For months now HP had to tolerate the coverage that press, blogs, forum and newsgroups dedicated to the Unified Computing System (UCS) that Cisco officially launched in March.
Even virtualization.info, which never considered the blade technology as strongly related to virtualization, has closely followed the UCS announcements, believing to see a new paradigm of integration between a virtual infrastructure (VMware vSphere in this case) and the physical layer below it (but this is something that Cisco still has to demonstrate).
Cisco just entered the x86 server market, and while it already appears in a very strong position thanks to its partnership with VMware and EMC, it still is a newcomer,
No customers would easily jump on the new bandwagon without a careful evaluation of the Cisco strategy, capability to execute, technology value and ROI.
But the word is that the network giant has closed a deal with VMware to replace HP as the server provider at the upcoming VMworld 2009. And there more than 10,000 potential customers will see the UCS in action there.
Additionally, the way VMware is pushing the Cisco Nexus 1000V virtual switch inside its new vSphere Enterprise Plus packaging may drive many customers away from the HP ProCurve networking equipment over the long term.
So HP must be feeling the pressure if decided to dedicate the July issue of its The Real Story newsletter to UCS, criticizing the Cisco blade system on many fronts.
The content of the message is relevant to the virtualization.info audience as it includes criticism about the virtualization aspect of UCS:
…Before considering a giant switch to a giant switch vendor please consider the following issues:
When a customer adds the Cisco Nexus 1000v for VMware vSphere 4 Enterprise Plus with 24×7- 3 year support it adds an additional $1138.70 per processor. This extra cost adds up fast, considering that a rack of 48 two-processor servers would cost an additional $109,315.20 just for the Nexus 1000v software.
it appears that traffic even between two virtual servers running next to each other on the same physical would have to traverse the network, making an elaborate “hairpin turn” within the physical switch, only to traverse the network again before reaching the other virtual server on the same physical machine. Return traffic (or a “response” from the second virtual machine) would have to do the same. Each of these packet traversals logically accounts for multiple interrupts, data copies and delays for your multi-core processor.
Cisco has defined a new proprietary frame protocol; VNTag, for UCS’s Network Interface Virtualization model such that an attached physical switch, according to Cisco, cannot be connected to just any IEEE 802.1D compliant Ethernet switch.
Another example: If a customer wants to connect an existing blade environment, such as an HP BladeSystem with a Cisco 3120 switch integrated in it, a Nexus 1000v soft switch would be unable to pass a VN-Tag to an upstream Nexus 5000 switch. In other words, Cisco’s VN-Tag approach doesn’t even work with their own switches!…
The other non-virtualization-related issues described in the message are important as well, and well worth a deeper analysis of the HP claims.