VMware VIX Problems

VMware VIX is one of VMware’s many virtualization APIs, which allows you to control and automate activity inside and outside of virtual machines (VMs).  Unlike VMware’s VI API (which is now called vSphere SDK for Web Services or the perl-specific wrapper, called vSphere SDK for Perl), VIX’s checkered past lies with the fact that it was originally developed for VMware Workstation  — while the VI codebase was almost exclusively developed for ESX.  Naturally, this means VI was designed with enterprise features, while VIX recently started supporting ESX with their latest version 1.6.2.  Why use VIX?  Simple.  It’s a very easy way to control programs *inside* the guest OS of the VM.  By using VIX, you can tell the VMware Tools daemon to copy a file, run a program, and even launch a browser.  It all sounds great — until you start trying to use VIX.  So far, I’ve found two major problems:

1. It’s possible that most VIX calls never return.  With the exception of waiting for VMware Tools to load properly, no other VIX API call supports any type of timeout mechanism.  As such, if you’re running your VIX code on a heavily loaded ESX server, there’s a chance each VIX call may never complete.  So far, I’ve been bit by this on the ReleaseHandle and HostDisconnect calls — specifically, there are times where literally the VIX API just gives up and dies… leaving my perl code hanging.  I’m forced to have to use an external timeout handler, but frankly, I shouldn’t have to do this.  We know the VMware folks have the ability to provide timeout support, so why didn’t they include it with all their calls?  Under the covers, when using  VI and VIX with ESX, both seem to use web services APIs to talk to ESX directly.  VI clearly exposes their web services logic (in Perl); while VIX hides this logic via C wrapper libraries.
2. Opening a browser via VIX for a VM on ESXv3.5U4 causes iexplore.exe to run with “NT AUTHORITY\SYSTEM” privileges — instead of running the application with the same permissions used when logging onto the guest OS in the first place.  Granted, the issue appears fixed in ESXv4; however, for those of us who can only run ESX on 32-bit hardware, we can’t upgrade to ESXv4 — so I’d wish they’d backport the fix to ESX3.5.  Oh, and running the latest VMware Tools for ESX v4 inside a VM that’s actually running on ESX3.5U4 doesn’t seem to help — so the problem is somehow located in the ESX3.5 codebase.

I would love for Matt LaMantia or Matt Richards from VMware to explain these oddities, as well as where they see VIX development going (since it’s been almost 6 months since their last release).  Oh, and as an icing, if they could explain how exactly VM Recording/Playback works for ESX (if at all?), I’d be thrilled.

vSphere SDK for Perl Documentation

Advertisement