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