Description of problem: VDSM for ppc64 must run with a newer version of qemu, otherwise an error related to the Virtual USB host device occurs. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Configure a Data Center, Cluster, Host and VM for the ppc64 architecture in oVirt engine 2. Run the created VM Actual results: QEMU crashes with the following error: qemu-system-ppc64: -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:16:01:51,bus=pci,addr=0x1: PCI: slot 1 function 0 not available for virtio-net-pci, in use by pci-ohci qemu-system-ppc64: -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:16:01:51,bus=pci,addr=0x1: Device 'virtio-net-pci' could not be initialized Expected results: The VM runs normally. Additional info: This PCI address conflict was fixed in QEMU 1.6, but in QEMU 1.4.2 (the version shipped with Fedora) it occurs.
Can this fix be backported to Fedora 19's qemu? If not, I would not mind adding an explicit spec-file dependency (for the ppc64 arch).
Adding Cole as he is the maintainer of qemu in Fedora. If there is a well-defined patch that cleanly applies to qemu, then you will need to open a bug against component=qemu & product=Fedora, and link it to this bug.
This error can be reproduced in QEMU using the command line: /usr/bin/qemu-system-ppc64 -machine pseries,accel=tcg,usb=off -m 1024 -smp 1,sockets=1,cores=1,threads=1 -no-user-config -nodefaults -no-shutdown -device spapr-vscsi,id=scsi0,reg=0x2000 -device virtio-scsi-pci,id=scsi1,bus=pci,addr=0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci,addr=0x4 -usb -drive if=none,id=drive-scsi0-0-0-0,readonly=on,format=raw,serial= -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 -netdev user,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:fa:c3:90,bus=pci,addr=0x1 -device usb-tablet,id=input0 -vnc 0:0 -k en-us -vga std -device virtio-balloon-pci,id=balloon0,bus=pci,addr=0x6 -usbdevice keyboard @Cole, do you have any idea why the PCI slot 1 is free in QEMU 1.6.0 and occupied by pci-ohci in QEMU 1.4.2?
I don't know offhand, git log doesn't show anything obvious. someone would have to bisect. Hopefully not a case of -M pseries changing ABI since maching types are supposed to be stable.
I found some extra info in this issue, if I call qemu like this: /usr/bin/qemu-system-ppc64 -machine pseries,accel=tcg,usb=off -m 1024 -smp 1,sockets=1,cores=1,threads=1 -no-user-config -nodefaults -no-shutdown -device spapr-vscsi,id=scsi0,reg=0x2000 -device virtio-scsi-pci,id=scsi1,bus=pci,addr=0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci,addr=0x4 -usb -drive if=none,id=drive-scsi0-0-0-0,readonly=on,format=raw,serial= -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 -netdev user,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:fa:c3:90,bus=pci,addr=0x1 -device usb-tablet,id=input0 -vnc 0:0 -k en-us -vga std -device virtio-balloon-pci,id=balloon0,bus=pci,addr=0x6 -usbdevice keyboard The error occurs, but if I replace '-vga std' with '-device VGA', the guest starts properly: /usr/bin/qemu-system-ppc64 -machine pseries,accel=tcg,usb=off -m 1024 -smp 1,sockets=1,cores=1,threads=1 -no-user-config -nodefaults -no-shutdown -device spapr-vscsi,id=scsi0,reg=0x2000 -device virtio-scsi-pci,id=scsi1,bus=pci,addr=0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci,addr=0x4 -usb -drive if=none,id=drive-scsi0-0-0-0,readonly=on,format=raw,serial= -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 -netdev user,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:fa:c3:90,bus=pci,addr=0x1 -device usb-tablet,id=input0 -vnc 0:0 -k en-us -device VGA,id=video0,bus=pci,addr=0x7 -device virtio-balloon-pci,id=balloon0,bus=pci,addr=0x6 -usbdevice keyboard Probably it has something to do with this code in spapr.c in the QEMU source code: if (usb_enabled(spapr->has_graphics)) { pci_create_simple(phb->bus, -1, "pci-ohci"); if (spapr->has_graphics) { usbdevice_create("keyboard"); usbdevice_create("mouse"); } }
This is an automated message. Re-targeting all non-blocker bugs still open on 3.4.0 to 3.4.1.
This is an automated message. oVirt 3.4.1 has been released. This issue has been retargeted to 3.5.0 since it has not been marked as high priority or severity issue, please retarget if needed.
let's not waste time on F19 anymore, it's old and about to be EOL soon Fixed in F20+ so no need to track anymore