On VMs in 1 of 3 vCenters I get the following certificate error during execution:
The vCenter where the WF does not work, appears normally under the vCenter Plugin and even other Guest Operations like "List path in guest" are working. I've imported also the root, intermediate and the vCenter certificate through vco-configurator and restarted afterwards vco-server. The vCenter which doesnt let me copy files to its VM guests is an OVH vCenter. I dont really get why I receive the certificate issue. Shouldnt vRO send the command directly to vCenter which then somehow gets it to the VMware tools (HGFS) on the specific VM?
Copying the file require a bit of collaboration between the vCenter server, the VM/host, and the plug-in. In the first step, we call a vCenter API to initiate the file transfer to guest. As a result, vCenter returns a URL, and then it is a responsibility of the client (in this case, the vCenter plug-in) to make a HTTP PUT request to this URL with the file content to copy in the request body.
This HTTP request must be secured with a X509 certificate for the host. The plug-in has code to do so, but maybe there is some issue with special deployments like your OVH vCenter.(I assume your other vCenters where this work are not OVH, is that correct?).
Thanks explaining the process in detail. One of the other vCenter is a "classic" on prem and the other one is an VMC (AWS) one. So yes it could be that something there on OVH is special.
It seems like vRO doesnt really care about the hosts cert, as the ones on the VMC hosts are self signed, so their not trusted by vRO and neither have a trusted root/intermediate on vRO.
Is the url that vCenter returns pointing to the appropriate host of the VM? So your guess would be that at this point something is different on OVH?
Here is what the vCenter documentation says about this URL:
A URL to which the user has to send a PUT request. The host part of the URL is returned as '*' if the hostname to be used is the name of the server to which the call was made. For example, if the call is made to esx-svr-1.domain1.com, and the file can be uploaded to http://esx-svr-1.domain1.com/guestFile?id=1&token=1234, the URL returned may be http://*/guestFile?id=1&token=1234. The client replaces the asterisk with the server name on which it invoked the call.
The URL is valid only for 10 minutes from the time it is generated. Also, the URL becomes invalid whenever the virtual machine is powered off, suspended or unregistered.
BTW, you can modify the workflow to dump the actual returned URL in your environment (you may need to duplicate the workflow in order to be able to make changes). Just add the following call as the second to last line in the scriptable task, that is, between the calls to initiateFileTransferToGuest() and putFile():
System.log("URL: " + uri);