Changes between Version 19 and Version 20 of VirtualBox


Ignore:
Timestamp:
05/19/10 00:30:48 (9 years ago)
Author:
dgquintas
Comment:

updated to reflect latest changes (corresponding to the 0.5.x series)

Legend:

Unmodified
Added
Removed
Modified
  • VirtualBox

    v19 v20  
    55== "Logistic" advantages ==
    66
    7  1. One order of magnitude lighter, both its installation package (~70 MB) and
     7 1. One order of magnitude lighter, regarding both its installation package (~70 MB) and
    88 its installed size (~80 MB). Compare with the 500+ MB of VMWare Server 2.0,
    99 that increase in some 150 extra MB when installed.
     
    1717== Technical points ==
    1818
    19 The interaction with the VM is made possible even from the command line, in
     19The interaction with the VM is possible even from the command line, in
    2020particular from the single command `VBoxManage` (extensive doc available in
    2121[http://www.virtualbox.org/manual/UserManual.html the manual]). The following VBoxManager arguments are particularly interesting :
     
    5454of quirks and platform specific pitfalls (COM is used on Windows, whereas Linux and presumably MacOS X resource to XPCOM).
    5555
    56 The Python bindings sound promising. Unfortunately, they aren't distributed with most of the pre-built binaries available at the !VirtualBox webpage.
    57 
    58 We are left with the SOAP based web services. This is a sufficiently well known mechanism as to have proper support on the three supported systems. Moreover, the [http://dlc.sun.com/virtualbox/vboxsdkdownload.html VirtualBox SDK] includes a good deal of Python code tailored for interacting with it.
    59 This is the way the current implementation has gone.
    60 
     56Fortunately, with the introduction of the 3.x !VirtualBox versions, the Python bindings have been largely improved
     57and provide a unified and portable entry point to the !VirtualBox internals (its API can be downloaded from
     58[http://www.virtualbox.org/wiki/Downloads the usual place] after registering -annoying but free-).
     59This is the mechanism being used to communicate with the !VirtualBox hypervisor.
    6160
    6261== Interacting with the VM Appliance ==
     
    6665properly secured both in term of authentication and encrypted traffic (that is
    6766to say, these features are already supported by !VirtualBox).
    68  
     67
    6968== Conclusions ==
    7069
     
    106105The lightweight [http://stomp.codehaus.org/Protocol STOMP protocol] has been considered, in order
    107106to incur on a small footprint. This protocol is simple enough as to have implementations in a
    108 large number of programming languages, while still fulfilling all flexibility needs. Despite its
    109 simplicity and being relatively unheard of, ActiveMQ supports it out-of-the-box (even though
    110 it'd be advisable to use something lighter for a broker).
     107large number of programming languages, while still fulfilling all flexibility needs.
    111108
    112109Focusing on the problem at hand, we need to tackle the following problems:
     
    121118  === Network Setup ===
    122119  In the previous diagram, it was implied that both host and guests were
    123   already connected to a common broker. This is clearly not the case upon startup. Both the
     120  already connected to a common broker. This is not the case upon startup. Both the
    124121  host and the guests need to share some knowledge about the broker's location, if it's going
    125122  to be running on an independent machine. Otherwise, it can be assumed that it listens on the
     
    127124  is put in place in the host in order to route the connections to the broker.
    128125 
    129   The addition, in version 2.2, of the host-only networking feature was really convenient. From
     126  The addition, in version 2.2+, of the host-only networking feature was really convenient. From
    130127  [http://www.virtualbox.org/manual/UserManual.html#network_hostonly the relevant section] of the manual:
    131128
     
    153150
    154151  === Command Execution ===
    155   Requesting the execution of a program contained in the guest fit nicely into an async.
     152  Requesting the execution of a program contained in the guest fits nicely into an asynchronous
    156153  message passing infrastructure: a tailored message addressed to the guest we want to
    157154  run the command on is published, processed by this guest and eventually answered back
     
    159156
    160157  Given the subscription-based nature of the system, several guests can be addressed at
    161   once by a single host, triggering the execution of commands (or any other action
     158  once by a single host (multicasting), triggering the execution of commands (or any other action
    162159  covered by this mechanism) in a single go. Note that neither the hosts nor the
    163160  (arbitrary number of) guests need to know how many of the latter conform the system:
     
    183180
    184181
    185   === Open Questions ===
    186   * Where should the broker live? Conveniently on the same machine as the hypervisor or on
    187     a third host? Maybe even a centralized and widely known (ie, standard) one? This last option
    188     might face congestion problems, though.
    189   * Broker choice. Full-fledged ([http://activemq.apache.org/ ActiveMQ]) or more limited but lighter?
    190     (ie, [http://www.germane-software.com/software/Java/Gozirra/ Gozirra]). On this
    191     question, unless a centralized broker is universally used, the lighter version largely suffices.
    192     Otherwise, given the high load expected, a more careful choice should be made.
     182  === The Broker ===
     183  An embedded Python-based broker ([http://code.google.com/p/coilmq CoilMQ]) is included and started by default
     184  on and by the host. It'd still be possible to substitute it for another broker, possibly running on a different
     185  machine, but we find that the default behavior is better fitted to most scenarios.
     186  Under usual conditions, the size/frequency of the exchanged messages
     187  doesn't justify the deployment of a full-fledge broker, such as [http://activemq.apache.org/ ActiveMQ]
     188  (which, by the way, natively supports STOMP as well).
    193189
    194190
    195191== Implementation ==
    196192[http://cernvm.cern.ch/cernvm/ CernVM] has been taken as the base guest system.
    197 '''Note''': if more than one CernVM instance is to be run on the same
    198 hypervisor, the UUID of the virtual machine's harddisk image has to be
    199 changed: at least in the !VirtualBox case, no two disk images (globally) can
    200 have the same UUID. Luckily this can be quickfixed, taking into account we
    201 are looking for the following pattern:
    202 
    203 {{{
    204 dgquintas@portaca:$ grep -n -a -m 1 "uuid.image" cernvm-1.2.0-x86.vmdk
    205 20:ddb.uuid.image="ef98873f-7954-4ed8-919a-aae7fb7443a8"
    206 }}}
    207 
    208 Notice the -m 1 flag, to avoid going through the many megabytes the file is
    209 worth. In place modifications of this UUID can be trivially performed in-place
    210 by using, for instance, sed.
    211 
    212 
    213 This prototype has been implemented in Python, given its cross-platform nature and the suitability
    214 of the tools/libraries it provides.
     193
     194This project has been implemented in Python, resulting in cross-platform code able to take
     195advantage of the great wealth of available tools/libraries.
    215196
    216197  === Overview ===
     
    224205  Two channels are defined for the communication between host agent and VMs: the
    225206  connection and the command channels (this conceptual "channels" are actually
    226   a set of STOMP topics. Refer to [http://bitbucket.org/dgquintas/boincvm/src/tip/BoincVMController/stomp/protocol/destinations.py the source]
     207  a set of STOMP topics. Refer to
     208  [http://bitbucket.org/dgquintas/boincvm/src/tip/common/boincvm_common/stomp/protocol/destinations.py the source]
    227209  for their actual string definition).
    228210
     211  === Structure ===
     212  [[Image(classDiagram.png)]]
     213  In the previous class diagram special attention should be paid to the classes
     214  of the "words" package: they encompass the logic of the implemented protocol.
     215  The `Host` and `VM` classes model the host agent and the VMs, respectively.
     216  Classes with a yellow background are support the underlying STOMP
     217  architecture.
     218  `CmdExecuter` deals with the bookkeeping involved in the execution of
     219  commands. `MsgInterpreter` takes care of routing the messages received by
     220  either the host agent or the VMs to the appropriate `word`. This architecture
     221  makes it extremely easy to extend the functionalities: just add a new `word`
     222  implementing `howToSay` and `listenAndAct` methods.
     223
    229224
    230225  === Unique Identification of Guests ===
    231   The preferred way to identify guests is by their name, as assigned by the hypervisor. This presents a problem, as they VMs themselves are internally unaware of their own name. A "common ground" is needed in order to work around this problem.
    232 
    233 The MAC address of the host-only virtual network card will be the common piece of data, unique and known by both the VM and hypervisor/host system, that will enable us to establish an unequivocal mapping between the VM and "the outside world". This MAC address is of course unique in the virtual network, ensured by !VirtualBox. It's available to the OS inside the VM has access to (as part of the properties of the virtual network interface), as well as through the VirtualBox API, completing the circle.
     226  The preferred way to identify guests is by their name, as assigned by the
     227  hypervisor. This presents a problem, as they VMs themselves are internally
     228  unaware of their own name. A "common ground" is needed in order to work
     229  around this problem.
     230
     231  The MAC address of the host-only virtual network card will be the common piece
     232  of data, unique and known by both the VM and hypervisor/host system, that will
     233  enable us to establish an unequivocal mapping between the VM and "the outside
     234  world". This MAC address is of course unique in the virtual network, ensured by
     235  !VirtualBox. It's available to the OS inside the VM has access to (as part of
     236      the properties of the virtual network interface), as well as through the
     237  VirtualBox API, completing the circle.
    234238
    235239  === VM Aliveness ===
     
    359363  Versions 2.4 and 2.6 of the Python runtime have been tested.
    360364
     365  === Work in Progress ===
     366  A preliminary installer for the Windows platform automating the installation of all the dependencies
     367  has been developed and will be released shortly.
     368  In addition, a more generic (and platform agnostic) way of deploying would be to rely on native
     369  Pythonic means of installation and depency resolution: [http://packages.python.org/distribute/ the distribute project]
     370  aims at precisely that, and such a installer script is also being developed. Note that this installer isn't
     371  necessarily incompatible in the case of a Windows system: we cannot assume Python will be installed on this platform,
     372  and thus an installer that -at least- takes care of installing the appropriate Python version would be desirable. 
     373
    361374== Miscelaneous Features ==
    362   * Multiplatform: it runs wherever a python runtime is available. All
     375  * Multiplatform: it runs wherever a Python runtime is available. All
    363376  the described dependencies are likewise portable.
    364   * Fully asynchronous. Thanks to the usage of the Twisted framework, the
     377  * Fully asynchronous. Thanks to the usage of the [http://twistedmatrix.com/
     378  * Twisted framework], the
    365379  whole system developed is seamlessly multithreaded, even though no
    366380  threads are used (in the developed code at least). Instead, all the
     
    369383  [http://twistedmatrix.com/projects/core/documentation/howto/async.html here].
    370384
    371 == Prototype ==
    372 Because action speak louder than words, a prototype illustrating the previous
    373 points has been developed. Bear in mind that, while functional, this is a
    374 proof of concept and surely can be much improved.
    375 
    376 === Structure ===
    377 [[Image(classDiagram.png)]]
    378 In the previous class diagram special attention should be paid to the classes
    379 of the "words" package: they encompass the logic of the implemented protocol.
    380 The `Host` and `VM` classes model the host agent and the VMs, respectively.
    381 Classes with a yellow background are support the underlying STOMP
    382 architecture.
    383 `CmdExecuter` deals with the bookkeeping involved in the execution of
    384 commands. `MsgInterpreter` takes care of routing the messages received by
    385 either the host agent or the VMs to the appropriate `word`. This architecture
    386 makes it extremely easy to extend the functionalities: just add a new `word`
    387 implementing `howToSay` and `listenAndAct` methods.
    388 
    389 
    390 === Configuration ===
    391 Several aspects can be configured, on three fronts:
    392 
    393 * Broker:
    394   * `host`: the host where the broker's running
    395   * `port`: port the broker's listening on
    396   * `username`: broker auth.
    397   * `password`: broker auth.
    398 
    399 * Host:
    400   * `chirp_path`: absolute path (including /bin) of the chirp tools
    401   * `xmlrpc_listen_on`: on which interface to listen for XML-RPC requests.
    402   * `xmlrpc_port`: on which port to listen for XML-RPC requests.
    403   * `vm_gc_grace`: how ofter to check for VM beacons (see [#VMAliveness VM Alivenes]).
    404 
    405 * VM:
    406   * `beacon_interval`: how often to send an aliveness beacon (see [#VMAliveness VM Alivenes])
     385== Configuration ==
     386Several aspects can be configured, both on the Host and the VM side. Please
     387refer to the comments on the actual configuration files for more information:
     388
     389  * [http://bitbucket.org/dgquintas/boincvm/src/tip/host/boincvm_host/HostConfig.cfg Host side]
     390  * [http://bitbucket.org/dgquintas/boincvm/src/tip/vm/boincvm_vm/VMConfig.cfg VM side]
    407391
    408392  The configuration file follows
     
    419403
    420404{{{
    421   dgquintas@portaca:~/.../$ python HostMain.py config.cfg
    422 }}}
    423 
    424 Likewise for the VMs (in principle from inside the actual virtual machine, but not necessarily):
    425 
    426 {{{
    427   dgquintas@portaca:~/.../$ python VMMain.py config.cfg
    428 }}}
    429 
    430 Of course, a broker must be running on the host and port defined in the
    431 configuration file being used, [#Configuration as described]. During
    432 development, [http://activemq.apache.org/ ActiveMQ 5.2.0] has been used,
    433 but [http://stomp.codehaus.org/Brokers any other] should be fine as well.
     405  $ python HostMain.py config.cfg
     406}}}
     407
     408For the VMs (in principle from inside the actual virtual machine, but not necessarily), we rely on the
     409Twisted Daemon ([http://linux.die.net/man/1/twistd twistd(1)]). Information about it can be found on
     410[http://twistedmatrix.com/documents/current/core/howto/application.html its official documentation].
    434411
    435412=== Logging ===
     
    441418for the host agent and [http://bitbucket.org/dgquintas/boincvm/src/tip/VMMain.py#cl-8 here] for the VM.
    442419
     420
     421=== Known Issues ===
     422* The !VirtualBox Python API implementation under Linux requires a python environment compiled with
     423UCS4/UTF-32 support. How to check it:
     424{{{
     425  python -c 'import sys; print (sys.maxunicode > 65535 and "UCS4" or "UCS2")'
     426}}}
     427NB: this is '''not''' an issue on Mac OS X or Windows.
    443428
    444429== Conclusions ==
     
    468453
    469454
     455