«

»

Heads up! vCloud Automation Center might delete VMs during import.

A few days ago i was informed about a potential problem/risk with the vCloud Automation Center (vCAC) 6.0 virtual machine (VM) import process. The problem can/will occur when you perform a VM import and using custom code in the (external stub workflow) during the vCAC VM provision state, WFStubMachineProvisioning.
If this external stub workflow fails, the VM your are importing will be deleted from the vSphere environment, since the vCAC workflow will execute the disposing state!
This can and most likely will ย cause a great deal of harm and not something you want to do in your environment or while on customer site.

I have been told there is an patch which prevents vCAC from either entering the disposal state if the external stub workflow fails or skips the external workflow state when importing VMs. ย Don’t know the exact details and i don’t know how to get it either, maybe you have to request it from VMware Global Support Services (GSS) directly.

Until you get the patch or if the problem is solved, maybe in vCAC 6.0 SP1 which hopefully is released soon, you can prevent this from happen by following the below steps.

  • Open a command (cmd) prompt on the machine where you have installed the vCAC Proxy Agent (vSphere Proxy Agent, vSphere Agent) and go to the agent installation directory.
    In my case “c:Program Files (x86)VMwarevCACAgents”
    In this directory you’ll find all installed vCAC Proxy Agents, in my case it is namedย vSphereAgent.
    Screen Shot 2014-02-03 at 15.52.43
  • Go to the vSphereAgent directory and youll see quite a few files:
    Screen Shot 2014-02-03 at 15.58.23
  • The .exe file we are interested in is DynamicOps.Vrm.VRMencrypt.exe.
    Run the following command to verify the command options:
    DynamicOps.Vrm.VRMencrypt.exe VRMAgent.exe.config
    The end of the output will be:

    • managementEndpointName
    • doDeletes
    • shutdownTimeout
    • statsInterval
    • statsNames
  • The output we are interested in is the doDeletes so lets list the current doDeletes config by running the following command:
    DynamicOps.Vrm.VRMencrypt.exe VRMAgent.exe.config get doDeletes
    The command output will looks like the below unless you haven’t performed any changes to the default settings:

    • managementEndpointName: vc-demo01
    • doDeletes: true
  • This confirms that vCAC will remove the VMs if the import fails so let’s change the setting by running the following command:
    DynamicOps.Vrm.VRMencrypt.exe VRMAgent.exe.config set doDeletes false
  • Verify the new setting by running the the same command as presented in the third bullet:
    DynamicOps.Vrm.VRMencrypt.exe VRMAgent.exe.config get doDeletes

    • managementEndpointName: vc-demo01
    • doDeletes: false

Now you can safely import VMs without accidentally having them removed in case your external stub workflow in the Provisioning State fails.

Just two more things.

  1. If the import fails the VM will be renamed in vCenter Server and placed in a vCenter Server Folder, in Virtual Machines & Templates view, called VRMDeleted.
  2. Remember this affects the process when you want to delete a vCAC based VM as well so change the doDeletes configuration back to true if you want to be able to delete VMs from vCAC User Interface.

Thanks to Kim Ranyard at VMware for the information.

1 ping

Comments have been disabled.