How to setup a KVM on Ubuntu

KVM (Kernel Virtual Machine) is a brilliant visualization software.  Over the last few years, I have installed quite a few hosts and have been keeping notes – so I thought that I would put them up on this blog.

Install Packages
Firstly, you need to install the basic Ubuntu packages.  I use ubuntu-vm-builder which automates most of the tasks.  The command to install everything you need is:

sudo apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils

Out of interest, KVM doesn’t have it’s own configuration directory. You’ll find the configuration files in:

/etc/libvirt/qemu/

Add Networking Bridge Adaptor
To give your virtual machines access to the network and you need to create a bridge on the host server.  You have already installed bridge-utils – so you just need to edit the network configuration in /etc/network/interfaces file.  If you make a mistake here and restart the networking the server will loose it’s network connection and you will have to use servers virtual console or actually terminal on the server – if it worth double checking everything.  Here is the configuration that I use:

auto br0
iface br0 inet static
address *.*.*.*
netmask *.*.*.*
network *.*.*.*
broadcast *.*.*.*
gateway *.*.*.*
dns-nameservers *.*.*.* *.*.*.*
bridge_ports eth0
bridge_fd 9
bridge_hello 2
bridge_maxage 12
bridge_maxwait 0

If you have installed a firewall on the host server (I always use UFW because it’s so easy to use) then you will need to relax the firewall to allow connections for the bridge adaptor.  To do this add the following line to /etc/ufw/before.rules, before COMMIT:

# allow bridge networking
-I FORWARD -m physdev –physdev-is-bridged -j ACCEPT

Installing a New Virtual Machine
To install a new VM you need to use vmbuilder. There are many, many, many options to vmbuilder. To view them all type vmbuilder –help.  The command I use to create the vm’s is shown below.  Obviously adjust everything to suit.

vmbuilder kvm ubuntu -v
–suite=precise
–libvirt=qemu:///system
–arch=amd64 –cpus=1 –mem=1024 –swapsize=4096 –rootsize=204800
–flavour=virtual
–hostname=hostname.co.uk
–ip=*.*.*.*
–mask=*.*.*.*
–net=*.*.*.*
–bcast=*.*.*.*
–gw=*.*.*.*
–dns=’8.8.8.8 8.8.4.4′
–bridge=br0
–mirror=http://archive.ubuntu.com/ubuntu –components=’main,universe’
–addpkg=openssh-server
–addpkg=acpid
–addpkg=acpi-support
–addpkg=linux-image-generic
–user=user
–pass=password
–dest=/somefolder/

Your guest will be built.  This will take some time as the host server has to connect to the Internet and download Ubuntu and install from there.  Once it is complete, if you selected to install the openssh-server package you can SSH into the guest and continue your set up from there.

Starting and Stopping the Guest
After installation you will need to start the VM.  To start and stop the guest you need to use Virsh (which you have already installed).  You can start the Virsh console by typing virsh. Alternatively you can type commands after virsh at the bash shell and it will execute the commands and return to the shell.

To see the list of currently running guests:

virsh list

To start your guest type:

virsh start hostname

To stop a guest it is recommended to connect (via SSH or other) to the guest and use the guest OS’ shutdown command. If that is not possible you can try send the machine an ACPI shutdown command using:

virsh shutdown hostname

In order for Ubuntu VM’s to respond to ACPI shutdown request they need to have acpid and acpi-support packages installed.  If you followed the instructions above when creating the VM, this will have already been installed.   However, you can install them on the VM by running:

sudo apt-get install acpid acpi-support

If the guest doesn’t have ACPI enabled or doesn’t want to respond you can forcefully shutdown the machine by using the destroy command.  This has to be the most worryingly named command – but don’t worry it only forcefully stops the VM.  You run it by issuing:

virsh destroy hostname

If the guest hostname is not recognised, stop and restart the libvirt-bin service using:

sudo service libvirt-bin stop
sudo service libvirt-bin start

For reasons unknown it is not sufficient to simply restart the service, it has to be stopped and started. Fortunately the running VMs do not shutdown when stopping the libvirt-bin service.

 

Reasons to love virtual machines and avoiding 3rd party cloud hosting.

In the last few years we’ve been migrating all our servers over to KVM virtual machines running on a Ubuntu servers.  I’ve come to love VM’s.  There seems to be compelling reasons for using them.

  1. You can install a new VM very quickly without having to setup new hardware.
  2. You can control the resources for each VM really easily – scaling memory and cpu.  So it you can use resources more effectively.
  3. You can backup an VM server really easily.
  4. However, the best longterm reason is that you can move the VM’s really easily. For example, if you move to a new server hosting company, you just stop the VM instance, copy it to the new server host and restart it again.  Brilliant.  Even if you’re renting a dedicated server and are only going to use all it’s resources for one server, I highly recommend setting up the dedicated server as a host and running vm on top.  This single VM can use all the cpu and memory.  The overhead is very low and when you come to more to another dedicate host it will save you hours of configuration – just copy the VM.

We have avoided using cloud hosting (such as Amazon, Rackspace or Linode) for several reasons:

  1. Your data isn’t in your control.  I want my data on my hard drives.
  2. Unlike the simplicity of raw or qcow2 disk images, you can’t move to an cloud hosted server very easily.  Yes, I know Openstack is supposed to solve this problem – but in the meantime have you tried migrating from Linode? Basically, you need to reinstall.
  3. If you have more than one server or need lots of space / cpu power then it is often cheaper hosting it yourself.

Basically, I think that VM’s rock. What do you think?

How to configure Ubuntu to log to a remote syslog server

I just installed a new Syncology 814 server in our rack to give us some more storage for backups.   It is very simple to use and well made.  While browsing through the software that comes with the NAS,  I discovered it has a centralised syslog server. There are instructions for installing the Syncology syslog server are here:

I’ve always wanted to centralise the syslogs of my servers to help with debugging. The key reasons are ensure that we have logs in the event a server was hacked and if a virtual machine crashes I can review the logs before restarting it.

Anyhow, I found it hard to find instructions for configuring Ubuntu 12.04 to send their syslog messages to the syslog server. As always – it is really simple when you know how.

Ubuntu uses a service called rsyslogd.  Its configuration file is located at:

/etc/rsyslog.d/50-default.conf

This file tells the deamon where to log each type of message. For example – the follow entry means that all cron message are sent to /var/log/cron.log:

cron.* /var/log/cron.log

If you want to the cron messages to also be sent our new remote syslog server, then you can add this entry.

cron.* @syslogserverhostname:514

To keep it really simple – I wanted all my messages send to the syslog server.  Why not – you can always filter them later.  I simply added:

*.* @syslogserverhostname:514

You need to restart the rsyslogd for the settings to take affect.

service rsyslog restart

Voila.  Happy Syslogging.