[vfio-users] Disk Performance

[Zir Blazer]

I spend a lot of time experimenting what works and what doesn't, through I never benchmarked anything to see performance differences.The main issue is that QEMU has a load of old syntaxis and parameters mixed with new ones that you must use to get the latest features, and documentation is extremely poor, so as an end user, I have absolutely no way to know what extra parameters I can tweak beyond the common sense ones. It takes A LOT of googling to understand how things works, and even then, it just to get them working, not even performance optimization.
The first thing you need to understand, is that just because QEMU seems to work and it starts your VM, does NOT MEANS that you get the things connected as you intend. For example, on your initial script, you are creating a VirtIO SCSI Controller, but you are NOT creating a scsi-hd to attach to it. Eventually, you will figure out that if you want to experiment, you need to use QEMU Monitor. Use -monitor stdio to have it at the Terminal you launch QEMU from. You can use info qtree to see a heavy Wall of Text that you will eventually figure out how to understand that tells you how things are connected, or basically, at what Bus or Controller each Device is attached.

At the moment, the current Storage Controllers contenders are these:
The PIIX3 IDE Controller provided by the i440FX platform, -device piix3-ide. Requires ide-hd/ide-cdThe ICH9 SATA Controller provided by the Q35 platform, which always runs in AHCI Mode (No IDE emulation) and supports NCQ, -device ahci-ich9. Requires ide-hd/ide-cdThe VirtIO Block Device, which is paravirtualized and the mainstream performance choice. -device virtio-blk-pciThe VirtIO SCSI Controller, which is also paravirtualized. Performance was nearly that of the VirtIO Block Device, but you could attach several SCSI HDs to a single controller, instead of needing one controller per drive. -device virtio-scsi-pci. Requires scsi-hd/scsi-cd
The Q35 ICH9 SATA Controller always runs in AHCI Mode, is not like the one you usually find in any Motherboard that you can set if you want IDE emulation. Basically, if you want to use Windows XP with it, you need to either slipstream the ICH9 AHCI Drivers with nLite, or pass to the VM a Floppy image with them to do the F6 installation procedure.The VirtIO Devices always need Drivers for Windows, easier way is to use the Fedora VirtIO Drivers ISO during Windows installation. VirtIO Block Device has Drivers for WXP, but VirtIO SCSI Controller does not, only Vista+.
Specifying Drives with the latest QEMU syntax is a two or three step procedure, and must be made in the following order on the command line:
1) You need to specify the host-side place that will represent the contents of the virtual Hard Disk. You do that with -drive.
-drive if=none,id=drive0,format=raw,file=/dev/vg0/w10x64
file= could be an entire Hard Disk (/dev/sdb), a physical partition (/dev/sda3), a LVM volume (/dev/vg0/lv0), a file (filebackedvm.img), etc. It can also be empty, which you can use if you want to create a CD-ROM drive that has no ISO inserted (Since ide-cd and scsi-cd requires a valid drive id parameter, but -drive doesn't requires a file=).
2) You need to create a Controller that will provide the Bus for the HDs that will contain those host-side routes to attach to:
-device virtio-scsi-pci,id=scsi0
On i440FX and Q35 you already have an IDE Bus thanks to the PIIX3 and ICH9. But we want to use the latest and greatest, so here you have the VirtIO SCSI Controller.
3) You need to create a Device that represents the virtual IDE or SCSI HD/CD with the host route from -drive, and attach it to the correct controller (IDE for either PIIX3 or ICH9, SCSI for... you guessed it, SCSI Controllers):
-device scsi-hd,drive=drive0,bus=scsi0
Important exception is the VirtIO Block Device, which is its own Controller and attaches the Drive to itself directly:
-device virtio-blk-pci,drive=drive0
There you have it working. Order is important since if you try to use -device scsi-hd before creating the SCSI Controller that provieds the SCSI Bus, QEMU will complain and refuse to create your VM.
Note that if there is only one SCSI Controller, you can avoid assigning manually bus= since there is only one SCSI Bus on the entire system, and QEMU will attach it to the only available controller, so you can merely do -device scsi-hd,drive=drive0. But if you were to use two SCSI Controllers, you may need to specify it so you get your intended topology. The more controllers you have, the more you may want to do things manually.For example, it happens when you use too many USB Devices. Even if you create two of the nec-usb-xhci Controllers, QEMU will by default try to saturate one Controller,, automatically creates an USB Hub for it, and keep attaching more USB Devices, instead of going to the second Controller. You will start to notice those very ugly things as you get friendly with QEMU Monitor info qtree.


Also important, -netdev user should be the least performing choice for Networking, and should be avoided unless you want to use it that way. The issue with QEMU Networking is that you need some understanding of how to configure a basic Bridge and TAP Device at the host side, and that may drastically change depending on your Linux distribution and the readily available tools, so I can't walkthrough those for you.For reference, you may want to check this Mail I sent to qemu-users. It has my current MACVLAN/MACVTAP (Which are supposed to be better than traditional Bridge + TAP)  templates for systemd-networkd in Arch Linux:http://lists.nongnu.org/archive/html/qemu-discuss/2016-03/msg00042.html 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20160402/c43a7f55/attachment.htm>