For RoCEv2, the most direct validation path is to confirm whether RDMA is operational but DCB is not, then correct the host-side DCB configuration and any VLAN settings that prevent PFC from working.
- Check whether the host is reporting RDMA without DCB
- If RDMA is working but PFC/ETS are not active, that indicates Data Center Bridging is not active on the Windows hosts.
- Windows does not automatically enable PFC/ETS just because switch QoS/DCBX is configured. The host must have the Data-Center-Bridging feature installed and QoS policies defined for the OS to negotiate and enforce DCB.
- Validate for known host-side RDMA blockers
In Network ATC environments, check for these conditions:
- RDMANotOperational can occur if the NIC is using an inbox driver.
- Resolution: update the adapter driver.
- RDMANotOperational can also occur if SR-IOV is disabled in BIOS.
- Resolution: enable SR-IOV in BIOS.
- RDMANotOperational can also occur if RDMA is disabled in BIOS.
- Resolution: enable RDMA in BIOS.
- Validate the RoCE VLAN configuration
- For RoCE RDMA, a nonzero VLAN is required so that PFC markings can be added to the frame.
- A valid VLAN must be in the range 1 - 4094.
- If VLAN 0 or another invalid override is being used, Network ATC reports InvalidIsolationID.
- If supported by the adapter, switching to iWARP avoids the RoCE nonzero-VLAN requirement, but for RoCEv2 the fix is to use a valid VLAN.
- Clear conflicting QoS/DCB policy on the host if already preconfigured
If the host already has traffic classes or QoS policies that conflict with the intended DCB configuration, Network ATC can report ConflictingTrafficClass. Clear the existing DCB configuration, then retry:
Get-NetQosTrafficClass | Remove-NetQosTrafficClass
Get-NetQosPolicy | Remove-NetQosPolicy -Confirm:$false
Get-NetQosFlowControl | Disable-NetQosFlowControl
Risk: this removes existing QoS/DCB policy from the host. Apply only during a controlled maintenance window.
- Reapply the intended DCB configuration and retry intent deployment
- After removing conflicting policy, run Set-NetIntentRetryState if Network ATC is managing the configuration.
- If the environment is not using Network ATC, the key requirement remains the same: install Data-Center-Bridging and define the required QoS policies so the host can participate in DCB/PFC.
- Validate the physical switch alignment
- For Azure Local switched and disaggregated deployments, top-of-rack switches must support Priority Flow Control (PFC) for lossless RDMA traffic.
- Also ensure the switch port MTU matches the host-side jumbo frame design. Azure Local applies the host MTU during deployment, but physical switches must be configured separately. A common pairing is MTU 9000 on the host and 9216 on the switch.
- Check live migration transport ports during failure analysis
For live migration timeout scenarios, verify clustering-related ports are listening on both source and destination:
netstat -ano | findstr /I /C:"6600"
Also verify TCP ports 6600 and 3343 are listening on both sides.
- If the issue persists, collect traces from both nodes
- Run TSS rOn VML:verbose on both source and destination nodes.
- Reproduce the live migration failure.
- Then collect logs with:
.\GetpsSDP.ps1 HyperV -localNodeOnly
For the scenario described, the most likely alignment checks are:
- host has RDMA enabled but not Data-Center-Bridging
- RoCE VLAN is invalid or zero
- existing host QoS/DCB policy conflicts with the intended configuration
- switch supports PFC, but host-side DCB/PFC negotiation is not actually enabled
- MTU is inconsistent between host and switch
References: