Any idea why vRA VM stuck in "Turning on" state for ever? This is like that since the VM is provisioned and it is been several months, and I am sure, we have rebooted the vRA instances in between couple of times. Any idea?
Could be that the guest agent communication was interrupted and wasn't able to signal the final task completion states. You may be able to forcibly destroy it from Infrastructure => Managed Machines.
You might be able to update the IaaS entity using the vRA Infrastructure plugin. Each vCAC VM has a vCACEntity as it's backing object. The backing entity has it's own set of properties and some of these can be changed.
so, if you have a vCAC:VirtualMachine object (use Server.findAllForType("vCAC:VirtualMachine") to get an array of all)
var vmEntity = vcacVirtualMachine.getEntity();
var vmEntityProperties = vmEntity.getProperties();
var vmState = vmEntityProperties.get("VirtualMachineState"); // in your case this will be "TurningOn"
to update you can use this OOTB action
and code like this
var updateProperties = new Properties();
updateProperties.put("VirtualMachineState", "On");
System.getModule("com.vmware.library.vcac").updateEntity(vmEntity, updateProperties, null);
This MAY work and if it does, the Managed VM state will change in the Infrastructure tab. However it is important to note that this will absolutely bypass the internal event system in vRA and so any Event subscriptions or other workflows will not fire. In addition, the associated CatalogRequest may not complete which will mean that the CatalogResources may not be created and made available.
LOTS of caveats to this
In practice, the safer way might be
- if you want to keep the actual Vcenter VM this entry represents --> unregister the VM if possible (or force the IaaS delete), terminate and clean up CatalogRequest + any resources, then re-import the VC VM into vRA management
- If the VM is not important, do as daphnissov suggests and just force the deletion to get rid of it
Thanks eoinbyrnefor detailed explanation and I like pointing that updateEntity. But what is missing that is causing the auto update by the vRA event system? Any idea? Instead of using the script or reimporting all VMs, I would like to see if I can fix it for good.
Sadly, as daphnissov suggested, there must have been a temporary interruption in the comms between the various components involved and the workitem chain was lost in the IaaS system. AFAI can piece it together from viewing ModelManager logs (and DEMWorker logs too), the workitems in vRA are the mechanism for transferring responsibility for a step around to the various actors. I've seen in some log files where a workitem report can be received but the matching queue/workitem data set is not found and so no processing takes place. It looks from the outside like workitem transfer is on an ACK free basis so the sender doesn't check or re-send if he can successfully transmit the workitem state once.
Like I said, at this point the data for the state of that VM is lost so you only have the choices outlined - bar raising an SR to VMWare support to see if they can come up a full and proper recovery.
It may be that some VMware employees are on here that can obtain more info - iiliev or others with his skills perhaps?