Guest script manager package

Guest script manager package

- 2016-11-01 - Please note that this package has been relocated to the VMware Sample Exchange due to the recent decommission of FlowGrab.com.

- 2015-03-24 - The package is now hosted on fowgrab to allow communities contributions

- Updated 2015-01-05 by Daniel Linsley:

  • Does not break anymore with UAC but UAC may still prevent some scripts to run.
  • Improved sleep for better handling of low script refresh

Running commands or scripts in VM guest is something that has been done with vCO for quite a while using different mechanisms. A popular way was to use the VIX plug-in for vCO. This plug-in is not needed anymore since the VIX functionality is part of the vCenter API since vCenter 5.0 and there are guest operations workflows to copy a script and run it into a VM guest OS since vCO 5.1

Using these library workflows requires to copy scripts from the vCO file system or include the scripts in your workflows. Getting the script output can be tricky and if part of the script include parameters that need to be replaced with your custom workflows inputs it requires a bit more coding.

The Guest Script Manager handle all of this for you so you do not have to reinvent the wheel. You can even create specific workflows to run existing scripts without having to do any vCO scripting !

Features

Script management : Add, edit, delete a script configuration. A script configuration contains:

  • Script type (bash, batch, Powershell) : Each type involve a different way of starting the script and getting the output.
  • Script content: The script itself. May contain parameters that will be replaced right before running the script.
  • Timeout: The time after the script execution is
  • Script interactivity: In case the script open a window that requires user interaction.
  • Script working directory: Where the script will run. Where the optional file will be copied.
  • File to copy: A file to be copied in addition to the script. For example a response file needed for the script.

The script configurations are stored as resource elements in the vCO database. This means :

  • Updating a script does not require updating a workflow
  • The scripts are in a much safer location compared to the file system
  • If you run a vCO cluster, the scripts are available for every vCO nodes
  • That you can export / import the script configurations in a package

The script configuration runner : "Run script in VM guest"

  • Search replace specified strings in the additional file, copy it to the guest (optional).
  • Search replace specified strings in the script, run it in the guest.
  • Get output code and output result, display these (including special characters supported by ANSI thanks to the included cmdAnsi.exe), fails the workflow if script failed.

There is also a workflow to run multiple scripts one after the other and a workflow to upload your files as resource elements.

Links

Credits

  • Reuben for the original guest Operations package.
  • vCO Engineering to make available guest operations workflows in vCO 5.1
  • Benoit for the included / modified "run script in guest" workflow
  • Pierre Torris for creating cmdAnsi. Donateware on www.ptorris.com
  • Burke / Henrik for testing early releases
  • Daniel Linsley for providing enhancements to the original package

Known issues

You must turn off UAC on Windows (2015-01-05) Package updated by Daniel

Use the package with the date to get the latest. The other one was kept for people needing the original.

Disclaimer: These samples workflows are provided AS IS and are not considered production quality and are not officially supported. Use at your own risk. Feel free to modify and expand and share your contributions.

Attachments
Comments

I've got a very basic problem in trying to use this package. I've run the Add script configuration and specified a simple bash script. I can run the Edit script configuration and select my script to edit. However, if I try to Run the script, when I try and select the script to run, I can't get anything into the Scripts to run field. When I click the Not set link, I get the array box and click insert value. I get the Resource Element picker but there is nothing listed and nothing I put into the search box returns anything.

Am I missing something here? Seems like I should be able to see my script. I do see my script in the COE\guest script configurations Resource element tree so I know it's there. I can also browse to it if I try and set the attribute which holds the resource element as the workflow loops through the array.

Confused. Thanks for any help

Did you happen to remove the placeholder.txt resource elements?  If so you'll want to put them back.  What version of vRO are you running this in?

Any ideas on why bash scripts would not work for a redhat guest?  I can manually go mount a windows share, but when I run the same command through the guest script manager I get access denied and a NT_STATUS_LOGON_FAILURE on the guest.  Almost makes me think the command isn't passing through vco correctly.

Have you verified you can run a simple command like uptime or  a directory listing?  In our environment I have issues when I try to run workflows with any account that authenticates against our directory.  I've spent nearly zero time troubleshooting the issue since everything I work with I have root access to.  We use Vintella for user authentication in our environment and I know I run into authentication issues and I can't remember what the exact errors are.

It's really weird.  Our test environment works fine running these same commands.  One main difference is prod vCO was updated to 6.0.3, and test is 5.5.  Our prod is not really prod yet Smiley Happy  I can run a basic command to create a blank directory.  However if I literally try to just run a local script already on the guest with the commands all there to mount a drive.  That doesn't even work.  The workflow says it completes, but it really isn't because the mount is not there.  Testing this way I'm only authenticating locally to the server so that shouldn't be an issue.  I can login and run the same script locally and it'll work instantly.

Hello , I am unable to run the VRO to Guest copy workflow , getting below error .

state: 'failed', business state: 'null', exception: 'A general system error occurred: Failed to generate URL (Workflow:VPC3 / Scriptable task (item1)#14)'

But in another vCenter it is working fine .  I am sure it is some thing with VRO .

Ok so now that I have a firewall separating my vCO from servers, my copy file from guest to vCO is failing.  It's giving me a connection timed out.  Are there certain ports that I'll need to setup to allow this?  My scripts aren't working without it now.

I have two problems.

1)I am unable to import the package in vRO 7.0.0, it fails with java.lang.NullPointerException.

2) flowgrab is hosted outside the US which makes it incredibly difficult to download because of the ridiculous blacklist my company uses. Can we get a US based mirror to download from?

‌Here is a Dropbox downlink: Dropbox - guestscriptmanager-version-0.0.3a.package

THis version is also fixed, so it can be imported in vRO7 (indicated by my added "a" to the file name)

Anyone know the future of where we want to host this package?  Github? Last I saw flowgrab was going bye bye.  I've contributed a couple of small enhancements and bug fixes and I have another enhancement to add.  Last time I attempted to make any sort of mod I was unsuccessful... I forget why exactly... anyhow... if flowgrab evaporates I'd hate to see collaboration on this go away.  Its a core part of my workflow's.

Hi, we use this package extensively in our deployments - thanks for the great work!

Today, we had to restart vRO, because it had reached an open file limit.  Before restarting, we checked what files were in use, and realised that most of them (31,000+) were Run Script in Guest temporary files.  After a bit of investigation and experimentation, I narrowed the problem down to the action Read output file (item12).  This action opens the temporary output file on the vRO server and reads its content, but never closes the file.

Adding the line:

fr.close();

after reading the file fixes the problem.

I thought I'd mention it here, as it might save someone the vRO restarts we have suffered.

Regards, Paul.

THANK YOU!!! 

Anyone else thinks that GuestProcessInfo should be extended with stdout and stderr?

It would make things so much less painful. The current workaround the package is using to read the stdout/err by piping into a file, transfering the file to vRO and reading from the file is probably not the best way to handle things?

This worked fine in a previous version of vRO (7.0.1) but once I upgraded to 7.2.0.4629841 it no longer works!  Is anyone else having this problem?  I can edit and add new scripts but when I try to run one of them I get an error.

FWIW I'm running 7.2.0.4629841 4629841 in my Dev, Test, and Prod vRA environments and haven't had any issues using the latest version of the Guest Script Manager package.

Can you provide some additional details on the error you are receiving... running fine in my 7.2 environment as well.

I also upgraded to 7.2 last night and now having an issue.  It worked in 7.1

[2017-02-18 14:25:16.670] [E] (com.vmware.pso.GuestOps/testVmToolsForGuestOps) Error in (Dynamic Script Module name : testVmToolsForGuestOps#0) TypeError: Cannot read property "guest" from null

[2017-02-18 14:25:16.688] [E] Workflow execution stack:

***

item: 'Run Script In Guest/item13', state: 'failed', business state: 'null', exception: 'TypeError: Cannot read property "guest" from null'

workflow: 'VE_Core_StubMachineProvisioned' (a62f5e89-343d-45aa-a937-aca000df65d9)

|  'attribute': name=username type=string value=vertex

|  'attribute': name=password type=SecureString value=__NULL__

|  'attribute': name=scriptType type=string value=bash

|  'attribute': name=script type=string value=/opt/util/server/scriptsvecore.sh

|  'attribute': name=scriptTimeout type=number value=700.0

|  'attribute': name=scriptRefreshTime type=number value=30.0

|  'attribute': name=scriptWorkingDirectory type=string value=/opt/util/server/

|  'attribute': name=interactiveSession type=boolean value=false

|  'attribute': name=localadmin type=string value=__NULL__

|  'attribute': name=hostname type=string value=

What happens when you run the script just using the "Run Script In Guest" Workflow... it looks like its being called from a vRA lifecycle stub.  Maybe some value that is needed is not being passed in correctly?

It is a WF stub after machine provisioned. Havent re-wrote everything for the EB yet.

The only thing different was an upgrade from 7.1 -> 7.2

It was run hundreds of times with no issues before the upgrade.  I even created a new vRO machine external to vra and still get same error there.

I did just notice one thing when vRO was upgraded it upgrade the vCenter plugin to 6.5 but i am still running vCenter 6.0 plus it looks like it is saying "unusable" for my endpoint..

****Update*****

Somehow during the update the VC plugin set VC to "unusable"  I removed existing VC and re-added it and now everything is working  ~phew~ before work on Monday atleast

Hi Czernobog, i am running into a similar issue, Run script in vm guest fails because vRO can't copy cmdansi to the guest, my VRO is on a subnet on different location and there are firewall rules in place, i will try copying cmdansi to the VM templates manually but i am also trying to actually modify the script to not use cmdansi.exe, do you know if that would avoid it to run? also can you confirm only 443 is required between vRO and ESXi hosts? Or are there more ports required to allow guest script mgr to fully work?

did you ever figured the ports required? i have a similar issue.

Run script in vm guest fails because vRO can't copy cmdansi to the guest, my VRO is on a subnet on different location and there are firewall rules in place, i will try copying cmdansi to the VM templates manually but i am also trying to actually modify the script to not use cmdansi.exe, do you know if that would avoid it to run? also can you confirm only 443 is required between vRO and ESXi hosts? Or are there more ports required to allow guest script mgr to fully work?

cdecanini_​ Do you know if i can do a workaround to skip the steps to copy to and from vCO? I am having issues because of firewall rules between vRO and ESXi hosts in vCenter in which copying to the guest VMs fails for cmdansi.exe. I am trying to accomplish joining a VM to domain.

Do I need to do something special to use bash shell variables?  I've tried a simple script in both Run Script in Guest and Run script in VM guest and shell variables don't seem to work.

foo="bar"

echo $foo

The echo doesn't output anything.  I also tried exporting foo in case this is related to subshells, but that didn't work either.

Hi all - I have updated to vRO 7.3 in my lab environment (with new vcPlugin) and a lot of my existing uses of "Guest Script Manager" are now failing. Specifically if I run a script (it runs fine) reboot the guest os then run second script the second "Run Script in Guest OS" workflow fails with no exception thrown but an error in the vRO server.log.

Cannot connect factory (Reason: java.lang.IllegalArgumentException: interface ch.dunes.model.IVSOFactory is not visible from class loader) for wfExecution[ff8080815c1b5671015c1bc8d51c093b]

Any ideas - got VMware support case opened but thought I would raise here too as not sure if it is specifically guest script manager issue or vRO general issue.

Thanks for the heads up... I am planning to upgrade our lab next week.  I'll do some testing and report back.

Seems the Guest Script manager package itself is fine but it is more to do with how I was restarting the guest os and waiting for tools - Using builtin reboot guest os workflow --> set 30 second wait timer using timerdate --> then wait for vmtools was causing the above issue. Using builtin guest os workflow --> running System.sleep in a script --> wait for vmtools no issues at all. Weird

I must be missing something here. I have vCo v7.2 with the latest Guest Script Manager. When I do something like Run Script in Guest and chose powershell and under script put something simple like New-Item c:\scripts\new_file.txt -type file all I get returned is The term 'New-Item' is not recognized as a cmdlt or function.... If I log into the machine and go to the Temp folder and run the file manually it runs fine. Any ideas? Trying to run the script as local administrator.

Great utility package for our Day 2 operations on vRA 7.3, nice work!

We are running scripts on our IaaS Windows host through this package, but seeing about 15% failures, randomly.  This appears as "Error in (Workflow:Create temporary directory in guest / Scriptable task (item1)#8) The operation is not allowed in the current state".  Seems strange to get this error from the DEM machine, since it is always present and able to run commands.  This especially happens with provisioning multiple machines at once (concurrency issue)?  Permissions are solid on the IaaS box, so creating temp directories would not seem problematic.

Went ahead and made the prescribed changes to /etc/vco/app-server/js-io-rights.conf and restarted vRO; seems to be stable for a few builds, then bonks again.  Looking for any help on where to go next; going to start profiling the GSM code and see what's up.

We had the same issue and i found i was indeed concurrency issues. I just created a custom "Run Script in VM Guest" workflow that loops a few times. This resolved it. It also helped to prevent failures when the box was down for patching or something else.

Thanks for the validation, thought I was going crazy on the concurrency thing.  Was thinking about converting the script guest from Windows to Linux, since there was a nasty little footprint of temp directories and DLLs on the script guest.  Appreciate the workflow; will go that route first.  Nice!

Hey Peter I think I am hitting exactly the same issue you did... I just posted a new thread then saw this.  Seems like there must be a but in 7.3 or 7.x that is causing this.  In your environment could you restart the failed workflow and it would work?  This is what I have noticed... I think it may have something to do with the nesting or something else weird going on with the cache or something.  I also get a status of "Unable to initialize workflow handler" Did you see this in your logs?

FWIW i see the same issue on my Linux script box. Our Linux team will push out 50+ boxes via the cloud client at once and they would just time out on the scripts. This handles the load pretty well. My next project when i have time is to build something that lets me round robin or intelligently load balance scripts between multiple scripting servers.

Any ideas what an error "bash script type is not valid for OS null" means?  is it just the OS still booting up and vRO is trying to run actions against it? 

hi vExpert: Christophe Decanini , i posted this same as a question on the VIX forum, but just in case it is not seen too often here it is again. Appreciate your help in advance or anyone that has had a similar issue when vRO has to go to different networks where NATing is in place.

Hello, i have an issue where vRo can create directories in VM guests but is unable to copy file to guest. Error is below

org.apache.http.conn.ConnectTimeoutException: Connect to x.x.x.x:443 [/x.x.x.x] failed: Read timed out (Workflow:Copy file from vCO to guest / Scriptable task (item1)12)'​

vRO server is on a separate network than vCenters and ESXis, in order to connect and perform tasks against the vCenters i had to add the NATed IPs in vRO /etc/hosts file, but if i do the same for the ESXI hosts it doesn't use the NATed IPs, the Copy file to guest workflow uses the "real" IPs, so i suspect it gets the IPs from the vCenters.

Is there any workaround that can be done so that vRo knows that it needs to use the ESXi host NATed IPs ?

Has anyone attempted to use the powershell portion with Windows Server 2019? I keep running in to the error: powershell script type is not valid for OS otherGuestFamily

Sounds like the vm you are attempting to run this on does not have its os type set to windows of some sort.  You might need to adjust the workflow to recognize 2019 if its os type is not matching up.

Version history
Revision #:
1 of 1
Last update:
‎01-06-2014 01:12 PM
Updated by: