Test Run

Configuration Testing With Virtual Server, Part 1

Dr. James McCaffrey

Contents

Installing Virtual Server
Creating Virtual Machines
Installing an OS on the Guest Machine
Creating Undo Disks, Differencing Disks, and Backups
Performing the Tests
Wrapping Up

In this month's column, I'll introduce you to software configuration testing with Microsoft® Virtual Server. Configuration testing is a general term that simply means testing a software system on different combinations of hardware and software. The traditional way to perform software configuration testing is to set up a lab with multiple physical machines running different combinations of operating systems, Web browsers, and other software. This can be expensive and time consuming. Happily, Virtual Server allows you to perform some types of software configuration testing by creating multiple virtual machines on a single physical machine.

In discussions with my colleagues, I learned that many of the techniques for configuration testing with Virtual Server are not widely known, so I set out to create a complete explanation of the process. This month's column is intended for beginners, so I'll assume you have no experience using Virtual Server.

The screenshot in Figure 1 illustrates many of the key concepts of configuration testing with Virtual Server. It demonstrates the testing of a DLL file on a Windows® 2000 Professional machine. The physical machine is running Windows Server® 2008 and is called the host machine in Virtual Server terminology. Behind the scenes, Virtual Server is running as a Windows service on the host machine. The virtual machine instance, which is running Windows 2000 Professional, is called the guest machine and is managed using a Web-based interface. In this example, I am running only one guest machine, but I can run multiple guests simultaneously on the host if I want.

Figure 1 Configuration Testing with Virtual Server (Click the image for a larger view)

In the guest machine, you can see that I have three windows open: two instances of Windows Explorer and a command shell. The top instance of Windows Explorer is pointing to \\WIN-6IN7WRUV5QY\Public, which is a share on the host machine. The bottom instance of Windows Explorer is pointing to C:\Tests, which is a directory on the guest. In my scenario, I copy two test files, testHarness.js and testData.txt, from the host onto the guest. I then execute a simple automated test that exercises a DLL on the guest. Of course, I could have performed any type of manual or automated test on the guest; the important idea here is that I have a fully functional Windows 2000 machine available to test any type of software I want.

Installing Virtual Server

Installing Virtual Server is straightforward, but there are a few factors you should take into consideration if you plan to perform configuration testing. Virtual Server 2005 R2 SP1, the current version, is available as a free download from microsoft.com/downloads. Each guest virtual machine requires processor resources, RAM, and hard disk space; as a general rule, the more of these resources your host machine has, the better. When using Virtual Server for configuration testing, you will likely have a large number of virtual hard drives, but normally you'll run only one virtual machine at a time. So, ideally you want to have an environment where you have a large amount of disk space and a reasonable amount of RAM. Of course, the reality is that you will probably be using an old machine with very limited resources.

A slightly more subtle installation issue involves your host machine's network adapters and network membership. It is quite feasible to create a completely standalone Virtual Server machine. But, as I'll show you shortly, when using Virtual Server for software configuration testing it is useful for your guest virtual machines to have access to other physical machines on a local network and to have access to the Internet.

My preferred configuration is to use a host machine with two network adapters, one of which is connected purely to a local network and one of which is connected to the Internet. As a matter of personal preference, although I do connect my host to a local network (so I can easily transfer files to the host), I do not join my host to the local network domain. That said, an advantage of joining your Virtual Server host machine to an Active Directory® domain is simplified authentication when you manage the machine; if your host machine is not part of a domain, you must repeatedly identify yourself using Windows NT® LAN Manager (NTLM) authentication, which can get rather tedious. Finally, I strongly recommend that your Virtual Server host machine be dedicated strictly to Virtual Server activities.

Virtual Server uses a Web-based management scheme and, therefore, requires IIS. So note that before starting the Virtual Server installation, you should enable and configure IIS on your host machine. That said, when you install Virtual Server on a host running Windows Vista SP1 or Windows Server 2008, IIS is installed automatically as a part of the Virtual Server setup. Once you have configured your host machine and downloaded the Virtual Server installation setup.exe file, you can begin the installation process.

The majority of the installation process is straightforward and consistent with most application installers. The configuration dialog, however, is one that causes Virtual Server beginners the most confusion. The screen asks you to specify a port number for the Virtual Server administration Web site. The default is port 1024, and you should use this unless the port number is unavailable. The configuration screen also asks you to select whether you want the Virtual Server administration Web site to run under a user account or under the Local System account. You should select the default user account option unless you intend to store some or all of your Virtual Server data, such as virtual hard drive files and virtual machine configuration files, on one or more remote machines. In that scenario you should choose the Local System option so that your host machine running the Virtual Server service can access those files.

Keeping all your data on a single machine is a simpler approach, and I prefer it whenever possible. The price of external hard drives has dropped to a point where they make an excellent storage solution for virtual machines for configuration testing, as opposed to using either secondary internal hard drives or remote storage on another machine.

In the installer you will also see an option to enable Windows Firewall exceptions for Virtual Server. As an alternative to Virtual Server's Web-based remote administration, you can enable the Remote Desktop feature on your guest machines. Remember to enable exceptions in Windows Firewall.

Creating Virtual Machines

Before you can perform configuration testing using Virtual Server you must create one or more virtual machines. It's easiest to use the GUI interface of the Virtual Server administration Web application. Additionally, Virtual Server exposes COM interfaces that enable you to automate management tasks using your favorite scripting host. You can navigate to the administration Web page by typing https://machinename:1024/ in the address bar of Internet Explorer® and you will be redirected to the application running at https://machinename:1024/VirtualServer/VSWebApp.exe—or you can access the page from the shortcut in the Start menu. The administration page defaults to a view of your Virtual Server status and a list of recently logged events. It's a good idea to scan the event messages to make sure that the Virtual Server service is properly running in the background.

Now you need to click the Create link in the Virtual Machine category. You will be redirected to the Create Virtual Machine page shown in Figure 2. Here you'll name your virtual machine. You should give some thought to both the location and the name. The name you specify will become the name of the virtual machine .vmc configuration file. If you just type in a name such as "MyVirtualMachine," you will create file MyVirtualMachine.vmc at a default location, which is %SystemRoot%\Users\Public\Documents\Shared Virtual Machines\ on Windows Server 2008, and %SystemRoot%\Documents and Settings\All Users\Documents\Shared Virtual Machines\ on Windows Server 2003.

Figure 2 Creating a Virtual Machine (Click the image for a larger view)

Because I use many different virtual machines and a lot of hard disk space when I use Virtual Server for configuration testing, I prefer to place my virtual machines in a non-default directory closer to the system root or even on a separate hard drive. It's usually a good idea to give your virtual machine a name that includes a description of the guest machine's operating system and any key software components on the guest. Even though the .vmc virtual machine configuration files are XML-based and easily readable, a descriptive file name makes the management of multiple virtual machines much easier.

In addition to an explicit .vmc file, the virtual machine creation process also creates a shortcut .lnk file at a default location (%System­Root%\Users\All Users\Microsoft\Virtual Server\Virtual Machines\ on Windows Server 2008). You need to remember this in case you want to delete a virtual machine manually by deleting the .vmc file. If you do not also delete the .lnk file and later try to create a new virtual machine with the same name as the deleted machine, you will get an error stating that the machine already exists. If you remove a virtual machine from a virtual server using the Web interface, only the shortcut file is actually deleted, so you can recover your virtual machine simply by recreating the shortcut.

After specifying the virtual machine's name and location you must specify the amount of RAM for the guest machine, as shown in Figure 3. Keep in mind that the host's RAM is used by the physical host machine and all running virtual guest machines. So, for example, if your host machine has 2GB of RAM, and you are running two virtual machines, each with 512MB (one-half a GB) of RAM, you will have 1GB of RAM available for the host (minus approximately 75MB per virtual machine for overhead).

Figure 3 Creating a Virtual Hard Disk (Click the image for a larger view)

The next step in creating a virtual machine is to specify whether you want to use an existing virtual hard drive or create a new one. For configuration testing you need to create a new one, so select the Create New Virtual Hard Disk option. For the size field, specify the largest amount of memory your virtual machine will need. As a rule of thumb, I have found that 20GB is a reasonable choice for configuration testing in most situations.

Naturally, though, the amount of disk space you will need is based on the type of applications that you will need to instal, so be sure to get a rough estimate before creating the virtual disk. The size you specify is the maximum size that the virtual hard disk can grow to, not a fixed size. Interestingly, even if your physical host machine has only an IDE hard disk bus, you can specify a SCSI bus for your virtual hard disk to increase performance and storage capacity. In general, I use a virtual IDE bus for configuration testing because performance is normally not an issue.

The last step in creating a new virtual machine is to specify a virtual network adapter. As I've explained, I like to use two physical network adapters on my host machine. If you examine the screenshot in Figure 4, you can see that I have four options: Not Connected, two External Network selections, and Internal Network. When you install Virtual Server, the setup process scans your host machine for network adapters. In this example, I have an 802.11g wireless adapter that I use to connect to the Internet and a wired adapter that I use to connect to a local network. Virtual Server places each adapter name in parentheses preceded by the text "External Network."

Figure 4 Virtual Network Adapters (Click the image for a larger view)

If you add a new network adapter to your host machine after installing Virtual Server, you can add to the list of available virtual adapters by clicking on the Create option of the Virtual Networks section on the main administration Web page. I recommend following the same network adapter naming conventions used by Virtual Server, which makes it very easy to identify the mapping between virtual network adapters on the guest machines and physical adapters on the host machine.

If you select the Not Connected option, your virtual machine will be completely isolated from all other machines—even the host machine—and you will not be able to copy files to or from the virtual machine. If you select the Internal Network option, your virtual machine will be able to connect to other virtual machines running on your host, but not the host machine itself. If you choose one of the virtual adapters associated with a physical adapter on the host, your virtual machine can connect to the host machine and reach anywhere the host can reach through its adapter.

In general, when using Virtual Server for configuration testing you will want to select one of the virtual adapters associated with a physical adapter on the host so that you can copy test-related files to the virtual machine and so that you can reach your system under test if it is network-based or Web-based (such as an ASP.NET Web app). Also, note that for simply deploying files to your virtual disk, you can use the vhdmount feature of Virtual Server to mount the vhd and then copy files to it.

After setting the virtual machine name, memory, hard disk, and network adapter options, you can click the Create button to create your virtual machine. When you view the Configure options for your machine, you'll see your current settings, as shown in Figure 5.

Figure 5 Virtual Machine Configuration Summary (Click the image for a larger view)

Installing an OS on the Guest Machine

Before you can use a virtual machine, you must install an operating system just as you would for a physical machine. Virtual Server beginners often incorrectly assume that a guest machine inherits an operating system or runtime in some way from the host machine. There are several ways to install an operating system on the guest. If your physical host machine has a CD/DVD drive, an easy installation technique is to insert a bootable CD or DVD containing an operating system into the host machine's CD/DVD drive. If Virtual Server has registered a virtual CD/DVD drive with the guest, the AutoRun feature of the virtual machine will kick in and automatically launch the operating system setup program when you start your virtual machine.

Once the OS installation on the virtual machine begins, the process is exactly like installing an OS on a physical machine. In Figure 6, note that the Windows XP setup program believes it is installing onto a physical machine with a 20GB disk drive. As soon as you begin the installation process you will notice that you have to perform a mouse-click into the ActiveX® control area in Internet Explorer in order to enable the virtual machine to recognize mouse and keyboard input. To place mouse and keyboard focus outside of your virtual machine and back onto your host machine you must tap the right Alt key.

Figure 6 Installing an Operating System on the Guest (Click the image for a larger view)

Setup will proceed normally except that the process will take a bit longer than it would on a physical machine. The main reason for this is that Virtual Server must dynamically expand as needed to accommodate operating systems files as they are copied from the host CD/DVD drive to the guest virtual machine. When Virtual Server is expanding the virtual disk drive, it may appear that the installation process has stalled—just be patient and the setup will continue after a few minutes. When the OS setup program asks you to specify a name for the guest machine, you should make sure that the machine name is unique relative to any other machines it may connect to; if your virtual machine is connected to a network, the machine name is the one you specify during setup and not the name you specify for the .vmc configuration file.

After you have completed installing the guest operating system, you should install the Virtual Machine Additions on the guest. Virtual Machine Additions can be installed onto a virtual machine to increase its performance and screen resolution, and it allows you to switch focus between guest machine and host machine by simply moving your mouse pointer.

To install Virtual Server Additions, start your virtual machine from the main administration Web page by clicking on the virtual machine icon. After the machine's status has updated from Off to Running, click on the icon again to go to a page that contains an ActiveX control that allows you to manipulate the guest machine. After logging onto the guest machine, scroll to the bottom of the administration Web page and click on the Click here to start Virtual Machine Additions set link. This will launch the installer application for Virtual Machine Additions.

Creating Undo Disks, Differencing Disks, and Backups

When you are using Virtual Server for configuration testing, it is very helpful to understand how to create and use undo disks, differencing disks, and backups. By default, when you create a virtual machine, all the changes you make to it are saved to its .vhd file when you shut down the virtual machine. Then when you restart it, all the changes are automatically read from the virtual hard disk file. This is exactly what you want when you use Virtual Server for machine consolidation.

However, this is not always what you want when using Virtual Server for configuration testing. In most situations, you want your virtual machine to start up in the same state for every test you run on the machine. One way to discard any changes made to the guest is to enable undo disks on the guest. If you do so, all changes you have made to the virtual machine while you are using it are saved in a .vud file. The Virtual Server administration page then gives you the option to either commit or delete changes to the underlying .vhd file.

To enable undo disks, click on the Configure item in the Virtual Machines section on the main page of the Virtual Server administration Web site. Then click on the Hard Disks item and check the Enable Undo Disks entry. Now when your virtual machine is running, the administration page gives you several options including Turn off virtual machine and commit undo disks, which effectively keeps all changes made to the state of your virtual machine; and Turn off virtual machine and discard undo disks, which effectively tosses out changes and keeps the original state of your virtual machine.

So when using Virtual Server for configuration testing, you usually want to enable undo disks so that you can run some tests on your guest and then reset the machine to the state before the tests were run. Undo disks are an effective way to manage virtual machine state, but based on my experience you should also make sure that you have a copy of your virtual machine's original virtual disk (.vhd) and machine configuration (.vmc) files. This is important because when performing tests on a virtual machine, it is very possible to get the machine into a state where you cannot use the Virtual Server administration site and thus can't gracefully discard your undo disks.

Differencing disks are a cousin to undo disks. A differencing disk is essentially a child virtual hard disk of a parent virtual hard disk. The large parent .vhd file contains the core state of a virtual machine (usually the OS and key software for your particular environment), and the smaller differencing disk contains only deltas to the parent disk. In configuration testing, you would typically use differencing disks to create a core operating system .vhd file (Windows XP with SP2 for example) and then create several child differencing disks, each with a different Web browser (Internet Explorer 6.0, Internet Explorer 7.0, and so on). With this approach you can save a lot of disk space on your host machine because each child .vhd differencing disk file is only a tiny fraction of the size of a full parent .vhd file.

To create a differencing disk, navigate to the main administration page, click the Create item in the Virtual Disks section, and then select the Differencing Virtual Hard Disk option. You will be directed to a page where you can specify the location and name of the new differencing disk file as well as the location and name of an existing .vhd file that you want to serve as the parent.

After creating a differencing disk you should use only the child disk, never the parent disk, because if the parent disk changes in any way the child disk will likely become unusable. This means that before you create a differencing disk you should make a backup copy of the intended parent .vhd file, set the file permissions of the parent .vhd file to read-only, and make sure that no virtual machine is configured to use the parent .vhd file. Until recently I was a big fan of using differencing drives; however, with the cost of hard disk drive space so low, I now generally prefer to make multiple full .vhd files.

Performing the Tests

Once you have created a virtual machine, software testing on the machine is just like testing on a physical machine. If your system under test runs locally (like a file compression utility does, for example) then you must copy or install the system under test onto your virtual machine and then perform automated tests, manual tests, or both. To copy the system under test or test files to a virtual machine, you can copy those files from a machine to which the virtual machine has access (which means the virtual machine must be connected to the special Internal Network adapter or a physical adapter on the host).

One technique I've used in the past is to create a virtual storage machine that holds the current build/iteration of the system under test and test-related files, and transfer files to various virtual machines via the Internal Network adapter. Another approach for copying application files is to burn them to a CD/DVD or build them into an ISO image and then mount that image within Virtual Server. Still another approach to copying files from host to guest is to use the vhdmount.exe utility that ships with Virtual Server; the product documentation explains how to do this.

In my experience I have found that Virtual Server is especially useful for configuration testing of Web apps. In this situation, you need to create a .vhd file that has the target Web browser installed, run the associated virtual machine, and point to the Web app under test. Depending upon your scenario, you may find that you need to test a live Web application on the Internet (in which case your host machine must have access to the Internet), on an intranet (your host machine must have access to the Web server that hosts the Web app), or both. Part of the beauty of using Virtual Server guest machines for software configuration testing is that all your normal testing paradigms work just as they do on physical machines.

Wrapping Up

Virtual PC and Virtual Server, the two current virtualization systems from Microsoft, are built upon the same core code base and are similar in many respects. Although useful and powerful, the upcoming Microsoft Hyper-V™ system promises to be a huge advance in virtualization technology. Like Virtual Server (but unlike Virtual PC), Hyper-V will be completely automatable. Additionally, Hyper-V will introduce a wide range of new features. Understanding the principles and techniques of performing configuration testing with Virtual Server provides you with an excellent foundation for understanding and transitioning to Hyper-V. That said, Hyper-V is only supported on 64-bit machines, so if you want to use a 32-bit machine as your virtualization host, Virtual Server is still the way to go.

One nice facet of Virtual Server that I did not have room to cover in this column is that Virtual Server is built upon a large set of classic COM components, so can it be completely automated. Although Virtual Server automation is well documented, much of the information is aimed at using Virtual Server for server consolidation tasks rather than for configuration testing. My next column will describe how to entirely automate configuration testing using Virtual Server.

Send your questions and comments for James to testrun@microsoft.com.

Dr. James McCaffrey works for Volt Information Sciences, Inc., where he manages technical training for software engineers working at the Microsoft Redmond campus. He has worked on several Microsoft products including Internet Explorer and MSN Search. James is the author of .NET Test Automation Recipes. He can be reached at jmccaffrey@volt.com or v-jammc@microsoft.com.