Thanks. Kumar, what you commented is defiantly what I want. Well, do you have something to share how to avoid the contention for VM1 and vm2?
I propose a solution that during 9-10am stopped VM1, running vm2 During 10-11am,stopped vm2 and running vm1 Thanks Jerry Jerry -----邮件原件----- 发件人: Bharat Kumar [mailto:[email protected]] 发送时间: 2013年8月16日 星期五 12:58 收件人: <[email protected]> 抄送: Jerry Jiang 主题: Re: CPU over-commitment Hi jiri, The actual utilization can never be greater than 400% i.e. 100% per vCPu. we are overcommitting by allocating 4 vCpus to both the VMs. if both the VMs are trying to use what is allocated then there will be contention for resources. During the contention the resource allocation is done differently in different hypervisors. So in the scenario below both the apps cannot be happy if VM1 and VM2 want to use 350% and 360% at the same time. Overcommit is useful to increase the overall resource utilization. Overcommit is useful if the scenario was say VM1 uses 300% and VM2 uses 100% during 10-11 am and form 11-12am VM2 uses 300% where as VM1 uses 100%. we have overcommitted the resource by allocation more than what we have, this will keep the cpu utilization of the host near 100% most of the time and we will be able to launch more VMs as not all the VMs try to use the resource allocated to them at the same time. Regards, Bharat. On Aug 16, 2013, at 9:28 AM, Jerry Jiang <[email protected]> wrote: > HI all, > > > > I have question not figured out very well. (may not for CS, but I > noticed CS supports CPU over-commitment) > > > > Imaging the following case, > > > > A host owns 4 physical CPUs > > Because apps on VM1 consume 350% CPU during 10am-11am, so I gave VM1 4 > vCPUs to ensure performance > > Because apps on VM2 consume 360% CPU during 10am-11am, so I gave VM2 4 > vCPUs to ensure performance > > > > So I would ask if Apps are both happy with vm1 and vm2 during > 10am-11am > > > > If not, Is CPU over-commitment meaningful? How is your guys consider > the over-commitment > > > > Thanks > > Jerry > > >
