Hello John. It looks like you're making too much conspiracy theories out of this simple problem.
I don't remember how this worked in 1.1 times of qemu. Apparently libvirt chooses -nodefaults and the result is that the pci bus created does not support hotplug, since libvirt didn't specify if qemu should enable that property or not. The fact that the operation is "half-worked" is a bug indeed -- qemu should clean up on the error path. It opens the device first and only when it's done, it tries to hotplug it, to discover that the pci bus does not support hotplugging. And it "forgets" to close the device. This is a bug, but a minor one, and it is fixed long ago in subsequent versions of qemu. Now, everything works fine with more recent versions of libvirt and qemu. At least 2.1 version of qemu which is available in wheezy-backports for a very long time works fine with libvirt from wheezy-backports. I haven't looked at the details and have no idea where this bug has been fixed, but I suspect it is libvirt, not qemu, since with -nodefaults qemu should explicitly specify hotpluggable attribute. One more possibility is that it is the guest OS who should have proper drivers for hotplug to be enabled, so by default PCI bus does not support hotplug, in order to not confuse an unsuspecting OS, and allows hotplugging only after an OS (guest in this case) driver enables this feature. I don't remember, this is a pure speculation, because it's been long ago since I looked at this, and even when it was only a brief look. So, basic recommendation is to check if your guest actually enables hotplug (if that's needed), and try with a more recent version. It definitely works with current qemu & libvirt. So, I've no other choice but to just close this bug report. I'll keep it open for a while just in case. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
