kernel-fxtec-pro1x/Documentation/lguest/lguest.txt

129 lines
4.4 KiB
Text
Raw Normal View History

__
(___()'`; Rusty's Remarkably Unreliable Guide to Lguest
/, /` - or, A Young Coder's Illustrated Hypervisor
\\"--\\ http://lguest.ozlabs.org
Lguest is designed to be a minimal 32-bit x86 hypervisor for the Linux kernel,
for Linux developers and users to experiment with virtualization with the
minimum of complexity. Nonetheless, it should have sufficient features to
make it useful for specific tasks, and, of course, you are encouraged to fork
and enhance it (see drivers/lguest/README).
Features:
- Kernel module which runs in a normal kernel.
- Simple I/O model for communication.
- Simple program to create new guests.
- Logo contains cute puppies: http://lguest.ozlabs.org
Developer features:
- Fun to hack on.
- No ABI: being tied to a specific kernel anyway, you can change anything.
- Many opportunities for improvement or feature implementation.
Running Lguest:
- The easiest way to run lguest is to use same kernel as guest and host.
You can configure them differently, but usually it's easiest not to.
You will need to configure your kernel with the following options:
"General setup":
"Prompt for development and/or incomplete code/drivers" = Y
(CONFIG_EXPERIMENTAL=y)
"Processor type and features":
"Paravirtualized guest support" = Y
"Lguest guest support" = Y
"High Memory Support" = off/4GB
"Alignment value to which kernel should be aligned" = 0x100000
(CONFIG_PARAVIRT=y, CONFIG_LGUEST_GUEST=y, CONFIG_HIGHMEM64G=n and
CONFIG_PHYSICAL_ALIGN=0x100000)
"Device Drivers":
"Block devices"
"Virtio block driver (EXPERIMENTAL)" = M/Y
"Network device support"
"Universal TUN/TAP device driver support" = M/Y
"Virtio network driver (EXPERIMENTAL)" = M/Y
(CONFIG_VIRTIO_BLK=m, CONFIG_VIRTIO_NET=m and CONFIG_TUN=m)
"Virtualization"
"Linux hypervisor example code" = M/Y
(CONFIG_LGUEST=m)
- A tool called "lguest" is available in this directory: type "make"
to build it. If you didn't build your kernel in-tree, use "make
O=<builddir>".
- Create or find a root disk image. There are several useful ones
around, such as the xm-test tiny root image at
http://xm-test.xensource.com/ramdisks/initrd-1.1-i386.img
For more serious work, I usually use a distribution ISO image and
install it under qemu, then make multiple copies:
dd if=/dev/zero of=rootfile bs=1M count=2048
qemu -cdrom image.iso -hda rootfile -net user -net nic -boot d
Make sure that you install a getty on /dev/hvc0 if you want to log in on the
console!
- "modprobe lg" if you built it as a module.
- Run an lguest as root:
Documentation/lguest/lguest 64 vmlinux --tunnet=192.168.19.1 --block=rootfile root=/dev/vda
Explanation:
64: the amount of memory to use, in MB.
vmlinux: the kernel image found in the top of your build directory. You
can also use a standard bzImage.
--tunnet=192.168.19.1: configures a "tap" device for networking with this
IP address.
--block=rootfile: a file or block device which becomes /dev/vda
inside the guest.
root=/dev/vda: this (and anything else on the command line) are
kernel boot parameters.
- Configuring networking. I usually have the host masquerade, using
"iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE" and "echo 1 >
/proc/sys/net/ipv4/ip_forward". In this example, I would configure
eth0 inside the guest at 192.168.19.2.
Another method is to bridge the tap device to an external interface
using --tunnet=bridge:<bridgename>, and perhaps run dhcp on the guest
to obtain an IP address. The bridge needs to be configured first:
this option simply adds the tap interface to it.
A simple example on my system:
ifconfig eth0 0.0.0.0
brctl addbr lg0
ifconfig lg0 up
brctl addif lg0 eth0
dhclient lg0
Then use --tunnet=bridge:lg0 when launching the guest.
Docs/Kconfig: Update: osdl.org -> linuxfoundation.org Some of the documentation refers to web pages under the domain `osdl.org'. However, `osdl.org' now redirects to `linuxfoundation.org'. Rather than rely on redirections, this patch updates the addresses appropriately; for the most part, only documentation that is meant to be current has been updated. The patch should be pretty quick to scan and check; each new web-page url was gotten by trying out the original URL in a browser and then simply copying the the redirected URL (formatting as necessary). There is some conflict as to which one of these domain names is preferred: linuxfoundation.org linux-foundation.org So, I wrote: info@linuxfoundation.org and got this reply: Message-ID: <4CE17EE6.9040807@linuxfoundation.org> Date: Mon, 15 Nov 2010 10:41:42 -0800 From: David Ames <david@linuxfoundation.org> ... linuxfoundation.org is preferred. The canonical name for our web site is www.linuxfoundation.org. Our list site is actually lists.linux-foundation.org. Regarding email linuxfoundation.org is preferred there are a few people who choose to use linux-foundation.org for their own reasons. Consequently, I used `linuxfoundation.org' for web pages and `lists.linux-foundation.org' for mailing-list web pages and email addresses; the only personal email address I updated from `@osdl.org' was that of Andrew Morton, who prefers `linux-foundation.org' according `git log'. Signed-off-by: Michael Witten <mfwitten@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2010-11-15 12:55:34 -07:00
See:
http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge
for general information on how to get bridging to work.
- Random number generation. Using the --rng option will provide a
/dev/hwrng in the guest that will read from the host's /dev/random.
Use this option in conjunction with rng-tools (see ../hw_random.txt)
to provide entropy to the guest kernel's /dev/random.
There is a helpful mailing list at http://ozlabs.org/mailman/listinfo/lguest
Good luck!
Rusty Russell rusty@rustcorp.com.au.