Difference between virtio and virtio single controller types?
- Thread starter WvdW
- Start date
More exactly virtio-scsi appears to the emulated guest as a standard scsci controller, so every SCSI command ( think:discard ) works there to.
Disk will appear like normal disks under a Linux guest /dev/sda,b,c
virtio controller is a special controller of its own kind and disks will appear as /dev/vda,b,c
Both of them should give you similar performances.
Disk will appear like normal disks under a Linux guest /dev/sda,b,c
virtio controller is a special controller of its own kind and disks will appear as /dev/vda,b,c
Both of them should give you similar performances.
I want to point out that neither of these responses actually talks about the difference between:
I can't find any documentation myself just yet either, so knowing what exactly the differences are would be important to us admins. Can we get these things documented somewhere please?
- "VirtIO SCSI" and
- "VirtIO SCSI single"
I can't find any documentation myself just yet either, so knowing what exactly the differences are would be important to us admins. Can we get these things documented somewhere please?
The 'single' variant can starts an extra IO thread per disk, so this can sometimes give better performance.
Last edited:
virtio-scsi-single is required to enable iothread. (and multiqueues in the future).
with virtio-scsi-single, you have 1 virtio-scsi controller by scsi disk.
virtio-scsi classic, you have all scsi disk on same virtio-scsi controller.
with virtio-scsi-single, you have 1 virtio-scsi controller by scsi disk.
virtio-scsi classic, you have all scsi disk on same virtio-scsi controller.
So I need to select VirtIO SCSI single in Options, and also enable IO Thread for every disk in Hardware to ensure iothread is working?
Is there any other limitation (cache type, etc.) for iothread? Right now my VM is on zfs-local, with cache=writeback.
Is there any reliable way to verify that iothread is working?
No, it means you will not be able to rollback a life snapshot (starting old snapshot crashes qemu)
your don't need to enable iothread on all disk. each disk can have his own iothread.
if you don't check iothread, the disk use the main qemu thread.
The bug was due to memory corruption so when rolling back qemu crashed. You say it is fixed, but is this fix in enterprise repo?
Neat info! Could we get the wiki updated to reflect this info? 
If you want I could help with such things occasionally?
If you want I could help with such things occasionally?
@BloodyIron: yes
sent a short email referecing this thread to office at proxmox com and ask for an account
wiki is currently invite only due to spam abuse
sent a short email referecing this thread to office at proxmox com and ask for an account
wiki is currently invite only due to spam abuse
the VM configuration is checked at the beginning of the backup and an error message is returned if iothreads are enabled on any of the disks that should be included in the backup.