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.