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