www.nico.schottelius.org/docs/linux-virtual-machines.mdwn

[[!meta title="Linux Virtual Machine Overview"]]

This document is ***WORK IN PROGRESS***

## Introduction

This article tries to summarise Linux Virtual Machine
methods and is in its early stage. It does not focus
on different types of hypervisors, but more on the
issues and features you get with each hypervisor.

### Host Kernel

Some supervisors need their own (modified Linux) kernel
to operate, whereas others work with any Linux kernel.
Though some of them again need some configurations
to be turned on in the stock kernel.

### VM Installation

Depending on the hypervisor, there are different requirements
and methods for the installation:

 * Installation can be done within the VM for completly isolated machines
 * Installation must be done outside / on the host for systems without own kernel

Some hypervisors can boot from the network, whereas others just
create a very lightweight isolation and boot an installed system
only.

### Guest OS changes

Some hypervisors require changes to the virtual machines, to be able
to run successfully. Others allow a original OS version to be
installed.

### Network configuration

Whether the VM is attached to a bridge, a tun/tap device, treated
as a normal process, there may be a lot of different configurations.
Furthermore, firewall (masquerade/nat) configurations may be necessary.

Additionally, some of the hypervisors support dynamic allocation
of mac or even ip addresses.


### Templates

Some hypervisors support reusage of installations.

### Management

Most hypervisors contain some minor collection of utilities
to manage virtual machines. Some libraries / frameworks
try to integrate those utilities, to abstract the different
implementations.

Typical issues are:

 * Autostart machines on startup / autostop on shutdown
 * Creation of new VMs / including template handling
 * Manual start/stop of VMs
 * Listing of running / existing VMs

### Automated usage

Especially interesting for a sysadmin is, how easy a system can
be automated, which steps need to be taken to get a new image
or copy of an existing one. This aspect is one focus of this
document.

## Hypervisors

[[!table  data="""
Name | Host Kernel | Guest OS changes
[QEMU](http://wiki.qemu.org/) | Original | no
[KVM](http://www.linux-kvm.org/) | Original w/KVM | no
[Lguest](http://lguest.ozlabs.org/) | Original w/Lguest | ?
[Linux Containers](http://lxc.sourceforge.net/) | Original w/Containers | yes
[Linux VServer](http://linux-vserver.org) | Own | ?
[User Mode Linux](http://user-mode-linux.sourceforge.net/) | Original | ?
[OpenVZ](http://wiki.openvz.org/Main_Page) | Own | ?
[Virtualbox](http://www.virtualbox.org/) | Original+Modules | no
[VMWare](http://www.vmware.com/) | Original+Modules / Own | no
[Xen](http://www.xen.org/) | Own | ?
"""]]

### lxc

Some hints on lxc:

 * Helper scripts existent (lxc-debian, lxc-fedora, ...)
 * adjust init. change dev. do not run udev (why?)
 * Root open in the filesystem
 * No network specified = all from host accessible!

## Libraries / Frameworks

[[!table  data="""
Name | Hints
Ganetti |
Libvirt |
"""]]

[[!tag net unix]]