Template build process

This post will show a really cool way of using vCloud Director with SCCM and vOrchestrator to build VDI templates and distribute them to vCenter servers across my environment with zero human interaction. Unfortunately I won’t be posting the actual workflows due to the fact that they are pretty specific to my environment, but I will try to post as much code that I can so that you can get some ideas from seeing what I did here.

Building the templates

For various reasons we build our VDI templates using SCCM task sequences, this preloads the applications that the different lines of business need and prepares it for deployment using View. The actual process is that you boot up a virtual machine using a special boot cd and it reads a config file from the floppy drive that tells it which SCCM task sequence that it should join. At the end of the task sequence it runs sysprep and shuts the vm down, this signals that it is ready to be used as a template.

One of the SCCM Wizzards (@Michael_Martian) at work came up with this method and I think it is really cool. Basically he created a vApp template that has one VM for each build type (Mortgage, Insurance, etc.) in it and each one has a unique floppy image that designates the SCCM task sequence. This means that when we need to refresh our templates, all we have to do is to deploy the template builder vApp, power it on and wait for the VMs to power off. Pretty cool, huh?

If we were to stop there we would have a cool automated way to build new VDI templates once a month, but since I enjoy automating as much of the process as I can I just can’t stop there…

Orchestrating the vApp deployment

The next obvious step to automate is the monthly deployment of this template builder vApp so that I only have to click once or twice or even better, just have it scheduled and executed once a month.

The first part of the workflow is pretty simple, just deploy the specific vApp and wait for the VMs to power off.

The waiting part is just a while loop that checks the power state of every vm in the vApp and doesn’t continue until every VM has shut down.

I did find one gotcha where the power state of the virtual machine would never change, so I had to throw in a call to updateInternalState, but once I added that everything worked great.

vApp = newvApp;
var vmsStopped = false;

while( !vmsStopped )
{
	vApp.updateInternalState();
	var vms = vApp.getChildrenVms();
	vmsStopped = true;

	for each ( var vm in vms )
	{
		vm.updateInternalState();
		if( vm.vmStatus != VclVMStatus.POWERED_OFF )
		{
			vmsStopped = false;
			break;
		}
	}

	System.sleep(15 * 1000);
}

vApp = newvApp;

var vmsStopped = false;

while( !vmsStopped )

{

vApp.updateInternalState();

var vms = vApp.getChildrenVms();

vmsStopped = true;

for each ( var vm in vms )

{

vm.updateInternalState();

if( vm.vmStatus != VclVMStatus.POWERED_OFF )

{

vmsStopped = false;

break;

}

System.sleep(15 * 1000);

}

So at this point we have a template builder vApp that is deployed once a month and builds templates, the problem is that these templates are in vCloud director, not in vCenter…

Exporting the VMs

The last piece of the puzzle is to export the VMs from vCloud director over to vSphere.

The way I do this is by using the SSH plugin for vOrchestrator to execute ofvtool, which does the import/export for me. Ovftool has many options but in the end it is fairly straight forward, give a source and a destination and it will copy a VM between them.

Ovftool will let you specify most options as either the full name of it or the moRef, I decided to go with the moRef in as many places as I could to reduce the risk of some funky characters messing up the command line.

Here are some examples of where i add the moRefs to the command line:

    commandline += " --datastore=vim.Datastore:" + targetDatastore.id;
    commandline += " --name="" + targetName + """;
    commandline += " --vmFolder=vim.Folder:" + targetFolder.id;
    commandline += " "vi://" + getHostname( sourcevCenter.name ) + "?moref=vim.VirtualMachine:" + vmRef.moRef +""";;
    commandline += " "vi://" + getHostname( targetvC.name ) + "/" + targetDatacenter.name + "/host/" + targetCluster.name + "/"";

commandline += " --datastore=vim.Datastore:" + targetDatastore.id;

commandline += " --name="" + targetName + """;

commandline += " --vmFolder=vim.Folder:" + targetFolder.id;

commandline += " "vi://" + getHostname( sourcevCenter.name ) + "?moref=vim.VirtualMachine:" + vmRef.moRef +""";;

commandline += " "vi://" + getHostname( targetvC.name ) + "/" + targetDatacenter.name + "/host/" + targetCluster.name + "/"";

The other thing you can do is instead of specifying a username/password in the command you can give it a one time use clone ticket that you can get from the API, since it is pretty simple to do and since it means that I don’t have to hard code passwords in my workflow I went that way. You get the clone ticket from the SessionManager object, which is a property of a SdkConnection object.

    commandline += " --I:sourceSessionTicket=" + sourcevCenter.sessionManager.acquireCloneTicket();
    commandline += " --I:targetSessionTicket=" + targetvC.sessionManager.acquireCloneTicket();

1 2	commandline += " --I:sourceSessionTicket=" + sourcevCenter.sessionManager.acquireCloneTicket(); commandline += " --I:targetSessionTicket=" + targetvC.sessionManager.acquireCloneTicket();

The hardest piece of all of this was probably to translate the VclVM object in to a VcVirtualMachine object, but with some help from Christophe on the communities I got it figured out. You get the VimServer URL from the vCD object and then you loop through the VcPlugin.allSdkConnections array of known vCenter servers and if it matches you have your SdkConnection.

var vApp = VclVirtualMachine.parent;
var vdc = vApp.parent;
var org = vdc.parent;
var host = org.parent;

var providerVdcReference = vdc.toAdminObject().providerVdcReference;
var providerVdc = host.getEntityByReference( VclFinderType.providerVdc ,providerVdcReference );
var adminExtProviderVdc = providerVdc.toAdminExtensionObject();

var vimServerUrl = adminExtProviderVdc.getVimServers()[0].url;

var allVimServers = VcPlugin.allSdkConnections;
sourcevCenter = null;

for each( var vimServer in allVimServers )
{
    if( isHostIpMatch( getHostname( vimServer.name ), getHostname( vimServerUrl ) ) )
	{
        sourcevCenter = vimServer;
        break;
    }    
}

var vApp = VclVirtualMachine.parent;

var vdc = vApp.parent;

var org = vdc.parent;

var host = org.parent;

var providerVdcReference = vdc.toAdminObject().providerVdcReference;

var providerVdc = host.getEntityByReference( VclFinderType.providerVdc ,providerVdcReference );

var adminExtProviderVdc = providerVdc.toAdminExtensionObject();

var vimServerUrl = adminExtProviderVdc.getVimServers()[0].url;

var allVimServers = VcPlugin.allSdkConnections;

sourcevCenter = null;

for each( var vimServer in allVimServers )

{

if( isHostIpMatch( getHostname( vimServer.name ), getHostname( vimServerUrl ) ) )

{

sourcevCenter = vimServer;

break;

}

The resulting commandline looks like this:

/usr/bin/ovftool 
   --noSSLVerify 
   --machineOutput 
   --I:morefArgs 
   --I:sourceSessionTicket=cst-VCT-5268e31e-9c02-2534-42e3-cbee243a0acd--tp-03-FE-30-4D-EC-91-F6-36-DE-B4-B6-70-6A-A9-71-93-21-E1-C7-2F 
   --I:targetSessionTicket=cst-VCT-52d52c29-8ed6-33ad-bc64-da5ec5446e9d--tp-5F-27-AF-1F-F0-11-25-AD-FE-7D-5A-0A-E3-00-F7-50-F1-E0-E7-EE 
   --datastore=vim.Datastore:datastore-55 
   --name="Template-Win7x86-2012-11-04" 
   --vmFolder=vim.Folder:group-v75 
   --network=vim.dvs.DistributedVirtualPortgroup:dvportgroup-69 
   "vi://sourcevcenter.local?moref=vim.VirtualMachine:vm-7237" 
   "vi://destvcenter.local/Dest Datacenter/host/DEST-CLUSTER/"

/usr/bin/ovftool

--noSSLVerify

--machineOutput

--I:morefArgs

--I:sourceSessionTicket=cst-VCT-5268e31e-9c02-2534-42e3-cbee243a0acd--tp-03-FE-30-4D-EC-91-F6-36-DE-B4-B6-70-6A-A9-71-93-21-E1-C7-2F

--I:targetSessionTicket=cst-VCT-52d52c29-8ed6-33ad-bc64-da5ec5446e9d--tp-5F-27-AF-1F-F0-11-25-AD-FE-7D-5A-0A-E3-00-F7-50-F1-E0-E7-EE

--datastore=vim.Datastore:datastore-55

--name="Template-Win7x86-2012-11-04"

--vmFolder=vim.Folder:group-v75

--network=vim.dvs.DistributedVirtualPortgroup:dvportgroup-69

"vi://sourcevcenter.local?moref=vim.VirtualMachine:vm-7237"

"vi://destvcenter.local/Dest Datacenter/host/DEST-CLUSTER/"

End result

The end result is that I have a scheduled workflow that deploys a vApp, waits for it to build new VDI templates and then copies those VMs out to various vSphere servers in my environment. Pretty nifty.

Orchestrate This!

I would much rather spend an hour scripting a task than an hour doing the work by hand.

Building the templates

Orchestrating the vApp deployment

Exporting the VMs

End result

One thought on “Template build process”

Leave a Reply Cancel reply