**UPDATE** Turns out that the custom property below does work for me, in my lab. I had placed it initially in the storage property set of the blueprint, instead of as a blueprint property. So, at least for me, it does work but the solution below may be helpful for other use cases (like a resource action to allow a machine owner to inflate a thin disk).
**UPDATE 2** Sorry that this issue is a moving target, but after looking at this with my customer it seems that the issue is related to Storage DRS in some way. I'll update this post as I learn more.
What they expected (as I did) is that the custom property VirtualMachine.Admin.ThinProvision set in the blueprint with a value of "false" would deploy the machine's VMDKs as thick. Just a side note, if you deploy from template in the vSphere client, you are given the option to select the virtual disk format (i.e. "Same format as source" or thick, thin).
You can "inflate" a thin VMDK by browsing to it in the datastore browser and right clicking. However, it occured to me that this could be used as a work around for my customer using vCO and the vSphere plugin. So, I wrote a simple action that will inflate a VMDK if you provide the vSphere virtual machine object and the uuid of the VMDK - both bits of info are available using the vCAC Extensibility workflows in vCO.
I added the UUID because, as the vCO Masters have taught me, never trust a human generated name to be unique!
I have provided the vCO action within a package here. As always, nothing should be considered "production ready" until you review and validate it for your needs - this is an example only. I also assume you are very familiar with vCO, as well as with the vCAC Extensibility workflows.
Importing the package you will find the following:
- an action in com.storagegumbo.inflateThinDisk
- a workflow wrapper in storagegumbo.com/Inflate Thins/vCAC Inflate Thin Disk
I recommend you take a look at the action and fully understand what the script is doing. I did put some error checking in there but you may wish to tighten things up and add more error handling and logging.
As I mentioned above, you will only need two items of information - to be honest, this action was written with vCAC in mind and those items are easy to retrieve from vCAC using the extensibility workflows.
- virtualMachine will automatically be mapped by virtue of being type VC:VirtualMachine
- diskID is included in the vCAC VM property bag sent over to vCO as a string value, so we have a simple script in the wrapper workflow to grab that value (VirtualMachine.Disk0.ExternalID) and assign to the diskID. Input of vCACVmProperties will handle this for you.
Important point to note is that my workflow package ONLY inflates the first VMDK! So, if your template contains multiple disks, you will want to modify the workflow to loop through them all and inflate them - easy enough to do, but I had to leave you some work didn't I?
Another note to consider is that I have put in a power off and start VM workflow as well as a "wait" for the inflate task. I wrote this assuming that the workflow would be used as a WFStubMachinePovisioned call. If you are using for a WFStubMachineRegistered you may want to take note that the machine MUST be powered off for the inflate action to work.
You could dress this up a bit by checking the value of the custom property VirtualMachine.Admin.Thinprovision.
I believe this would also serve as an ASD workflow but may require some modification.