cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Abhinandan Prateek <>
Subject Re: Regarding cpu and ram overcommit.
Date Thu, 21 Feb 2013 06:18:34 GMT
  We should document that it is admins responsibility to check if the
underlying Hvs have capability to support overcommit before using the
overcommit provided by CS.


On 21/02/13 11:13 AM, "Bharat Kumar" <> wrote:

>I think  the licensing and the os dependencies are subject to change in
>future and if we want to do this check for different os and hypervisors
>it will be difficult to maintain.
>On Feb 21, 2013, at 10:38 AM, Nitin Mehta <> wrote:
>> Sateesh - Please find my answers inline
>> On 20/02/13 10:28 PM, "Sateesh Chodapuneedi"
>> <> wrote:
>>>> -----Original Message-----
>>>> From: Bharat Kumar []
>>>> Sent: 20 February 2013 18:18
>>>> To:
>>>> Subject: Regarding cpu and ram overcommit.
>>>> The cpu and ram overcommit feature depends on availability hypervisor
>>>> specific
>>>> features like DMC in case of xenserver.
>>>> The availability of these features depends on the type of licenses
>>>> are being
>>>> used.  Enabling  these features requires changing the license and i
>>>> think should
>>>> be done by admin.
>>> In addition to hypervisor host license, hot add (cpu/memory) features
>>> depends on guest operating system type.
>>>> So should we check for these dependencies when using the overcommit
>>>> feature
>>>> or document all the prerequisites and leave it to the admin.
>>> There are 2 cases to consider to start with,
>>> 1) Hypervisor host does not support hot add feature
>>> If there exists a mix of licenses (license per each host) in a cluster,
>>> which is enabled with this feature,
>>> it is required to know which host supports (through its license type)
>>> feature to deploy VM on correct host.
>>> Otherwise, overcommit configuration may not be effective as expected.
>>> Of course we may assume all hosts in a cluster () are already licensed
>>> adequately and 
>>> go ahead enabling hot add while deploying VM. Need to document such
>>> as disclaimer.
>> We expect that the cluster has homogeneous hosts. If it has different
>> licenses several other features will fail. I think the license check if
>> all should happen in a different layer altogether.
>>> 2) guest OS does not support host add feature
>>> In cluster that is enabled with this feature, while deploying VM
>>> if the OS type would support
>>> this feature or not would help avoid false positive by continuing to
>>> configure hot add  for the VM.
>>> Atleast in case of VMware, configuration of VM while deploying VM would
>>> fail if guest OS type
>>> does not support this feature. Of course we can handle the exception
>>> either continue with disclaimer that
>>> hot add is not effective on this VM or fail VM deployment saying OS
>>> doesn't support this, also we can
>>> provide force=true kind of option to deploy a VM without overcommit
>>> feature in that cluster (here the cluster
>>> is already configured for this feature)
>> We should do this in allocators checking that the guest os can't reside
>> this cluster and not consider it for allocation. I think we do something
>> similar there.

View raw message