Table of Contents |
---|
...
|
Introduction
...
This document describes the Cpu/Ram overcommit feature.
...
This feature implements the ram overcommit and allows the ram and cpu overcommit ratios to be specified on a per cluster basis.
...
...
change the vm density on all the hosts in a given cluster. This can be done by specifying the cpu and ram overcommit ratios.
...
- when combined with dedicated resources, it gets better - with dedicated resources, we may have the capability to tell account A will use cluster X. If this account is paying for "gold" quality of service, perhaps, those clusters would have a ratio of 1. If they are paying for "bronze" QoS, their cluster ratio could be 2.
...
...
Admin can give the cpu and ram overcommit ratios at the time of creating a cluster or update the values after creating.
Cloudstack will deploy the vms based the overcommit ratios. If the overcommit ratio of a particular cluster is updated, only the vms deployed hereafter will be deployed based on the updated overcommit ratios, this is ensured by storing overcommit ratio with which the vm got deployed stored in user_vm_details. The overcommit ratios for cluster will be stored in the cluster details table and will be inherited from global setting at the time of creation. Also whenever we add a host we will check of the host has the capabilities to perform the cpu and ram overcommiting. These capabilities will be stored in the db.
...
...
XenServer
KVM
VMware
...
...
Capacity calculation model will be changed to align with the hypervisors calculation. When a vm is deployed with "x" overprovisioing factor we want to guarantee (service offering of vm / x ) during its lifecycle even though the over provisioning changes.
...
Same model is followed for cpu.
KVM
TBD
...
...
...
All the alerts are generated based on the global cpu/memory threshold values.
...
...
The feature is dependent on the OS type ,Hypervisor capabilities, and some scripts.
...