After you install VMware GSX Server 3.1 on your Windows or Linux server, you're ready to start deploying virtual machines to supplement your production environment. Here's how you go about it.
With VMware GSX Server 3.1 deployed on your Windows or Linux server, you can start creating and using virtual machines to support your lab environment or supplement your production environment. Either way, you'll find virtual server deployment pretty straightforward. In this article, I'll go over some things you should consider as you begin to deploy virtual machines on your VMware GSX Server.
GSX supports practically any x86-based operating system, including DOS 6.22, Windows (all the way back to Windows 3.1 and up to Windows Server 2003), a ton of Linux distributions, NetWare, various versions of FreeBSD, and even the x86 version of Sun's Solaris. VMware's site provides the exact details on the supported operating systems, including which Linux distributions and versions they support. However, if your distribution of choice isn't listed, it doesn't mean that it won't work. Do a little digging and use VMware's forums to get help. In some cases, a particular distribution or Linux kernel can't work with VMware, but these instances are pretty rare.
One thing to keep in mind is that 64-bit operating systems are not supported by VMware GSX Server. So if you had your mind set on testing the 64-bit edition of Windows Server 2003 using VMware, you're out of luck!
RAM and storage requirements planning is a critical step in the virtual server deployment process. To learn how to properly size your overall VMware GSX Server, see my previous article, "Installing VMware GSX Server."
Clients running inside VMware GSX Server have some limitations you should know about. On the memory front, each client is limited to 3.6 GB of RAM, no matter how much RAM is in the host server. The GSX host server supports up to 64 GB of RAM, however, for host machines that can break the 4-GB memory barrier. For non-PAE-enabled machines, the host is limited to 4 GB of RAM and won't be suitable for large-scale virtual server rollouts. Hosts running a 2.2 version of the Linux kernel are further limited; only 2 GB of host RAM can be made available to virtual machines. I wouldn't recommend running VMware on a 2.2 series kernel, especially with the 2.4 and 2.6 kernels widely available and extremely stable.
One area that is confusing is processor use. GSX Server-based virtual servers can have only a single processor inside the virtual machine. The ESX version of VMware currently supports guest machines that span up to two processors in an SMP configuration.
In late 2005, VMware plans to add to ESX Server support for four-processor guest system configurations. ESX will ultimately break the power limitations that keep high-end systems, such as databases and large Exchange stores, from being able to take advantage of the benefits brought by virtualization. That said, people get confused because they think that the whole of GSX can't use more than a single processor. In reality, the GSX installation can use every processor in the system, but the individual clients will never see, or be able to make use of, more than a single processor.
Before you deploy an application on a GSX-hosted client, ask yourself if the application can run smoothly on a single processor. If not, leave the app on a multiprocessor server, or consider using ESX Server instead.
Make sure to consider disk space in your calculations, although you'll quickly find that there are few limits to the different ways GSX virtual servers can access storage.
A virtual machine can have up to four IDE devices (a combination of CD-ROM drives, virtual hard disks, pointers to ISO image files). Virtual disk files are where the meat of the virtual machine resides. An IDE-based virtual disk can be up to 128 GB. If you install a virtual SCSI adapter in your virtual machine, you can add up to seven SCSI-based virtual hard disk files, each up to 256 GB.
You can install up to three SCSI adapters inside a GSX virtual server, providing a total of up to 28 SCSI devices in the virtual machine. You don't actually need a real SCSI adapter, either. You can store the SCSI-based files on a NAS unit on the network or on a fibre channel array. Or, you can actually hang massive SCSI storage units off the GSX Server and use it for your virtual hard disk files. One thing you'll discover is that virtual hardware is very flexible.
For licensing purposes, consider any virtual servers to be real, deployed servers on your network. Just as you need a Windows license for a new physical Windows server on your network, you also need a license for any virtual Windows servers you deploy. Don't forget about the GSX Server itself; it also needs a valid Windows license if you're running atop Windows. So, if you have four virtual Windows servers on your GSX Server, you'll actually need five Windows server licensesï¿?four for the virtual servers and one for the GSX host server.
If you decide to deploy a product that uses "per processor" licensing inside a virtual server, you only need a single processor license. For example, if you have a Windows Server 2003 guest server running SQL Server 2000 on a host with four processors, you need only a single processor license, since that's all the guest can use. Of course, if you move SQL Server to the host, you might need to upgrade to a four-processor license, but since the guest operating system has only a single processor, that's all you need to license for.
Installing virtual machines
To start installing a new virtual machine, click the New Virtual Machine button or select File | New Virtual Machine. This starts a wizard that helps to guide you through the virtual machine configuration process. You first need to decide whether you want to start a typical installation or customize your virtual server. A typical installation selects the initial amount of RAM and a few other parameters for your new server, whereas a custom installation lets you select every detail about your new server. Regardless of what you select, you can easily change your server's parameters anytime. For this article, I've selected a custom installation so I can detail as much as possible.
Your first major decision comes on the screen shown in Figure A. Here, you select the operating system that will run inside your new server. I've selected Windows Server 2003 Enterprise Edition for this example.
|Choose the operating system you'd like to install inside the virtual server.|
Next, you need to name your new virtual server on the screen shown in Figure B. I like to name my machines the same as their network/computer names so I can easily work with them. I use the same name for the location to help keep things straight. If you have one or two virtual servers, it's not a big deal, but if you get into a situation where you have a couple dozen machines, it can get pretty confusing after a while. The location field for Windows host installation is the Virtual Machines directory on the drive to which VMware GSX Server was installed. Linux hosts store virtual machine directories in the /var/lib/vmware/Virtual Machines directory.
|Name your virtual machine something easy to remember.|
One feature that GSX sports that is not present in the Workstation product is the ability to make a virtual server private, meaning that only your user account has access to it. This can be useful if you're running a test server that only you should be able to get to. If you want to enable this feature, select the checkbox Make This Virtual Machine Private on the screen shown in Figure C. If, on the other hand, you want any administrator on the host to be able to access the virtual server, uncheck this box.
|Decide who should be able to administer this virtual machine.|
Since each GSX Server-based virtual machine runs in its own user space, you need to decide what account the new virtual machine will use. For this, you have three choices:
- User That Powers On The Virtual Machineï¿?Anyone can still connect to the server as expected, but the actual virtual server runs in the context of the user who powered on the virtual machine.
- Local System Accountï¿?The virtual machine runs under the Local System account. You can enable this option if you're logged in to the host operating system as an administrative user. It's important to note that you can't use this option if you plan to store virtual hard drive files or virtual CD-ROM images on a remote computer.
- This Userï¿?Specify the account under which the virtual machine is to run. This should be an administrative user.
On the screen shown in Figure D, if you select Local System Account or This User, you can also allow the virtual machine to start up and shut down automatically when the host starts up and shuts down. This is pretty useful if you plan to roll out virtual servers in a production environment and you want clean shutdowns of your virtual servers.
|Decide what account context to use for the virtual machine and set startup/shutdown options.|
Every machine needs RAM, but you already knew that. In this case, you carve out a chunk of the host's RAM to dedicate to the virtual machine. Fortunately, VMware is pretty smart and makes some suggestions based on what operating system you plan to use and how much RAM is installed in the host system. In Figure E, 384 MB of RAM is going to be devoted to the new WS2K3 Enterprise installation. My host has 2 GB of RAM, of which 1.76 GB is usable for virtual machines; the host needs some RAM, after all!
|How much RAM should be dedicated to this new virtual machine?|
Because VMware can be used in a variety of environments -- production, development, testing, and more -- the product provides pretty flexible networking options. For example, if you're a developer testing code that could disrupt network communications, you might want to keep sample traffic combined to a sandbox and use the host-only networking type. All four are explained below.
- Bridged networking: This option provides the virtual server with its own IP address from the primary network. It looks and acts just like any other server on the network and can be accessed by clients just like any other server. In fact, unless you look, you can't even tell that it isn't a physical server.
- Network address translation: If you want all virtual machines to communicate via the host's IP address (perhaps you have access to only a single IP address, for example), you can use NAT. This is the same NAT you might use to connect your network to the Internet, and it works the same way. You can still access the virtual machine from other machines on the network, but only by name.
- Host-only network: As the name implies, host-only networking isolates communication on your new virtual machine to just the host. As I stated before, this is particularly useful if you need to do testing that could be dangerous to the rest of the network.
- None: You can also choose no networking at all!
One important point to note: The virtual machine emulates a 10/100 Ethernet adapter for network communications. However, if you have a gigabit Ethernet adapter in the host, your virtual machine will also communicate at gigabit speeds. I learned this after some research into whether or not I wanted a file server to be virtualized. I wouldn't have made this move if I couldn't have enabled a gigabit channel to the virtual file server. For this example, I'll use bridged networking, as shown in Figure F.
|How should your new server communicate with the rest of the network?|
Drivers make Windows do its thing with hardware. In the case of a virtual machine, you still need drivers that provide access to your virtual devices. You configure these on the screen shown in Figure G. In particular, virtual IDE and SCSI drivers make your storage devices work. For your new virtual machine, you always get an ATAPI IDE driver that works with any supported guest operating system.
The SCSI driver, on the other hand, depends on the guest operating system you've chosen to install. The LSI Logic driver works very well with Windows Server 2003, Red Hat Enterprise Linux 3, and NetWare 6.5; the BusLogic driver is used for all other selections. The LSI driver provides better performance but doesn't always work on operating systems other than those listed.
|Which drivers should be used for your new OS?|
With driver selection out of the way, you now need actual space for the new machine. This happens on the wizard's next screen, where you're provided with three options:
- Create A New Virtual Diskï¿?A virtual disk is just a hard disk saved inside a file on the host (or accessible to the host over the network). The great part about a virtual disk is that it can be copied and moved, even with the virtual machine up and running. (This is enabled when you add the VMotion management utility to your GSX software purchase.)
- Use An Existing Virtual Disk -- If you have an existing virtual disk file you want to use, feel free. One common application for this is to create a baseline operating system image and then make a copy of it for use by a new virtual machine.
- Use A Physical Disk -- If you want to use hardware directly rather than virtualizing it, you can use an existing physical SCSI disk. You lose flexibility to move things around when you choose this option, though, so be careful.
I'll create a new virtual disk for this example, as shown in Figure H.
|How should disk storage be handled for your new virtual machine?|
The next screen you'll see asks if you want the new disk to be IDE-based or SCSI-based. The default option depends on what VMware feels works best for your operating system selection. For my Windows Server 2003 selection, a SCSI disk is recommended, so I'll use that.
Drive type is all well and good, but how much space do you want to allocate to the file? The next step of the wizard asks this question. You can allocate as little as 100 MB or up to 256 GB for SCSI disks, or 128 GB for IDE disks. Keep in mind that other virtual machines might vie for the same space unless you're careful in your storage planning. Remember that you need enough space on your virtual machine to house the OS and any files that you might save on the virtual machine.
VMware can allocate space for the new server either on the fly or all at once. When you allocate space on the fly, the file that holds the virtual server grows only as it needs to. This is useful if you're not sure if you have enough space on the host for all virtual servers. However, there's a slight performance hit with this option, since the host has to grow the file. If you want to avoid this hit, and you have enough space, select Allocate All Disk Space Now. A file will be saved to your host with the size you specify here.
You can also opt to break the space up into 2-GB chunks, which is useful if your file system doesn't support large files. For example, if your host system uses FAT16, a file size beyond 2 GB isn't supported. For this article, I'll use a 10-GB disk and won't split it up, since my system uses NTFS (Figure I).
|How much space should the new server have, and how should it work?|
Your new disk needs a filename, which you provide in the next step of the wizard. I like to name my disk files the same as the virtual server and put a number after the file. It lets me easily keep track of what disk files belong to which virtual machines. I've named my virtual disk file3-1.vmdk.
You can use the Advanced button to make this disk persistent or non-persistent. A persistent disk works just like any disk in any file server. When you boot the system and work with it, changes are saved and accessible when you reboot. With VMware, you can also use a non-persistent disk. When you power down the virtual machine, all changes you made are rolled back, and none of the changes you made during the session are saved. This means that you get the same system every time you start up. This is really useful if you need a baseline system in order to track down a problem.
When you click Finish, your new disk is formatted (Figure J). Don't worryï¿?your host operating system is not affected.
|What do you want to name the new disk?|
When you're done, you'll get an overview of your new system, as shown in Figure K. The one change I made to the configuration shown here was to point the new server's CD-ROM device at an ISO image of a Windows Server 2003 CD. I create ISO images for all CDs in my environment, and I haven't lost or damaged a CD since I started doing this!
|Here's an overview of your new system.|
Operating system installation
From this point forward, the virtual server acts just like a physical server. To install a new operating system, just insert the OS CD into the host's CD-ROM drive (or mount an ISO image of the OS CD), and power on the virtual machine using the Start This Virtual Machine option on the overview page.
To mount an ISO image of a CD, click Edit Virtual Machine Settings. On the resulting screen, select ISO Image and browse for the ISO image location. An ISO image of a CD acts exactly like a real CD. Your virtual machine can even use it as a boot device if the original CD was bootable.
VMware Tools installation
After you get your operating system installed, it's highly recommended that you install the VMware Tools inside your guest system. VMware Tools is basically a set of drivers that optimize your virtual machine. The driver set includes a video driver and better network drivers, and it also provide the ability for mouse pointer integration between the host and the guest (meaning that you don't have to use [Ctrl][Alt] to escape the guest anymore. Once VMware Tools is installed, you can copy and paste, and drag and drop, between the guest and the host operating systems.
For Windows guests, from the guest operating system's window, select VM | Install VMware Tools. If you have autorun enabled on the guest, the VMware Tools installation will start. If you've disabled autorun, go to Start | Run and execute <drive>:\setup\setup.exe. Replace <drive> with the drive letter of your virtual CD-ROM device.
VMware Tools is installed from an ISO image shipped with GSX Server, so you don't actually need any physical CD to perform the installation. I recommend choosing a complete installation of VMware Tools. There's really no reason to pick and choose what to install. You'll probably have to reboot the guest after installation completes. If you're running a Windows 98, Me, or NT guest, refer to the VMware Tools installation guide shipped with GSX Server for additional steps you need to take after installation.
For Linux/FreeBSD guests, perform the following steps as a root user:
- Choose VM | Install VMware Tools while the Linux client is active: This attaches to the guest the ISO image that contains the VMware Tools installer.
- mount /dev/cdrom /mnt: Mount the CD-ROM device so it's usable by the operating system.
- cd /tmp: Change to the /tmp directory.
- tar zxf /mnt/vmware-linux-tools.tar.gz: Unpack the Linux version of the VMware Tools installer in the server's /tmp directory.
- umount /mnt: Unmount the CD-ROM.
- cd vmware-tools-distrib: Change to the VMware Tools installation directory.
- ./vmware-install.pl: Start the VMware Tools installer (a Perl script). Answer the questions the installer asks about where files should be located.
- vmware-config-tools.pl: If you want,change your virtual machine's display resolution by following the instructions on the screen.
- exit: Exit the root account. You might need to log back in as a regular user, depending on how you got to the root account (via login or su).
- Start your X terminal as you normally would: The goal here is to get to your normal operating environment.
- vmware-toolbox &: Start a terminal and type this at the command line to start a background session of VMware Tools. Refer to the VMware GSX manual for information on how your operating environment can be configured to start the tools automatically.
More than Workstation
VMware's GSX Server product goes beyond Workstation by providing more control and a more robust, expandable environment in which to run your virtual machines. By providing support for up to 64 GB of RAM and a large number of processors, GSX Server can easily be used for legacy server consolidation, a test lab, or even applications that don't require multiple CPUs.