Red Hat Bugzilla – Bug 486734
libvirt says "unable to connect to qemu:///system" if /usr/bin/qemu is a dead link
Last modified: 2010-03-16 13:17:57 EDT
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:
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):
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
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:
(interpolate the above with /usr/local/bin)
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