Поделиться через

So you wanna build a VM....

  • Статья

Sorry for the delayed post....I was visiting my family in Canada and didn't get a chance to post before I left. 

In this post I'll get into how you go about building a VM. We wanted to make the product as flexible as possible and allow for the creation of virtual machines from a variety of sources without making it overly complicated. Most customers told us they have a handful of 'gold images' that they create VMs from - typically these are sysprepped VHDs. We centered a lot of the functionality around this concept but we also support alternative VM creation methods. I'll walk you through them some of our thinking.

Creating a VM from a Template

If you're planning on deploying lots of VMs, it's a good idea to use templates. In SCVMM, a template has three parts:

1) A sysprepped VHD - if you click on 'new template' in the library section of the UI we can create one of these for you from a VM if you don't already have one in the library. We basically sysprep the source VM and stash the resulting VHD into the library and it becomes part of the template. If the source VM for your template has multiple VHDs, you should select the VHD that contains the OS. You should also make sure you have the VM additions baked into your template to have the sysprep process go smoothly. Since the source machine is converted into a template, if you want to keep your original source VM in tact, make a copy before creating the template. The current version of SCVMM supports Windows 2000 and Windows Server 2003 templates. More operating systems will be supported in the next release (see the end of this post).

2) OS/Sysprep Settings - These are settings that tell SCVMM how to configure your OS. If you want to reuse the same sysprep setting across a set of templates (i.e. same product key, same admin password, timezone etc.), you can create and save what we call an "operating system profile" and store it in the library. When you create a new template (or a VM from a template), you can either specify the sysprep settings manually or reuse a pre-defined operating system profile. We did this to keep the number of templates you'd need manageable (or as manageable as possible). OS profiles are kept in our database. Logically you'll see them show up in the library and you can find them in our UI but you won't find them in your library file shares. If you use sysprep.inf files, you can associate this file to an OS profile and avoid directly specifying all of the settings as well.

3) Hardware Settings - These are settings that tell SCVMM what the virtual hardware for your VM should look like. Similar to OS profiles, we also support hardware profiles that you can save and associate with a template. When creating a new template (or VM from a template) you can either specify the virtual hardware settings or reuse an existing hardware profile from the library. Like OS profiles, these are logical entities that are stored in our DB. As a point of interest, you'll notice a CPU drop-down list that we provide during specification of virtual hardware. This actually came from our colleagues in the Capacity Planner team and was originally dreamed up by MS Research. At the time, it was somewhat of a science project to come up with software models of hardware but then along comes virtualization to put the technology to good use.....good thing for us.

 We arrived at this overall user model for templates after lots of customers told us that server build processes typically involve selecting hardware, choosing an OS and configuring the OS so we added SCVMM user elements for each of these steps. There are often additional build steps and we do support sysrep's ability to run individual commands once after customization is complete (this is a setting on the OS profile). You can independently save off a bunch of hardware and OS profiles even without templates so the system is pretty flexible. Personally I worried about the fact that this flexibility added too much complexity to the product but I think it worked out well since for simpler environments, you don't need to touch OS profiles or HW profiles at all and everything still works.

Now that you have a template in the SCVMM library, you can use it as the starting point for new VMs. When you launch the new VM wizard, just select a template from the library and all VM settings are defaulted to what was specified in the template. You can override the settings if you so choose. SCVMM builds the VM per your virtual hardware specs and apply the sysprep settings for you. If you go to the jobs UI can click on the running operation, you can see the steps involved in customizing a new VM in all of its glory. (You might notice that we create and remove a virtual floppy drive....we use this mechanism to inject the sysprep answer file into the build process).

If you create a new VM from a template, you'll notice that you cannot store the VM in the library and you have to actually place it on a host. That's because the customization step can't be done offline (yet anyways). If you want to pre-build a bunch of VMs from a template and stash them in the library via scripting, a good approach is to create a host group with one or more hosts and call it "maintenance hosts" or something like that. Have your script scope placement to that host group and once customization completes, you can script the saving of the resulting VM into your library. You can use a similar approach for patching images in the library but I'll provide a post with more prescriptive help there.

Creating a VM from an Existing VM or VHD

When you launch the new VM wizard, you're also given the option of creating a VM from a VM that you already have. The UI is slightly misleading here - if you hit the 'select' button after launching the wizard, you'll see a list of VHDs, templates and VMs in your library and you'll also see all stopped VMs on managed hosts. SCVMM always creates a copy of the source objects in this type of VM creation so your original VM, VHD or template is never moved or modified, it is 'cloned'. If you want to deploy the actual VM stored in the library rather than a copy of the VM, you can go to the library, select the VM you want and click the 'deploy' action which will physically move the VM from the library to a managed host for execution.

The key difference between using a template to create a VM versus a VM or VHD is that you cannot specify operating system configuration information (sysprep settings) with the latter.

Creating a VM from an Blank VHD

This is also supported in the event that you want to lay down an OS with PXE or perhaps drop an ISO image into a virtual DVD-ROM and install from scratch. This is a nice way to build a source image for a template. As a side note, you can attach an ISO from the library to a VM's virtual DVD-ROM and and select the option to use the library's copy rather than actually copying it local to the VM. This saves you from proliferating hundreds of ISOs with identical content all over your environment and sharing the central library copy instead. We got this feature request during one of our betas for customers using SCVMM to deploy VM additions via ISO images inserted into virtual DVD-ROMs.

 

 

 

Creating a VM from a VMware Virtual Machine

We had lots of customers asking for this functionality but didn't think we had time to get it in. However, due to the work of a couple of our hotshot developers and testers, we were able to ship this in V1. Just copy your VMs to a library share and then go to the library section of our UI and click on 'convert virtual machine'. You might need to refresh the library first since by default we only refresh new library objects every hour. You then point us at the .vmx file and walk through the rest of the familiar wizard and SCVMM does the conversion work for you. I should point out that this isn't just a format conversion.....vmdk to VHD is a trivial process. Actually ensuring the VM will run once converted can involve driver replacement, a HAL swap and disabling VMware tools (we disable the service, we don't uninstall). We reuse a good chunk of our P2V code and infrastructure to make this conversion process work.

Since this is often a scripted operation, here's an excerpt from our scripting guide that provides some guidance (Okay, it kind of uses a back door and goes directly against a file path rather than a library path....technically this isn't supported and you should use a library path to your .VMX file but this should work)

####################################################################

# Connect to the Virtual Machine Manager server.

####################################################################

# Substitute the name of your VMM server and domain in this command:

Get-VMMServer -ComputerName "VMMServer1.Contoso.com"

 

####################################################################

# Define variables.

####################################################################

# Substitute the name of your host server and domain in this command:

$VMHost = Get-VMHost -ComputerName "VMHost01.Contoso.com"

 

# Substitute the path to your .vmx file in this command:

$LegacyVM = "E:\VMWare\Windows Server 2003 Enterprise Edition (Dynamic)\Windows Server 2003 Enterprise Edition.vmx"

$Memory=256

 

# Substitute the name of your virtual machine for VM01 in this command:

$VMName = "VM01"

$VMPath = $VMHost.VMPaths[0]

 

####################################################################

# Run a VMM cmdlet that creates a job - in this example script, the

# cmdlet is New-V2V, so the job is the creation of a new VM from an

# existing VMware VM.

####################################################################

$VM = New-V2V -VMXPath $LegacyVM -VMHost $VMHost -Name $VMName -Path $VMPath -Memory $Memory -Runasynchronously -Jobvariable "Job"

 If you want to use VMware VMs in your library as a source, the following Powershell script should do the trick:

 

get-vmmserver –computername “VMMSERVER.CONTOSO.COM”

$vmhost = get-vmhost –computername “VSHOST1.CONTOSO.COM”

$library = get-libraryserver –computername “VMMSERVER.CONTOSO.COM”

new-v2v –LibraryServer $library –vmxpath “\\VMMSERVER.CONTOSO.COM\MSCVMMLibrary\VMDKS\ConvertMe.vmx” –vmhost $vmhost -name “DemoV2V” –path “C:\VHDs”

You do have to provide a host for this conversion to work since we need to fire up the VM to finalize the conversion. You can make a library server a host as well (just add it as a host and as a library in our UI) and have everything run local to the machine to expedite things. Alternatively, you could use the maintenance host group concept that I described earlier.

In the next version of SCVMM, we'll have the same core set of features and mechanisms to create VMs but we'll support new functionality available with our upcoming hypervisor currently not available in Virtual Server including multi--proc VMs, 64-bit VMs, direct disk access, higher memory limits and much more. Since we're supported VMware, you'll also be able to create these types of VMs on their platform too. We also plan to support templatizing (is that a word?) Vista and Windows Server 2008. We may have time to fit in Windows XP template support as well but we're not certain at this stage but a couple of customers have already asked for this.

You can get lots of additional information on creating new VMs and templates here.

I didn't discuss the P2V process in this post and I'll cover that in the future as it warrants a separate discussion. With P2V you can create a VM from a physical server and then use that as the basis for your template or other VMs as well so it just adds an additional source for new VMs.

rakesh

Comments