Hello
There are two issues involved here. First, sometimes it seems the VC doesn't return the host/thumbprint pair when issuing a ticket. There have been other such complaints but we were unable to reproduce it. This affects GUI client jobs, too. OTOH, when connecting to ESX directly, the ticket doesn't contain a host/thumbprint pair always (it assumes there are known to the caller because it has already connected anyway). Because of this, when the ticket contains no thumbprint, the worker attempts to connect with the thumbprint from the conection spec. Hence the workaround of targeting the ESX directly.
Now we come to the second issue. GUI client always passes a thumbprint as part of the connection spec but SDK samples don't. You can fix this in the target vm spec:
ConverterTargetVmSpecManagedVmLocation targetVMLocation = new ConverterTargetVmSpecManagedVmLocation();
targetVMLocation.vimConnect = new ConverterVimConnectionSpec();
...
targetVMLocation.vimConnect.verifyPeerSpecified = true;
targetVMLocation.vimConnect.verifyPeer = true;
targetVMLocation.vimConnect.sslThumbprint = "..."; // You VC/ESX SSL thumbprint here
This should work when targeting the ESX. I would like to know a little more about the issue with VC. Can you please give some more info:
- what are the versions of your VC and ESX
- do they use certificates issued by a trusted authority or they are local ones
- the log snippet from your previous post when targeting VC from API client contains a remoteDeviceConnect invokation with thumbprint
(... -T 97:70:f0:03:ec:ca:3e:ad:b9:cb:d9:ac:1c:70:42:54 ...) Do you have an idea where it came from? I mean - did you pass it somewhere in the job spec?
Regards,
Plamen