vCAC Day 2: Detach Linked Clone VM

This post will demonstrate another very cool day 2 operation, detaching a linked clone VM. Though I didn’t implement it as part of a customer engagement, it just occurred to me that this can be done with some of the great vCO / ASD Day 2 operations.
In vCAC, when creating a linked clone blueprint, one must properly design the hardware infrastructure underneath. Or more correctly, your underlying storage.

There are many storage considerations that needs to take place when designing a Dev / QA typed linked clone environment with vCAC, since vCAC unlike vCD, doesn’t currently abstract the underlying linked clone machine management.
While this is not an issue if planned correctly, performance hits are something that can always lurk behind dark corners, when many VMs are using the same Read-Only replica.

This, got me thinking. If vCAC doesn’t do any abstraction on the VM provisioning layer like vCD, you could actually detach, or inflate, a vCAC linked clone vm, with a simple API call to vSphere. Thus, turning the VM to a full-clone machine, totally non-dependent on the ‘source replica’ it was generated from.
This is also an API call generally available in vCD as well as a ‘Consolidate’ operation. It’s available in the vApp VM menu given the right permission, and that the VM is powered off. BUT, in vCD, if a VM is consolidated it still won’t be able to do stuff as hard disk resizing – while vCAC VMs – CAN!

Thus, the main difference though is that vCAC VMs , when detached from their linked-clone replicas, just turn into day to day vsphere VMs, while vCD VMs will still be under vCD’s ‘Hard’ management thus a bit more tricky to back up / restore etc, and still retain the OvDC Linked Clone policy in some forms.

The Technical Details

Essentially, the API call we are going to utilize is for a VC:VirtualMachine object. The method is called ‘promoteDisks_Task’ we can see in vCO, that this method accepts two parameters,an array of which disks do you want to promote, and whether to detach them from the link clone replica.

Screen Shot 2014-11-09 at 11.18.14

We’ll create a workflow for our Day 2 Op. Since the VM needs to be powered off during this operation, we will prompt the user for the best time for shut-down of his VM, by choosing an input of ‘date’ type (ASD will take care to present it automatically with a nice calendar. How cool is that?!) The second input for the workflow is the VM itself of course, of type VC:VirtualMachine.

With vCAC 6.1, we can create 2 workflows to run at separate cases, when the VM is Off, or On. The Off state workflow will not contain a date input, and the On Status workflow will. For this blog’s purpose, i’ll demonstrate only the On status workflow.

The workflow, will wait for the time specified by the user, then power off the VM grace fully, then, it will invoke the promote disks api call (we’ll get that in a second) and last it will wait for the generated task to end. Of course you can also opt to power the VM back on again.

Screen Shot 2014-11-06 at 18.12.15So what is in that scriptable task you ask? first , the scriptable takes in the VC:VirtualMachine parameter, and as out parameter has a VC:Task object (the task generated from promoting disks). The actual code that’s in there is:

[code]vcTask = vm.promoteDisks_Task(true)[/code]

This line of code will execute the promoteDisks task, on all of the VM disks, by specifying a null array, or only one parameter. Second parameter is ‘true’ for detaching disks (rather then just consolidating them).
Once the user will submit the request, vCO will do its thing, and by morning, that VM will turn into a regular boy! (VM!). The time this task takes may vary according to disk size, etc.

Once we have the workflow ready, we’ll configure it as an ‘On Status’ Day 2 operation like so:

Screen Shot 2014-11-15 at 12.24.16


And create an appropriate form for it:

Screen Shot 2014-11-17 at 11.41.12

As far as IaaS reservations , and policies for the user using up storage space, a check can be made to see if the VMs data store has enough room for the operation. Part from that, vCAC will actually calculate a full-disk usage on your reservation when you use linked-clones. This is due to the fact that linked clones are able to reach maximum VMDK size, thus , causing over allocation of their owner reservation. With this default method of calculating reservations, we can give our users the option to detach their VMs without worrying that their reservation will be over-subscribed.

As funny as it may seem, I couldn’t get a working vCAC system to demonstrate this fully and take screenshots, but really wanted to get this post out as soon as possible. I‘ll update it hopefully soon with the rest of the screenshots showing the VMs turning to full clones after the day 2 initiated.

Also, a thank you is deserved for Niran Even-Chen my VCDX friend for letting me use his 6.1 system, to take the screenshots above. Go check out his website –

vCAC Day 2: Un-Archive VM

So, for a recent project of mine, I was requested with a cool ‘vCAC feature’ being able to archive, and un-archive a vCAC managed VM. I’ll explain the meaning behind the request.
Basically, the customer wanted to have his old VMs moved to low tier storage (SATA spindles), as part of the archiving process, in order to save on expensive storage, and of course for them to be able to back up ‘archived’ VMs in a certain manner, etc.
In order to achieve this, I leveraged two of vCAC’s abilities:

  • Use / Create a “Machine Expired” workflow stub.
  • Created a Day 2 Operation with vCO , to do a couple of things:
    • Storage vMotion the VM to its original datastore
    • Submit a lease extend request so the user won’t have to do two operations.

An “Expired” state workflow already exists in the vCAC stub workflow library, so its pretty simple to utilize it in order to trigger a storage vMotion operation to move an expired VM to a predefined storage location.
All we have to do next is to keep the original storage location in a custom property, for later use, to be able to get the VM to its original location.

I’ve created a custom property called “VirtualMachine.OriginalDatastore” and assigned it to my vSphere blueprints. What we need to do next is to write a vCO workflow to update that property with the VMs datastore ID when the machine’s expired, and also trigger a simple Storage vMotion to a predefined location (or an archive storage location that is decided by what ever logic you choose.

To trigger the expired vCO workflow, we can either use the vCAC Designer , or the vCO vCAC plugin (Extensibility pack.
I’ll cover doing this with the extensibiltiy pack. Simply copy the workflow template from the vCAC Extensibility package (vCAC -> Infrastructure Administration – > Extensibility) and generate a new workflow off of it.

Archive Flow


(Action is ‘addUpdatePropertyFromVirtualMachineEntity’)
As for the scriptable code:
Basically i’m just preparing variables needed to update the property on the expired VM.
After that, i’m updating the blueprints property to store it’s original location, and the I svMotion it to Archive Storage.

Now for the cooler part – Un-Archiving / Un-Expiring the VM. Here, we will create an ASD day 2 operation, that will:

  • Read the previous datastore data for that VM, locate the datastore object.
  • Storage vMotion the VM to its original datastore
  • Request a lease time extension on behalf of the user, so the VM won’t be ‘Expired’ anymore.

And here is how the workflow for it looks like:



First off, i’m receiving a VC:VirtualMachine object from the day 2 operation (the VM the user is requesting the operation on) so in the first activity I find the vCAC IaaS object that is that vCenter VM, with an action.
After that, I need to check if the machine is actually expired, since this day 2 is meant for ‘Expired’ VMs. This , BTW, can be avoided with vCAC 6.1, since I can expose the ‘Un-Archive’ Day 2 operation only when the VM status equals ‘expired’.

If the VM is in an ‘Expired’ state, I continue to read the ‘Pre Archive Datastore’ cusom property I put earlier on in the VM. After that, I get the VC:Datastore object of that datastore. Now, you can notice that if I don’t find that datastore, I ask the administrator what to do. He can opt to cancel the entire thing, or to continue extending the lease on the current VM ‘Archive’ datastore and let it power-on there.
If I find the datastore, I svMotion the virtual machine to its correct datastore. vCAC will pick this change on the next data collection cycle.

Lastly, I generate an action request to change the lease, to the user’s chosen date. This workflow, also takes a date variable as an input. This will prompt the user for a date, with a nice calendar UI in the Day 2 operation form.

Since I won’t be able to really show you how this is actually done in this context, i’ll link you to a very helpful community article written by one of our vCAC vCO plugin lead developers, that will help you to understand how to submit a request in vCAC using vCO.

I hope you enjoyed this article, leave your comments below!

vCAC XaaS: Requester Details

The next couple of posts will be more focused about some nice vCAC XaaS things i’ve been doing lately. This post is probably a good way to get to know some XaaS tips & tricks.
When you create an ASD Service – e.g – XaaS / Day 2 Operation, you can get some of requester details , which are handed to you by the ASD/XaaS engine. This comes in VERY handy.

How can this be used? Well, for an example, if you build a catalog item that grants the user with a Virtual Desktop, meaning, a Desktop-as-a-Service , you will be able to determine who you need to entitle the new desktop for – seamlessly.
No need to query the user for their details (user name, department ) you might just want to query what the desktop is used for and why , and that’s itץ Advanced Service Designer will automatically fill the gaps for you.

The information that is retrievable is:
– By whom the Request was made
– Who was the item/day 2 requested for (in case of an ‘On behalf of’ request
– Tenant reference (which in vCAC is the tenant name)
– Subtenant reference – The business group uuid
– The catalog request id
– Any static parameter that was inserted in the ASD form.

In order to get these essential parameters, all we have to do is to build our Day 2 / XaaS request as usual, but then we can achieve the data within the vCO workflow in to simple ways:
1. Download this vCO package, containing actions to get the parameters
2. In scriptable tasks, you can use the code I’ll exhibit below

This code is essentially the same that makes up the vCO Actions in the ASD package I linked – but i’ll break it down anyway for you lazies :)
vco asd actions

Essentially what we’re doing is just grabbing some info from the vCO server runtime, by using this code to get the ‘Requested For’ parameter


What this piece of code will return, is basically the user name for the user who the requested XaaS , Day 2 Op is for, in a user@domain format.

This can also be used in conjunction to other parts of the vCAC plugin, grabbing useful business group information like the amount of Memory or Storage that the user’s business group is currently using. Though i’d generally recommend not to rely on implementing your own policy logic, and try to enforce business group policies through the IaaS engine when you can.

Again to break everything completely down, i’ll list the options of scriptable code writing in order to retrieve these details:


Also, you can notice that these variables automatically appear at vCO’s execution tokens. Taking a close look at the ‘variables section’ we can see them:
vco asd vars

So, start XaaS-ing and build awesome services and day 2 operations, extending your Private cloud with automated!
More blogposts are coming up on cool use cases where I used this XaaS capability. Any comments you have – Below!

There are no more results.