Nutanix AHV Networking: Prism Virtual Switch and VLANs

AHV networking is Open vSwitch underneath a Prism Element UI, and Nutanix is unusually explicit about which parts of that stack customers may touch: do not modify OpenFlow tables, do not rename vs0, and do not remove the Controller VM from its bridge. What you do configure is the uplink bonding, the VLAN separation between CVM/hypervisor and guest traffic, and the virtual networks that VMs attach to. Getting the VLAN model right up front prevents the two classic failures: CVM traffic competing with guest broadcast traffic, and nodes that cannot rejoin the cluster after a switch change.

The Default Topology

• vs0 is the default virtual switch, backed by OVS bridge br0; it cannot be deleted or renamed.
• Uplinks are physical interfaces added to a bond (LACP or balance-slb) and then attached to vs0.
• The Controller VM and the AHV host sit on the same VLAN — by default VLAN 0, meaning untagged, matching the native VLAN of the connected switch port.
• Guest VMs should live on separate, tagged VLANs so their broadcast and multicast traffic never reaches the CVM network.

Configure Uplinks and Bonds in Prism

Prism Element -> Network -> Host -> Network Configuration
  1. Create the bond(s) from the physical interfaces (add all uplinks used for host traffic)
  2. Confirm the bond type: LACP if the switch port is a port-channel, balance-slb otherwise
  3. Attach the bond to the virtual switch vs0
  4. Set MTU (1500-9000 only; Prism rejects anything outside that range)

# CLI equivalent for verification
ovs-vsctl show
ovs-vsctl list port | grep -E "name|bond_mode|lacp"
ifconfig br0
manage_ovs --help

If LACP is configured on the switch but the bond is not LACP in AHV (or vice versa), the link stays up but throughput collapses to a single member — a failure that looks like a "slow node" until you check the bond mode on both ends.

Separate CVM, Host and Guest Traffic

# Prism: Network Configuration -> create a VLAN-backed network
Name: VLAN-101-APP
VLAN ID: 101
Virtual Switch: vs0
# then attach the network to VMs from the VM's Update pane

# verify a VM's NIC settings from the CLI
acli vm.get VMNAME | grep -i network
ovs-vsctl list port | grep 101
virsh dumpxml  | grep -A3 interface

Recommendations worth treating as rules: keep CVM and hypervisor host on one dedicated, protected VLAN that is never reachable from the internet; use tagged VLANs for all guest traffic and add those VLANs to every switch port that carries cluster host uplinks; and keep the number of guest VLANs on a host small to limit broadcast load.

MTU, Latency and Cluster Health

ncli host list
ncli cluster get-host-names
allssh "ping -M do -s 8972 "     # jumbo frame validation
nutanix_api_check /health
cluster status

Jumbo frames must be end-to-end consistent (switch port, bond, virtual switch and guest adapter). A single 1500-byte hop in the path silently fragments or drops large packets, which shows up as poor storage performance rather than an obvious network error. Validate with a large-payload ping before enabling jumbo MTU in production.

Change Management Notes

• Do not place nodes of the same cluster in a stretched L2 domain across a WAN; Nutanix explicitly warns against this for a stretched cluster design.
• Assign a tagged VLAN to CVM and hypervisor only during node provisioning, before adding the node to the cluster — changing it afterwards can isolate the node.
• Document uplink names and bond mode per node. After a switch replacement, an inconsistent bond configuration is the number one reason a node fails to rejoin.

Related reading: Proxmox VE VLAN-aware bridge with LACP bond and Linux VLAN tagging with ip link 802.1Q.

原文链接：https://portal.nutanix.com/page/documents/details?targetId=AHV-Admin-Guide-v11_2%3Aahv-acr-nw-best-practices-c.html