$ uname -r
$ findmnt /
/      /dev/vda3 ext4   rw,relatime,seclabel
$ sudo fstrim -v /
fstrim: /: the discard operation is not supported

Same VM, but after switching the disk from VirtIO to SATA:

$ findmnt /
/      /dev/sda3 ext4   rw,relatime,seclabel
$ sudo fstrim -v /
/: 5.3 GiB (5699264512 bytes) trimmed

The virtual disk is backed by a QCOW2 file. I am using virt-manager / libvirt. libvirt-daemon is version 4.7.0-2.fc29.x86_64. My host is currently running a vanilla kernel build 5.1 (ish), so it's a little bit "customized" at the moment, but I built it starting from a stock Fedora kernel configuration.

Is there a way to enable discard support on VirtIO somehow? Or does the code just not support it yet? I don't necessarily require the exact instructions how to enable it, but I am surprised and curious and I would like a solid answer :-).


Apparently discard wasn't supported on that setting. However it can work if you change the disk from "VirtIO" to "SCSI", and change the SCSI controller to "VirtIO". I found a walkthrough. There are several walkthroughs; that was just the first search result. This new option is called virtio-scsi. The other, older system is called virtio-block or virtio-blk.

I also found a great thread on the Ubuntu bug tracker. It points out that virtio-blk starts supporting discard requests in Linux 5.0. It says this also requires support in QEMU, which was committed on 22 Feb 2019. Therefore in future versions, I think we will automatically get both VirtIO and discard support.

Currently my virt-manager does not create virtio-scsi disks by default, even when it knows I am installing Fedora 29; it only creates the basic "VirtIO" disks. I do not know if there is any disadvantage of switching to virtio-scsi.

I guess virtio-scsi provides the same sort of performance advantage as virtio-blk, when compared to emulated SATA. (I do not see an option to use NVME protocol anywhere in virt-manager :-P, with or without VirtIO).

The oVirt website has some nice propaganda, which mentions

  1. some limitations in virtio-blk
  2. virtio-scsi can be used in pass-through mode to a SCSI LUN, and can use various new SCSI command features without needing modifications in virtio-scsi . If you are not specifically using SCSI pass-through, then any new commands will require new support in QEMU, but not in the virtio-scsi code.
  3. virtio-scsi includes support for multiple queues. (I am not clear whether this is also helpful for efficiency on single-queue hardware, or not).
  • You should use virtio-scsi anyway; virtio-blk doesn't have as good performance and AFAIK isn't being well maintained anymore. virt-manager will eventually catch up; they use extremely conservative default settings unfortunately. – Michael Hampton May 10 '19 at 17:56
  • @MichaelHampton I suppose virtio-scsi got discard support without needing to add any more specific code for it :-). I probably won't bother with this issue until my laptop runs out of disk space again :-). A performance citation would be interesting if you had one. The references I find say it's mostly about features and flexibility and show the performance is similar in most cases. – sourcejedi May 10 '19 at 18:36
  • @MichaelHampton: According to RHEL pdf, see page 25. Admit it's from 2008, but still. It saysvirtio-blk has better performance and should be selected when possible. It's my impression it's still very much maintained. They "just" added the trim support a few qemu versions back. Are you still holding on to you statement, please correct me if I'm wrong. – MrCalvin Jun 22 '20 at 11:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.