Bug 244773 - 'virsh connect qemu:///system' fails, must use env var to communicate with QEMU hypervisor
'virsh connect qemu:///system' fails, must use env var to communicate with QE...
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Veillard
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2007-06-19 00:33 EDT by Nathan Watson
Modified: 2007-12-01 10:32 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-12-01 10:32:03 EST
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 Nathan Watson 2007-06-19 00:33:44 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20070515 Firefox/

Description of problem:
I am trying to use 'virsh' (part of libvirt RPM apparently) to manage
virtual machine instances.  Whenever trying these commands  ...:

  virsh connect localhost
  virsh connect
  virsh connect SHORT_ALIAS_NAME
  virsh connect FULL_IP_ADDRESS

... I always get this error message:

  "virsh: error: failed to connect to the hypervisor"

I compared this behavior with the virt-manager program ...
and that always works.  When virt-manager (started from the
same shell in which I was trying to use 'virsh') runs,
it lists virtual machines, I'm able to start/stop virtual
machines, etc.  I'm assuming 'virt-manager' and 'virsh' use
much of the same underlying infrastructure.  Also, a comparison
of 'lsof | grep libvirt' and 'lsof | grep qemu' before and
after starting 'virt-manager' both imply extra activity
between 'virt-manager' and 'libvirtd' (???) or something
like it, with client-side loading (?) of libvirt*.so and
related, and a new (UNIX domain?) socket connection between
virt-manager and the virtual machine mgmt infrastructure.

More info:

  * I am booting the *.fc7 and not the *.fc7xen kernel
  * I am connecting to the QEMU hypervisor when running
  * documentation for 'virsh' doesn't indicate any different
    procedure when connecting to QEMU vs. Xen hypervisor
    (though I've tried qemu:///server_name instead)
  * I am running virtual machines with KVM (hardware
    acceleration), but I understand QEMU is used to
    create/manage these instances)

I'll be willing to provide more info.

I'm interested in using 'virsh' because it's easier
than mucking around with /etc/libvirt/qemu/* files,
and I'm not sure what implications of doing that are
yet (is stuff cached elsewhere? need to re-start


  * tried shutting down one or both of 'qemu' and
   'libvirtd' services ... virt-manager works only
   when both are runing, 'virsh' doesn't work ever

'root' USER.

ALSO, server was originally named something else before
being renamed and having IP address changed ...
virt-manager worked before and after, and I tried 'virsh'
only after re-booting after IP address/hostname changes.
Maybe something is cached somewhere.

Version-Release number of selected component (if applicable):
libvirt-0.2.3-1.fc7 (possibly libvirt-python-0.2.3-1.fc7)

How reproducible:

Steps to Reproduce:
1. ... already did that above ... sorry

Actual Results:
'virsh'  never connects to hypervisor

Expected Results:
'virsh' should have connected to hypervisor

Additional info:
... willing to provide more info ...
Comment 1 Daniel Veillard 2007-06-19 04:47:38 EDT
There is no supprt yet for remote access.
By defaut libvirt connects to Xen, which you don't have running
To connect to QEmu instances locally use

See http://libvirt.org/remote.html
There is also VIRSH_DEFAULT_CONNECT_URI environemnt variable where you can
set the default connect argument.
This is just a lack of documentation, I guess I would need a "getting started"
section in the libvirt site. But it doesn't look like a defect in the way 
libvirt or virsh works a priori, i.e. unless you come up with more data.

Comment 2 Nathan Watson 2007-06-19 13:06:31 EDT
Changing title from "virsh does not connect to QEMU hypervisor (virt-manager
does)" to "'virsh connect qemu:///system', must use env var to communicate with
QEMU hypervisor".  The following 'bash' session transcript with comments shows
confusing inconsistencies in how QEMU hypervisor is treated.  Re-opening the
bug, perhaps this is just a documentation issue or program feedback guiding the
user on how to use the 'virsh' tool with QEMU.

[root]# # Make sure no env effects
[root]# # Try a 'virsh' command just to make sure
[root]# virsh list
virsh: error: failed to connect to the hypervisor
[root]#    # ok, didn't connect to hypervisor, expected
[root]# #### ---- See
[root]# ####      for my impression of 'virsh connect' syntax:  "virsh connect
<name>" where <name> is hypervisor machine name
[root]# # hmmm ... using QEMU, can't connect to remote system, only localhost
through special "qemu:///system" ...
[root]# # when I read that somewhere I thought perhaps the "system" should be
substituted with the machine name
[root]# # hosting QEMU, but thanks to bugzilla comment I now underestand ... so
I'd suppose THIS would work:
[root]# virsh connect qemu:///system
virsh: error: failed to connect to the hypervisor
[root]# virsh connect 'qemu:///system'
virsh: error: failed to connect to the hypervisor
[root]# virsh list
virsh: error: failed to connect to the hypervisor
[root]#   # still doesn't work
[root]# # So let's try the env var
[root]# export VIRSH_DEFAULT_CONNECT_URI='qemu:///system'
[root]# virsh connect
error: Failed to connect to the hypervisor

[root]# virsh connect asdf.asdf.asdf
libvir: error : no support for hypervisor
error: Failed to connect to the hypervisor

[root]#    # env var doesn't affect 'virsh connect', and doesn't override
attempted hostname (makes sense)
[root]# # ... but how about other 'virsh' commands?
[root]# virsh list
 Id Name                 State
  4 BogatzaWinXpProM02   running
  5 nnXXXXXXXXXX01       running

[root]#    # HEY, IT WORKS NOW ... thanks, a bit confusing but at least works
[root]# # Right now, seems the only way to bake this in QEMU is to (a) ignore
'virsh connect' command,
[root]# # (b) make sure to set the env var, and (c) use the other 'virsh' commands

Comment 3 Nathan Watson 2007-06-19 13:08:03 EDT
I'm glad that I can now use 'virsh', looks like a very useful tool.

The whole virtualization system you all have put together is very nice!
Comment 4 Daniel Berrange 2007-12-01 10:32:03 EST
You are using the wrong syntax to run virsh.

Instead of 

   virsh connect  qemu:///system

You need to use

   virsh --connect  qemu:///system

The former 'connect' command is only relevant in interactive mode, to change the
existing connection. The initial connection attempt uses the '--connect' arg.

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