vCAC Inflate a Thin Disk

I had a customer contact me this week to ask about a vCAC custom property setting that didn't seem to be working.  The background is, they wanted to have all templates staged as thin provisioned but on deployment they would like them to be thick.

**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).

However, it seems that this custom property only works with new disks that aren't already part of the template.  This is what my customer was experiencing - the OS drive was deploying thin but any drives added during request time were deployed as thick.

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.

A Couple of Gotchas Using Out of the Box Content in Application Director

I thought I would share these - not major issues if you know about them. During a recent POC these came to light and hopefully will save others some time and frustration if you are using any of the OOTB (out of the box) content (services, application blueprints, scripts, etc). As I find other gotchas I may add them to this list.

Service - Microsoft .Net Framework 4.0

THE PROBLEM - Service exits with a non-zero errorlevel causing deployment to fail.

DESCRIPTION - I attempted to use this OOTB service to install .Net 4.5, thinking I could just substitute the content property "DOTNETFX40_EXE" and the DOTNET_VERSION property with the newer version (which WILL work - that's not the bug).  However, what I discovered was that .Net installer returns a non-zero error level (for reboot required) and the INSTALL script is a somewhat elaborate cmd file that traps this error and attempts to exit with an errorlevel 0.

The reason for this is that you really want AppD to handle the reboots so that the deployment workflow is resumed properly when the system comes back up.

But, as good intended as this install cmd script is, it fails to exit with an errorlevel 0.  This is because of the way batch/cmd scripts handle vars.  Basically, the manipulation of the errorlevel works but once the conditional loop is closed the original errorlevel is reset, the script exits with a "non-zero" and the AppD workflow fails.

MY FIX - I basically removed the script's conditional loop for trapping the non-zero errorlevel and added "set errorLevel=0" as the last line in the script.  My script looks like this -

@echo off

if exist %WINDIR%\Microsoft.NET\Framework\%DOTNET_VERSION% (

  echo Found %WINDIR%\Microsoft.NET\Framework\%DOTNET_VERSION%, the .NET framework of interest appears to have already been installed.

  echo.

   echo Skip .NET 4.0 installation. 

) else (

    echo Installing .Net Framework.

    start "Install .NET Framework" /wait "%DOTNETFX40_EXE%" /q /norestart

)

echo Installation Completed.    

echo This lifecycle always reboots. Rebooting now...

REM log the error level returned by the .Net installer for troubleshooting

echo Errorlevel NOW set to %errorLevel%

REM always exit with a zero

set errorLevel=0

Service - vFabric tc Server v2.7.1

THE PROBLEM - tcServer does not install and deployment fails.

DESCRIPTION - The required properties of the service were provided (or catalog values used where appropriate).  However, the install would fail with the error that the EXTERNAL_TEMPLATE could not be found - and that property is NOT shown as required.  This property is referenced in the CONFIGURE script and you can see on line 36 of that script there's a conditional check for the property and if it's populated then it is used - otherwise, nothing is done.  I believe the problem is with the script itself in that a NULL value for that property isn't evaluated as intended.

MY FIX - Really just put in any value there.  I noticed that the OOTB jPetStore Blueprint sets the value to the darwin_global.conf path (as used in the global_conf property) and that seems to work just fine.  Of course, if you actually HAVE an external template that path should be used.  Ideally, you could modify the service and set the property there so you could just use the catalog value each time.

Use vCAC Static IP Without vCenter Customization Spec

You are probably aware that vCAC has a nice little IP Address Management (IPAM)  capability built in (referred to as "Static IP" in the documentation) that allows you to create IP pools and settings with Network Profiles that can be associated to Network Paths in your reservations.  If so, you're also aware that using this out of the box for VMware virtual machines requires you to use VM templates and vCenter Customization Specifications*.

However, deploying a Windows VM with a customization spec adds time and if all you really want is the IP address assignment it can be annoying to have to use a customization spec.  In fact, the reason I'm posting this information is because I had a request from a customer to speed up the provisioning time while still using the Static IP feature.  The use case was they simply needed to spin up a Windows server for quick QA and then destroy it.  Now, there are some other ways to accomplish this (snapshot/revert comes to mind) but it did get me to thinking of ways to avoid running vCenter customizations on Windows clones to speed up deployment.

One way to accomplish this is with vCenter Orchestrator (vCO).  This post assumes some knowledge of and experience with vCO, but you may be able to put this together without that background.  

In general, a VM deployed with Static IP will have the following machine properties set with the values from the Network Profile:

VirtualMachine.Network0.Address

VirtualMachine.Network0.SubnetMask

VirtualMachine.Network0.Gateway

VirtualMachine.Network0.PrimaryDNS

... and optionally ...

VirtualMachine.Network0.SecndaryDNS

There are other properties for networking, but for our use case we will leverage these specific property values via the vCAC Extensibility Workflows.  These are included with the embedded vCO instance and you will want to go ahead and set that up if you haven't already.  See this presentation for an overview and setup walk-through.

In addition, I will use the Guest Script Manager Package for vCO to run the configurations directly on the new VM's guest OS - note that this requires VMtools to be installed on the guest.

*Static IP is also supported for AutoYAST/kickstart using the guest agent.  

Publish an Application Director blueprint to the vCAC Catalog

This post covers how to publish you VMware Application Director (AppDir) 6.x application blueprints to the vCAC 6.x catalog so that users can request them.  This post assumes you have a knowledge of AppDir blueprints and have configured AppDir 6.x with a vCAC 6.x cloud provider.

Choose the application and create a deployment profile as if you were going to provision the application from AppDir.  When you get to "Step 4: Review" you will notice that a "Publish" button is available.  This will allow you to publish the deployment profile to vCAC.

Clicking the "Publish" button will provide you a dialog to set the name and description for the catalog item in vCAC.

You may now save the deployment profile, there's no need to deploy.  From the vCAC 6.x interface, go to the Administration tab and select Catalog Items.  You will see your application there and you can configure it just as you would an IaaS or ASD service blueprint.  You probably want to set up another Service type for your applications.

Once configured and entitled, you can now request and provision the application from vCAC as well as view application deployment details once it is provisioned.

vCAC - Automatically Manage Local Administrator AD Groups

In my last post, we covered adding the VM requester's AD account to local administrators on the guest.  This is a quick and dirty way to getting the machine requester up and running with their new VM.  However, many organizations prefer to use AD security groups for this kind of access.  In fact, if you use an AD group to control local admins for a Windows VM, then you can create actions for the provisioned VM so that the owner can assign local admin to whomever they wish.

In this post we will cover the following use case - a new VM is requested and as it is being provisioned, a new AD security group will be created in a designated OU with the name of the VM and some custom suffix (like "vmname-localadm").  The requester of the VM will be placed into this group by default and the new group will be added to local admins on the machine after it has been built and customized.

vCAC - Add VM Requester to Windows Local Admin Group

This is a request that I get frequently.  The person requesting a Windows VM needs to be a local administrator, so that after the VM is provisioned they can begin to access via RDP and perform tasks that require this level of access (install software, for example).

This can be accomplished using the Guest Agent for vCAC.  Installing the Guest Agent on the VM template allows vCAC to perform many post-build activities such as running scripts.  In this post I will show how you can use the Guest Agent to run a script that will add the requester of the machine to local administrators group.

Note: Post updated with a new script that accepts UPN (as provided by vCAC 6.0) or sAMAccount (as provided by vCAC 5.2).  Thanks to Sam Pursch for testing and suggesting the fix!

Using vCAC Resource Actions

vCloud Automation Center 6.0 includes a new and easier way to extend the machine action menus so that you can add just about any type of operation to the list.  As you can see here, I've added an action to mount an ISO to a virtual CD drive on a VM.

What's involved?  Well, for starters you will need to have Advanced Services configured within you vCAC install.  If you have already set this up you can skip to CREATE A RESOURCE ACTION.

SETTING UP ADVANCED SERVICES FOR VCAC