lemke's Posts

'datacenter-245' is an internal (unique) identifier.  There may be easier ways, but I'd use the Managed Object Browser to learn more. vSphere Documentation Center describes how to use it. I think you could simply use: https://<VC IP>/mob/?moid=datacenter-245 Or you can browse around. You'll be able to see the datacenter's  'name' there amongst other properties.

First, VIX for vSphere has been deprecated, so I wouldn't suggest using it. If you do, at least upgrade -- you're using an almost 4 year old build. Release Notes For getting more detailed VIX logging, you can turn up the debug level by setting the config entry vix.debugLevel = "9" in one of the config files.  The user one is probably best since you're on Windows. %AppData%\VMware\config.ini If it works right, you'll see the debug log show the new value 2015-05-27T11:01:31.771+10:00| vix| I120: Vix_InitializeGlobalState: vixLogLevel = 0 I can't recall ever seeing a error 48 from curl before.  The docs say its a bad option, which may be the result of VIX doing something stupid.  It may have been fixed in a more recent release.

Results will depend on the guest user being used, and whether or not you use interactiveSession.  interactiveSession isn't exposed by vmrun, but can be used if you use VIX directly.  Its also possible you've hit a (fixed) bug, since we had issues with Windows env variables a few years back.  We'd need some version details to know. vmtoolsd with -n vmusr means someone is logged into the console, so a second, user-mode copy of tools is running.  This copy runs as the logged-in user, and handles drag&drop and other UI related things.  The other copy of vmtoolsd is running as SYSTEM, and as such will only see things SYSTEM sees (like most env variables).  The SYSTEM copy also has no access to the desktop.

Short of porting open-vm-tools to the emulator (not a clue how hard that could be), I suspect VIX isn't going to help much.  You may be able to use some MKS based tool to do the screen capture.  Maybe some other guest agent could report its IP somehow?

VIX needs two communication channels.  One is specified by the URL, the other uses that same hostname and port 902. If only the first works, you'll get exactly what you're seeing -- any operations that don't involve a powered on or powering on VM will work, others will fail with a communication error because port 902 cannot be contacted.

Its likely that it failed to connect to the automation socket.  VIX needs to talk to port 902 on the ESX system in order to execute guest operations, and it tries to get that connection when poweringOn.  Be sure there's no firewalls in place. We also recently found a bug where there was some case-sensitivity in the URL used for the connection.  'https://<ip>/sdk' worked fine, but 'Https://<ip>/sdk' did not, because some code couldn't handle the upper case.

It may be a privilege issue.  VMOpen has to enumerate all the datacenters, which means the user passed in HostConnect needs the privileges to look at the vSphere folders. Have you tried as an admin user? You can also do some quick tests with 'vmrun list'.

I'd need to see the debug logs from vmrun to know for sure, but my initial guess is that the host running vmrun can't connect to the ESX automation socket.  Is there any firewall in place blocking port 902?

Perhaps it would be better said to be a confusing part of VIX.  Many of the variables you can modify don't actually affect the VM (eg power state), and this is one of them.  Player is also probably buggy in reporting the new value. VIX doesn't have an API for reconfiguring a powered-on VM.