VMware ESXi and vSphere Cluster Management
VMware ESXi Resource Sharing Explained
Learn how VMware ESXi shares CPU, memory, networking, and storage among virtual machines, including default shares, contention, reservations, and limits.
VMware ESXi allows multiple virtual machines (VMs) to run on one physical server. Instead of giving every operating system its own dedicated server, ESXi presents each VM with virtual hardware while coordinating access to a shared pool of physical CPU, memory, networking, and storage resources.
This resource sharing is a core benefit of server virtualization. It improves hardware utilization and makes it possible to consolidate different workloads, such as Windows and Linux servers, onto the same physical host. It also introduces a responsibility: administrators must size VMs appropriately and monitor the host so that workloads do not compete excessively for limited capacity.
What Resource Sharing Means in Virtualization
A host is the physical server running ESXi. A virtual machine is an isolated, software-defined computer running its own guest operating system and applications. The host supplies the physical resources, while each VM receives a configured set of virtual resources.
For example, a VM can be configured with four virtual CPUs, 8 GB of memory, a virtual disk, and a virtual network adapter. These components look like computer hardware to the guest operating system, but they usually do not represent four permanently dedicated physical CPU cores, a dedicated section of RAM, or a separate physical network adapter. ESXi maps and schedules the virtual resources onto the host's hardware.
Sharing does not mean that all VMs directly access one another. Each VM has its own virtual hardware view and protected execution environment. ESXi controls the path between that virtual hardware and the physical server.
The Role of the ESXi Hypervisor
VMware ESXi is a bare-metal hypervisor. A hypervisor is software that creates and runs virtual machines while managing their use of physical hardware. ESXi runs directly on the server rather than as an application inside another operating system.
The hypervisor performs several important tasks:
- It presents virtual CPUs, memory, disks, and network adapters to VMs.
- It schedules virtual workloads onto physical processors.
- It allocates and protects host memory for each VM.
- It connects virtual network adapters to virtual switches and physical network adapters.
- It routes storage requests from virtual disks through datastores, adapters, controllers, and storage paths.
- It isolates guest operating systems so that one VM cannot normally read or overwrite another VM's memory.
This design enables several independent guest operating systems to operate concurrently on one physical server. vSphere is VMware's broader virtualization platform and management ecosystem, including ESXi hosts and related management components.
Which Physical Resources Are Shared?
VMs can share nearly every major resource supplied by an ESXi host. The virtual hardware assigned to a VM is an access model, not necessarily a dedicated physical device.
| Physical host resource | VM representation or access method | How it is shared | Potential contention symptom |
|---|---|---|---|
| CPU | vCPUs | ESXi schedules vCPUs on the host's physical CPUs. | High CPU ready or co-stop indicators, slow applications, and delayed processing. |
| RAM | VM memory allocation | ESXi assigns host memory to a VM and protects its address space from other VMs. | Memory pressure, swapping or reclamation activity, and degraded VM performance. |
| Physical NICs | Virtual NICs | Several virtual NICs use virtual networking and ultimately share one or more physical adapters. | Reduced throughput, packet drops, or increased network latency. |
| Storage adapters and controllers | Virtual disks and datastores | VM storage requests use common host adapters, controllers, paths, and storage systems. | High storage latency, slow disk operations, and application timeouts. |
How Virtual Machine Resources Are Allocated
When creating or editing a VM, an administrator normally configures its virtual CPU count, memory size, virtual disks, and virtual network adapters. These settings should reflect the workload's actual requirements rather than simply copying the capacity of a physical server.
A small infrastructure service may need one or two vCPUs and a modest amount of memory. A database server may need more memory, more processing capacity, and faster storage access. Giving every VM unnecessarily large allocations can make capacity planning harder and may increase contention on a busy host.
Multiple VMs divide the available capacity of one ESXi host. Unused capacity can be available to other VMs, while busy workloads receive CPU time, memory, network bandwidth, and storage I/O according to current demand and configured resource controls.
Memory Allocation and Isolation
Memory allocation is the host memory made available to a VM for its guest operating system and applications. Each VM receives its own assigned memory space. ESXi maintains isolation between those memory spaces, so a guest operating system and its applications cannot normally inspect or modify another VM's memory.
This isolation is different from unrestricted sharing of one VM's memory with another. The host may use virtualization techniques to manage memory efficiently, but each VM still has a protected memory view. If the host cannot satisfy memory demand, ESXi must manage the pressure through its memory-management mechanisms, and performance can suffer.
CPU Sharing and Scheduling
A vCPU is a virtual processor assigned to a VM. It is not automatically a permanently reserved physical core. CPU scheduling is the process ESXi uses to assign physical CPU time to vCPUs.
When a VM is ready to run, ESXi schedules its vCPU on an available physical processor. When several VMs need processing at the same time, ESXi distributes CPU time according to demand, availability, and resource controls. Resource contention occurs when multiple VMs request more CPU capacity than the host can provide at that moment.
Network and Storage Sharing
Virtual and Physical Networking
Each VM can have one or more virtual NICs. A virtual NIC is a network adapter presented to the guest operating system and connected through the ESXi virtual networking layer. Multiple VMs can therefore communicate through virtual switches while ultimately using the host's physical NICs and external network connections.
For example, several VMs may send traffic through the same physical adapter. If their combined traffic approaches the adapter's capacity, or if another network component is constrained, throughput and latency can be affected. Virtual networking provides logical separation and flexible connectivity, but it does not create unlimited physical bandwidth.
Shared Storage and Storage I/O
VMs store their virtual disks on storage locations such as datastores. Their read and write requests travel through shared host storage adapters, controllers, paths, and underlying storage systems.
Storage I/O means read and write activity between VMs and their underlying storage. Several VMs can use the same datastore and storage path. If many workloads perform intensive operations simultaneously, the path or storage system may become constrained even though every VM sees its own virtual disk.
| Physical host resource | Virtual machine representation or access method | How it is shared | Potential contention symptom |
|---|---|---|---|
| CPU and vCPU | A configured number of vCPUs | vCPUs compete for scheduled time on physical CPU resources. | Applications take longer to respond during simultaneous demand. |
| RAM and VM memory | Configured memory size | Host memory is assigned and isolated for each VM, subject to host capacity and controls. | Memory pressure or increased guest and host activity related to memory reclamation. |
| Physical NICs and virtual NICs | Virtual NIC connected to virtual networking | Many virtual NICs can use the same physical NIC or uplink. | Network latency, reduced throughput, or packet loss. |
| Storage adapters/controllers and virtual disks/datastores | Virtual disks stored on datastores | VMs share host paths and the performance of the underlying storage. | High latency or slow application reads and writes. |
Default Equal-Share Behavior
Under default settings, VMs on the same ESXi host are generally treated with equal resource-sharing priority at the relevant level. This means that similarly configured VMs do not automatically receive a higher priority simply because one hosts a more important application.
Resource shares are relative priority values. They influence how available resources are distributed when contention exists. Equal shares do not mean that every VM receives an identical permanent portion of CPU, memory, network capacity, or storage capacity. An idle VM does not need to consume its supposed portion, and a VM's configured memory size or vCPU count can differ from another VM's.
Administrators can use resource controls when workloads have different business priorities:
| Control | Purpose | Behavior during contention | Typical use case |
|---|---|---|---|
| Shares | Sets relative priority compared with other VMs or groups. | A VM with more shares receives a larger relative portion of a contested resource. | Give an important workload greater priority without permanently reserving all capacity. |
| Reservation | Guarantees a minimum quantity of a resource for a VM or resource pool. | The reserved amount is protected subject to the applicable host and cluster capacity. | Support a workload that requires a known minimum resource level. |
| Limit | Sets a maximum amount a VM or resource pool may consume. | Consumption is capped even if unused host capacity is available. | Restrict a deliberately bounded workload; use carefully. |
| Default allocation behavior | Uses standard settings and generally equal relative priority. | Resources are distributed according to demand and default controls during contention. | Normal workloads where no special priority or guarantee is required. |
A resource pool is a logical grouping used to manage and prioritize resources for a group of VMs. It can help organize workloads and apply shares, reservations, or limits at a group level.
Example: Windows and Linux on One Host
Consider one physical ESXi server hosting a Windows Server VM for a business application and several Linux VMs for web, database, and utility services. The VMs can run different guest operating systems at the same time because ESXi presents each one with compatible virtual hardware and keeps their execution environments isolated.
All of these VMs may use the same host CPU capacity, memory capacity, physical network adapters, storage controllers, and datastore. The Windows VM does not need a separate physical server merely because the Linux VMs are present. This consolidation can reduce hardware requirements and improve utilization, provided that the host has enough capacity for the combined workloads.
Practical Allocation Examples
- Size for demand: Give a light infrastructure VM fewer vCPUs and less memory than a busy database VM when monitoring and testing show that the smaller allocation is sufficient.
- Default priority: Two similarly configured VMs with default settings generally have the same relative share priority. If both require more CPU than is available, neither is automatically favored.
- Shared network hardware: Multiple virtual NICs can use one physical NIC. Heavy traffic from one VM can reduce available throughput for other VMs if the uplink is insufficient.
- Shared storage path: Several VMs can place virtual disks on one datastore. Concurrent high-I/O operations can increase latency for all of them.
Benefits and Limitations
| Area | Benefit | Risk if poorly planned | Administrative consideration |
|---|---|---|---|
| CPU | Idle processing capacity can be used by active VMs. | Simultaneous demand can cause CPU contention. | Monitor demand and avoid assigning unnecessary vCPUs. |
| Memory | Host RAM can support multiple appropriately sized workloads. | Overcommitment or pressure can degrade VM performance. | Size memory from workload requirements and monitor host pressure. |
| Network | Many virtual networks and VMs can use a small set of physical adapters. | Shared uplinks can become bandwidth or latency bottlenecks. | Review traffic patterns and physical adapter capacity. |
| Storage | Many virtual disks can use shared datastores and storage paths. | Concurrent I/O can increase storage latency. | Evaluate throughput, latency, paths, and workload patterns. |
| Guest operating system consolidation | Windows and Linux workloads can run on one host, reducing the need for one physical server per operating system. | A host failure or capacity shortage can affect many workloads at once. | Use capacity planning and appropriate availability and distribution designs. |
Resource sharing improves utilization and lets administrators match VM capacity to actual workload needs. Its limitation is that the physical host remains finite. Adding VMs does not add CPU cores, RAM, network bandwidth, or storage performance automatically. Capacity planning is therefore essential to avoid overcommitment and contention.
Conceptual Configuration Guidance
- Configure the VM's vCPU count according to measured or expected processing demand.
- Configure memory based on the guest operating system and application's working set.
- Review CPU and memory shares when one workload must have greater relative priority during contention.
- Use reservations only when a workload requires a guaranteed minimum resource level and the host has sufficient capacity.
- Avoid unnecessary limits. A limit can restrict a VM even when unused host capacity is available.
- Review network and storage performance as well as CPU and memory. A slow VM is not necessarily CPU-constrained.
Troubleshooting Resource-Sharing Problems
Several VMs Slow Down at the Same Time
Likely cause: CPU, memory, network, or storage contention on the shared ESXi host.
Investigation: Check host-level utilization and determine which resource is constrained. Review CPU demand, memory pressure, network throughput, and storage latency instead of assuming that CPU is the cause.
A Critical VM Performs Worse Than Less Important VMs
Likely cause: The critical VM may have the same default resource priority as other workloads.
Investigation: Review the VM's sizing, shares, and reservations. Change priority only after confirming the source of contention and understanding the effect on other workloads.
A VM Is Slow Even Though Host Resources Appear Available
Likely cause: An explicit CPU or memory limit may be capping the VM, or the workload may be constrained by network or storage I/O.
Investigation: Review VM resource settings and check storage latency and network performance. Available capacity at the host level does not help a VM that is being limited or waiting on another subsystem.
Performance Becomes Inconsistent After Adding VMs
Likely cause: The host may be overcommitted, or the new workloads may compete for the same resource or path.
Investigation: Compare demand patterns, perform capacity planning, and redistribute or resize workloads if necessary. Examine whether the common constraint is CPU, memory, a physical NIC, a datastore, or a storage path.
Key Exam Notes
- ESXi is a bare-metal hypervisor between guest operating systems and physical server hardware.
- A VM's vCPU, memory, virtual disk, and virtual NIC are virtual representations backed by host resources.
- CPU capacity, memory, physical NICs, storage connectivity, and storage I/O capability can all be shared.
- VM memory is allocated and isolated; one VM does not receive unrestricted access to another VM's memory.
- CPU scheduling assigns physical CPU time to vCPUs as demand and availability change.
- Default equal shares describe relative priority during contention, not a permanent equal allocation of every resource.
- Reservations provide guaranteed minimums, while limits cap consumption.
- Resource sharing improves consolidation and utilization, but overcommitment can cause contention and performance problems.
Understanding these principles provides the foundation for VM sizing, performance monitoring, resource pools, and workload distribution in vSphere.