Just wanted to add some clarification for this point

>>>
However, a change to one of those service profiles will not affect any of the other service profiles cloned from the same template.
>>>

UCS has two variants of Service Profile Templates

1) Initial Template
2) Updating Template

If a service profile is created from a “initial template”, it will get all the properties from template, but remain detached from the template i.e any later changes to the template are not applied to the service profile

However, if the service profile is created from a “updating template”, it will get all the properties from the template, and remain attached to the template. Any later changes to the template will apply to all the service-profiles that used this template as “updating template”

Disclosure: Cisco employee

Cisco knew from the beginning that being all things to all people with regard to management is an inherently un-winable prospect. UCS includes a comprehensive and open XML API to facilitate the development and integration of 3rd-party tools. Anything you can do in the UCS Manager can also be done via XML API.

http://www.cisco.com/en/US/products/ps10281/products_programming_reference_guides_list.html

BMC’s has been working with Cisco since the early days of UCS, and Blade Logic for UCS provides automation, OS provisioning, App provisioning and patch management. My description of Blade Logic’s capabilities is a very short sampling of what it can do.

There is no need to wait ’1-2′ years for an enterprise-scalable solution. You can order it today.

I’d really like to hear some more detail on your experience around how service profiles work. Some of this may be redundant from other postings, but I had so many questions that I figured I would throw them all out there.

From what I gather there is exactly one service profile per blade (similar to HP VC). In addition to the MAC and LAN information, does the profile also include the WWNs (or are those handled differently?), and firmware images or something like that? Are the WWNs part of the profile regardless of the mezzanine card? Seems that with Menlo and Palo there would be different profile capabilities in that regard.
Is the firmware image part of the service profile? How does option specific firmware get installed on the blade? What I am trying to understand is how the firmware update mentioned earlier is part of the service profile, and how it gets applied.
In the case of different blades and different I/O adapters, does there have to be a service profile template for each hardware combination? What if a specific set of blades require a different firmware level than others? Can UCS manager handle multiple templates with different firmware versions?
When firmware needs to be updated for a bunch of blades all at once, does each service profile need to be modified or is there a “one button” upgrade? This is all very intriguing concept, don’t want to assume how anything really works without hearing from a subject matter expert.

As a consumer of Egenera, HP, and Cisco compute platforms let me just say that no one other than Egenera in my opinion is an innovator of these technologies. That said when I read a blog entry by Pete Manca of Egenera about the launch of the Cisco UCS, and saw the same type of conversation occuring I had to comment. Pete had to post some snarky comments abotu how Egenera did this first and for many years. Well at the end of the day it does not matter who does it first but about who does it best.

Bottom line is that many companies will be developing products with features that solve the same pain points for the customer. While they may do it nearly the same, the result is intended to be identical; the mitigation of the pain point. Now some companies will do this better than others as is the case here. The example of the service profiles and HP having done this for 2 years just really does not do complete justice to Cisco and the service profiles.

The fact is this, in many ways the Cisco UCS service profiles and how they work are more comprehensive and less complex than HP stateless operation. Brad’s comment about the firmware is huge and HP really falls flat by that single comparison. The only thing I have seen close to Cisco UCS and service profiles is the Egenera pServer model, which even falls short to some degree when compared to Cisco’s solution. The quality of the Cisco UCS for a 1.0 product I think speaks volumes, as they are coming late into an arena dominated by giants like HP and IBM, and from what I have seen it is a very legitimate product able to compete against the HP C-class which has become the defacto standard for blade servers.

While it has it warts, I for one think the UCS is a great start and frankly what customer only buys from a single server vendor today? Now they have a real alternative from a company who brings a great name and reputation to the table. Cisco is no Egenera, and to that end I would simply say to happy HP customers, “Keep your eyes and mind open”.

Disclosure: I am a happy Cisco employee.

UCS uses VNTag technology internally and using it does not require UCS to be connected to Nexus. In fact as VNtag is link local only it does not matter where you connect UCS to nor is VNTag ever visible to user or upstream switch.
Only thing that is required to connect UCS to any environment is 10Gb Ethernet port and in the future you can connect it to 1Gb ports as well.

Disclosure: Cisco UCS TME