7.3 Compute, Dynamic Memory & Hardware Acceleration

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) | |
|   +---------------------------------------+       +-----------------------------------+ |
+-----------------------------------------------------------------------------------------+

:: 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

1. 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).
2. VM Generation: Generation 2 VM (recommended) with VM Configuration Version 8.0 or higher.
3. 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%). $\text{Buffer RAM} = \text{Committed Memory} \times \left(\frac{\text{Buffer Percentage}}{100}\right)$
• 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:

1. The virtual machine is being restarted (not started from a stopped/powered-off state).
2. There is no available physical host RAM to fulfill the difference between Minimum RAM and Startup RAM.
3. 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.