VMware ESXi and vSphere Cluster Management

Resource Sharing in VMware vSphere and ESXi

Learn how VMware ESXi shares CPU, memory, storage, and network resources among virtual machines, including allocation, contention, priorities, and capacity planning.

Resource sharing is the controlled distribution of a physical server's hardware capacity among multiple virtual machines (VMs). VMware ESXi allows several isolated software-defined computers to run on one physical host while sharing that host's processors, memory, storage paths, network adapters, and other I/O components.

Each VM has its own guest operating system, applications, virtual hardware, and isolation boundary. However, the VM does not own a separate physical server. Its virtual resources are backed by capacity on the ESXi host and are scheduled or serviced as the workload needs them.

This lesson explains how VMware vSphere and ESXi share resources, how VM allocations differ from actual consumption, what happens during contention, and how to plan and troubleshoot shared capacity.

What Resource Sharing Means

Virtualization is the abstraction of physical computing resources into virtual systems that can run independent workloads. A virtual machine is an isolated software-defined computer. Its guest operating system is the operating system installed inside that VM.

A host is the physical server on which ESXi runs. VMware ESXi is a bare-metal hypervisor, meaning it runs directly on server hardware rather than as an application inside another operating system. The host provides the physical capacity that VMs use.

For example, one ESXi host might run a Windows Server VM for an application and a Linux VM for a web service. The VMs are separate from each other, but both may use the same physical CPU cores, RAM modules, network adapters, storage controllers, and disks.

This differs from a traditional dedicated-server model. With dedicated hardware, one physical machine's resources are primarily assigned to one operating system and its applications. With virtualization, the same physical server can support multiple workloads, and ESXi controls how those workloads use shared capacity.

Why Resource Sharing Is a Core Benefit of Virtualization

Many physical servers operate below their maximum capacity. One application might use significant CPU for short periods but little CPU at other times. Another application may need memory or disk capacity at different times. Consolidating these workloads on an ESXi host can improve overall utilization.

  • Higher utilization: workloads can use capacity that would otherwise remain idle on separate servers.
  • Right-sized deployment: administrators can assign virtual capacity based on application requirements instead of deploying one physical server per application.
  • Smaller physical footprint: fewer servers can reduce rack space, power use, cooling requirements, and hardware maintenance.
  • Lower administrative overhead: fewer physical systems may simplify firmware management, monitoring, provisioning, and replacement planning.
  • Operational flexibility: VMs can generally be deployed, resized, moved, backed up, or retired more easily than standalone physical servers.

Consolidation does not create unlimited capacity. It combines workloads on fewer systems, so administrators must verify that the host can handle normal demand, peak demand, and operational overhead.

The Role of the ESXi Hypervisor

A hypervisor creates and operates VMs while managing their use of physical hardware. ESXi presents virtual hardware to each guest operating system, such as virtual CPUs, virtual memory, virtual disks, and virtual network adapters.

The guest operating system normally interacts with this virtual hardware rather than directly owning the host's physical devices. ESXi translates or schedules requests between the virtual hardware view and the physical components.

When workloads compete, ESXi performs several important functions:

  • Scheduling: it schedules vCPU work on available physical processor execution resources.
  • Allocation: it assigns or backs VM memory with host memory resources.
  • Isolation: it prevents one VM from directly accessing another VM's protected memory or virtual devices.
  • Arbitration: it determines how competing workloads receive constrained resources according to demand and configured policies.
  • Device sharing: it allows multiple VMs to use shared storage paths, network uplinks, controllers, buses, and other I/O infrastructure.

Physical Resources Shared by Virtual Machines

CPU: Physical host processor sockets, cores, and execution capacity are shared by virtual CPUs. ESXi schedules active vCPUs on physical CPU resources. A common concern is CPU contention or excessive vCPU configuration.

Memory: Host RAM backs the memory configured for VMs. The host manages finite physical memory while VMs see their assigned virtual memory. Memory pressure can cause reclamation, compression, or swapping and can reduce performance.

Network: A VM uses a virtual network adapter connected to a virtual switch. The virtual switch uses one or more physical NIC uplinks to reach external networks. Shared uplinks can become saturated during backups, replication, or other high-volume transfers.

Storage: Virtual disks are stored as files or volumes on datastores. A datastore may use local disks, shared storage controllers, or networked storage. Several VMs performing intensive I/O can increase datastore or storage-path latency.

I/O infrastructure: Disk controllers, physical NICs, buses, and other host devices serve multiple workloads. Their throughput and queue capacity can limit performance even when CPU and memory appear available.

VM Resource Allocation

When configuring a VM, an administrator defines virtual hardware and policy values. Common allocations include:

  • Virtual CPU count: the number of vCPUs presented to the guest operating system.
  • Memory: the amount of virtual memory presented to the VM.
  • Virtual disk capacity: the configured capacity of the VM's virtual disks on a datastore.
  • Virtual NIC configuration: the VM's virtual network adapters and their connection to virtual networks.

Configured capacity is not the same as active consumption. A VM configured with four vCPUs does not necessarily use four physical cores continuously. If the guest is idle, ESXi schedules little CPU work for it. Similarly, a virtual disk may have a large capacity but perform little I/O at a particular moment.

vCPU: The VM's configured vCPU count. The host supplies physical execution time as the guest has runnable work. The distinction matters because assigning more vCPUs does not automatically improve performance and can increase scheduling complexity.

Memory: The VM's configured memory size. The host backs and manages that memory over time. The distinction matters because the total configured memory and the host's physical RAM may differ, especially in an overcommitted environment.

Disk capacity: The size of the VM's virtual disks. The host supplies storage operations only when the guest issues them. Capacity, I/O operations per second, throughput, and latency are separate considerations.

Network capacity: The VM's virtual NICs and network settings. Actual traffic varies with workload behavior and competes for virtual switch and physical uplink capacity.

Allocation decisions should reflect the application workload. Excessive virtual CPU or memory configuration can be harmful. An oversized VM may increase scheduling work, consume capacity reserved for other workloads, or make contention harder to manage. Start with a justified configuration and adjust it using performance evidence.

Default Distribution and Resource Contention

Under normal conditions, comparable VMs competing for unconstrained resources are generally treated fairly according to their demand and applicable vSphere policies. Fair treatment does not mean that every VM permanently owns an identical amount of physical CPU time, memory bandwidth, network throughput, or storage performance.

Resource contention occurs when simultaneous demand exceeds the host capacity currently available. For example, several VMs may become CPU-intensive at the same time, or multiple VMs may issue disk operations faster than the shared storage system can complete them.

Actual resource delivery depends on:

  • the workload's current behavior and peak demand;
  • the VM's configured vCPU and memory sizes;
  • the host's processor, memory, storage, and network capacity;
  • reservations, limits, shares, and resource-pool policies;
  • other VMs running on the host; and
  • hypervisor overhead and required operational headroom.

Overcommitment means configuring virtual resource demand beyond immediately available physical capacity, relying on scheduling and the fact that workloads are not always busy at the same time. Overcommitment can improve utilization, but it must be monitored carefully and should not be based on assumptions that fail during workload peaks.

Reservations, Limits, and Shares

vSphere resource controls influence how capacity is handled, especially during contention. They should be configured deliberately rather than changed as a first response to every performance problem.

Reservation: Establishes a minimum resource commitment for a VM or resource pool where supported. During contention, the reserved amount receives protection before unreserved capacity is distributed. An excessive reservation can reduce flexibility for other workloads.

Limit: Caps the maximum resource consumption of a VM or resource pool. During contention, or even when capacity is otherwise available, a limit can prevent the workload from using more than its configured maximum. An unintended limit can cause poor performance.

Shares: Express relative priority when multiple workloads compete for available resources. A VM with more shares receives a larger relative entitlement than a VM with fewer shares when both are contending. Shares do not guarantee a fixed physical amount when there is no contention or when total demand exceeds all available capacity.

A practical default is to retain ordinary settings unless there is a documented requirement for guaranteed minimum capacity, a maximum cap, or a relative priority relationship. Always examine the surrounding resource pool and cluster design before changing a VM's policy.

Mixed Guest Operating Systems

A single ESXi host can run VMs with different supported guest operating systems. For example, one VM can run Windows Server for a business application while another runs Linux for an application service or monitoring tool.

Each VM retains its own guest OS, applications, virtual hardware view, and isolation boundary. The operating systems do not become one combined system. They share the host's physical infrastructure only through the resource controls and virtual devices provided by ESXi.

How Resource Sharing Works in Common Scenarios

CPU Sharing Under Normal Load

Suppose several VMs each have vCPUs configured, but only two are actively processing requests. ESXi schedules physical CPU time primarily for the runnable workloads. Idle VMs consume little processor capacity even though their virtual CPUs exist.

CPU Contention and Priority

If two application VMs require CPU at the same time on a heavily used host, both compete for available execution time. If one VM has more CPU shares, it receives a larger relative portion of the available CPU during that contention, subject to other settings and the scope of the policy.

Memory Sizing

A database VM may receive a larger memory configuration because its workload benefits from caching. A lightweight utility VM may receive less. Both allocations still come from the host's finite physical RAM, and the combined demand must be evaluated against host capacity and peak behavior.

Shared Network Uplink

Multiple VMs can connect to a virtual switch whose uplinks are physical NICs. If a backup VM saturates those uplinks, application VMs may experience reduced available bandwidth unless traffic design, policies, or additional uplinks provide separation or capacity.

Storage Competition

Several virtual disks may reside on one datastore. When multiple VMs perform disk-intensive operations simultaneously, the underlying storage path and devices may become busy, increasing latency for several workloads at once.

Capacity Planning and Operations

Before consolidating workloads, assess more than average utilization. Review host CPU capacity, memory capacity, storage performance, network throughput, and expected workload peaks.

  • Allow for ESXi overhead and host operational headroom.
  • Measure peak CPU demand, not only daily averages.
  • Check whether physical RAM can support active VM demand without harmful memory reclamation.
  • Evaluate storage throughput, I/O operations, queueing, and latency.
  • Check physical NIC speed, uplink redundancy, and aggregate network demand.
  • Place workloads so that one high-demand application does not create an avoidable shared bottleneck.
  • Monitor after consolidation and revise VM sizing based on observed behavior.

Useful indicators include CPU utilization, CPU scheduling delay or ready time, memory usage, ballooning, compression, swapping, datastore latency, disk activity, network throughput, and uplink saturation. Good sizing aims for predictable performance during normal operation and reasonable resilience during peaks or maintenance events.

Reviewing VM Settings in the vSphere Client

Review Assigned Virtual Hardware

  1. Open the target virtual machine.
  2. Select Edit Settings.
  3. Review configured CPUs, memory, virtual disks, and network adapters.
  4. Confirm that the allocation matches the workload's documented requirements.

Review Resource Policies

  1. Open the VM configuration or resource settings.
  2. Review CPU and memory reservations, limits, and shares.
  3. Use default values unless a documented performance or prioritization requirement justifies a change.
  4. Consider resource pools and cluster policies before interpreting the VM's settings in isolation.

Check Host-Level Pressure

  1. Open the ESXi host performance views.
  2. Review CPU utilization and CPU scheduling indicators.
  3. Review memory usage and signs of memory reclamation or swapping.
  4. Review datastore latency and network throughput for shared I/O bottlenecks.

PowerCLI Example

The following PowerCLI command lists VM CPU, memory, and selected resource-policy values. It requires a PowerCLI session connected to the relevant vCenter Server or ESXi endpoint.

Get-VM | Select-Object Name, NumCpu, MemoryGB, @{N='CpuShares';E={$_.ExtensionData.ResourceConfig.CpuAllocation.Shares.Shares}}, @{N='CpuReservationMHz';E={$_.ExtensionData.ResourceConfig.CpuAllocation.Reservation}}, @{N='CpuLimitMHz';E={$_.ExtensionData.ResourceConfig.CpuAllocation.Limit}}, @{N='MemShares';E={$_.ExtensionData.ResourceConfig.MemoryAllocation.Shares.Shares}}, @{N='MemReservationMB';E={$_.ExtensionData.ResourceConfig.MemoryAllocation.Reservation}}, @{N='MemLimitMB';E={$_.ExtensionData.ResourceConfig.MemoryAllocation.Limit}}

Troubleshooting Shared-Resource Problems

Multiple VMs Slow During High Activity

Possible causes: CPU contention, too many vCPUs assigned relative to host capacity and workload needs, or a high-priority workload consuming a disproportionate share during contention.

Checks: Review host CPU utilization and VM CPU scheduling metrics. Compare demand with configured vCPU counts. Inspect CPU shares, reservations, and limits.

Corrective direction: Right-size vCPU allocations, remove unnecessary limits, validate priority settings, or add or rebalance capacity.

VM Has Memory-Related Performance Problems

Possible causes: insufficient configured memory, host memory pressure, or host swapping or other memory reclamation activity.

Checks: Review guest memory demand and host memory performance metrics. Check for ballooning, compression, or swapping indicators where applicable. Compare the VM's configuration with application requirements.

Corrective direction: Increase memory only when justified, reduce pressure from other workloads, establish an appropriate reservation for a critical service, or add host memory capacity.

Network Performance Falls During Backup or Replication

Possible causes: saturated physical NIC uplinks, a virtual network design that does not separate high-volume traffic, or insufficient bandwidth and redundancy.

Checks: Review host and VM network throughput during the affected period. Identify the VM or traffic class creating the load. Review virtual switch uplinks and network policy design.

Corrective direction: Reschedule high-bandwidth work, separate traffic where appropriate, or increase available uplink bandwidth.

Several VMs Have Slow Disk Response

Possible causes: datastore or storage-path contention, insufficient aggregate storage performance, or one disk-intensive workload affecting other VMs on the datastore.

Checks: Review datastore latency and VM disk activity. Identify concurrent high-I/O workloads. Verify storage capacity, path health, and workload placement.

Corrective direction: Redistribute workloads, improve storage performance, isolate demanding workloads when necessary, or adjust workload schedules.

Key Exam Notes

  • ESXi is the hypervisor that abstracts host hardware and presents virtual hardware to VMs.
  • A vCPU is not a permanently dedicated physical core unless a specific design and policy provide that behavior.
  • Configured VM capacity and active physical consumption are different measurements.
  • Contention occurs when simultaneous demand exceeds currently available capacity.
  • Reservations provide minimum commitments, limits cap consumption, and shares establish relative priority during contention.
  • Network and storage resources can become bottlenecks even when CPU and memory utilization look acceptable.
  • Overcommitment can improve utilization but requires monitoring, peak-demand analysis, and operational headroom.
  • Resource sharing preserves VM isolation while allowing multiple guest operating systems and applications to use one physical host.

Summary

VMware vSphere uses ESXi to share a physical host's CPU, memory, storage, network, and I/O infrastructure among multiple isolated VMs. Each VM receives configured virtual hardware, but ESXi determines how physical capacity is scheduled and supplied over time.

Resource sharing improves consolidation and flexibility, but it requires deliberate sizing and monitoring. Understanding the difference between configured capacity and active consumption, recognizing contention, and using reservations, limits, and shares appropriately are essential to maintaining predictable VM performance.

Continue with Resource Sharing Explained for the central reference on this topic.