Windows Server 2016 TP3 Hyper-V includes a very interesting feature that got several names out there vCDN, Consistent Naming of Virtual Network Adapters and Virtual Adapter Identification. Only the last two are a good wording for it, because it is not Consistent Device Naming.
In this blog post I use the following wording vNIC Consistent Naming regarding to the TechNet Library description and will show you the benefit of this feature.
-> https://technet.microsoft.com/en-us/library/dn705350.aspx#BKMK_networking
First of all you can use the feature even without VMM. All you need is the Hyper-V Manager, but I’m going to show you it in VMM.
When you deploy a VM with VMM you get three options for the so called device properties in the settings of each vNIC.
| Device property | Description |
| Do not set adapter name | Nothing happens |
| Set adapter name to name of VM network | The vNIC Consistent Naming property will have the same name as the connected VM network. |
| Set custom adapter name | The vNIC Consistent Naming property will have the name you specify. |
In this example I have chosen the second option. After the successful VM deployment log in into the VM and start the PowerShell console. Type in Get-NetAdapterAdvancedProperty and execute the PowerShell cmdlet.
As you can see the yellow marked row represents our vNIC Consistent Naming property. You may also have recognized that the vNIC name is Ethernet as it is always in Windows. You see it is not Consistent Device Naming, because CDN affects the vNIC name and that is not the case with vNIC Consistent Naming.
Why you should use vNIC Consistent Naming for your deployments? Imagine you have a VM with more than one vNIC. If you are depending on post deployment scripts that are responsible for the vNIC configuration, then the vNIC Consistent Naming is a huge time saver. Because you can easily identify which vNIC is used for their appropriate purpose and configure it.
Have a look at the next screenshot as an example. I’m using the following PowerShell cmdlets to isolate the advanced vNIC property and the next one takes it to the level where you get the corresponding vNIC through the advanced vNIC property.
Get-NetAdapterAdvancedProperty|Where-Object {$_.DisplayValue –eq “Management”}
Get-NetAdapterAdvancedProperty|Where-Object {$_.DisplayValue –eq “Management”}|Get-Netadapter
If you want to know which device properties setting the VM is using, you can use this small PowerShell script.
$VM=Get-SCVirtualMachine -Name “NC-01.neumanndaniel.local”
$vNIC=Get-SCVirtualNetworkAdapter -VM $VM[0]
$vNIC.DevicePropertiesAdapterNameMode
$vNIC.DevicePropertiesAdapterName
The next idea that will truly pops up will be to change the device properties setting. But that will end up in an error message.
Set-SCVirtualNetworkAdapter -DevicePropertiesAdapterNameMode Custom -DevicePropertiesAdapterName “NetworkController” -VirtualNetworkAdapter $vNIC
Set-SCVirtualNetworkAdapter : Cannot configure the DevicePropertiesAdapterNameMode of the virtual network adapter ‘NC-01.neumanndaniel.local’
because it is not a valid synthetic virtual network adapter of a Generation 2 VM Template or Hardware Profile. (Error ID: 50098)Provide a valid synthetic virtual network adapter of a Generation 2 VM Template or Hardware Profile.
Currently the VMM cmdlet does not support it and I have not tested it yet if it is possible with the Hyper-V Manager.
Be aware of that you can only specify the device properties during the VM deployment progress. When you are creating your VM template you cannot set the device property through the UI.
You have to use PowerShell instead, because you do not want to decide or remember every time you deploy a VM to set the device properties.
$VMTemplate=Get-SCVMTemplate -Name “Network Controller”
$vNIC=Get-SCVirtualNetworkAdapter -VMTemplate $VMTemplate
Set-SCVirtualNetworkAdapter -DevicePropertiesAdapterNameMode Custom -DevicePropertiesAdapterName “Southbound” -VirtualNetworkAdapter $vNIC
When you start the VM deployment process again the device properties are now set!
I totally recommend to use this feature every time you deploy a VM with more than one vNIC. Especially when you are deploying NVGRE gateways in a SDN scenario.