Red Hat Bugzilla – Full Text Bug Listing
|Summary:||libvirtd segfaults with redirected pci device not found|
|Product:||[Fedora] Fedora||Reporter:||Liam Dennehy <liam>|
|Component:||libvirt||Assignee:||Daniel Veillard <veillard>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||10||CC:||berrange, clalance, crobinso, itamar, veillard, virt-maint|
|Fixed In Version:||0.6.2-14.fc11||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-08-15 04:30:16 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Liam Dennehy 2009-07-12 07:49:28 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): libvirt-0.6.1-1.fc10 How reproducible: Always 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" Actual results: "Failed to open file '/sys/bus/pci/devices/0000:01:08.0/vendor': No such file or directory Segmentation fault" libvirtd no longer running "libvirtd" command returns: "error : Failed to open pid file '/var/run/libvirtd.pid' : File exists" Expected results: 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 Additional info: 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.
Comment 1 Liam Dennehy 2009-07-12 07:52:21 EDT
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.
Comment 2 Daniel Berrange 2009-08-04 11:06:27 EDT
Fixed upstream in ommit 4a7acedd3c59a6a750576cb8680bc3f08fe0b52c 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
Comment 3 Daniel Berrange 2009-08-05 12:08:21 EDT
Built fix into libvirt-0.6.2-14.fc11
Comment 4 Fedora Update System 2009-08-05 12:12:44 EDT
libvirt-0.6.2-14.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/libvirt-0.6.2-14.fc11
Comment 5 Liam Dennehy 2009-08-06 11:57:26 EDT
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? Thanks again
Comment 6 Daniel Berrange 2009-08-06 12:04:24 EDT
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.
Comment 7 Liam Dennehy 2009-08-06 12:12:24 EDT
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?
Comment 8 Fedora Update System 2009-08-07 01:00:26 EDT
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
Comment 9 Fedora Update System 2009-08-15 04:29:45 EDT
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.