How to Configure Windows Server 2016 Hyper-V Discrete Device Assignment
Discrete Device Assignment (DDA) is a powerful Hyper-V feature in Windows Server 2016 that allows a physical PCIe device to be passed through directly to a virtual machine, bypassing the hypervisor for I/O operations. The guest VM communicates with the device hardware as if it were running on bare metal, using the device’s native drivers. This delivers near-native performance for high-throughput devices such as NVMe SSDs, graphics cards (GPU passthrough), network interface cards, and field-programmable gate arrays (FPGAs). This tutorial covers the requirements, the dismount process, VM configuration, and cleanup.
Use Cases for Discrete Device Assignment
DDA is primarily used in scenarios where a virtual machine needs to access a physical device at native speeds. GPU passthrough for machine learning workloads, scientific computation, or professional graphics applications is the most common use case. High-performance NVMe storage passthrough removes virtualisation overhead from latency-sensitive database workloads. Network I/O at wire speed using SR-IOV-capable NICs benefits high-frequency trading or network appliance VMs. FPGAs for real-time signal processing or hardware acceleration can be dedicated to specific VMs.
Requirements and Limitations
DDA requires a physical Hyper-V host running Windows Server 2016. The PCIe device must support message-signalled interrupts (MSI or MSI-X) and must not be in use by the host operating system while assigned to a VM. The host firmware must support PCIe ACS (Access Control Services) for proper device isolation. Only one VM can own a DDA device at a time. The VM must be Generation 2 or Generation 1; both are supported for DDA. When a device is assigned to a VM, it is unavailable to the host and all other VMs until it is reassigned.
Step 1: Identify the Target Device
On the Hyper-V host, use PowerShell to list all PCIe devices that are potentially eligible for DDA. The Get-PnpDevice and Get-VMHostAssignableDevice cmdlets are useful here:
Get-PnpDevice | Where-Object {$_.Class -eq "DiskDrive" -or $_.Class -eq "Display" -or $_.Class -eq "Net"} | Select-Object FriendlyName, InstanceId, Status
To see which devices are already assignable (have been prepared for DDA):
Get-VMHostAssignableDevice
Step 2: Verify ACS Support
Use the PCI location path to verify that Access Control Services is enabled on the PCIe hierarchy for the device. Microsoft provides a verification script in the DDA documentation. At a minimum, check your firmware (BIOS/UEFI) settings to ensure ACS is enabled for the PCIe slots you intend to use.
$locationPath = (Get-PnpDeviceProperty -InstanceId "PCIVEN_10DE&DEV_xxxx..." -KeyName DEVPKEY_Device_LocationPaths).Data[0]
Write-Host "Device Location Path: $locationPath"
Step 3: Dismount the Device from the Host
Before a PCIe device can be assigned to a VM, it must be dismounted from the host operating system. This removes the host’s access to the device and prepares it for passthrough. First, disable the device in the host:
Disable-PnpDevice -InstanceId "PCIVEN_10DE&DEV_xxxx..." -Confirm:$false
Then dismount it from the host partition using the Dismount-VMHostAssignableDevice cmdlet, supplying the location path you retrieved earlier:
Dismount-VMHostAssignableDevice -LocationPath "PCIROOT(0)#PCI(1C00)#PCI(0000)" -Force
Verify the device is now listed as an assignable device:
Get-VMHostAssignableDevice
Step 4: Configure the VM for DDA
Before assigning the device, the VM must be configured to allow automatic stops (for unmounting on VM shutdown) and to cache device write buffers on migration or shutdown:
Set-VM -Name "GPUWorkloadVM" -AutomaticStopAction TurnOff
Set the write-combining memory mapping size. For GPUs, a value of 128 MB or more is typical. This must match or exceed the device’s BAR (Base Address Register) memory requirements:
Set-VM -GuestControlledCacheTypes $true -VMName "GPUWorkloadVM"
Set-VM -LowMemoryMappedIoSpace 3GB -VMName "GPUWorkloadVM"
Set-VM -HighMemoryMappedIoSpace 33280MB -VMName "GPUWorkloadVM"
Step 5: Assign the Device to the VM
With the VM in a stopped state, assign the dismounted device using the Add-VMAssignableDevice cmdlet:
Add-VMAssignableDevice -LocationPath "PCIROOT(0)#PCI(1C00)#PCI(0000)" -VMName "GPUWorkloadVM"
Verify the assignment:
Get-VMAssignableDevice -VMName "GPUWorkloadVM"
Step 6: Start the VM and Install Device Drivers
Start the VM. The guest operating system will detect the newly assigned PCIe device through PnP enumeration. Install the appropriate vendor driver inside the guest VM as you would on a physical machine. For NVIDIA GPUs, install the standard NVIDIA WHQL driver inside the guest. For NVMe devices, Windows should recognise them natively with the built-in StorNVMe driver.
Start-VM -VMName "GPUWorkloadVM"
Step 7: Remove the Device Assignment and Remount on Host
When you need to release the device from the VM (for maintenance or reassignment), first shut down the VM, remove the device assignment, then remount it on the host:
Stop-VM -VMName "GPUWorkloadVM" -Force
Remove-VMAssignableDevice -LocationPath "PCIROOT(0)#PCI(1C00)#PCI(0000)" -VMName "GPUWorkloadVM"
Mount-VMHostAssignableDevice -LocationPath "PCIROOT(0)#PCI(1C00)#PCI(0000)"
Enable-PnpDevice -InstanceId "PCIVEN_10DE&DEV_xxxx..." -Confirm:$false
Limitations and Considerations
VMs with DDA devices cannot be live-migrated using Hyper-V Live Migration because the physical device must remain attached to its host. Use quick migration or plan maintenance windows accordingly. Save and restore operations may not work depending on the device. Checkpoints are not supported for VMs with DDA devices. Always check vendor compatibility before deploying DDA in production. Not all PCIe devices are certified or designed for virtualisation passthrough, and some devices have firmware assumptions about exclusive host access that can cause instability inside a VM.
DDA is a transformative feature for workloads that need raw hardware access inside a VM, eliminating the I/O bottlenecks of traditional device emulation and enabling high-performance computing, deep learning, and latency-sensitive applications to run inside a virtualised infrastructure without sacrificing performance.