Bug 486734

Summary: libvirt says "unable to connect to qemu:///system" if /usr/bin/qemu is a dead link
Product: [Community] Virtualization Tools Reporter: zaba
Component: libvirtAssignee: Daniel Veillard <veillard>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: low    
Version: unspecifiedCC: berrange, crobinso, klaus, rjones, xen-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-07-30 11:38:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description zaba 2009-02-21 15:36:23 UTC 
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 15:44:46 UTC 
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 15:56:25 UTC 
<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 Berrangé 2009-02-23 10:39:41 UTC 
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 11:31:03 UTC 
Updating summary to more accurately describe the bug (see comment 3).
Comment 5 Klaus Kiwi (Old account no longer used) 2009-03-11 18:51:43 UTC 
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 Berrangé 2009-07-30 11:38:55 UTC 
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