I spent most of my secondary schooling fearing the library. I didn’t want nor have time to read as I was busy socializing and when I wasn’t at school I didn’t want to think about reading. Fast forward a number of years and you will find that, oddly, I’m in love with the library and pretty fond of the Librarian. This isn’t the public library my friend but instead System Center Virtual Machine Manager (SCVMM) 2008’s Library. For this library, I play the snazzy cool role of Librarian as I own what goes in and what goes out. For users of SCVMM, you get to play this excellent role as well.
When I first started down the path of “checkin” out this library concept I was a bit “mystified” by it and wasn’t sure how it was used. In fact, for the longest time, I thought the library really played no “role” in production deployments. Shame on me…
In today’s post I’m going to focus a bit on the building blocks to getting started with rapid provisioning of systems utilizing Hyper-V & SCVMM.
The first thing that you have to grasp and understand is the concept of SCVMM profiles. There are two types of profiles in the library and those are “stored” as master items that span across all library servers. This is a key distinction from items such as VMs, VHDs, and templates who are individually stored per library server.
The first profile type is hardware and it is fairly straight forward. It defines a potential hardware “sku” as a virtual asset so that you can have custom definitions based on the purpose of the Virtual Machine. For example, the enterprise IT environment would have different memory & hard drive requirements for SQL servers than they would say a Active Directory domain controller. The former would probably have a great deal of memory and hard drive space while the latter would focus more on hard drive space as AD domain controllers don’t require a lot of memory.
Although the actual decisions for hardware that you make will vary, the steps for creating a hardware profile are the same (assuming you are using the VMM Administrators console). Let’s create a hardware profile for our base Windows Vista client machine -
The true power, in my opinion, is the sweet integration of base hardware with the ability to quick and easily customize the Operating System through the use of Guest OS profiles. This is extremely powerful for Windows-based OS’s such as Vista and Windows 7 through the use of SCVMM & Windows Automated Installation Kit (WAIK). In this step, I will show how to easily create a Guest OS profile though I will focus on the simple aspects of it and not so much the deep integration offered with WAIK (future post soon).
The guest OS profile is the ability to provide a name for new machines as well as set OS-related parameters such as:
SCVMM doesn’t use any special magic sauce to set these settings at run-time (e.g. creation) but instead simply injects a pre-compiled unattended file to the operating system. The format depends on the Operating System and the WAIK such as unattend.txt for Windows 2003 while it uses unattend.xml for Windows 2008. All the above data stored in the Guest OS profile is injected into a unttended file and off you go with a brand new sysprep’d machine with custom settings.
To create a Guest OS profile, you do the following:
That’s it. You now have the fundamental building blocks for building a virtual machine with all the settings and configuration desired.
The last part of today’s post will talk about how you can now leverage these profiles when building new Virtual Machines. There are two methods of usage – by SCVMM Administrators or via Self-help users using the SCVMM portal. For now, I’m not going to focus on the self-help (future post) and instead help those new to SCVMM.
The primary step used to create a virtual machine is the New Virtual Machine wizard in SCVMM. You have two options, use an existing VM, template, or virtual hard disk or to create the new virtual machine with a blank hard disk (RAW unformatted).
In order to expose your newly created profiles in this process, you will need to create what SCVMM calls “Templates.” The easy way I keep them separated in my mind is to remember that profiles are as “generic” as I can get and should work across your entire SCVMM infrastructure. Templates, on the other hand, add that next layer of complexity for your environment by allow you to use the generic profiles and “slightly” customize per location, area, etc. The key thing to point out is that templates are stored individually on library servers so you should ensure that you create the template where you want it to reside.
For example, I have three Library servers in our lab environment – 1, 2, and 3. For Library 1, I have the following:
On the other hand, for Library 2 I have the following:
The key thing I attempt to do is to create templates close to the actual hosts where the virtual machines will run, such as, on library servers in the same location. To create templates, you follow these steps outlined below.
When creating a new VM you can provide all the hardware & OS selections directly from the wizard or you can select pre-existing profiles to use. This becomes handy when you are trying to create multiple machines of the same “type” and want to ensure they are identical.
To create templates based on your new profiles, you do the following:
NOTE: When you change the underlying Hardware or Guest OS profiles, the template(s) are not automatically updated. You will need to update the template to take the changes.
This post focused on taking us back to the library and talked about how to utilize this very handy feature to drastically reduce your deployments. This is pre-cursor to digging a bit deeper into the Guest OS customizations and some examples of changing the base image utilizing WAIK. For now, though, you should be able to start thinking about how to break down your “deployments” into logical pieces that then you take actions on such as building profiles & templates.