-libguestfs is a library for accessing and modifying guest disk images.
+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:
clones, cloning guests and changing registry/UUID/hostname info, and
much else besides.
-libguestfs uses Linux kernel and qemu code, and can access any type of
+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.
-libguestfs provides ways to enumerate guest storage (eg. partitions,
+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).
+in the context of the guest. Also you can access filesystems over
+FUSE.
-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 is a library that can be linked with C and C++ management
+programs (or management programs written in OCaml, Perl, Python, Ruby,
+Java, PHP, Haskell or C#). 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:
+Libguestfs was written by Richard W.M. Jones (rjones@redhat.com) and
+hacked on by lots of other people. For discussion, development,
+patches, etc. please use the mailing list:
- https://www.redhat.com/mailman/listinfo/fedora-virt
+ http://www.redhat.com/mailman/listinfo/libguestfs
+
+
+Home page
+----------------------------------------------------------------------
+
+ http://libguestfs.org/
Requirements
----------------------------------------------------------------------
-- nfs-utils source, unpacked
- http://download.sourceforge.net/nfs
+- recent QEMU >= 0.12 with virtio-serial support
-- Recent QEMU with vmchannel support
+- febootstrap >= 2.10
-- Compiled Linux kernels for 32 and/or 64 bit (see note below).
+- fakeroot
-- mkinitrd
+- fakechroot >= 2.9
-- cpio
+- XDR, rpcgen (on Linux these are provided by glibc)
-- XDR, rpcgen
+- pcre (Perl Compatible Regular Expressions C library) (optional)
-- If you are running a 64 bit or non-x86 machine, see note below.
+- libmagic (the library that corresponds to the 'file' command) (optional)
-We don't support initramfs at the moment. Patches gratefully
-received.
+- libvirt (optional)
-Running ./configure will check you have all the requirements installed
-on your machine.
+- libxml2 (optional)
+- Augeas (http://augeas.net/) (optional)
-Building
-----------------------------------------------------------------------
+- gperf
-Unpack nfs-utils source into a directory somewhere, then create a
-symlink daemon/nfs-utils to where you unpacked it. For example:
+- squashfs-tools (mksquashfs only)
- pushd daemon
- tar zxf /path/to/nfs-utils-1.1.4.tar.gz
- ln -s nfs-utils-1.1.4 nfs-utils
- popd
+- genisoimage / mkisofs
-For nfs-utils 1.1.4, you may find that the patch
-(nfs-utils-1.1.4-build.patch) helps.
+- hivex >= 1.2.1 (http://libguestfs.org/download)
-Then make the library and shell tools:
+- (Optional) FUSE to build the FUSE module
- ./configure
- make
+- perldoc (pod2man, pod2text) 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
+- (Optional) Readline to have nicer command-line editing in guestfish.
+
+- (Optional) xmllint to validate virt-inspector RELAX NG schema
+
+- (Optional) OCaml if you want to rebuild the generated files, and
+ also to build the OCaml bindings
+
+- (Optional) local Fedora mirror
+
+- (Optional) 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) GHC if you want to build the Haskell bindings
+
+- (Optional) Perl XML::XPath, Sys::Virt modules (for libvirt support
+in virt-inspector).
+
+- (Optional, but highly recommended) perl-libintl for translating perl code.
+
+- (Optional) po4a for translating manpages and POD files.
-For 64 bit you'll probably want to build the 32 bit daemon and NFS
-server too:
+- (Optional) PHP, phpize if you want to build the PHP bindings
- mkdir daemon/build-32
- pushd daemon/build-32
- ../configure --enable-32bit [--disable-nfsv4 --disable-gss]
+Running ./configure will check you have all the requirements installed
+on your machine.
+
+
+Building
+----------------------------------------------------------------------
+
+Then make the daemon, library and root filesystem:
+
+ ./configure [--with-mirror=URI]
make
- popd
-For complex cross-architecture environments, you may want to build
-other versions of the daemon and NFS server as well. See the note
-below.
+Use the optional --with-mirror parameter to specify the URI of a local
+Fedora mirror. See the discussion of the MIRROR parameter in the
+febootstrap(8) manpage.
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.
+
+Fedora
+----------------------------------------------------------------------
+
+We provide packages for Fedora >= 11 in Fedora. Use those, or build
+from our source RPMs - it's far simpler that way.
+
+You can compile libguestfs on Fedora 10 but you cannot use it with the
+version of qemu in Fedora 10. You need to compile your own qemu, see
+section 'qemu' below.
+
+
+RHEL / EPEL / CentOS etc
+----------------------------------------------------------------------
+
+We provide packages in EPEL which cover RHEL/CentOS >= 5. Use those
+or build from our source RPMs.
-Note on 64 bit and non-x86 architectures
+Debian
----------------------------------------------------------------------
-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).
+libguestfs is now built as a package in Debian by Guido Gunther and
+the other Debian libvirt maintainers. See:
-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 ...?
+http://wiki.debian.org/Teams/DebianLibvirtTeam#Packages
-Several factors influence the choice:
+You can build for Debian in two different ways, either building a
+Fedora-based appliance using febootstrap, yum, rpm, fakeroot,
+fakechroot (all packaged in Debian). However the recommended way is
+to build a Debian-based appliance using debootstrap and debirf.
-(a) The host architecture.
+Both ways are supported by the configure script.
-(b) The guest architecture.
-(c) What kernel(s) we find at runtime.
+qemu
+----------------------------------------------------------------------
-(d) What compiler(s) we find at configure time.
+By far the most common problem is with broken or incompatible
+qemu releases.
-(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.
+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.
-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.
+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.
-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).
-SO: to enable maximum features on 64 bit architectures:
+Note on using KVM
+----------------------------------------------------------------------
-(1) Ensure that "gcc -m32" can create usable binaries.
+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.
-(2) Provide 32 and 64 bit kernels binaries at runtime.
+You may also need to enable KVM support for non-root users, by following
+these instructions:
-If you have a really weird environment, eg. you want to run programs
-inside PPC64 guests on your MIPS machine, then:
+ http://www.linux-kvm.org/page/FAQ#How_can_I_use_kvm_with_a_non-privileged_user.3F
-(3) Provide gcc cross-compiler and glibc for each architecture, and
-cross-compile the daemon and NFS server:
+On some systems, this will work too:
- mkdir daemon/build-ppc64
- pushd daemon/build-ppc64
- ../configure --host=ppc64-gnu-linux
- make
- popd
+ chmod o+rw /dev/kvm
+
+On some systems, the chmod will not survive a reboot, and you will
+need to make edits to the udev configuration.
+
+
+vmchannel
+----------------------------------------------------------------------
+
+Previous versions of libguestfs required something called "vmchannel".
+Vmchannel is a special device given to virtual machines which allows
+them to communicate in some way with the host, often (but not always)
+without using a traditional network device. In reality, there is no
+one thing called "vmchannel". This idea has been reimplemented
+several times under the name vmchannel, and other hypervisors have
+their own incompatible implementation(s) too.
+
+In libguestfs <= 1.0.71, we required a specific vmchannel which is
+properly known as "guestfwd" and has been upstream in qemu since here:
+
+ http://lists.gnu.org/archive/html/qemu-devel/2009-02/msg01042.html
+
+In libguestfs >= 1.0.71 we don't require any vmchannel implementation,
+as long as qemu has been compiled with support for SLIRP (user mode
+networking, or "-net user"), which is almost always the case.
+
+In libguestfs >= 1.5.4 we switched again to using qemu's virtio-serial
+and removed all the other vmchannels and the SLIRP channel.
+
+
+Supermin appliance
+----------------------------------------------------------------------
+
+If you configure with --enable-supermin then we will build a supermin
+appliance (supermin = super-minimized). This is a very specialized
+appliance which is built on-the-fly at runtime (specifically, when you
+call guestfs_launch).
+
+The normal appliance is a self-contained Linux operating system, based
+on the Fedora/RHEL/CentOS Linux distro. So it contains a complete
+copy of all the libraries and programs needed, like kernel, libc,
+bash, coreutils etc etc.
+
+The supermin appliance removes the kernel and all the executable
+libraries and programs from the appliance. That just leaves a
+skeleton of config files and some data files, which is obviously
+massively smaller than the normal appliance. At runtime we rebuild
+the appliance on-the-fly from the libraries and programs on the host
+(eg. pulling in the real /lib/libc.so, the real /bin/bash etc.)
+
+Although this process of rebuilding the appliance each time sounds
+slow, it turns out to be faster than using the prebuilt appliance.
+(Most of the saving comes from not compressing the appliance - it
+transpires that decompressing the appliance is the slowest part of the
+whole boot sequence). On my machine, a new appliance can be built in
+under a fifth of a second, and the boot time is several seconds
+shorter.
+
+The big advantage of the supermin appliance for distributions like
+Fedora is that it gets security fixes automatically from the host, so
+there is no need to rebuild the whole of libguestfs for a security
+update in some underlying library.
+
+There are several DISADVANTAGES:
+
+It won't work at all except in very narrow, controlled cases like the
+Fedora packaging case. We control the dependencies of the libguestfs
+RPM tightly to ensure that the required binaries are actually present
+on the host.
+
+Furthermore there are certain unlikely changes in the packages on the
+host which could break a supermin appliance, eg. an updated library
+which depends on an additional data file.
+
+Also supermin appliances are subjected to changes in the host kernel
+which might break compatibility with qemu -- these are, of course,
+real bugs in any case.
+
+Lastly, supermin appliances really can't be moved between branches of
+distributions (eg. built on Fedora 12 and moved to Fedora 10) because
+they are not self-contained and they rely on certain libraries being
+around. You shouldn't do this anyway.
+
+Use supermin appliances with caution.
+
+
+Notes on cross-architecture support
+----------------------------------------------------------------------
+
+At the moment we basically don't support cross-architecture or
+32-on-64. This limits what is possible for some guests. Filesystem
+operations and FUSE will work fine, but running commands in guests may
+not be possible.
+
+To enable this requires work for cross-architecture and 32-on-64
+support in febootstrap, fakeroot and fakechroot.
+
+The daemon/ directory contains its own configure script. This is so
+that in future we will be able to cross-compile the daemon.
+
+
+Mirroring tip
+----------------------------------------------------------------------
+
+On my machines I can usually rebuild the appliance in around 3
+minutes. If it takes much longer for you, use a local Fedora mirror
+or squid.
+
+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).
+
+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
+
+
+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 find or port the following packages
+first:
+
+ - fakeroot
+ - fakechroot
+ - python
+ - rpm-python http://www.rpm.org/
+ - yum http://yum.baseurl.org/
+ - febootstrap http://people.redhat.com/~rjones/febootstrap/
Copyright and license information
----------------------------------------------------------------------
-Copyright (C) 2009 Red Hat Inc.
+Copyright (C) 2009-2010 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