How to Configure Hyper-V Virtual Networking on Windows Server 2025

How to Configure Hyper-V Virtual Networking on Windows Server 2025

Virtual networking is one of the most critical — and often most complex — aspects of a Hyper-V deployment. Getting it right determines whether your virtual machines can communicate with each other, reach the corporate network, access the internet, and talk to storage systems. Windows Server 2025 builds on the Hyper-V Extensible Switch architecture introduced in earlier releases, adding improved performance, enhanced security, and tighter integration with Software Defined Networking (SDN). This tutorial covers every major virtual networking concept: switch types, VLAN tagging, bandwidth management, NIC teaming, SR-IOV, and the Hyper-V extensible switch extension model.

Prerequisites

• Windows Server 2025 with Hyper-V role installed
• One or more physical network adapters — use Get-NetAdapter to list them
• Administrator privileges on the Hyper-V host
• Basic understanding of VLANs and TCP/IP networking
• For SR-IOV: a physical NIC with SR-IOV support and a chipset/BIOS with SR-IOV enabled
• For NIC Teaming: two or more physical NICs connected to the same physical switch or different switches with LACP/802.3ad support

Step 1: Understand the Three Virtual Switch Types

Before creating any virtual switch, choose the type that matches your network topology:

• External: Bound to one or more physical NICs. VMs can communicate with each other, with the Hyper-V host, and with the wider network (internet, corporate LAN). This is the most common type for production workloads.
• Internal: Not bound to any physical NIC. VMs can communicate with each other and with the Hyper-V host OS, but they cannot reach external networks directly. Useful for lab environments where you want host-to-VM connectivity without exposing VMs to the LAN.
• Private: Completely isolated. VMs on the switch can only communicate with other VMs on the same private switch — the host OS is excluded entirely. Ideal for multi-tier application testing where you want a completely isolated network segment.

# View existing virtual switches
Get-VMSwitch | Select-Object Name, SwitchType, NetAdapterInterfaceDescription, AllowManagementOS

# View the physical adapters available to bind an external switch to
Get-NetAdapter | Where-Object { $_.Status -eq "Up" } | Select-Object Name, InterfaceDescription, LinkSpeed, MacAddress

Step 2: Create Virtual Switches

# External switch — binds to a physical NIC and allows full network access
# -AllowManagementOS $true creates a virtual NIC on the host so it retains LAN connectivity
New-VMSwitch -Name "vSwitch-External-Prod" `
             -NetAdapterName "Ethernet 1" `
             -AllowManagementOS $true `
             -Notes "Production external switch bound to 10GbE port"

# External switch without host OS access (VMs only — the host uses a separate NIC)
New-VMSwitch -Name "vSwitch-External-VMs" `
             -NetAdapterName "Ethernet 2" `
             -AllowManagementOS $false

# Internal switch for host-to-VM lab communication
New-VMSwitch -Name "vSwitch-Internal-Lab" -SwitchType Internal

# Private switch for isolated VM clusters
New-VMSwitch -Name "vSwitch-Private-Cluster" -SwitchType Private

# Confirm switches were created
Get-VMSwitch | Format-Table Name, SwitchType, AllowManagementOS -AutoSize

Step 3: Add and Connect VM Network Adapters

Each VM can have multiple virtual NICs, each connected to a different virtual switch. This is the standard way to segregate traffic — for example, one NIC on the production LAN switch and another on a private storage switch.

# Add a network adapter to a VM (VM can be running or off)
Add-VMNetworkAdapter -VMName "APPSRV01" `
                     -Name "Production-NIC" `
                     -SwitchName "vSwitch-External-Prod"

# Add a second NIC for isolated storage traffic
Add-VMNetworkAdapter -VMName "APPSRV01" `
                     -Name "Storage-NIC" `
                     -SwitchName "vSwitch-Private-Cluster"

# Connect an existing (disconnected) network adapter to a switch
Connect-VMNetworkAdapter -VMName "APPSRV01" `
                         -Name "Storage-NIC" `
                         -SwitchName "vSwitch-Private-Cluster"

# Disconnect a NIC from its switch (NIC stays attached to VM but loses connectivity)
Disconnect-VMNetworkAdapter -VMName "APPSRV01" -Name "Storage-NIC"

# List all network adapters for a VM with their switch connections
Get-VMNetworkAdapter -VMName "APPSRV01" | Select-Object Name, SwitchName, MacAddress, Status, IPAddresses

Step 4: Configure NIC Teaming on the Hyper-V Host

NIC Teaming (LBFO — Load Balancing and Failover) lets you bind an external virtual switch to a team of physical NICs rather than a single adapter. This provides both bandwidth aggregation and failover redundancy. The team presents a single logical adapter to Hyper-V.

# Create a NIC team using two physical adapters (requires both NICs to be up and unbound)
New-NetLbfoTeam -Name "HV-Production-Team" `
                -TeamMembers "Ethernet 1", "Ethernet 2" `
                -TeamingMode SwitchIndependent `
                -LoadBalancingAlgorithm Dynamic

# Verify the team is active before binding to it
Get-NetLbfoTeam -Name "HV-Production-Team" | Select-Object Name, Status, TeamingMode, LoadBalancingAlgorithm
Get-NetLbfoTeamMember -Team "HV-Production-Team" | Select-Object Name, OperationalStatus, TransmitLinkSpeed

# Create an external virtual switch bound to the NIC team
New-VMSwitch -Name "vSwitch-External-Teamed" `
             -NetAdapterName "HV-Production-Team" `
             -AllowManagementOS $true

# On Windows Server 2025, SET (Switch Embedded Teaming) is preferred over LBFO for Hyper-V
# SET combines teaming and virtual switching — create a switch with multiple adapters directly
New-VMSwitch -Name "vSwitch-SET-Prod" `
             -NetAdapterName "Ethernet 1", "Ethernet 2" `
             -EnableEmbeddedTeaming $true `
             -AllowManagementOS $true

Switch Embedded Teaming (SET) is the recommended approach for Hyper-V on Windows Server 2025. Unlike LBFO, SET integrates directly with the Hyper-V vSwitch and supports RDMA (Remote Direct Memory Access) on team members, which is critical for SMB Direct and high-performance storage traffic.

Step 5: Configure VLAN Tagging

VLAN tagging allows a single VM NIC to be isolated into a specific VLAN, just as a physical NIC would be. The Hyper-V host adds or strips the 802.1Q tag transparently so the guest OS does not need to be VLAN-aware.

# Assign a VM's NIC to VLAN 100 (Access mode — the NIC sees only VLAN 100 traffic)
Set-VMNetworkAdapterVlan -VMName "WEBSRV01" `
                         -VMNetworkAdapterName "Production-NIC" `
                         -Access `
                         -VlanId 100

# Configure trunk mode — the VM NIC sees tagged traffic on specified VLANs
# Use this when the guest OS manages VLANs itself (e.g., for a virtual firewall or router VM)
Set-VMNetworkAdapterVlan -VMName "FW-VM01" `
                         -VMNetworkAdapterName "WAN-NIC" `
                         -Trunk `
                         -NativeVlanId 0 `
                         -AllowedVlanIdList "10,20,30,100-110"

# Set VLAN on the management OS virtual NIC (the host's own vNIC on an external switch)
Set-VMNetworkAdapterVlan -ManagementOS `
                         -VMNetworkAdapterName "vSwitch-External-Prod" `
                         -Access `
                         -VlanId 10

# Check VLAN configuration for all NICs on a VM
Get-VMNetworkAdapterVlan -VMName "WEBSRV01" | Format-Table VMName, VMNetworkAdapterName, OperationMode, AccessVlanId

Step 6: Configure VM Bandwidth Management

Bandwidth management prevents a single VM from monopolising network bandwidth on a shared external switch. You can set minimum and maximum bandwidth guarantees per virtual NIC.

# Set minimum bandwidth (guaranteed) and maximum bandwidth (cap) per NIC
# Values are in bits per second — 100MB/s = 800,000,000 bps
Set-VMNetworkAdapter -VMName "WEBSRV01" `
                     -Name "Production-NIC" `
                     -MinimumBandwidthAbsolute 100000000 `
                     -MaximumBandwidth 1000000000

# Use weight-based bandwidth allocation (relative priority 0-100; 0 disables)
# This requires -MinimumBandwidthMode Weight on the switch
Set-VMSwitch -Name "vSwitch-External-Prod" -DefaultFlowMinimumBandwidthWeight 50
Set-VMNetworkAdapter -VMName "WEBSRV01" -Name "Production-NIC" -MinimumBandwidthWeight 40
Set-VMNetworkAdapter -VMName "DBSRV01"  -Name "Production-NIC" -MinimumBandwidthWeight 80

# Check bandwidth settings
Get-VMNetworkAdapter -VMName "WEBSRV01" | Select-Object Name, BandwidthSetting

Step 7: Enable SR-IOV for High-Performance Networking

Single Root I/O Virtualisation (SR-IOV) allows a physical NIC to present multiple Virtual Functions (VFs) directly to VM guest operating systems, bypassing the Hyper-V vSwitch entirely. This eliminates hypervisor overhead for network-intensive workloads and can deliver near-wire-speed performance with very low CPU utilisation.

# Verify that the physical NIC supports SR-IOV
Get-NetAdapterSriov | Select-Object Name, Enabled, VFsAvailable, SriovSupport

# Enable SR-IOV on the external virtual switch (must be done at switch creation time)
New-VMSwitch -Name "vSwitch-SRIOV" `
             -NetAdapterName "Ethernet 1" `
             -EnableIov $true `
             -AllowManagementOS $true

# Enable SR-IOV on a VM's network adapter
Set-VMNetworkAdapter -VMName "HPCVM01" -Name "Production-NIC" -IovWeight 100

# Verify SR-IOV VF assignment after VM starts
Get-VMNetworkAdapter -VMName "HPCVM01" | Select-Object Name, IovWeight, IovVirtualFunctionNumber

SR-IOV has important limitations: VMs using SR-IOV cannot be live-migrated to a host that lacks identical SR-IOV hardware, and VM checkpoints are not supported while an SR-IOV VF is assigned. Always evaluate whether the performance benefit outweighs the operational constraints for your workload.

Step 8: Configure Network Adapters for Guest Clustering

Windows Server Failover Clustering (WSFC) inside VMs requires dedicated network adapters for the cluster heartbeat and, optionally, iSCSI storage traffic. Use private or internal switches for the heartbeat network to isolate it from production traffic.

# Add a heartbeat NIC on the private cluster switch for each cluster node VM
$clusterVMs = @("CLNODE01", "CLNODE02")
foreach ($vm in $clusterVMs) {
    Add-VMNetworkAdapter -VMName $vm `
                         -Name "Cluster-Heartbeat" `
                         -SwitchName "vSwitch-Private-Cluster" `
                         -DeviceNaming On
    Set-VMNetworkAdapterVlan -VMName $vm `
                             -VMNetworkAdapterName "Cluster-Heartbeat" `
                             -Access `
                             -VlanId 200
}

# Enable MAC address spoofing — required for clustered VMs that use floating IP addresses
Set-VMNetworkAdapter -VMName "CLNODE01" -Name "Production-NIC" -MacAddressSpoofing On
Set-VMNetworkAdapter -VMName "CLNODE02" -Name "Production-NIC" -MacAddressSpoofing On

The Hyper-V Extensible Switch

The Hyper-V Extensible Switch is a software-defined networking framework that allows third-party vendors to insert forwarding, filtering, and monitoring extensions into the virtual switch data path. Extensions are installed as Windows drivers and managed through PowerShell:

# List all extensions installed on the system
Get-VMSwitchExtension | Select-Object Name, Vendor, Version, Enabled, Running

# List extensions on a specific switch
Get-VMSwitchExtension -VMSwitchName "vSwitch-External-Prod" | Format-Table Name, Enabled, Running

# Enable a specific extension on a switch
Enable-VMSwitchExtension -Name "Microsoft Windows Filtering Platform" `
                          -VMSwitchName "vSwitch-External-Prod"

# Disable an extension
Disable-VMSwitchExtension -Name "ThirdPartyExtensionName" `
                           -VMSwitchName "vSwitch-External-Prod"

Microsoft ships built-in extensions including the Windows Filtering Platform (WFP) capture extension for packet tracing. Third-party vendors (such as network security vendors) provide monitoring and enforcement extensions that integrate with network access control systems.

Conclusion

Virtual networking in Hyper-V on Windows Server 2025 is both flexible and powerful. In this tutorial you created External, Internal, and Private virtual switches, configured NIC teaming with both LBFO and the preferred Switch Embedded Teaming approach, applied VLAN tagging in both access and trunk modes, enforced bandwidth policies to protect shared infrastructure, enabled SR-IOV for high-performance workloads, and configured network adapters for guest failover clustering. Understanding these building blocks gives you the control you need to design Hyper-V networks that match your organisation’s security zones, performance requirements, and management model. The next article in this series covers Live Migration — enabling you to move running VMs between hosts with zero downtime.