Information Technology Reference
In-Depth Information
calculations of how memory will be assigned and used, especially if you plan on using a num-
ber of VMs with large amounts of memory and a large number of virtual CPUs. As you can see
in Table 11.1, the memory overhead in that situation could become fairly substantial.
Summarizing How Reservations, Limits, and Shares Work with
Memory
Because the specii c behavior of reservations, shares, and limits is slightly different for each resource,
here's a quick review of their behavior when they are used for controlling memory allocation:
◆
Reservations guarantee memory for a particular VM. Memory isn't allocated until
requested by the VM, but the host must have enough free memory to satisfy the entire res-
ervation before the VM can be powered on. Therefore—and this makes sense if you think
about it—you can not reserve more memory than the host physically has installed. Once
allocated to a VM, reserved memory is not swapped, nor is it reclaimed by the ESXi host. It
is locked to that VM.
Limits enforce an upper ceiling on the usage of memory. Limits are enforced using the
balloon driver (if VMware Tools is installed) and—depending on the VM's working set
size— could have a dramatic negative impact on performance. As the VM approaches the
limit (a limit of which the guest OS is not aware), the balloon driver will inl ate to keep VM
memory usage under the limit. This will cause the guest OS to swap out to disk, which will
typically degrade performance noticeably.
◆
◆
Shares apply only during periods of host RAM contention and serve to establish pri-
oritized access to host RAM. VMs are granted priority based on percentage of shares
allocated versus total shares granted. During periods when the host is not experienc-
ing memory contention, shares do not apply and will not affect memory allocation or
usage.
We'll provide a similar summary of the behavior of reservations, limits, and shares when
they are used to control CPU usage, which is the topic of the next sections.
Managing Virtual Machine CPU Utilization
When creating a new VM using the Web Client, you have two options when coni guring the
CPU. First, choose how many virtual CPUs you want in the VM and then decide how many
cores should be allocated to each socket. Your selection determines how many sockets the VM
has. These CPU settings effectively let the guest OS in the VM utilize between 1 and 64 virtual
CPUs on the host system, depending upon the guest OS and the vSphere license.
When the VMware engineers designed the virtualization platform, they started with a real
system board and modeled the VM after it—in this case it was based on the Intel 440BX chipset.
The VM could emulate the PCI bus, which could be mapped to input/output devices through a
standard interface, but how could a VM emulate a CPU? The answer was “no emulation.” Think
about a virtual system board that has a “hole” where the CPU socket goes—and the guest OS
simply looks through the hole and sees one of the cores in the host server. This allowed the
VMware engineers to avoid writing CPU emulation software that would need to change each
time the CPU vendors introduced new instruction sets. If there was an emulation layer, it would
