VMware Cloud Community
lurims
Enthusiast
Enthusiast

vRA VM stuck in "Turning on" state for ever

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?

Tags (1)
Reply
0 Kudos
4 Replies
daphnissov
Immortal
Immortal

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.

eoinbyrne
Expert
Expert

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

pastedImage_0.png

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 Smiley Happy

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

lurims
Enthusiast
Enthusiast

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.

Reply
0 Kudos
eoinbyrne
Expert
Expert

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?