Red Hat Bugzilla – Bug 510907
libvirtd segfaults with redirected pci device not found
Last modified: 2009-08-15 04:30:16 EDT
Description of problem:
qemu-kvm domain contains a host pci deive redirected to the guest. When this is not found on trying to launch the guest, libvirtd segfaults. pid file is left behind which causes libvirtd to be unable to restart
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create xml VM defintion ("virsh dumpxml $VMName >$VMName.xml")
2. Add section to xml containing <hostdev> directive, referring to a [nonexistent|moved] pci device
3. launch libvirtd
4. "virsh start $VMName"
"Failed to open file '/sys/bus/pci/devices/0000:01:08.0/vendor': No such file or directory
libvirtd no longer running
"libvirtd" command returns:
"error : Failed to open pid file '/var/run/libvirtd.pid' : File exists"
libvirtd should gracefully handle error and return status code of unabel to start guest VM
pid file presence should not stop libvirtd restarting if it is not already running
Device is a wireless LAN card that has been removed from the host, strangely it never actually got directed to the guest when it was present as it shared an IRQ with Intel E1000 NIC. That failure was gracefully handled, but not now that the device is physically missing.
Created attachment 351387 [details]
XML definition file for guest VM.
Removing the <hostdev> directive starts the VM, but since nothing is logged I had quite a time tracking this down.
Fixed upstream in
Author: Daniel P. Berrange <firstname.lastname@example.org>
Date: Thu Jul 16 13:23:32 2009 +0100
Fix free of unitialized data upon PCI open fail
Built fix into libvirt-0.6.2-14.fc11
libvirt-0.6.2-14.fc11 has been submitted as an update for Fedora 11.
Compiled on F10, launched the VM using the old (broken) configuration, libvirtd survives :)
Thanks for the fix!
However, the error isn't very useful:
error: Failed to start domain XP1
error: this function is not supported by the hypervisor: Failed to read product/vendor ID for 0000:01:08.0
I'm assuming then that the error detail provided by qemu isn't great either, the error above would indicate that the device is unsupported rather than missing
The update (from libvirt-0.6.1-1 to libvirt-0.6.2-14) has however broken every other VM, since it now takes the <type arch='í686'> directive literally, whereas my 64-bit Windows VMs would boot just fine, switching into 64-bit mode even though the domain is defined as i686.
Since there is no option to redefine this in the GUI (where they were first defined, without specifying 32/64) any user would need to redefine the VM using virsh - unsure of any other means. Since a straight dump to XML includes the <target vnet> spec (which I'm not keen on locking down), this is quite a lot of work.
Worth posting a new bug/feature here?
Yep, the error message could do with improving, but at least it doesn't crash :-)
That's a known issue with no good answer. The previous config was requesting i686, but in fact giving you a x86_64 guest, which was in itself a serious bug that is now fixed. The best bet is to use 'virsh edit GUEST' while shutoff, to just change to x86_64 where required.
Well since x86_64 is a superset of i686, I can imagine this was a safe approach, I can't see a specific benefit of splitting the personalities.
But perhaps the focus of another forum. Thanks again, i've submitted a test report over on Fedoraproject, when/how does this get closed?
libvirt-0.6.2-14.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update libvirt'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-8333
libvirt-0.6.2-14.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.