Tag Archives: vSphere

Automating vRA IaaS Blueprint creation with vRO

In some situations it might be very convenient to be able to automatically create vRA (vCAC) Iaas blueprints. However, since the IaaS part of vRA uses an OData API doing so is not a trivial task. OData is basically just a representation of the IaaS database. So there is no logic in front of it and thus no way to tell the API: “Create a blueprint for this VM please”. Previsously I talked a bit about the vCAC API. In this post I’ll get more practical and explain the steps involved when automating vRA IaaS blurptint creation with vRO.

Entities

All objects in the IaaS OData API are called entities. It doesn’t matter if it is a blueprint, a host or a build profile, everything is an entity. So in order to create a new blueprint we have to create a new entity. Which is done with the following line of code:

the createModelEntiy method  needs a couple of input parameters. The first one is easy, it’s the id of the vCACServer. This is the IaaS server object in vRO not the vCACCAFE host. You can just configure this server as an input of the workflow.

The second parameter is always “ManagementModelEntities.svc” and the third one is basically the table name of where the entity should end up. In the case of a blueprint entity it’s always “VirtualMachineTemplates” because that’s the table where the blueprints live.

Now for the tricky part: the parameter and links values.

Parameters

The parameters for the entity are basically the properties of the object. The trick is figuring out which properties to use. There are a couple of methods. You could create a simple workflow that just dumps all the properties of an existing blueprint entity in a log. I prefer using LINQpad because it also shows you the relations between different tables.

So which properties do we need for the blueprint entity and how do we put them into the parameters variable? The script below shows how to do this.

Obviously you might want to change the TenantID or get it from a variable.

Links

An entity object is basically an entry in a database table. This table links to other tables. So when creating a new entity you need to define to which elemetns in other tables this entity links to.

For blueprint entities there are 5 links to be set:

  • InterfaceType (vSphere in this case)
  • HostReservationPolicy (The reservation policy to deploy to)
  • ProvisioningGroup (A.ka Businiss Group)
  • WorkflowInfo (This is the kind of deployment you want. So for a BP that clones a template you need the Clone Workflow WorkflowInfo entity… still with me?)
  • GlobalProfiles (A.k.a Build Profiles)

This is how you put those links into a links object:

As you can see each attribute in the object is an array. The content of the array are vCAC Entities.  Most arrays have one value only the globalProfiles has multiple values if you have more then one build profile selected. In the code above I the buildProfiles variable is defined somewhere else and it is already an array so I left out the [ ].

Finding links entities

I guess you’re now wondering how to get the entities object for the links. You need to use the vCACEntitieManager to find these entities. Here is an example of how to find the WorkflowInfo entity for the clone workflow:

You can find the reservation policy by name in a very similar way:

If you have an array with build profile names as in input you can find all the corresponding entities with this piece of code:

If you want more of this in a workflow that’s ready to run, see the link at the end of this post.

Properties

So now we are able to create an entitie with the right parameters and links. After that’s successfully done there is one more thing we need to do: configuring the custom properties on the blueprint.

There are a couple required properties which start with a double underscore. Here is the list I used:

__buildprofile_order (order in which the buildprofiles are applied)
__clonefromid (id of the virtualmachineTemplate entity we created)
__clonefrom (name of the vmtemplate entity we created)
__clonespec (name of the customization spec in vCenter)
__displayLocationToUser (false)
__menusecurity_snapshotmanagement (false)
VirtualMachine.DiskN.IsClone (true for each disk)
VirtualMachine.DiskN.Size (the size of each disk)

You can set these properties with the “Update Property to Blueprint” workflow that comes with the vCAC plugin.

I used this script to generate the buildprofile order:

 Just give me the workflow

Too much information? I uploaded the example workflows to flowgrab. Find the download here.

A word of warning: The workflows might assume you’re using the vsphere.local tenant in vCAC. Should be easily fixable. If I’ve got some timeleft in the near future I might fix that myself. If you’re using another tenant you should be able to easily makes this work for you anyways.

How to Automate: PowerCLI

After writing my blog posts about the why and the what of automation I decided to write a bit about how to automate. This series of posts won’t go into much technical detail but rather offer some pointers to help you choose the right tool for the job.

When you think of automating tasks in a vSphere environment the first tool you probably think about it PowerCLI. For all less technical readers out there: VMware vSphere PowerCLI is a command line interface tool for automating vSphere tasks.

The Upsides

PowerCLI has the backing of a huge community. There are also plenty of books on the subject. On top of that there are a lot of command lets available from all kind of vendors so it integrates easily with a lot of products.

Thanks to the huge community it is pretty easy to learn PowerCLI or to build your scripts by just recycling code that can be found online and in books.

Another upside is that it is object oriented. This makes passing around information and monipulating the information pretty easy

The Downsides

The object oriented nature of PowerCLI could also be a downside depending on where you’re coming from. If you are used to writing bash scripts then some of the PowerCLI syntax may seem familiar but handling objects can be confusing.

Another disadvantage in my opinion is that you need a windows machine to run powershell. Me being a linux guy I really don’t feel a need to run any windows machine. Especially in lab environments where you can get away with running vCenter VA instead of the windows installation.

The last disadvantage is not specific for powerCLI but applies to scripts in general: Simple tasks are easy to automate but more complex tasks or long processes will result in huge scripts or piles of scripts which are hard to understand and very hard to troubleshoot and modify if needed.

The right tool for the job?

So is powerCLI the right tool for your job? Of course this depends on what the job is. I think it’s the right tool if you’re automating vSphere administration tasks. In that case it can make your life easier and save time. But if you try to automate whole IT Operations processes I highly doubt if this is the right tool you. More on that in a future blog post.