Hi Tony,
The VEMs are able to switch traffic while both VSMs are powered off and will switch traffic based on their last known configuration. However, if you try to change the port group the VM is assigned to while the VM lives on a headless VEM, the VM will no longer have network connectivity as the VSM is not able to reach the VEM to program that port. If you reboot a host that is headless, the VEM will only be able to communicate on System VLANs when it comes back up, as these VLANs are pushed from the vCenter and not programmed by the VSM. You could confirm if a VEM is headless by running the command 'vemcmd show card' on the VEM (from host CLI).
During this headless state we have some limitations, as the VSM is not able to communicate with the VEMs. Any operations that require the VSM to program the VEM can not be done in headless mode. Here are some operations that can't be performed without VSM interaction:
•No new ports can be brought up on the headless VEM (new VMs coming up or VMs coming up after vMotion).
•No NetFlow data exports.
•Ports shut down because DHCPS/DAI rate limits are not automatically brought up until the VSM reconnects.
•Port security options, such as aging or learning secure MAC addresses and shutting down/recovering from port-security violations, are not available until the VSM reconnects.
•The Cisco Discovery Protocol (CDP) does not function for the disconnected VEM.
•IGMP joins/leaves are not processed until the VSM reconnects.
•Queries on BRIDGE and IF-MIB processed at the VSM give the last known status for the hosts in headless mode.
(source)
If you are familiar with traditional modular switches, the supervisor programs the line cards. Nexus 1000v is the same, only the line cards (VEMs) are able to retain the last known configuration while the VSM is unreachable.
HTH,
Joe
