Windows Cluster Vlan issue in one server out of 5 node.

A likely cause is an inconsistent VLAN configuration on that one host rather than a VM or cluster-wide problem.

The strongest clues are:

1. Four nodes work with the same design.
2. One node fails on only one VLAN.
3. The network works when an IP is assigned directly to the adapter.
4. VM movement fails for workloads connected to that network.

That pattern points to a host-specific networking mismatch such as:

• The switchport or trunk on that server not advertising the same VLAN set as the other four hosts.
• A misconfigured or inconsistent VLAN on the host for the adapters participating in the same intent.
• A cluster network on that host not being available for the operation.
• Adapter binding/order issues on the affected node.

Use this troubleshooting path:

1. Verify cluster network availability on the affected host. Run PowerShell as administrator:

      Get-ClusterNetwork
      Get-ClusterNetworkInterface | ft NodeName, NetworkName, State
   

   Confirm the affected network is present and usable on the problem node. If the interface for that VLAN shows a failed or unavailable state, the cluster cannot use it for VM movement.
2. Check that cluster communication is allowed on that network. For the affected cluster network, make sure Allow cluster network communication on this network is enabled. If the cluster marks that network unavailable, live migration or VM movement can fail with "A cluster Network isn't available for this operation."
3. Compare VLAN consistency across all five hosts. The problem is likely that the switchports connected to the affected host are not advertising the same VLANs as the other nodes. Microsoft guidance for Network HUD calls out misconfigured or inconsistent VLANs as a cause of VM connectivity loss and storage isolation failure. The VLAN set must be consistent:
   • across adapters in the same host intent
   • across the same intent on all hosts in the cluster
   • for all workload VLANs required by the VMs
4. Validate the host network configuration. Run the Validate a Configuration Wizard in Failover Cluster Manager and review the Network section for warnings and errors. This helps identify whether the adapter is reachable, properly configured, and participating correctly in cluster communication.
5. Check adapter binding order on the affected node. On the problem server:
   • Open Start → Run → ncpa.cpl
   • Open Advanced Settings
   • Review Adapters and Bindings Network adapters used for client communication should be at the top of the binding order. Incorrect priority can affect outbound connectivity on multi-homed cluster nodes.
6. Confirm the same virtual switch exists on all nodes. For VM mobility, the VM must have the same virtual switch on all nodes. If the switch exists but the underlying VLAN path is different on one host, VMs attached to that VLAN can fail after migration.
7. If Network ATC is in use, check intent status.

      Get-NetIntentStatus
   

   This helps detect host-level inconsistencies. Microsoft documentation also notes that VLANs for storage and management can be explicitly set when creating intents, and inconsistent adapter presence or configuration is reported by status checks.

What the direct-IP test means: If assigning an IP directly to the adapter makes the network work, the physical path is likely functional. That shifts focus to the virtual switch/VLAN presentation on that host, or to cluster recognition of that network, rather than a total cable/NIC failure.

Most likely resolution:

• Make the VLAN configuration on the affected host match the other four hosts exactly.
• Verify the physical switchport/trunk for that server allows the same VLANs.
• Confirm the cluster network for that VLAN is available and enabled for cluster communication.
• Confirm adapter binding order and virtual switch consistency.

References:

• Troubleshoot live migration issues
• Troubleshoot cluster issue with Event ID 1135
• What is Network HUD for Windows Server?
• Manage Network ATC