Libvir is a C toolkit to interract with the virtualization capabilities of recent versions of Linux (and other OSes). It is free software available under the GNU Lesser General Public License. Virtualization of the Linux Operating System means the ability to run multiple instances of Operating Systems concurently on a single hardware system where the basic resources are driven by a Linux instance. The library aim at providing long term stable C API primarily for the Xen paravirtualization mechanism but should be able to integrate other virtualization mechanisms if needed.
Here is the list of official releases, however since it is early on in the development of libvir, it is preferable when possible to just use the CVS version or snapshot, contact the mailing list and check the ChangeLog to gauge progresses.
Libvir won't try to provide all possible interfaces for interacting with the virtualization features of a set of Linux (or other OS) system.
To avoid ambiguity about the terms used here here are the definitions for soem of the specific terms used in libvir documentation:
Now we can define the goal of libvir: to provide the lowest possible generic layer to manage domains on a node.
This implies the following:
So libvir should be a building block for higher level management tools or for applications focusing on virtualization on a single node (the only exception being domain migration between node capabilities which may need to be added at the libvir level)
In a Xen environment, programs using libvir have to execute in "Domain 0", which is the primary Linux OS loaded on the machine. That OS kernel provides most if not all of the actual drivers used by the set of domains. It also runs the Xen Store, a database of informations shared by the hypervisor, the kernels, the drivers and the xen daemon. Xend, the xen daemon, also runs in Domain0 and supervise the control and execution of the sets of domains. The hypervisor, drivers, kernels and daemons communicate though a shared system bus implemented in the hypervisor. The figure below tries to provide a view of this environment:
The library can be initialized in 2 ways depending on the level of priviledge of the embedding program. If it runs with root access, virConnectOpen() can be used, it will use three different ways to connect to the Xen infrastructure:
If it runs without root access virConnectOpenReadOnly() should be used,
it will try to open the read-only socket
/var/run/xenstored/socket_ro to connect to the Xen Store and
also try to use the RPC to the Xen daemon. In this case use of hypervisor
calls and write to the Xen Store will not be possible, restraining the amount
of APIs available and slowing down information gathering about domains.
The latest versions of libvir can be found on the libvir.org server ( HTTP, FTP). You will find there the released versions as well as snapshot tarballs updated from CVS head every hour
Anonymous CVS is also available, first register onto the server:
cvs -d :pserver:anoncvs@libvir.org:2401/data/cvs login
it will request a password, enter anoncvs. Then you can checkout the development tree with:
cvs -d :pserver:anoncvs@libvir.org:2401/data/cvs co libvir
Use ./autogen.sh to configure the local checkout, then make
and make install, as usual. All normal cvs commands are now
available except commiting to the base.
Table of Contents:
libvir is released under the GNU Lesser General Public License, see the file COPYING.LIB in the distribution for the precise wording. The only library that libvir depends upon is the Xen store access library which is also licenced under the LGPL.
Yes. The LGPL allows you to embed libvir into a proprietary application. It would be graceful to send-back bug fixes and improvements as patches for possible incorporation in the main development tree. It will decrease your maintainance costs anyway if you do so.
The original distribution comes from ftp://libvir.org/libvir/.
The most generic solution is to re-fetch the latest src.rpm , and rebuild it locally with
rpm --rebuild libvir-xxx.src.rpm.
If everything goes well it will generate two binary rpm packages (one providing the shared libs and virsh, and the other one, the -devel package, providing includes, static libraries and scripts needed to build applications with libvir that you can install locally.
One can also rebuild the RPMs from a tarball:
rpmbuild -ta libdir-xxx.tar.gz
Or from a configured tree with:
make rpm
Large parts of the API are only accessible as root, however the read only access to the xenstore data doesnot have to be forbidden to user, at least for monitoring purposes. If "virsh info" fails to run as an user, change the mode of the xenstore read-only socket with:
chmod 666 /var/run/xenstored/socket_ro
As most UNIX libraries libvir follows the "standard":
gunzip -c libvir-xxx.tar.gz | tar xvf -
cd libvir-xxxx
./configure --help
to see the options, then the compilation/installation proper
./configure [possible options]
make
make install
At that point you may have to rerun ldconfig or a similar utility to update your list of installed shared libs.
Libvir requires libxenstore, which is usually provided by the xen packages as well as the public headers to compile against libxenstore.
The configure script (and other Makefiles) are generated. Use the autogen.sh script to regenerate the configure script and Makefiles, like:
./autogen.sh --prefix=/usr --disable-shared
To simplify the process of reusing the library, libvir comes with pkgconfig support, which can be used directly from autoconf support or via the pkg-config command line tool, like:
pkg-config libvir --libs
There is a mailing-list libvir-list@redhat.com for libvir, with an on-line archive. Please subscribe to this list before posting by visiting the associated Web page and follow the instructions. Patches with explanations and provided as attachments are really appreciated and will be discussed on the mailing list. If possible generate the patches by using cvs diff -u in a CVS checkout.
We expect to use Red Hat Bugzilla to track bugs for libvir, though there isn't yet a libvir software module.