VMware Cloud Community
scrappydoo99
Contributor
Contributor
Jump to solution

ERROR - The guest operations agent could not be contacted

Hi,

We have a workflow that clones a vApp, and after VMware Tools starts in one of the cloned VMs, we run a batch script using the "Run program in guest" workflow.  We run this cloning process multiple times without issue, but 1 out of every 5-10 ends with the error of "The guest operations agent cannot be contacted".  Does anyone know what may be causing this issue or how we can implement a workaround for it?

Thanks,
Dan

Reply
0 Kudos
1 Solution

Accepted Solutions
Burke-
VMware Employee
VMware Employee
Jump to solution

I'm not terribly sure what would be causing this... intermittent errors like this are always a big challenge to get resolved. I can make a suggestion on the work-around however. I would suggest adding exception handling to the Run program in guest part of your overall workflow... Drag a Scriptable task or logging element and drop it onto you existing call to the run program in guest part of your workflow. This will create a new path with a red-line (exception path). On the run program in guest element, you will now need to Bind the exception to an attribute -- default name for this is "errorCode" - go ahead and create that attribute and use it for the binding. Next, pass that errorCode into your new logging element or scriptable task to provide some feedback/indication that there was an issue and you are re-trying. Add a sleep or wait for time element (requires setting the time to wait for) in order to add a little pause in the workflow. Then, delete the end element of this exception path and connect the last element back up to the Run program in guest part of the workflow.. so the flow should be something along the lines of:

  1. Whatever pre-processing you do
  2. Clone/customize VM
  3. Run program in guest
    1. if exception, wait 30 sec (or whatever time) and try again
    2. Optionally, set a max number of retries and implement a counter to track these - if max is met, then throw exception and/or e-mail notification
  4. End of workflow
If my answer resolved or helped you, please mark it as Correct or Helpful to award points. Thank you!

Visit http://www.vcoteam.info & http://blogs.vmware.com/orchestrator
for vRealize Orchestrator tips and tutorials - @TechnicalValues on Twitter

View solution in original post

Reply
0 Kudos
4 Replies
Burke-
VMware Employee
VMware Employee
Jump to solution

I'm not terribly sure what would be causing this... intermittent errors like this are always a big challenge to get resolved. I can make a suggestion on the work-around however. I would suggest adding exception handling to the Run program in guest part of your overall workflow... Drag a Scriptable task or logging element and drop it onto you existing call to the run program in guest part of your workflow. This will create a new path with a red-line (exception path). On the run program in guest element, you will now need to Bind the exception to an attribute -- default name for this is "errorCode" - go ahead and create that attribute and use it for the binding. Next, pass that errorCode into your new logging element or scriptable task to provide some feedback/indication that there was an issue and you are re-trying. Add a sleep or wait for time element (requires setting the time to wait for) in order to add a little pause in the workflow. Then, delete the end element of this exception path and connect the last element back up to the Run program in guest part of the workflow.. so the flow should be something along the lines of:

  1. Whatever pre-processing you do
  2. Clone/customize VM
  3. Run program in guest
    1. if exception, wait 30 sec (or whatever time) and try again
    2. Optionally, set a max number of retries and implement a counter to track these - if max is met, then throw exception and/or e-mail notification
  4. End of workflow
If my answer resolved or helped you, please mark it as Correct or Helpful to award points. Thank you!

Visit http://www.vcoteam.info & http://blogs.vmware.com/orchestrator
for vRealize Orchestrator tips and tutorials - @TechnicalValues on Twitter
Reply
0 Kudos
MKguy
Virtuoso
Virtuoso
Jump to solution

This sounds like the exact same error that PowerCLI is spilling with the Invoke-VMscript cmdlet when it can't communicate with the VM's VMware Tool Service. This was fixed in the 5.0 U2 and 5.1 U1 tools packages:

http://alpacapowered.wordpress.com/2012/12/03/invoke-vmscript-issue-the-guest-operations-agent-could...

Are you running a recent version of the VMware Tools in these VMs?

-- http://alpacapowered.wordpress.com
Burke-
VMware Employee
VMware Employee
Jump to solution

Nice - thanks for sharing MKguy - I wasn't aware of this... Hopefully we can get scrappy back on track with the solution Smiley Wink

If my answer resolved or helped you, please mark it as Correct or Helpful to award points. Thank you!

Visit http://www.vcoteam.info & http://blogs.vmware.com/orchestrator
for vRealize Orchestrator tips and tutorials - @TechnicalValues on Twitter
Reply
0 Kudos
scrappydoo99
Contributor
Contributor
Jump to solution

We are on version 5.5.  It turns out that it was a timing issue and the exception loop helped get us around the issue.  Someone had made a change to the esx host which caused the OS to be really slow booting up.  My understanding is that once VMware Tools was running, the script would be able to run which is not the case.  If we add a 15 second delay in there after waiting on VMware tools to start, the script starts running fine.

Thanks Burke & MKguy

Reply
0 Kudos