So, one of the huge advantages of Cisco UCS is its approach to “statelessness”. If you are not familiar with this concept, just know that anything that ties an operating system, hypervisor, or application to a specific piece of hardware is considered “stateful” and is not desirable in datacenter servers. Using this methodology, Cisco has made the upgrade path extremely easy for a customer to upgrade from one server model to the next without having to re-install anything. To be more specific, I upgraded various operating systems and hypervisors that were running in a service profile assigned to a B200 M2 and moved the profile to a brand new architecture of a B200 M3. The UCS portion of this migration is really (really) easy – you simply associate the profile from an M2 and assign it to an M3. The OS or hypervisor takes care of the rest. This article will cover the details of how this migration worked and what steps I took to make sure it was a success. Disclaimer: everything you’re about to read is totally unsupported by Cisco TAC. As a company, we have not tested nor certified this process. I am simply reporting here what I, myself, have tested and seen work. So don’t call Cisco if this doesn’t work. Feel free to leave a comment and I’ll look into it when I can find time. Continue reading →

So, there is a little known feature in Cisco UCS that allows one to monitor traffic on the control plane without the hassle of actually hooking up an Ethernet analyzer. The control plane is physically the “mgmt0″ port on the Fabric Interconnect (FI) and it is used for managing the FIs themselves and for attaching to KVM sessions on the blades. Cisco UCS makes the capture process really easy and in this article I’ll show you how to do it. Remember, this process only captures control plane traffic – not data traffic (UCS has a similar function called Traffic Monitor for that). So, how is this useful? Well, there’s always the chance that something unexpected could happen in UCS Manager as a result of malformed packets entering the Fabric Interconnect’s mgmt0 port. TAC would need to see what the data looks like in order to determine the cause. But the more likely scenario here is that you are using the Cisco UCS XML API and would like to inspect the management traffic being sent to and from the Fabric Interconnect from either UCS Manager or some other external manager controlling UCS. This is an extremely useful tip to aid in the XML API learning process. If you are not familiar with the API of Cisco UCS, it’s an extremely powerful engine provided to customers, system integrators, independent software vendors (ISV). You can find additional information about the API, download it, and learn how to work with it on the following site: Continue reading →