X-Git-Url: http://git.annexia.org/?p=libguestfs.git;a=blobdiff_plain;f=README;h=e231840dfb846b216a08dfe3d18ddef44ad28b35;hp=6c9d5ab7905ea746ddf822a6ffa59f26869a6e43;hb=61da709722ec244da1c3c7d4f1a8706f76687cb3;hpb=28d760b1542da7ff83b18c4ca60c2d03f327c2f4;ds=sidebyside diff --git a/README b/README index 6c9d5ab..e231840 100644 --- a/README +++ b/README @@ -1,4 +1,4 @@ -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: @@ -6,169 +6,331 @@ virt-p2v), performing partial backups, performing partial guest 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.9 -- 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) -- If you are running a 64 bit or non-x86 machine, see note below. +- libmagic (the library that corresponds to the 'file' command) -We don't support initramfs at the moment. Patches gratefully -received. +- libvirt -Running ./configure will check you have all the requirements installed -on your machine. +- libxml2 +- Augeas (http://augeas.net/) -Building ----------------------------------------------------------------------- +- squashfs-tools (mksquashfs only) -Unpack nfs-utils source into a directory somewhere, then create a -symlink daemon/nfs-utils to where you unpacked it. For example: +- genisoimage / mkisofs - pushd daemon - tar zxf /path/to/nfs-utils-1.1.4.tar.gz - ln -s nfs-utils-1.1.4 nfs-utils - popd +- hivex >= 1.2.1 (http://libguestfs.org/download) -For nfs-utils 1.1.4, you may find that the patch -(nfs-utils-1.1.4-build.patch) helps. +- (Optional) FUSE to build the FUSE module -Then make the library and shell tools: +- perldoc (pod2man, pod2text) to generate the manual pages and + other documentation. - ./configure - make +- (Optional) Readline to have nicer command-line editing in guestfish. -Make the daemon and NFS server: - mkdir daemon/build - pushd daemon/build - ../configure - make - popd +- (Optional) xmllint to validate virt-inspector RELAX NG schema + +- (Optional) OCaml + OCaml library xml-light if you want to rebuild + the generated files, and also to build the OCaml bindings + (http://tech.motion-twin.com/xmllight.html) -For 64 bit you'll probably want to build the 32 bit daemon and NFS -server too: +- (Optional) local Fedora mirror - mkdir daemon/build-32 - pushd daemon/build-32 - ../configure --enable-32bit +- (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. + +- (Optional) PHP, phpize if you want to build the PHP bindings + +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. -Note on 64 bit and non-x86 architectures +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. + + +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