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.ku...@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.me...@citrix.com> wrote: > >> Sateesh - Please find my answers inline >> >> On 20/02/13 10:28 PM, "Sateesh Chodapuneedi" >> <sateesh.chodapune...@citrix.com> wrote: >> >>>> -----Original Message----- >>>> From: Bharat Kumar [mailto:bharat.ku...@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. >> >>> >> >
