VirtualBox looks certainly promising.

Logistic" advantages

1) One order of magnitude lighter, both its installation package (~35 MB) and its installed size (~60 MB). Compare with the 500+ MB of VMWare Server 2.0, that increase in some 150 extra MB when installed.

2) License. Its OSE (Open Source Edition) is published under the GPL v.2, but even the non-libre version -PUEL, Personal Use and Evaluation License, ​http://www.virtualbox.org/wiki/VirtualBox_PUEL- could be used for our purposes, but that's something to be checked by someone who actually knows something about licensing, unlike myself.

3) Faster and "less painful" installation process, partly due to its lighter weight. No license number required, hence less hassle for the user.

Technical points

The interaction with the VM is made possible even from the command line, in particular from the single command !VBoxManage (extensive doc available at ​http://download.virtualbox.org/virtualbox/2.1.4/UserManual.pdf ). Of particular interest for us are the following VBoxManager's arguments:

• startvm
• controlvm pause|resume|reset|poweroff|savestate ...
• snapshot
• vmstatistics
• createvm
• registervm

All the functionalities exposed by this command are also available throughout a C++ COM/XPCOM based API, as well as Python bindings. More on this later.

Following the capabilities enumeration introduced by Kevin, VirtualBox would compare to his analysis based on VMWare Server as follows:

1) Manage the Image. Covered by the "snapshot" command

2) Boot the virtual machine. Covered by "startvm"

3) Copy files host -> guest *Not* directly supported by the VirtualBox API. We'd need to resource to external solutions such as a properly configured SSH server on the Appliance.

4) Run a program on the guest. Same as 3)

5) Pause and unpause the guest. Covered by "controlvm pause/resume"

6) Retrieve files from the guest. See 3) and 4), same situation.

7) Shutdown the guest Covered by "controlvm poweroff"

Tackling the interaction with the appliance

A straightforward solution could be the configure the appliance to have a running ssh server, setup for public-key authentication such that communication with the host system is seamless. Moreover, this approach is complementary to whatever interaction support there might already be, such as the one provided by VIX: shell access to the appliance could provide us with certain information that would be impossible or just inconvenient to get ahold otherwise. Anything having to do with the running environment (ulimits, environment variables, etc) come to mind.

Bindings

Both VMWare Server and VirtualBox make available C/C++ APIs, as well as Python, with different levels of support -in case of VMWare, it's an unsupported project-. VirtualBox's API is based on COM/XPCOM, and it's possible to implement a unified windows/linux approach based on the former technology. The actual code implementing the VBoxManage command is a very good reference ( ​http://www.virtualbox.org/browser/trunk/src/VBox/Frontends/VBoxManage ) Therefore, implementing a "hypervisor abstraction layer" is in principle feasible, with a common win/linux codebase both for VIX and VirtualBox API. I'll be providing code snippets towards this goal in the following days. Interestingly enough, a working wrapper prototype could be implemented without much effort by taking advantage of the aforementioned VBoxManage command. That of course is somewhat "hackish", but nevertheless a convenient tool to have.

Interacting with the VM Appliance

Another very nice feature of VirtualBox is the possibility to interact with the running appliance through a Remote Desktop connection, which can be properly secured both in term of authentication and encrypted traffic (that is to say, these features are already supported by VirtualBox).

Conclussions

VirtualBox provides several appealing features, as powerful as those provided by VMWare at a lower cost -both in terms of inconveniences for the user and licensing-. However, it lacks support for direct interacting with the guest appliance: there are no equivalents to VIX's CopyFileFromGuestToHost?, RunProgramInGuest?, etc. related to the seven points summarizing the requirements. This inconvenience can nevertheless be addressed as mentioned with certain additional benefits and no apparent drawbacks.

To-Do

• Compare performance
• Implement a working prototype based on the VirtualBox API
• ... such that it works with no of minimal code changes both in windows and linux
• Demostrate it with a custom appliance implementing the ssh based communication mechanism