You can also call upon the Ethernet and FC port designations you created earlier -- such as eth0, eth1, fc0, and fc1 -- that correspond to each FI, thus providing redundancy across each blade. I did run across a few bugs here; for example, port assignments that were clearly defined as Fabric A and Fabric B somehow merged in to Fabric A when that template was applied to a server and had to be manually corrected. I was assured that this bug was being actively addressed. In the grand scheme of things, it's minor and highlights the fact that this is a 1.0 release.
There are two forms of service profile templates: initial and updating. Each has specific pros and cons, and it's unfortunately not possible to switch forms after a profile has been created; if you begin with an initial profile, the profile cannot later be used to propagate updates.
Initial profile templates are used to build service profiles once, with no attachment to the originating templates. Updating templates are bound to those service profiles, so changing settings on an updating template will cause those changes to be pushed out to all bound service profiles. This is a double-edged sword, because while it does simplify the management of service profiles, making those changes results in a reboot of those profiles -- sometimes with little or no warning. Something as innocuous as changing the boot order on a template could cause 20 blades to reboot when you click Save. It would be nice to have an option to stagger the reboots, schedule them, or both. Cisco has acknowledged that problem and is working on a fix.
Initial profiles do not have this problem, but once built, they must be manually modified one by one, server by server, if changes are required. There is no best-of-both-worlds solution here, unfortunately.
In any event, you can create a service profile that defines what firmware a blade should run on each component; what WWNN, WWPN, and MAC addresses to assign to the various ports on the blade; what management IP address to assign to the BMC; what order to boot the blade; and where the blade boots from -- local disk or SAN LUN. You can then assign that profile to either a specific blade, or you can put all the identical blades into a pool and assign the profile to the pool, letting UCS pick the blades. Here, a curious thing happens.
Each blade is but an empty vessel before UCS gets its hands on it. With each server profile, a blade must conform to any number of specific requirements, from the firmware revision on up. Cisco accomplishes the transformation from blank slate to fully configured blade by PXE booting the blade with some 127.0.0.0 network PXE magic and pushing a Linux-based configuration agent. The agent then accesses all the various components, flashes the firmware, assigns the various addresses, and makes the blade conform to the service profile. This takes a minute or two, all told. Following that, the blade reboots and is ready to accept an operating system.
This process presents a bit of a quandary: What if I want to PXE boot the OS? Through a bit of magic, the UCS configurator PXE framework will not interfere with normal PXE operations. It's apparently smart enough to get out of the way once the blade has been imprinted with the service profile. From that point on, you can install an OS as normal -- say, VMware ESX Server, RHEL 5.3, or what have you.
You may still be better off sticking with Win7 or Win8.1, given the wide range of ongoing Win10...
Now that we're down to the wire, many upgraders report that the installer hangs. If this happens to...
Based on a technique created by a German blogger, here's how to stop wasting hours checking for Windows...
Cloud storage vendors don't provide a comfortable balance for some IT admins, but third-party options...
The bad guys are wreaking havoc. Why can't they be brought to justice?
A project sponsored in part by Google aims to allow algorithms to be optimized to get the most out of...
Not every enterprise application makes sense for the cloud. Here's how you'll know when you've...