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. _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
