<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Cole:<div><br></div><div>That link you posted refers to our work at ISI. We're currently running LXC as the hypervisor on our SGI UV. Other than performance, one of the issues with KVM is that it currently has a hard-coded limit on how many vCPUs you can run in a single instance, so we can't run, say, a 256 vcpus instance. </div><div><br></div><div>Some of the LXC-related issues we've run into:</div><div><br></div><div>- The CPU affinity issue on LXC you mention. Running LXC with OpenStack, you don't get proper "space sharing" out of the box, each instance actually sees all of the available CPUs. It's possible to restrict this, but that functionality doesn't seem to be exposed through libvirt, so it would have to be implemented in nova.</div><div><br></div><div>- LXC doesn't currently support volume attachment through libvirt. We were able to implement a workaround by invoking "lxc-attach" inside of OpenStack instead (e.g., see <<a href="https://github.com/usc-isi/nova/blob/hpc-testing/nova/virt/libvirt/connection.py#L482">https://github.com/usc-isi/nova/blob/hpc-testing/nova/virt/libvirt/connection.py#L482</a>>. But to be able to use lxc-attach, we had to upgrade the Linux kernel in RHEL6.1 from 2.6.32 to 2.6.38. This kernel isn't supported by SGI, which means that we aren't able to load the SGI numa-related kernel modules. </div><div><br></div><div>Take care,</div><div><br></div><div>Lorin</div><div><div apple-content-edited="true"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>--</div><div>Lorin Hochstein, Computer Scientist</div><div>USC Information Sciences Institute</div><div>703.812.3710</div><div><a href="http://www.east.isi.edu/~lorin">http://www.east.isi.edu/~lorin</a></div><div><br></div></div><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">
</div>
<br><div><div>On Dec 3, 2011, at 5:08 PM, Cole wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">First and foremost: <a href="http://wiki.openstack.org/HeterogeneousSgiUltraVioletSupport">http://wiki.openstack.org/HeterogeneousSgiUltraVioletSupport</a><div><br></div><div>With Numa and lightweight container technology (LXC / OpenVZ) you can achieve very close to real hardware performance for certain HPC applications. The problem with technologies like LXC is there isn't a ton of logic to address the cpu affinity that other hypervisors offer (which generally wouldn't be ideal for HPC).</div>
<div><br></div><div>On the interconnect side. There are plenty of open-mx(<a href="http://open-mx.gforge.inria.fr/">http://open-mx.gforge.inria.fr/</a>) HPC applications running on everything from single channel 1 gig to bonded 10 gig.</div>
<div><br></div><div>This is an area I'm personally interested in and have done some testing and will be doing more. If you are going to try HPC with ethernet, Arista makes the lowest latency switches in the business.</div>
<div><br></div><div>Cole</div><div>Nebula</div><div><br><div class="gmail_quote">On Sat, Dec 3, 2011 at 11:11 AM, Tim Bell <span dir="ltr"><<a href="mailto:Tim.Bell@cern.ch">Tim.Bell@cern.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
At CERN, we are also faced with similar thoughts as we look to the cloud on how to match the VM creation performance (typically O(minutes)) with the required batch job system rates for a single program (O(sub-second)).<br>
<br>
Data locality to aim that the job runs close to the source data makes this more difficult along with fair share to align the priority of the jobs to achieve the agreed quota between competing requests for limited and shared resource. The classic IaaS model of 'have credit card, will compute' does not apply for some private cloud use cases/users.<br>
<br>
We would be interested to discuss further with other sites. There is further background from OpenStack Boston at <a href="http://vimeo.com/31678577" target="_blank">http://vimeo.com/31678577</a>.<br>
<br>
Tim<br>
<a href="mailto:tim.bell@cern.ch">tim.bell@cern.ch</a><br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</div></div></blockquote></div><br></div>
_______________________________________________<br>Mailing list: <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>Unsubscribe : <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>More help : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><br></blockquote></div><br></div></body></html>