<br><br>
<div class="gmail_quote">2009/6/16 Ashley Pittman <span dir="ltr"><<a href="mailto:ashley@pittman.co.uk">ashley@pittman.co.uk</a>></span><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="im">><br>> elements (or slots) allocated for the job on the node - if the VM is<br>> able to adapt itself to such a situation, f.e. by starting several MPI<br>> ranks and using shared memory for MPI communication. Further, to<br>
> cleanly stop the job, the queueing system will have to stop the VMs,<br>> sending first a "shutdown" and then a "destroy" command, similar to<br>> sending SIGTERM and SIGKILL today.<br></div>
</blockquote>
<div> </div>
<div>I will provide a counter-example here - I think that a lot of people have thought about re-booting nodes every time they finish a job. There are codes out there which leave processes running, or leave shared memory segments, if the code is not properly terminated. I think everyone has had to run clean-ipcs at some time!</div>

<div>Yes, you're right, the codes should be written properly and should not do this.</div>
<div>However it is very tempting to put a reboot in as a step following every job, which means you get a machine in a known state for the next job. Running virtual machines will make that easy (depends how long they take to boot up)</div>

<div> </div>
<div>I agree with you about the 5% figure - the point I was making is that there will come a point where the advantages of running a virtual machine will outweigh a few percent of performance loss. Who knows where that point will be!</div>

<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div> </div></div>