Changes between Version 17 and Version 18 of VirtualBox

Author:

dgquintas (IP: 137.138.182.211)

Timestamp:

10/20/09 04:55:25 (1 month ago)

Comment:

Updated to latest version

VirtualBox

@@ -5 +5 @@
-== "Logistic" advantages ==
-
-35
-6
+70
+8
- that increase in some 150 extra MB when installed.
- 1. License. Its OSE (Open Source Edition) is published under the GPL v.2, but
- even the non-libre version -PUEL,
-
-
-
+
+
- 1. Faster and "less painful" installation process, partly due to its lighter
- weight. No license number required, hence less hassle for the user.
-The interaction with the VM is made possible even from the command line, in
-particular from the single command `VBoxManage` (extensive doc available in
-
-
+
-    - startvm
-    - controlvm  pause|resume|reset|poweroff|savestate ...
-    - registervm
-
-
-
-
-
+
+
-
-Following the capabilities enumeration introduced by Kevin, !VirtualBox would
-compare to his analysis based on VMWare Server as follows:
-
- 
- 
+
+
- 1. Copy files host -> guest: '''Not''' directly supported by the !VirtualBox API.
- We'd need to resource to external solutions
- such as the one detailed below based on [http://www.cs.wisc.edu/condor/chirp/ Chirp].
- 1. Run a program on the guest. Same as 3.
- 
+
- 1. Retrieve files from the guest.  See 3 and 4, same situation.
- 1. Shutdown the guest Covered by "`controlvm poweroff`"
-
-== Bindings ==
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-== Interacting with the VM Appliance ==
-== Introduction ==
-In previous sections, two limitations of the API offered by !VirtualBox
- 
- 
+
+
-While relatively straightforward solutions exist, notably the usage of SSH,
-they raise issues of their own: the guest needs to (properly) configure this
-Thus, the requirements for a satisfactory solution would include:
-
- 
- 
+
+
-    guests should be isolated from "the outside world" as much as possible.
-
-
-  * Scalability. The solution should account for the execution of an arbitrary
- 
+
-  * Technology agnostic: dependencies on any platform/programming
-    language/hypervisor should be kept to a minimum or avoided altogether.
-
-== Proposed Solution ==
-
-
-
-
-
+
+
+
+
-simplicity and being relatively unheard of, ActiveMQ supports it out-of-the-box (even though
-it'd be advisable to use something lighter for a broker).
-Focusing on the problem at hand, we need to tackle the following problems:
-
-
+ (+ resource usage accounting for proper crediting).
-  * File transfer from the host to the guest
-  * File transfer from the guest to the host
-  host and the guests need to share some knowledge about the broker's location, if it's going
-  to be running on an independent machine. Otherwise, it can be assumed that it listens on the
- 
- 
+
+
- 
-
-
-
+
+
-
-    Host-only networking is another networking mode that was added with version 2.2
-    virtual machines cannot be seen, the traffic on the “loopback” interface on the host
-    can be intercepted.
- 
+
-  That is to say, we have our own virtual "ethernet network". On top of that, !VirtualBox
-  provides an easily configurable DHCP server that makes it possible to set a fixed IP for the
-  message passing infrastructure: a tailored message addressed to the guest we want to
-  run the command on is published, processed by this guest and eventually answered back
- 
+
-
-  Given the subscription-based nature of the system, several guests can be addressed at
-  once by a single host, triggering the execution of commands (or any other action
- 
+
-  (arbitrary number of) guests need to know how many of the latter conform the system:
-  new guest instances need only subscribe to these "broadcasted" messages on their own
-  === File Transfers ===
-  This is a trickier feature: transfers must be bidirectional, yet we want to avoid any kind
- 
+
-
-  The proposed solution takes advantage of the [http://www.cse.nd.edu/~ccl/software/chirp/ Chirp protocol and set of tools].
-  This way, we don't even require privileges to launch the server instances. Because
-  the file sharing must remain private, the chirp server is run on the guests. The host agent
- 
+
-  gory details involved in the actual management of the transferences, delegating the job
-  to chirp (which deals with it brilliantly, by the way).
-
- 
- 
+
+
-  custom STOMP-based protocol implemented makes it possible for the guests to "shout out" their
-  details so that the host can keep track of every single one of them.
-  * Where should the broker live? Conveniently on the same machine as the hypervisor or on
-    a third host? Maybe even a centralized and widely known (ie, standard) one? This last option
- 
- 
- 
+
+
+
-    question, unless a centralized broker is universally used, the lighter version largely suffices.
-    Otherwise, given the high load expected, a more careful choice should be made.
-changed: at least in the !VirtualBox case, no two disk images (globally) can
-have the same UUID. Luckily this can be quickfixed, taking into account we
- 
-
-
- 
+
+
+
+
-20:ddb.uuid.image="ef98873f-7954-4ed8-919a-aae7fb7443a8"
-}}}
-Notice the -m 1 flag, to avoid going through the many megabytes the file is
-worth. In place modifications of this UUID can be trivially performed in-place
- 
+
-
-
-
-  === Overview ===
- 
- 
+
+
-  Once connected, it "shouts out" he's joined the party, providing a its unique id (see
-  following section for details). Upon reception, the BOINC host notes down this unique id for
- 
+
-  host acknowledges the new guest (using the STOMP-provided ack mechanisms).
-
-  Two channels are defined for the communication between host agent and VMs: the
-  connection and the command channels (this conceptual "channels" are actually
- 
+
-  for their actual string definition).
-
-
-  === Unique Identification of Guests ===
-
+
+
+
-
-  === VM Aliveness ===
-  The whole custom made protocol syntax is encapsulated in the
-  classes of the "words" package. Each of these words correspond
- 
+
-  the first single word of the exchanged STOMP messages.
-
-
-{{{
- 
+
-  CMD_RUN
-}}}
-
-{{{
- 
+
-  CMD_RESULTS <json-ed dict. of results>
-}}}
-
- 
+
-      Its body encodes the command execution results as
- 
-
-
- 
- 
+
+
+
+
+
-    'cmd-id': same as in the word headers
-    'out': stdout of the command
-== API Accesibility ==
-The host agent functionalities are made accesible through a XML-RPC
- 
+
-standard and multiplatform mechanism of communication between this
- 
+
-
-
-== Dependencies ==
-This section enumerates the external packages (ie, not included in the
- 
+
-is given in parenthesis.
-
- 
+
-  * [http://code.google.com/p/stomper/ Stomper] (0.2.2)
- 
+
-     [http://www.zope.org/Products/ZopeInterface Zope Interfaces] (3.5.1)
-  * [http://code.google.com/p/simplejson/ simplejson] (2.0.9). Note that this
-== Miscelaneous Features ==
-  * Multiplatform: it runs wherever a python runtime is available. All
- 
+
-  * Fully asynchronous. Thanks to the usage of the Twisted framework, the
- 
+
-  threads are used (in the developed code at least). Instead, all the
- 
- 
+
+
-  [http://twistedmatrix.com/projects/core/documentation/howto/async.html here].
-
-Because action speak louder than words, a prototype illustrating the previous
-points has been developed. Bear in mind that, while functional, this is a
- 
+
-
-=== Structure ===
-[[Image(classDiagram.png)]]
-In the previous class diagram special attention should be paid to the classes
- 
- 
+
+
-Classes with a yellow background are support the underlying STOMP
- 
+
-`CmdExecuter` deals with the bookkeeping involved in the execution of
-commands. `MsgInterpreter` takes care of routing the messages received by
-Several aspects can be configured, on three fronts:
-
- 
+
-  * `host`: the host where the broker's running
-  * `port`: port the broker's listening on
-  * `password`: broker auth.
-
- 
+
-  * `chirp_path`: absolute path (including /bin) of the chirp tools
-  * `xmlrpc_listen_on`: on which interface to listen for XML-RPC requests.
-
-  The configuration file follows
-!
- 
+
+
-  [http://bitbucket.org/dgquintas/boincvm/src/tip/config.cfg here].
-
-=== Download and Usage ===
- 
+
-[http://bitbucket.org/dgquintas/boincvm/ mercurial repository], or downloaded from that same webpage.
-
-
+
-
-Starting up the host agent amounts to:
-
-{{{
- 
+
-}}}
-
-Of course, a broker must be running on the host and port defined in the
-configuration file being used, [#Configuration as described]. During
- 
+
-but [http://stomp.codehaus.org/Brokers any other] should be fine as well.
-
-solution to interact with a set of independent and loosely coupled machines
-from a single entry point (the host agent). In our case, this translates to
- 
+
-a more traditional distributed computing setup, such as a cluster of machines
-that could take advantage of the "chatroom" nature of the implemented
- 
+
-While some of the features this infrastructure offers could be regarded as
-already covered by the hypervisor API (as in the !VmWare's VIX API for command
-execution), the flexibility and granularity we attain is far greater: by means
-of the "words" of the implemented STOMP based protocol, we have ultimate
- 
+
-
-
-    completely operate with the wrapped VM-based computations.
-  * Possibly implement more specialized operations, such as resource usage
-
-
-
-
+
+
+
+
+