正文共:999 字 11 图,预估阅读时间:1 分钟
书接上文**(** 不会吧!KVM竟然不支持磁盘的精简置备!?) ,我们已经掌握了通过**"虚拟系统管理器VMM"** 创建虚拟机的基本方法,但是遗留了一个问题,那就是通过页面创建没有**"精简置备"**磁盘的选项,导致磁盘空间占用非常高,无法创建足够数量的虚拟机。
简单回顾一下,这是我们虚拟机的虚拟磁盘,存储大小为30 GB,存储格式为qcow2,其他为默认选项,没有"精简置备"的选项。
从命令行查看文件,大小同样为30 GB。
我想在网上搜一下解决方案,没想到竟然直接搜到了我提出的问题,这也太尴尬了!
没办法,再翻翻其他的。
结合广大同学的建议,基本上都指向了一个改进方向,那就是命令行操作。但是Libvirt不能直接使用精简置备的卷来作为存储池,即创建逻辑卷时,没有精简置备的选项。
如果要将精简卷与libvirt一起使用,有两种可能的操作:
1、手动创建所需的精简卷,再将其挂载到虚拟机上;
2、创建一个大型精简卷,使用XFS对其进行格式化,挂载它并使用libvirt创建一个基于目录的存储池(将VM磁盘映像创建为XFS文件系统上的纯文件)。
主要操作命令是qemu-img,命令的介绍和用法请参考**(** qemu-img命令手册)。
使用qemu-img命令手册查看磁盘镜像文件信息。
可以看到,文件格式为qcow2,磁盘大小为30 GB,但是实际已使用空间为31 GB,估计是计算方法不一样导致的。
"compat"值为1.1,表示需要匹配QEMU版本为1.1或更新版本,才能支持镜像格式扩展。"lazy_refcounts"值为true,表示引用计数更新将被推迟,目的是避免元数据I/O并提高性能。
但是并没有精简置备相关的说明。
qemu-img命令手册中提到,"qcow"和"qcow2"格式支持压缩-c,我们测试一下。
css
qemu-img convert -c -O qcow2 centos7.0.qcow2 thin.qcow2
压缩之后的文件大小仅有800多兆,查看一下文件信息。
看一看到,"lazy_refcounts"的值发生了变化,变成了false,同时,磁盘使用大小变成了797 MB,锐减至只有之前的2.6 %。难道和这个属性相关?
我们把之前的硬盘移除,然后挂载这个新的硬盘看看能不能用。
可以看到,磁盘信息和之前没有差别。启动虚拟机试一下。
OK,可以使用。
也就是说,我们前面提到的第一种方法,手动创建所需的精简卷,再将其挂载到虚拟机上,这种方式是可行的。
然后看一下磁盘的大小变化。
上面是虚拟机开机的情况,下面是虚拟机关机的情况,可以看到,qemu-img命令读到的实际磁盘大小差别不大。但是在开机状态下,使用du命令读到的估计文件空间使用情况稍大,大概多300M左右,可能和虚拟内存相关。
当然,我们也可以在创建虚拟机之前手工创建磁盘文件,命令如下:
css
qemu-img create -f qcow2 test.qcow2 30G
lazy refcounts的值同样为false,我们试着创建一个值为true的镜像。
sql
qemu-img create -f qcow2 -o compat=1.1 -o lazy_refcounts=on test2.qcow2 30G
OK,确认了,不是lazy refcounts属性的问题。
综合来看,确实是VMM或者说是Libvirt的问题,它不能直接创建精简置备的卷来作为存储池,而是需要先手动创建所需的精简卷,再将其挂载到虚拟机上。
这么一来,确实麻烦了不少啊。
长按二维码
关注我们吧
<>
KVM部署初体验
<> <>
不会吧!KVM竟然不支持磁盘的精简置备!?
<> <>
vCenter Server Appliance部署实录
<> <>
vCenter(Linux版)从开机到部署一镜到底
<> <>
VMWare ESXi中,不同的虚拟网卡性能竟然能相差三倍!
<> <>