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