On 09/14/2011 07:06 AM, Trey Dockendorf wrote: Running libvirtd in a VM makes senses only if you are set up for nested VMs (that is, libvirtd runs in the host, and controls guests of that host; if you run libvirtd within a level 1 VM, then you are controlling level 2 guests). Level 2 nested guests are rare; I've done it before with a xen PV guest running inside a kvm guest, but it is certainly not typical. Generally, you only need to run libvirtd in the bare-metal (level 0) host. Libvirtd does not require the kvm kernel module, but without the kvm kernel module, any qemu guests that you run will not have hardware acceleration, and will appear to run very slowly. Yes, newer clients can always talk to older servers, with the caveat that any function call or flag bits that were added after the older server will gracefully fail instead of doing the functionality that the newer servers can give. http://libvirt.org/hvsupport.html gives a good overview of which APIs will fail (but we don't yet have an automated way to document which releases add support for various flag bits within existing APIs). Libvirt is designed for backwards compatibility - so you get the least common denominator between features that your client knows how to invoke as features your remote server knows how to respond to. Mismatch in libvirt versions is not a problem, as long as you don't use any APIs not present in the oldest version of the two sides. Given your original qeustion, if your management apps really do require 0.8.8 APIs, then you'll need to upgrade libvirtd on your CentOS host to be at least 0.8.8 in order to honor your management app requests, or else modify your management app to gracefully implement fallbacks to older API approaches that were available in 0.8.1. -- Eric Blake eblake(a)redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org