Enterprise IT eco systems have gotten much more complex the last few years. Today's enterprise applications need to run well in a heterogeneous environment, meaning run well in a diverse eco system. It is common that applications need to support multiple OS versions, browser versions, support various databases, and, last but not least, have strong interop capabilities. IT departments are struggling with this increased complexity as do the development teams responsible for building these products. There are really two contributing factors.
Enterprises have heavily invested in enterprise applications during the dot-com boom in the hope of improving un-efficiencies in the day-to-day work of their employees and also to automate business processes. This resulted in an unprecedented number of applications deployed in enterprises. Business-Process-Automation is still in its early stages because it means that applications need to be able to exchange data easily and reliably. This level of data exchange and communication was achieved in the past by undertaking costly integrations which required the help of large integrators and large budgets. Most of these integrations ran over-budget and over-schedule and are quite often considered to be unsuccessful undertakings. Today's enterprise applications need strong interop capabilities as enterprises are no longer willing to undertake expensive one-of integrations.
This means it is a given fact that enterprise applications need to integrate with a number of other applications and need strong interop capabilities. This also means that your application will interact with many other enterprise applications and your development and test team needs to build these capabilities and test them thoroughly.
The bigger problem is the constant cycle of new releases. ISVs constantly improve the capabilities of their enterprise applications and every one to two years issue a new release. It is time consuming and expensive for enterprise customers to roll out a new release. Resource constraints and budget constraints force customers to wait at least two to three years before they roll out the latest release. This means ISVs have to support at least the last two to three releases of their applications. But, it also means they have to run with the last two to three releases of all the other applications they rely on or integrate with. And, that is where it quickly can become very costly for ISVs. It means your development and test team spends considerable time in making sure the release works with all the other applications.
Typically, development teams and test teams come up with a number of deployment scenarios. For example, the server component of your application can be deployed on Windows 2000 and Windows 2003 and supports Internet Explorer 5.5 and 6.x as well as Netscape Navigator 7.x access. The development team and testing team then create a number of different environments to simulate these deployment scenarios. It then needs dedicated hardware for each deployment scenario. Sometimes, the team does not have enough hardware, so it spends time reconfiguring systems. It may, for example, first install Windows 2000 and when these tests are completed install Windows 2003. But, if there is a need to go back to Windows 2000, it spends time reconfiguring the system again. This can take a lot of time and effort.
Your Virtual Development and Test Environment
Virtualization has arrived over the last few years. There are a number of companies that offer virtualization products. Most of them address slightly different needs. Also, Microsoft entered that market by acquiring Connectix. It released the redesigned product under the name "Virtual PC 2004" at the end of 2003. The sweet-spot of Microsoft Virtual PC 2004 is in the following three areas:
- Application migration—Rolling out a new OS version or application has many implications. You might have other legacy applications that no longer run in this new environment. This can become an obstacle for the rollout of the new OS or application. It can be overcome by running the legacy application in its old environment under Virtual PC. So, you install Virtual PC, which is very easy to install and takes only minimal hard disk space, and then create an exact image of the current environment. And then, you run that application under Virtual PC till you can upgrade the legacy application or phase it out. Launching into the legacy application requires that you first launch that Virtual PC, which requires only seconds if you save its state (more on that later).
- Application support—Support centers need to have access to environments that represent the customer's environment. Most support groups have multiple hardware environments, sometimes even an environment per customer. The other alternative is to utilize multi-boot options so you can have multiple OSs and you choose at boot-time which OS, or which environment, you start up. The multiple hardware environment option can become very costly and the multi-boot option can take a while to get the customers' environment up and running. The alternative is to create multiple Virtual PC images and keep each in the saved state. This then allows support engineers to activate a Virtual PC representing the customer's environment in seconds.
- Application test—Test teams need to test enterprise applications in many varying environments. The most common approaches are to have a hardware environment for each scenario or to have one hardware set that is reconfigured each time. Both approaches are very costly, whether it is the cost of enough hardware and maintaining the environments or the cost of constantly re-configuring an environment. Virtual PC allows you to create multiple images, each representing an environment to test. This allows you to choose a configuration and bring it online for testing within seconds. The "Undo Disk" option becomes very handy because it allows you to keep the original image and store all changes you make for testing onto a separate disk (more on that later). When done, you can easily discard all changes or make them permanent.
Virtual PC can eliminate a lot of complexities and costs in each of these three scenarios. Virtual PC officially supports only Windows XP Professional and Windows 2000 Professional on the host machine (the OS on which you boot up the physical machine), although it allows you to install on other Windows versions. I installed it on Windows 2003 and it ran fine. On the virtual machine (guest machine), it supports almost any Window version and even some OS/2 and Novel versions (see Microsoft documentation). Microsoft is also working on "Microsoft Virtual Server 2005," which will be a server version running only on Windows 2003. I used a release candidate at the time of writing this article. The biggest difference is that Virtual Server offers a Web-based interface so you can manage the virtual machines remotely. The virtual machines all run in the "vssrvc.exe" process. The sweet spot for Virtual Server is in the following four areas:
- Application migration—It can ease the same migration pains as Virtual PC, but targeted towards server applications. So, if you have legacy server applications that no longer work with the new server OS or other server applications, you can run them as virtual machines on the server. Clients can still access the server application the same way.
- Server consolidation—Implementing and running enterprise applications can be very costly. The hardware and software costs are only one-time costs and very often a small part of the TOC (total cost of ownership). Over the last few years, many IT teams have started server consolidation projects. The goal of these projects is to reduce the number of servers that need to be administered. This is achieved by upgrading to newer versions of these enterprise applications which are more efficient or by running multiple server applications on the same machine. Running multiple applications on the same machine has its own complexities because these applications sometimes require conflicting configurations or versions of server resources. Virtual Server provides a powerful alternative. You can have one host machine that runs multiple guest (virtual) machines and each is completely isolated from each other. This makes it much easier to consolidate multiple enterprise applications onto one physical server.
- Consolidate application test and development environments—Each test and development team requires many environments to be able to test enterprise server applications in all supported deployment scenarios. This results in increased hardware costs as well as administrative tasks in keeping all these environments running. Virtual Server offers an alternative by running multiple virtual machines on one physical server. For example, you have an n-tier application (data tier, application tier, and presentation tier) that you need to test on Windows 2000 Server and Windows 2003 Server. Traditionally, you have six machines so you have these two different testing environments available. With Virtual Server, you can achieve that with one or two physical machines, depending on the available resources such as CPU and memory on the machine(s).
- Simulating distributed application deployments—Most server applications are n-tier applications that have a data tier, application tier, and presentation tier. Most enterprise ISVs recommend that you deploy these tiers on separate machines; thiis results in increased hardware demands for customers. Virtual Server provides a powerful alternative by still running each tier separately in a virtual machine but still all on the same physical server. Truth be told, most development teams develop the application by running all tiers on their single development machine and only the testing team tests the application deployed in a way as recommended to customers. Virtual Server makes it easy for each developer to run three virtual machines and test and develop the application the same way as recommended to customers. This allows you to find defects right when the code is written and unit tested by the developer. The earlier you find and correct a defect, the cheaper it is.
As the name indicates, Virtual Server is targeted towards server applications and Virtual PC towards desktop applications. You cannot install Virtual PC and Virtual Server on the same host machine. Doing so will break the previously installed version. You also cannot reuse the "Virtual Machine Settings" (*.vmc) file. They are different between Virtual PC and Virtual Server. The good news is that the "Virtual machine Hard Drive Image" (*.vhd) file is the same for both products. So, you can reuse a virtual hard drive configured and installed for Virtual PC with Virtual Server. This makes it very easy to reuse existing Virtual PC machines when migrating to Virtual Server. You create a new virtual machine, attach the existing virtual disk image, and start up the virtual machine.
Microsoft Virtual PC 2004
In this section, we look at how to install and run Virtual PC. Running setup will warn you if you install Virtual PC on any other Windows version than Windows XP Professional or Windows 2000 Professional, but it still allows you to install on any version you use. The installation is very quick and only requires about 30 MB on the hard drive. The install interrupts your network connectivity briefly so it can install the "Virtual machine Network Services" driver. This driver is used to simulate the network card to the virtual machine. When done go, to the Start menu item "All Programs | Microsoft Virtual PC" to launch it. At first launch, it brings up the wizard to create a new virtual machine. You can create a new virtual machine by providing all configuration details, create a new virtual machine with the default settings, or add an already existing machine. All files are stored under "[User Profile]\My Documents\My Virtual Machines". All "virtual machine" settings are stored as a file with the extension VMC, which is nothing more than a XML file with all the settings. This last option makes it easy to copy the files from one physical machine to another and then just connect to an already existing virtual machine.
Let's create a new virtual machine so we see how to set it up. We select "Create a virtual machine" and click Next. Next, we enter the name of the virtual machine and click Next again. Now, we select the OS we want to install on the virtual machine—for example, Windows 2000 Server—and click Next again. The next screen allows you to select how much physical memory will be available for the virtual machine. Based on the selected OS, it makes a recommendation but also allows you to change it. My physical machine has 1 GB and I know Windows 2000 wants lots of memory so I change it to 400 MB and click Next again. Your physical machine needs to have enough memory for the host machine plus all running guest machines. The next screen allows you to create a virtual disk, a disk that is used by this virtual machine. Virtual Disk Images are stored as files with the extension VHD. So, copying a virtual machine to another physical machine requires copying the VMC and the VHD files. If you have an existing disk image, you can connect to it. In our sample, we select "A new virtual hard disk" and click Next again. On the next screen, you enter the location and name of the disk image and click Next and then Finish. This creates under "[User Profile]\My Documents\My Virtual Machines" a new folder with the name we gave the virtual machine (unless you changed the default location). In this folder, you find a VMC file with the name of the virtual server and a VHD with the name of the virtual disk.
The Virtual PC console shows you that this virtual machine is "not running." Select the virtual machine and click Settings. It shows you all the settings for this virtual machine. This allows you to make changes to the configuration of the virtual machine; for example, changing the memory available or adding a second or third hard disk. We will come back to this screen later. From the PC console, you can select a virtual machine and start it. It brings up a new window that shows the console for this new virtual machine. First, you see a typical boot screen. Like the boot screen of your physical machine, it shows the memory found as well as the disk drives, CD, and floppy drives found. It then will tell you that no boot device has been found because we have not yet installed an OS on this virtual machine. So, now we enter a Windows 2000 bootable CD into the physical CD drive (or whatever OS you have selected) on the physical machine and press a key. The virtual machine starts the setup program of Windows 2000. This now allows you to install the OS the same way as you would on your physical machine. While the install runs, you can see the VHD file growing. New data and files written on the virtual disk are written to the VHD file that dynamically grows.
The mouse is a shared resource between the host and guest machine. Clicking on the Virtual PC window hands the mouse control over to the guest machine. Pressing the host key, which is by the default the right ALT key, hands the mouse control back to the host machine. You also see a separate mouse pointer for the host and guest machine. Clicking on the Virtual PC window hides the host mouse pointer, because the control is now with the guest machine. Pressing the host key shows again the host mouse pointer because control is now back to the host machine, while it also continues to show the guest mouse pointer itself in the Virtual PC window. The keyboard is a shared resource as well. Handing over control of the keyboard to the guest machine can also be achieved by clicking on the Virtual PC window. Handing control back to the host machine is done by pressing the host key and then clicking with the mouse on any window on the host machine.
You can change the host key from the Virtual PC console through the "File | Options" menu. This provides general mouse, keyboard, display, and performance settings for Virtual PC. Select "Keyboard" from the list, click in the "Current host key" textbox, and press the new host key you want to use, for example the left CTRL key. When on the guest machine, pressing the host key + ENTER allows you to switch between window and full-screen mode and pressing host key + ARROW DOWN minimizes the Virtual PC window to the task bar on the host machine.
When you log on to the guest machine, you need to press CTRL+ALT+DEL, but that key combination is always handled by the host machine. To send this key combination to the guest machine, select the "Action | Ctrl+Alt+Del" menu on the Virtual PC window. You also can change the screen resolution on the guest machine. By default, this is 640x480; changing it to 800x600 will automatically enlarge the Virtual PC window. If you run Windows on the guest machine, you should install the "Virtual Machine Additions." To install these additions, select "Action | Install or Update Virtual Machine Additions" on the Virtual PC window. This launches the setup on the guest machine itself and when completed requires you to reboot the guest machine. These additions provide a smoother integration between the host and guest machine:
- Single mouse—There is no longer a separate mouse on the guest machine. You only see the mouse of the host machine. You can simply move the mouse in and out of the guest machine. Clicking on the Virtual PC window will translate it to a click on the guest machine at the exact location you clicked.
- Single keyboard—Guest and host machine share the same keyboard. When the Virtual PC window has the focus, all key strokes are sent to the guest machine.
- Sharing—The guest machine now can connect a share to the host machine. In the status bar of the Virtual PC window, you see a number of symbols, the fourth one being a folder symbol. Right-click on it and select "Share folder" from the popup menu. Now, you can select to which folder on the host machine you want to connect to plus in the lower right corner whether this share is permanent (Share every time). In the lower left corner, you choose the drive letter to use. Go to "My Computer" on the guest machine and you can open up this new drive. This provides you the same access to the host machine as your current security governs.
You can install applications on the guest machine the same way as you would on your physical machine. You can create as many virtual machines as needed and you can run as many as needed, provided you have enough resources. If you have only 512MB RAM, you won't be able to run five guest machines at the same time. If you have only a 1GHz processor, you will strain the system running five guest machines at the same time. But, there are a number of actions you can apply to running guest machines (through the Action menu on the Virtual PC window):
- Pause—This will halt the execution of the guest machine. It will no longer take any CPU cycles but it will not free any used memory.
- Resume—This will resume a halted guest machine. So, Pause and Resume allow you to freeze and unfreeze a guest machine.
- Reset—This is like pressing the reset button on your physical machine. It restarts the guest machine.
- Close—This closes the guest machine and provides three choices. It is also called when you simple try to close the Virtual PC window with the Close icon in the upper right corner.
- Turn off—Is like switching off your physical machine. It will close the guest machine and free up all its resources. It does not perform a log off and shut down; it just kills it.
- Shut down—Is a graceful shut down of the guest machine. So, it logs off the user, shuts down the guest machine, and then frees up all its resources.
- Save State—This is like the "hibernate" option of your physical machine. It saves the current state of the guest machine and then frees up the resources. The state is written into a VSV file at the same location where the VMC file is located. The Virtual PC console shows the guest machine as saved and you can start it again which is the same as waking up your physical machine from the hibernated state. Starting a guest machine from the saved state is very quick.
The "saved state" is an option to quickly bring a guest machine back online as needed. For testing and training purposes, it is sometimes very useful to be able to restore the guest machine back to a known state. This can be achieved via an "Undo Disk." Open up the Settings of a virtual machine and select the "Undo Disks" item in the list. On the right side, select the checkbox and save the settings. This can be done only when the guest machine is not running and not in a saved state. The next time you start the guest machine, it creates a VUD file (Virtual Machine Undo Drive) in the same location where the VHD file exists. Any change you make while running the guest machine is no longer done on the virtual disk but on this undo disk. When you shut down or turn off the guest machine, it allows you three options:
- Delete undo disk changes—All changes will be discarded and the VUD file deleted. The next time you start the guest machine, it is at the same known state as before, the state stored on the master disk (VHD file).
- Save undo disk changes—Save all the changes on the undo disk (VUD file) so they are available next time. But, the changes have not been made part of the master disk (VHD file).
- Commit changes to the virtual hard disk—All the changes are made permanent by writing them on the master disk (VHD file) and then the undo disk (VUD file) is discarded.
Resetting the guest machine will warn you that all the changes on the undo disk will be lost. You also have control about the network connectivity of each guest machine. Open up the settings of a virtual machine and select the item "Networking" from the list. You can configure multiple network adapters for the guest machine. For each, you have the following choices:
- Not connected—No network connectivity. If chosen for all network cards, it means that the guest machine runs standalone.
- Local—Provides connectivity between any guest machines running on your host machine. Neither Internet connectivity nor connectivity to the host machine is provided.
- Shared Networking (NAT)—This option is only available for the first network card. Virtual PC creates a private network and also runs a virtual DHCP server and virtual network address translator. Connectivity to other systems is done through the host. This is useful when you are connected to an ISP that limits the number of machines you can connect to it. Only the host machine is connected to the ISP and gets its IP from the ISP. Your guest machine gets connectivity through the host machine.
- Network adapter of the host—The guest machine uses the network card of the host machine. The machine appears and behaves like any other physical machine on your network.
Virtual PC is a powerful desktop virtualization solution. It provides a lot of control and can solve most desktop virtualization needs. It can reduce complexities and costs from a variety of projects. Virtual PC does not support USB drives nor does it support SCSI drives.