GSX Server provides smooth, stable server virtualization

The first release of VMware Workstation in 1999 marked the birth of simple system virtualization on the x86 architecture. In the years since, VMware has matured, adding significantly to its product line with GSX Server, a virtualization platform that relies on a host OS.

Virtualization software simplifies computing infrastructure by partitioning and isolating servers into virtual machines, each of which can run its own OS and applications. Virtual machines running under VMWare’s Workstation product can be accessed by any other system via the network, but access to the server console is limited to the workstation running the application.

GSX Server, on the other hand, runs as a daemon process on a host server and thus does not have any console-location constraints. Using a modified, integrated VNC (Virtual Network Computing) server, any virtual system running on the host is accessible to any VMware console client on the network, regardless of guest OS. Moreover, console access is not limited to a single connection, as multiple users can connect to a single virtual system console simultaneously.

The main thrust of the GSX Server line is not necessarily server consolidation. Although running production servers under GSX is certainly possible, the virtual systems are subject to limitations that can reduce their effectiveness in that capacity. For development and quality-assurance purposes however, GSX Server performs admirably.

With the release of GSX Server 3.1, VMware has added support for 64-bit host operating systems. In practice, this means there are 64-bit drivers present, permitting installation on x86_64 platforms. Officially, VMware supports 32-bit guest OSes on 64-bit host servers but not 64-bit guest OSes, so we’ll have to wait a while to run x86_64 code in a VMware guest operating system.

In the lab, I installed VMware GSX Server 3.1 on multiple host systems running Red Hat Advanced Server 3.0, both i386 and x86_64, and 32-bit Windows Server 2003. The installation under Linux is straightforward, requiring only a single RPM (Red Hat Package Manager) package and functions under v2.4 and v2.6. The Windows installation uses a standard installer.

 Next, I installed the MUI (management user interface). The MUI runs a separate SSL-enabled Apache instance on the host server, providing the browser-based server-monitoring application. The application provides at-a-glance virtual server operational status, including CPU and memory resources in use. It also provides links to manage the virtual servers configuration or access the console.

On my workstation, I installed the VMware console application, which is nicely linked from the server management page. Once the console was installed, I could directly access the console of any virtual server, configure virtual server settings, and create new virtual servers. One great feature is the concept of system snapshots, which permits you to take a snapshot of a guest system, modify the system, and quickly revert to the snapshot, reversing any changes. VMware also offers Virtual Center, a Windows-only service that permits consolidated management of multiple VMware host servers and their guest servers.

The virtual server creation process is simple. Once the guest OS has been defined, the guest server’s disk is configured. A virtual disk is limited to 256GB and can be represented as either an IDE or SCSI device. In my testing, I routinely saw disk I/O in the 45Mbps range on virtual servers, with the host server clocking that disk at a healthy throughput of 70Mbps. Alternately, you may configure raw disk devices as virtual server disks.

You can allocate RAM to virtual systems as needed, up to the limit configured for that server. Device access for virtual servers is quite extensive, as serial, USB, and sound devices can be passed through the host to the virtual server. Additionally, you can configure network access for virtual servers as a simple bridge of the host NIC in a NAT configuration or host-only, which limits the virtual servers’ network access to the host server only. I ran all the servers in bridged mode, each allocating a unique MAC (media access control) address. Network throughput to virtual servers is not wire speed, but it is solid, with a Linux virtual server showing 500Mbps raw TCP throughput to external systems. The host OS showed 970Mbps throughput.

DVD and CD-ROM devices can be presented to the virtual server as the physical device in the host server or directly from an ISO image. This is very handy, as server installations can be conducted without requiring physical access to the server. An ISO of Windows Server 2003 or the Red Hat boot image will boot without problem, and the subsequent virtual server OS installation is quite fast. PXE (Preboot Execution Environment) support is also present.

There are no hard limits to the number of concurrent virtual servers outside of available RAM and disk space, and I had no trouble running four to five concurrent virtual servers on a dual 2.8GHz Xeon server with 4GB of RAM. Individual server performance can definitely suffer when other virtual servers are heavily engaged, but at no time did any virtual server suffer systemic problems. For host servers running multiple processors however, there is a caveat; if Intel processors are used with hyperthreading, a guest OS can only use a single CPU thread rather than the entire CPU. On a four-CPU system, this limits each guest OS to 12.5 percent of the host OS CPU resources. Therefore, it is generally best to disable hyperthreading on VMware host servers.

Overall, VMware’s GSX Server provides good bang for the buck. In a development or lab environment, it can quickly become an indispensable tool to quickly test new software or configurations; I know it has for me.