Should I use “detect-zeroes” for TRIM/discard support on QEMU guests

kvm-virtualizationlibvirtqemu

Until now I've enabled discard on my QEMU guests using the libvirt XML command

..
<driver name='qemu' type='qcow2' discard='unmap' />
..

And it seems to work fine.

Now that I'm about to convert my storage from virtio-scsi to virtio-blk because it now support discard, I ran into the option detect_zeroes=off|on|unmap (or QEMUs equivalent detect-zeroes)

Should I also use this option and why?
I assume beside the areas will be marked "available" by discard they are also written by zeroes, but what values does it have, especially on SSD backed storage?

Using qcow2 images I see the point of writing zeros to mark the empty space sparsed, but it seems the qcow2 image files are actually getting smaller (sparsed) without this option and just using discard='unmap'.

The libvirt documentation says:

The optional detect_zeroes attribute controls whether to detect zero write requests.
The value can be "off", "on" or "unmap". First two values turn the detection off and on, respectively.
The third value ("unmap") turns the detection on and additionally tries to discard such areas from the image based on the value of discard above (it will act as "on" if discard is set to "ignore"). NB enabling the detection is a compute intensive operation, but can save file space and/or time on slow media. Since 2.0.0

Which unfortunately didn't got me closer to a decision of using detect_zeroes or not :-/

Backing storage for my QEMU guests are both qcow2 images on HDD and SSD and LVM block devices located on SSD.

Best Answer

Modern operating systems are capable of sending TRIM/UNMAP commands to the virtual storage to free up the space, so detect_zeroes is not necessary for such OSes.

The only reason I can think of to use detect_zeroes is to gain discard support for an ancient operating system that doesn't support TRIM/UNMAP. In this case blocks of zeroes will be unmapped when you set detect_zeroes='unmap' instead of blocks of zeroes being written to disk. In the virtual guest OS you would run some utility that writes zeroes to all the free space on the disk, and KVM will convert these to TRIM/UNMAP. This can be CPU intensive though. Also, I can't figure any good reason to have it on without unmap.

P.S. You said: "Now that I'm about to convert my storage from virtio-scsi to virtio-blk" ... Did you get these backward? Normally you convert from virtio-blk to virtio-scsi.

Related Solutions

Linux – mount qcow2 snapshots

You should apply the snapshot and mount the image like always. It's better to create a snapshot right before applying if you want to turn back to the original disk contents before you do these operations. After you apply the snapshot you just mount the image with qemu-nbd as always:

# modprobe nbd max_part=8
$ qemu-img snapshot -c backup image.qcow2
$ qemu-img snapshot -a old_snapshot image.qcow2
$ qemu-nbd --connect=/dev/nbd0 image.qcow2
# mount /dev/nbd0p1 /mnt

You might want to save snapshot separately and mount it as another disk drive. For this you should use convert comand for qemu-img.

$ qemu-img convert -s old_snapshot image.qcow2 old_snapshot.qcow2
$ qemu-nbd --connect=/dev/nbd0 old_snapshot.qcow2
# mount /dev/nbd0p1 /mnt

See man qemu-img(1) and qemu-nbd(1) for more details.

Kvm low io performance

The optimal configuration is (usually) as follows:

On the host, set elevator=deadline
Use virtio and only virtio
use raw LVs whenever possible. Qcow2 gives overhead. Files on a FS also have overhead
in the VM use the elevator=noop
both in host and VM, use noatime,nodiratime in fstab wherever possible
Make sure the virtio drivers are up to date, especially the windows ones.
Debian based distros are (arguably) not as good as Fedora and RHEL for QEMU/KVM. Not to start a flamewar, but most of the development and testing is done on Fedora and RHEL, and in my own experience, there have been lots of issues on Ubuntu and Debian that I couldn't reproduce on Fedora and RHEL. You can ignore this particular bullet if you want, but if you're looking for a solution, a quick benchmark on another distro is usually worth a try

Best Answer

Related Solutions

Linux – mount qcow2 snapshots

Kvm low io performance

Related Topic