VMware ESXi and vSphere Cluster Management

VMware vSphere Shares Explained

Learn how VMware vSphere CPU, memory, and storage shares prioritize virtual machines during contention, and how shares differ from reservations and limits.

VMware vSphere shares are relative priority weights. They help ESXi decide how to distribute a constrained resource among competing virtual machines (VMs). Shares can apply to CPU, memory, and storage I/O.

A share value is not a quantity of CPU, memory, or storage. It is not a guaranteed percentage and does not reserve capacity by itself. Instead, it expresses how strongly one VM should be favored relative to other active consumers of the same resource.

What Are VMware Shares?

Shares are relative resource-priority weights assigned to a VM or another resource consumer. For example, if one VM has 2,000 CPU shares and another has 1,000 CPU shares, the first VM has twice the CPU allocation weight of the second when both are actively competing for scarce CPU capacity.

Shares are defined separately for resource categories:

  • CPU shares: relative CPU scheduling priority during CPU contention.
  • Memory shares: relative memory priority during memory contention.
  • Storage shares: relative storage I/O priority during storage contention.

The important distinction is that shares describe priority, not an absolute entitlement. A VM with 3,000 shares does not automatically receive 3,000 MHz, 3,000 MB, or a fixed percentage of storage bandwidth.

When Do Shares Take Effect?

Shares matter when two conditions are present:

  1. Multiple active VMs request the same resource.
  2. The available capacity cannot satisfy all of that demand.

This condition is called resource contention: demand for a host resource exceeds the capacity available to competing workloads. During contention, ESXi uses share weights to influence proportional allocation.

If the host has adequate unused CPU, memory, or storage capacity, a low-share VM can use that available capacity. Giving a VM more shares does not make it faster merely because the value is larger. Shares become significant when competing demand makes prioritization necessary.

How Proportional Allocation Works

To estimate a VM's relative allocation during contention, divide its shares by the total shares of all active VMs competing for the same resource:

Relative allocation percentage = VM shares / total active shares × 100

Total shares means the sum of the share values for the active consumers in that resource competition. The calculation is dynamic: powering on or powering off a competing VM changes the total and can change every remaining VM's effective entitlement.

Example: Equal Shares

VM A, VM B, and VM C each have 1,000 shares and all request the same constrained resource.

Total shares = 1,000 + 1,000 + 1,000 = 3,000
Each VM = 1,000 / 3,000 × 100 = 33.3%

Each VM has an equal one-third relative allocation weight. This does not mean each VM will always consume exactly one-third. Each must have sufficient demand, and the resource must actually be contended.

Example: Unequal Shares

Suppose VM A has 1,000 shares, VM B has 3,000 shares, and VM C has 1,000 shares.

Total shares = 1,000 + 3,000 + 1,000 = 5,000
VM A = 1,000 / 5,000 × 100 = 20%
VM B = 3,000 / 5,000 × 100 = 60%
VM C = 1,000 / 5,000 × 100 = 20%

VM B has three times the share weight of each one-share-unit peer, so its relative allocation is three times as large during this contention scenario.

Share Weight Calculation Examples

Scenario: Three VMs with 1,000 shares each

VM A | Configured shares: 1,000 | Total active shares: 3,000 | Relative allocation: 33.3%

VM B | Configured shares: 1,000 | Total active shares: 3,000 | Relative allocation: 33.3%

VM C | Configured shares: 1,000 | Total active shares: 3,000 | Relative allocation: 33.3%

Scenario: Three VMs with 1,000, 3,000, and 1,000 shares

VM A | Configured shares: 1,000 | Total active shares: 5,000 | Relative allocation: 20%

VM B | Configured shares: 3,000 | Total active shares: 5,000 | Relative allocation: 60%

VM C | Configured shares: 1,000 | Total active shares: 5,000 | Relative allocation: 20%

Scenario: Four VMs with 1,000, 3,000, 1,000, and 1,000 shares

VM A | Configured shares: 1,000 | Total active shares: 6,000 | Relative allocation: approximately 16.7%

VM B | Configured shares: 3,000 | Total active shares: 6,000 | Relative allocation: 50%

VM C | Configured shares: 1,000 | Total active shares: 6,000 | Relative allocation: approximately 16.7%

VM D | Configured shares: 1,000 | Total active shares: 6,000 | Relative allocation: approximately 16.7%

Scenario: VM C removed from the four-VM example

VM A | Configured shares: 1,000 | Total active shares: 5,000 | Relative allocation: 20%

VM B | Configured shares: 3,000 | Total active shares: 5,000 | Relative allocation: 60%

VM D | Configured shares: 1,000 | Total active shares: 5,000 | Relative allocation: 20%

Changing the Active VM Population

A VM's configured share count can remain unchanged while its effective entitlement changes. Effective entitlement is the relative portion the VM can receive under contention based on its shares and the current set of contenders.

Powering On Another VM

Starting with shares of 1,000, 3,000, and 1,000, the total is 5,000. VM B has a 60% relative weight. If VM D starts with 1,000 shares, the total becomes 6,000:

  • VM B changes from 60% to 50%.
  • Each 1,000-share VM changes from 20% to approximately 16.7%.

The existing VMs did not lose configured shares. A new competing VM added share weight to the total pool.

Powering Off or Removing a VM

If VM C is powered off or otherwise stops competing, the total in the four-VM example falls from 6,000 to 5,000. The remaining VMs receive larger proportional weights:

  • VM B increases from 50% to 60%.
  • Each remaining 1,000-share VM increases from approximately 16.7% to 20%.

Always calculate shares against the current active contenders, not against every VM that exists in inventory.

Shares Versus Reservations and Limits

Shares, reservations, and limits solve different resource-management problems.

Shares | Primary function: relative priority | Effect during contention: influence proportional allocation among competing consumers | Guarantee or cap: neither | Key caution: effective percentages change when contenders change

Reservation | Primary function: establish a configured minimum resource commitment when applicable capacity and platform conditions allow it | Effect during contention: reserved capacity is considered before share-based distribution of remaining capacity | Guarantee or cap: minimum commitment, subject to availability and configuration conditions | Key caution: it consumes or protects capacity that may not be available to other workloads

Limit | Primary function: cap resource consumption | Effect during contention: the VM cannot consume above the configured boundary, even if it has unused share priority | Guarantee or cap: upper cap | Key caution: a high share value cannot overcome a restrictive limit

A reservation is a minimum commitment, not a priority weight. A limit is an upper boundary, not a priority weight. Shares do not create a guaranteed minimum and do not create a consumption cap.

In a simplified allocation scenario, after applicable guaranteed capacity is considered, share weights determine the priority for resource capacity that remains insufficient for all active demand. Actual behavior also depends on the resource category, VM demand, configured limits, reservations, and the platform's resource-management rules.

Operational Uses for Shares

Shares are most useful when the business needs a predictable priority order during host pressure. For example, you might give production application VMs more relative shares than development, test, or batch VMs so production workloads receive greater weight when the same resource is constrained.

Choose values according to business importance rather than changing shares as routine performance tuning. A useful process is:

  1. Identify the resource category under pressure: CPU, memory, or storage I/O.
  2. List every active VM or resource consumer competing for that category.
  3. Classify workloads by business importance and service objectives.
  4. Assign equal shares to workloads with equal priority.
  5. Assign larger relative values to workloads that should receive more priority during contention.
  6. Check reservations and limits so they do not conflict with the intended result.
  7. Monitor contention and review the configuration when the VM population or workload importance changes.

Do not interpret a single VM's share value in isolation. The same value can produce different effective percentages in different clusters, hosts, resource pools, or active VM populations.

Configuration and Planning Formula

Configure the share value for the relevant VM resource category. Use equal values for equal priority and larger relative values for workloads that should receive more weight during contention.

VM relative allocation = VM shares / sum of active competing VM shares × 100

Use this formula for contention planning. It is not a promise that the VM will constantly consume that percentage. A VM that needs only a small amount of CPU, memory, or storage I/O may consume less, even when its theoretical contention weight is high.

Troubleshooting Share Behavior

A High-Share VM Does Not Appear Faster

Likely cause: The resource is not contended, so shares are not governing allocation.

Check: Confirm actual CPU, memory, or storage pressure and verify that the VMs are competing for the same resource. Under idle conditions, both VMs may receive all the capacity they need.

A VM's Expected Percentage Drops When Another VM Starts

Likely cause: The newly active VM added shares to the total.

Check: Recalculate the percentage using the updated total active shares. A VM's configured share count may be unchanged even though its effective entitlement is lower.

A VM Has Many Shares but Cannot Consume More

Likely causes: A configured limit caps consumption, or the VM does not have enough workload demand.

Check: Review limits and workload demand separately from shares. High shares do not override a limit and do not create demand.

An Administrator Expects Shares to Guarantee a Minimum

Likely cause: Shares have been confused with reservations.

Check: Review reservation settings when the requirement is a minimum resource commitment. Use shares when the requirement is relative priority among competing consumers.

Exam-Relevant Notes

  • Shares are relative weights, not absolute resource quantities.
  • Shares influence allocation only during contention.
  • The calculation is VM shares divided by total active competing shares.
  • Equal shares provide equal relative weighting among comparable contenders.
  • Three times the shares provide three times the relative weight, not a permanent guaranteed percentage.
  • Powering on a competing VM increases total shares and can reduce existing VMs' percentages.
  • Powering off a competing VM reduces total shares and can increase the remaining VMs' percentages.
  • Reservations establish minimum commitments; limits establish maximum consumption; shares establish relative priority.
  • Demand is required: a VM does not automatically consume its theoretical share percentage.

Related Resource Management Topics

For broader practice, review how resource pools work, creating a resource pool, and memory overcommitment. These topics help explain how resource priorities interact with the wider vSphere environment.