by Greg Shields

One of the huge benefits Hyper-V’s virtualization brings to VDI is the ability to use differencing disks. These special disks allow you to create multiple virtual machines whose configuration is based on a master disk. With differencing disks, you start by creating a reference computer, the configuration of which will serve as your “golden image.” Once created and locked down, you then create one or more virtual machines with differencing disks that link to the master disk.

Hyper-V’s differencing disks are useful for pooled virtual desktops because with these desktops, users are never guaranteed to be connected to the same desktop. Instead, when they attempt to connect, they’re given the next desktop that’s available in the pool. If you’ve got 10 desktops in the pool, you’ve got 10 targets to which users can connect.

Using pooled virtual desktops for problem application hosting is a particularly smart idea because you can administer these desktops just like you would a typical RDS server. In an RDS server, you typically use Terminal Server Roaming Profiles (now, Remote Desktop Server Roaming Profiles) to inject user personality information to the session as the user logs in. You can do the same thing with pooled virtual desktops. Here, you assume that no user data will ever be stored on the desktop itself. In fact, as you’ll discover in a minute, Microsoft includes a setting that automatically wipes clean any changes made by the user as they log out of their pooled virtual desktop. Combining this capability with RDS-only roaming profiles ensures that every user always gets the same experience every time they log in.

To create your reference computer, open the Hyper-V Manager console and go through the normal processes of creating a virtual machine. For this example, your desktops will not run a server OS but instead a desktop OS such as Windows XP or Windows 7. Use the OS that works best with your problem application.

Once finished with the standard installation, be aware that Microsoft’s VDI solution requires non-standard configurations to be manually added. These configurations add support for remoting the virtual machine as well as ensuring it can be managed through Microsoft’s VDI. They are an absolutely required part of this step, as without them, you won’t be able to connect to your virtual desktops. Those settings are documented in the Installing and Configuring Virtual Machines section of Microsoft’s step-by-step guide, so I won’t repeat them here.

Once finished with the installation and special configurations, you can install your application to the virtual machine and complete any final configurations that should be replicated to the desktops you’ll later deploy. Finally, remember that the process of using differencing disks creates exact duplicates of your virtual machine-not unlike Ghost images. Thus, you’ll either want to drop the machine into Workgroup mode or run SysPrep prior to the next step.

Building the Differencing Disks

Now for the fun part: Creating the differencing disks and ultimately the virtual machines for your pool. This example will create two desktops from a reference image.

The OS on this reference image has already been installed and the special customizations required by Microsoft have already been undertaken. For this example, the machine has been reverted back to Workgroup mode in preparation for creating and linking differencing disks.

Differencing disks start their lives as a standard Hyper-V .VHD file, which by default is located in C:UsersPublicDocumentsHyper-VVirtual Hard Disks. Each time a virtual machine that’s based on a differencing disk needs to use a piece of data, the system internally determines whether that data is unique to the virtual machine (and, thus, within the virtual machine’s differencing disk) or if it is contained within the parent disk. For this reason, once differencing disks are created from a parent image, the parent image can never change. This includes interacting with it, or even powering it on.

As such, Microsoft’s recommendation is to set the parent disk to Read Only once it has been created and immediately before configuring your first differencing disk from it. Locate the .VHD file that’s associated with your reference computer and do this now. You might also want to remove the computer from exposure within the Hyper-V manager to protect yourself against confusion down the road.

Creating the differencing disks occurs outside the wizard that’s normally used for creating new virtual machines. In the Hyper-V Manager console, click New | Hard Disk, and create a new Differencing disk within the wizard. Give the new hard disk a name (using the name of the desktop is common) and location. Finally, specify the .VHD that will serve as the parent.

Another advantage of differencing disks is their small size. Remember that a differencing disk contains only the data that is different from the parent disk. For a 9.6GB parent disk, my initially-created differencing disk started with a paltry 321KB size. That size will increase as the virtual machine is used. Mine increased to around 1GB in size after changing the computer name and adding it back to the domain. That’s a much larger size, but still far below the parent’s 9GB.

Once complete, the process to create two new virtual machines with these disks uses the same process as any virtual machine creation. Click New | Virtual Machine to create the virtual machine, then answer the questions just like you did with the earlier virtual machine creation. Different here is that you’ll attach each virtual machine to one of the newly-created differencing disks. Finally, power on the virtual machines, rename them, and add them back into your domain.

You may need to review and reset some of the special VDI-related settings discussed earlier. Two in particular involve repopulating the Remote Desktop Users group with the users who will need access, and adding the computer account of the RD Virtualization Host server back into the virtual machine’s local Administrators group. Be aware that it may be possible (and far easier) to ensure these settings get re-populated by using Group Policy.

About the Author

Greg Shields is an independent author, speaker, and IT consultant, as well as a Partner and Principal Technologist with Concentrated Technology. With 15 years in information technology, Greg has developed extensive experience in systems administration, engineering, and architecture specializing in Microsoft OS, remote application, systems management, and virtualization technologies. He is a Contributing Editor and columnist for TechNet Magazine and Redmond Magazine, and serves as the Series Editor for Realtime Publishers, the world’s leading provider of high-quality content for the IT market. Greg is a highly sought-after and top-ranked speaker for both live and recorded events, and is seen regularly at conferences like TechMentor Events, Microsoft Tech Ed, VMworld, and more. He is a multiple recipient of Microsoft “Most Valuable Professional” award.