diff --git a/docs/en-US/best-practices-for-vms.xml b/docs/en-US/best-practices-for-vms.xml index bba20c6fce3..f2656a09e5d 100644 --- a/docs/en-US/best-practices-for-vms.xml +++ b/docs/en-US/best-practices-for-vms.xml @@ -22,18 +22,46 @@ -->
- Best Practices for Virtual Machines - The &PRODUCT; administrator should monitor the total number of VM instances in each - cluster, and disable allocation to the cluster if the total is approaching the maximum that - the hypervisor can handle. Be sure to leave a safety margin to allow for the possibility of - one or more hosts failing, which would increase the VM load on the other hosts as the VMs - are automatically redeployed. Consult the documentation for your chosen hypervisor to find - the maximum permitted number of VMs per host, then use &PRODUCT; global configuration - settings to set this as the default limit. Monitor the VM activity in each cluster at all - times. Keep the total number of VMs below a safe level that allows for the occasional host - failure. For example, if there are N hosts in the cluster, and you want to allow for one - host in the cluster to be down at any given time, the total number of VM instances you can - permit in the cluster is at most (N-1) * (per-host-limit). Once a cluster reaches this - number of VMs, use the &PRODUCT; UI to disable allocation of more VMs to the - cluster. + Best Practices for Virtual Machines + For VMs to work as expected and provide excellent service, follow these guidelines. +
+ Monitor VMs for Max Capacity + The &PRODUCT; administrator should monitor the total number of VM instances in each + cluster, and disable allocation to the cluster if the total is approaching the maximum that + the hypervisor can handle. Be sure to leave a safety margin to allow for the possibility of + one or more hosts failing, which would increase the VM load on the other hosts as the VMs + are automatically redeployed. Consult the documentation for your chosen hypervisor to find + the maximum permitted number of VMs per host, then use &PRODUCT; global configuration + settings to set this as the default limit. Monitor the VM activity in each cluster at all + times. Keep the total number of VMs below a safe level that allows for the occasional host + failure. For example, if there are N hosts in the cluster, and you want to allow for one + host in the cluster to be down at any given time, the total number of VM instances you can + permit in the cluster is at most (N-1) * (per-host-limit). Once a cluster reaches this + number of VMs, use the &PRODUCT; UI to disable allocation of more VMs to the + cluster. +
+
+ Install Required Tools and Drivers + Be sure the following are installed on each VM: + + For XenServer, install PV drivers and Xen tools on each VM. + This will enable live migration and clean guest shutdown. + Xen tools are required in order for dynamic CPU and RAM scaling to work. + For vSphere, install VMware Tools on each VM. + This will enable console view to work properly. + VMware Tools are required in order for dynamic CPU and RAM scaling to work. + + To be sure that Xen tools or VMware Tools is installed, use one of the following techniques: + + Create each VM from a template that already has the tools installed; or, + When registering a new template, the administrator or user can indicate whether tools are + installed on the template. This can be done through the UI + or using the updateTemplate API; or, + If a user deploys a virtual machine with a template that does not have + Xen tools or VMware Tools, and later installs the tools on the VM, + then the user can inform &PRODUCT; using the updateVirtualMachine API. + After installing the tools and updating the virtual machine, stop + and start the VM. + +
diff --git a/docs/en-US/changing-service-offering-for-vm.xml b/docs/en-US/changing-service-offering-for-vm.xml index 22724eb9ede..fb22702de83 100644 --- a/docs/en-US/changing-service-offering-for-vm.xml +++ b/docs/en-US/changing-service-offering-for-vm.xml @@ -23,13 +23,14 @@ -->
Changing the Service Offering for a VM - To upgrade or downgrade the level of compute resources available to a virtual machine, you can change the VM's compute offering. - - Log in to the &PRODUCT; UI as a user or admin. - In the left navigation, click Instances. - Choose the VM that you want to work with. - (Skip this step if you have enabled dynamic VM scaling; see .) - Click the Stop button to stop the VM. + To upgrade or downgrade the level of compute resources available to a virtual machine, you can change the VM's compute offering. + + Log in to the &PRODUCT; UI as a user or admin. + In the left navigation, click Instances. + Choose the VM that you want to work with. + (Skip this step if you have enabled dynamic VM scaling; see .) + Click the Stop button to stop the VM. + @@ -37,48 +38,71 @@ StopButton.png: button to stop a VM - - Click the Change Service button. - - - - - ChangeServiceButton.png: button to change the service of a - VM - - - The Change service dialog box is displayed. - Select the offering you want to apply to the selected VM. - Click OK. - + + Click the Change Service button. + + + + + ChangeServiceButton.png: button to change the service of a + VM + + + The Change service dialog box is displayed. + Select the offering you want to apply to the selected VM. + Click OK. +
- + CPU and Memory Scaling for Running VMs (Supported on VMware and XenServer) It is not always possible to accurately predict the CPU and RAM requirements when you first deploy a VM. - You might need to increase or decrease these resources at any time during the life of a VM. + You might need to increase these resources at any time during the life of a VM. You can dynamically modify CPU and RAM levels to - change these resources for a running VM without incurring any downtime. + scale up these resources for a running VM without incurring any downtime. Dynamic CPU and RAM scaling can be used in the following cases: - New VMs that are created - after the installation of &PRODUCT; 4.2. - If you are upgrading from a previous version of &PRODUCT;, - your existing VMs created with previous versions - will not have the dynamic scaling capability. - User VMs on hosts running VMware and XenServer. System VMs on VMware. - VM Tools or XenServer Tools must be installed on the virtual machine. + VMware Tools or XenServer Tools must be installed on the virtual machine. The new requested CPU and RAM values must be within the constraints allowed by the hypervisor and the VM operating system. + New VMs that are created + after the installation of &PRODUCT; 4.2 + can use the dynamic scaling feature. + If you are upgrading from a previous version of &PRODUCT;, + your existing VMs created with previous versions + will not have the dynamic scaling capability + unless you update them using the following procedure. + +
+
+ Updating Existing VMs + If you are upgrading from a previous version of &PRODUCT;, + and you want your existing VMs created with previous versions + to have the dynamic scaling capability, + update the VMs using the following steps: + + Make sure the zone-level setting "dynamic scalable" is set to true. + Install Xen tools (for XenServer hosts) or VMware Tools (for VMware hosts) on each VM + if they are not already installed. + Stop the VM. + Click the isDynamic Scaling checkbox. + Restart the VM. + +
+
+ Configuring Dynamic CPU and RAM Scaling To configure this feature, use the following new global configuration variables: enable.dynamic.scale.vm: Set to True to enable the feature. By default, the feature is turned off. scale.retry: How many times to attempt the scaling operation. Default = 2. +
+
+ How to Dynamically Scale CPU and RAM To modify the CPU and/or RAM capacity of a virtual machine, you need to change the compute offering of the VM to a new compute offering that has the @@ -92,8 +116,29 @@ If there is no host in the cluster that can fulfill the requested level of CPU and RAM, the scaling operation will fail. The VM will continue to run as it was before. - &PRODUCT; will not check to be sure that the new CPU and RAM levels are compatible - with the OS running on the VM. +
+
+ Limitations + + You can not do dynamic scaling for system VMs on XenServer. + &PRODUCT; will not check to be sure that the new CPU and RAM levels are compatible + with the OS running on the VM. + When scaling memory or CPU for a Linux VM on VMware, you might + need to run scripts in addition to the other steps mentioned above. + For more information, see + Hot adding memory in Linux (1012764) + in the VMware Knowledge Base. + (VMware) If resources are not available on the current host, + scaling up will fail on VMware because of a known issue where &PRODUCT; and vCenter calculate the available capacity differently. + For more information, see + https://issues.apache.org/jira/browse/CLOUDSTACK-1809. + On VMs running Linux 64-bit and Windows 7 32-bit operating systems, + if the VM is initially assigned a RAM of less than 3 GB, + it can be dynamically scaled up to 3 GB, but not more. + This is due to a known issue with these operating systems, which will freeze + if an attempt is made to dynamically scale from less than 3 GB to more than 3 GB. + +