Planning Virtual Machine vCPUs
Allocate virtual CPUs (vCPUs) to assign computing resources to a virtual machine (VM) on the everRun system.
When allocating vCPUs to a VM, consider the following information and restrictions:
- Each vCPU represents a virtual unit of processing power. The total number of vCPUs available on a system is equal to the minimum of the number of hardware threads presented by either physical machine (PM) in the system. For example, in a system where one PM that has 4 cores and 2 threads per core (8 vCPUs) and a second PM (in that system) that has 8 cores and 2 threads per core (16 vCPUs), the total number of vCPUs available is 8 vCPUs (fewest threads of either PM).
-
The number of vCPUs available for all VMs is equal to the total number of vCPUs available on the everRun system minus the number of vCPUs allocated to the everRun system software. (You set system vCPUs to 2 or 4, as described in Configuring System Resources.)
-
The maximum number of vCPUs you can allocate to any one VM is the total number of vCPUs available to all VMs minus the number of vCPUs allocated to currently running VMs (as described above), within the limits listed in Virtual Machine Recommendations and Limits.
- Windows-based VMs: If you change the number of assigned vCPUs from 1 to n or n to 1, after restarting the VM at the end of the reprovisioning process (see Reprovisioning Virtual Machine Resources), you must shut down and restart the VM a second time. This allows the VM to correctly reconfigure itself for Symmetric Multiprocessing (SMP). The VM displays odd behavior and is not usable until it is restarted.
-
The System page of the everRun Availability Console (see The System Page) indicates the total number of vCPUs, the number of vCPUs allocated to the everRun system software, the number of vCPUs consumed by running VMs, and the number of free vCPUs.
- By design, a VM displays its vCPU as an Intel Xeon Sandy Bridge E312xx with the base CPU speed of the host CPU, regardless of the system's actual CPU and actual CPU speed. For example, in a VM that is running a Windows operating system, the system properties utility displays the CPU as Sandy Bridge and the CPU speed as the base CPU speed even when the system's CPU is not Sandy Bridge and you have used a tool to increase or boost the CPU speed. For additional information, access the Knowledge Base to search for the article VM's vCPU reports as a Sandy Bridge with the base CPU clock speed (KB-9913). See Accessing Knowledge Base Articles.
- The everRun software allows the over-provisioning of vCPUs. If the number of free vCPUs on the System page is less than zero, you have over-provisioned the vCPUs; the console indicates this and displays an estimate of the degree to which vCPUs have been over-provisioned.
- The over-provisioning of vCPUs does not prevent you from creating or starting VMs; however, it is best to avoid running the system in an over-provisioned state.
Considerations When Over-Provisioning Virtual CPUs
Note: In general, avoid over-provisioning VM resources. It is best to isolate each VM's resources to protect the VM against other VMs that might experience resource leaks or unexpected performance peaks. When you create and configure VMs, assign dedicated resources that cannot be used by other VMs.
You should over-provision physical CPUs only under the following conditions:
- The peak vCPU resources consumed by the combined VMs does not exceed the physical resources of the everRun system.
- One or more VMs are used at different times (such as off-peak backups).
- One or more of the VMs will be stopped while the other is running, for example, during VM upgrades or VM point-in-time backup or recovery.
- Peak total CPU use by VMs will not affect service level agreements or required response times.
- Each VM’s CPU use is well understood, and its application(s) are not prone to resource leaks. When CPUs are over-provisioned, a leak in one VM can affect the performance of other VMs.