Here is an old post I never finished. With the benefits of the Nexus 2000 and the FEX architecture (a earlier post), scalability, simplified management, flexibility, Cisco extended its use further into the servers all the way up to the virtual hosts.This allows much greater control and flexibility. After all network guys should look after all aspects of networking, server guys should look after the servers and today virtual hosts.
A summary of the different FEX implementations:
- Rack FEX – Consists of a Nexus 2000 series devices typically installed in a TOR (top of rack) fashion, inside the cabinet which connects to a parent N5K (or N7K). The physical servers appear to be directly connected to the N5K.
- Chassis FEX – Consist of a special form-factor FEX unit that lives inside a blade chassis system. Examples would include the B22 HP FEX, B22 Fujitsu FEX, and the Cisco UCS 2100 FEX (a.k.a. IO-Module). The FEX functionality is very similar to the Nexus 2000 FEX.
- Adapter FEX – Consists of a hardware adapter in either the Cisco UCS C-series or B-series chassis that virtualizes a physical NIC offering multiple (up to 128) vNICs/vHBAs to the operating system. The switch fabric is extended up to the server, allowing the vNICs/vHBAs to appear locally connected on the parent N5K
- VM-FEX – Is an extension of adapter FEX, whereby the control plane is extended from the UCS Manager to VMware vCenter. This extends the switch fabric up to the VM host. Each VM host is assigned an individual dynamic vNIC, which allows each VM to have its own logical switch port on the upstream parent N5K
For more reading refer to the following links:
Routing-Bits 
Don’t forget the neglected Nexus 4001i module for IBM BladeCenter H chassis that would fit in the Chassis FEX category. Supports the 14 blades and has 6 uplinks.
Unfortunately Cisco is lazy and hasn’t released NXOS 5 for it yet.
Nexus 4000 is not a fex, but a switch. And yes, it’s neglected, virtually dead!