[libvirt-users] Libvirt daemon usage question

[Eric Blake]

On 09/14/2011 07:06 AM, Trey Dockendorf wrote:
> I could use some help with clarification on the use of the libvirtd daemon
> with regards to managing remote KVM instances.  Right now I have a CentOS 6
> KVM server (libvirt-0.8.1), but would like to use some management
> applications that require higher version (0.8.8).  First, is it possible to
> run the libvirtd daemon from within a VM, or does it require active kvm
> kernel module?

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.

>  Secondly, could a daemon running in say Fedora 15 (0.8.8) be
> used to communicate with my CentOS 6 daemon (0.8.1).

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).

>  Does this sort of
> model present a problem if the KVM host is not using the same or close to
> the same version as the remote libvirtd?

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 at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org