☰

QEMU-虚拟驱动器的实际磁盘大小不正确

tag-icon • tag-icon virtualization virtual-machines kvm-virtualization filesystems qemu
QEMU-虚拟驱动器的实际磁盘大小不正确

df并ls报告主机上不同的大小，因为分配的大小和 EXT4 文件系统中实际使用的空间量不同。问题是两者都报告了错误的大小。qemu-img也没有报告客户机文件系统（也是 EXT4）内实际使用的空间。

在主机上：

# qemu-img info sdb.raw
image: sdb.raw
file format: raw
virtual size: 2.0T (2173253451776 bytes)
disk size: 1.9T

# ls -larth sdb.raw 
-rw-r--r-- 1 hypervisor hypervisor 2.0T Mar  6 13:47 sdb.raw

# du -sh sdb.raw 
1.9T   sdb.raw

# fdisk -l sdb.raw 
Disk sdb.raw: 2 TiB, 2173253451776 bytes, 4244635648 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: E6242A7E-1253-E74A-9389-68654A21E4F4

Device     Start        End    Sectors Size Type
sdb.raw1    2048 4244635614 4244633567   2T Linux filesystem

在客户机上（/dev/vdb1）：

# df -h
Filesystem      Size  Used Avail Use% Mounted on
dev              32G     0   32G   0% /dev
run              32G  496K   32G   1% /run
/dev/vda2       220G  100G  111G  48% /
tmpfs            32G     0   32G   0% /dev/shm
tmpfs            32G     0   32G   0% /sys/fs/cgroup
tmpfs            32G   26M   32G   1% /tmp
/dev/vdb1       2.0T  761G  1.2T  41% /root
tmpfs           6.3G     0  6.3G   0% /run/user/1002

如您所见，我在客户系统上只使用了 761G，还有 1.2T 可用。尽管如此，它却qemu-img显示我正在使用 1.9T。这是什么原因？有办法解决这个问题吗？我想看看主机上实际使用的空间。我知道这是可以实现的，因为在我填充sdb.raw数据之前它工作正常 - qemu 根据磁盘内部使用的空间报告了正确的磁盘大小。不幸的是，它只能以一种方式工作 - 当使用空间逐渐增加时。在我删除一些文件并将使用空间从 1.9T 减少到 761G 后，报告的大小qemu-img并没有变为更小的值，它仍然保持在 1.9T。

答案1

qemu-img并且du都报告实际分配的空间从主机角度来看。他们无法知道/理解客户操作系统是否真的在使用该空间，或者是否像您的情况下一样，该空间已被用户释放。

要通知主机，您的客户机有大量可用空间，您需要将fstrim客户机文件系统和您必须确保您的 qemu/guest 块设备堆栈正确传递TRIM/discard请求。为此，您需要：

  • 使用支持 TRIM/discard 的 qemu 块设备驱动程序。此类驱动器的示例包括virtio-scsi、scsi和sata/ahci。所有这些驱动程序都使用经典/dev/sd[abcd...]命名法来公开块设备。另一方面，您的客户机似乎正在使用普通virtio驱动程序（带有/dev/vd[abcd...]名称），它确实不是支持 TRIM/discard。您可以通过发出以下命令来检查您的驱动程序是否支持丢弃lsblk -D；

  • 启用相对libvirt 域discard=unmap选项；

最后，您的主机必须使用hole_punching支持 ext4（您正在使用）和 xfs 的文件系统。

你可以阅读这里了解更多信息。

如果所有先决条件都满足，fstrim <mount_point>则在客户机中发出命令也会自动取消分配主机上未使用的空间。请务必了解逻辑/表观文件大小将保持不变（即：此后它将一直显示 2.0 TB fstrim），但使用qemu-img或du将显示真实（较小）的分配文件大小。

如果不满足先决条件，您需要通过以下方式离线压缩您的图像文件virt-sparsify或者qemu-img convert 用零清理客人可用空间后（IE：dd if=/dev/zero of=bigfile bs=1M count=<almost_all_free_space>; rm bigfile）。

请务必理解上述步骤的含义：任何错误都可能对您的图像文件造成无法挽回的损坏。在对磁盘映像文件进行任何操作之前，请确保已进行可靠的备份！*

答案2

这是预期的行为。正如您所写的，“在我删除一些文件并将已用空间从 1.9T 减少到 761G 之后” - 原始虚拟映像无法自动“收集垃圾”，即使对于已删除的文件，实际空间仍将保持写入和分配状态。解决方法是执行（双重）转换 raw>qcow2(>raw)。

更详细的解释在这里 -https://balau82.wordpress.com/2011/05/08/qemu-raw-images-real-size/ 和这里 -https://techpiezo.com/tech-insights/raw-vs-qcow2-disk-images-in-qemu-kvm/

相关内容