[libvirt] error: failed to connect to the hypervisor

Daniel P. Berrange berrange at redhat.com
Sun May 24 13:06:37 UTC 2009

On Fri, May 22, 2009 at 12:24:40PM -0600, Erkan Unal wrote:
> Hi,
> I installed the libvirt with the following  configure options as an 
> unprivileged user,  I  am planning to use it just for qemu/kvm:
> ./configure --without-xen --without-lxc --without-uml --without-openvz 
> --without-vbox --without-numactl --prefix=/some/nonstandard/dir
> make
> make install
> --without-numactl is added because of a compilation error. I am not sure 
> whether it is completely necessary or not. If you think it has effect on 
> the error, please state the reason.

NUMA is completely optional - you merely loose ability to query the NUMA
topology which is not critical.

> After installation I got the following error when I tried to run the 
> virsh without any  options:
> error: failed to connect to the hypervisor

Check that the libvirtd daemon is running. Also, since you have built
with a --prefix=XXX arg, make sure you are running the daemon you just
built, rather than the one that might have been installed by your OS
distro in /usr. The --prefix arg alters where the UNIX domain socket 
is  located - for most distro builds, it'll be in /var/run/libvirt, but
with your build it'll be expected in $PREFIX/var/run/libvirt. So you
must use matching libvirtd and client builds.

Another debugging tip is to set 'LIBVIRT_DEBUG=1' when running virsh,
and also you can set the same for the libvirtd daemon

> With the following command line error was "Segmentation Fault":
> virsh -c qemu:///session.

That's bad !  Run 'valgrind virsh -c qemu:///session' to get a report
of where it is crashing

> P.S.: Is there a way to compile static virsh executable?  I tried 
> altering make files, configure options, linker flags and compiler flags 
> but no luck. "ldd virsh" command should say "not a dynamic executable" 
> after compilation.

configure  --disable-shared.

I'd recommend against that though. The reason 'ldd virsh' gives you
that output is not because it is shared, it is because I think you're
running it on the source tree src/virsh  file, which is actually a
libtool shell wrapper script. The real binaries are in src/.lib/
until you run 'make install'

If you want to debug these intermediate libtool wrappers, then you can
run then using via libtool, eg to run virsh under GDB

   libtool --mode=execute gdb ./src/virsh

Or to run valgrind

   libtool --mode=execute valgrind ./src/virsh

Personally I create a little simpler script

  $ cat ~/bin/ltrun
  exec libtool --mode=execute "$@"

So I can then just do

  ltrun gdb ./src/virsh

|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

More information about the libvir-list mailing list