Recently I hear that the experimental x-data-plane feature from virtio-blk was production-ready and that virtio-scsi also got support for it, so, after finding what the new syntax is: http://comments.gmane.org/gmane.comp.emulators.qemu/279118 ...I decided to test it. After all, it was supposed to be a free huge performance boost.
My test setup: 1- A Xen Host running Xen 4.5 with Arch Linux as Dom0 using Kernel 4.0, and three VMs (One main everyday VM, another for some work which I want isolated, and the Nested KVM Host). I'm intending to replace this host with QEMU-KVM-VFIO after I nail down all the details.2- A Nested KVM Host running Arch Linux using Kernel 4.4 and QEMU 2.5 (I'm not using libvirt, just standalone QEMU). Since I'm using Nested Virtualization, this host can create KVM capable VMs3- A test VM spawned by the Nested KVM Host. I just use it to boot ArchISO (Arch Linux LiveCD) and check if things are working The problem (And the reason why I'm sending this mail) is that when I launch QEMU from the command line to create a VM using virtio-scsi-pci with the iothread parameter, it throws a strange "Guest moved index from 0 to 61440" warning. Some googling reveals that this error appeared for some users in totally different circunstances (Like removing not-hotpluggable devices) and that its actually a fatal error that makes the VM hang, crash, or something else, but in my case, it appears only at the moment that I create the VM, and it seems to work after the warning. However, since the device involved is a storage controller, I'm worried about possible data corruption or other major issues. The bare minimum script that produces the warning, should be this: #!/bin/bash qemu-system-x86_64 \-m 1024M \-enable-kvm \-object iothread,id=iothread0 \-device virtio-scsi-pci,iothread=iothread0 \ This produces the "Guest moved index from 0 to 61440" warning. It happens when virtio-scsi-pci has the iothread parameters set.Of note, not using -enable-kvm in the previous script produces this fatal error: virtio-scsi: VRing setup failedqemu-system-x86_64: /build/qemu/src/qemu-2.5.0/memory.c:1735: memory_region_del_eventfd: Assertion `i != mr->ioeventfd_nb' failed. ...but since I didn't googled if having KVM enabled was required to use virtio-scsi-pci or other VirtIO devices, I don't know if this is standard behavior or unintended, so this may not be important at all. You can even get multiple warnings, one for each virtio-scsi-pci device using iothreads. For example... #!/bin/bash qemu-system-x86_64 \-monitor stdio \-m 1024M \-enable-kvm \-object iothread,id=iothread0 \-object iothread,id=iothread1 \-object iothread,id=iothread2 \-device virtio-scsi-pci,iothread=iothread0 \-device virtio-scsi-pci,iothread=iothread1 \-device virtio-scsi-pci,iothread=iothread2 \-device virtio-scsi-pci \ This one produces three identical "Guest moved index from 0 to 61440" warnings on the Terminal.Using info iothreads on QEMU Monitor does shows the three IO Threads. Additional -object iothread,id=iothreadX that aren't used, or -device virtio-scsi-pci devices that aren't using a iothread, does not produce extra warnings. The warning does NOT happen if I use instead virtio-blk-pci with iothread. This is a more complete test script booting the Arch Linux ArchISO LiveCD, which was what I was using previously when I found the warning the first time: #!/bin/bash qemu-system-x86_64 \-name "Test VM" \-monitor stdio \-m 1024M \-M pc-q35-2.5,accelt=kvm \-nodefaults \-drive if=none,file=archlinux-2016.03.01-dual.iso,readonly=on,format=raw,id=drive0-drive if=none,file=/dev/vg0/lv0,format=raw,id=drive1 \-drive if=none,file=filetest1.img,format=raw,id=drive2 \-drive if=none,file=filetest2.img,format=raw,id=drive3 \-device ide-cd,drive=drive0 \-device qxl-vga \-object iothread,id=iothread0 \-object iothread,id=iothread1 \-object iothread,id=iothread2 \-device virtio-scsi-pci,iothread=iothread0,id=scsi0 \-device virtio-scsi-pci,iothread=iothread1,id=scsi1 \-device scsi-hd,bus=scsi0.0,drive=drive1 \-device scsi-hd,bus=scsi1.0,drive=drive2 \-device virtio-blk-pci,iothread=iothread2,drive=drive3 \ Starting the VM produces two warnings on the Terminal. Arch Linux however does see with lsblk the drives sda and sdb (Plus vda for the VirtIO Block Device), and lsblk does show two Virtio SCSI Controllers (Plus the VirtIO Block Device). I didn't tried to read or write to them to check if they work. I also asked to a guy at QEMU IRC that had an Arch Linux host with a cloned test VM with a virtio-scsi-pci device, to add the -object iothread and iothread parameter to virtio-scsi-pci. He said that it worked and he didn't received any Terminal warning, but that Windows CPU Usage was always 100% when he launched with it. I don't know if in his case, VirtIO Windows Drivers may be the reason (Sadly, forgot to ask Windows and VirtIO Drivers versions). In my VM with ArchISO, using top, CPU Usage seems to be under 1%, so at least in Linux it doesn't happens. Basically, I want if someone can confirm me if the warning happens to someone else, why, and if its something to worry about that should be fixed (Possible data corruption), or I can merely ignore it. Maybe is Nested Virtualization related and doesn't happen on bare metal... As an additional question, I have found some somewhat related info here... http://pve.proxmox.com/pipermail/pve-devel/2015-January/013970.html ...that seems to say that if I want to use iothreads with virtio-scsi, since you can't point a scsi-hd to an iothread, you should place each scsi-hd at an exclusive virtio-scsi-pci controller, each with its own iothread. So if I have 10 scsi-hd, I should have 10 virtio-scsi-pci with 10 iothread objects. Is this required, or just recommended? At least I tried with a single virtio-scsi-pci with iothread and two scsi-hd attached to it, and besides the warning, they looked in lsblk as expected. Wasn't one of the goals of virtio-scsi to allow consolidating multiple drives on a single PCI Device Slot instead of requiring one per drive like virtio-blk? It seems like using iothreads hurts that goal a bit. Is there any other feature or performance reason to use virtio-scsi, or should I be like the other home users and just stick to virtio-blk? Finally, does using iothreads adds anything at all to the QEMU Monitor qtree? I also tested having two virtio-scsi-pci, one with iothread and other without, and can't find a way to figure out by using info qtree if there is a parameter that tells you that it is using an iothread.
