incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Abhinandan Prateek <Abhinandan.Prat...@citrix.com>
Subject Re: Regarding cpu and ram overcommit.
Date Thu, 21 Feb 2013 06:18:34 GMT
Bharat,
  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.

-abhi


On 21/02/13 11:13 AM, "Bharat Kumar" <bharat.kumar@citrix.com> 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 <Nitin.Mehta@citrix.com> wrote:
>
>> Sateesh - Please find my answers inline
>> 
>> On 20/02/13 10:28 PM, "Sateesh Chodapuneedi"
>> <sateesh.chodapuneedi@citrix.com> wrote:
>> 
>>>> -----Original Message-----
>>>> From: Bharat Kumar [mailto:bharat.kumar@citrix.com]
>>>> Sent: 20 February 2013 18:18
>>>> To: cloudstack-dev@incubator.apache.org
>>>> 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
>>>>that
>>>> 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)
>>>the
>>> 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
>>>case
>>> 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
>>it
>> 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
>>>knowing
>>> 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
>>>and
>>> 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
>>in
>> this cluster and not consider it for allocation. I think we do something
>> similar there.
>> 
>>> 
>> 
>


Mime
View raw message