Architecture

Libvirt is a C toolkit to interact with the virtualization capabilities of recent versions of Linux (and other OSes), but libvirt won't try to provide all possible interfaces for interacting with the virtualization features.

To avoid ambiguity about the terms used here here are the definitions for some of the specific concepts used in libvirt documentation:

• a node is a single physical machine
• an hypervisor is a layer of software allowing to virtualize a node in a set of virtual machines with possibly different configurations than the node itself
• a domain is an instance of an operating system running on a virtualized machine provided by the hypervisor

Now we can define the goal of libvirt: to provide the lowest possible generic and stable layer to manage domains on a node.

This implies the following:

• the API should not be targeted to a single virtualization environment though Xen is the current default, which also means that some very specific capabilities which are not generic enough may not be provided as libvirt APIs
• the API should allow to do efficiently and cleanly all the operations needed to manage domains on a node
• the API will not try to provide high level multi-nodes management features like load balancing, though they could be implemented on top of libvirt
• stability of the API is a big concern, libvirt should isolate applications from the frequent changes expected at the lower level of the virtualization framework

So libvirt should be a building block for higher level management tools and for applications focusing on virtualization of a single node (the only exception being domain migration between node capabilities which may need to be added at the libvirt level). Where possible libvirt should be extendable to be able to provide the same API for remote nodes, however this is not the case at the moment, the code currently handle only local node accesses (extension for remote access support is being worked on, see the mailing list discussions about it).