7.4 VM Resource Controls, CPU Groups & Host Compute Partitioning

Virtual Machine Resource Controls, CPU Groups & Host Compute Partitioning

Hypervisor scheduler type decides how virtual processors are placed on logical processors. Resource controls decide how much CPU each virtual machine — or each class of virtual machine — is allowed to consume once it is placed. On a consolidated Hyper-V host running workloads of different business value, the scheduler alone will happily let a runaway batch job starve a production database. Resource controls are how you stop that.

The exam treats this as three related layers: per-VM resource controls, CPU groups, and minroot host partitioning.

---

1. Per-VM Processor Resource Controls

Every virtual machine has had three processor controls since Hyper-V shipped. They are set per VM on the Processor node in Hyper-V Manager, or with Set-VMProcessor.

# Guarantee 20% of host CPU, cap at 75%, and give this VM double default priority
Set-VMProcessor -VMName 'SQL-PROD-01' `
    -Reserve 20 `
    -Maximum 75 `
    -RelativeWeight 200

# Inspect the current controls across every VM on the host
Get-VMProcessor -VMName * |
    Select-Object VMName, Count, Reserve, Maximum, RelativeWeight, HwThreadCountPerCore

[!IMPORTANT] Reserve and Maximum are expressed as a percentage of the virtual machine's own allocated virtual processors, not of the whole host. A VM with 4 vCPUs on a 16-LP host set to -Maximum 50 is capped at 50% of 4 LPs' worth of compute, which is 2 LPs, not 8.

Two behavioural traps show up in scenario questions:

• Reserve blocks VM startup. If the sum of reservations across running VMs would exceed host capacity, the next VM simply fails to start. Over-reserving is the most common cause of a VM that will not power on despite the host showing free memory.
• Weight does nothing on an idle host. Relative weight is only consulted when virtual processors are competing. A ticket that says "the VM is slow but the host is at 20% CPU" is not a weight problem.

[!NOTE] Per-VM processor resource controls (reserve, limit, weight) are not supported when the hypervisor root scheduler is enabled, because scheduling has been handed to the root partition's NT scheduler. They apply only under the classic and core scheduler types — another reason the root scheduler is not recommended on Windows Server.

---

2. CPU Groups: Classes of Service Across Multiple VMs

Per-VM controls cannot express "these twelve tenant VMs together may use no more than half of this host." That is what CPU groups are for. Introduced in Windows Server 2016, a CPU group lets an administrator:

• Bundle virtual machines into a named group with a shared allocation of host CPU, creating tiers or classes of service.
• Apply a group cap that bounds what the entire group may consume, no matter how many VMs are in it.
• Affinitize the group to a specific subset of the host's logical processors, isolating one group's VMs from another's.

[!IMPORTANT] CPU groups are managed only through the Hyper-V Host Compute Service (HCS). Hyper-V Manager, WMI, and PowerShell do not expose CPU groups. Microsoft ships a command-line utility, CpuGroups.exe, on the Microsoft Download Center that drives the HCS interface. If an exam option offers a New-VMCpuGroup cmdlet or a Hyper-V Manager checkbox, it is a distractor.

The Group Cap Formula

The hypervisor enforces a computed group cap:

G = n x C

  G = the amount of host logical-processor time allocated to the group
  n = the number of logical processors in the group
  C = the class of service, as a percentage of total compute capacity

Worked example — a group affinitized to 4 LPs with a 50% cap:

G = 4 x 50% = 2 LPs' worth of CPU time, shared by the whole group

The cap applies regardless of how many VMs are bound to the group and regardless of whether they are running. That produces the single most important operational consequence:

Because the group budget is divided among whoever is bound to it, the administrator or the management layer must re-tune the group cap as VMs are added or removed to keep a target per-VM allocation. Hyper-V will not do it for you.

Working With CpuGroups.exe

Parameters use spaces as delimiters, with no leading / or - before the command verb itself.

:: Show the host's LP, NUMA node, package, core and root VP mapping
CpuGroups.exe GetCpuTopology

:: Create a group affinitized to logical processors 0, 1, 16 and 17
CpuGroups.exe CreateGroup /GroupId:36AB08CB-3A76-4B38-992E-000000000001 /GroupAffinity:0,1,16,17

:: Set that group's cap to 50%  (valid CpuCap range is 0-65536; 32768 = 50%)
CpuGroups.exe SetGroupProperty /GroupId:36AB08CB-3A76-4B38-992E-000000000001 /CpuCap:32768

:: Bind a VM to the group, then list group membership
CpuGroups.exe SetVmGroup /VmName:TenantVM01 /GroupId:36AB08CB-3A76-4B38-992E-000000000001
CpuGroups.exe GetGroupVms

:: Unbind a VM by assigning the NULL GUID, then delete the now-empty group
CpuGroups.exe SetVmGroup /VmName:TenantVM01 /GroupId:00000000-0000-0000-0000-000000000000
CpuGroups.exe DeleteGroup /GroupId:36AB08CB-3A76-4B38-992E-000000000001

Two hard rules to memorise:

• CpuCap is expressed on a 0–65536 scale, not 0–100. 65536 is 100%, 32768 is 50%, 6553 is roughly 10%.
• Only an empty CPU group can be deleted. Deleting a group that still has bound VMs fails with error 0xc0350070; every VM must be reassigned to the NULL GUID first.

A VM also cannot be moved directly between groups. It must be unbound to the NULL GUID first, then bound to the destination group.

---

3. Combining Group Caps With VM Caps

Group caps and per-VM caps are complementary, and a well-designed tiering scheme uses both:

• The group cap stops a whole tier from exceeding its purchased share of the host.
• The per-VM cap stops one member of that tier from opportunistically consuming the whole tier budget while its siblings are idle.

Without a per-VM cap, a single active VM in a lightly loaded "economy" tier will burst to the entire group allocation — which is exactly the behaviour a hosting provider selling fixed-size instances needs to prevent.

---

4. Minroot: Separating Root VPs From Guest VPs

By default Hyper-V creates one root virtual processor on every physical logical processor, mapped 1:1 and never migrated, and guest VPs share those same LPs. For a latency-sensitive premium workload that is unacceptable — root-partition I/O handling introduces scheduling jitter.

The minroot configuration restricts the host (root) partition to a subset of the host's logical processors. Combining minroot with an affinitized CPU group on the remaining LPs gives complete CPU separation: the root partition runs on its own processors and the premium guest runs on processors the root never touches.

:: Restrict the root partition to 8 logical processors (reboot required)
bcdedit /set hypervisorrootproc 8

In CpuGroups.exe GetCpuTopology output, LPs carrying a root VP show a RootVpIndex of 0 or greater; LPs excluded from the root partition by minroot show RootVpIndex = -1 while remaining fully available to guest VPs.

---

5. Choosing the Right Control