Study guide
7.3 Compute, Dynamic Memory & Hardware Acceleration
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.3 Compute, Dynamic Memory & Hardware Acceleration
Key Takeaways Explain This Topic AI
Hypervisor Scheduler types define CPU execution models: Classic scheduler (fair-share LP), Core scheduler (mitigates SMT/hyperthreading side-channel attacks by assigning entire physical cores to a single VM), and Root scheduler (client OS).
Nested Virtualization enables running Hyper-V inside a guest VM by exposing hardware virtualization extensions ( Set-VMProcessor -ExposeVirtualizationExtensions $true ), requiring static memory and MAC spoofing on the outer vNIC.
Dynamic Memory dynamically balances RAM between Startup, Minimum, and Maximum thresholds using a ballooning driver, while Memory Buffer (default 20%) maintains emergency headroom.
Smart Paging creates temporary host disk paging files ( .slp ) exclusively during VM restarts when host physical RAM is constrained and the VM cannot reach its Startup RAM allocation.
Discrete Device Assignment (DDA) dismounts physical PCIe hardware from the host and grants direct, exclusive guest access for near-native GPU/NVMe performance, whereas GPU Partitioning (GPU-P) fractionalizes physical GPUs across VMs.
Last updated: August 2026
Compute, Dynamic Memory & Hardware Acceleration
Optimizing Hyper-V compute and memory resources requires a deep understanding of processor scheduling, security boundary mitigation against side-channel vulnerabilities, nested virtualization configurations, dynamic memory management algorithms, and PCIe hardware acceleration technologies.
1. VM Compute Resource Allocation & Hypervisor Schedulers
Hyper-V provisions compute to virtual machines in the form of virtual processors (vCPUs) . When allocating vCPUs, administrators configure the number of processors, resource weights, and resource reserves, while aligning with host Non-Uniform Memory Access (NUMA) node topologies. # Configure VM processor count and relative scheduling weight
- Set-VMProcessor -VMName "VM-APP-01" `
- Count 8 `
- Reserve 10 `
- Maximum 100 `
- RelativeWeight 200
- Virtual NUMA (vNUMA)
On multi-socket physical hosts, physical memory is partitioned across NUMA nodes directly attached to specific CPU sockets. Accessing local NUMA memory is significantly faster than accessing remote NUMA memory across the interconnect bus (QPI/UPI/Infinity Fabric).
vNUMA projects the physical host's NUMA topology into guest VMs with more than one NUMA node of resources, ensuring guest OS multi-threaded workloads (e.g., SQL Server) allocate and access memory within the same NUMA node to maximize throughput.
Hypervisor Scheduler Architectures
Starting with Windows Server 2019 and continuing in Windows Server 2022 and 2025, Microsoft redesigned the hypervisor processor scheduler to protect multi-tenant cloud and enterprise virtualization environments against processor microarchitectural side-channel attacks (e.g., Spectre, Meltdown, L1 Terminal Fault / Foreshadow, MDS). +-----------------------------------------------------------------------------------------+
- | HYPER-V HYPERVISOR SCHEDULER COMPARISON |
- | |
- | CLASSIC SCHEDULER CORE SCHEDULER |
- | +---------------------------------------+ +-----------------------------------+ |
- | | Physical Core 0 (SMT Enabled) | | Physical Core 0 (SMT Enabled) | |
- | | - Logical Processor 0: [VM-A vCPU 0] | | - Logical Processor 0: [VM-A vCPU0] | |
- | | - Logical Processor 1: [VM-B vCPU 0] | | - Logical Processor 1: [VM-A vCPU1] | |
- | | | | | |
- | | (Vulnerable to cross-tenant SMT | | (Guaranteed isolation: Only vCPUs | |
- | | speculative execution side-channel) | | from the SAME VM share SMT core) | |
- | +---------------------------------------+ +-----------------------------------+ |
- +-----------------------------------------------------------------------------------------+
Scheduler Type Scheduling Model Security & Performance Profile
Classic Scheduler Fair-share, round-robin per-Logical Processor (LP) scheduling. High compute density. Virtual processors from different VMs can be scheduled simultaneously on adjacent SMT threads (hyperthreads) of the same physical core, exposing workloads to cross-tenant side-channel snooping.
Core Scheduler (Default) Schedules all SMT sibling threads of a physical core exclusively to vCPUs of the same virtual machine . Mitigates SMT side-channel vulnerabilities across tenant boundaries. Provides strict compute isolation at the hardware core level without requiring hyperthreading to be disabled in UEFI.
Root Scheduler Delegates LP scheduling to the root partition's Windows OS scheduler. Default on Windows 10/11 client Hyper-V; optimized for desktop responsiveness and client workloads. :: Query current hypervisor scheduler type
bcdedit /enum {current}
- :: Configure the hypervisor to enforce the Core Scheduler on Windows Server
- bcdedit /set hypervisorschedulertype Core
- 2. Nested Virtualization Architecture & Configuration
Nested Virtualization allows running Hyper-V inside a Hyper-V guest virtual machine. This technology enables running nested VMs, Windows Subsystem for Linux (WSL2), Windows Sandbox, and Hyper-V-isolated Docker containers inside guest servers. +-----------------------------------------------------------------------------------------+
- | NESTED VIRTUALIZATION STACK |
- | |
- | +---------------------------------------------------------------------------------+ |
- | | INNER GUEST VM (Level 2) | |
- | | - Container Workload / Nested Hyper-V Child VM | |
- | +---------------------------------------------------------------------------------+ |
- | | |
- | +---------------------------------------------------------------------------------+ |
- | | OUTER GUEST VM (Level 1 Hyper-V Host) | |
- | | - Windows Server 2022/2025 with Hyper-V Role Installed | |
- | | - Static / Fixed Memory Allocated (Dynamic Memory must be disabled) | |
- | | - Virtualization Extensions Exposed to vCPU via Set-VMProcessor | |
- | +---------------------------------------------------------------------------------+ |
- | | (VMBus & Hypervisor Trap Forwarding) |
- | +---------------------------------------------------------------------------------+ |
- | | PHYSICAL HYPER-V HOST (Level 0 Bare-Metal) | |
- | | - Intel VT-x with EPT or AMD-V with RVI Physical Processor | |
- | | - Physical vSwitch with MAC Address Spoofing Enabled on Outer VM vNIC | |
- | +---------------------------------------------------------------------------------+ |
- +-----------------------------------------------------------------------------------------+
- Technical Prerequisites for Nested Virtualization
Hardware: Physical host must have an Intel processor with VT-x and EPT, or an AMD processor with AMD-V and RVI (supported in Windows Server 2022/2025 and Windows 11).
VM Generation: Generation 2 VM (recommended) with VM Configuration Version 8.0 or higher.
Memory Configuration: Dynamic Memory must be disabled on the outer VM; the outer VM requires static fixed RAM.
- Step-by-Step Deployment Workflow # Step 1: Turn off the target Outer Virtual Machine
- Stop-VM -Name "VM-NestedHost-01" -Force
- # Step 2: Expose hardware virtualization extensions to the outer VM's vCPU
- Set-VMProcessor -VMName "VM-NestedHost-01" -ExposeVirtualizationExtensions $true
- # Step 3: Disable Dynamic Memory and set static memory allocation
- Set-VMMemory -VMName "VM-NestedHost-01" -DynamicMemoryEnabled $false -StartupBytes 16GB
- # Step 4: Configure MAC Address Spoofing on the outer VM's network adapter
- # Required so inner VMs (with distinct MAC addresses) can communicate across the physical vSwitch
- Get-VMNetworkAdapter -VMName "VM-NestedHost-01" | Set-VMNetworkAdapter -MacAddressSpoofing On
- # Step 5: Start the outer VM
- Start-VM -Name "VM-NestedHost-01"
Important
Exam Trap (Nested VM Networking): If MAC Address Spoofing is not enabled on the outer VM's virtual network adapter, the physical host's vSwitch will drop incoming packets from inner VMs because their MAC addresses are unknown to the top-level switch. Alternatively, you can configure an Internal Virtual Switch with NAT inside the outer VM.
3. Dynamic Memory Mechanics & Configuration
Dynamic Memory is Hyper-V's automated memory management mechanism that reclaims unused physical RAM from idle VMs and reallocates it to workloads under active memory pressure. +-----------------------------------------------------------------------------------------+
- | DYNAMIC MEMORY ARCHITECTURE |
- | |
- | +---------------------------------------------------------------------------------+ |
- | | Maximum RAM: Upper ceiling threshold (e.g. 16 GB) | |
- | | |
- | | [CURRENT COMMITTED RAM] = Workload Active Footprint + Memory Buffer (e.g. 20%) | |
- | | |
- | | Startup RAM: Initial RAM allocation during guest boot (e.g. 4 GB) |
- | | |
- | | Minimum RAM: Lowest reclaimed threshold after boot initialization (e.g. 2 GB) | |
- | +---------------------------------------------------------------------------------+ |
- +-----------------------------------------------------------------------------------------+
- Dynamic Memory Parameters
Startup RAM: The exact amount of physical memory allocated to the virtual machine during initial power-on and operating system boot (e.g., 4096 MB).
Minimum RAM: The lowest amount of physical RAM Hyper-V can reclaim down to after the guest OS has completed initialization (e.g., 2048 MB).
Maximum RAM: The upper ceiling boundary beyond which Hyper-V will never allocate additional RAM to the VM (e.g., 16384 MB).
Memory Buffer (%): The percentage of available free RAM Hyper-V attempts to maintain inside the guest VM as headroom for unexpected memory spikes. The default is 20% (range: 5% to 2000%). Buffer RAM = Committed Memory × ( Buffer Percentage 100 ) \text{Buffer RAM} = \text{Committed Memory} \times \left(\frac{\text{Buffer Percentage}}{100}\right) Buffer RAM = Committed Memory × ( 100 Buffer Percentage )
Memory Weight (Priority): A relative priority slider (value 1 to 100, default 50). When physical host memory is fully saturated, Hyper-V prioritizes allocating available RAM to VMs with higher memory weights. # Configure Dynamic Memory parameters via PowerShell
- Set-VMMemory -VMName "VM-APP-01" `
- DynamicMemoryEnabled $true `
- StartupBytes 4GB `
- MinimumBytes 2GB `
- MaximumBytes 16GB `
- Buffer 20 `
- Priority 70
- Memory Ballooning Mechanics
Dynamic Memory uses an in-guest balloon driver ( dm_balloon ). When Hyper-V needs to reclaim memory from a VM, the hypervisor instructs the balloon driver to inflate, consuming memory pages within the guest OS. The guest OS writes these pages to its internal pagefile, and the hypervisor frees the underlying physical host memory frames for other VMs.
4. Smart Paging Mechanics
Smart Paging solves a specific operational challenge: restarting a virtual machine when physical host memory is overcommitted. +-----------------------------------------------------------------------------------------+
- | SMART PAGING WORKFLOW |
- | |
- | 1. VM is running stably at Minimum RAM (2 GB). Host physical RAM is 100% full. |
- | 2. Administrator restarts the VM. |
- | 3. VM OS boot loader requires Startup RAM (4 GB) to initialize kernel & drivers. |
- | 4. Host lacks 2 GB of physical RAM to bridge the gap. |
- | 5. Hyper-V creates a temporary Smart Paging file (.slp) on host disk storage. |
- | 6. VM boots successfully using disk-backed Smart Paging memory. |
- | 7. Within 10 minutes, guest drivers initialize; memory is ballooned down to 2 GB. |
- | 8. Smart Paging file (.slp) is automatically deleted from host storage. |
- +-----------------------------------------------------------------------------------------+
- Smart Paging Trigger Criteria
Smart Paging is engaged only when all of the following conditions are simultaneously true:
The virtual machine is being restarted (not started from a stopped/powered-off state).
There is no available physical host RAM to fulfill the difference between Minimum RAM and Startup RAM .
No memory can be reclaimed from other virtual machines on the host.
Caution
Performance Impact: Smart Paging uses disk storage for temporary memory, which causes severe I/O latency while active. To minimize impact, store Smart Paging files on high-speed solid-state storage (NVMe/SSD). # Configure the Smart Paging storage path for a virtual machine
- Set-VM -VMName "VM-APP-01" -SmartPagingFilePath "D:\Hyper-V\SmartPaging"
- 5. Hardware Acceleration: DDA, GPU-P & SR-IOV
Modern enterprise workloads (AI inference, machine learning, VDI graphics rendering, 100GbE networking) require bypassing hypervisor abstraction layers to achieve line-rate throughput and bare-metal latency. +-----------------------------------------------------------------------------------------+
- | HARDWARE ACCELERATION COMPARISON MATRIX |
- | |
- | DISCRETE DEVICE ASSIGNMENT (DDA) GPU PARTITIONING (GPU-P) |
- | +------------------------------------+ +------------------------------------+ |
- | | Physical PCIe Device (e.g. GPU) | | Physical GPU (e.g. NVIDIA A16/A40) | |
- | | | | | - Partition 1: [VM-VDI-01 (25%)] | |
- | | v | | - Partition 2: [VM-VDI-02 (25%)] | |
- | | Exclusively mapped to SINGLE VM | | - Partition 3: [VM-VDI-03 (50%)] | |
- | | (Near 100% native performance) | | (Fractional shared GPU slicing) | |
- | +------------------------------------+ +------------------------------------+ |
- +-----------------------------------------------------------------------------------------+
- 1. Discrete Device Assignment (DDA)
Architecture: Dismounts an entire physical PCIe device (such as an NVIDIA GPU, NVMe SSD, or SAS controller) from the host root partition and passes it directly into a child VM.
Performance: Bypasses the VMBus and hypervisor abstraction, delivering near-native bare-metal execution.
Operational Restrictions: VMs utilizing DDA cannot be live-migrated, cannot use Dynamic Memory, and cannot take standard checkpoints with memory state. # Step 1: Query location path of target PCIe GPU on host
$pciPath = (Get-PnpDevice -FriendlyName "*NVIDIA*" | Get-PnpDeviceProperty -KeyName 'DEVPKEY_Device_LocationPaths').Data[0]
- # Step 2: Disable device in host OS Device Manager
- Disable-PnpDevice -InstanceId (Get-PnpDevice -FriendlyName "*NVIDIA*").InstanceId -Confirm:$false
- # Step 3: Dismount device from host root partition
- Dismount-VMHostAssignableDevice -LocationPath $pciPath -Force
- # Step 4: Configure VM memory parameters required for DDA
- Set-VM -VMName "VM-AI-01" -AutomaticStopAction TurnOff
Set-VM -VMName "VM-AI-01" -GuestControlledCacheTypes $true -LowMemoryMappedIoSpace 3GB -HighMemoryMappedIoSpace 32GB
- # Step 5: Assign PCIe device directly to the child virtual machine
- Add-VMAssignableDevice -VMName "VM-AI-01" -LocationPath $pciPath
- 2. GPU Partitioning (GPU-P)
Divides a single physical graphics processing unit into multiple virtual GPU partitions, allocating fractional GPU compute and dedicated VRAM slices to multiple concurrent VMs.
Supported on Windows Server 2025 and Azure Stack HCI for VDI and AI inference workloads.
3. Single Root I/O Virtualization (SR-IOV)
Allows a physical network adapter to expose multiple Virtual Functions (VFs) directly to child virtual machines.
Network packets flow directly between the physical NIC hardware and the guest VM's memory via Direct Memory Access (DMA), bypassing the virtual switch CPU processing stack.