First, we need to make sure that all of our time settings are correct. Let’s compare the hardware clock settings to the current real time, which is 11:13AM EST:

[16:13] root@ns3:~ # hwclock
Wed 21 Dec 2011 04:13:49 PM EST  -0.297984 seconds
[16:13] root@ns3:~ # date
Wed Dec 21 16:13:07 EST 2011
[16:13] root@ns3:~ #

Well, here we can see that the hardware and system clocks are wrong! KVM/QEMU likes to keep its “hardware time” as UTC, so it takes the time from the host system and adjusts it to UTC, based off of the host system’s timezone setting. The host system shows the correct time (and actually this physical host machine’s hardware time is set to local, not UTC).

Ok, well lets make sure our timezone is set correct. The /etc/localtime file represents the timezone info for your particular time zone. This can either be a symbolic link to the correct file, or a copy of the correct file. On my system, it looks like this:

[16:20] root@ns3:~ # ls -alh /etc/localtime
lrwxrwxrwx 1 root root 36 Dec 21 15:14 /etc/localtime -> /usr/share/zoneinfo/America/New_York
[16:21] root@ns3:~ #

Now, you can either make a symbolic link using the command

ln -s /usr/share/zoneinfo/America/New_York /etc/localtime

or you can copy the zone file with the command

cp /usr/share/zoneinfo/America/New_York /etc/localtime

There are arguments for and against each method, use whichever method you prefer.

Next, we need to check our /etc/sysconfig/clock file to make sure it is correct. My file looks like this:

ZONE="America/New_York"

Some users will add a line that says UTC="true" (or false), but it isn’t needed and can just add confusion.

Finally, we need to check the /etc/adjtime file; this file was the key! The 3rd line in the file will say either UTC or LOCAL. Since our hardware clock was set to UTC time (as shown above), we need to change our adjtime file to say UTC instead of LOCAL. Here is what mine looks like:

-15185.281863 1324482636 0.000000
1324482636
UTC

So now everything should be set to keep the system time correct after a hard reboot (power off & on), but our current clock is still wrong! Well, we can fix the current time with the following command:

[16:24] root@ns3:~ # hwclock --utc -s
[11:24] root@ns3:~ #

This will set our system time from the hardware clock, stating that the hardware clock is kept in UTC time.

Now, in order to test everything, we need to completely power down the virtual machine and restart it. Simply issuing a reboot won’t force our host machine to apply it’s time settings to the VM. Previously, after every hard boot the time would be wrong, but now it’s correct!

You should also set up some NTP time synchronization to keep your time accurate; but this will at least keep the zone correct between power cycles.

The first thing you want is to start with a nice server with a good OS installed. I’m starting with the CentOS 6 operating system, and a newer Dell Poweredge server. Obviously the more powerful the hardware, the better, but you will want something that supports full hardware virtualization, which is important for security, stability, and speed, among other things. Check in your BIOS for something like “Enable Virtualization.” Check with your hardware manufacturer for details.

After you have your initial server set up, you’ll need to add some packages for virtualization support. We’ll use the yum groupinstall command to get our necessary package groups, then install the bridge software separately, make sure everything is up to date, and finally restart the server so that we have the latest kernel running.

bash# yum groupinstall "Virtualization" "Virtualization Client"
bash# yum groupinstall "Virtualization Platform" "Virtualization Tools"
bash# yum install bridge-utils
bash# yum update
bash# reboot

When you reconnect to your host machine, make sure to forward some ports so you can tunnel to the VM’s console display! With putty, you can use a command like this:

putty.exe -L 5900:127.0.0.1:5900 -L 5901:127.0.0.1:5901 user@server

This will forward two ports for us, 5900 and 5901 to the localhost (the machine we’re connecting to) that we will use for VNC connections. Our first VM will use port 5900, our second VM will use port 5901, and so on. You can easily add more port forwards to your SSH connection to enable connecting to additional VM’s.

The first thing we need to do are set up some network bridges. There are a lot of different ways to configure network bridges, but we’re going to keep this one simple. Let’s say our machine has two physical network interfaces, eth0 and eth1. We’re going to assume that both interfaces are connected to the same network (so we can’t bridge them together), that we will use eth0 to connect to our physical machine (aka hypervisor, dom0, host, or manager), and that eth1 has no IP address. So, just create a separate bridge for each physical interface, br0 and br1.

Start by configuring eth0 (/etc/sysconfig/network-scripts/ifcfg-eth0):

DEVICE="eth0"
HWADDR="12:34:56:78:90:ab"
NM_CONTROLLED="no"
ONBOOT="yes"
IPADDR=10.0.0.100
GATEWAY=10.0.0.1
TYPE=Ethernet
BOOTPROTO=none
NETMASK=255.255.255.0
USERCTL=no
PEERDNS=yes
IPV6INIT=no
SEARCH=mydomain.com
DNS1=10.0.0.1
DNS2=10.0.0.2
DNS2=8.8.8.8
BRIDGE=br0

You could optionally configure eth0 to use DHCP, if desired. Be careful when remotely making changes to your active network connection; a misconfiguration could make you unable to connect!

Next, lets configure eth1 (/etc/sysconfig/network-scripts/ifcfg-eth1):

DEVICE="eth1"
HWADDR="12:34:56:78:90:cd"
NM_CONTROLLED="no"
ONBOOT="yes"
BRIDGE=br1

Restart the network connections to make sure everything is working so far:

bash# service network restart

Now that our physical interfaces are configured, lets configure some bridges! We can just edit the bridge scripts, so open the files and configure them already!

Bridge device br0 (/etc/sysconfig/network-scripts/ifcfg-br0):

DEVICE=br0
BOOTPROTO=none
ONBOOT=yes
TYPE=Bridge

Bridge device br1 (/etc/sysconfig/network-scripts/ifcfg-br1):

DEVICE=br1
BOOTPROTO=none
ONBOOT=yes
TYPE=Bridge

Restart the network services again, and we’re ready to go!

bash# service network restart

Check that our bridge devices exist with the following command:

bash# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.842b2b03fa01       no              eth0
br2             8000.0010186e94e8       no              eth2

This shows us that br0 has interface eth0, and br1 has interface eth1.

Ok, so now that we have our host correctly configured, we need an OS to install! You can use a disk drive with the OS installation, install from something provided on the network, or go get a .iso of your favorite OS, and install from there. We’ll just use an .iso. Take a look at the following command:

bash# virt-install -n newbawx --vcpus=1 -f /home/vm/newbawx -s 60 -r 2048 --nonsparse -w bridge:br1 --vnc --accelerate -c /tmp/Fedora-15-x86_64-DVD.iso --os-type=linux --os-variant=fedora13 --noautoconsole
Starting install...
Creating storage file newbawx                            |  60 GB     04:43
Creating domain...                                       |    0 B     00:00
Domain installation still in progress. You can reconnect to
the console to complete the installation process.

First we use the virt-install command to create a new virutal machine named newbawx. We give it a hard drive size of 60GB (-s 60), 2GB of RAM (-r 2048), tell it to use bridge 1 (-w bridge:br1), and have it use a Fedora 15 .iso as a virtual CD drive to install from (-c /tmp/Fedora-15-x86_64-DVD.iso). Don’t forget the --vnc option to enable VNC access to the guest console. Notice that the os-variant is fedora13; that is because it is the highest os-variant parameter currently supported for Fedora!

After the virt-install command is run, we can optionally set the VM to automatically start with the host server:

bash# virsh autostart newbawx
Domain newbawx marked as autostarted

Next, fire up your favorite VNC client and connect to 127.0.0.1:5000. You will be greeted with the installation walkthrough for your guest OS!

Also, if you wanted to delete and remove a virtual machine named newbawx:

bash# virsh destroy newbawx
bash# virsh undefine newbawx
bash# rm -rf /home/vm/newbawx

XML files containing your virtual machine settings are located in /etc/libvirt/qemu/.