libvirt Installation

Compiling a release tarball

libvirt uses the standard configure/make/install steps: 

$ xz -c libvirt-x.x.x.tar.xz | tar xvf -
$ cd libvirt-x.x.x
$ ./configure

The configure script can be given options to change its default behaviour.

To get the complete list of the options it can take, pass it the --help option like this: 

$ ./configure --help

When you have determined which options you want to use (if any), continue the process.

Note the use of sudo with the make install command below. Using sudo is only required when installing to a location your user does not have write access to. Installing to a system location is a good example of this.

If you are installing to a location that your user does have write access to, then you can instead run the make install command without putting sudo before it. 

$ ./configure [possible options]
$ make
$ sudo make install

At this point you may have to run ldconfig or a similar utility to update your list of installed shared libs.

Building from a GIT checkout

The libvirt build process uses GNU autotools, so after obtaining a checkout it is necessary to generate the configure script and Makefile.in templates using the autogen.sh command. By default when the configure script is run from within a GIT checkout, it will turn on -Werror for builds. This can be disabled with --disable-werror, but this is not recommended.

Libvirt takes advantage of the gnulib project to provide portability to a number of platforms. This is normally done dynamically via a git submodule in the .gnulib subdirectory, which is auto-updated as needed when you do incremental builds. Setting the environment variable GNULIB_SRCDIR to a local directory containing a git checkout of gnulib will let you reduce local disk space requirements and network download time, regardless of which actual commit you have in that reference directory.

However, if you are developing on a platform where git is not available, or are behind a firewall that does not allow for git to easily obtain the gnulib submodule, it is possible to instead use a static mode of operation where you are then responsible for updating the git submodule yourself. In this mode, you must track the exact gnulib commit needed by libvirt (usually not the latest gnulib.git) via alternative means, such as a shared NFS drive or manual download, and run this any time libvirt.git updates the commit stored in the .gnulib submodule:

$ GNULIB_SRCDIR=/path/to/gnulib ./autogen.sh --no-git

To build & install libvirt to your home directory the following commands can be run: 

$ ./autogen.sh --prefix=$HOME/usr
$ make
$ sudo make install

Be aware though, that binaries built with a custom prefix will not interoperate with OS vendor provided binaries, since the UNIX socket paths will all be different. To produce a build that is compatible with normal OS vendor prefixes, use 

$ ./autogen.sh --system
$ make

When doing this for day-to-day development purposes, it is recommended not to install over the OS vendor provided binaries. Instead simply run libvirt directly from the source tree. For example to run a privileged libvirtd instance 

$ su -
# service libvirtd stop  (or systemctl stop libvirtd.service)
# /home/to/your/checkout/daemon/libvirtd

It is also possible to run virsh directly from the source tree using the ./run script (which sets some environment variables): 

$ ./run ./tools/virsh ....