Changes between Initial Version and Version 1 of VirtualBox


Ignore:
Timestamp:
Apr 3, 2009, 11:41:51 AM (15 years ago)
Author:
davea
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • VirtualBox

    v1 v1  
     1!VirtualBox looks certainly promising.
     2
     3= Logistic" advantages =
     4
     51) One order of magnitude lighter, both its installation package (~35 MB) and
     6its installed size (~60 MB). Compare with the 500+ MB of VMWare Server 2.0,
     7that increase in some 150 extra MB when installed. 
     8
     92) License. Its OSE (Open
     10Source Edition) is published under the GPL v.2, but even the non-libre version
     11-PUEL, Personal Use and Evaluation License,
     12http://www.virtualbox.org/wiki/VirtualBox_PUEL- could be used for our purposes,
     13but that's something to be checked by someone who actually knows something
     14about licensing, unlike myself.
     15
     163) Faster and "less painful" installation
     17process, partly due to its lighter weight. No license number required, hence
     18less hassle for the user.
     19
     20= Technical points =
     21
     22
     23The interaction with the VM is made possible even from the command line, in
     24particular from the single command !VBoxManage (extensive doc available at
     25http://download.virtualbox.org/virtualbox/2.1.4/UserManual.pdf ).  Of
     26particular interest for us are the following VBoxManager's arguments:
     27    - startvm
     28    - controlvm  pause|resume|reset|poweroff|savestate ...
     29    - snapshot
     30    - vmstatistics
     31    - createvm
     32    - registervm
     33
     34All the functionalities exposed by this command are also available throughout
     35a C++ COM/XPCOM based API, as well as Python bindings.  More on this later.
     36
     37
     38Following the capabilities enumeration introduced by Kevin, !VirtualBox would
     39compare to his analysis based on VMWare Server as follows:
     40
     411) Manage the Image.  Covered by the "snapshot" command
     42
     432) Boot the virtual machine. Covered by "startvm"
     44
     453) Copy files host -> guest *Not* directly supported by the !VirtualBox API.
     46
     47We'd need to resource to external solutions
     48
     49such as a properly configured SSH server on the Appliance. 
     50
     514) Run a program on the guest. Same as 3)
     52
     535) Pause and unpause the guest. Covered by "controlvm pause/resume"
     54
     556) Retrieve files from the guest.  See 3) and 4), same situation.
     56
     577) Shutdown the guest Covered by "controlvm poweroff"
     58
     59
     60= Tackling the interaction with the appliance =
     61
     62
     63A straightforward solution could be the configure the appliance to have a
     64running ssh server, setup for public-key authentication such that communication
     65with the host system is seamless. Moreover, this approach is complementary to
     66whatever interaction support there might already be, such as the one provided
     67by VIX: shell access to the appliance could provide us with certain information
     68that would be impossible or just inconvenient to get ahold otherwise. Anything
     69having to do with the running environment (ulimits, environment variables, etc)
     70come to mind.
     71
     72= Bindings  =
     73
     74
     75Both VMWare Server and !VirtualBox make available C/C++ APIs, as well as Python,
     76with different levels of support -in case of VMWare, it's an unsupported
     77project-.  !VirtualBox's API is based on COM/XPCOM, and it's possible to
     78implement a unified windows/linux approach based on the former technology. The
     79actual code implementing the VBoxManage command is a very good reference (
     80http://www.virtualbox.org/browser/trunk/src/VBox/Frontends/VBoxManage )
     81Therefore, implementing a "hypervisor abstraction layer" is in principle
     82feasible, with a common win/linux codebase both for VIX and !VirtualBox API.
     83I'll be providing code snippets towards this goal in the following days.
     84Interestingly enough, a working wrapper prototype could be implemented without
     85much effort by taking advantage of the aforementioned VBoxManage command. That
     86of course is somewhat "hackish", but nevertheless a convenient tool to have.
     87
     88= Interacting with the VM Appliance =
     89
     90Another very nice feature of !VirtualBox is the possibility to interact with the
     91running appliance through a Remote Desktop connection, which can be properly
     92secured both in term of authentication and encrypted traffic (that is to say,
     93these features are already supported by !VirtualBox).
     94 
     95
     96= Conclussions  =
     97
     98VirtualBox provides several appealing features, as powerful as those provided
     99by VMWare at a lower cost -both in terms of inconveniences for the user and
     100licensing-. However, it lacks support for direct interacting with the guest
     101appliance: there are no equivalents to VIX's CopyFileFromGuestToHost,
     102RunProgramInGuest, etc. related to the seven points summarizing the
     103requirements. This inconvenience can nevertheless be addressed as mentioned
     104with certain additional benefits and no apparent drawbacks.
     105
     106= To-Do  =
     107
     108 - Compare performance
     109 - Implement a working prototype based on the VirtualBox API
     110 - ... such that it works with no of minimal code changes both in windows and linux
     111 - Demostrate it with a custom appliance implementing the ssh based  communication mechanism
     112