Think of what you could do if you had a mainframe computer at your disposal. What feature would mean the most to you as a network administrator? To a lot of network admins I know, the most valuable feature is the ability to completely isolate processes from each other. With a mainframe, you can even run multiple operating systems on a single machine and keep those operating systems completely separate from one another, even though they all share the same hardware infrastructure.
You might not have a million dollars for an IBM mainframe, but you can get some of those mainframe features with VMware GSX Server (for $2,549 U.S.), which allows you to virtualize operating systems into virtual machines (VMs). The VMs actually exist on top of another operating system that’s already running on a server. Each VM runs a guest operating system. The host operating system is the one that’s actually running on the physical computer. You can use the GSX Server for the following:
- Server consolidation
- Testing new configurations
- Fault tolerance
- Accelerated remote server deployment
- Setting up student machines in training centers
There’s a lot to like about VMware GSX Server; when you compare the price and what you get for your buck to a standard mainframe, you quickly realize how valuable VMware GSX Server is.
Many companies run server consolidation projects to simplify the management of computing resources by bringing business-critical applications, services, and data onto fewer, more powerful, computers.
The problem with many server consolidation projects is that some mission-critical applications don’t play nicely with one another. For example, you might have a powerful server with fault-tolerant power supplies, network interfaces, and disks. You want to put Exchange 2000, SQL Server, and some custom reporting software that you’ve developed in-house on this server. The problem is that Exchange 2000 and SQL 2000 can have problems getting along together, and the in-house application only runs on Windows NT 4.0.
This is a common scenario and it can defeat your server consolidation plan. With GSX Server, you can place all of these applications on a single physical machine by running three separate VMs. You can create two Windows 2000 VMs running Exchange and SQL and one Windows NT VM running your in-house reporting software.
Testing new configurations
Developers need a sandbox to test new applications. The problem you have as a network administrator is providing enough computers in a networked environment for all of the developers. They’re working with new code, and you don’t want them all to share the same server because one developer’s code will bump into another’s. You could buy new computers dedicated to testing, but the cost can be burdensome.
Another task that befuddles administrators is testing new server applications and service packs to see how they’ll get along with existing applications and services on the production server.
You can use GSX Server to install multiple instances of the operating systems you need. You create a base image that mirrors your production environment. Then the developers can test their applications in a real-world, live environment, and you can test the effects of service packs, new services, and hotfixes on a VM that mirrors your production server. You can even take down your production server and have the VM replace it for a real trial by fire. If the configurations pass muster, you can update the actual server and save the VM as a backup.
The administrator’s Holy Grail is uptime. When a server goes down, you need to bring the services up again as soon as possible. Good hardware with redundant components can go a long way, but if a fire consumes the building or the sprinklers destroy your server, all that redundant hardware won’t help.
With GSX Server, quick recovery from these types of disasters is easy. All you need to do is install GSX Server on a live machine and then copy mirror images of your production servers. Your VM images will have applications and services configured just like you had them on the live server. The VMs can stand in until you bring the other servers back online, or you may choose to run mission-critical services in GSX VMs. The VMs are stable and reliable, so it’s worth giving it a try if you don’t have the resources to replace all the physical servers.
Quick remote server deployment
Geographically dispersed organizations have a special challenge when they need to roll out new servers at remote offices. A remote office might need a replacement or upgrade to their mail, database, or Web servers. An office at another site may have grown to the point where you need to place a domain controller on site. Often, an experienced IT person from the home office must travel to and from the remote site to accomplish these tasks, leading to loss of productivity.
With GSX Server, you can copy images to the remote office over the WAN link or mail them on DVD. If the GSX Server is already installed on a machine at the remote office, it’s relatively simple for a novice administrator, with your written or verbal instructions, to copy the image to the GSX Server. Then you can start the VM remotely or have the user start the machine locally. And when you need to add or replace servers, just send another image and fire up another VM.
GSX Server can be a real boon to computer training centers. Conventional disk-imaging procedures that deploy over the network are effective but can be time-consuming. Sometimes hardware differences among machines can lead to an inconsistent deployment. The network resources required to copy images to an entire classroom can also be a problem. GSX Server solves this problem by allowing you to create master images that can be copied to locations on the GSX Server disks, without using up precious network bandwidth. All the VMs present the same hardware environment to the operating system, so you don’t need to worry about hardware incompatibility.
Students make many errors while learning, and it’s often a challenge to figure out what went wrong. You can use a special VM feature called undoable disks. When students use an undoable disk, no changes are actually made to the images of the operating systems they’re working with. Instead, all the changes are saved to an undo log file. Students can make changes, restart the operating system within the VM, and continue to make changes. If the student runs into a catastrophic problem, he or she can turn off the VM and tell GSX Server not to save the changes, and the VM will be returned to its original configuration. The days of reinstalling and reimaging are over.
Hardware requirements for GSX Server vary according to what you want to do, but some general guidelines can help you get started. Hardware requirements include:
- Hard disk
Processor and memory
GSX Server runs on Pentium-class processors. I recommend you get the fastest processor you can afford. GSX Server can take advantage of multiple processors, and you can assign VMs to a particular processor on the machine. If you have four processors on a machine, let the host operating system use one and create three VMs that can have their own processors.
While you can use virtually any Pentium-class processor, the new Athlon XP chip is not supported. Also, if you’re interested in multiprocessor machines, you’ll have to steer clear of dual Athlon configurations.
The server should have a considerable amount of memory. GSX Server supports up to 4 GB of RAM. You need enough memory for the host operating system and for each VM. Each VM can take advantage of a predefined chunk of physical RAM. For example, if you want to run Exchange 2000, you can dedicate 512 MB of RAM to its VM. The minimum memory requirement for the physical server is 256 MB. The maximum amount of memory you can dedicate to each VM is 1,024 MB (1 GB).
Hard disk and networking
The core GSX Server application and remote management software (discussed in a later section) requires about 150 MB of hard disk space. The major disk space requirements are for the VMs. You can create virtual disk drives of up to 4 GB in a VM, and you can create multiple virtual drives. However, the virtual drives only take up the amount of disk space they require; as you install applications or files, the virtual drive grows with the needs of the VM, up to the maximum size of the virtual drive. Determine how much disk space you want to dedicate to each VM so you can provision the server with the appropriate size and number of drives.
If you want the VM to interact with other computers on the network, you’ll need an Ethernet adapter. You can install GSX Server on a machine connected to a non-Ethernet network architecture, but it won’t be able to communicate with other machines on the network. However, you can create a virtual network on the GSX Server itself, and all the VMs will be able to communicate with each other.
Software requirements and support
GSX Server supports a number of operating system environments. Support is divided by the following:
- Host operating system
- Guest operating system
Host operating systems
GSX Server can be installed on the following operating systems:
- Windows 2000 Server and Windows 2000 Advanced Server SP1 or SP2
- Windows NT 4.0 SP 3 and above
Note that you cannot install GSX Server on Windows NT 4.0 Workstation or Windows XP. As with other server applications, you need to install GSX Server on a server operating system.
Guest operating systems
You have many choices when it comes to guest operating systems. Microsoft operating systems supported by GSX Server include the following:
- MS-DOS 6x
- Windows 3.1
- Windows 95/98/98SE/Me
- Windows NT 4.0 Workstation and Server
- Windows 2000 Professional, Server and Advanced Server
- Experimental support for Windows XP
I installed Windows 3.1, Windows 95, Windows NT 4.0 Server, Windows 2000 Advanced Server, and Windows XP on the same GSX server. All the VMs ran flawlessly and were able to communicate with one another and with other computers on the network. Although the Windows XP support is experimental, the XP VM under my testing has run without incident for over a week. GSX Server will be updated in the near future to support Windows XP VMs.
Linux versions supported by GSX Server include:
Of these, I have only tried Red Hat 7.0, but I found that it worked great.
Managing GSX Server
GSX Server provides several options for managing the servers, including:
- Local and remote consoles
- The management Web page
- Terminal servers
The local and remote consoles
The GSX Server can be managed using a console interface that looks a lot like the VMware Workstation interface. The local console allows you to:
- Install new VMs
- Start and stop VMs
- Configure GSX Server parameters
New VMs can be installed at the local console. This procedure is very similar to the one used in VMware Workstation. VMs can also be started and stopped at the local console, but this isn’t the preferred method because if you start a VM using a local console, you may not be able to manage it remotely. Since the real beauty of GSX Server is found in its remote management capabilities, refrain from using the local console to start and stop servers. You can configure how much memory (virtual memory pool) can be used by all the VMs at the local console.
The remote console works very much like the local console, except that you cannot configure the amount of memory used for the VM pool using the remote console. The remote console works a lot like a Terminal Services client that allows you to work in the guest operating system from a remote computer. Unlike a Terminal Services client, you can start, restart, and stop a VM from a remote console. You can also install a new VM from the remote console.
|Selecting a VM at the remote console|
You’re presented with a list of VMs when you start the remote console (see Figure A).
|You can view and manage a VM using the remote console.|
If you select a VM that is already started, the console will take you to the running operating system, as shown in Figure B.
You can open multiple remote consoles so that you can manage multiple VMs at the same time.
The management Web page
The management Web page (see Figure C) allows you to start, stop, restart, and install VMs using a browser interface. Unlike the remote management console, you don’t manage the actual VMs from the browser. The Web-based interface does provide you with information about which VMs are running and how long they’ve been up. The page refreshes automatically so that you have accurate status information about the running VMs.
Installing the remote console
You can install the remote console from the management Web page, which is convenient because you can avoid creating extraneous shares on the GSX Server machine.
Using Terminal Services to manage the guest operating system
If you’re running an operating system in a VM that also has terminal server running, you can use the Terminal Services client for that operating system to connect to the VM. For example, if you have a Windows 2000 guest operating system on the GSX Server and you have installed Terminal Services on Windows 2000, then you can use the Terminal Services client software to connect to the guest operating system. You might find it a bit easier to manage the VM using a terminal server because performance seems a bit better. However, if you choose to restart the VM, you won’t have as much control over the boot process as you would with the remote console.
VMware GSX Server allows you to create multiple VMs on a single physical server. You’ll find lots of advantages to running multiple VMs on a single GSX server, such as server consolidation, fault tolerance, disaster recovery, and the ability to create a real-world testing environment. You can manage the VMs using the local console, remote console, and management Web page. VMs look and behave just like actual physical machines and are easy to back up and restore by copying a very small number of files.
If you think VMware GSX Server might have a place in your organization, check out the VMware Web site for more information.
Send us your comments
Would you like to know more about using VMware products? If so, send your requests to Jack Wallen, Jr.