Description of problem: Xen PV domU's have no PCI bus (at least as seen on Rackspace's Cloud Servers). libvirt's src/node_device/node_device_udev.c calls pci_system_init which looks for /sys/bus/pci. If it does not find /sys/bus/pci (which it won't in a Xen PV domU) it returns unsuccesfully, which libvirt considers fatal. It's perfectly reasonable to want to run libvirt in a paravirt Xen domU, e.g. for running LXC, QEmu or UML guests. Additionally, the PCI check is disabled on s390, and a failing check is ignored for qemu:///session, so I don't see how it can be absolutely required for qemu:///system on non-s390. Version-Release number of selected component (if applicable): Observed in 0.8.8 and onwards. Perhaps it appeared earlier. How reproducible: 100% Steps to Reproduce: 1. Fire up a Xen PV domU (e.g. on Rackspace Cloud Servers) 2. Attempt to start libvirtd as root. 3. Fail. Actual results: It fails, saying something like: libpciaccess: No such file or directory. Expected results: It should start, and whatever functionality depends on pci access should simply be disabled. Since s390 gets away with this, it should be feasible. Additional info:
Fix is now upstream, and will be part of libvirt 0.9.5: commit 9c7283166f667967d9d435ba233178f07af2eee0 Author: Soren Hansen <soren> Date: Mon Sep 5 21:29:06 2011 +0200 Don't treat pci_system_init failure as fatal if no PCI bus is present Xen PV domU's have no PCI bus. node_device_udev.c calls pci_system_init won't in a Xen PV domU) it returns unsuccesfully (ENOENT), which libvirt considers fatal. This makes libvirt unusable in this environment, even though there are plenty of valid virtualisation options that work there (LXC, UML, and QEmu spring to mind)