I was performing my first upgrade past 2.2(3) this weekend (upgrading to 2.2(5)) and I came across a small change that took some googling to figure out. Eventually, I found the resolution in the Release Notes. If you’re performing a manual upgrade to 2.2(4b) or later, you have to clear the Startup Version of the Default Infrastructure Pack. This action is the result of bug fix CSCus73964 and can be found in the Behavior Changes section of the 2.2 Release Notes.
The error occurred when trying to Activate the firmware of the IO Modules. It states, “Failed start activation. Manual upgrade/activation is disallowed because the Default Infrastructure Policy ‘Startup Version’ is set. Retry the operation after changing the version to ‘Not Set.'”
The UCSM GUI option to clear the startup version on the Auto Install tab was grayed out so I couldn’t clear it from there. The Firmware Management CLI Guide offered the CLI solution to clearing it, though, and it worked fine.
Reading the release notes is always a good idea – but boring. But I perked up today when I was perusing the latest release notes for 2.2(5) for an upcoming implementation. Here are a few items I think are mentionable. Note that all these features were released in 2.2(4).
Clearly I didn’t deploy any UCS’s around the time that 2.2(4) was released because I totally missed this feature. In the distant IT past (pre 2.1 days), both the Infrastructure and Server firmware had to be at the same level to stay in support. Then came 2.1 which introduced backward compatibility with older Server firmware. Now you’re not necessarily forced to upgrade your blade firmware at the same time as your Infrastructure firmware. Nice. Now with 2.2(4) and Server Packs, blade firmware is backward compatible with Infrastructure firmware. Even better. Of course, this comes with caveats. That being that this feature starts at 2.2(4). So at this point, only 2.2(4) and 2.2(5) support such a configuration. But this is cool. Below is the latest mixed firmware version table from the release notes.
Read the rest of this entry »
I was recently designing a vSphere Replication and SRM solution for a client and I stated we would use static routes on the ESXi hosts. When asked why, I was able to 1. discuss why the default gateway on the management network wouldn’t work and 2. present some options as to how we could separate the vSphere Replication traffic in a way that would allow flexibility in throttling its bandwidth usage.
You won’t see listed here Network I/O Control because this particular client didn’t have Enterprise Plus licensing and therefore wasn’t using a vDS. In addition, this client was using a fibre channel SAN on top of Cisco UCS with only a single VIC in his blades. This configuration doesn’t work well with NIOC because it doesn’t take into account FC traffic which is sharing bandwidth with all the Ethernet traffic NIOC *is* managing.
I had the opportunity recently to deploy 18 B420 M3 blades across two sites. Having only deployed half width blades over the last two years, I had to change my usual Service Profile configuration for ESXi hosts to ensure the vNICs and vHBAs were properly spread across the two VICs installed in each blade. Each B420 had a VIC 1240 and a VIC1280. The Service Profile for the blades includes six vNICs and two vHBAs. The six vNICs were used to take advantage of QoS policies at the UCS-level. The six vNICs configured included:
- vNIC FabA-mgmt
- vNIC FabA-vMotion
- vNIC FabA-VM-Traffic
- vNIC FabB-mgmt
- vNIC FabB-vMotion
- vNIC FabB-VM-Traffic
So my UCS Manager GUI was having certificate problems today in my test lab and I really wanted to get something done. I think I need to update UCSM from 2.0(1s) to one of the latest, but that’s a project in itself, especially if I can’t just click-click-click my way through. What I really wanted to do was add a couple existing VLANs to the vNIC of an ESXi host on a blade (so I could vMotion some stuff around). Of course, with the GUI, it’s a few clicks. Without the GUI (and not knowing where to go in the CLI), I was at a bit of a loss.
The UCS CLI guide wasn’t helpful as it was more for managing the hardware or upstream configs – not so much for what would seem like a task made for UCSM. So to get on with it, let me share the quick config for adding VLANs to vNICs. This post actually got me in the ballpark (just search for “vlan” in the post), but from there, I was on my own!