mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-12-25 01:34:11 +03:00
cfdc0c771a
The most important part is LIBVIRTD_PATH env var fix. It is used in virFileFindResourceFull() from tests. The libvirtd no longer lives under daemon/. Then, libvirtd-fail test was still failing (as expected) but not because of missing config file but because it was trying to execute (nonexistent) top_builddir/daemon/libvirtd which fulfilled expected outcome and thus test did not fail. Thirdly, lcov was told to generate coverage for daemon/ dir too. Fourthly, our compiling documentation was still suggesting to run daemonn/libvirtd. And finally, some comments in a systemtap file and a probes file were still referring to daemon/libvirtd. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
141 lines
4.5 KiB
XML
141 lines
4.5 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE html>
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<body>
|
|
<h1><a id="installation">libvirt Installation</a></h1>
|
|
|
|
<ul id="toc"></ul>
|
|
|
|
<h2><a id="compiling">Compiling a release tarball</a></h2>
|
|
|
|
<p>
|
|
libvirt uses the standard configure/make/install steps:
|
|
</p>
|
|
|
|
<pre>
|
|
$ xz -c libvirt-x.x.x.tar.xz | tar xvf -
|
|
$ cd libvirt-x.x.x
|
|
$ ./configure</pre>
|
|
|
|
<p>
|
|
The <i>configure</i> script can be given options to change its default
|
|
behaviour.
|
|
</p>
|
|
|
|
<p>
|
|
To get the complete list of the options it can take, pass it the
|
|
<i>--help</i> option like this:
|
|
</p>
|
|
|
|
<pre>
|
|
$ ./configure <i>--help</i></pre>
|
|
|
|
<p>
|
|
When you have determined which options you want to use (if any),
|
|
continue the process.
|
|
</p>
|
|
|
|
<p>
|
|
Note the use of <b>sudo</b> with the <i>make install</i> 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.
|
|
</p>
|
|
|
|
<p>
|
|
If you are installing to a location that your user <i>does</i> have write
|
|
access to, then you can instead run the <i>make install</i> command
|
|
without putting <b>sudo</b> before it.
|
|
</p>
|
|
|
|
<pre>
|
|
$ ./configure <i>[possible options]</i>
|
|
$ make
|
|
$ <b>sudo</b> <i>make install</i></pre>
|
|
|
|
<p>
|
|
At this point you <b>may</b> have to run ldconfig or a similar utility
|
|
to update your list of installed shared libs.
|
|
</p>
|
|
|
|
<h2><a id="building">Building from a GIT checkout</a></h2>
|
|
|
|
<p>
|
|
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 <code>autogen.sh</code> command. By default when
|
|
the <code>configure</code> 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.
|
|
</p>
|
|
<p>
|
|
Libvirt takes advantage of
|
|
the <a href="http://www.gnu.org/software/gnulib/">gnulib</a>
|
|
project to provide portability to a number of platforms. This
|
|
is normally done dynamically via a git submodule in
|
|
the <code>.gnulib</code> subdirectory, which is auto-updated as
|
|
needed when you do incremental builds. Setting the environment
|
|
variable <code>GNULIB_SRCDIR</code> 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.
|
|
</p>
|
|
<p>
|
|
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:</p>
|
|
<pre>
|
|
$ GNULIB_SRCDIR=/path/to/gnulib ./autogen.sh --no-git
|
|
</pre>
|
|
|
|
<p>To build & install libvirt to your home
|
|
directory the following commands can be run:
|
|
</p>
|
|
|
|
<pre>
|
|
$ ./autogen.sh --prefix=$HOME/usr
|
|
$ make
|
|
$ <b>sudo</b> make install</pre>
|
|
|
|
<p>
|
|
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
|
|
</p>
|
|
|
|
<pre>
|
|
$ ./autogen.sh --system
|
|
$ make
|
|
</pre>
|
|
|
|
<p>
|
|
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
|
|
</p>
|
|
|
|
<pre>
|
|
$ su -
|
|
# service libvirtd stop (or systemctl stop libvirtd.service)
|
|
# /home/to/your/checkout/src/libvirtd
|
|
</pre>
|
|
|
|
<p>
|
|
It is also possible to run virsh directly from the source tree
|
|
using the ./run script (which sets some environment variables):
|
|
</p>
|
|
|
|
<pre>
|
|
$ ./run ./tools/virsh ....
|
|
</pre>
|
|
</body>
|
|
</html>
|