Context Navigation

Changes between Version 8 and Version 9 of VirtualBox

Timestamp:: May 14, 2009, 3:49:15 PM (15 years ago)
Author:: Nicolas
Comment:: Fix formatting and some typos

Legend:

: Unmodified
: Added
: Removed
: Modified

VirtualBox

-                      v8
+                      v9
 . 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
+ [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.
 . Faster and "less painful" installation process, partly due to its lighter
 …
 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.
+`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.
 …
   [[Image(STOMPArchV2.png)]]
   === Network Setup ===
   In the previous diagram, it was implied that both host and guests were
   already connected to a common broker. This is clearly not the case upon startup. Both the
   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's IP. Moreover, this can always be assumed if an appropriate port forwarding mechanism
   is put in place in the host in order to route the connections to the broker.
   The recent release of the 2.2 series of !VirtualBox is a very convenient one: the newly introduced
   host-only networking feature fits our needs like a glove. From
   [http://download.virtualbox.org/virtualbox/2.2.2/UserManual.pdf the manual] (section 6.7):
+=== Network Setup ===
+In the previous diagram, it was implied that both host and guests were
+already connected to a common broker. This is clearly not the case upon startup. Both the
+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's IP. Moreover, this can always be assumed if an appropriate port forwarding mechanism
+is put in place in the host in order to route the connections to the broker.
+The recent release of the 2.2 series of !VirtualBox is a very convenient one: the newly introduced
+host-only networking feature fits our needs like a glove. From
+[http://download.virtualbox.org/virtualbox/2.2.2/UserManual.pdf the manual] (section 6.7):
     Host-only networking is another networking mode that was added with version 2.2
 …
     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
   host while retaining a flexible pool of IPs for the VMs.
   Thanks to this feature, there is no exposure at all: not only do the used IPs belong to a private
   intranet IP range, but the interface itself is purely virtual.
   === Command Execution ===
   Requesting the execution of a program contained in the guest fit nicely into an async.
   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
   with some sort of status (maybe even periodically in order to feedback about progress).
   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
   covered by this mechanism) in a single go. Note that neither the hosts nor the
   (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
   to become part of the overall system. This contributes to the ''scalability'' of the system.
   === File Transfers ===
   This is a trickier feature: transfers must be bidirectional, yet we want to avoid any kind
   of exposure or (complex) configuration.
   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
   would act as a client that'd send or retrieve files. We spare ourselves from all the
   gory details involved in the actual management of the transferences, delegating the job
   to chirp (which deals with it brilliantly, by the way).
   The only bit missing in this argumentation is that the host needs to be aware of the guests'
   IP addresses in order to communicate with these chirp servers. This is a no-issue, as the
   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.
   === Open Questions ===
   * 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
     might face congestion problems, though.
   * Broker choice. Full-fledged ([http://activemq.apache.org/ ActiveMQ]) or more limited but lighter?
     (ie, [http://www.germane-software.com/software/Java/Gozirra/ Gozirra]). On this
     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.
+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
+host while retaining a flexible pool of IPs for the VMs.
+Thanks to this feature, there is no exposure at all: not only do the used IPs belong to a private
+intranet IP range, but the interface itself is purely virtual.
+=== Command Execution ===
+Requesting the execution of a program contained in the guest fit nicely into an async.
+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
+with some sort of status (maybe even periodically in order to feedback about progress).
+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
+covered by this mechanism) in a single go. Note that neither the hosts nor the
+(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
+to become part of the overall system. This contributes to the ''scalability'' of the system.
+=== File Transfers ===
+This is a trickier feature: transfers must be bidirectional, yet we want to avoid any kind
+of exposure or (complex) configuration.
+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
+would act as a client that'd send or retrieve files. We spare ourselves from all the
+gory details involved in the actual management of the transfers, delegating the job
+to chirp (which deals with it brilliantly, by the way).
+The only bit missing in this argumentation is that the host needs to be aware of the guests'
+IP addresses in order to communicate with these chirp servers. This is a no-issue, as the
+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.
+=== Open Questions ===
+ * 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
+   might face congestion problems, though.
+ * Broker choice. Full-fledged ([http://activemq.apache.org/ ActiveMQ]) or more limited but lighter?
+   (ie, [http://www.germane-software.com/software/Java/Gozirra/ Gozirra]). On this
+   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.
 …
 of the tools/libraries it provides.
   === Overview ===
   Upon initialization, guests connect to the broker, that's expected to listen on the
   default STOMP port 61613 at the guest's gateway IP.
   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
   further unicast communication (in principle, other guests don't need this information). The
   host acknowledges the new guest (using the STOMP-provided ack mechanisms).
   === Unique Identification of Guests ===
   The preferred way to identify guests is based simply on their IP.
   === Tailor-made STOMP Messages ===
   The whole custom made protocol syntax is encapsulated in the
   classes of the "words" package. Each of these words correspond
   to this protocol's commands, which are always encoded as
   the first single word of the exchanged STOMP messages.
   It is the !MsgInterpreter class responsability to "interpret"
   the incoming STOMP messages and hence route them towards
   the appropriate "word" in order to perform the corresponding
   action.
+=== Overview ===
+Upon initialization, guests connect to the broker, that's expected to listen on the
+default STOMP port 61613 at the guest's gateway IP.
+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
+further unicast communication (in principle, other guests don't need this information). The
+host acknowledges the new guest (using the STOMP-provided ack mechanisms).
+=== Unique Identification of Guests ===
+The preferred way to identify guests is based simply on their IP.
+=== Tailor-made STOMP Messages ===
+The whole custom made protocol syntax is encapsulated in the
+classes of the "words" package. Each of these words correspond
+to this protocol's commands, which are always encoded as
+the first single word of the exchanged STOMP messages.
+It is the !MsgInterpreter class responsibility to "interpret"
+the incoming STOMP messages and hence route them towards
+the appropriate "word" in order to perform the corresponding
+action.
   The "words" considered so far are:
 …
 == Miscelaneous Features ==
   * Multiplatform: it runs wherever a python runtime is available. All
   the described dependencies are likewise portable.
   * Fully asynchronous. Thanks to the usage of the Twisted framework, the
   whole system developed is seamlessly multithreaded, even though no
   threads are used (in the developed code at least). Instead, all the
   operations rely on the asynchronous nature of the Twisted mechanism,
   about which details are given
   [http://twistedmatrix.com/projects/core/documentation/howto/async.html here].
+ * Multiplatform: it runs wherever a python runtime is available. All
+   the described dependencies are likewise portable.
+ * Fully asynchronous. Thanks to the usage of the Twisted framework, the
+   whole system developed is seamlessly multithreaded, even though no
+   threads are used (in the developed code at least). Instead, all the
+   operations rely on the asynchronous nature of the Twisted mechanism,
+   about which details are given
+   [http://twistedmatrix.com/projects/core/documentation/howto/async.html here].
 == Prototype ==
 …
     completely operate with the wrapped VM-based computations.