Thank you very much Gyula.<br>I am very interested in learning your solutions. So please post it.<br><br>Curious to know, what cgroups subsystems are you using. I am only considering cpu. Are you using anything else, like cpuset or memory?<br>
<br>A note on the CPU overcommiting: do you see a problem in overcommitting single CPU VMs, i.e, multiple small size VMs (vCPU=1) sharing a physical core? Your note seems to suggest the problem is only with SMP guests.<br>
I think this is a very important feature. And without running multiple VMs on a single core, I feel there is not much need for cgroups really. The current ONE seems good enough if we always set CPU=VCPU in the ONE template. What I wanted to have is CPU=1 while vCPU=0.5 or even 0.25.<br>
<br>Thanks.<br>Shi<br><br><div class="gmail_quote">2010/7/13 Csom Gyula <span dir="ltr"><<a href="mailto:csom@interface.hu">csom@interface.hu</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
regarding ONE plans I have no clue:) Otherwise in our system (currently under development)<br>
we are using cgroups also (especially we are using it in order to guarantee CPU performance<br>
which is required for vms like web application servers or kinda). We are using cgroups in the<br>
following way:<br>
<br>
1. The vm cpu number is technically bound to VCPU (both at OpenNebula and libvirt).<br>
2. We are using cpu shares in order to give the proper share.<br>
3. We are using the ONE hook system [1] in order to trigger the cgroups script.<br>
<br>
We are using the following convenctions:<br>
4. System share: 90% goes to vms and 10% goes to the system itself.<br>
5. We are not overcommiting cpu resources since KVM has problems with such environments<br>
[2]:<br>
* physical cpu number must be equal to the vcpu number<br>
* the total number of vcpus on a given host cannot exceed the numbers of physical cpus<br>
<br>
BTW: Our solution will reach the alpha state this month, if interested I might post it here.<br>
<br>
Cheers,<br>
Gyula<br>
<br>
---<br>
<br>
[1] <a href="http://www.opennebula.org/documentation:rel1.4:oned_conf#hook_system" target="_blank">http://www.opennebula.org/documentation:rel1.4:oned_conf#hook_system</a><br>
[2] SMP overcommiting problem: <a href="http://www.mail-archive.com/kvm@vger.kernel.org/msg32079.html" target="_blank">http://www.mail-archive.com/kvm@vger.kernel.org/msg32079.html</a><br>
<a href="http://www.mail-archive.com/kvm@vger.kernel.org/msg33739.html" target="_blank">http://www.mail-archive.com/kvm@vger.kernel.org/msg33739.html</a>. The route cause seems to be<br>
spin locks: they might cause dead locks in SMP systems when overcommitting host resources.<br>
The problem is also named "lock holder preemption", you might find related articles on the web,<br>
for instance: <a href="http://www.amd64.org/fileadmin/user_upload/pub/2008-Friebel-LHP-GI_OS.pdf" target="_blank">http://www.amd64.org/fileadmin/user_upload/pub/2008-Friebel-LHP-GI_OS.pdf</a>.<br>
<<a href="http://www.reservoir-fp7.eu/index.php?mact=News,cntnt01,detail,0&cntnt01articleid=66&cntnt01returnid=108" target="_blank">http://www.reservoir-fp7.eu/index.php?mact=News,cntnt01,detail,0&cntnt01articleid=66&cntnt01returnid=108</a>><br>
________________________________<br>
Feladó: <a href="mailto:users-bounces@lists.opennebula.org">users-bounces@lists.opennebula.org</a> [<a href="mailto:users-bounces@lists.opennebula.org">users-bounces@lists.opennebula.org</a>] ; meghatalmazó: Shi Jin [<a href="mailto:jinzishuai@gmail.com">jinzishuai@gmail.com</a>]<br>
Küldve: 2010. július 13. 1:28<br>
Címzett: opennebula user list<br>
Tárgy: [one-users] integrating cgroup into OpenNebula-KVM?<br>
<div><div></div><div class="h5"><br>
Hi there,<br>
<br>
Redhat is going to include cgroups in the new RHEL-6, which is a great way to do quality of service (QoS) control on the resources, such as VM CPU, memory, network etc.<br>
Especially on CPU power, I remember the OpenNebula template has a variable CPU but it is not really used under KVM but rather a scheduling criteria.<br>
With cgroups, the CPU can have a meaning used to give each VM their proper share of the system computing power.<br>
I wonder if there is any plans to integrate this into OpenNebula.<br>
<br>
Thank you very much.<br>
<br>
--<br>
Shi Jin, Ph.D.<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Shi Jin, Ph.D.<br><br>