Description of problem: Using libvirt 0.6.0, libvirtd says it is unable to connect to qemu:///system upon trying to do something simple, such as virsh -c qemu:///system list --all. The UNIX socket files are created and listened on by it, though. From the logs: 18:17:27.135: debug : virConnectOpen:1032 : name=qemu:///system 18:17:27.135: debug : do_open:902 : name "qemu:///system" to URI components: scheme qemu opaque (null) authority (null) server (null) user (null) port 0 path /system 18:17:27.135: debug : do_open:912 : trying driver 0 (Test) ... 18:17:27.135: debug : do_open:918 : driver 0 Test returned DECLINED 18:17:27.135: debug : do_open:912 : trying driver 1 (remote) ... 18:17:27.135: debug : do_open:918 : driver 1 remote returned DECLINED 18:17:27.135: debug : do_open:912 : trying driver 2 (QEMU) ... 18:17:27.135: debug : do_open:918 : driver 2 QEMU returned DECLINED 18:17:27.135: error : could not connect to qemu:///system libvir: error : could not connect to qemu:///system Version-Release number of selected component (if applicable): libvirt 0.6.0. How reproducible: Occurs everytime I try to connect to libvirtd.
I spent a bit of time with the reporter on IRC trying to find out what was going on, even running libvirtd with debugging, but I couldn't even see an error message. Our debugging support sucks ... Anyway, I need to know (from the reporter): - where libvirt obtained/installed from - what you're running (not Fedora) - QEMU and KVM version, and names of the installed binaries for these
<Zaba> rjones, it appears, /usr/bin/qemu was a dead symlink. <Zaba> making it point to a right path fixes it.. <rjones> we need better debugging for that sort of thing
This is a flaw in the logic for the QEMU driver open method. It should not be returning 'DECLINED' when the user gives an explicit 'qemu:///system' URI. It should return an explicit error, in this case saying that not QEMU binary was found. It should only return 'DECLINED' when doing the auto-probing of drivers for a 'NULL' URI
Updating summary to more accurately describe the bug (see comment 3).
Given the number of names/places QEMU might assume in the host system, wouldn't be appropriate to have it as a configurable option? I've seen Qemu at least as: /usr/bin/qemu /usr/bin/kvm /usr/bin/qemu-system-x86_64 (interpolate the above with /usr/local/bin) -Klaus
As of the following commit, libvirt will *never* decline a valid URL. It will always accept it, or provide a real error message. The remote driver is also fixed to report better errors. This will all be in the forthcoming 0.7.0 release http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=d2c9fe850b5c158ec7c1f1f9c3c6ab6424239ad5;hp=56a46886ad4335b81daac32c86c77ccbcefa3e23