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.
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.
So 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:
And create an appropriate form for it:
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 – http://Cloud-Abstract.com