Symptoms
Cause
The following conditions may contribute to this issue:
Note: In this example, VEM module is up and port-channel mac-pinning relative shows (4) 1GB vmnics (vmnic2, vmnic3, vmnic4, vmnic5) with no port-channels configured on upstream:
Note: In this example, VEM module is up and port-channel mac-pinning relative shows (4) 1GB vmnics (vmnic2, vmnic3, vmnic4, vmnic5) with no port-channels configured on upstream:
- All ports on upstream have the same configuration.
- vmnic2 is down.
- Node-id request is being sent only on vmnic2 which is down.
- Module will not attach when Host is rebooted or VEM is upgraded.
Resolution
This is a known issue affecting VMware ESX 4.1.x and ESXi 5.0.x
To workaround this issue, bring up vminc2, which is the lowest numbered vmnic on which the Node ID requests have been sent.
Examples of this issue:
Examples of this issue:
- VEM booted with vmnic1 down goes headless
Issue: If a VEM is rebooted with vmnic2 down, it goes headless upon bootup. If system is rebooted with vmnic0 down, it does not go headless.
Workaround: If vmnic1 cannot be brought up, manually remove vmnic1 from N1k with ESXi CLI.
# esxcfg-vswitch -Q vmnic1 n1k-name -V - VEM tries to pin traffic to a down vmnic
Issue: When link is shut from physical interface connected to the vmnic, or when vmnic is down due to hardware issue and VEM is running in ESXi 5.0.
Workaround: Restart VEM, causing a complete network outage for the virtual machines on ESX host infected, or remove the vmnic that is down due to the hardware issue. - N1k VEM PC does not form without VSM
Issue: VEM Port-Channel does not form, leading to N1k VEM not being able to restore connectivity at boot. Lower numbered vmnic down at boot time.
Workaround: Restore connectivity to port.
Based on VMware KB 2022024
