X-Git-Url: http://git.annexia.org/?p=libguestfs.git;a=blobdiff_plain;f=README;h=bf978ca25bab15786b2b23038ebc2b7e90514dbc;hp=fe3a745c4891ca2950d92aa7063fd5dca09f2c2c;hb=c55bad93fbde03a3daa6058913f02098c45e55f5;hpb=22a50e4e3bb9125c5f2520b812811d4ae2bd7d72 diff --git a/README b/README index fe3a745..bf978ca 100644 --- a/README +++ b/README @@ -1,53 +1,68 @@ -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 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, -LVs, what filesystem is in each LV, etc.). It can also run commands -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 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) and -hacked on by lots of other people. For discussion, development, -patches, etc. please use the mailing list: +Libguestfs is tools and a library for accessing and modifying guest +disk images. For more information see the home page: + + http://libguestfs.org/ + +For discussion, development, patches, etc. please use the mailing +list: http://www.redhat.com/mailman/listinfo/libguestfs -Home page +Requirements ---------------------------------------------------------------------- - http://libguestfs.org/ +Running ./configure will check you have all the requirements installed +on your machine. +Fedora/RHEL users: -Requirements ----------------------------------------------------------------------- + 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: + + 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. + +The full requirements are described below. + +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 -- recent QEMU >= 0.12 with virtio-serial support +- kernel >= 2.6.34 with virtio-serial support enabled. -- febootstrap >= 2.10 +- 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) -- fakeroot +- febootstrap >= 3.3 (it is best to use the latest version) -- fakechroot >= 2.9 + 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) -- pcre (Perl Compatible Regular Expressions C library) (optional) +- cpio + +- gperf + +- pcre (Perl Compatible Regular Expressions C library) + +- genisoimage (NOT mkisofs any more) + +- hivex >= 1.2.7 (http://libguestfs.org/download) (optional) - libmagic (the library that corresponds to the 'file' command) (optional) @@ -55,60 +70,69 @@ Requirements - libxml2 (optional) -- Augeas (http://augeas.net/) (optional) +- libconfig (optional) -- gperf +- augeas >= 0.5.0 (http://augeas.net/) (optional) -- squashfs-tools (mksquashfs only) +- Berkeley DB 'db_dump' and 'db_load' utilities + (db4-utils or db4.X-util or similar) (optional) -- genisoimage / mkisofs +- systemtap/DTrace userspace probes (optional) + http://sourceware.org/systemtap/wiki/AddingUserSpaceProbingToApps -- hivex >= 1.2.1 (http://libguestfs.org/download) +- perldoc (pod2man, pod2text, pod2html) to generate the manual pages + and other documentation. -- (Optional) Berkeley DB 'db_dump' and 'db_load' utilities - (db4-utils or db4.X-util or similar) +- Readline to have nicer command-line editing in guestfish (optional) -- (Optional) FUSE to build the FUSE module +- xmllint (part of libxml2) to validate virt-inspector + RELAX NG schema (optional) -- perldoc (pod2man, pod2text) to generate the manual pages and - other documentation. +- OCaml if you want to rebuild the generated files, and + also to build the OCaml bindings (optional) -- (Optional) Readline to have nicer command-line editing in guestfish. +- po4a for translating manpages and POD files. + This is optional when compiling from the tarball, but mandatory + if you compile from git. -- (Optional) xmllint to validate virt-inspector RELAX NG schema +- getfacl, getfattr libraries and programs (optional) -- (Optional) OCaml if you want to rebuild the generated files, and - also to build the OCaml bindings +To build FUSE support (guestmount): -- (Optional) local Fedora mirror +- FUSE libraries and kernel module (optional) -- (Optional) Perl if you want to build the perl bindings +To build language bindings: -- (Optional) Python if you want to build the python bindings +- Perl if you want to build the perl bindings (optional) -- (Optional) Ruby, rake if you want to build the ruby bindings +- Python if you want to build the python bindings (optional) -- (Optional) Java, JNI, jpackage-utils if you want to build the java -bindings +- Ruby, rake if you want to build the ruby bindings (optional) -- (Optional) GHC if you want to build the Haskell bindings +- Java, JNI, jpackage-utils if you want to build the java + bindings (optional) -- (Optional) Perl Sys::Virt module. +- GHC if you want to build the Haskell bindings (optional) -- (Optional) Perl Win::Hivex module. +- PHP, phpize if you want to build the PHP bindings (optional) -- (Optional) Perl Pod::Usage module. +To build the Perl tools: -- (Optional) Perl Test::More module (from perl Test::Simple). +- Perl Sys::Virt module (optional) -- (Optional, but highly recommended) perl-libintl for translating perl code. +- Perl Win::Hivex module (optional) -- (Optional) po4a for translating manpages and POD files. +- Perl Pod::Usage module (optional) -- (Optional) PHP, phpize if you want to build the PHP bindings +- Perl Test::More module (from perl Test::Simple) (optional) -Running ./configure will check you have all the requirements installed -on your machine. +- Perl String::ShellQuote module (optional) + +- perl-libintl for translating perl code (optional) + +To run virt-sysprep: + +- virt-sysprep requires FUSE support since it uses guestmount Building @@ -116,55 +140,55 @@ Building Then make the daemon, library and root filesystem: - ./configure [--with-mirror=URI] + ./configure make -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 +There are some extra tests, but these require that you have some +libvirt guests installed, that these guests' disks are accessible by +the current user, and these tests may fail for other reasons which are +not necessarily because of real problems. If you want to run these +extra tests do: + + make extra-tests + If everything works, you can install the library and tools by running this command as root: make install +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: -Fedora ----------------------------------------------------------------------- + ./run ./fish/guestfish [usual guestfish args ...] -We provide packages for Fedora >= 11 in Fedora. Use those, or build -from our source RPMs - it's far simpler that way. + ./run ./inspector/virt-inspector [usual virt-inspector args ...] -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. +If you are already in the fish/ subdirectory, then the following +command will also work: + ../run ./guestfish [...] -RHEL / EPEL / CentOS etc ----------------------------------------------------------------------- +You can also make a symlink (note: NOT a hard link) from your $PATH to +the run script, eg: -We provide packages in EPEL which cover RHEL/CentOS >= 5. Use those -or build from our source RPMs. + 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: -Debian ----------------------------------------------------------------------- - -libguestfs is now built as a package in Debian by Guido Gunther and -the other Debian libvirt maintainers. See: + ./run valgrind [valgrind opts...] ./cat/virt-cat [virt-cat opts...] -http://wiki.debian.org/Teams/DebianLibvirtTeam#Packages +This also works with sudo (eg. if you need root access for libvirt or +to access a block device): -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. - -Both ways are supported by the configure script. + sudo ./run ./cat/virt-cat -d LinuxGuest /etc/passwd qemu @@ -202,106 +226,11 @@ 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 +minutes. If it takes much longer for you, use a local distro mirror or squid. To use squid to cache yum downloads, read this first: @@ -325,21 +254,14 @@ 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/ +appliance. You will need to port the febootstrap first +(http://people.redhat.com/~rjones/febootstrap/). Copyright and license information ---------------------------------------------------------------------- -Copyright (C) 2009-2010 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