Installing VMWare GSX Server

In the first article in this series, you learned about some of the key concepts and theories of virtual computing. With the basics now sorted, it’s time to get on to the fun part – working with virtualization software. In this article, we’re going to install one of the most popular options out there – VMWare’s GSX Server.

As this is probably your first installation of the GSX Server (and because in future articles we’ll be creating virtual machines and playing with them), I believe you might want to install GSX Server on a test computer, not a production one…

GSX Server uses the second approach to virtualization, discussed in my last article. Specifically, this means that it is installed as a normal application on top of an underlying operating system referred to as the “host” system.

Therefore, the first step of the installation process is to decide which operating system you are going to use as your host system. You can install GSX Server on a host machine running any version of Windows 2000 or Windows Server 2003, and even on Linux systems. For the purpose of this article, we’ll install GSX Server on a computer running Windows Server 2003 Enterprise Edition.

The hardware requirements for the host machine are relatively easy to fulfill. You need an x86-based machine with up to 32 processors and between 512MB and 64GB of RAM. Each processor has to be at least a Pentium II (or an AMD Athlon processor), and run at 733Mhz or faster. You should also have at least 130 MB (Windows), or 20MB (Linux) of free hard drive space for the server, and 1GB of space available for each virtual machine.

Downloading the appropriate files from Vmware

The next step is to download the GSX Server software from the VMWare Web site. On the download page of VMWare, scroll down to VMWare GSX Server 3.1, and choose either “Evaluate,” (to download the evaluation version), or “Download” to purchase the program (Figure 1).

According to VMWare, the only limitation of the evaluation version is time-related: it expires after one month.

Figure 1: WMware Download page

Next, choose the appropriate version for your host operating system – for the sake of this article, Windows. The download page for Windows VMWare offers three different installer files: the server, the Windows client package, and the Linux client package (Figure 2). The server will allow you to install GSX server and to access it either interactively through the console, or (eventually) remotely through the Web Management Interface. The client packages will allow you to install remote administration consoles on other computers running either Windows, or Linux.

Figure 2: VMware download page for Windows

Download the installer files you need, according to the operating system running on your host machine, and on the workstations you want to use for remote access. For example, I intend to use exclusively Windows clients for remote access, so I would download the server (currently VMware-gsx-server-installer-3.1.0-9089.exe), and the Windows client package (currently

Starting the Installation

Double click on the Master installer to start the installation of the Server. The Master installer extracts the installation files, and starts the installation wizard (Figure 3).

Figure 3: GSX Server Installation wizard

Click Next, accept the End User License Agreement (EULA), and click Next again (Figure 4).

Figure 4: VMware End User License Agreement (EULA)

On the next screen, you are asked to choose between a Complete installation, and a Custom one. (Figure 5).

Figure 5: Choose installation type

For a first installation, it is usually safer to choose the “Complete” option. However, for the time being, we want to choose the Custom option because it will allow us to see the different features that will be installed by the wizard, their sizes, and their uses.

Exploring the Features of the Master Install

Select Custom instead of Complete, and click Next. The Custom Setup Window shows the different features included in the GSX Server Master Installer: two Server features, and two client features. Clicking on a feature highlights its name in the left part of the window. At the same time, a fast description of the feature, and the amount of storage required for its installation appear in the right part of the window. (Figure 6).

Figure 6: Custom Setup Window

The first Server feature is the VMWare GSX Server itself. This feature requires only 47Mb of storage space, and is the only one really needed to create and configure virtual machines if you want to access it exclusively through the local console.

The second Server feature is the Web Management Interface that allows users to manage the virtual machines from a browser. This feature needs 23 MB of hard disk space, and requires that IIS, and either the Netscape Navigator 7.0, or the Mozilla 1.x browser be installed on the host machine to function.

The two client features are scripting tools that use either Perl or COM for remote management of the virtual machines. They require 14 MB, and 2932 KB of hard disk space respectively.

The Custom Setup Window also has two additional options to allow users to customize their installation. The Browse button allows the user to install GSX Server on any volume of the physical machine (Figure 7).

Figure 7: Install on any volume of the physical machine

The Space button (at the bottom of the Window between Help and Back), checks each volume on the physical machine to see whether they have enough disk space available to install the features selected, and shows the results of this check in a different window (Figure 8).

Figure 8: Checking disk space

Finally, a red cross in the icon on the left of a feature indicates that it will not be installed. At the same time, the feature description in the right part of the window will indicate that the feature requires 0Kb of storage (Figure 9).

Figure 9: Management Interface will not be installed

To include the feature in the Custom install, just click the icon, and choose the white rectangle with the picture of a disk. Clicking on the Help button will show you the icons corresponding to each available install state (Figure 10).

Figure 10: Custom Setup Help

Finishing the GSX Server Installation Process

Now that you have explored the four different features that will be installed by the wizard, their sizes, and their uses, click on Back. This will bring you back to the previous window, where you will select Complete instead of Custom, and click on Next to continue the installation.

If Internet Information Services (IIS) is not installed on your system at this point, the wizard will give you the choice between exiting the wizard, installing IIS and restarting the installation, or installing GSX Server without the Web–based Management Interface (Figure 11).

Figure 11: IIS is not installed on the physical machine

Now, you are currently installing GSX Server for learning and testing purposes, not for production purposes. So if you get this alert, I suggest you exit the setup, install IIS on the physical machine, restart the setup, and redo the previous steps until you see the Setup Type window shown back in Figure 5.

If IIS is installed, clicking Next will take you a window where you’ll be given the opportunity to change the directory in which GSX Server will be installed. The default directory is C:\program Files\VMWare, and each feature is installed in its own subdirectory:

Server feature: C:\Program Files\VMware\VMware GSX Server
Management Interface: C:\Program Files\VMware\VMware Management Interface
COM scripting tool: C:\Program Files\VMware\VMwareVmCOM Scripting API
Perl scripting tool: C:\Program Files\VMware\VMwareVmPerl Scripting API

Accept the default values, or pick the directory of your choice on a local drive and click Next. You’ll be given a last chance to change the choices you have made up to this point (Figure 12).

Figure 12: Last chance to make changes in the installation settings

If you want to make any changes, click the Back button until you reach the screen corresponding to the changes you want to make. Make your changes, and then redo all the steps until you come back to the window shown in Figure 12.

Once you’re satisfied with the selected settings, click Install. The installer generates the scripts, searches for previous installations of the application, and installs the different elements of the software.

If the CD-ROM Autorun feature is enabled on your host machine, the Installer will ask you if you want to disable it (Figure 13). Personally, I prefer to disable it because I find that it can create inconveniences when several virtual machines are running at the same time.

Figure 13: Disable the CD-ROM Autorun feature of the host machine

Note, however, that if you click Yes the feature will only be disabled after you reboot the host machine.

Whether you click Yes or No, the Installer will continue its work until it finishes the installation. At this point, you will see two new icons on your desktop: one named VMWare Virtual Machine Console, and one named VMWare GSX Server Console. You will also see the final window of the Master Installer (Figure 14).

Figure 14: Final window of the Master Installer

Click Finish to complete the installation. If prompted to reboot the host machine, do so. You have completed the installation of VMWare GSX Server on your host machine. Congratulations!

This finalizes this second article in this series on virtualization. I hope you had more fun with this one than with the first one. With the installation business out of the way, things will only get better from this point forward.

Welcome to the World of Virtualization

If you read technical magazines regularly, you’re bound to have seen at least one article about virtualization in the past six months. Virtual data centers, virtual disaster recovery facilities, virtual servers, virtual switches and virtual networks seem to have become almost omnipresent.

Even with the abundance of coverage that virtualization receives in the press it is often still difficult to learn the basics of its various purposes and benefits. What is virtualization? How can virtualization really help in business or academic environments? What are the benefits of going this route? These are all questions that need to be answered before you begin digging deeper into specific products or technologies.

The purpose of this series of articles is to approach virtualization via its most basic of components, namely virtual machine systems. Ultimately, we’ll use this introduction as a stepping-stone to work our way to some of the more complicated aspects of virtualization.

Definition and History

Virtualization – sometimes referred to as virtual machine systems technology – makes use of a software layer to enable multiple, diverse, and independent operating systems to run simultaneously on a single set of hardware.

IBM first developed virtual machines in the 60s. At the time, their main goal was to correct some of the limitations of the company’s OS 360 multi-programming operating system. IBM’s virtual machines were basically fully protected, isolated copies of the underlying physical machine’s hardware. A software component ran directly on the “real” hardware. This software component could then be used to create multiple virtual machines, each of which could run its own operating system.

Popular during the 60s and 70s, virtual machines practically disappeared during the 80s and 90s. It was not until the end of the 90s that they truly came back on the scene, not only in the traditional area of servers, but also in many other areas of the computing world.

The Structure of Virtual Machine Systems

Current virtual machine systems are essentially built on the same theoretical grounds as their IBM ancestors. A thin layer of software – the virtual machine monitor (VMM) – is interposed between two of the layers of a computer (Figure 1) to create a virtual machine environment.

Figure 1

The VMM creates a layer of abstraction between the physical machine’s hardware and the virtual machine’s operating system. The VMM then manages the resources of the underlying physical machines (referred to as the host machine) in such a way that the user can create several virtual, “guest” machines on top of the physical host machine. The VMM also virtualizes the physical hardware of the host machine and presents to each virtual guest machine a hardware interface that is compatible with the operating system the user chose to install on it.

Each of the guest machines is composed of a combination of the host machine’s hardware and the VMM. The layer of abstraction created by the VMM gives each guest machine the illusion of being a complete physical machine, and fools each guest operating system into believing that it is running on the normal hardware environment it is used to.

How Virtual Machine Systems are built

There are currently two main approaches to the building of virtual machine systems. In the first approach, the VMM sits between the hardware of the real machine and the guest systems (Figure 2). This approach was used in the 60s by the original IBM virtual machine systems, and is also used nowadays by modern implementations like VMWare’s ESX Server.

Figure 2

In the second approach, the VMM is installed as a normal process between the underlying real operating system, called the host system, and the virtual machines created by the users (Figure 3). This approach is currently used by some of the most popular virtualization software, like VMWare’s Workstation and GSX Server, and Microsoft’s Virtual PC 2004 and Virtual Server 2005.

Figure 3

Common characteristics of Virtual Machines Sytems

Regardless of the approach used to build them, virtual machine systems share a certain number of necessary characteristics: faithful reproduction of the guest operating system’s normal environment, adequate performance, isolation between the guest machines (and between each guest and the host), centralized control of the host’s resources, and encapsulation of the virtual machines.

The main goal of virtualization is to enable applications and guest operating systems to run on hardware, or host operating systems with which they would normally not be compatible. To attain this goal, the VMM must first reproduce the system it is emulating as faithfully as possible.

Eventually, the VMM must be able to map into software parts of the original hardware architecture that no longer exist. If the virtual machines are used to test prototype and beta software, the VMM might even have to map into software parts of system architecture that do not exist yet.

The VMM must also be able to provide the guest operating systems and applications with an environment that is essentially identical to the original machine so that any program running on a guest machine will have the same behavior and the same effects as the same program running in its original environment.

The VMM represents an additional layer of software between the hardware, or the host operating system and the guest operating systems and applications. This additional layer is likely to add overhead to the system, and affect the performance of the software running on the guest machines. To be useful, however, the virtual machine system must exhibit a performance level comparable to that of the original real machine.

If the VMM really reproduces faithfully the real system it is emulating, and if the environment provided by the VMM is essentially identical with the original machine, the definitions of the two interfaces, real and virtual, should match, and the performance of the virtual machine should hardly suffer from the virtualization.

The first modern virtual machines systems implemented on common Intel-like computers, used to suffer performance losses sometimes as high as 50%. Nowadays, however, there is hardly any difference between the performances of real and virtual machines. At the end of last year, I personally tested the performance of virtual machines installed on a VMWare GSX server, and found it absolutely comparable to the performance of a “real” physical machine. In many cases, the virtual machines actually performed better than the physical machine.

Virtual machine systems must allow applications hosted in the different virtual machines to run concurrently without interfering with each other. To achieve this goal, the VMM must be able to completely isolate the virtual machines from each other and from the real machine.

This isolation must be twofold. On one hand, the applications and data of each machine, virtual or real, must be out of the reach of all the other machines. On the other hand, the VMM must be able to ensure that the use of host system resources by one virtual machine does not have a negative impact on the performance of other virtual machines. This means that the VMM must constantly have complete control over the resources, such as memory, peripherals, I/O, and even, eventually, processor time, used by the virtual machines. It must be in charge of allocating resources, and it must be able to dynamically allocate and remove them as needed.

Finally, virtual machine systems must encapsulate all the software of each virtual machine. This encapsulation enhances the isolation of the virtual machines from the host machine. It also allows users to easily migrate virtual machines from one hardware platform to another, different one. This allows users to “save” the state of a virtual machine at a certain moment in time, change the configuration of the machine, for example install new applications or security patches, test them, then return the virtual machine to its original state of it.

Final Thoughts

This finalizes this first article on virtualization. I know it is rather theoretical and dry beginning, but I believe in having at least a general idea of how things work before using them 🙂

In the next article, we’ll start getting our hands dirty, and installing virtualization software – that’s where the real fun begins!