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...
Status: CLOSED NEXTRELEASE
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Veillard
:
Depends On:
Blocks:
  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:
Environment:
Last Closed: 2009-07-30 07:38:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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:
/usr/bin/qemu
/usr/bin/kvm
/usr/bin/qemu-system-x86_64
(interpolate the above with /usr/local/bin)

 -Klaus
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

http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=d2c9fe850b5c158ec7c1f1f9c3c6ab6424239ad5;hp=56a46886ad4335b81daac32c86c77ccbcefa3e23

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