Virtualization makes provisioning new servers a breeze. With the ability to turn server requests into a functioning workload in a relatively short time, server OS base installations from media are much faster. But the quickest and most efficient way to provision new virtual machines (VMs) is to create templates for different operating system types and workloads.
In this case, a virtual machine template is defined as a prepared Virtual Hard Disk (VHD) that can be repeatedly copied for rapid server provisioning. This strategy is most commonly used for desktop or laptop master images, where the operating system's identifying information has been stripped out and then captured with a third-party imaging product. This concept is similar to preparing a template in Hyper-V, but there is one major advantage: The hardware layer stays consistent. Typically, trying to get software, security patches and different integration agents from an older image on a newer laptop model with a differe...
To continue reading for free, register below or login
To read more you must become a member of SearchServerVirtualization.com
nt motherboard is difficult. This becomes a moot point when creating a VHD template because the hardware does not change.
Some IT professionals believe that building every VM from scratch is the best approach. But in my experience, using an exact copy of this original template allows for a standard starting point. If there is a problem with the template, it would be consistent across all systems using that template. At that point, one fix would correct all the affected servers. More than likely, though if there were a major flaw in the template, it would be obvious before too many were provisioned.
Creating templates in Hyper-V
So now that we've established how important -- and useful – VM templates can be, let's explore how they are created, the potential issues and ways to deploy them in Hyper-V virtual machines. In my environment, I've created a base of templates that corresponds to operating system versions and types. My main templates are for Windows Server 2003 and Windows Server 2008 Enterprise Editions.
I use Enterprise Edition because of how I license my virtual hosts with Windows Server 2008 Datacenter Edition (In a previous tip, I explained the reasons why I chose Datacenter Edition ). Enterprise Edition allow the greatest flexibility to expand resources such as RAM above the 4 GB mark if a particular application has a temporary or long-term need. Without Enterprise Edition, I would need to upgrade the OS from the standard edition or potentially rebuild the environment.
Remember: The more templates you create, the more you will have to update on regular basis. Starting with a few core templates and making the adjustments after the application deployment will save time over having many specific templates. Below is a table which outlines the template parameters that have been successful in speeding up deployments in my environment.
Windows Server 2003 Enterprise Edition 32-bit
Windows Server 2003 Enterprise Edition Internet Information Services(ISS) 6
Windows Server 2008 Enterprise Edition 32-bit
Windows Server 2008 Enterprise Edition 32-bit, ISS 7
Windows Server 2008 Enterprise Edition 64-bit
Windows Server 2008 Enterprise Edition 64-bit, ISS 7
System drive size
10 GB
10 GB
16 GB
16 GB
24 GB
24 GB
Number of CPUs
Up to two
Up to two
Up to four
Up to four
Up to four
Up to four
RAM size
As needed
As needed
As needed
As needed
As needed
As needed
D:\ drive size
As needed
As needed
As needed
As needed
As needed
As needed
As you can see, the size of the system drive is the only structural factor I set for the template. My approach is to create only the system drive for the base operating system -- whether the OS is Windows or Linux -- and then create a second or third drive for any data or I/O considerations an application may need (i.e. SQL data and log directories).
In a virtual environment, I also use fixed-sized disk instead of a dynamically expanding one to maximize VM I/O. For this reason, the drive sizes in the table may look a bit stingy. But in my experience, as long as most other application data lies on separate data drives, these sizes are adequate. As for any other resource, such as RAM or the number of CPUs, these will be related directly to the resources your application needs and provisioned at the template's deployment.
Additionally, consider the following tips when you create a new template:
- If you build a Windows Server 2003 template with one CPU, change the processor architecture in the device manager from uniprocessor to multiprocessor. This allows you to provision additional processors on other VMs using this template.
- The security identifier (SID) change and other software identifiers also need to be cleared before sealing your template. Sysprep or other SID clearing utilities are critical for proper domain functionality. Further, most applications that communicate with a server also have specific global unique identifiers that need to be cleared (i.e., antivirus application and Microsoft Windows Server Update Services).
Once your templates are prepared and sealed as a VHD, what's the next step? This depends on if you use a management application such as System Center Virtual Machine Manager (SCVMM) or the built-in Hyper-V Manager. At a basic level, you will be copying this sealed VHD to the drive where you want to create your next VM, creating the framework, (i.e. CPU, RAM and other disk space) and attaching the copied VHD. SCVMM uses a library where these templates can be stored and provisioned. Behind the scenes, though, it performs a file copy of the template and sets up the resources you specified in the wizard. Depending on the VM disk sizes and the network connection speed, this process can take as little as 10 minutes to prepare a fully functional OS for an application install.
As you begin to provision servers in this fashion, a new service-level expectation will emerge in your organization. With the creation of waiting templates, you can meet the "just in time" mind-set and respond quickly to requests in your data center. A VM workload can be provisioned quickly when it is needed, as long as there are enough host slots available. If you stay on top of the number of VM slots you have available, however, this is easier to plan for than trying to meet the needs of those requesting a physical server at the last minute.
Rob McShinsky is a senior systems engineer at Dartmouth Hitchcock Medical Center in Lebanon, N.H., and has more than 12 years of experience in the industry -- including a focus on server virtualization since 2004. He has been closely involved with Microsoft as an early adopter of Hyper-V and System Center Virtual Machine Manager 2008, as well as a customer reference. In addition, he blogs at VirtuallyAware.com, writing tips and documenting experiences with various virtualization products.
