Skip navigation

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

Advertisements

2 Comments

  1. good discoveries…

    The timeout issue has been adressed by dblock in his vmware tasks library.

    • Yeah, but it’s too bad that VMware can’t bother to bake in timeout support into all its VIX APIs, by default. Dealing with timeouts should be built into the API.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: