stressfree - virtualisation

USB devices with VMWare Server 2.0 on Ubuntu

David — Mon, 17 Aug 2009 05:17:18 +0000

One of the nice features of VMWare Server 2.0 is that it supports the forwarding of USB devices to virtual machines. Unfortunately when it comes to Linux the VMWare team have leveraged an old method (/proc/bus/usb) for scanning the USB bus which newer distributions, such as Ubuntu Server 8.04 no longer support.

To resolve this problem the "old" method for scanning for USB devices must be enabled in the underlying operating system. In the case of Ubuntu Server 8.04 this is a case of editing the file /etc/init.d/mountdevsubfs.sh and uncommenting the following section:

#
# Magic to make /proc/bus/usb work
#
mkdir -p /dev/bus/usb/.usbfs
domount usbfs "" /dev/bus/usb/.usbfs -obusmode=0700,devmode=0600,listmode=0644
ln -s .usbfs/devices /dev/bus/usb/devices
mount --rbind /dev/bus/usb /proc/bus/usb

Reboot the server and /proc/bus/usb should be functional once more.

Activating a USB device within a virtual machine

Once the underlying USB subsystem is configured the USB device needs to be associated with a virtual machine. For this to occur the virtual machine must have the USB Controller added to its virtual hardware configuration. If the controller is not already part of the virtual machine's configuration shutdown the VM, add the device and restart.

The VMWare web console with USB device selection (click to enlarge)

Assuming there are USB devices attached to the server, once the virtual machine boots a small USB icon will appear within the VMWare web management console. Click on the icon and select the relevant USB device to attach it to the running virtual machine.

All going well the USB device will appear within the virtual machine as an accessible device. VMWare Server remembers this selection, so the next time the virtual machine (or server itself) is restarted the USB device will automatically be attached to the running VM.

VMWare Server 2.0 optimisations

David — Sun, 19 Jul 2009 08:42:08 +0000

VMWare Server 2.0 is emerging as a capable, zero cost alternative to VMWare ESX when used in combination with Ubuntu Server 8.04LTS. Unfortunately "out of the box" performance can be a little disappointing, especially when running guest Windows virtual machines. What follows are a few system tweaks that can improve performance without hampering overall system stability. I have not come up with these myself, instead they are pruned from the following pages:

Kernel parameters

In addition to the default Ubuntu Server kernel parameters, the following should be appended to the end of /etc/sysctl.conf.

vm.swappiness=0
vm.overcommit_memory=1
vm.dirty_background_ratio=5
vm.dirty_ratio=10
vm.dirty_expire_centisecs=1000
dev.rtc.max-user-freq=1024

Once added reboot the server to ensure their application is successful and permanent.

Create an in-memory temp drive

In the host's /tmp directory create a new directory named vmware (e.g. /tmp/vmware). This will be used as the mount point for a tmpfs (in-memory) partition for storing VM related, temporary files.

Edit /etc/fstab and add the /tmp/vmware partition to your list of mount points:

tmpfs /tmp/vmware tmpfs defaults,size=100% 0 0

Now if you execute the following command the tmpfs filesystem will be mounted at /tmp/vmware:

sudo mount /tmp/vmware

If successful, reboot the Ubuntu server to ensure the tmpfs partition is mounted at boot time.

VMWare Server configuration

Edit the /etc/vmware/config file and ensure the following configuration declarations are set:

prefvmx.minVmMemPct = "100"
prefvmx.useRecommendedLockedMemSize = "TRUE"
mainMem.partialLazySave = "TRUE"
mainMem.partialLazyRestore = "TRUE"
tmpDirectory = "/tmp/vmware"
mainMem.useNamedFile = "FALSE"
sched.mem.pshare.enable = "FALSE"
MemTrimRate = "0"
MemAllowAutoScaleDown = "FALSE"

These configuration declarations instruct VMWare Server to keep all virtual machines in memory and not to write unused blocks to disk. It also sets the temporary directory to the newly created tmpfs partition at /tmp/vmware.
Restart the VMWare Server process (sudo /etc/init.d/vmware restart) or reboot the server for these changes to take effect. The net result should be notably smoother virtual machine performance, especially when it comes to Windows guests.

Virtual machine tips

Always use fully allocated disk images.
Do not use snapshots as they are approximately 20% slower.
Always install the VMWare Tools package.
If running Linux make sure the kernel is compiled for running within a VM, or is using the correct boot time parameters.

Remotely managing VMWare servers via SSH

David — Sun, 19 Oct 2008 09:44:05 +0000

As the cornerstone of any company's server infrastructure it is extremely rare to find VMWare servers (be they Server, ESX or ESXi) directly exposed the the Internet. Generally these important services are hidden behind layers of protection which can make managing them when not onsite quite a challenge. Of course you could setup a VPN or use some remote desktop access software, but why bother when plain old SSH can do the job for you.

Once you have SSH access to a system within the organisation's network it is a fairly simple task to create virtual tunnels to the VMWare servers. This is a secure way to manage the devices because all traffic goes through an encrypted tunnel and beyond the SSH service itself you are not interacting with any other internal services.

Remote VMWare server access requires two SSH tunnels, an HTTPS tunnel (typically port 443) and a console tunnel (typically port 902). Below is a small script that you can use to create these tunnels from Linux, OSX or any other *NIX operating system.

Copy and paste the following text into a file named vmware-manage.sh:

#! /bin/sh

# The local I.P. address for the tunnel endpoint
LOCAL_IP=192.168.1.1

# The SSH connection details
SSH_USER=sshuser
SSH_HOST=ssh.host.com
SSH_PORT=62222

# VMWare server configuration
VMWARE_IP=$2
VMWARE_WEB_PORT=443
VMWARE_CONSOLE_PORT=902

echo "Managing VMWare server at $VMWARE_IP"
echo "Accessible via $LOCAL_IP:$VMWARE_WEB_PORT"
echo "Press CTRL+C to close"

case "$1" in
console)
sudo ssh -N -L $LOCAL_IP:$VMWARE_CONSOLE_PORT:$VMWARE_IP:$VMWARE_CONSOLE_PORT $SSH_USER@$SSH_HOST -p $SSH_PORT
;;
web)
sudo ssh -N -L $LOCAL_IP:$VMWARE_WEB_PORT:$VMWARE_IP:$VMWARE_WEB_PORT $SSH_USER@$SSH_HOST -p $SSH_PORT
;;
esac

At the top of the file edit the LOCAL_IP, SSH_USER, SSH_HOST and SSH_PORT variables to suit your specific setup.

LOCAL_IP - Typically your desktop's I.P. address (or 127.0.0.1).
SSH_USER - The SSH user account to log in with.
SSH_HOST - The hostname with the accessible SSH service.
SSH_PORT - The port SSH is running on. For security run SSH on a non-standard port if facing the Internet (i.e. not 22).

Now flag this file as being executable:

chmod a+x vmware-manage.sh

To manage a VMWare server with an internal I.P. address of 10.1.1.5 run the following command:

./vmware-manage.sh web 10.1.1.5

You will be prompted for your local password (for sudo access) and the SSH password.

Once created open a second console and create the second tunnel for console access:

./vmware-manage.sh console 10.1.1.5

You should no be able to access your VMWare server at https://192.168.1.1 (i.e. the LOCAL_IP address value). Or if you are using the VI Client enter 192.168.1.1 as the server address.

Once you have finished managing your system you can close the tunnels by pressing CTRL+C.

VMWare Server 2 finally goes gold

David — Sun, 05 Oct 2008 08:46:03 +0000

On September 23 after a year of public development VMWare Server 2.0 was officially released. Server is VMWare's free, entry-level, server-centric hypervisor. Unlike VMWare's other server virtualisation products ESX and ESXi, Server must be pre-installed onto a host operating system (Windows or Linux). This adds a management and performance overhead, which for some is incentive enough to choose VMWare's more costlier offerings (or explore Xen). However if you are looking to easily virtualise a handful of servers and do not mind a small performance hit, VMWare Server is a great place to begin.

In comparison to VMWare Server 1 (a.k.a GSX) this new release appears to be a complete rewrite. However when first announced the new version received a mixed response as many existing users viewed it as slow, bloated and buggy compared to its predecessor. Ignoring the bugs which come with any beta-quality code, the majority of this criticism fell into two areas: the new web-based management console and a 500MB+ download (up from ~100MB).

Web-centric virtualisation management

Without a doubt the most controversial aspect of VMWare Server 2 is its focus on a web-based management console. In the previous release management was primarily conducted through a Windows-only client with a token web interface provided to view what was running. This new interface enables all of the hypervisor's functionality to be managed and monitored from any modern, Javascript-enabled browser. The only cavet being that virtual machine console access requires an ActiveX or Firefox extension (Windows/Linux only). Process-wise this is a little disjointed as a browser restart is needed when this extension is first installed. Whilst not a major problem this two-step process does take the shine from being able to manage your virtual infrastructure from 'any' computer.

The web administration console (click to enlarge)

As an aside given the variety of Java-based SSH, VNC and remote client applets it is a little surprising to see VMWare go the ActiveX/Firefox extension route. Whilst I have not tried the ActiveX control, the Firefox extension is large and feels sluggish when running in both Windows and Linux. Still the ability to setup and manage VMWare from something other than Windows is a definite bonus. However as an OSX user it would be nice to see VMWare management support on this platform as well.

The Firefox extension for virtual console access (click to enlarge)

But wait, VI Client to the rescue

If you are used to a traditional Windows client or just cannot stand the new web interface you will be glad to hear it is possible to manage Server 2 from the Virtual Infrastructure Client. The VI Client is very polished and feels far more responsive than the web interface for administration and console tasks. It also comes with some very nice realtime monitoring tools that graph hardware utilisation at a VM and host level. Whilst personal preference, if you manage VMWare from Windows I suggest ignoring the web interface altogether and heading straight to the VI Client.

The VI Client running against VMWare Server 2.0 (click to enlarge)

Server 2 comes with the VI Client which can be downloaded from: http://your.vmware.server/client/VMware-viclient.exe.

Does a 500MB download represent a bloated hypervisor?

The five fold jump in installer size gave many the impression that the new hypervisor would leave no free resources for the virtual machines it was intended to run. In reality this is far from the case, with the increased download size attributable an enhanced feature-set and broader guest operating system support. The installer size is also not helped by the packaging all software dependencies such as Java, Tomcat and VIX rather than relying on these to be installed independently.

The end result is that an installation of VMWare Server 2 will consume more disk space than its predecessor, but it does not use excessive amounts of CPU or memory. For example the primary 'vmware-hostd' process consumes approximately 130MB of memory and the Java web console 64MB. Assuming you are running a slim host O/S such as Ubuntu 8.04 Server this leaves plenty of memory and CPU cycles for virtual machines.

Ubuntu Server, the perfect VMWare host

For the last six months I have had great success with Ubuntu Server 8.04 as the host operating system. The default installation of Ubuntu Server is very light-weight and has extensive hardware support. To top it off Ubuntu 8.04 is a Long Term Release (LTS) which is supported by Canonical until 2013. VMWare Server 2 comes with pre-compiled kernel modules for Ubuntu 8.04 making installation a breeze. The only thing you need to do prior to installing VMWare Server is install the make package:

sudo apt-get install make

Whilst nothing needs to be compiled for VMWare Server to run, the installer does not like it when the make tool is not present. Apart from this minor distraction installation goes smoothly on both 32bit and 64bit variants of Ubuntu & VMWare Server.

A couple of VMWare tips

1. Keep your host machine 'clean'

For best performance only run the bare minimum on the host operating system. If possible stick to a cut down server O/S like Ubuntu Server instead of Windows or a full blown X-Windows Linux install.

2. Run optimised kernels on Linux virtual machines

The 2.6 Linux kernel introduced a 1000Hz clock ticker that is great for desktop performance but a drain on a hypervisor. Not only does this degrade overall performance but it can lead to weird (fast or slow) clocks in the virtual machines themselves. VMWare is optimised for a 100Hz clock so try to run a kernel optimised for virutalisation or set the following kernel parameters: "clock=pmtmr divider=10".

For example if you are using Grub as your Linux virtual machine's bootloader it would look something like this:
/boot/grub/menu.lst (in this example a Centos 5.2 VM)

default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-92.1.13.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-92.1.13.el5 ro root=/dev/VolGroup00/LogVol00 clock=pmtmr divider=10
initrd /initrd-2.6.18-92.1.13.el5.img

* divider=10 instructs a 2.6 Linux kernel to check the hardware clock every 100Hz (1000Hz/10).

3. Install VMWare Tools

Take the time to install VMWare Tools on each of your virtual machines. This package has a decent network driver that removes some of the shortcomings of using a virtualised network interface. If you are running virtual machines with a graphical interface (i.e. Windows) you will also notice significantly improved performance.

4. Always use SCSI hard drive controllers in your virtual machines

Whilst it is possible to define an IDE hard drive controller within your virtual machine you run the risk of encountering issues when migrating from VMWare Server to ESX/ESXi. This is not an issue if you will only ever be using VMWare Server, but to be sure just stick to the default SCSI controller.

5. Do not overload RAM

Whilst it is possible to allocate more virtual RAM than your server actually has this is not a good idea. Hard drive access is far slower than memory, so if possible do not impose this bottleneck on your virtual machines.

Conclusion

VMWare Server 2.0 has come a long way since its early beta releases. Virtual machine performance is very good especially once VMWare Tools is installed and the kernel optimised (if Linux). A lot of work has obviously gone into the web interface and although it is not mind-blowing it does work pretty well. However if you are managing your VMWare infrastructure with Windows you will find the VI Client is superior in terms of functionality and performance. Overall for a free (as in beer) hypervisor VMWare Server 2.0 provides a simple and reliable introduction to virtualisation. Also its compatability with VMWare's Virtual Intrastructure ensures that it is easy (but not cheap) to scale your virtual machines well beyond one or two physical hosts.

Installing VMWare Server 1.0 on Ubuntu 6.06LTS

David — Wed, 23 Jan 2008 09:04:58 +0000

Ubuntu 6.06LTS is a useful platform for VMWare because it has a small footprint by todays standards and is supported by Canonical until 2011. Unfortunately installing VMWare Server 1.0 can be a little painful given there are no binary kernel modules for Ubuntu in this release.

Fortunately there are some excellent guides for installing VMWare on this platform such as this one from HowtoForge. What follows is an installation script based on the HowtoForge guide that saves the administrator a lot of time and solves a bug along the way.

Build your Ubuntu server

A basic install of 6.06LTS is pretty light weight and by default doesn't have anything running that isn't needed. A few things that you may want to install is the openssh-server package for remote access and ntp-server for keeping your system clock accurate.

sudo apt-get install openssh-server ntp-server

By default Ubuntu 6.06 configures its network via DHCP which is fine for a desktop system but probably not ideal for a server. To set a static IP address edit the /etc/network/interfaces file and set the relevant static network interface and address parameters. For example:

iface eth0 inet static
address 192.168.1.10
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1

Also check the /etc/resolv.conf file contains the correct DNS server details before restarting the network interfaces with:

sudo /etc/init.d/network restart

The VMWare Installation Script

1. Create a vmware directory somewhere handy to store the installation files, your home directory is a good place. Once the installation is complete you can remove this directory although it is worth making a backup should you wish to install VMWare again.

2.Download the Linux tar archives of VMWare Server 1.0 and the Management User Interface (MUI) from the VMWare website. The current stable release of VMWare Server at the time of writing was version 1.0.4-56528. Also as you are downloading remember to record your serial code as this will be needed during the installation process.

3. In the same directory where you have downloaded these install archives create a new file named rundir.httpd.vmware with the following contents:

#! /bin/sh
# /var/run gets purged at every reboot!

RUNDIR="/var/run/vmware/httpd"
OWNER="www-data"
GROUP="www-data"

/usr/bin/test -d "$RUNDIR" || \
/bin/mkdir -p "$RUNDIR" && /bin/chown "$OWNER:$GROUP" "$RUNDIR"

This file is copied to the /etc/init.d/ directory by the installation script and overcomes an permissions issue which stops the VMWare MUI from loading.

4. Now create a file called install-vmare.sh with the following contents:

#! /bin/sh
TMP="/tmp"
VERSION="1.0.4-56528"

echo "Installing VMware Server for Ubuntu 6.06"

echo "Installing application requirements"
echo "---------------------------------------------------"
echo "Installing dev headers and xinetd..."
sudo apt-get -y install libx11-6 libx11-dev libxtst6 xlibs-dev xinetd wget
echo "---------------------------------------------------"

echo "Installing Linux Kernel headers..."
sudo apt-get -y install linux-headers-`uname -r` build-essential
echo "---------------------------------------------------"

echo "Installing build utilities..."
sudo apt-get -y install gcc binutils-doc cpp-doc make manpages-dev autoconf \
automake1.9 libtool flex bison gdb gcc-doc gcc-4.0-doc libc6-dev-amd64 lib64gcc1

# Install VMWare Server
echo "---------------------------------------------------"
echo "Uncompressing the VMware Server $VERSION archive..."

# Copy files to revelant locations
cp VMware-server-$VERSION.tar.gz $TMP
cp VMware-mui-$VERSION.tar.gz $TMP
sudo cp rundir.httpd.vmware /etc/init.d/

cd $TMP
tar -xzf VMware-server-$VERSION.tar.gz
rm VMware-server-$VERSION.tar.gz

echo "---------------------------------------------------"
echo "Installing VMware Server $VERSION..."
cd vmware-server-distrib
sudo ./vmware-install.pl

# Install the VMWare web management console
echo "---------------------------------------------------"

echo "Uncompressing the VMware MUI $VERSION archive..."

cd $TMP
tar -xzf VMware-mui-$VERSION.tar.gz
rm VMware-mui-$VERSION.tar.gz

echo "---------------------------------------------------"
echo "Installing VMware MUI $VERSION..."

# Configure the MUI rundir fix
sudo chmod 755 /etc/init.d/rundir.httpd.vmware
sudo ln -s /etc/init.d/rundir.httpd.vmware /etc/rc2.d/S90rundir.httpd.vmware

cd vmware-mui-distrib
sudo ./vmware-install.pl

echo "---------------------------------------------------"
echo "Cleaning up..."
cd $TMP
rm -rf vmware-server-distrib
rm -rf vmware-mui-distrib
echo "---------------------------------------------------"
echo "VMWare installation complete"

echo ""
echo "To administer VMWare you will need to either:"
echo "1. Enable root logon access (sudo passwd root)"
echo "2. Set set the uid of a designated user to 0 (sudo nano /etc/passwd)"
echo ""
echo ""

This is the script that handles installation of all the required dependencies, kernel sources and VMWare packages.

NOTE: You may need to tweak the TMP and VERSION variables to suit your server environment and downloaded VMWare version.

5. Finally enable execute permissions on this file and run the script:

chmod a+x install-vmware.sh./install-vmware.sh

The script will prompt you for your password in order to gain administrator privileges (sudo). It will then install all the required packages via apt before copying the rundir.http.vmware file into the correct location and running the VMWare installers.

For the most part the default VMWare install options can be accepted without much thought. The only settings that may need tweaking is the location of the VMWare images (default /var/lib/vmware/Virtual Machines) and the MUI's default login time of 60 minutes which seems a little long for my liking (15 minutes would seem more appropriate).

All going well at the end of the process you should have a fully functional VMWare Server with a web management console operating at https://server-ip-address:8333/. Whilst you cannot create or install virtual machines via the web console you can download the Windows or Linux VMWare Console installers which will get you going.

Kernel Updates

Be aware that each time you upgrade the Ubuntu kernel to a different version the VMWare kernel module must be recompiled. After upgrading your kernel and rebooting the system you will find VMWare fails to load. At this point do not panic, it only takes a few steps to rectify the situation.

1. First download the headers for your current kernel.

sudo apt-get install linux-headers-`uname -r`

2. Now run the vmware-config.pl script, accept the default settings and rebuild the VMWare kernel module.

sudo vmware-config.pl

Once this script completes VMWare should once again be operational. The only thing left to do is remove the old kernel headers if you feel you won't be needing them again:

sudo apt-get remove linux-headers-(old kernel version)

Parallels update brings Windows CAD to the OSX desktop

David — Wed, 28 Feb 2007 08:24:20 +0000

Parallels released an update today for their Parallels Desktop for Mac virtualisation software which introduced 'coherence' mode and seriously improved video drivers capable of supporting DirectX. To give the new features a test drive I installed Autodesk Design Review, Revit 9.1 (trial version) and Bentley View on the virtual instance of Windows XP and had a play. All performed very well even with minimal RAM allocated for testing purposes. Quite possibly the only let down was that before you could start using the software the virtual machine first had to load Windows.

The screencast above illustrates the boot process, coherence mode, Design Review and Revit in action. The screencast was taken at a fairly low frame rate and YouTube just makes it all that worse. Please take my word for it that performance on a 1.83 Intel Core Duo iMac was fairly snappy even with only 256meg of RAM assigned to the VM. In a production environment you would certainly want to allocate at least 512meg of RAM to Parallels which would mean needing between 1.5/2gig of RAM in the Mac.

Whilst I would hardly recommend to architects that they should use their primary productivity application in a virtualised window, from the perspective of those Mac users who need to occasionally use a piece of Windows only software this level of functionality and performance from Parallels is perfect. Sure it is not nearly as quick as running natively, but then you don't have instant access to all of OSX's niceties that you begin to miss once forced to work on a Windows desktop for a little while.

XenExpress - the fast lane of Xen virtualisation

David — Sun, 21 Jan 2007 04:19:54 +0000

The open source Xen virtualisation suite has caused a bit of a stir within the Linux world because it combines the power of VMWare without the proprietary code and cost hassles. Unfortunately Xen is not the most user friendly thing in the world to setup or configure. For a large organisation this is not so much of a problem because they can afford to hire expensive consultants or train their in-house staff. For smaller players or individuals interested in the concept but unwilling to invest hours into training XenSource have released XenExpress.

XenExpress fits on a single CD and can be downloaded without charge from the XenSource website (they do however ask for a few contact details). To setup your very own Xen host you just boot the computer from the CD, answer a few configuration questions like time and network setup and then just sit back and watch as XenExpress turns your computer into a fully functional Xen platform (for further instructions checkout this howto). After installation is complete configuration of the Xen host occurs remotely via a Java desktop application that runs on Windows, Linux or after a little hacking OSX. Most of the basic Xen tasks like virtual instance management and system maintenance can be accomplished through the interface without much effort or reference to the user guide. If you are an advanced user you can also bring up a terminal on the Xen host and run your normal Linux commands as at its heart XenExpress appears to be a slimmed down Red Hat distribution.

The XenServer Client on Windows displaying the properties of an instance

XenExpress is a free product and as such it is digitally handicapped when compared to its more expensive siblings. From a hardware perspective only 4gig of RAM is supported which limits the number of simultaneous instances that can be run. At the software level only Debian, Windows and Red Hat instances can be installed from scratch whilst existing Suse Enterprise 9 servers can be migrated onto the server (but not created from scratch).

Installation of a Debian instance is the easiest option as a base copy of the OS is installed on the server ready to use. This means after a couple of mouse clicks and a few minutes waiting a Debian instance will be installed, booted and ready to use. For a new user who just wants to experiment with what virtualisation is all about this functionality is excellent. Experienced users will soon find limitations with this approach but their needs are better meet by the XenServer and XenEnterprise software packages. On a side note existing installations of XenExpress can be upgraded to XenServer through the purchase of a license key which means one can easily shift prototype boxes into production should the need arise without a complete reinstall.

The XenServer client on Windows showing a text console on a Debian instance straight after installation.

In order to run Windows XP SP2 or Windows 2003 you must be using an HVM compatible processor. This rules out Windows virtualisation on anything except for the latest hardware but still its great that such functionality is available in the open source world these days. Another drawback of XenExpress is that it only supports network installations of Red Hat Linux. This means that if you want to run up a Red Hat instance you must first copy your CD media to an FTP or SMB share. This is not a huge pain but it would be nice if you could just install from CD especially given the target market for XenExpress is the casual user. Although I did not try it my guess is Centos will also install using the Red Hat template which means you can run a commercial grade Linux distribution without the commercial licensing fees.

The XenClient on OpenSuse 10.1 displaying some operating statistics of the Xen host

I was really impressed by XenExpress as it made the process of setting up the base Xen host quick and completely painless. I did experience one problem on my test box which was the DMA support was not enabled on the IDE drives. Hopefully these teething pains will be cleaned up as the product matures as things like this will put new users off the product and virtualisation. The XenExpress client interface was very good and quite snappy, I especially liked the fact it combined Text Console, Graphical Console (VNC) and server statistics into a single, well laid out control panel. One major limiting factor with the XenExpress client interface is that is designed to work with a single server rather than operate at a cluster level. Whilst this is limiation is not present in the XenServer and XenEnterprise packages still it would be nice to have the ability to monitor and manage two servers in XenExpress. Going even further it would be really nice to be presented with the option to easily migrate Xen instances between these two servers (through seamless export/import). This would allow even inexperienced users to begin to appreciate the true power of Xen (and hypervisors in general) which is its ability to completely differentiate hardware decisions (i.e. upgrades and retirements) from the operating environment.

At the end of the day XenExpress won't suit you if you are looking for a highly customisable Xen server platform. If on the other hand you are an curious home user or someone looking for a quick and easy way getting into virtualisation then XenExpress is in my view the best way of getting your feet wet. You won't be presented with hundreds of options and in less time that it takes to read and understand the Xen documentation you can have a Xen host with a couple of Debian instances up and running ready to play with.

Parallels on OSX and OpenSUSE 10.1 experimenting

David — Tue, 23 May 2006 20:53:17 +0000

I have been trying out SuSE 10.1 on my iMac with the Release Candidate version of Parallels. Parallels is awesome, there is nothing like being able to play with (and blow away) Linux and Windows at almost full speed directly within OSX. On the PowerPC I have used Virtual PC and the Intel iMac has also gone through Bootcamp but Parallels is far and away a better solution for most tasks (you would not want to run games through Parallels).
From a website design perspective it really eases the testing of html/css in all four major environments (Windows Explorer, Firefox, Linux Konquerer and OSX Safari).

One new default feature in OpenSUSE 10.1 that is really very cool is AppArmor. It makes the task of securing server and client based applications simple through the automatic creation of application-based rules (i.e. Firefox can execute these files, modify these files and access these devices). The SUSE Diary has a nicely written tutorial introducing the application and describing how to easily create rulesets.

Through proper use it can protect systems from zero day exploits and just stop users from doing dumb things. It is definitely a huge feature that will appeal to corporate users, rather than messing around with file permission and access levels directly, you just tell the kernel what you want the application to be able to do and it looks after it from there. In theory these rulesets can be managed centrally from Zen (they are just simple text files) but I don't think Novell have released details on this.

Also the Jem Report have a useful article describing how to get your OpenSUSE 10.1 install up to speed with all the packages you may need (Java, mp3, etc.). OpenSUSE have begun to make this task easier with their 'Add-On' CD but still it is nice to have a single document that lists all the optional features available.

The Art of Xen

David — Sun, 12 Feb 2006 19:32:03 +0000

In order to install Zimbra without issues I had to setup Xen on my server. This was actually a good thing because I had been thinking of doing so for a while after experimenting with it last year.

Setting up Xen on OpenSUSE is relatively straightforward if you follow the Xen howto on the Wiki: http://en.opensuse.org/Installing_Xen3

The latest Xen OpenSUSE 10 files can be downloaded from here:
http://www.suse.de/~garloff/linux/xen/RPMs-100/

For my setup I have used the following /etc/fstab file on my virtual server:

/dev/hda1       /                reiserfs acl,user_xattr      1 1
/dev/hda2       swap         swap     defaults              0 0
proc               /proc          proc       defaults              0 0
sysfs              /sys           sysfs      noauto                0 0
usbfs             /proc/bus/usb        usbfs      noauto              0 0
tmpfs             /dev/shm             tmpfs      defaults              0 0
devpts            /dev/pts             devpts     mode=0620,gid=5       0 0
/dev/shm        /opt/zimbra/amavisd-new-2.3.3/tmp       tmpfs   defaults,users,size=150m,mode=777     0 0

I did initally have a lot of trouble setting up the network on the virutal instance but after a lot of experimenting with different Xen packages and configuration options I finally settled on the following file (/etc/xen/zimbra):

# -*- mode: python; -*-

# configuration name:
name     = "zimbra"

# usable ram:
memory   = 512

# kernel und initrd:
kernel   = "/boot/vmlinuz-xen"
ramdisk = "/boot/initrd-xen"

# boot device:
root     = "/dev/hda1"

# boot to run level:
extra    = "3"

# network
nics=1
vif = [ 'mac=aa:00:00:50:02:f0, bridge=xenbr0' ]
dhcp ="dhcp"
hostname="zimbra"

# storage devices:
disk     = [ 'phy:system/mail,hda1,w','phy:system/mailswap,hda2,w' ]

One last thing is that the Xen howto modifies the virtual server's mtab file with the following line:

sed -e "s/^[1-6]:/#\\0/" < ./etc/inittab > ./etc/inittab.new

This command also commented out the default console as well as the other terminal consoles which meant that after installation there was no login prompt. In order to correct this edit the /etc/inittab file on the virtual server (whilst it is still mounted on the host system) and uncomment the following line:

1:2345:respawn:/sbin/mingetty --noclear tty1