This is still work in progress! Feel free to jump in and extend this documentation!

Basic info

Ubuntu uses [http://kvm.qumranet.com/ kvm] as the backend virtualisation technology. To manage VM's we use [http://libvirt.org/ libvirt] as the basic toolbox and [http://virt-manager.et.redhat.com/ virt-manager] as the graphical frontend for managing your vm's.

Why virtualise?

Virtualisation is being adopted in many different environments and situations. If you're a developer, virtualisation can provide you with a contained environment where you can safely do almost any sort of development safe from messing up your main working environment. If you're a systems administrator, you can use virtualisation to more easily separate your services and move them around based on the demand they're seeing.

How to get started

How to check if your cpu supports hardware virtualization

Run the following command:

egrep '(vmx|svm)' /proc/cpuinfo

If nothing is printed, it means that your cpu doesn't support hardware virtualization. Otherwise, it does - but you still need to make sure that virtualization is enabled in the BIOS.

Installing packages

You need to install a few packages first:

$ sudo apt-get install virt-manager kvm libvirt-bin

• virt-manager is the gui.
• libvirt-bin provides libvirtd which you need to administer qemu and kvm instances using libvirt
• kvm is the backend

Next, you want to add yourself to the libvirt group. If your username is joe, you run:

$ sudo adduser joe libvirtd

This will give you access to the system-wide libvirtd instance. This is preferable for you because it gives you access to the advanced networking options rather than simply the "userspace networking" option as you may know it from QEmu.

Note: You need to log out and log back in for the new group membership to take effect.

libvirt will create a new vnet0 network interface. To stop this confusing network-manager, add this stanza to the end of /etc/network/interfaces:

iface vnet0 inet manual

Once that's done, you can test if it worked by issuing the following command:

$ virsh -c qemu:///system list
 Id Name                 State
----------------------------------

$

If on the other hand you get something like this:

$ virsh -c qemu:///system list
libvir: Remote error : Permission denied
error: failed to connect to the hypervisor
$

Something is wrong and you probably want to fix this before you move on. The critical point here is whether or not you have write access to /var/run/libvirt/libvirt-sock.

Ok, now that that's sorted, you can fire up virt-manager. The first time we do this, we pass it the exact libvirt URI we want to connect to. Subsequently, virt-manager will remember this URI and present it in its UI, so you should only really need this the first time.

$ virt-manager -c qemu:///system

attachment:virtmanager-initial.png

You can now set up your first VM! Click the line that says "localhost" and then click the "New" button.

Virt-manager will ask you a few questions about your new VM.

• First, you give it a name.
• Next, you choose which type of virtualisation you want to use. You want to choose "Fully virtualised" and either "x86_64" or "i686" as the CPU architecture, and finally enable "Enable kernel / hardware acceleration". That last checkbox decides whether you're invoking qemu or kvm.
• Next, you choose the location of your ISO image that will be used during installation.
• Next, you choose your storage details. The simplest approach is to use the "Simple file" option. You enter the location of the image, and set a size. If you've got loads of space, you'll get an increase in performance if you enable "Allocate entire virtual disk now?", but deselecting that is also fine.
• Next, your choose your network settings. "Usermode network" is almost never what you want. "Virtual network" is usually the best default. It connects your vm to a virtual network that libvirt has set up. It resides at 192.168.122.0/24 and there's a router at 192.168.122.1. You'll notice your host also has a virbr0 interface (which will be brought up when the first guest vm using it is fired up) connected to the same virtual network.
• Finally, you choose your memory settings and decide on the number of CPU's the guest should see.
• All you need to do now, is acknowledge these settings and you're done.

Note: There seems to be an issue right now with showing the gfxboot screen. You will not be able to see the menu, but you can just press Return and the installation will continue. https://bugs.edge.launchpad.net/ubuntu/+source/kvm/+bug/183727

Remote management

If for instance you have libvirtd running on several machines, you can even manage them from your workstation. Instead of connecting to qemu:///system, you can:

$ virt-manager -c qemu+ssh://virtnode1.mydomain.com/system

This assumes that you've already set up ssh connectivity between your system and virtnode1.mydomain.com. This is out of scope for this page.

Somewhere down the line, we'll support live migration of virtual machines between nodes.

Troubleshooting

• Q: I'm on Intel hardware, and I'm trying to boot Dapper, Edgy, Feisty, or Gutsy, but kvm fails immediately.
• A: Yes, this is rather unfortunate. The issue is a limitation in Intel's virtualisation extensions that don't interact very well with gfxboot. The evil, hacky workaround is to modify the ISO to disable gfxboot. The following has worked for me, but it might kill your cat or make your coffee go cold or make other unpleasantries happen to you. You've been warned!

$ sed -e 's/GFXBOOT bootlogo/#FXBOOT bootlogo/g' < ubuntu-7.10-server-amd64.iso > ubuntu-7.10-server-amd64-nogfxboot.iso

Don't change the above command! The lenght of the string mustn't change or you will have knackered the filesystem on the CD.

A slightly safer way is to download gfxboot-disable from [http://hg.codemonkey.ws/gfxboot-disable] and then run:

$ gfxboot-disable ubuntu-7.10-server-amd64.iso

Creating an image using the command-line

$ qemu-img create ubuntu-server.img -f qcow2 6G

Converting VMware machines to virt-manager

kvm has the ability to use VMware's vmdk disk files directly, as long as the disk is wholly contained in the vmdk (ie VMware allows splitting a disk into smaller, usually 2GB, vmdk files. kvm can't use these). Point kvm at the vmdk with the appropriate options (see  man kvm-qemu ), and it should work.

To use the VMware machine from within virt-manager, the .vmx file must be converted to libvirt's .xml. vmware2libvirt was created to help with this, and it can be used like so:

$ vmware2libvirt -f ./file.vmx > file.xml
$ virsh -c qemu:///system define file.xml

The first command converts the VMware 'file.vmx' file to the libvirt compatible 'file.xml'. See  man vmware2libvirt  for details. Note: until vmware2libvirt is shipped with the libvirt packages, you can download it from [http://people.ubuntu.ccom/~soren/]. The second command imports file.xml into libvirt. The imported .xml files are stored in /etc/libvirt/qemu.

IMPORTANT: keep in mind that while the .vmx file is converted to .xml, the disks are used as is, therefore it is important to make backups, especially if you want to use the virtual machine in vmware later.

Caveats

While vmware2libvirt works well on simple virtual machines, there are limitations because .vmx file don't always contain enough information, and also because vmware2libvirt tries not to make too many assumptions about what it finds. A couple of things to look out for:

1. While vmware2libvirt attempts to detect a 64-bit guest, be sure that your 64-bit guest has in its .xml file:

   <os>
    <type arch='x86_64' machine='pc'>hvm</type>
    ...
   </os>

2. vmware2libvirt currently only detects and uses the first ethernet interface found. Additional interfaces can be added from within virt-manager.
3. vmware2libvirt currently will use the first scsi disk if found, otherwise the first ide disk. Additional disks can be added from within virt-manager.

4. vmware2libvirt hard codes the virtual machine to 1 cpu. This can be changed with:

     <vcpu>2</vcpu>

5. vmware2libvirt does not (and cannot) convert anything that was VMware-specific within the guest. See 'Guest Notes' below for more details.

Guest notes

1. Be sure to remove vmware-tools if you have it installed (otherwise it will overwrite xorg.conf on reboot)
2. Guests should not use ntp to synchronize the clock, so be sure to remove/disable ntpd

3. Linux guests with Xorg should be using the 'vmmouse' driver (not available on Ubuntu Dapper). To use, perform within the guest:

   aptitude install xserver-xorg-input-vmmouse

   then adjust /etc/X11/xorg.conf to have (the Identifier line should not change, and you should have only an Identifier line and Driver line for the mouse):

   Section "InputDevice"
           Identifier      "Configured Mouse"
           Driver          "vmmouse"
   EndSection

4. Linux guests with Xorg need to adjust the resolution for Xorg in /etc/X11/xorg.conf. Look for the Screen section, and make sure each of the 'Modes' lines has a reasonable resolution for your system (due to [https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/193456 bug #193456] the resolution in the guest's resolution needs to be smaller than the host). Eg:

   Section "Screen"
           ...
           SubSection "Display"
                   Depth           16
                   Modes           "800x600" "640x480"
           EndSubSection
           SubSection "Display"
                   Depth           24
                   Modes           "800x600" "640x480"
           EndSubSection
   EndSection

5. Windows virtual machines should substitute in the .xml file:

     <features>
       <acpi/>
     </features>

   with:

     <features/>