02-25-2015 09:33 AM - edited 03-01-2019 06:21 AM
Hello-
I'm trying to create a custom workflow to run a bash script inside a linux host using the Execute VIX Script task and I have a few questions. I am staring with something simple, just a script to echo hostname to a file in th machines tmp directory. This is the contents of the script pane:
#!/bin/bash
hostname >> /tmp/UCSD_script_results
The script will "successfully" complete if I just type in "hostname" in the script without the redirect to the file, however when I include the redirects, it takes forever to complete and then it eventually says that it was successful, but the file with the results is never created.
First, is this the proper way to try and run a bash script on a VM through UCSD? I'm thinking about this in the traditional methods of creating a bash script as a file on a local disk and then executing it, so not sure if I am missing something here.
Second, is there a way to capture the terminal output of the script and log them to the workflow log? It would be very helpful in debugging script errors and whatnot if those results were available.
Lastly, is there any documentation regarding what characters can be entered into the script pane without needing to escape them and which need to be preceded by an escape character (which is "\" correct?)
02-25-2015 11:04 AM
+1
I am also very interested in this question. We are trying to figure out how to create some post-provisioning actions in our VMs, and executing custom script through workflow is the best way we have found, but haven't tried yet.
Kind Regards
03-02-2015 06:32 AM
Anyone? Even if someone has a sample of a working bash script injected using this method that would be extremely helpful. I've tried a bunch of variations in the script and I still get a report back saying that it was successful but nothing actually seems to run on the target VM.
03-02-2015 01:07 PM
So far, I have only found this example where shell script is used to change VM IP address, subnet and gateway.. However it is only prepared workflow with workflow task that should execute "/a.sh" script on the Linux or Windows machine. No working script was packed as part of example.
Link: VIX example
Kind Regards
03-18-2015 08:52 AM
Still trying to get this working, but just an FYI I noticed that if you put a password in for root, it will display it openly in the task logs. There are two entries, one that has a masked password and one that shows the actual password. Not sure if it's something I am doing wrong or not but something to be aware of, especially if you have this in a vDC where end users can see the logs of services requests that may contain it. Can anyone else confirm if they see the same behavior or if everything is properly masked in their logs?
03-18-2015 09:00 AM
Hi Jon,
What version of UCSD are you running so that we can look into the password in clear text issue and make sure this is fixed?
Thanks,
Mike
03-18-2015 09:11 AM
5.1.0.0 Build 51089
I know there are various ways to supply the password, i.e. workflow user inputs, admin inputs, task inputs, etc. I think I've tried all of them and experience the same behavior but can't say 100% for sure. The log below is from a workflow using the password supplied via admin task input in the workflow designer. Input type is listed as credential and password is masked in the workflow/task design input dialog box.
Mar 18, 2015 12:03:30 EDT Request submitted
Mar 18, 2015 12:03:33 EDT Executing workflow item number 1
Mar 18, 2015 12:03:33 EDT Completed workflow item number 1, with status Completed
Mar 18, 2015 12:03:39 EDT Executing workflow item number 2
Mar 18, 2015 12:03:39 EDT Trigger context executeWorkFlowStep called
Mar 18, 2015 12:03:39 EDT Executing custom action Execute VM Script (custom_Execute VIX Script - 2014-10-28)
Mar 18, 2015 12:03:39 EDT Executing custom action Execute VM Script (custom_Execute VIX Script - 2014-10-28) for VM 28 (testvm1)
Mar 18, 2015 12:03:39 EDT Executing custom script for Execute VIX Script - 2014-10-28
Mar 18, 2015 12:03:40 EDT [VIXActionHandler] - account details VMName testvm1 Host testhost1.domain.com OS Type Red Hat Enterprise Linux 6 (64-bit)
Mar 18, 2015 12:04:25 EDT Task #1 (Execute VM Script (custom_Execute VIX Script - 2014-10-28)) completed successfully in 45 seconds
Mar 18, 2015 12:04:25 EDT Input/Output values for Task #1 (Execute VM Script (custom_Execute VIX Script - 2014-10-28)):
Mar 18, 2015 12:04:25 EDT [Mapped Input: Select VM = 28]
Mar 18, 2015 12:04:25 EDT [Local Input: Credential Type = Login]
Mar 18, 2015 12:04:25 EDT [Local Input: Login = root]
Mar 18, 2015 12:04:25 EDT [Template Input:Password = UnmaskedPword ]
Mar 18, 2015 12:04:25 EDT [Resolved Template Input: Password = L]
Mar 18, 2015 12:04:25 EDT [Local Input: Password = **masked-value**]
Mar 18, 2015 12:04:25 EDT [Local Input: Script = touch /tmp/UCSD_script]
Mar 18, 2015 12:04:25 EDT [Local Input: Undo Script = ]
Mar 18, 2015 12:04:25 EDT Completed workflow item number 2, with status Completed
Mar 18, 2015 12:04:28 EDT Executing workflow item number 3
Mar 18, 2015 12:04:28 EDT Completed workflow item number 3, with status Completed
03-24-2015 08:51 AM
Thank Jon. Apologies for the delayed response back. Looks like the password issue you are seeing is fixed in UCSD 5.2, I was just able to confirm on a UCSD 5.2.0.0 system.
In regards to the VIX script issues, can you put the bash commands you want to run into a shell script (.sh) and then call the shell script from the UCSD VIX task?
In other words...
1) create shell script, "touch /myscript.sh"
2) "vi /myscript.sh"
#!/bin/bash
hostname >> /tmp/UCSD_script_results
3) Use "/myscript.sh" in the "Script" box in the VIX task in UCSD
Please give that a try if you haven't already gotten it to work...
Thanks,
Mike
03-24-2015 11:05 AM
Thanks for the suggestion, I'll upgrade to 5.2 and give that a try, although I wouldn't consider that an ideal solution. What we're trying to do is support a multi-tenant environment where each tenant VM is based off of a single template image (less templates to maintain means easier to update and less of a chance of having configuration drift) and each customization task is contained in the specific workflow. While we could consolidate everything down to a single image and then store our post customization scripts on the host itself, destroying them once the customization is complete, it would be better to have it all done/maintained in the workflow and UCSD itself. I know it is possible to inject a bash script into a VM through powershell, so the functionality is there already in VMware's API, it's just a matter of being able to call it in UCSD.
I'll send an update once I try running a local script.
03-25-2015 06:53 AM
Password issue is definitely fixed, thanks for that. Script issue still exists though, even when trying to call a local script. I created /test.sh and tried to call it from the workflow. Despite the workflow reporting that it was successful, nothing ever happens on the guest VM.
03-25-2015 07:42 AM
HI Jon,
Here is what I was able to test successfully...does this differ from what you were trying?
-Example Shell script on linux VM...
[root@mzdc02-gateway /]# cat ./mztest.sh
#!/bin/bash
hostname >> /tmp/UCSD_script_results
-Current /tmp directory on linux VM...
[root@mzdc02-gateway tmp]# pwd
/tmp
[root@mzdc02-gateway tmp]# ls
vmware-root
VIX Script Task (sorry can't include screenshot)...
Select VM: mzdc02-gateway
Credential Type: Login
Login: root
Password: *******
Script: /mztest.sh
-After executing VIX script task in UCSD...
[root@mzdc02-gateway tmp]# pwd
/tmp
[root@mzdc02-gateway tmp]# ls
UCSD_script_results vmware-root
[root@mzdc02-gateway tmp]# cat ./UCSD_script_results
mzdc02-gateway
Do you have VMware Tools installed on your VM?
Thanks,
Mike
03-25-2015 09:45 AM
I created a new task from scratch and I still get no results. VMware tools is installed and is up to date. vSphere versions is 5.5 u3, vm hardware version 10.
/test.sh (manual execution shows that script works and puts results in /tmp):
#!/bin/bash
echo "Hello" >> /tmp/ucsdtest.txt
VIX Task is identical to yours save for the script name. I get the inputs at run time from the user, although my previous attempts were defined admin inputs.
03-26-2015 02:51 PM
Michael-
What version of vSphere are you using? I found this today when trying to investigate further, not sure if it's relevant or not.
http://www.vmware.com/files/pdf/techpaper/vsphere_powercli51r1_technote.pdf
"Based on the version of your VMware virtualization software, Invoke-VMScript selects a service to run your script with.
-For vCenter Server 5.0 and later or ESX/ESXi 5.0 and later, Invoke-VMScript runs your script through the VIM service.
-For earlier vCenter Server and ESX/ESXi versions, Invoke-VMScript runs your script through the VIX component. The VIX component is included with PowerCLI."
There is a difference in behavior indicate by the task log of the guest in vSphere between running the commands through PowerCLI and UCSD.
PowerCLI:
Guest operation Create Temporary File performed.
info
3/26/2015 5:17:18 PM
Guest operation Start Program performed.
info
3/26/2015 5:17:19 PM
Guest operation List Processes performed.
info
3/26/2015 5:17:19 PM
Guest operation List Processes performed.
info
3/26/2015 5:17:24 PM
Guest operation Initiate File Transfer From Guest performed.
info
3/26/2015 5:17:25 PM
Guest operation Delete File performed.
info
3/26/2015 5:17:25 PM
UCSD:
A ticket of type guestControl has been acquired.
info
3/26/2015 5:19:51 PM
Nothing else happens after that.
So it seems as though UCSD is in fact not using the same method to inject a script into the guest as PowerCLI does. Any ideas on what I could do to create my own custom workflow/task to make direct calls to the vSphere API? Not really sure where to get started there... I also noticed that there is an Execute Command task that seems similar to the Execute VIX Script but it errors out when I try to run it and I seem to remember seeing somewhere that it doesn't work with ESXi 5 and later.
07-17-2015 01:23 PM
It finally works! I updated to 5.3 the other day so that may have had something to do with it and I have done limited testing to see what other variables may have impacted the end result, but I just made a custom workflow with the Execute VIX Script task (all variables were supplied directly in the task configuration pane, nothing was passed through from a user selection or workflow input) and the VM ran the script. The script command was a simple one-liner show below. I will be experimenting with more combinations but I did try with it using #!/bin/bash which didn't seem to work. At least I have something to work off of know to know which settings break it and which work. One more item to note was that the VM was set to Red Hat 6 x64 despie it actually being a CentOS 6 VM, which may or may not have an impact.
Script"
/bin/echo "Hello world" >> /tmp/world.txt
03-02-2015 08:51 AM
Hi,
Im also having the same with issue with VMware VIX on Linux VM's, the workflow reports success but nothing seems to run within the VM.
I have carried out the below actions to troubleshoot, I have noticed UCSD seems to check the guest OS and if it is Linux does not carry out any VIX Execute actions.
2015-03-02 11:17:34,984 [WFExec-76-1] INFO isImageWindows(VixUtils.java:151) - *****************Guest OS is: Microsoft Windows Server 2008 R2 (64-bit)
2015-03-02 11:17:34,984 [WFExec-76-1] INFO executeCustomAction(VIXActionHandler.java:132) - [VIXActionHandler] - Windows environment
2015-03-02 11:17:34,984 [WFExec-76-1] INFO executeCustomAction(VIXActionHandler.java:133) - [VIXActionHandler] - Executing guest command
2015-03-02 11:17:37,852 [Thread-16] INFO processTriggers(TriggerManager.java:92) - Checking 0 triggers
2015-03-02 11:17:38,514 [WFExec-76-1] INFO executeCustomAction(VIXActionHandler.java:136) - [VIXActionHandler] - Completed executing guest command
2015-03-02 11:31:02,338 [WFExec-77-1] INFO isImageWindows(VixUtils.java:151) - *****************Guest OS is: CentOS 4/5/6/7 (64-bit)
2015-03-02 11:31:02,399 [WFExec-77-1] INFO run(WorkFlowExecutor.java:114) - Completed workflow Step 1 of 4 for SR 77
2015-03-02 11:31:08,254 [WFExec-77-2] INFO run(WorkFlowExecutor.java:78) - Executing Step 3 of 4 for SR 77
Regards Nathan
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide