On Fri, May 22, 2009 at 12:24:40PM -0600, Erkan Unal wrote: NUMA is completely optional - you merely loose ability to query the NUMA topology which is not critical. 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 That's bad ! Run 'valgrind virsh -c qemu:///session' to get a report of where it is crashing 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 #!/bin/sh exec libtool --mode=execute "$@" So I can then just do ltrun gdb ./src/virsh Daniel -- |: 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 :|