Fabric A Port-Channel Change: vNICs Survive, vHBAs Do Not

In end-host mode the fabric interconnect does not run STP on server-facing links; it pins each server adapter's MAC address to a specific uplink inside the port-channel. When a new member joins the port-channel, pinning is recalculated and some adapters move to the new link.

A vNIC needs only its server VLAN on that member. A vHBA needs strictly more:

• the FCoE VLAN allowed on the port-channel member it moved to,
• a vFC interface bound to the correct VSAN on that member,
• a no-drop / priority-flow-control class so FCoE frames are not dropped under contention,
• and membership in the correct FC uplink port-channel toward the SAN.

If the new 40 Gb link was added to a second port-channel, or to the existing one without the FCoE VLAN and the vFC binding, Ethernet keeps working and FLOGI/FDISC fails - exactly the observed split.

Check first:

1. show pinning server-interface and show pinning border-interface - did the vHBAs re-pin to the new link?
2. show fcoe and show flogi database on fabric A - do the eleven blades appear at all?
3. The new member's allowed VLAN list, PFC configuration, and show interface vfc binding versus a surviving member.

No - it is evidence that MPIO worked, which is not the same thing.

The blades lost their fabric A paths exactly like the other nine; the difference is that their application I/O is multipathed and failed over to fabric B without an interruption visible to the database. That leaves two problems:

• Redundancy is now zero on those two hosts. Every I/O is crossing a single fabric with a single HBA. Any fabric B event, ISL event, or array port flap is now a full outage rather than a path loss. That is a far more dangerous state than the eleven blades that failed loudly.
• Silent degradation may be present anyway. Check (multipath -ll, powermt display, or the array's own path state) for paths marked failed, for thrashing, and for queue-depth saturation on the surviving paths. RAC interconnect traffic that has to cross the surviving fabric adds latency that may show up as cluster wait events rather than errors.

During the window: treat the RAC blades as highest priority for restoration because they are the ones whose protection has been consumed, and do not perform any fabric B maintenance until fabric A paths are restored and verified end to end.

Restore, then gate.

Restoration:

1. Correct the new member: allow the FCoE VLAN, bind the vFC to the VSAN, apply the no-drop class, and confirm it is in the same uplink port-channel as the working members.
2. Verify logins at scale, not by sampling: show flogi database counts on fabric A should return to the pre-change number, and the eleven blades should show both vHBAs logged in.
3. Re-check array-side path state before releasing the window - a host that logged back in but is still in an error path state has not recovered.

Validation gate for future changes, applied to one chassis first:

• Before the change, capture the counts: number of FLOGI entries per fabric, number of pinned vHBAs per uplink.
• After the change, compare, do not just eyeball uplink status. End-host mode will happily show an uplink as up while a pinned vHBA behind it is dark.
• Diff the port-channel configuration against a known-good peer (VLAN list, PFC, vFC binding) as an automated pre-check.
• Only then roll to the remaining chassis, one at a time.

The reason this incident was expensive is that show interface reported the uplink healthy the whole time; the gate should assert on FLOGI counts, which reflect what the hosts can actually do.