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 | | |
| 56 | Fortunately, with the introduction of the 3.x !VirtualBox versions, the Python bindings have been largely improved |
| 57 | and 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-). |
| 59 | This is the mechanism being used to communicate with the !VirtualBox hypervisor. |
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). |
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 | |
| 194 | This project has been implemented in Python, resulting in cross-platform code able to take |
| 195 | advantage of the great wealth of available tools/libraries. |
| 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 | |
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. |
| 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 | |
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 == |
| 386 | Several aspects can be configured, both on the Host and the VM side. Please |
| 387 | refer 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] |
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 | |
| 408 | For the VMs (in principle from inside the actual virtual machine, but not necessarily), we rely on the |
| 409 | Twisted 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]. |