Build environment set up for libguestfs.

1 files changed, 175 insertions, 0 deletions

diff --git a/README b/README
new file mode 100644
index 00000000..6c9d5ab7
--- /dev/null
+++ b/README
@@ -0,0 +1,175 @@
+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 mount guest filesystems on
+the host (requires root privs and NFS).
+
+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
+
+
+Requirements
+----------------------------------------------------------------------
+
+- nfs-utils source, unpacked
+  http://download.sourceforge.net/nfs
+
+- Recent QEMU with vmchannel support
+
+- Compiled Linux kernels for 32 and/or 64 bit (see note below).
+
+- mkinitrd
+
+- cpio
+
+- XDR, rpcgen
+
+- If you are running a 64 bit or non-x86 machine, see note below.
+
+We don't support initramfs at the moment.  Patches gratefully
+received.
+
+Running ./configure will check you have all the requirements installed
+on your machine.
+
+
+Building
+----------------------------------------------------------------------
+
+Unpack nfs-utils source into a directory somewhere, then create a
+symlink daemon/nfs-utils to where you unpacked it.  For example:
+
+  pushd daemon
+  tar zxf /path/to/nfs-utils-1.1.4.tar.gz
+  ln -s nfs-utils-1.1.4 nfs-utils
+  popd
+
+For nfs-utils 1.1.4, you may find that the patch
+(nfs-utils-1.1.4-build.patch) helps.
+
+Then make the library and shell tools:
+
+  ./configure
+  make
+
+Make the daemon and NFS server:
+  mkdir daemon/build
+  pushd daemon/build
+  ../configure
+  make
+  popd
+
+For 64 bit you'll probably want to build the 32 bit daemon and NFS
+server too:
+
+  mkdir daemon/build-32
+  pushd daemon/build-32
+  ../configure --enable-32bit
+  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.
+
+Finally run the tests:
+
+  make check
+
+If everything works, you can install the library and tools by running
+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
+----------------------------------------------------------------------
+
+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).
+
+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 ...?
+
+Several factors influence the choice:
+
+(a) The host architecture.
+
+(b) The guest architecture.
+
+(c) What kernel(s) we find at runtime.
+
+(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.
+
+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.
+
+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:
+
+(1) Ensure that "gcc -m32" can create usable binaries.
+
+(2) Provide 32 and 64 bit kernels binaries at runtime.
+
+If you have a really weird environment, eg. you want to run programs
+inside PPC64 guests on your MIPS machine, then:
+
+(3) Provide gcc cross-compiler and glibc for each architecture, and
+cross-compile the daemon and NFS server:
+
+  mkdir daemon/build-ppc64
+  pushd daemon/build-ppc64
+  ../configure --host=ppc64-gnu-linux
+  make
+  popd
+
+
+Copyright and license information
+----------------------------------------------------------------------
+
+Copyright (C) 2009 Red Hat Inc.
+
+The library is distributed under the LGPLv2+.  The programs are
+distributed under the GPLv2+.  Please see the files COPYING and
+COPYING.LIB for full license information.