More technical details about Cisco Unified Computing System emerge

cisco logo

At the beginning of this week Cisco finally announced its long awaited blade system once known as California.

The company unveiled an impressive list of partners (VMware, EMC and BMC are the key ones) that will provide the building blocks of this new platform called Unified Computing System (UCS), and provided some scarce information about some of its hardware components. But it didn’t unveil anything about the most important part of the system: its control center, the UCS Manager, that will have to integrate everything in a seamless way.

Anyway in the last three days a lot of information about the platform were leaked.

Scott Lowe summarizes some of them in his last post:

…there are three different CNA families targeted at different markets: high-performance Ethernet, compatibility with existing driver stacks, and virtualization.

[the virtualization CNA] will utilize SR-IOV (Single Root I/O Virtualization), a PCI SIG standard for allowing a physical network adapter to present multiple virtual adapters to upper-level software, in this case the hypervisor. This eliminates the need for the hypervisor to manage the physical network adapter and allows VMs to attach directly to one of the SR-IOV virtual adapters.

It will utilize Intel I/O Acceleration Technology (Intel I/OAT) to minimize bottlenecks in the hardware and allow the server to better cope with massive dataflows like those generated by 10GbE adapters.

It will use Intel Virtual Machine Device Queues (VMDq) to improve traffic management within the server and decrease the processing burden on the VMM, i.e., the hypervisor…

Chad Sakac, Vice President of VMware Technology Alliance at EMC, adds more details on his personal blog:

…[The Cisco] VN-Link can apply tags to ethernet frames –  and is something Cisco and VMware submitted together to the IEEE to be added to the ethernet standards.

It allows ethernet frames to be tagged with additional information (VN tags) that mean that the need for a vSwitch is eliminated.   the vSwitch is required by definition as you have all these virtual adapters with virtual MAC addresses, and they have to leave the vSphere host on one (or at most a much smaller number) of ports/MACs.   But, if you could somehow stretch that out to a physical switch, that would mean that the switch now has “awareness” of the VM’s attributes in network land – virtual adapters, ports and MAC addresses.   The physical world is adapting to and gaining awareness of the virtual world…

More to come.