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:

Advertisement

Realistic ESX Snapshot Performance

Let’s say you want to create a lot of snapshots for a single VM inside VMware ESX. How many snapshots can you create before your ESX server’s performance goes to crap? Furthermore, is this maximum number relative, depending on how the snapshots are organized in the tree? (For example, can I have more snapshots whose of depth is 1 versus less snapshots of depth 3?)

Those were just some of the questions I’ve been dealing with, in porting the HoneyClient code to ESX.

Here’s the short answer: If your snapshots are getting stored as regular files (which is the default), then UNDER NO CIRCUMSTANCES should you exceed 32 snapshots per VM.

The longer answer: Regardless of how the snapshots are organized, VMware ESX appears to seek through ALL snapshots (in chronological order) when performing ANY snapshot-related operation (e.g., renaming a given snapshot). So, if you create 128 snapshots and just want to rename/revert/alter/delete the 3rd snapshot, then guess what? The ESX server will still iterate through all 128 snapshots before performing the requested operation.

You’d think ESX would be smart enough to perform some sort of depth-first (or even breadth-first search), but no, it doesn’t. This limitation comes from the fact that the snapshot metadata is stored as a FLAT FILE in chronological order.

Wait, it gets better. So it appears that as the number of snapshots increases linearly, the amount of time ESX needs to seek through these snapshots increases in a geometric rate (not quite exponential, but bad enough). And so, this delay becomes noticeable when the number of snapshots is greater than 32.

So, here are my questions to VMware and other ESX users:

1) I’m guessing that this 32 snapshot limit still exists, even if the disks and snapshot data were mapped to a physical iSCSI volume via RDM. Can anyone confirm?

2) VMware: Are you ever planning on improving this snapshotting implementation, for those who want more than 32 snapshots?

3) Anyone aware of similar limitations in other virualization products? (VirtualBox, Xen, etc.?)

ESXi + Laptop = Possible?

So now that VMware has released a free version of ESXi, has anyone had any luck getting it to run natively on any laptops? For example, Dell D6xx or D8xx series? And, no, I’m not talking about running ESXi inside a VM within VMware Workstation.

Update: So apparently ESXi can’t seem to detect IDE-based laptop harddrives, but it can boot directly off USB.  Here’s the link which explains how to boot ESXi off USB.