Timothy
Parker Consulting Incorporated
|
|
|
|
VMWare GSX Server 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 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. |
|
Send mail to
tparker@tpci.com with
questions or comments about this web site.
|