A regional hospital vNIC goes down when its only uplink fails, even though the other fabric interconnect uplinks stay up. The LAN pin group on that vNIC contains only the failed port. Why does the vNIC stay down?
Select an answer to reveal the explanation.
Short Explanation
The truck was assigned to one gate, and that gate closed while the other gates stayed open. You left the vNIC down because its LAN pin group has no remaining uplink to move to. Firmware, boot order, and the best-effort class do not take an Ethernet vNIC down just because one uplink failed.
Full Explanation
A LAN pin group statically limits which uplinks a vNIC may use. If the uplink in that group fails and the group has no other member, UCS has nowhere to repin the vNIC, so the vNIC stays down even though other uplinks on the fabric interconnect are healthy. That is the hospital's failure. A host firmware package selects server images and reboots a server only under the maintenance policy. It does not shut every vNIC because one uplink flapped. The boot policy orders boot devices such as local disk or a SAN target. A missing SAN target can affect boot, and it does not own Ethernet pinning or bring a vNIC down when an uplink fails. QoS system classes decide how traffic is queued during congestion. Best effort does not administratively shut a vNIC when a pinned port leaves the up state. Caveat: adding another uplink to the same pin group restores a place to repin, while removing the pin group lets the interconnect pin dynamically, and those are different operations. Operational check: confirm the vNIC is bound to the one-member pin group, add a live uplink to that group or clear the static pin, and confirm the vNIC recovers without a server reboot.