VMware ESXi and vSphere Cluster Management
VMware vSphere and ESXi Resource Shares Explained
Learn how VMware vSphere shares prioritize CPU, memory, and supported storage resources during ESXi contention, with formulas, examples, and troubleshooting guidance.
VMware vSphere resource shares are relative weighting values used by the resource scheduler. They help ESXi decide which workloads should receive more of a constrained resource when multiple workloads compete for it.
Shares are not a fixed amount of CPU, memory, or storage throughput. They express priority relative to other workloads in the same scheduling scope. A workload with twice as many shares has twice the relative scheduling weight of a workload with half as many shares, provided both are competing for the same resource and other resource-management settings do not change the result.
What Are vSphere Resource Shares?
A share is a relative priority value assigned to a virtual machine or resource-pool relationship. vSphere can use shares for CPU, memory, and supported storage-related resource scheduling.
For example, consider two VMs competing for CPU:
- VM A has 1,000 CPU shares.
- VM B has 2,000 CPU shares.
VM B has twice VM A's CPU scheduling weight during CPU contention. This does not mean that VM B permanently owns two-thirds of the host's CPU or that VM A is limited to one-third. The relationship becomes important only when both VMs need more CPU than the host can provide at that time.
When Shares Affect Workload Behavior
Resource contention is the condition in which workload demand for a resource exceeds the available supply. Examples include several VMs demanding CPU cycles from an overloaded host or multiple workloads competing for memory that cannot all be kept readily available.
When there is no contention, a lower-share VM can often receive all the CPU, memory, or supported storage service it requests. Its lower share value does not normally act as a cap.
When contention occurs, the scheduler compares the relative weights of active competitors. The exact observed result can also be influenced by reservations, limits, resource-pool hierarchy, actual demand, and other resource-management behavior.
Unconstrained and constrained hosts
- Unconstrained host: A VM with fewer shares may receive all the resources it requests because unused capacity is available.
- Constrained host: Competing VMs cannot all receive their full demand, so share weights help determine relative access to the available capacity.
Relative and Proportional Allocation
Shares are ratios, not guaranteed percentages or fixed quantities. To calculate a workload's theoretical relative weight, total the shares of all active workloads competing for the same resource and divide the workload's shares by that total.
Relative share proportion = workload shares / total shares of active competitorsThis calculation describes a scheduling weight under the stated contention conditions. It is not an unconditional reservation.
Equal-share example
VM A, VM B, and VM C each have 1,000 shares and all demand the same constrained resource.
Total shares = 1,000 + 1,000 + 1,000 = 3,000
Each VM's proportion = 1,000 / 3,000 = 1/3, or approximately 33.3%If all three VMs continue demanding the resource, equal shares produce equal proportional priority.
Unequal-share example
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 = 20%
VM B = 3,000 / 5,000 = 60%
VM C = 1,000 / 5,000 = 20%VM B has three times the shares of either other VM, so it has three times their relative scheduling weight during contention. It still does not receive a permanent 60% allocation when the host is unconstrained or when its demand is lower than that amount.
How the Active Competitor Set Changes Results
Only workloads competing for the same resource in the applicable scheduling scope should be included in a share calculation. CPU shares are compared for CPU contention; memory shares are compared for memory contention. CPU shares do not directly determine memory allocation, and memory shares do not directly determine CPU allocation.
An active competitor is a workload currently demanding the constrained resource within that scope. Powered-on VMs that are not demanding the resource may not have the same practical effect as workloads actively seeking it. The relevant set can change as VMs start, stop, become busy, or become idle.
Adding a fourth VM
Start with VM A, VM B, and VM C having 1,000, 3,000, and 1,000 shares. If VM D starts demanding the same resource with 1,000 shares, the total changes to 6,000.
VM A = 1,000 / 6,000 = approximately 16.7%
VM B = 3,000 / 6,000 = 50%
VM C = 1,000 / 6,000 = approximately 16.7%
VM D = 1,000 / 6,000 = approximately 16.7%No individual configured share value changed, but every VM's relative proportion changed because the total share pool increased.
Removing a VM
If one of the 1,000-share VMs leaves the competing set, the remaining total is 5,000:
VM with 3,000 shares = 3,000 / 5,000 = 60%
Remaining VM with 1,000 shares = 1,000 / 5,000 = 20%Removing a competitor increases the relative proportions of the workloads that remain. Always recalculate using the currently active competitors rather than relying on a previous percentage.
| Scenario | VM | Configured Shares | Total Competing Shares | Relative Proportion During Contention |
|---|---|---|---|---|
| Three equal VMs | A | 1,000 | 3,000 | 33.3% |
| Three equal VMs | B | 1,000 | 3,000 | 33.3% |
| Unequal shares | B | 3,000 | 5,000 | 60% |
| Fourth VM added | B | 3,000 | 6,000 | 50% |
| Fourth VM added | D | 1,000 | 6,000 | 16.7% |
| One 1,000-share VM removed | B | 3,000 | 5,000 | 60% |
Shares Compared with Reservations
A reservation is a configured minimum resource commitment. Subject to admission and available capacity, it protects a specified amount of CPU or memory for a workload. Shares serve a different purpose: they express relative priority when workloads compete for capacity beyond their protected levels.
Suppose a critical application and a batch process both have reservations. If both workloads request resources beyond their reservations and the host cannot satisfy all of that additional demand, shares help determine the relative distribution of the remaining capacity. A reservation does not make shares unnecessary, and shares do not replace a reservation when a guaranteed minimum is required.
| Control | Primary Function | Behavior During Contention | Guarantees Capacity | Typical Use |
|---|---|---|---|---|
| Shares | Assign relative priority | Higher-weight workloads receive a larger relative claim among competitors | No | Prioritize important workloads when distributing constrained capacity |
| Reservation | Establish a protected minimum | Reserved capacity is considered when the workload is admitted and scheduled | Yes, subject to admission and configuration | Protect a required baseline for a critical workload |
| Limit | Set an upper bound | Prevents a workload from using more than the configured maximum | No | Restrict maximum consumption |
Shares for CPU, Memory, and Storage
CPU shares
CPU shares are relative CPU scheduling priorities. During CPU contention, a VM with more CPU shares has a larger claim on available processing time than a competing VM with fewer shares.
Memory shares
Memory shares express relative memory priority during memory contention. They do not reserve a fixed amount of physical memory. If a VM needs less memory than its theoretical proportion, the scheduler can make capacity available to workloads that need it.
Storage shares
Storage shares provide relative priority for supported storage resource scheduling under storage contention. Apply the same reasoning: calculate shares within the relevant storage scheduling scope, and do not confuse a relative weight with a guaranteed throughput amount.
Perform the calculation separately for each resource type. A VM can have high CPU shares and ordinary memory shares because business importance may differ by resource or workload behavior.
Shares and Resource Pools
A resource pool is a logical grouping and hierarchical allocation construct for distributing host resources among workloads. Resource pools can organize VMs and assign relative priority between groups.
When resource pools are used, shares are relevant to parent-child allocation relationships. A pool's allocation relative to sibling pools can affect how much capacity reaches the pool, and shares inside the pool can then influence allocation among its child workloads. Therefore, do not evaluate a VM's share value in isolation when it belongs to a resource-pool hierarchy.
Operational Interpretation
- Assign shares according to workload importance, service priority, or business impact.
- Use shares to prioritize additional capacity during contention, not to model permanent capacity ownership.
- Use reservations when a workload needs a protected minimum.
- Review CPU, memory, and storage priorities independently.
- Reevaluate the active competitor set when VMs start, stop, or change demand.
- Validate changes under realistic contention rather than expecting an immediate visible change on an unconstrained host.
A high-share VM may not visibly consume more resources if it is idle, if the host has spare capacity, or if it does not demand its theoretical proportion. Conversely, a low-share VM may appear to consume substantial resources when higher-priority workloads are idle or when there is no contention.
Configuration concept
Assign or adjust VM share values for CPU, memory, and applicable storage resources through the vSphere resource settings. Choose values that represent relative importance and evaluate them within the relevant host or resource-pool contention domain.
For each resource type and scheduling scope:
1. List active competing workloads.
2. Add their share values to calculate total shares.
3. Divide each workload's shares by that total.
4. Compare the result with actual demand, reservations, limits, and hierarchy.Troubleshooting Share Behavior
A low-share VM still receives substantial resources
The host may not be contended for that resource, or higher-share workloads may not be consuming their potential allocation.
- Confirm resource demand and host utilization.
- Identify whether CPU, memory, or storage is actually constrained.
- Check whether higher-share VMs are active competitors for the same resource.
A high-share VM does not receive an expected fixed percentage
Shares provide a relative weight, not a fixed entitlement. The active competitor set, actual demand, reservations, limits, and resource-pool hierarchy can all affect observed behavior.
- Recalculate using currently competing workloads.
- Verify that the high-share VM is demanding the expected amount.
- Review reservations, limits, and parent resource-pool settings.
Allocation changes after a VM starts or stops
The total shares in the active contention set probably changed.
- List the active workloads sharing the constrained resource.
- Recalculate total shares.
- Calculate each remaining workload's relative proportion.
A critical VM lacks its required minimum
Shares may have been used where a reservation is needed. Determine whether the requirement is a guaranteed minimum, review admission capacity and reservation design, and retain shares for relative priority beyond the protected minimum.
Exam-Relevant Summary
- Shares are relative resource-priority weights.
- Shares matter when demand exceeds available capacity for the relevant resource.
- Shares do not add physical capacity and do not normally impose a cap when capacity is available.
- Relative proportion equals a workload's shares divided by the total shares of active competitors.
- CPU, memory, and storage shares apply to their respective resource types; one type does not directly control another.
- Adding or removing active competitors changes the total share pool and therefore the relative proportions.
- Reservations protect a minimum; shares prioritize access beyond that minimum.
- Resource pools add hierarchy and can change the scope in which shares are interpreted.
For a concise reference, see VMware shares explained.