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