VMware vRealize Automation – Machine provisioned entered but guest customization still running

Have you ever been in the situation where you wish you could use the vRealize Automation guest agent (more information about the guest agent can be found at: http://pubs.vmware.com/vra-62/index.jsp#com.vmware.vra.iaas.virtual.doc/GUID-393ACC6D-5487-4805-8E41-FD3CDE40B9CF.html), however for security reasons a client does not allow it?

I faced this situation the other day and while this normally should not cause too much issues, the workaround simply means a bit more workflow development, still I have experienced some odd behaviors.

Before I go any further, let us go back for a second and review the phases in vRealize Automation. The following picture shows the lifecycle management of vRA and the different phases objects can be a part of.

lifecycle-vrealize automation

Overview of the lifecycle phases

The phases are:

  1. You request an object
  2. The object moves into the building phase
  3. Once the building phase is finished, the provisioned phase starts
  4. If all goes well the object will be released to end-user and enters the managed phase

Now the issue I have experienced is that if you don’t use the vRA Guest Agent, it actually moves sooner into the provisioned state then you would like it to do. In my case, the server was still busy going through its sysprep phase when my provisioned stub already kicked off. Obviously this is not exactly a desired behavior.

The problem

How can I tell my provisioned stub to wait until the sysprep is finished and I am ready to continue? Now one could say “add a Wait for VMTools action in your stub”. This is not really reliable if you look at the process of cloning a virtual machine or template with customization specification enabled. The process goes as following:

  • Machine is cloned
  • Machine boots with disconnected NICs
  • VMTools will start (Wait for VMTools check in the workflow can be bypassed at this point)
  • The customization specification will kick off the sysprep generalize
  • The machine will reboot after the sysprep
  • The machine goes through its sysprep phase
  • The machine boots and runs the “Run Once” scripts if specified

The solution

While there might be more than one solution for this particular problem, I will share you mine, which is based on the trick of using the vmtools daemon to set an advanced property that indicates that the machine is ready for the provisioning phase. A “RunOnce” command in the customization specification is used to put the advanced property using the vmtools daemon.

With the following code in the “RunOnce” of the customization specification, the advanced property (in this case we used the ‘guestinfo.build’ tag but this can be chosen as desired) will be set on the virtual machine:

cmd.exe /c c:\Progra~1\VMware\VMware~1\vmtoolsd.exe –cmd “info-set guestinfo.build true” > null

We put this in the “Run Once” because these commands are executed only when the customization (sysprep process) is completed.

Note: “Run Once” is only triggered when a user logs in the first time so it is advised to use it in combination with the autologon feature of the customization specification 

Only setting the advanced property on the virtual machine is not enough. In the provisioned stub we also need a process that checks if the advanced property is set to “true”. The workflow is illustrated below:


Illustration of the advanced property checking workflow

The code of the “Sysprep Status” scriptable task is the most important since this contains the logic to read the value of the advanced property. In the image below you can see the input and output parameters for the scriptable task. You obviously need the virtual machine object as an input parameters as well as the guestInfo string. This string contains the value of the tag you defined in the “Run Once” command (in this case I used the value guestinfo.build).


Code of the Sysprep Status scriptable task

The rest of the workflow components are for error handling, verifying the advanced property value or setting the time-out/wait period. Also note the use of the “vim3WaitDnsNameInTools” action to make sure the virtual machine is fully booted.

In the workflow we use the wait timer instead of the sleep function. Wait Timer is “the better sleep” as you can read here, all credits go to http://ullberg.us/orchestrate/277/getting-better-sleep!

The result

The result of using the different tools (advanced property and the workflow) is that it is guaranteed that the provisioning workflow will only continue to run when the guest customization is fully completed and this without using the guest agent.

I am looking forward to hear from you if you experienced the same or similar behavior and how you solved it?

Last but not least I would like to thank Tom Arentsen from Nubera for his contributions in this post.