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

[Whit Blauvelt]

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:
> On 08/19/2012 12:19 PM, Whit Blauvelt wrote:
> > Hi,
> > 
> > Did something dumb - had two VM hosts with DRBD mirroring of VMs on the same
> > UPS, which failed and crashed them both. While I've got VMs running now on
> > both, "virsh list" and "virsh start" and so on are just hanging. I'm not
> > seeing it log anything in these instances - just hanging.