Server virtualization

From Biowikifarm Metawiki
Jump to: navigation, search

(This information is from 2008/2009, refers to Xen 4 and 5 and may in part be dated)


Servers break down. RAID arrays are great, but less so if the RAID controller dies and the system from the backup does not want to live under new hardware (because the controller-specific driver is part of boot process and not automatically replaced, painful previous experience...). Installation and configuration of software is very complex and should ideally survive server hardware lifetime. Our analysis was that the project is more limited by management resources than by a requirement to obtain optimal performance out of the server.

For these reasons, we used virtual machines inside a VM server. In an archived discussion we have selected XenServer, the Citrix-distributed variant of the Xen open source software (see also wikipedia over the fully free Xen (no experience, very difficult to setup and administer, no tools for this) or VMWare (not open source, although some versions are free of cost).

XenServer comes with a very convenient XenCenter Windows tool for graphical administration. This tool is not open source, and one way Citrix is getting money - the free XenServer Express is limited to only a single host being administered at a time, meaning you have to open and close hosts if you have multiple ones. It also does not support advanced features like live migration (a Virtual machine under Xen can be migrated from one physical hardware to another while running, without stopping service for more than a few milliseconds!).

XenServer Installation (dated, Version 4/5)

XenServer works best on newer hardware where the processor supports virtualization. If this is not the case, you may receive an error message saying the the XenTools are not supported. XenServer may then still be used, but it will consume more memory and be slower, since paravirtualization is not possible (it will be as slow as the free VMWare Server software).

When creating a new VM, the easiest way is to use one of the provided templates (the Debian 4 is simplest, because everything is already on the Xen host, no additional CDs required).

The alternative is to importing an existing VM (XenCenter menu: VM, Import) that was previously exported (XenCenter menu: VM, Export as Backup, creating *.xva files).

In both cases, the IP number needs to be set. Should a VM under XenServer be misconfigured (e. g., it cannot be reached using ssh), one can still use the console that is part of XenCenter. Go there, log in, fix the IP-number, and forget that the server is running as a VM, simply use it with ssh etc. as if it where running directly on a physical hardware in a different building. If you use XenCenter and XenTools, you do not manually have to manage any port forwarding, etc.

Network Time Protocol (NTP) configuration

The Network Time Protocol (NTP) is a protocol for synchronizing the clocks of computer systems over packet-switched, variable-latency data networks. NTP uses UDP port 123 as its transport layer. It is designed particularly to resist the effects of variable latency (Jitter). Using NTP is a great way to keep your system clock set correctly. It works by contacting a number of servers around the world, asking them for the time and then calculating what the correct local time is from their responses. The optimal number of servers to listen to is three but two will also give a good accuracy. If your ISP runs a time server for you it is worth including it in your server list as it will often be more accurate than the pooled servers.

We need to add a number of servers to the server list. This is performing in /etc/ntp.conf by adding these rows: [NOTE: NOT DONE ON THE XEN6, it automatically obtains time from a *]


Now we need to run the ntpdate command against the server and start the ntp daemon:

# /etc/init.d/ntpd stop
# ntpdate
# /etc/init.d/ntpd start

Use the ntpq command to see the servers with which you are synchronized:

# ntpq -p

When the clock in the operating system shows the correct time, set the hardware clock like this:

# hwclock --systohc

See Also:

Migrating existing machines

Several tools exist, if you have experiences please add them here.

JKI, Windows Server 2003: It should be possible to use the VMWare tools to migrate into a VMWare compatible backup, and then modify this to import under XenCenter. However, we tried and succeeded with a simpler way: We installed a new Windows Server 2003 with the original CDs, then install the XenTools, then did a restore of the original (hardware-based) Server on the VM-Win2003 (using Windows own Backup program). Upon this we did have a minor problem with the restored Windows crashing, the solution was to reinstall the XenTools after booting the VM-Win2003 in protected mode (which is possible through the XenCenter console, albeit a bit tricky to get the F8-Keystroke in at the right time).

Tips for managing Virtual Machines

To backup the entire VMs, you have to stop it. Provided your VM-Host has a large hard disk, it is recommended to first copy the machine inside the server (XenCenter menu: VM, Copy). This minimizes the downtime. After the end of copying, the primary machine can be restarted, while the offline copy can then be backed up to a different location (backup is usually much slower than copy).

With Xen 6 it is possible to make a fast copy. Note that such a copy will degrade performance over time, however, so it should be replaced with a true copy. A good strategy is, however, to make a live copy, copy this again, and then delete the live copy.

We also usually keep a VM backup on the XenServer, to be able to stop a failing machine and quickly restart an older backup. However, there seems to be a catch in that XenCenter automatically changes the MAC address of the network interface of a copy. While this is very useful when intending to run the copy as well as the original, it causes temporary router-problems when they are intended as exclusive either-or failover-copies. If you start a copy and it does not seem to be immediately addressable under the original IP-Number, stop it and set the MAC Adress in XenCenter to be identical to the original VM (using XenCenter, Network tab).

Xen 6 Notes, esp. autostart

Xen 6 has removed the autostart VM Option from the administration console (XenCenter) of the free version because they want customers to buy their highly expensive High Availability versions. Thus, if a power interruption occurs, the XenServer will restart, but all VMs will remain shut down, requiring manual restarting. This is letdown, almost a reason to leave the "Citrix Xen" for good.

We attempted to follow recommendations to fix this from the command line (i.e. from XenCenter, on the XenServer-Console-Tab). See here. First, even if only a single server exists, create a pool in the XenCenter GUI. Then copy the uuid of the pool and the uuid of the VM you want to start from the respective "General" tabs in the XenCenter. Now on the console, issue:

xe pool-param-set uuid=ba8ddd9b-0062-2bfb-a420-59daef1a5699 other-config:auto_poweron=true
xe vm-param-set   uuid=0ee65706-0aff-0e67-aa77-bb74f028f9d8 other-config:auto_poweron=true

Executed, but not immediately tested, waiting for next regular or accidential shutdown to verify....