X-Git-Url: http://git.annexia.org/?p=libguestfs.git;a=blobdiff_plain;f=README;h=abf058e7588e2cb99d635d8b574ccb2cf61bedd7;hp=9306b5cce08c584cd28bb8ddd1cbb54462c06144;hb=d43dac69483e8ec62e8356d93f761684ce2f5cc8;hpb=407caabfd04a8bb6338a7fcf4f46d85d75e709df diff --git a/README b/README index 9306b5c..abf058e 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,22 +6,20 @@ 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 FTP. -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 +or Haskell). You can also use it from shell scripts or the command line. -libguestfs was written by Richard W.M. Jones (rjones@redhat.com). +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 @@ -30,66 +28,51 @@ For discussion please use the fedora-virt mailing list: Requirements ---------------------------------------------------------------------- -- nfs-utils source, unpacked - http://download.sourceforge.net/nfs +- recent QEMU >= 0.10 with vmchannel support + http://lists.gnu.org/archive/html/qemu-devel/2009-02/msg01042.html -- Recent QEMU with vmchannel support +- febootstrap >= 1.5 -- Compiled Linux kernels for 32 and/or 64 bit (see note below). - -- mkinitrd +- XDR, rpcgen -- cpio +- (Optional) Augeas (http://augeas.net/) -- XDR, rpcgen +- perldoc (pod2man, pod2text) to generate the manual pages and +other documentation. -- If you are running a 64 bit or non-x86 machine, see note below. +- (Optional) Readline to have nicer command-line editing in guestfish. -We don't support initramfs at the moment. Patches gratefully -received. +- (Optional) OCaml if you want to rebuild the generated files, and +also to build the OCaml bindings -Running ./configure will check you have all the requirements installed -on your machine. +- (Optional) local Fedora mirror +- (Optional) Perl if you want to build the perl bindings -Building ----------------------------------------------------------------------- +- (Optional) Python if you want to build the python bindings -Unpack nfs-utils source into a directory somewhere, then create a -symlink daemon/nfs-utils to where you unpacked it. For example: +- (Optional) Ruby, rake if you want to build the ruby bindings - pushd daemon - tar zxf /path/to/nfs-utils-1.1.4.tar.gz - ln -s nfs-utils-1.1.4 nfs-utils - popd +- (Optional) Java, JNI, jpackage-utils if you want to build the java +bindings -For nfs-utils 1.1.4, you may find that the patch -(nfs-utils-1.1.4-build.patch) helps. +- (Optional) GHC if you want to build the Haskell bindings -Then make the library and shell tools: +Running ./configure will check you have all the requirements installed +on your machine. - ./configure - make -Make the daemon and NFS server: - mkdir daemon/build - pushd daemon/build - ../configure [--disable-nfsv4 --disable-gss] - make - popd +Building +---------------------------------------------------------------------- -For 64 bit you'll probably want to build the 32 bit daemon and NFS -server too: +Then make the daemon, library and root filesystem: - mkdir daemon/build-32 - pushd daemon/build-32 - ../configure --enable-32bit [--disable-nfsv4 --disable-gss] + ./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: @@ -100,69 +83,62 @@ these commands as root: make install - pushd daemon/build - make install - popd - # Repeat for each daemon/build* directory you made above. - -Note on 64 bit and non-x86 architectures +Note on using KVM ---------------------------------------------------------------------- -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). +If you are using x86-64, then 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. -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 ...? +You may also need to enable KVM support for non-root users, by following +these instructions: -Several factors influence the choice: + http://www.linux-kvm.org/page/FAQ#How_can_I_use_kvm_with_a_non-privileged_user.3F -(a) The host architecture. +On some systems, this will work too: -(b) The guest architecture. + chmod o+rw /dev/kvm -(c) What kernel(s) we find at runtime. +On some systems, the chmod will not survive a reboot, and you will +need to make edits to the udev configuration. -(d) What compiler(s) we find at configure time. -(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. +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 FTP export will work fine, but running commands in +guests may not be possible. -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. +To enable this requires work for cross-architecture and 32-on-64 +support in febootstrap, fakeroot and fakechroot. -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). +The daemon/ directory contains its own configure script. This is so +that in future we will be able to cross-compile the daemon. -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. +Having a local Fedora mirror makes a massive difference to the time it +takes to build and rebuild initramfs images. -If you have a really weird environment, eg. you want to run programs -inside PPC64 guests on your MIPS machine, then: +Failing that, use squid to cache yum downloads, but 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 +IntelligentMirror is another possibility, although I couldn't get it +to work for me. Copyright and license information