So, I had to fix a broken UCS fabric interconnect the other day and I wrote about it here. In that experience, I came across a new feature that is pretty cool. I wish I could say which version of UCS introduced this, but I’m not that “close” to each UCS release these days. But I know it works if the FI is running at least 2.1.3 because that is what I was on. Continue reading
So, I recently noticed that nowhere on the web (that I could find) is it documented what happens when you run “erase configuration” on a single Fabric Interconnect that is part of a cluster. Does it erase the configuration on just that one FI or does it erase the whole UCS “system” as the command warning says? I know the suspense is killing you….Well, it’s just the single FI an it leaves the other FI and the full configuration intact. This is useful if you need to rebuild the config of a single FI that is part of a cluster.
So, I thought I’d share an experience I had yesterday where my Cisco UCS Fabric Interconnect (FI) wasn’t feeling well and in my attempt to resurrect it, I seemed to break it even more. I’m sure that never happens to you…The FI was now booting to a bash prompt instead of the normal UCS console interface. It would get to the point where it would say “System is coming up….Please wait” and it would say this about 12 times and then display the bash prompt. I won’t bore you with what I actually did in my attempt to get beyond this, but lets just say I spent about 2 hours debugging it when the fix should have only taken about 5 minutes (hindsight is 20/20). It goes without saying that this situation should not happen under normal circumstances, but I’ve heard rumblings of people seeing this here and there after upgrading to 2.2.x. So if Google brought you here looking for a solution, you’re in luck. Continue reading
So, today’s article is on VLAN separation, the problems it solves, and the problems it sometimes creates. Not all networks are cut from the same cloth. Some are simple and some are complex. Some are physical and some are virtual. Some are clean while others are quite messy. The one thing that they all have in common is that Cisco UCS works with all of them. Continue reading
So, about 2 years ago I was with a customer who had opted to purchase UCS over their incumbent HP hardware for their private cloud build. As a first step, we upgraded the firmware on the UCS system. What I did not know at the time was that the mgmt0 cable plugged into the “B” Fabric Interconnect (FI) was showing link, but was not on the right vlan (or wasn’t passing traffic). When it came time in the upgrade to failover the management instance of UCSM to the “B side”, we lost access completely to UCS manager. This and other seemingly related events (but were actually totally unrelated in hindsight) led me to believe that UCSM had failed in some manner and started me down a multi-hour troubleshooting session that I really wished had never happened. I opened an enhancement request to allow UCSM to detect this situation in the future and move UCSM back to the originating FI if it is unable to find the default gateway. Had I known this trick that I am about to tell you concerning the UCS shells, I might have been smart enough to get out of my situation much faster. The sad thing is I actually did know this – it was just knowledge from so early on in my UCS learning curve that I didn’t fully absorb the importance of it. So, now is your chance to start absorbing…
So, way back in early 2009, Sean McGee and I decided to work over the weekend in San Jose to get more stick time with “Project California” as UCS was called then. We borrowed a system from someone, backed it up, and started discovering how UCS worked. We had no help locally since it was a weekend and one thing I wanted to know was how to erase the configuration and start over. We were still months away from documentation and the online help inside the pre-1.0 UCSM was very incomplete. We eventually did figure out how to erase the configuration and start over, but we had to stumble upon it. Resetting UCSM is a well-documented process now, but I thought I’d write this post to cut through the pre-requisites and making sure proper backups are done, etc. I just wanted to give you the commands to get the job done. You’re on your own to make sure you really want to do this.
So, everyone would agree that a helping hand is nice to have now and then. Like the time I thought it would be a good idea to skateboard while holding onto my brother’s car as he drove down the street. It was his helping hand reaching down to pick me up off the road (bleeding) and sitting me in the car that I won’t forget (I still have that scar on my hip). It was brother helping brother – an understanding that when one is down, the other will help get him on his feet (hopefully before mom sees so that we could get our story coordinated as to how it happened). In the UCS world, the brothers in this scenario are the Fabric Interconnects (I’m not sure who the mother is). Continue reading
So, have you heard the news? The world’s fastest growing x86 server company is joining forces with the world’s fastest application acceleration company? While the partnership on the blade front is somewhat recent news, Cisco has long been supporting Fusion-io accelerator products in our C-Series servers (and will continue to do so). In June 2012, Fusion-io and Cisco inked a deal that would extend our partnership to cover UCS B-Series Blade servers as well. It’s not simply changing the form-factor and connector; it’s also extending UCS Manager to include integrated support for the cards for inventory and management purposes. To read more on the partnership, look here: http://www.fusionio.com/blog/coming-to-cisco-ucs-blade-servers-soon-iomemory/
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