Hi,
I just tried to use the VIX Plug-In for the first time to copy some files to a guest, but the Workflow run seems to hang at the action connectToServer. The workflows don't fail, they just keep running. I have some workflows running for almost two hours now. Unfortunately there aren't any errors in the vCO logfiles.
For testing I created a little workflow running only the connectToServer action. The connection doesn't work there neither. Has anyone experienced this before? I'm using vCO 4.2.1.
Thanks a lot.
Christophe pointed me to this thread.
The putFile() call is unique to the next version of the VCO plugin Library workflows for the GuestOpsManager as Christophe pointed out.
You can use the URL object to do an HTTP PUT, but we ended up using the HTTP REST plugin to support HTTPS connections to avoid the internal SSL certificate checks.
I posted up a simple GuestOps package - http://communities.vmware.com/docs/DOC-19918
It only supports four workflows currently (based on a need I had for a project):
Copy File To Guest - Copy local VCO system file to Guest OS
Copy Resource To Guest - Copy VCO Resource Element to Guest OS
Make Directory In Guest - Create directory in Guest OS
Run Program In Guest - Run program in Guest OS
Also, one small note. If you're doing multiple, simultaneous Copy File to Guests, set the input parameter KEEP REST HOST = TRUE in the workflow. It can create a timing condition where the REST HOST is deleted mid stream during another VM's Copy File To Guest workflow execution. I believe the last edit I made sets the default to TRUE for keeping the REST Host configuration to avoid this problem.
Hey mate,
A few things to check:
1 - You have installed the plug-in correctly, including extracting the contents of the zip and adding that extraction to the $PATH.
2 - You have run the Vix initial configuration workflow (can't remember the name OTOH).
3 - Your vcenter hosts are configured in the vcenter plugin with full hostnames (including domain suffix).
I have had issues with point 3, point 2 not so much, point 1 is a game killer but you would see things in the log if that was the case..
1. I did unzip the "VMware-vix-x64-1.10.1-266898.zip" file and and added the folder to the $PATH as described in the install guide. I didn't unzip the other ZIP-File ("VSOSDK-vix-src.zip"), but that's just the source, so I won't need that, right?
2. The workflow is called "Set VIX configuration defaults" and I did run it successfully.
3. Well, we have two vCenter Servers synchronized using VMware Heartbeat. So just one node is active at a time. I configured the alias of the cluster (including the domain suffix) in the vCenter plugin, which always points to the active node. But the underlying IP address is always the same. It switches from node to node at swichover. Do you think this might be an issue?
btw.: The workflows I started last friday kept running over the whole weekend and I can't cancel them.
You may have to restart Orchestrator in order to cancel them.
I am not sure if the problem is with the HA setup, possibly, you could try with adding just a single vcenter additionally in the vcenter plugin and see if that works..
I already tried to restart Orchestrator. The workflows just resume after startup.
The HA configuration doesn't seem to be the problem. I added the active node to the vCenter plugin, disabled the other entry and restarted vCO, but the problem persists. I even tried to set the server URL to the active node manually to make sure the right URL is being used, but it didn't work neither.
Hmmm, sounds there would be 2 things you can do.
1 - Change the restart behaviour with Orchestrator, then restart it. Then the jobs should stay stopped.
2 - Stop Orchestrator and remove the workflow runs from the database. Not particularly sure on how you would do this and I would opt for option 1 as it should be safer/easier.
Unfortunately, the VIX plugin is unsupported by VMware so a support request won't get you much help and you will be up a creek unless you are compatible with other methods (ie. vSphere 5 and Powershell windows VMs).
Great, changing the restart behaviour worked. Now at least the workflows stopped running
What do you mean by "other methods"? Is there an alternative to the VIX Plugin in vSphere 5? A method supported by VMware would be even better anyway.
You could use the vCenter APIs or if you have Powershell everywhere then you could use the Powershell plugin.
I can't be of much help here though since we are running vCenter 4.x and don't have Powershell on our 2K3 servers so I am stuck using the VIX plugin (and the non-appliance version of Orchestrator).
The VIX plug-in was a "fill the gaps" temporary solution until we get VIX functionality in the vCenter API. If you are running vCenter 5 you can leverage the guest operations API.
I did not check but there may be Guest operations pre-canned workflows in the recently posted vCO vCenter Plugin-in - 5.0.1.2.
Christophe.
I upgraded my vCenter Plug-in to 5.0.1.2 but I can't find any pre-canned workflows. I found the appropriate scripting classes, though.
Could someone give me a code example how to copy a directory to the guest using initiateFileTransferToGuest? I tried to get it working whole yesterday afternoon but I had no luck.
Try this
var host = vm.sdkConnection;
var guestOperationsManager = host.guestOperationsManager;
var guestAuth = new VcNamePasswordAuthentication();
guestAuth.username = vmUsername;
guestAuth.password = vmPassword;
var fileManager = guestOperationsManager.fileManager;
result = false;
var attr = new VcGuestFileAttributes();
var srcFile = new File(vcoPath);
var uri = fileManager.initiateFileTransferToGuest(vm , guestAuth ,guestFilePath, attr, srcFile.length, overwrite);
result = fileManager.putFile(vcoPath, uri);
And let me know if this works for you.
Christophe.
Thanks, but I doesn't work. I get the following error message:
Property named 'putFile' not found on object : VcGuestFileManager
Then I am sorry I pasted this. I thought this would be compatible with older version of the plug-in but is not. As a work around you can use the REST plug-in PUT.
Christophe.
I installed the REST Plugin, but it doesn't seem to be very easy to start a put operation. Do I really have to add the appropriate ESXi host as REST host and add a REST operation before I can put my files on the guest?
Anyway, I didn't manage to copy my files on the guest yet. But there are a few inputs im not sure what to enter. When I start the "Invoke a REST operation" workflow and choose my operation I can enter a content type and the content itself. Can I leave this fields empty and if no, what's my content type if I want to put files and what do I have to enter into the "content" field? The paths to the files I want to copy? I tried a few things, but I always get a 404 HTTP error.
I have asked a VMware colleague to post his guest operation package in the document tab. This may be in the next couple of days when he gets the time to update it.
Christophe.
Thanks to Reuben we have now a guest operations package in the document section : http://communities.vmware.com/docs/DOC-19918
Christophe.
Christophe pointed me to this thread.
The putFile() call is unique to the next version of the VCO plugin Library workflows for the GuestOpsManager as Christophe pointed out.
You can use the URL object to do an HTTP PUT, but we ended up using the HTTP REST plugin to support HTTPS connections to avoid the internal SSL certificate checks.
I posted up a simple GuestOps package - http://communities.vmware.com/docs/DOC-19918
It only supports four workflows currently (based on a need I had for a project):
Copy File To Guest - Copy local VCO system file to Guest OS
Copy Resource To Guest - Copy VCO Resource Element to Guest OS
Make Directory In Guest - Create directory in Guest OS
Run Program In Guest - Run program in Guest OS
Also, one small note. If you're doing multiple, simultaneous Copy File to Guests, set the input parameter KEEP REST HOST = TRUE in the workflow. It can create a timing condition where the REST HOST is deleted mid stream during another VM's Copy File To Guest workflow execution. I believe the last edit I made sets the default to TRUE for keeping the REST Host configuration to avoid this problem.
Thanks a lot. The workflows work great. I tested a few things and have two more questions:
1. Can I also copy a whole directory to my guests or do I have loop through my files?
2. Is it also possible to call powershell scripts using the "Run Program in Guest" workflow? I had to create a batch script which calls the PS-Scripts to run them, but a direct way would be nicer of course.
You can recursively create the directory structure if you set the "Create Parent Directories" flag in the workflow inputs.
If you want to copy a complex directory structure with multiple file contents, you'll probably want to use a compressed structure and Run Program In Guest to extract it appropriately.
You should be able to run anything you could run at cmd.exe with Run Program In Guest. You may have to use the interpreter executable and for PowerShell you will need to set the execution permissions appropriately.
For example, I use perl heavily and I won't pretend to be of much use with PowerShell. I can call perl scripts as: "perl.exe" "c:\Scripts\script.pl". In the Run Program In Guest workflow input, "perl.exe" would be the Path input, and "C:\Scripts\script.pl" would be the arguments. I usually use the full path to the interpeter exe to be safe "C:\Program Files (x86)\...".
The workflow just passes those values straight into the GuestProcessManager methods. A similar format should work for the PowerShell scripts.
Let me know if you hit any snags with the workflows. I've used them enough to feel comfortable I caught most of the bugs, but I'm sure a few snuck by. Drop a note here if you see any issues and I'll see if I can't update them quickly in response.
Thanks,
Reuben
Thanks. I think I'll zip my folder and extract it on the guest. That works great and it's easier than copying every single file. The execution of my powershell scripts works too now.
Until now, everything works fine. But I'll let you know if I find any snags.