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 fast. 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…
Continue reading →

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.
Continue reading →

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/
Continue reading →

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 →

So, in my last article, I discussed Appliance Ports and how to set them up. But there was a hidden gem in there that I felt deserves its own article because it’s just that cool. If you’ve ever setup the MTU on servers because you want to use an iSCSI array, you’ve suffered through how exactly to get the OS to recognize the new MTU size. As I pointed out in my last article, this process this involves a registry hack, ifconfig, esxcfg-vswitch, or setting the MTU manually within the Windows adapter properties. It’s worth the time to investigate because many applications perform better when the conversation doesn’t have to be fragmented into many small chunks. Continue reading →

So, I recently had a customer that wanted to enable “Jumbo Frames” to a UCS server that had the Cisco Virtual Interface Card (VIC) installed in it (also applies to Palo/M81KR, VIC-1240, VIC-1280). You might also know this process as “maximizing the MTU”. In this particular situation, the customer had an iSCSI appliance directly connected to the fabric interconnects (Whiptail in this case, which is not officially supported by Cisco as of this writing, but this process will be the same for any iSCSI appliance – supported or unsupported). It’s not the first time this has come up so I thought I’d write it down so that everyone can benefit (including me when I forget how I did all of this). This article will be helpful if you’re using any NAS storage such as NFS, CIFS/SMB, or iSCSI. Continue reading →

So, first let me define some terms….the Cisco VIC is also called “Palo” – a codename that sort of stuck (much the chagrin of the marketing team). Palo’s official name is M81KR – now do you see why “Palo” sort of stuck ? We have some new VIC cards as well – the VIC-1240 and VIC-1280 and Sean McGee (@mseanmcgee) talks more about the VIC-1280 here. The VIC-1240 is a built-in option on the M3 blades. Now that we settled that, where is Part 1 of this article? Well, my good friend Ryan Hughes (@angryjesters) got the ball rolling on this. He took it upon himself to write an excellent article explaining how to access the obscure-but-useful command called LUNLIST. So if you are looking for Part 1 to this article, I’m not the author of it. I learned some things reading Ryan’s article, which is not all the surprising since I’m rarely with Ryan when I don’t learn something. You should check out his site if you have not seen the article already, but briefly, LUNLIST is a command that shows you what the Cisco VIC HBA can actually “see” on the fabric – much like a typical HBA BIOS would…but way cooler. Continue reading →