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