Server partitioning tools such as VMware's ESX Server are designed to enable a single server to run multiple guest operating systems simultaneously.
Vendors differentiate their partitioning tools by the number and variety of guest operating systems they support, and also by how much control they allow IT staff over the use of server resources such as processors, RAM, disk and network interfaces.
Each guest operating system typically uses one directory and a handful of files containing about 1GB of data. These files contain all the data associated with the guest operating system and its applications, and can be compressed and written to CD-ROM or another backup device. Moving guests from one server system to another is as simple as moving these files - allowing easy backup and rapid deployment.
Another advantage of a virtual server environment is that virtual networks can be used in place of LAN hardware. As well as possibly saving the cost of several gigabit NICs and associated LAN switching hardware, virtualised networks reduce the load on real networks, possibly avoiding the need for backbone upgrades, as well as reducing the amount of cable used and providing better security.
VMware's ESX Server provides tools to assign server resources to specific guests, and to limit resource utilisation according to simple policies when several guests contend for the same resource.
The ESX software is based on a Linux kernel, and installation on our test system - an eight-way IBM x440 server, detailed below - took about 15 minutes. Once installed, ESX is managed from a Web-based console, and virtual machines are accessed using network-based remote control tools. Several guest operating systems are supported, including Windows, Linux and NetWare. The most notable omission is Solaris x86.
A maximum of 64 concurrent guest operating systems are supported, running on a maximum of 16 processors and 64GB RAM. Currently, each guest can access only a single processor in the host server, but VMware will deliver support for multi-processor guests this year.
We found ESX Server gave excellent control, letting us lock specific guests to specific processors and other resources. Unlike other virtual server tools, ESX runs its own operating system rather than running as an application on top of Windows or Linux. Consequently it delivers much better performance and a richer set of features. In tests, we found CPU-intensive benchmarks ran at the same speed regardless of whether they ran inside an ESX virtual machine or directly on the x440 hardware.
Installation starts from a bootable CD-ROM, which loads Linux and a version of Red Hat's Anaconda installation tool, which is used to set-up the ESX operating system. The wizard asked us questions about country settings and time zones, and about 10 minutes later the server was ready for configuration. At this point we logged onto the ESX console and were surprised to find that the ESX operating system used only one of the x440's CPUs, and less than 256MB of its RAM. The rest of the CPUs and RAM were set aside exclusively for use by the guest operating systems.
However, rather than configure ESX from the x440's keyboard and screen, the system is designed to be managed using a Web browser running on a client PC and connected to the server via a dedicated local area network (LAN) interface.
We connected using HTTP, and were automatically redirected to a Secure Sockets Layer (SSL) connection. The console is password protected, and uses the same user-name database as the ESX Server environment. From the console, we used a wizard to complete our setup. The main task is to specify whether SCSI host adapters are used by ESX, the virtual machines, or both. As our x440 was fitted with only two disks, we configured ESX to share these with the guest operating systems.
When the wizard finished, we needed to create a partition for storing virtual machine data. The ESX console has menus and forms for creating such partitions, and for other types of system maintenance for guests. However, we needed to log into the main ESX Linux console and use standard Linux tools to create an additional partition that could be used by ESX Server.
Guests can be configured to use a percentage of the host system's CPU, network and RAM resources. Guests can also be locked to one or more processors, although each virtual machine uses only one host CPU at any moment.
In production environments, guest operating systems would probably be accessed by networked clients. For example, our Perl-based intranet application is accessed by staff using their Web browsers. However, server administrators also need to access guest operating systems as if they were sitting at the server's screen and typing on its keyboard. VMware provides suitable remote control tools for accessing guests from both Windows and Linux workstations. Several of these clients can access the same guest simultaneously.
For our evaluation of ESX's server consolidation capabilities, we took the collection of Windows and Linux servers used in our lab and replicated them as guest operating systems running on ESX. As we currently use a single Linux server to run several important applications, we also took the opportunity to split these out onto separate guest operating systems.
We installed a Trustix Linux firewall as a guest, configured to be the Internet gateway for our lab LAN and other guests. The configuration of the firewall provides some insight into the potential of virtualised server farms. For example, the firewall is the only guest that is attached to the NIC linking the server hardware to the Internet. Consequently, none of our other servers need be exposed to unfiltered Internet traffic. The firewall is also attached to our lab LAN via another NIC. This enables systems also connected to the lab LAN to access the Internet.
Our usual firewall also runs a Secure Shell (SSH) server so we can manage lab systems from the Internet. For this test we configured a second Linux guest to run the SSH software, and configured the firewall to pass incoming SSH traffic onto our SSH guest server via a virtual, gigabit-speed NIC.
Using virtualised networking, if the destination were another guest, the data would go via a virtual NIC and never touch our LAN. If the destination was on our lab LAN, the connection would be completed via a normal NIC.
We also migrated a guest that had previously been created on a twin-processor system running VMware's mid-range GSX Server. This guest was configured with a Perl/Web-based intranet application.
Such migrations are typically done using FTP or a CD-ROM writer to copy the guest's files from the original server to the replacement. We needed to make a few adjustments to the guest's IP settings and the ESX configuration files, but the redeployment took only minutes.
Price: £2,450 + VAT for two CPUs; £9,700 + VAT for eight CPUs
reader comments