+ 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/
git.annexia.org / libguestfs.git / blobdiff