Bug 486734 - libvirt says "unable to connect to qemu:///system" if /usr/bin/qemu is a dead link
libvirt says "unable to connect to qemu:///system" if /usr/bin/qemu is a dead...
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Veillard
Depends On:
  Show dependency treegraph
Reported: 2009-02-21 10:36 EST by zaba
Modified: 2010-03-16 13:17 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-30 07:38:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description zaba 2009-02-21 10:36:23 EST
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.
Comment 1 Richard W.M. Jones 2009-02-21 10:44:46 EST
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
Comment 2 Richard W.M. Jones 2009-02-21 10:56:25 EST
<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
Comment 3 Daniel Berrange 2009-02-23 05:39:41 EST
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
Comment 4 Richard W.M. Jones 2009-02-24 06:31:03 EST
Updating summary to more accurately describe the bug (see comment 3).
Comment 5 Klaus Heinrich Kiwi 2009-03-11 14:51:43 EDT
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)

Comment 6 Daniel Berrange 2009-07-30 07:38:55 EDT
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


Note You need to log in before you can comment on or make changes to this bug.