Study guide
7.4 VM Resource Controls, CPU Groups & Host Compute Partitioning
Administering Windows Server Hybrid Core Infrastructure AZ-800
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
About Exam AZ-800: Format, Scoring & the September 2026 Retirement
2 Chapter 1: Active Directory Domain Services Architecture & Deployment
1.1 Deploying & Managing Domain Controllers On-Premises 1.2 Domain Controllers in Azure IaaS & Virtualized DC Cloning 1.3 Read-Only Domain Controllers (RODCs) & Password Replication Policies 1.4 Flexible Single Master Operation (FSMO) Roles & Troubleshooting 1.5 Active Directory Sites, Subnets & Site Link Topology 1.6 AD DS Replication: Topology Generation, Convergence & Diagnostics 1.7 Forest and Domain Trust Relationships
3 Chapter 2: AD DS Security Principals, Service Accounts & Domain Join
2.1 Managing Users, Groups & Objects in Multi-Domain and Multi-Forest Environments 2.2 Service Account Types & Group Managed Service Accounts (gMSA) 2.3 Joining Windows Server to AD DS, Microsoft Entra Domain Services & Microsoft Entra ID 2.4 Creating & Managing Users, Groups and Organizational Units at Scale
4 Chapter 3: Hybrid Identity & Microsoft Entra Integration
3.1 Microsoft Entra Connect Sync Architecture, Installation & Filtering 3.2 SourceAnchor, Synchronization Rules & Microsoft Entra Connect Health 3.3 Microsoft Entra Cloud Sync & Disconnected Multi-Forest Topologies 3.4 Hybrid Authentication Methods & Staged Rollout 3.5 Microsoft Entra Domain Services 3.6 Integrating Microsoft Entra ID, AD DS & Entra Domain Services: Choosing an Architecture
5 Chapter 4: Group Policy in AD DS and Hybrid Environments
4.1 Group Policy Architecture & Processing Order (LSDOU) 4.2 Group Policy Filtering, Loopback Processing & Client-Side Extensions 4.3 Group Policy Preferences, Item-Level Targeting & Central Store 4.4 Group Policy in Microsoft Entra Domain Services & Fine-Grained Password Policies
6 Chapter 5: Remote Server Management in Hybrid Environments
5.1 Windows Admin Center (WAC) Deployment On-Premises and in Azure 5.2 PowerShell Remoting, WinRM & the Kerberos Double-Hop Problem 5.3 Just Enough Administration (JEA) for Constrained PowerShell Endpoints 5.4 OpenSSH on Windows Server & PowerShell Remoting over SSH 5.5 Secure RDP Access, Remote Desktop Gateway & Azure Bastion
7 Chapter 6: Hybrid Management with Azure Arc and Azure Services
6.1 Azure Arc-Enabled Servers Architecture & Onboarding 6.2 Azure Machine Configuration & VM Extensions on Arc Servers 6.3 Azure Update Manager: Assessment, Maintenance Configurations & Dynamic Scoping 6.4 Azure Automation for Hybrid Workloads: Runbooks & Hybrid Runbook Workers
8 Chapter 7: Hyper-V Virtualization & Virtual Machine Configuration
7.1 Hyper-V Type 1 Architecture, Installation & Hardware Prerequisites 7.2 VM Generations, Secure Boot, vTPM, Enhanced Session Mode & Direct VM Access 7.3 Compute, Dynamic Memory & Hardware Acceleration 7.4 VM Resource Controls, CPU Groups & Host Compute Partitioning 7.5 Hyper-V Virtual Hard Disks & Checkpoint Management 7.6 Hyper-V Virtual Switches, NIC Teaming & Switch Embedded Teaming (SET) 7.7 Integration Services, Guest Components & Time Synchronization
9 Chapter 8: Hyper-V High Availability, Security & Containers
8.1 Hyper-V Failover Clustering & Cluster Shared Volumes (CSV) 8.2 Hyper-V Replica & Azure Site Recovery (ASR) 8.3 Guarded Fabric & Shielded Virtual Machines 8.4 Windows Server Container Hosts, Isolation Models & Images 8.5 Managing Container Instances & Linux Containers with WSL 8.6 Windows Container Networking & AKS Enabled by Azure Arc 8.7 Managing Container Images, Tags & Azure Container Registry
10 Chapter 9: Azure IaaS Virtual Machine Administration
9.1 Azure VM Sizing, Series Selection & Managed Disk Tiers 9.2 Azure VM Host Caching, Disk Bursting, Ephemeral OS Disks & Disk Operations 9.3 Azure VM High Availability: Availability Sets, Zones & Proximity Placement Groups 9.4 Virtual Machine Scale Sets, Autoscale & Azure Dedicated Hosts 9.5 Azure VM Networking, NSGs & Connectivity
11 Chapter 10: Hybrid DNS Infrastructure & Name Resolution
10.1 Active Directory-Integrated DNS Architecture, Dynamic Updates & Zone Types 10.2 DNS Records, Aging & Scavenging and the GlobalNames Zone 10.3 DNS Forwarding, Conditional Forwarding & Azure DNS Zone Integration 10.4 Hybrid Name Resolution with Azure DNS Private Resolver 10.5 Windows Server DNS Policies & DNSSEC
12 Chapter 11: IP Addressing, DHCP & IPAM Management
11.1 DHCP Server Role, the DORA Lifecycle & Active Directory Authorization 11.2 DHCP Scopes, Option Hierarchy, Reservations & Relay Agents 11.3 DHCP High Availability & Failover Configurations 11.4 IP Address Management (IPAM) Deployment & Auditing 11.5 Resolving IP Address Issues in Hybrid Environments
13 Chapter 12: Hybrid Network Connectivity, Remote Access & Private Access
12.1 Remote Access Role, VPN Protocols & Site-to-Site VPN to Azure 12.2 Network Policy and Access Services (NPAS), RADIUS & Policy Processing 12.3 Azure Network Adapter & Azure Extended Network 12.4 Web Application Proxy & Microsoft Entra Application Proxy 12.5 Microsoft Entra Private Access & Global Secure Access 12.6 Azure Relay & Hybrid Connections
14 Chapter 13: File Services, DFS, SMB & Azure File Sync
13.1 Windows Server File Share Access, NTFS Permissions & Access-Based Enumeration 13.2 File Server Resource Manager: Quotas, File Screens & Storage Reports 13.3 DFS Namespaces (DFS-N) & DFS Replication (DFS-R) 13.4 BranchCache: Distributed Cache and Hosted Cache Modes 13.5 Modern SMB Protocols, SMB Multichannel & SMB over QUIC 13.6 Azure File Shares, Tiers & Hybrid Permissions 13.7 Azure File Sync, Cloud Tiering & Monitoring 13.8 Migrating DFS Namespaces & DFS Replication to Azure File Sync
15 Chapter 14: Windows Server Storage Infrastructure & High Availability
14.1 Disk Partitioning, Volumes & Enterprise File Systems (NTFS vs ReFS) 14.2 Data Deduplication Architecture, Usage Types & Management 14.3 Storage Spaces & Storage Spaces Direct (S2D) 14.4 Storage Replica & Storage Quality of Service 14.5 iSCSI Target Server, IQNs, CHAP Authentication & Multipath I/O
7.4 VM Resource Controls, CPU Groups & Host Compute Partitioning
Key Takeaways Explain This Topic AI
Per-VM processor controls are reserve (a guaranteed floor that blocks VM startup if unavailable), limit (a hard ceiling), and relative weight (1–10000 priority that only takes effect when the host is contended).
Reserve and Maximum on Set-VMProcessor are percentages of the VM's own allocated virtual processors, not of total host capacity.
CPU groups are managed only through the Host Compute Service using the downloadable CpuGroups.exe utility; Hyper-V Manager, WMI, and PowerShell provide no CPU group interface.
The CPU group cap is computed as G = n x C, where n is the number of logical processors in the group and C is the class-of-service percentage, and the resulting budget is shared by every VM bound to the group.
Per-VM reserve, limit, and weight are unsupported under the hypervisor root scheduler because scheduling is delegated to the root partition's NT scheduler.
Last updated: August 2026
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 .
Control Hyper-V Manager label What it does
Reserve Virtual machine reserve (percentage) Guarantees a minimum share of host CPU. The VM will not start if the host cannot honour the reservation
Limit Virtual machine limit (percentage) Hard ceiling. The VM can never exceed this share of host CPU even when the host is idle
Weight Relative weight Relative priority, 1–10000, used only when the host is contended. A weight of 200 gets twice the CPU of a weight of 100 # 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:
- VMs bound to the group Each VM's effective share of a 50% group cap on 8 LPs
- 1 50% of the host (4 LPs' worth)
- 2 25% each (2 LPs' worth each)
- 4 12.5% each (1 LP's worth each)
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
- Requirement Correct mechanism
- Guarantee a database VM never drops below a floor of CPU Per-VM reserve
- Stop one VM exceeding a fixed ceiling Per-VM limit ( -Maximum )
- Prioritise VM A over VM B only when the host is busy Per-VM relative weight
- Cap what an entire tenant tier may consume collectively CPU group cap via CpuGroups.exe
Guarantee tenant A's VMs never share a physical core with tenant B's CPU group affinity (plus the core scheduler)