A VMware virtual machine provides administrators with many options for handling multiple operating systems, quick restorations, disposable test environments, hardware consolidation, and other technology tasks. VMware can also be used as a means of distributing prebuilt system configurations to streamline the sharing of virtual machines. I will walk you through the steps involved with distributing a virtual machine for demonstration, training, or testing.

What is VMware?
VMware is virtual machine software. It runs on one computer (the host) and offers virtual computers in the form of guest operating systems. These virtual computers are simply a collection of files (or a complete hard disk) you allocate that run an instance of an operating system you specify. For a more thorough explanation of how this works, see “Creating virtual machines for testing systems in VMware.”

For the purposes of this article, I’m going to be using VMware on Windows as the host platform, although other operating systems (such as Linux) can be the host platform as well.

Files involved
A virtual machine is composed of a group of files. By default, the files are kept in the \My Documents\My Virtual Machines\<Virtual Machine Name> folder. These files tell VMware the configuration of the virtual machine and include a log of virtual machine activities (independent of the guest OS), a virtual disk file (if virtual disks are used), a lock file, configuration backups, and rollback option files (if you have them enabled as an Undoable disk). A typical configuration may have several .lck, .log, .bak, .raw, and .vmdk filename extensions and one nvram file for one virtual machine.

Many factors determine exactly what files will be involved and how large the virtual machine’s files will be. For example, a base install of Windows 2000 Professional with Service Pack 3 is around 790 MB in my configuration. Obviously, the more software that is installed on a virtual machine, the larger the files will be.

VMware does not natively perform a compression on the files involved for a virtual machine, as that would decrease performance (which can be an issue in some cases). VMware is resource intensive, since it is causing your processor, RAM, host operating system, and other hardware components to work double time or more. Thorough testing will give you an idea of what your hardware is capable of performing in consideration of the VMware performance hit.

Version issues
VMware is generally very good about moving virtual machines across versions of VMware, as well as across VMware products. In preparing this material, I used demo versions of VMware Workstation 3.2 and VMware GSX Server 2.0. I was able to take virtual machines to and from each without incident.

VMware Tools may need to be updated depending on the destination host system version of VMware. You may also get some messages about the CMOS from a virtual machine created on VMware Workstation when it is being opened on VMware GSX Server or any migration where the VMware CMOS version differs. Figure A shows an example of one of these messages.

Figure A

In this scenario, VMware will use the newer CMOS. Keep in mind that when VMware mentions the CMOS, it is not referring to the host computer’s CMOS or BIOS but to a virtual CMOS for each virtual machine. You can enter the virtual CMOS for configuration options for the virtual machine, just as you would for the CMOS on a real system. Figure B shows cascaded VMware windows and their two CMOS versions (GSX Server 2.0 and Workstation 3.1).

Figure B

Distribution and ensuring open compatibility
After creating a virtual machine with your custom configuration, you may take a look at the files involved and become concerned about their size. That’s because virtual machine files can compress well, depending on the guest operating system. For example, I have a sample Linux Mandrake 8.2 configuration that’s 575 MB uncompressed. Using WinZip, I was able to compress all files for the virtual machine to a single 282-MB file. The compression results will vary, depending on the contents of the virtual machine.

To optimize your virtual machines, consider installing only what is needed and do not keep any extra configuration, source code, or applications on the hard drive of the virtual machine (service packs, the \i386 directory, etc.). This will keep the virtual machine as small as possible, which will ease deployment and backups/restores. You can also perform an offline defragmentation of a virtual machine’s disk in the Configuration Editor to optimize the files.

For transporting VMware virtual machines, it is a better practice to use the “virtual disk” type rather than the “physical disk” option. This is because the host file system would also have to be transported with the virtual machine rather than just the virtual disk (.vmdk) file. To transfer a virtual machine to another VMware host computer, simply move the virtual machine files to the new machine and then go into the VMware application, choose File | Open, and select the .vmdk file.

There are a few issues to keep in mind when moving virtual machines. If you write the virtual machine files on a CD, they will become read-only, so that attribute needs to be removed when the files reach the virtual machine’s final destination. Also, in transporting virtual machines, you want to enable the most compatibility. One way of accomplishing this is by using the Configuration Editor for the virtual machine in question. Figure C shows the Configuration Editor window for a Linux virtual machine.

Figure C

As you can see, this virtual machine has a hardware inventory of 128 MB RAM, one virtual hard disk, a CD-ROM drive, a floppy drive, a bridged network adapter, and a 2-port USB controller. This inventory was generated on the VMware host computer where the virtual machine was initially created and thus is based on that computer’s hardware. If I created the virtual machine on a computer without a floppy drive, the floppy drive would not be in the inventory. The important part is the hardware of the systems that will receive the virtual machine.

If you send a virtual machine configured like that in Figure C, and that machine has neither a CD-ROM nor a floppy drive, you will get a series of error messages during the boot-up phase of the virtual machine that will prevent it from booting.

In addition, if the destination computer has less than 128 MB RAM, another error message will appear. To avoid the problem, you can modify the memory setting in the Configuration Editor on the destination computer. Using the Configuration Editor, you can have the destination hardware in mind and set up compatibility.

In my experience with transporting virtual machines, I have modified the Configuration Editor before the virtual machine was created to avoid any unnecessary plug and play during an install. I usually set the configuration to have only a basic amount of memory (32 MB for Linux, 64 MB for Win2K) and a virtual disk. If a network interface, CD-ROM, or other device is required, I add them explicitly. This allows the virtual machine to scale up to the hardware resources that are available.

Endless possibilities
Transporting virtual machines can help an IT staff in a variety of ways. Whether you’re offering a demonstration of a software solution to a customer, developing a sandbox for testing servers for a rollout of a new enterprise system, or sending the support department a virtual machine that mirrors the configuration of a new desktop rollout, distributing a virtual machine offers a flexible, powerful solution.