Description of problem: libvirt cannot create virtio-scsi-using VMs in Rawhide. The error is simply as in the summary: unsupported configuration: This QEMU doesn't support virtio scsi controller [code=67 domain=10] with no other information. Version-Release number of selected component (if applicable): qemu 1.6.0-1.fc20 libvirt 1.1.1-2.fc20 How reproducible: 100% Steps to Reproduce: 1. Try to run (eg) libguestfs-test-tool on Fedora 20, or any other libguestfs program / tool. Additional info: http://kojipkgs.fedoraproject.org//work/tasks/843/5830843/build.log
Strangely this was only seen on i686. It doesn't happen on x86-64.
qemu.i686 appears to be pretty broken: $ qemu-system-i386 --help qemu-system-i386: symbol lookup error: qemu-system-i386: undefined symbol: rbd_aio_flush I opened a new bug about this: bug 998722 Maybe this is the cause of the current bug, but shouldn't libvirt give a more obvious error if qemu won't run at all?
qemu-kvm stopped supporting 'virtio-scsi' model of 'scsi' controller. libvirt 1.1.1-2.fc20 should have my commit b7f1c0c38729e5eba44ba134b93b1b95a4dae8d8 in, so it means libguestfs is requesting particularly this model. The error describes exactly what is going on, you can check that by running: qemu-kvm -device '?' especially: qemu-kvm -device '?' 2>&1 | grep '"virtio-scsi"'
(In reply to Martin Kletzander from comment #3) > qemu-kvm stopped supporting 'virtio-scsi' model of 'scsi' controller. > libvirt 1.1.1-2.fc20 should have my commit > b7f1c0c38729e5eba44ba134b93b1b95a4dae8d8 in, so it means libguestfs is > requesting particularly this model. As noted above, this works fine on x86-64, but fails on identical packages on i686. Also as noted, qemu.i686 is totally broken (bug 998722). > The error describes exactly what is > going on, you can check that by running: > > qemu-kvm -device '?' > > especially: > > qemu-kvm -device '?' 2>&1 | grep '"virtio-scsi"' On x86-64: $ qemu-kvm -device '?' 2>&1 | grep '"virtio-scsi"' $ qemu-kvm -device '?' 2>&1 | grep '"virtio-scsi-pci"' name "virtio-scsi-pci", bus PCI, categories "Storage" On i686 [see bug 998722]: $ qemu-kvm -device '?' /usr/bin/qemu-system-x86_64: symbol lookup error: /usr/bin/qemu-system-x86_64: undefined symbol: rbd_aio_flush libguestfs uses the following XML for specifying the device (and has for ages): <devices> <controller type="scsi" index="0" model="virtio-scsi"/> <disk device="disk" type="file"> <source file="/tmp/libguestfs6JEnee/scratch.1"/> <target dev="sda" bus="scsi"/> <driver name="qemu" type="raw" cache="none"/> <address type="drive" controller="0" bus="0" target="0" unit="0"/> </disk>
The missing symbol error will have totally fubar'd libvirt's capabilities detection. So that'll be why we don't detect virtio scsi support on i686. Fixing bug 998722 ought to fix this bug too.
(In reply to Daniel Berrange from comment #5) > The missing symbol error will have totally fubar'd libvirt's capabilities > detection. So that'll be why we don't detect virtio scsi support on i686. > Fixing bug 998722 ought to fix this bug too. Can the error message not be improved? qemu has long supported -help (it was added in Jan 2007), so I would suggest that we ignore any versions of qemu older than this, and then if qemu -help prints an error, fail hard and display the error.
(In reply to Richard W.M. Jones from comment #6) > (In reply to Daniel Berrange from comment #5) > > The missing symbol error will have totally fubar'd libvirt's capabilities > > detection. So that'll be why we don't detect virtio scsi support on i686. > > Fixing bug 998722 ought to fix this bug too. > > Can the error message not be improved? > > qemu has long supported -help (it was added in Jan 2007), so I would > suggest that we ignore any versions of qemu older than this, and > then if qemu -help prints an error, fail hard and display the error. That might be possible. I have a vague recollection that -help would print to stderr rather than stdout in some older versions, but I might be mistaken in that. Alternatively we might be able to check exit status of qemu -help to detect this kind of failure.
AFAIK qemu doesn't do any module loading, so it's just completely broken: $ qemu-kvm -M none /usr/bin/qemu-system-x86_64: symbol lookup error: /usr/bin/qemu-system-x86_64: undefined symbol: rbd_aio_flush $ qemu-kvm -M none -device \? /usr/bin/qemu-system-x86_64: symbol lookup error: /usr/bin/qemu-system-x86_64: undefined symbol: rbd_aio_flush
qemu needs a dep on a newer ceph-libs apparently, F19 is also affected *** This bug has been marked as a duplicate of bug 995883 ***