Re: [libvirt-users] Finding cause when "virsh list" hangs

Eric, Thanks for taking the time to respond. Your explanation about the stuck queue makes sense. The system with the more recent libvirt, I realized on closer inspection, was still using the original kvm. Once I switched the kvm symlink to /usr/local/bin/qemu-system-x86_64 and restarted libvirtd it became happy. I'd just made the dumb assumption that the default builds of both, letting them go in their default /usr/local locations, would work together automatically, what with /usr/local/bin being first in the path. Not too hard a thing to adjust. But I wonder if in most cases where libvirt is being installed from source the object is to use it with a packaged version of kvm-qemu, or with a kvm-qemu also installed from source. If the latter, would it make more sense for it to invoke /usr/local/bin/qemu-system-x86_64 as its default rather than /usr/bin/kvm? Or would the trick - providing that libvirt isn't specifying the full path but just invoking "kvm" - be for the kvm-qemu source build to by default put a kvm symlink in /usr/local/bin, for libvirt to find it first, before the /usr/bin version? Quibbles, I know. But with this area evolving so fast, the distros often fall behind. Having source install be easy can be a good thing. Best, Whit On Tue, Aug 21, 2012 at 03:59:12PM -0600, Eric Blake wrote: