-libguestfs is a library for accessing and modifying guest disk images.
-Amongst the things this is good for: making batch configuration
-changes to guests, getting disk used/free statistics (see also:
-virt-df), migrating between virtualization systems (see also:
-virt-p2v), performing partial backups, performing partial guest
-clones, cloning guests and changing registry/UUID/hostname info, and
-much else besides.
+Libguestfs is tools and a library for accessing and modifying guest
+disk images. For more information see the home page:
-libguestfs uses Linux kernel and qemu code, and can access any type of
-guest filesystem that Linux and qemu can, including but not limited
-to: ext2/3/4, btrfs, FAT and NTFS, LVM, many different disk partition
-schemes, qcow, qcow2, vmdk.
+ http://libguestfs.org/
-libguestfs provides ways to enumerate guest storage (eg. partitions,
-LVs, what filesystem is in each LV, etc.). It can also run commands
-in the context of the guest. Also you can mount guest filesystems on
-the host (requires root privs and NFS).
+For discussion, development, patches, etc. please use the mailing
+list:
-libguestfs is a library that can be linked with C and C++ management
-programs (or management programs written in other languages, if people
-contribute the language bindings). You can also use it from shell
-scripts or the command line.
-
-libguestfs was written by Richard W.M. Jones (rjones@redhat.com).
-For discussion please use the fedora-virt mailing list:
-
- https://www.redhat.com/mailman/listinfo/fedora-virt
+ http://www.redhat.com/mailman/listinfo/libguestfs
Requirements
----------------------------------------------------------------------
-- nfs-utils source, unpacked
- http://download.sourceforge.net/nfs
+Running ./configure will check you have all the requirements installed
+on your machine.
+
+Fedora/RHEL users:
+
+ A useful tip is to run:
+
+ yum-builddep libguestfs
+
+ which will install all build dependencies automatically. If that is
+ successful, you don't need to bother with the rest of this section.
+
+Debian/Ubuntu users:
-- Recent QEMU with vmchannel support
+ Take a look at the debian/control file and install everything listed
+ in "Build-Depends". If that is successful, you don't need to bother
+ with the rest of this section.
-- Compiled Linux kernels for 32 and/or 64 bit (see note below).
+The full requirements are described below.
-- mkinitrd
+For basic functionality and the C tools:
+
+- look at appliance/packagelist.in and install as many of the packages
+ that apply to your distro as possible
+
+- recent QEMU >= 0.13 (0.14 or later is better) with virtio-serial support
+
+- kernel >= 2.6.34 with virtio-serial support enabled.
+
+- virtio-block and virtio-net drivers should be compiled into your
+ host kernel (strictly speaking this is optional, but you will have
+ to make complex changes to the ./configure command line to get it
+ to work if you don't have virtio)
+
+- febootstrap >= 3.3 (it is best to use the latest version)
+
+ Notes: (1) febootstrap 2.x WILL NOT WORK
+ (2) febootstrap 3.x is distro-independent, and is required on
+ Debian and other distros as well as Fedora
+
+- XDR, rpcgen (on Linux these are provided by glibc)
- cpio
-- XDR, rpcgen
+- gperf
-- If you are running a 64 bit or non-x86 machine, see note below.
+- pcre (Perl Compatible Regular Expressions C library)
-We don't support initramfs at the moment. Patches gratefully
-received.
+- genisoimage (NOT mkisofs any more)
-Running ./configure will check you have all the requirements installed
-on your machine.
+- hivex >= 1.2.7 (http://libguestfs.org/download) (optional)
+- libmagic (the library that corresponds to the 'file' command) (optional)
-Building
-----------------------------------------------------------------------
+- libvirt (optional)
-Unpack nfs-utils source into a directory somewhere, then create a
-symlink daemon/nfs-utils to where you unpacked it. For example:
+- libxml2 (optional)
- pushd daemon
- tar zxf /path/to/nfs-utils-1.1.4.tar.gz
- ln -s nfs-utils-1.1.4 nfs-utils
- popd
+- libconfig (optional)
-For nfs-utils 1.1.4, you may find that the patch
-(nfs-utils-1.1.4-build.patch) helps.
+- augeas >= 0.5.0 (http://augeas.net/) (optional)
-Then make the library and shell tools:
+- Berkeley DB 'db_dump' and 'db_load' utilities
+ (db4-utils or db4.X-util or similar) (optional)
- ./configure
- make
+- perldoc (pod2man, pod2text, pod2html) to generate the manual pages
+ and other documentation.
-Make the daemon and NFS server:
- mkdir daemon/build
- pushd daemon/build
- ../configure [--disable-nfsv4 --disable-gss]
- make
- popd
+- Readline to have nicer command-line editing in guestfish (optional)
-For 64 bit you'll probably want to build the 32 bit daemon and NFS
-server too:
+- xmllint (part of libxml2) to validate virt-inspector
+ RELAX NG schema (optional)
- mkdir daemon/build-32
- pushd daemon/build-32
- ../configure --enable-32bit [--disable-nfsv4 --disable-gss]
- make
- popd
+- OCaml if you want to rebuild the generated files, and
+ also to build the OCaml bindings (optional)
+
+- po4a for translating manpages and POD files.
+ This is optional when compiling from the tarball, but mandatory
+ if you compile from git.
+
+- getfacl, getfattr libraries and programs (optional)
+
+To build FUSE support (guestmount):
+
+- FUSE libraries and kernel module (optional)
+
+To build virt-resize:
+
+- OCaml PCRE bindings (ocaml-pcre) (optional)
+
+To build language bindings:
+
+- Perl if you want to build the perl bindings (optional)
+
+- Python if you want to build the python bindings (optional)
+
+- Ruby, rake if you want to build the ruby bindings (optional)
+
+- Java, JNI, jpackage-utils if you want to build the java
+ bindings (optional)
-For complex cross-architecture environments, you may want to build
-other versions of the daemon and NFS server as well. See the note
-below.
+- GHC if you want to build the Haskell bindings (optional)
+
+- PHP, phpize if you want to build the PHP bindings (optional)
+
+To build the Perl tools:
+
+- Perl Sys::Virt module (optional)
+
+- Perl Win::Hivex module (optional)
+
+- Perl Pod::Usage module (optional)
+
+- Perl Test::More module (from perl Test::Simple) (optional)
+
+- Perl String::ShellQuote module (optional)
+
+- perl-libintl for translating perl code (optional)
+
+
+Building
+----------------------------------------------------------------------
+
+Then make the daemon, library and root filesystem:
+
+ ./configure
+ make
Finally run the tests:
make check
If everything works, you can install the library and tools by running
-these commands as root:
+this command as root:
make install
- pushd daemon/build
- make install
- popd
- # Repeat for each daemon/build* directory you made above.
+You can run guestfish, guestmount and the virt tools without needing
+to install, using the "run" script in the top directory. This script
+sets up some environment variables. For example:
+
+ ./run ./fish/guestfish [usual guestfish args ...]
+ ./run ./inspector/virt-inspector [usual virt-inspector args ...]
-Note on 64 bit and non-x86 architectures
+If you are already in the fish/ subdirectory, then the following
+command will also work:
+
+ ../run ./guestfish [...]
+
+You can also make a symlink (note: NOT a hard link) from your $PATH to
+the run script, eg:
+
+ cd ~/bin
+ ln -s ~/libguestfs/run libguestfs-run
+ cd ~/libguestfs
+ libguestfs-run ./inspector/virt-inspector [...]
+
+You can also run the C programs under valgrind like this:
+
+ ./run valgrind [valgrind opts...] ./cat/virt-cat [virt-cat opts...]
+
+This also works with sudo (eg. if you need root access for libvirt or
+to access a block device):
+
+ sudo ./run ./cat/virt-cat -d LinuxGuest /etc/passwd
+
+
+qemu
----------------------------------------------------------------------
-The library runs the Linux kernel code in QEMU. It also runs a small
-control daemon inside QEMU. It might also run an NFS server. It
-might also run programs from the guest's disk/environment (if asked to).
+By far the most common problem is with broken or incompatible
+qemu releases.
-This leaves open the question of which QEMU do we run, eg. qemu (the
-i386 emulator) or qemu-system-x86_64 or qemu-system-ppc64 or ...?
+Different versions of qemu have problems booting the appliance for
+different reasons. This varies between versions of qemu, and Linux
+distributions which add their own patches.
-Several factors influence the choice:
+If you find a problem, you could try using your own qemu built from
+source (qemu is very easy to build from source), with a 'qemu
+wrapper'. Qemu wrappers are described in the guestfs(3) manpage.
-(a) The host architecture.
-(b) The guest architecture.
+Note on using KVM
+----------------------------------------------------------------------
+
+By default the configure script will look for qemu-kvm (KVM support).
+You will need a reasonably recent processor for this to work. KVM is
+much faster than using plain Qemu.
-(c) What kernel(s) we find at runtime.
+You may also need to enable KVM support for non-root users, by following
+these instructions:
-(d) What compiler(s) we find at configure time.
+ http://www.linux-kvm.org/page/FAQ#How_can_I_use_kvm_with_a_non-privileged_user.3F
-(e) In general, we would prefer to run a 32 bit kernel over a 64 bit
-kernel, because that reduces the amount of system memory we have to
-give to qemu significantly, and makes libguestfs smaller, faster and
-use less memory.
+On some systems, this will work too:
-For example, if (a) the host is x86-64, then it might be running a
-mixture of (b) i386 and x86-64 guests. Disk formats are stable, even
-across 32 and 64 bit and endianness changes, so it doesn't really
-matter what kernel we use if we just want to access files in the
-guest. In the absence of any other factors, we would choose an i386
-kernel and run it in plain 'qemu', because that would use the least
-amount of memory.
+ chmod o+rw /dev/kvm
-But if we wanted to enable the feature of running a guest program in
-an x86-64 guest, then we have to run an x86-64 kernel and
-qemu-system-x86_64 (an i386 kernel can't run 64 bit programs). The
-same applies if we didn't find a 32 bit kernel at runtime, or if we
-couldn't run "gcc -m32" at configure time (because we can't compile
-the daemon).
+On some systems, the chmod will not survive a reboot, and you will
+need to make edits to the udev configuration.
-SO: to enable maximum features on 64 bit architectures:
-(1) Ensure that "gcc -m32" can create usable binaries.
+Mirroring tip
+----------------------------------------------------------------------
-(2) Provide 32 and 64 bit kernels binaries at runtime.
+On my machines I can usually rebuild the appliance in around 3
+minutes. If it takes much longer for you, use a local distro mirror
+or squid.
-If you have a really weird environment, eg. you want to run programs
-inside PPC64 guests on your MIPS machine, then:
+To use squid to cache yum downloads, read this first:
+https://lists.dulug.duke.edu/pipermail/yum/2006-August/009041.html
+(In brief, because yum chooses random mirrors each time, squid doesn't
+work very well with default yum configuration. To get around this,
+choose a Fedora mirror which is close to you, set this with
+'./configure --with-mirror=[...]', and then proxy the whole lot
+through squid by setting http_proxy environment variable).
-(3) Provide gcc cross-compiler and glibc for each architecture, and
-cross-compile the daemon and NFS server:
+You will also need to substantially increase the squid configuration
+limits:
+http://fedoraproject.org/wiki/Using_Mock_to_test_package_builds#Using_Squid_to_Speed_Up_Mock_package_downloads
- mkdir daemon/build-ppc64
- pushd daemon/build-ppc64
- ../configure --host=ppc64-gnu-linux
- make
- popd
+
+Porting to other Linux distros / non-Linux
+----------------------------------------------------------------------
+
+libguestfs itself should be fairly portable to other Linux
+distributions. Non-Linux ports are trickier, but we will accept
+patches if they aren't too invasive.
+
+The main porting issues are with the dependencies needed to build the
+appliance. You will need to port the febootstrap first
+(http://people.redhat.com/~rjones/febootstrap/).
Copyright and license information
----------------------------------------------------------------------
-Copyright (C) 2009 Red Hat Inc.
+Copyright (C) 2009-2011 Red Hat Inc.
The library is distributed under the LGPLv2+. The programs are
distributed under the GPLv2+. Please see the files COPYING and
git.annexia.org / libguestfs.git / blobdiff