Take your virtualization endeavors to the next level
In a recent project, I helped build a selfcontained virtualized infrastructure based on a couple of virtual machines (VMs) with AD, DHCP, DNS, RIS, and WINS services running on them. The team started with Microsoft Virtual PC 2007 and installed the latest Virtual Machine Additions. (To learn about the often-overlooked task of installing Virtual Machine Additions, see the Web-exclusive sidebar “Essential Virtual Machine Additions, InstantDoc ID 97288.) After placing the solution in production for a while, we saw that the VM infrastructure just couldn’t cope with the load that our project demanded. To solve the problem, we ultimately installed Microsoft Virtual Server 2005 SP1, and ported the VMs over by making the necessary modifications and attaching the VHDs to SCSI adapters.
Virtual PC is an excellent, inexpensive tool for building precinct environments, whether for Help desk support or for testing security patches before production rollout. But as your needs grow, you might encounter similar limitations in performance and scalability. Or perhaps you’ve already built a core library of VMs and would like to reuse them in a secured server-farm environment.
Virtual Server might just be the answer you’re seeking. Microsoft’s well-designed virtualization architecture permits an almost seamless integration and interoperability between Virtual PC and Virtual Server. After a couple of free downloads, and a little tinkering, you’ll be able to tackle any virtual environment.
For information about how to download both Virtual Server and Virtual PC for free, see the Learning Path. Before you start your download, however, you need to understand the subtle differences between Virtual PC 2007 and Virtual Server 2005 to help make porting VMs between the two platforms a little less painful. For the purpose of this article, all references are to Virtual Server 2005 R2 SP1 Enterprise Edition and Virtual PC 2007. Discussions about Virtual PC 2007 also apply to Virtual PC 2004 SP1, unless otherwise stated.
The design philosophies of Virtual PC and Virtual Server differ in their purpose and market segments. Put simply, Virtual PC targets the average desktop user, focusing on tight host-guest integration, ease of use, and a rich user experience. Virtual Server, by contrast, is aimed toward the enterprise-server sector, in which buzzwords such as manageability, scalability, and security are paramount.
Even considering this market distinction, you’ll find that Virtual PC and Virtual Server share a fundamental set of core features. The key enabler that facilitates VM porting between the platforms is the common file architecture: the virtual machine configuration (VMC) file and the virtual hard disk (VHD). The VMC file is an XML configuration file that contains metadata describing the VM. The actual disk storage as seen by the VM is enclosed in one or more VHDs.
The system automatically creates virtual machine saved state (VSV) files and undo disk (VUD) files, if enabled, in the same folder in which the VM is defined. The VSV file stores the suspended state of a running VM for restoration at a later time. The system writes changes made while a VM is in use to the VUD file, where rollback to a good known state can be accomplished by discarding the changes instead of committing them to disk. VSV files are incompatible between the two platforms. Hence, to avoid potential problems, modifications should always be flushed to disk and the VM properly shut down before moving VMs between Virtual PC and Virtual Server. The virtual network configuration (VNC) file is unique to Virtual Server and isn’t used under Virtual PC.
Moving a Virtual PC–built VM to Virtual Server is as simple as accessing Virtual Server’s administration Web site and specifying the fully qualified path of the VMC file under Virtual Machines, Add. I do recommend that you first use the Virtual Disk, Inspect option. Doing so helps to verify the integrity of the VHD, including any dependency, such as the case when the VHD is set up as a differencing disk linked to its parent, as Figure 1 shows.
You might have a need to port a VM in the reverse direction, from Virtual Server to Virtual PC—for example, when the target machine doesn’t have Virtual Server installed or you want to enable some Virtual PC–specific features. To do so, open the Virtual PC console and start the New Virtual Machine Wizard. Select Add an existing virtual machine and point to the fully qualified path of the VMC.
As you can see, deploying an existing VM on either platform is as straightforward as adding the VM itself. Nevertheless, a few device types and functionalities will behave differently due to architectural variation between the products Web Table 1 (InstantDoc ID 97084) outlines some potential interoperability problems.
Both Virtual PC and Virtual Server support a maximum of four virtual network adapters per VM. Although the internal VMC file structure is common, networking is one aspect that differs slightly on the two platforms. Virtual PC stores network-configuration information directly in the VMC file with the same name as the VM, under the ethernet_adapter section, which Figure 2 shows.
The actual description of host network adapters available to a user resides in the options.xml file, which resides at %APPDATA% Microsoft\Virtual PC. Because Virtual PC has no GUI front end for changing the network adapter name, you’ll have to modify <name type="string">Manufacturer Network Adapter Name</name> in the <virtual_network id="n"> section. Remember to make a backup copy of the file before editing it.
Virtual Server stores network settings in separate XML configuration files with a VNC extension. You’ll find them under %ALLUSERSPROFILE% Documents\Shared Virtual Networks, and only local administrators have access to this folder in a standard installation. By default, the system creates a number of files that match the physical network adapters present on the host. Suppose you have two internal network adapters, one wired and the other wireless. Virtual Server will create two files named External Network (manufacturer name and wired NIC model).vnc and External Network (manufacturer name and wireless NIC model).vnc. Additionally, Internal Network .vnc is also automatically created to facilitate VM-to-VM communication only.
Virtual Server lets you create an infinite number of virtual networks, each with a fully customizable virtual DHCP Server, as you see in Figure 3. There’s also no limit to the number of VMs that can connect to each virtual network. By separating VNC files that describe various common network settings, you achieve isolation without tying a physical network adapter to a specific VM or user.
Obviously, performance will suffer if you attach multiple network-intensive VMs to the same virtual network, which is typically associated with a physical network adapter on the host. The trick is to install multiple adapters on the host and distribute the load among the pool of VMs, according to usage and application needs Because of this subtle difference in virtual network configuration, moving a Virtual PC–created VM already configured with networking to Virtual Server (or vice versa) might result in an error, leaving the network adapter in an unplugged, unconnected state.
To connect to a virtual network under Virtual Server after importing a VM from Virtual PC, click Network Adapters, then OK after selecting the correct connection, as you see in Figure 4. Network connectivity will be available once the guest OS is started, without further configuration necessary.
Unfortunately, you must perform this manual process every time you move a VM from Virtual PC to Virtual Server. However, the reverse isn’t true. Alternatively, you can use a script such the one in Listing 1 to automate this task.
Putting It to Work
Now, let’s put everything into practice. In our sample scenario, we have a VM originally created with Virtual Server. We’re porting from Virtual Server to Virtual PC to take advantage of the new hardware-assisted virtualization support that’s available only in Virtual PC 2007. This also demonstrates the important fact that the VHD file structure is generic and can be attached to a different adapter type (SCSI or IDE).
- Ensure that the guest OS is properly shut down under Virtual Server.
- Make a backup copy of the XML-based VMC file.
- Start Virtual PC and walk through the New Virtual PC Wizard.
- Select the Add an existing virtual machine option, and specify the full path of the existing VMC.
- Inspect the VM settings, and notice that Hard Disk 1 and Adapter 1 appear as None and Not Connected, respectively, as Figure 5 shows. Before you attempt to start the VM, you must manually define a hard disk by attaching to the previously created VHD. If network connectivity is desired, you must explicitly connect a physical network adapter as well.
- You’re now ready to start the VM. Highlight the VM in the Virtual PC Console, and click Start. Immediately, you’ll see warnings about incompatible hardware settings. You can safely ignore these warnings by clicking OK.
- If you’ve explicitly selected the Enable sound card option in the VM settings, Plug and Play (PnP) will kick in automatically and you’ll be prompted to install the appropriate sound drivers in the guest OS. A reboot might be necessary, after which you can use the VM without further modifications.
Return of Investment (ROI) is key in today’s fast-paced and competitive landscape. Virtualization can let you ensure the timely support and coexistence of legacy applications, as well as handle the onslaught of new technologies. IT investments in Virtual PC technology can easily be expanded to a larger scale when your organization is ready to move up. The good news is that you can accomplish this ideal scenario without sacrificing compatibility or throwing money at costly retraining. All you have to do is dive into Virtual Server’s enterprise- class features.