Since the beginning, UCS has supported boot from SAN via FC or FCoE and that works great if you have that environment. But what if you don’t and you want to be completely stateless and boot ESXi from an iSCSI target on your SAN? Before UCS 2.0, you would be out of luck. Sure it’s not THAT big a deal—but if you want to squeeze every bit of benefit out of UCS—you really want to have everything offloaded but compute and memory. It makes it so much easier to upgrade, perform maintenance, provision new systems, and respond to outages. Now, with UCS 2.0, you are good to go.
Configuring disjoint Layer 2 networks—hmmm. Try to explain that one to your mom. Or try to explain to your customer why they can’t hook their servers or VMs into multiple disparate physical networks. You won’t have to anymore, as now each vNIC can be pinned to a specific uplink and each uplink to a specific network. In the case of one of our customers, their existing infrastructure was built with a separate backup network in order to keep that traffic off their core switch and limit the possibility of impacting performance on production systems. Our best option with UCS 1.4, was to route to the upstream core switch and push traffic to the backup network, essentially eliminating the benefit of the intended design. With UCS 2.0, that is no longer an issue. This feature is also great in multi-tenant environments too!
All in all, UCS 2.0 brings a lot to the table. Kudos to Cisco for continuing to grow an already great platform—and especially for not leaving early adopters out in the cold. UCS! UCS! UCS!