Hi, 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 working.
Thanks, sarnex #!/bin/sh export QEMU_AUDIO_DRV=pa 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 \ -drive if=none,format=raw,cache=none,cache.direct=on,file=/media/500GB/win10.img,aio=native,id=ssd2,discard=off,detect-zeroes=off \ -object iothread,id=iothread2 \ -device virtio-blk-pci,drive=ssd2,request-merging=on,iothread=iothread2,modern-pio-notify=on,config-wce=off On Sat, Apr 2, 2016 at 9:56 PM, Zir Blazer <zir_bla...@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 > 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 > > _______________________________________________ > vfio-users mailing list > vfio-users@redhat.com > https://www.redhat.com/mailman/listinfo/vfio-users > >
_______________________________________________ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
