In complex enterprise virtualisation topologies, multi-homed virtual machines frequently require several virtual network adapters attached to different virtual switches or isolated VLAN networks (such as Management, iSCSI Storage, Cluster Heartbeat, and Public DMZ). However, when a guest operating system boots, it identifies network interfaces based purely on PCI bus discovery order or assigned MAC addresses, assigning generic names like Ethernet 1, Ethernet 2, or eth0, eth1. Guest administrators cannot intuitively determine which virtual interface maps to which host vSwitch without manual MAC matching. Hyper-V in Windows 11 resolves this challenge through Consistent Device Naming (CDN), enabled via the DeviceNaming property in PowerShell. When active, Hyper-V injects host-defined adapter names directly into the guest operating system via ACPI data tables.
Understanding Consistent Device Naming Architecture
Hyper-V Consistent Device Naming provides an out-of-band metadata bridge between host hypervisor definitions and the guest kernel:
- ACPI _DSM Injection: Hyper-V injects the host-assigned virtual network adapter name into ACPI Device-Specific Method (_DSM) tables exposed to the guest VM.
- Windows Guest Integration: In Windows 10/11 and Windows Server guests, the Windows Plug-and-Play (PnP) subsystem reads the ACPI table and populates the
DeviceName/DriverDescriptionproperties, allowing automated network scripts to correlate adapters effortlessly. - Linux Guest Integration: In modern Linux guests (Ubuntu, Red Hat, Debian), systemd and
udev(viabiosdevnameornet.ifnames) read the ACPI data and automatically name the interface based on the host definition. - Generation Compatibility: Fully supported on Generation 2 UEFI virtual machines and modern Generation 1 virtual machines running Windows 11.
Auditing Existing Virtual Network Adapters on the Host
Before configuring consistent device naming, query the host hypervisor via PowerShell to inspect how network adapters are named on target virtual machines:
# Query all virtual network adapters on a specific VM
Get-VMNetworkAdapter -VMName "Cluster-Node-01" | Select-Object VMName, Name, SwitchName, MacAddress, DeviceNaming
Notice the DeviceNaming attribute. On standard Hyper-V virtual machines, DeviceNaming defaults to Disabled.
Naming Host Virtual Adapters and Enabling Device Naming
To implement consistent device naming effectively, first ensure that the virtual network adapters on the host carry clear, descriptive names representing their function:
# Rename default adapter to Management
Get-VMNetworkAdapter -VMName "Cluster-Node-01" -Name "Network Adapter" | Rename-VMNetworkAdapter -NewName "vNIC-Management"
# Add a secondary adapter for storage traffic
Add-VMNetworkAdapter -VMName "Cluster-Node-01" -Name "vNIC-iSCSI-Storage" -SwitchName "vSwitch-Storage"
# Add a third adapter for cluster heartbeat
Add-VMNetworkAdapter -VMName "Cluster-Node-01" -Name "vNIC-Cluster-Heartbeat" -SwitchName "vSwitch-Internal"
Next, enable Consistent Device Naming across all network interfaces attached to the virtual machine using Set-VMNetworkAdapter with -DeviceNaming Enabled:
# Enable Consistent Device Naming on all adapters of the target VM
Get-VMNetworkAdapter -VMName "Cluster-Node-01" | Set-VMNetworkAdapter -DeviceNaming Enabled
# Verify that DeviceNaming is now active
Get-VMNetworkAdapter -VMName "Cluster-Node-01" | Select-Object Name, SwitchName, DeviceNaming
Note: If the virtual machine is actively running, a restart of the guest operating system is recommended so the guest kernel can enumerate the updated ACPI device tables.
Verifying Device Naming Inside Windows Guest Operating Systems
Once enabled on the host, query the guest operating system via PowerShell Direct to confirm that the host adapter names are successfully exposed:
# Query network adapters inside the guest using PowerShell Direct
Invoke-Command -VMName "Cluster-Node-01" -ScriptBlock {
Get-NetAdapterAdvancedProperty | Where-Object { $_.DisplayName -like "*Device Name*" } | Select-Object DisplayValue, InterfaceDescription
}
Inside the Windows guest, you can automate renaming the internal network connections to match the host-defined names perfectly:
# Script to run inside Windows guest: Align internal interface names with host names
Invoke-Command -VMName "Cluster-Node-01" -ScriptBlock {
Get-NetAdapter | ForEach-Object {
$Nic = $_
$HostName = (Get-NetAdapterAdvancedProperty -Name $Nic.Name -DisplayName "*Device Name*" -ErrorAction SilentlyContinue).DisplayValue
if ($HostName) {
Write-Host "Renaming $($Nic.Name) to $HostName"
Rename-NetAdapter -Name $Nic.Name -NewName $HostName
}
}
}
After executing this script inside the guest, running Get-NetAdapter displays vNIC-Management, vNIC-iSCSI-Storage, and vNIC-Cluster-Heartbeat instead of ambiguous Ethernet 1 labels.
Verifying Device Naming Inside Linux Guest Operating Systems
In modern Linux distributions (such as Ubuntu 22.04 / 24.04 LTS), udev detects the ACPI device naming metadata automatically:
# Inside Linux guest: Inspect network interface udev properties
udevadm info /sys/class/net/eth0 | grep -i ID_NET_NAME
The output reports the host-assigned string under ID_NET_NAME_ONBOARD or ACPI device aliases, allowing custom netplan or systemd-networkd configurations to bind directly to host labels.
Bulk Enabling Device Naming Across Clusters
For large-scale virtualisation clusters, automate Consistent Device Naming across all virtual machines:
# Enable Device Naming across all registered virtual machines
Get-VM | Get-VMNetworkAdapter | Where-Object { $_.DeviceNaming -ne "Enabled" } | ForEach-Object {
Write-Host "Enabling Device Naming on VM '$($_.VMName)' Adapter '$($_.Name)'..."
Set-VMNetworkAdapter -VMNetworkAdapter $_ -DeviceNaming Enabled
}
Disabling Consistent Device Naming
If legacy guest operating systems experience ACPI enumeration conflicts during migration, disable the feature:
# Revert Device Naming back to disabled
Get-VMNetworkAdapter -VMName "Cluster-Node-01" | Set-VMNetworkAdapter -DeviceNaming Disabled
Configuring Hyper-V Consistent Device Naming in Windows 11 bridges the visibility gap between host hypervisors and guest environments, eliminating configuration errors and accelerating multi-NIC network automation.