lemke's Accepted Solutions

vmrun (and VIX) won't let you do what you're trying to do.  Nothing is paying attention to those variables being changed.  You'll need to use an API that reconfigures the VM's networking, which probably means writing some code using a vSphere API.

VM names are not unique, which is why this isn't supported. You can use VixHost_FindItems() and search for the undocumented VIX_PROPERTY_FOUND_ITEM_NAME property and use the associated VIX_PROPERTY_FOUND_ITEM_LOCATION to get the value to pass to VixHost_OpenVM().  You'll have to deal with any duplicate names however

Error 182 is ERROR_INVALID_ORDINAL 182 (0xB6) The operating system cannot run %1. Does vmrun work? Does your app link any of the libs VIX uses, with a different version? I've usually seen INVALID_ORDINAL when trying to use a library that's missing some symbols because its too old.

Here's the man page for the API.  The only API we provide a timeout for is WaitForToolsInGuest() https://www.vmware.com/support/developer/vix-api/vix11_reference/lang/c/functions/VixVM_RunProgramInGuest.html

Vix deosn't have any way to lock a VM.  RaedVaraible and WriteVariable (of type VIX_VM_CONFIG_RUNTIME_ONLY) might allow you to put your own hints in place (still plenty of room for races though).  Note that since those values are presisted in the .vmx file, choose your variable names closely (you don't want to affect the VM by setting something important) and error recovery may also get tricky if your app exits uncleanly and doesn't clear the flag.

It has all the symptoms of a bug in Vix that was fixed in version 1.8. When Vix tries to open a VM on a VC system with muliple datacenters, there was a race that could cause memory corruption. Upgrading should fix the problem.

Vix is using libcurl to do the actual http traffic, so be sure you don't have any of its env variables set (see the curl man page). I've found out the hard way that some distros like to set those values unexpectedly. I doubt the locale message is meaningful.

<![endif] ><! [if gte mso 9]> This can cover the un-intended install: sudo sh -c 'TERM=dumb VMWARE_EULAS_AGREED=yes sh ./VMware-VIX-........bundle --console --required' That's probably overkill, but covers the bases for an unattended install. It will not use a progress bar, but will still print progress information. If you want it truly quiet, you'll have to redirect the output yourself to /dev/null or a log file. However, if you're redistributing Vix, the VMware EULA does need to be displayed and acknowledged.

Which Vix are you using? The trace suggests its related to an ugly race dealing with snapshot updates -- doing a snapshot operation while the snapshot tree was being populated could hit freed memory. Its possible your code could be tripping over this. This is fixed in the current 1.10 beta release (http://www.vmware.com/support/developer/vix-api/) You could also do a quick test kludge with a sleep() before and after the snapshot operations.

Was the snapshot taken when the VM was on? Are you passing VIX_VMPOWEROP_LAUNCH_GUI to the Revert call? Is the UI running and has the VM open? If the UI has the VM open, it has it locked. Unless you tell Revert to use VIX_VMPOWEROP_LAUNCH_GUI, it will try to restart it in headless mode, and it will hit the lock error because the UI has the VM.

We recently found and fixed a bug here. What triggers it is doing the Connect/Disconnect very quickly, so that the Disconnect is started while we're still getting data from the server. There was some bad code dealing with throwing the late responses away. It shouldn't matter if the server is Server 2.0 or an ESX flavor. But its very dependent on timing, so its quite possible that you see it on Server 2.0 because that system is slower than your ESX boxes (esp since Server 2.0 has to share.) If your problem vanishes with a short sleep between, then its probably the same bug.

There's no function, but its a pretty simple algorithm. Get all the root snapshots (VixVM_GetNumRootSnapshots(), VixVM_GetRootSnapshot()), iterate over them with VixSnapshot_GetNumChildren() and VixSnapshot_GetChild(), recurse. Get the name using Vix_GetProperties(snapshtohandle, VIX_PROPERTY_SNAPSHOT_DISPLAYNAME...).

Ah, glad you found it -- for some reason I thought you were on Windows. Looking back, and I can't see why I thought that... One thing that does seem different here -- for your app, are you linking directly to libvix.so? The values of the handles suggest yes. Can you check ldd output and be sure the loader is picking up all the Vix libraries from what we shipped? I can't think why using a system libglib or libcurl could cause this, but I want to rule it out. I've seen library mismatches do some strange stuff, though usually it just crashes. Unfortunately, that release doesn't have as much debug noise as I'd hoped -- we've added a lot more since then. Since it sounds like the core issue is that the request is simply not being processed, I was hoping to see if it was some how not being sent, or if it was hanging on the server side. So more debug, this time on the server side. The server logs are in /var/log/vmware/hostd-?.log. The output level can be controlled by modifying its config in /etc/vmware/hostd/config.xml. The &lt;log&gt;&lt;level&gt; can be set to 'trivial' to dump the highest amount of data. Another way to check this is to dump the raw HTTP traffic, which can be done by setting the env variable "VMWARE_BASICHTTP_TRACE" to 1 for the client process. This will dump the HTTP to stdio and make curl verbose. No timestamps, but a multi-minute delay before the req is sent will hopefully be obvious.