[vfio-users] Disk Performance
commendsarnex at gmail.com
Sun Apr 3 02:26:27 UTC 2016
Thanks for your detailed post. I believe I have already changed my script
to make sense, thanks to the previous reply. I've attached it again below.
For networking, I am using a wireless card where I cannot create a bridge,
and my IP changes very often. Is there a simple way to manually create a
tap with this? I wasn't able to get either of the 2 most popular tutorials
qemu-system-x86_64 -enable-kvm \
-m 5120 \
-cpu host \
-smp 6,sockets=1,cores=6,threads=1 \
-device vfio-pci,host=01:00.0,x-vga=on,multifunction=on \
-device vfio-pci,host=01:00.1 \
-vga none \
-device vfio-pci,host=00:12.0 \
-device vfio-pci,host=00:12.2 \
-device vfio-pci,host=00:16.0 \
-device vfio-pci,host=00:16.2 \
-soundhw ac97 \
-rtc base=localtime \
-netdev user,id=net0 \
-device virtio-net-pci,netdev=net0 \
-object iothread,id=iothread2 \
On Sat, Apr 2, 2016 at 9:56 PM, Zir Blazer <zir_blazer at hotmail.com> wrote:
> 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-cd
> The 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-cd
> The VirtIO Block Device, which is paravirtualized and the mainstream
> performance choice. -device virtio-blk-pci
> The 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
> 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
> -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:
> vfio-users mailing list
> vfio-users at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vfio-users