VmApps: vm_email.txt

File vm_email.txt, 29.4 KB (added by davea, 15 years ago)

email correspondence as of Mar 09

Line 
1
2THE HISTORY OF THE "BOINC_VM PROJECT" IN SELECTED EMAILS SINCE SEPTEMBER 2008 (B. Segal):
3
4
5From: David Anderson <davea@ssl.berkeley.edu>
6Date: 15 September 2008 18:26:41 GMT+02:00
7To: Ben Segal <b.segal@cern.ch>
8Cc: Bruce Allen <bruce.allen@aei.mpg.de>, Kevin Reed <knreed@us.ibm.com>, Reinhard Prix <Reinhard.Prix@aei.mpg.de>, Rom Walton <rwalton@ssl.berkeley.edu>, Daniel Lombraña González <teleyinex@gmail.com>, David Weir <david.weir03@imperial.ac.uk>, Predrag Buncic <Predrag.Buncic@cern.ch>
9Subject: Re: BOINC client strategies for virtualized jobs
10
11Ben:
12
13BOINC VM apps will be important to lots of people,
14and we definitely need to coordinate efforts.
15I suggest that we use the following Wiki page for the evolving design:
16http://boinc.berkeley.edu/trac/wiki/VmApps
17If you send me a doc in another format I can put it there.
18
19I can devote resources to working on this over the next year,
20i.e. BOINC client changes and/or the VM wrapper.
21
22-- David
23
24
25
26From: Daniel Lombraña González <teleyinex@gmail.com>
27Date: 9 January 2009 12:30:41 GMT+01:00
28To: David James Weir <david.weir03@imperial.ac.uk>
29Cc: Predrag Buncic <Predrag.Buncic@cern.ch>, Ben Segal <B.Segal@cern.ch>
30Subject: Re: [Fwd: Re: A BOINC-VM question]
31
32Hi David, Predag and Ben,
33
34Thanks for sending me your suggestions about BOINC and virtualization. Your comments are really interesting, all of them seem to point into the right direction. However I have some minor suggestions or comments. The use of VMware Server is the best solution, but volunteers could be afraid of installing that software (remember that you have to register yourself in vmware.com in order to obtain a free serial number). So I don't know if the solution of VMware Server is good enought for all. Therefore, we should bear in mind always both approaches: institutions like Cern or Universities and Volunteers.
35
36The rest of your implementation sounds really good and I would like to test it in our infrastructure, obviously if you are interested. If you have a public repository where I can check out the source code it will be interesting to start some minor tests with your code. At the same time we are going to try also the HTTP solution for getting the output files from the VM.
37
38That's all, thanks for your comments and happy new year ;)
39
40Daniel
41
42******************
43
44On Sun, Jan 4, 2009 at 3:09 PM, David James Weir <david.weir03@imperial.ac.uk> wrote:
45Hi Daniel (and Predrag),
46
47Ben suggested I forward to you these notes I made about BOINC with Virtual Machines. It incorporates his thinking with my experience trying to get the various bits to work together.
48
49I'm at the stage where I will be trying out the approach I give below in shortly (as soon as I have some spare time!). I think the major hurdles are now overcome; the big question is whether the approach I outline below will be useful to anyone!
50
51Kind regards,
52
53David Weir
54
55******************
56
57On 2 janv. 09, at 21:38, David James Weir wrote:
58I've had a couple more days to work on the BOINC-VM code; with  VMWare server 1 (as discussed earlier) I've got BOINC, VMWare and a  wrapper talking to each other, though I haven't (yet) tried running  it as a workunit because of issues with 64-bit Linux on my work  desktop.
59
60Daniel's idea is very good, and best of all doesn't assume too much  about the virtualisation method. We can probably do better with  VMWare Server, though: we can use VixVM API calls like  FileExistsInGuest() and CopyFileFromGuestToHost(), eliminating the  HTTP server altogether! Furthermore, this might be able to  eliminate the dependence on any form of network connection between  guest and host -- simplifying the configuration of VMWare Server.
61
62I think, though, that the exact way in which we do this is strongly  dependent on the "target audience" -- is it still the porting of  applications? I'm aware that what follows is essentially a rewrite  of the implementation you suggested to me a month or two back, but  as I have become familiar with the capabilities of the VIX API I've  been able to flesh out some of the details.
63
64Assumptions: no "inner BOINC client", inner application does not  link against BOINC libraries, inner application is small with very  few dependencies not included in a basic virtual machine. No  assumptions are made about whether the inner application would need  access to the network, but the wrapper XML standard could be  extended to include a field indicating whether this is necessary.
65
661. We deploy a virtual machine image over BOINC, with the VMWare  Tools installed. This need only be done once for our hypothetical  project, with different programs being sent as part of the workunit.
67
682. The VMWare-aware wrapper powers up the virtual machine, checks  for a snapshot relevant to the current workunit with  VixVM_GetNamedSnapshot() and VixVM_RevertToSnapshot() (this is our  checkpointing recovery step). If so, we skip to stage 4.
69
703. For a given workunit, the wrapper XML standard is then used to  send a package containing a non-BOINCified program and dependencies  (suppose a RPM for the CernVM). This is installed using a call to  RunProgramInGuest() by the VMWare-aware wrapper. This is then also  used to start the program running.
71
724 (main loop). The wrapper polls the process handle returned by  RunProgramInGuest() to see if the workunit has finished. It also  calls boinc_time_to_checkpoint(); then runs VixVM_CreateSnapshot()  to create a snapshot as a checkpoint, if necessary.
73
745. Upon successful completion of the inner job, we must copy out  the results, uninstall the workunit package in the VM and move the  checkpointed snapshot. The results are then sent back to the BOINC  server. We can get the CPU time easily inside the virtual machine  by calling the executable through time(1), say, but it may turn out  to be more reasonable to use the cputime estimate made by the core  client itself.
75
76Note: For issuing partial credit on long processes we could require  the inner program to update a file inside the VM (say /tmp/ creditreport) giving the number of floating point and integer  operations done so far. This could then be polled in step 4 (the  main loop), and the results returned to the core client. The same  thing would be necessary for reporting the fraction done. We could  even re-implement fraction_done() and ops_cumulative(), writing a  "fake" BOINC library to be used when compiling projects to run  inside virtual machines.
77
78******************
79
80From: Kevin Reed <knreed@us.ibm.com>
81Date: 20 January 2009 20:34:29 GMT+01:00
82To: Ben Segal <b.segal@cern.ch>
83Cc: Bruce Allen <bruce.allen@aei.mpg.de>, David Anderson <davea@ssl.berkeley.edu>, David Weir <david.weir03@imperial.ac.uk>, Derrick Kondo <derrick.kondo@inria.fr>, Francois Grey <francois.grey@cern.ch>, Predrag Buncic <Predrag.Buncic@cern.ch>, Reinhard Prix <Reinhard.Prix@aei.mpg.de>, Rom Walton <rwalton@ssl.berkeley.edu>, Daniel Lombraña González <teleyinex@gmail.com>
84Subject: Re: BOINC client strategies for virtualized jobs
85
86Ben et all,
87
88For your reference, I am attaching what I produced for my operating system course in regards to looking at virtual machines and using them with BOINC. The premise of the paper and study is a little flaky, but the work using the VIX API was decent. There are some rough thoughts about how BOINC could use this but there are a lot of issues out there.
89
90(See attached file: project_reed21.pdf)       ***** NOTE FROM BEN:  THIS IS NOW AVAILABLE ON THE BOINC WIKI ************
91
92Set up details and code:
93
94http://home.comcast.net/~kevin_reed/
95
96worth a little look. It still needs some maturity in my mind (like VMware server had processes that would stop running periodically).
97
98Kevin Reed
99. . . . . . . . . . . . . . . . . . . . . . . . .
100i b m i n t e r a c t i v e
10171 S. Wacker Dr
102Chicago, IL, 60606-4637
103
104312 529 2802 office
105knreed@us.ibm.com email
106
107unknown.gif šBen Segal ---01/20/2009 01:29:46 PM---Dear Dave (and BOINC colleagues),
108
1091__#$!@%!#__unknown.gif š
110From:
1112__#$!@%!#__unknown.gif š
112Ben Segal <b.segal@cern.ch>
1133__#$!@%!#__unknown.gif š
114To:
1154__#$!@%!#__unknown.gif š
116David Anderson <davea@ssl.berkeley.edu>
1175__#$!@%!#__unknown.gif š
118Cc:
1196__#$!@%!#__unknown.gif š
120Bruce Allen <bruce.allen@aei.mpg.de>, Kevin Reed/Chicago/IBM@IBMUS, Reinhard Prix <Reinhard.Prix@aei.mpg.de>, Rom Walton <rwalton@ssl.berkeley.edu>, Daniel Lombraña González <teleyinex@gmail.com>, David Weir <david.weir03@imperial.ac.uk>, Predrag Buncic <Predrag.Buncic@cern.ch>, Francois Grey <francois.grey@cern.ch>, Derrick Kondo <derrick.kondo@inria.fr>
1217__#$!@%!#__unknown.gif š
122Date:
1238__#$!@%!#__unknown.gif š
12401/20/2009 01:29 PM
1259__#$!@%!#__unknown.gif š
126Subject:
12710__#$!@%!#__unknown.gif š
128Re: BOINC client strategies for virtualized jobs
129
130Dear Dave (and BOINC colleagues),
131
132It's been a while (4 months) since our last exchange on this topic  
133but now I can happily report some progress. David Weir has found some  
134spare time from his PhD studies and is building a test implementation  
135of a "VM wrapper" along the lines we proposed. He has just put up  
136initial documentation on the Wiki page you created for us: http://boinc.berkeley.edu/trac/wiki/VmApps
137
138Daniel (in Spain) and we at CERN are looking forward to testing  
139David's code when it's ready.
140
141Any comments from any of you will be welcome!
142
143Best wishes to all and Happy New Year,
144
145Ben
146
147******************
148
149From: David James Weir <david.weir03@imperial.ac.uk>
150Date: 20 January 2009 20:38:10 GMT+01:00
151To: Kevin Reed <knreed@us.ibm.com>
152Cc: Ben Segal <b.segal@cern.ch>, Bruce Allen <bruce.allen@aei.mpg.de>, David Anderson <davea@ssl.berkeley.edu>, Derrick Kondo <derrick.kondo@inria.fr>, Francois Grey <francois.grey@cern.ch>, Predrag Buncic <Predrag.Buncic@cern.ch>, Reinhard Prix <Reinhard.Prix@aei.mpg.de>, Rom Walton <rwalton@ssl.berkeley.edu>, Daniel Lombraña González <teleyinex@gmail.com>
153Subject: Re: BOINC client strategies for virtualized jobs
154
155Hi Kevin,
156
157Kevin Reed wrote:
158Set up details and code:
159http://home.comcast.net/~kevin_reed/
160
161It seems to me you've already done almost exactly what I was proposing!
162
163(I've just read your followup email... we have!)
164
165David
166
167******************
168
169From: Daniel Lombraña González <teleyinex@gmail.com>
170Date: 21 January 2009 09:29:48 GMT+01:00
171To: Kevin Reed <knreed@us.ibm.com>
172Cc: Ben Segal <b.segal@cern.ch>, Bruce Allen <bruce.allen@aei.mpg.de>, David Anderson <davea@ssl.berkeley.edu>, David Weir <david.weir03@imperial.ac.uk>, Derrick Kondo <derrick.kondo@inria.fr>, Francois Grey <francois.grey@cern.ch>, Predrag Buncic <Predrag.Buncic@cern.ch>, Reinhard Prix <Reinhard.Prix@aei.mpg.de>, Rom Walton <rwalton@ssl.berkeley.edu>
173Subject: Re: BOINC client strategies for virtualized jobs
174
175Hi all,
176
177At the end we have two similar solutions, that's good :). I have been
178reading Kevin's paper. The proposal for integrating BOINC and VMware
179sounds really good.
180
181For me there is only an small issue with using VMware Server and
182volunteers. Probably, some users will not join us due to the fact that
183they have to register themselves on vmware.com in order to download
184the vmware server 2.0 (correct me if I'm wrong). Besides this, the
185VMware solution is by far, the best solution for institutions like
186universities or companies, as for them it will be very easy to deploy
187such configuration.
188
189As Ben said before, we would like to try this solution with some
190problems that we have already tested with our previous approach of
191Vmware Player and BOINC. So, as soon we have tried it we will comment
192out the results.
193
194Regards,
195
196Daniel
197
198******************
199
200From: Daniel Lombraña González <teleyinex@gmail.com>
201Date: 21 January 2009 09:34:00 GMT+01:00
202To: David James Weir <david.weir03@imperial.ac.uk>
203Cc: Ben Segal <b.segal@cern.ch>, Predrag Buncic <Predrag.Buncic@cern.ch>, Francois Grey <francois.grey@cern.ch>
204Subject: Re: BOINC client strategies for virtualized jobs
205
206Hi,
207
208We have now a new point for working on. The solution proposed by Kevin
209seems really good as it was yours. At the end, both of them are pretty
210similar, so I think that we can collaborate in order to improve  the
211code in one direction. Right now, Kevin's solution only works on
212windows machines (the most used OS), however it will be interesting to
213add support for Linux and Mac. Thus, it will be interesting to add
214this work to Kevin's code.
215
216Additionally, it will be possible to start discussing if it will be
217interesting to modify BOINC for supporting VMware, or we prefer to
218modify only the wrapper job.xml file to support VMs. I think this is a
219really good discussion, so what do you think?
220
221Regards,
222
223Daniel
224
225******************
226
227On Tue, Jan 20, 2009 at 9:30 PM, David James Weir
228<david.weir03@imperial.ac.uk> wrote:
229Hi Ben,
230
231Ben Segal wrote:
232
233What a surprise! I hope you're not too ticked off about this.
234
235Not at all bothered! He also has his own ideas about how to integrate this
236with BOINC.
237
238On the positive side it nicely confirms our approach (and shows that
239VMware Server 2 is OK to use). But it wasn't very comradely of Kevin to have
240sent no information on his work out to the list or to the Wiki. But it's a
241very nice job and also a fine discussion of many of the issues, including
242those around BOINC configuration and management.
243
244Since we've been caught on the back foot, I'm attaching what I've done so
245far to make a working VMWare wrapper, and I've put the necessary
246configuration examples below. It's more or less exactly what Kevin's done.
247The wrapper should compile with the standard wrapper makefile, adding
248-lvmware-vix if any of you are interested.
249
250There's much left to be done in my code: error checking, checkpointing,  and
251correct BOINC handling of output files -- the code itself represents an
252afternoon of thinking and an afternoon of work, more or less.
253
254Note that I reindented the code (by mistake!) so running diff against the
255original code may not give helpful output!
256
257David
258
259----
260
261(inner.sh)
262
263#!/bin/sh
264#
265cd /tmp
266cat foo.dat > bar.dat
267
268(job.xml)
269
270<job_desc>
271   <task>
272       <vm>cernvm-1.01-x86/cernvm-1.01-x86</vm>
273       <user>djw03</user>
274       <password>guestpass</password>
275       <datadir>/tmp</datadir>
276       <innerjob>inner.sh</innerjob>
277       <partial_credit>0</partial_credit>
278       <snapshots>0</snapshots>
279       <data>foo.dat</data>
280       <output>bar.dat</output>
281   </task>
282</job_desc>
283
284
285(sample run)
286
287vmwrapper: starting
288Connected to server.
289Processing task 0.
290Task 1.
291========
292
293VM file root is cernvm-1.01-x86/cernvm-1.01-x86
294Registered virtual machine with the server.
295Got handle.
296VM is now on (if it wasn't already).
297Logged in. Preparing job...
298Copying in input...
299Processing: foo.dat
300Running main program: done.
301Copying out output...
302Processing: bar.dat
303Sanitising virtual machine...
304Removing: foo.dat
305Removing executable.
306called boinc_finish
307
308
309******* NOTE FROM BS:  DAVID'S CODE IS AVAILABLE AT:  http://www.cern.ch/ben/DW_Wrapper_VM.rtf  ****************
310
311******************
312
313From: David Anderson <davea@ssl.berkeley.edu>
314Date: 2 March 2009 20:15:17 GMT+01:00
315To: Kevin Reed <knreed@us.ibm.com>
316Cc: Daniel Lombraña González <teleyinex@gmail.com>, Ben Segal <b.segal@cern.ch>, David Weir <david.weir03@imperial.ac.uk>, Derrick Kondo <derrick.kondo@inria.fr>, Reinhard Prix <Reinhard.Prix@aei.mpg.de>, Rom Walton <rwalton@ssl.berkeley.edu>
317Subject: Re: BOINC client strategies for virtualized jobs
318
319I'd like to move forward with BOINC support for VM apps.
320In particular, I'd like to add code to the client to detect the
321presence/version of VM executives and report them to the server.
322
323Was a concensus reached on which VM executive to use for BOINC VM apps?
324(i.e., one with an API for suspend/resume and for moving files in and out)
325
326Recent postings suggest that the leading candidate is VMWare Server 2,
327with the VIX API.
328This has the drawback that its installation process
329(which volunteers will have to perform) is targeted at IT professionals,
330and may intimidate average volunteers.
331
332-- David
333
334
335******************
336
337From: Ben Segal <b.segal@cern.ch>
338Date: 2 March 2009 20:37:36 GMT+01:00
339To: David Anderson <davea@ssl.berkeley.edu>
340Cc: Kevin Reed <knreed@us.ibm.com>, Daniel Lombraña González <teleyinex@gmail.com>, David Weir <david.weir03@imperial.ac.uk>, Derrick Kondo <derrick.kondo@inria.fr>, Reinhard Prix <Reinhard.Prix@aei.mpg.de>, Rom Walton <rwalton@ssl.berkeley.edu>, Predrag Buncic <Predrag.Buncic@cern.ch>
341Subject: Re: BOINC client strategies for virtualized jobs
342
343Hi David,
344
345We'd also like to move forward with this but have no programming effort at the moment.
346
347Yes, the consensus is what you say: VMware Server 2 and VIX.
348
349For your information, a copy of David Weir's Linux code, based on his "Proposal" in the BOINC Wiki, is at:
350
351http://www.cern.ch/ben/DW_Wrapper_VM.rtf
352
353This nicely complements Kevin's Windows code (developed independently!).
354
355All the best,
356
357Ben
358
359******************
360
361From: David James Weir <david.weir03@imperial.ac.uk>
362Date: 2 March 2009 21:00:54 GMT+01:00
363To: Ben Segal <b.segal@cern.ch>
364Cc: David Anderson <davea@ssl.berkeley.edu>, Kevin Reed <knreed@us.ibm.com>, Daniel Lombraña González <teleyinex@gmail.com>, Derrick Kondo <derrick.kondo@inria.fr>, Reinhard Prix <Reinhard.Prix@aei.mpg.de>, Rom Walton <rwalton@ssl.berkeley.edu>, Predrag Buncic <Predrag.Buncic@cern.ch>
365Subject: Re: BOINC client strategies for virtualized jobs
366
367Hi all,
368
369I should warn you that the above code was just a couple of afternoons of playing around, and I gave up when I realised I was reinventing someone else's wheel!
370
371If we have some forward momentum, I'm happy to lend a hand with whatever  eventually happens -- in between doing my PhD.
372
373Cheers,
374
375David
376
377******************
378
379From: Daniel Lombraña González <teleyinex@gmail.com>
380Date: 3 March 2009 08:32:33 GMT+01:00
381To: David James Weir <david.weir03@imperial.ac.uk>
382Cc: Ben Segal <b.segal@cern.ch>, David Anderson <davea@ssl.berkeley.edu>, Kevin Reed <knreed@us.ibm.com>, Derrick Kondo <derrick.kondo@inria.fr>, Reinhard Prix <Reinhard.Prix@aei.mpg.de>, Rom Walton <rwalton@ssl.berkeley.edu>, Predrag Buncic <Predrag.Buncic@cern.ch>
383Subject: Re: BOINC client strategies for virtualized jobs
384
385Hi all,
386
387Adding code to detect which virtual hypervisor is using the PC will be
388an interesting step on moving forward.
389
390The detection is the first step on integrating VMs and BOINC.
391
392As Ben has said: VMware Server is the best solution just right now,
393but as you have pointed out it will a bit difficult for average
394volunteers. The main problem, from my point of view, is that you need
395to register yourself on vmware.com, and I think that some volunteers
396will not like to register on VMware.
397
398Daniel
399
400******************
401
402From: Kevin Reed <knreed@us.ibm.com>
403Date: 3 March 2009 16:52:26 GMT+01:00
404To: Daniel Lombraña González <teleyinex@gmail.com>, Ben Segal <b.segal@cern.ch>, David Anderson <davea@ssl.berkeley.edu>, David James Weir <david.weir03@imperial.ac.uk>, Derrick Kondo <derrick.kondo@inria.fr>, Predrag Buncic <Predrag.Buncic@cern.ch>, Reinhard Prix <Reinhard.Prix@aei.mpg.de>, Rom Walton <rwalton@ssl.berkeley.edu>
405Subject: Re: BOINC client strategies for virtualized jobs
406
407David,
408
409As you look at implementing this I would like to suggest a different approach. I propose that the BOINC client views a particular host as having a set of 'Resources' and a set of 'Capabilities'. A 'Resource' are things like Ram, Processing Cores, Disk Space, GPU capabilities. Resources are fundamental to the client's task scheduling and management logic. A 'Capability' on the other hand, is something that the client has that may or may not allow it to run certain types of jobs. Examples of capabilities are the version of java it can run, the version of perl installed or a particular virtual machine being installed on the client.
410
411I think that the BOINC client should have embedded logic that allows it to detect Resources. However, it should also be designed so that each project can provide a small application that will detect the 'Capabilities' of the machine. This app would have a certain API that would report to the core client the set of capabilities that the host has and these capabilities would be reported back to the project on each scheduler request. I would expect that BOINC would provide a sample app that detects some common things and then projects can extended it as needed. For each additional capability there will likely be a 'wrapper' application developed that would support that capability. Hopefully projects would contribute their detection logic and wrapper applications back to BOINC and a very nice library could evolve over time.
412
413The reason that this is attractive is that the number of capabilities that projects may wish to use will change frequently. Adding each possibility to the core client will likely also result in a lot of bloat in the client over time as well as the client will be constantly behind in the features that projects are looking to use.
414
415So if we took this approach the changes that would be needed are:
416Modify the client to look for the test application if available from a project (needs to handle the multi-platform logic)
417If one is available, run it after it is downloaded and start reporting the capabilities (which would use the existing server logic to match applications with clients (i.e. like for GPU))
418Create a example version of this sample application that can detect VMWare Server 2.0
419Create a wrapper application that can run the VMWare Server 2.0
420
421Once this is done,if projects want to go a different route and use different capabilities, all they need to do is add the logic for items #3 and #4.
422
423For example, Carl over at Quake Catcher network would implement 3 and 4 to see if the client has the appropriate device for detection and then the wrapper to monitor it.
424
425Just my 2 cents
426
427Kevin Reed
428. . . . . . . . . . . . . . . . . . . . . . . . .
429i b m i n t e r a c t i v e
43071 S. Wacker Dr
431Chicago, IL, 60606-4637
432
433312 529 2802 office
434knreed@us.ibm.com email
435
436******************
437
438From: David Anderson <davea@ssl.berkeley.edu>
439Date: 3 March 2009 17:19:27 GMT+01:00
440To: Kevin Reed <knreed@us.ibm.com>
441Cc: Daniel Lombraña González <teleyinex@gmail.com>, Ben Segal <b.segal@cern.ch>, David James Weir <david.weir03@imperial.ac.uk>, Derrick Kondo <derrick.kondo@inria.fr>, Predrag Buncic <Predrag.Buncic@cern.ch>, Reinhard Prix <Reinhard.Prix@aei.mpg.de>, Rom Walton <rwalton@ssl.berkeley.edu>
442Subject: Re: BOINC client strategies for virtualized jobs
443
444I think this is the right approach.
445The key distinction is that a "resource" is something for which
446there can be contention,
447so that the client needs to know about it and do some kind of scheduling
448(e.g., allow only one GPU job to run at a time)
449whereas a "capability" has no contention.
450
451The changes for the "test application" approach are all server-side
452and should be fairly minor; I'll work on it.
453
454--------
455
456I'll contact VMWare and ask for their cooperation,
457e.g. to get a special version of VMWare Server 2 that is a 1-click
458install and is smaller than 560 MB.
459Of course, it would be better to use an open-source VM system;
460if anyone hears of interesting development let us know.
461
462-- David
463
464******************
465
466From: Daniel Lombraña González <teleyinex@gmail.com>
467Date: 3 March 2009 17:34:23 GMT+01:00
468To: David Anderson <davea@ssl.berkeley.edu>
469Cc: Kevin Reed <knreed@us.ibm.com>, Ben Segal <b.segal@cern.ch>, David James Weir <david.weir03@imperial.ac.uk>, Derrick Kondo <derrick.kondo@inria.fr>, Predrag Buncic <Predrag.Buncic@cern.ch>, Reinhard Prix <Reinhard.Prix@aei.mpg.de>, Rom Walton <rwalton@ssl.berkeley.edu>
470Subject: Re: BOINC client strategies for virtualized jobs
471
472I agree with David and Kevin,  detecting "capabilities" will be the
473key step for running within clients Python applications, R scripts or
474whatever is needed. An interesting feature could be to allow BOINC
475clients to auto-install needed packages in clients by accepting a
476check-box or something similar that warn users about needed 3rd party
477software.
478
479For example, imagine that a project needs Python installed on the clients:
4801.- The client detect if the Python interpreter is installed (as Kevin
481has explained)
4822.- If it is not installed, ask the user if BOINC can automatically
483install it from a software repository.
484
485The interesting approach of this behavior is that, BOINC can install
486(with the user permissions) dependencies for running experiments,
487opening BOINC to more researchers. For security reasons, it will be
488interesting to support a bunch of applications that are digitally
489signed by BOINC or something similar, to avoid security failures or
490malware.
491
492I don't know if it will be better to have a central repository or the
493BOINC server's project has to act as a software repository for their
494clients. This last solutions sounds really interesting, as researches
495can define which are the "capabilities" requirements for running their
496experiments.
497
498Daniel
499
500******************
501
502From: David Anderson <davea@ssl.berkeley.edu>
503Date: 3 March 2009 20:15:51 GMT+01:00
504To: Ben Segal <b.segal@cern.ch>
505Cc: Kevin Reed <knreed@us.ibm.com>, Daniel Lombraña González <teleyinex@gmail.com>, David Weir <david.weir03@imperial.ac.uk>, Derrick Kondo <derrick.kondo@inria.fr>, Predrag Buncic <Predrag.Buncic@cern.ch>, Reinhard Prix <Reinhard.Prix@aei.mpg.de>, Rom Walton <rwalton@ssl.berkeley.edu>
506Subject: Re: BOINC client strategies for virtualized jobs
507
508I'll add a "test application" mechanism
509to allow projects to probe host capabilities.
510Let's postpone thinking about how to automatically install capabilities;
511let's assume that the user has to do it manually,
512and we can notify them via messages in the BOINC manager
513if they need to do so.
514
515The next steps are to develop the app to probe VM presence/version,
516and to develop the wrapper (which seems to be largely done).
517However, to finish either of these we need to nail down the choice of VM system.
518VMWare Server 2 is the only one we've identified that meets our needs,
519but its installation process is too involved
520(and the 560MB download is probably too big) for volunteers.
521It's conceivable that VMWare could provide us with a
522"VMWare Lite" tailored to the needs of BOINC.
523
524I know Mendel Rosenblum, who developed VMWare but has since left the company.
525I just sent him an email asking him for contacts in VMWare,
526and asking him if he knows of viable alternatives.
527
528If anyone else knows of VMWare alternatives, please let us know.
529
530-- David
531
532******************
533
534From: Predrag Buncic <Predrag.Buncic@cern.ch>
535Date: 3 March 2009 22:31:38 GMT+01:00
536To: David Anderson <davea@ssl.berkeley.edu>
537Cc: Ben Segal <b.segal@cern.ch>, Kevin Reed <knreed@us.ibm.com>, Daniel Lombraña González <teleyinex@gmail.com>, David Weir <david.weir03@imperial.ac.uk>, Derrick Kondo <derrick.kondo@inria.fr>, Reinhard Prix <Reinhard.Prix@aei.mpg.de>, Rom Walton <rwalton@ssl.berkeley.edu>
538Subject: Re: BOINC client strategies for virtualized jobs
539
540
541Perhaps Sun's VirtualBox (http://www.virtualbox.org/) could qualify as
542an alternative to VMware - its is cross platform (Windows, Linux, MacOS,
543Solaris) and Open Source Edition would probably be good enough for what
544we want to do. It has a command line as well as Web service API. The
545download size is 30-36 MB (depending on a platform)
546<http://www.virtualbox.org/>and memory footprint is ~17 MB. As a bonus,
547it can use the same image format as VMware (without VMware tools
548installed). The drawback is that it is still a bit more complicated to
549install and configure than VMware.
550
551Regarding installation of software packages, we can handle that using
552'thin virtual machine' approach (like we do in CernVM) where all
553software is made available to VM just in time by means of a special file
554system that takes care of efficient downloading, caching and possibly
555sharing software components...
556
557Predrag
558
559******************
560
561From: Daniel Lombraña González <teleyinex@gmail.com>
562Date: 4 March 2009 10:26:40 GMT+01:00
563To: Predrag Buncic <Predrag.Buncic@cern.ch>
564Cc: David Anderson <davea@ssl.berkeley.edu>, Ben Segal <b.segal@cern.ch>, Kevin Reed <knreed@us.ibm.com>, David Weir <david.weir03@imperial.ac.uk>, Derrick Kondo <derrick.kondo@inria.fr>, Reinhard Prix <Reinhard.Prix@aei.mpg.de>, Rom Walton <rwalton@ssl.berkeley.edu>
565Subject: Re: BOINC client strategies for virtualized jobs
566
567I have been re-reading the papers that Kevin send us. The technical
568report: "Using Virtual Machines in Desktop Grid Clients for
569Application Sandboxing" from the CoreGrid team proposes to use
570Qemu+KQEMU.
571
572After re-reading it, it seems a good option to use qEmu+KQEMU. One of
573the main benefits is that run on Windows and GNU/Linux, it is small (6
574to 9 MB depending on the platform), and it seems that it is possible
575to access and control it via a socket. Additionally it is GPL, so it
576is possible to integrate the code with BOINC. It has some drawbacks
577like it is slower than VMware, and setting up an ethernet connection
578could be more difficult to the user than installing VMware Software.
579
580When I started with Qemu+KQEMU and VMware at CERN, the KQEMU
581accelerator was not GPL. Thus, we didn't use it because: 1) you have
582to install 3 packages: Qemu, KQEMU, and OpenVPN in Windows machines
583for having ethernet connection; 2) it wasn't GPL and 3) the set up of
584the ethernet connection is more complex than in VMware.
585
586I think that we can continue with VMware server, but on the other hand
587we should re-check Qemu and see if it is a good solution for the
588future.
589
590What do you think?
591
592PS: Adjoining is the technical report.
593
594Daniel
595
596******************