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. > >> >
