You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Bharat Kumar <bh...@citrix.com> on 2013/02/20 13:48:02 UTC
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.
So should we check for these dependencies when using the overcommit feature or document all the prerequisites and leave it to the admin.
Re: Regarding cpu and ram overcommit.
Posted by Abhinandan Prateek <Ab...@citrix.com>.
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" <bh...@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 <Ni...@citrix.com> wrote:
>
>> Sateesh - Please find my answers inline
>>
>> On 20/02/13 10:28 PM, "Sateesh Chodapuneedi"
>> <sa...@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.
>>
>>>
>>
>
Re: Regarding cpu and ram overcommit.
Posted by Bharat Kumar <bh...@citrix.com>.
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 <Ni...@citrix.com> wrote:
> Sateesh - Please find my answers inline
>
> On 20/02/13 10:28 PM, "Sateesh Chodapuneedi"
> <sa...@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.
>
>>
>
Re: Regarding cpu and ram overcommit.
Posted by Nitin Mehta <Ni...@citrix.com>.
Sateesh - Please find my answers inline
On 20/02/13 10:28 PM, "Sateesh Chodapuneedi"
<sa...@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.
>
RE: Regarding cpu and ram overcommit.
Posted by Sateesh Chodapuneedi <sa...@citrix.com>.
> -----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.
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)