cloudstack/docs/en-US/over-provisioning-service-offering-limits.xml

<?xml version='1.0' encoding='utf-8' ?>
<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
<!ENTITY % BOOK_ENTITIES SYSTEM "cloudstack.ent">
%BOOK_ENTITIES;
]>

<!-- Licensed to the Apache Software Foundation (ASF) under one
 or more contributor license agreements.  See the NOTICE file
 distributed with this work for additional information
 regarding copyright ownership.  The ASF licenses this file
 to you under the Apache License, Version 2.0 (the
 "License"); you may not use this file except in compliance
 with the License.  You may obtain a copy of the License at
 
   http://www.apache.org/licenses/LICENSE-2.0
 
 Unless required by applicable law or agreed to in writing,
 software distributed under the License is distributed on an
 "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 KIND, either express or implied.  See the License for the
 specific language governing permissions and limitations
 under the License.
-->

<section id="over-provisioning-service-offering-limits">
  <title>Over-Provisioning and Service Offering Limits</title>
  <para>(Supported for XenServer, KVM, and VMware)</para>
  <para>CPU and memory (RAM) over-provisioning factors can be set for each cluster to change the
    number of VMs that can run on each host in the cluster. This helps optimize the use of
    resources. By increasing the over-provisioning ratio, more resource capacity will be used. If
    the ratio is set to 1, no over-provisioning is done.</para>
  <para>The administrator can also set global default over-provisioning ratios
    in the cpu.overprovisioning.factor and mem.overprovisioning.factor global configuration variables.</para>
  <note>
    <para>In XenServer, due to a constraint of this hypervisor, you can not use an
      over-provisioning factor greater than 4.</para>
  </note>
  <para>Over-provisioning ratios are dynamically substituted in &PRODUCT;'s capacity
    calculations. For example: </para>
  <para>Capacity = 2 GB</para>
  <para>Over-provisioning factor = 2</para>
  <para>Capacity after over-provisioning = 4 GB</para>
  <para>With this configuration, suppose you deploy 3 VMs of 1 GB each:</para>
  <para>Used = 3 GB</para>
  <para>Free = 1 GB</para>
  <para>The administrator can specify a memory over-provisioning ratio, and can specify both CPU and
    memory over-provisioning ratios on a per-cluster basis.</para>
  <para>In any given cloud, the optimum number of VMs for each host is affected by such things
    as the hypervisor, storage, and hardware configuration. These may be different for each
    cluster in the same cloud. A single global over-provisioning setting could not provide the
    best utilization for all the different clusters in the cloud. It had to be set for the
    lowest common denominator. The new per-cluster setting provides a finer granularity for
    better utilization of resources, no matter where the &PRODUCT; placement algorithm decides
    to place a VM.</para>
  <para>The overprovisioning settings can be used along with dedicated resources (assigning a
    specific cluster to an account) to effectively offer different levels of service to
    different accounts. For example, an account paying for a more expensive level of service
    could be assigned to a dedicated cluster with an over-provisioning ratio of 1, and a
    lower-paying account to a cluster with a ratio of 2.</para>
  <para>When a new host is added to a cluster, &PRODUCT; will assume the host has the
    capability to perform the CPU and RAM over-provisioning which is configured for that
    cluster. It is up to the administrator to be sure the host is actually suitable for the
    level of over-provisioning which has been set.</para>
  <section id="overcommit-prerequisites">
    <title>Requirements for Over-Provisioning</title>
    <para>Several prerequisites are required in order for over-provisioning to function
      properly. The feature is dependent on the OS type, hypervisor capabilities, and certain
      scripts. It is the administrator's responsibility to ensure that these requirements are
      met.</para>
    <section id="balloon-driver">
      <title>Balloon Driver</title>
      <para>All VMs should have a balloon driver installed in them. The hypervisor
        communicates with the balloon driver to free up and make the memory available to a
        VM.</para>
      <formalpara>
        <title>XenServer</title>
        <para>The balloon driver can be found as a part of xen pv or PVHVM drivers. The xen
          pvhvm drivers are included in upstream linux kernels 2.6.36+.</para>
      </formalpara>
      <formalpara>
        <title>VMware</title>
        <para>The balloon driver can be found as a part of the VMware tools. All the VMs that
          are deployed in a over-provisioned cluster should have the VMware tools
          installed.</para>
      </formalpara>
      <formalpara>
        <title>KVM</title>
        <para>All VMs are required to support the virtio drivers. These drivers are installed
          in all Linux kernel versions 2.6.25 and greater. The administrator must set
          CONFIG_VIRTIO_BALLOON=y in the virtio configuration. </para>
      </formalpara>
    </section>
    <section id="memory-ballooning">
      <title>Hypervisor capabilities</title>
      <para>The hypervisor must be capable of using the memory ballooning.</para>
      <formalpara>
        <title>XenServer</title>
        <para>The DMC (Dynamic Memory Control) capability of the hypervisor should be enabled.
          Only XenServer Advanced and above versions have this feature.</para>
      </formalpara>
      <formalpara>
        <title>VMware, KVM</title>
        <para>Memory ballooning is supported by default.</para>
      </formalpara>
    </section>
  </section>
  <section id="create-overcommit">
    <title>Setting Over-Provisioning Ratios</title>
    <para>The root admin can set CPU and RAM over-provisioning ratios when creating a cluster.
      The ratios can also be modified later for an existing cluster. In this case, only VMs
      deployed after the change are affected by the new setting.</para>
    <orderedlist>
      <listitem>
        <para>Log in as administrator to the &PRODUCT; UI.</para>
      </listitem>
      <listitem>
        <para>In the left navigation bar, click Infrastructure.</para>
      </listitem>
      <listitem>
        <para>Under Clusters, click View All.</para>
      </listitem>
      <listitem>
        <para>Click Add Cluster.</para>
      </listitem>
      <listitem>
        <para>Fill in your desired over-provisioning multipliers in the fields CPU overcommit
          ratio and RAM overcommit ratio. The value of 1 which is intially shown in these
          fields is the default value: over-provisioning is turned off by default. </para>
        <note>
          <para>In XenServer, due to a constraint of this hypervisor, you can not use an
            over-provisioning factor greater than 4.</para>
        </note>
      </listitem>
    </orderedlist>
  </section>
  <section id="op-service-offering-limits">
    <title>Service Offering Limits and Over-Provisioning</title>
    <para>Service offerings limits (e.g. 1 GHz, 1 core) are strictly enforced for core count.  For example, a guest with a service offering of one core will have only one core available to it regardless of other activity on the Host.  </para>
    <para>Service offering limits for gigahertz are enforced only in the presence of contention for CPU resources.  For example, suppose that a guest was created with a service offering of 1 GHz on a Host that has 2 GHz cores, and that guest is the only guest running on the Host.  The guest will have the full 2 GHz available to it.  When multiple guests are attempting to use the CPU a weighting factor is used to schedule CPU resources.  The weight is based on the clock speed in the service offering.  Guests receive a CPU allocation that is proportionate to the GHz in the service offering.   For example, a guest created from a 2 GHz service offering will receive twice the CPU allocation as a guest created from a 1 GHz service offering. &PRODUCT; does not perform memory over-provisioning.</para>
  </section>
</section>