Linux users are most likely familiar with VMWare’s products. The GSX Server is the latest update to VMWare’s product line. GSX Server is designed to reside on a server (Linux powered, of course) and provide application services to clients on the network. GSX Server is not the same as VMWare’s product for workstations deployed for an entire network, but a different approach to providing similar services. The design goal for GSX Server is to provide some standard applications (even on multiple operating systems) that are usually run in multiple instances across the network such as news readers, file servers, programming tools, and so on, on a single host. GSX Server is not an inexpensive package at $2,499 for the basic package, so what do you get for this kind of investment, and is it worth the money?

GSX Server runs on top of Linux. There are several supported versions, including RedHat 5.X and later, Caldera OpenLinux 2.2 and later, SuSE Linux 6.X and later, and TurboLinux 6.0. VMWare is working on a version for Windows NT and Windows 2000, but it isn’t even in beta yet. The server hardware is obviously designed for Intel or AMD, and a fast processor or multiprocessor is recommended. VMWare suggests at least a 400 MHz CPU with 256MB RAM, but on most networks with a dozen or more clients you’ll want more horsepower and more RAM than that. Apart from the Linux OS you will also need to install X, and some of the glibc libraries are required for the GSX Server software. The GSX Server can run in a headless mode (no keyboard, mouse or monitor) ideal for rackmount servers providing for network-wide support.

The clients for GSX Server are either Linux or Windows machines. The remote console application included with GSX Server can be used on these platforms, or you can use a browser. Both Internet Explorer and Netscape Navigator current releases worked well with our setup. The clients need to have a reasonable CPU (VMWare recommends 266MHz or faster, which seems realistic although a little slow for some purposes) and at least 64MB RAM. We experienced swapping with the Linux clients with only 64MB RAM when under medium to high simulated loads, but the problem didn’t occur with 128MB based systems.

The MultipleWorlds aspect of GSX Server allows for multiple operating systems to be hosted on the server, and to host applications accessible by the clients. Supported host operating systems for MultipleWorlds cover Linux, DOS, Windows and Windows NT flavors. Virtual networking for these operating systems can be through TCP/IP or IPX/SPX, with support for NFS and Samba. Virtual disks are easily created for client applications, and come in three flavors including persistent (changes are saved after each session), nonpersistent (changes are lost), and undoable (allows saving or discarding of changes at the user’s control). A suspend-and-restore feature allows for a snap-shot of a current session in one of the MultipleWorld environments, with quick reload at any future time. Cut and paste as well as the usually copy and drag-and-drop attributes are permitted between all the environments supported by GSX Server.

We tested GSX Server on three different hardware servers to gauge response to network usage: a single CPU 800MHz AMD Athlon with 256MB RAM, a dual-750MHz PIII with 512MB RAM, and a 1.5GHz P4 with 512MB RAM. The software performed well on all three platforms, with no problems from the AMD or Pentium 4 machines. The RAM requirement on the server has to be able to handle not only the server’s Linux platform as well as the GSX Server software, but also the virtual platforms created by the clients. On larger networks, a multiprocessor machine with well over a Gigabyte of RAM may be a minimum requirement. Our test network was a 100Mbps Ethernet setup with twenty clients, all running scripts to simulate variable loads.

Disk requirements for GSX Server are not too bad, with the basic software load requiring 30MB. On top of that, you need to add space for each client application and session, which really translates to about 1GB minimum of disk space for a small GSX Server setup. For larger networks with multiple applications served, more disk space will be needed. Fortunately, disk space is inexpensive.

So much for the details. In use, GSX Server is relatively easy to install once you have a server with enough horsepower and RAM. The installation and configuration process was a little tricky because we were working with pre-shipping software with preliminary documentation, but this will likely be eased in the shipping product. A set of wizards make the configuration easier, but the process is still not trivial as you have to create a virtual machine, load the native operating system, clone it for virtual machine use, then configure the environment. We spent well over a day getting each of our servers set up properly, although we did run multiple operating systems.

The whole idea of GSX Server is to provide client machines on the network the ability to launch an application in any one of the supported Windows, DOS, or Linux operating systems, creating a virtual machine on the server, accessible through the network to the client. We set up many applications, at least two under each of the primary operating systems we loaded (RedHat Linux, Windows 98, Windows NT 4.0, and DOS) and used the mixed Windows and Linux clients to pound on the server with scripted requests for operations.

With a low level of scripting (standard user actions) on the twenty clients, the 800MHz AMD machine with 256MB RAM handled the load, although it did start to slow down at some points due to swapping. The other two, faster, servers kept up well. When we doubled the script rate, essentially simulating double the number of users, the P4 started to experience a slowdown in requests, while the dual 750MHz system continued to handle the load. In fast script mode, essentially simulating four times the number of users (80 users on the network), all three machines were gasping for breath. Even the fastest machine was slow, with delays for requests of several seconds to a minute. Obviously, more horsepower and RAM is needed to provide the server the ability to handle 80 clients. We did try load sharing across the network with the three servers working in tandem, and clients accessing only one of the three servers, and that helped but still caused problems for the slowest machine. The moral is obviously that the GSX Server has to be a top-end, maxed out platform for anything but casual use by medium sized networks.

A common question is how the GSX Server differs from VMWare’s usual workstation virtual machine software, VMWare Workstation. Primarily, as noted elsewhere, GSX Server is a server-oriented system, moving the VMWare software to a network deployed server instead of on each user’s workstation. This allows both headless operation in a rack setup, as well as access from any number of clients. GSX Server also offers a scriptable API that is lacking in the Workstation version, as well as the Web-based management interface. As a final feature, GSX Server allows access to up to 64GB of virtual disk capacity, much more than Workstation can.

VMWare also offers the ESX Server product, which is quite similar. The differences between ESX and GSX are that GSX is designed for machines with one to four processors, while ESX is for one to eight processors. The implementations are different, too: GSX runs on a departmental server as an application, while ESX is a dedicated operating system and virtual machine server on its own. GSX supports more hardware configurations, but has to share the load with other applications and tasks on the server. The ESX server is a totally dedicated solution with more advanced management capabilities.

The primary role of the GSX Server is not as a replacement for multiple VMWare workstation products, although it can act in this capacity. Instead, VMWare sees GSX Server as a product allowing you to move several existing server applications onto one machine, each application running inside a virtual machine on that server. For example, if you have a Web server on one machine, an SMTP server on another, an application on a third, and so on. Even if these are all under different operating systems they can be consolidated on a GSX Server, all running as headless servers on one machine. In this role, GSX Server excels, as long as the horsepower and RAM is available for all the servers to be properly serviced.

Client behavior was very good, and it was undeniably fun to run Windows, DOS and Linux applications from a single client, cutting and pasting between them. You could do the same thing with VMWare’s workstation product, but the idea of the GSX Server is to cut down on multiple instances of commonly used applications. Accessing virtual machines from the clients is trivial.

The remote management console is a neat feature provided as part of the GSX Server. It allows an administrator to monitor and manage GSX Servers across a network, even when there are many GSX Servers running in a server pool. The interface is clean and workable, and can run under a Web browser of KVM console.

So, the point of GSX Server is to provide application support for multiple applications, and potentially multiple operating systems, across a network, cutting down on total resource requirements. With that as a goal, VMWare has succeeded very well with GSX Server. The software performed perfectly, with only a few glitches in our testing run, and always at high loads. As long as you can configure a server or server pool with enough resources to handle the client demands, GSX Server can help you deploy common applications to a whole network. Is it worth the money? That will depend on the network and requirements. Certainly, if you are running a Linux network and need to support Windows applications, the cost of GSX Server may well pale compared to the deployment costs of Windows and the applications themselves. VMWare does make GSX Server available for a 30-day trial deployment from their Web site, so it is a good idea to try before you buy. As long as you have the hardware to properly support GSX Server , we suspect you’ll want to keep it around afterwards.

GSX Server
3145 Porter Drive
Building F
Palo Alto, CA 94304 USA
Fax: 650-475-5001

Summary: Multiple operating systems and multiple applications across a network, using virtual machines. It works, and works well, but requires a really good server setup.