1. Initial deployment of hardware/server
Lets think about the steps (and time) involved in deploying a blade for each system. With HP, the blade is inserted into a slot and a profile is built (either from scratch or copied) and applied. The blade must then be checked for firmware, and possibly patched. Now the blade is ready to be zoned for storage and have an OS installed. This process takes several hours

With Cisco UCS the process is drastically different and shorter! Here is how it happens in my environment. A PM comes to me and says, “I just submitted a PO for 8 UCS blades for project x. Once they arrive, how long do your team need to build them?”. My answer, “a couple hours”. This is becuase we can setup Service Profiles without having the hardware. And since the Service Profile contains the WWWN, we can have the zoning completed before the hardware arrives onsite. The only work left to do once the blade arrives is to slide it into any slot (more on this later) and install an OS!

2. Firmware Management
How many people enjoy patching firmware on a HP c7000? Anyone? I didn’t think so! You spend a couple hours searching HP’s site for firmware compatibility matrix and downloading packages for switches, blades, etc. Then you get to apply those patches, and in the case of Virtual Connect, HP states it cannot be done without downtime!!!

With Cisco UCS it is almost too easy. For starters, there are 2 downloads, the blades and the chassis infrastructure. Not only that, but the versions match!!! Applying the firmware is exponentially simpler and can be done with, imagine this, NO downtime (until you patch the actual server adapters). The best part is that with Cisco UCS, the firmware version is managed within the Service Profile. This means that any blade that is associated with a specific profile will always have the desired firmware level, automatically!!! And, to go one step further, with Service Profile Templates a series of like Service Profiles will always be the same. Updates to the Template get pushed to the Profiles!

3. Server Inventory
For our HP Chassis environment we maintain a spreadsheet to track the location of each chassis and blade. This is how it works…Joe comes to me and says, “Server BLAH seems to be down, can you get into to the ILO”. I have to open a spreadsheet, find out in what chassis that blade resides and then login to that chassis OA and then to the ILO of the blade. Now, to be fair, a well implemented Insight Manager can help with this, but who has a well implemented Insight Manager environment?

With Cisco UCS, we keep zero records of blade location! Why would we since we do not care about the physical blade. What we care about is the Service Profile associated with a blade. If there is a problem with server BLAH, we simply log into UCSM (a single management interface) and connect to that Service Profile. We do not even label the blades in the datacenter. The blade server is now a commodity!

The second, and my absolute favorite is Storage DRS!!! Our primary production VMware environment consists of ~65TB of storage. In the past 18 months, we have migrated that storage 3 times. The first two times were between SANs environments. The third migration was from 500GB datastores to 1TB datastores, a project that is still in progress. With vSphere 4.x we have had to use PowerCLI to automate those migrations (see this VMware Communities Site for an example script). This has worked well, but requires oversight due to provisioned capacity, free space, affifinty, and VMs per datastore. Storage DRS in vSphere 5 eliminates the need for manual storage migrations and PowerCLI scripts. In addition, it adds a great deal of important functionality such as I/O load balancing and Datastore Clustering.

The fault is F0337: Server does not fulfill Service Profile due to invalid-wwn. More specifically, it is due to the OUI of the WWNN being all zeros (xx:xx:00:00:00:00:xx:xx).

I thought it was odd because a fault was never generated when I created the WWNN Pool, but only when the Pool was applied to a Service Profile.

The fault is easily resolved by modifying the WWNN Pool such that the OUI contains at least one non-zero character.

Did you previously not create a SoL Policy?

If both of those are true, then you are probably getting warning faults on your Service Profiles. The fault is do to the Serial over LAN (SoL) Policy changes in Cisco UCS Firmware version 1.4(1i).  In version 1.3(1n) the SoL Policy could be left un-configured or default.  If a custom SoL policy was NOT created in 1.3, after upgrading to 1.4, each Service Profile and Service Profile Template will show a warning fault (blue box around it).

The fix is simple, create a new SoL Policy and apply it to each Service Profile Template / Service Profile.

This is a known bug, but at this time a fix has not been released. But, there is a simple workaround.

For each enable port with license state of “License Grace Period”, simply disable then enable the port. The license state should then reset to “License OK”.

“