But for instance, let's say I have a UCS with UCS Manager 1.4, and I purchase a new blade that has the 2.0 firmware in BIOS/CIMC/M81KR...what should I do here?:

a) Upgrade the whole UCS to the 2.0 version

b) Downgrade the new blade to the 1.4 version

c) No problem to have blade with 2.0 while keeping 1.4 for the rest of UCS (in this case: is there any compatibility matrix where to check the valid relationships?)

Thanks,

This is what the Host Firmware Package/Management Firmware package policies are for. 

With these policies you set a firmware version for BIOS, Adaptor, Disk controller, Board Controller (B230/440). The Management Firmware package sets the CIMC version. These policies are then tied to a Service Profile Template/Service Profile. When you deploy a Service Profile from the template for the new blade it will upgrade/downgrade to be complient with the policy.

This firmware upgrade/downgrade happens as part of the Service Profile association.

I know that FW policies are there to help me...but to help me do....what?? Again, te question was: having UCS 1.4 and purchasing a new blade with 2.0 FW...what shoud I do??

a) Upgrade the whole UCS to the 2.0 version

b) Downgrade the new blade to the 1.4 version

c)  No problem to have blade with 2.0 while keeping 1.4 for the rest of UCS  (in this case: is there any compatibility matrix where to check the  valid relationships?)

Thanks in advance

The blade work with the other FW versions being at 1.4,

Think of it this way, when you do upgrade the firmware from 1.4 to 2.0 you can upgrade the host Adaptor and CIMC first. This is one of the supported upgrade paths if you aren't using host/mgmt FW policies. If you do this your blades will have 2.0 but everything else is still at 1.4.

I would however match it with the others especially if it will be an ESXi host in a cluster with other hosts. This way everything is consistent across the board.

The FW policies will downgrade the FW of the new blade to match the policy. When you do decide to upgrade to 2.x you can use the FW polices to assist with this. In combination with a user-acknowledge maintenance policy your can apply a new FW policy with version 2.x and then if you have a user-acknowledge maintenance policy it will kick in and require you to acknowledge each service profile reboot. If you are running ESXi on these you can utilize maintenance mode and do a rolling upgrade one host at a time.

Ok, so I assume out of your answer that either downgrade the blade or upgrade the rest of the UCS would work fine.

But still, if I choose to not do any of the two above, I could still keep the 1.4 in the UCS and the 2.0 in the blade, right?

Then I don't understand the following statement:

"You cannot mix component software versions (e.g you can not have a B200 using the 1.0(1) BIOS with a UCS M81KR adapter running 1.0(2) firmware managed by UCS Manager 1.3(1))"

http://www.cisco.com/en/US/docs/unified_computing/ucs/release/notes/OL_25363.pdf

Why I cannto mix these firmwares? Where is the Matrix that tells me I cannot mix them?

Right, you can have some at 1.4 and some at 2.0. During a firmware upgrade component versions will be at different versions. You don't upgrade every component at the same time so during this time some components will be at 1.4 and some at 2 but everything will continue to work fine.

I wouldn't recommend running that way long term but it does work fine

I have performed numerous upgrades from 1.3 to 2.0 where the blade adaptor, cimc and bios are upgraded last but at a later date of may be a few days. During this time some components are at 2 and some at 1.3.

Then, could you explain me the meaning of the following statement that I took from 2.0 Release Notes?:

"You cannot mix component software versions (e.g you can not have a  B200 using the 1.0(1) BIOS with a UCS M81KR adapter running 1.0(2)  firmware managed by UCS Manager 1.3(1))"

http://www.cisco.com/en/US/docs/unified_computing/ucs/release/notes/OL_25363.pdf

There are 3 different versions there with a wide gap between the versions. That is not supported. All components on a blade need to be at the same level. That includes CIMC, BIOS, and adapter firmware. As Jeremy said if you are in the process of upgrading that is fine, but never run long term in that situation.

You also want all your components within UCS to be the same code level as well. We do not support UCSM at one level and your FIs/IOMs at another. Everything must be at the same level.

If you get a new blade or component that is at a higher level than you are running then you should downgrade. In some cases newer hardware requires an upgrade. A good example will be the M3 blades when they come out. You will not be able to run an M3 blade on 1.4 code you will have to upgrade.

Hope that explains it.

louis

CIMC's can by updated without interupting blades. I preffer updating CIMC's first, and have mixed 2.0 and 1.4 Bios and Mez card without any trouble a few times. Best to control CIMC, Bios, and Mez card code level with Firmware policies.

The 2.0 code has new OS drivers so be sure and check that out. Have mixed 2.0 and 1.4 a few times both ways and never made a difference. Due to a lazy SCCM admin ran 2.0 OS drivers on 1.4 blade firmware for a few months. Didn't make a difference. This is all with Windows 2008R2.

Over time have found that this is the best order for updating code levels on Cisco UCS. This way the UCSM keeps communication between itself down to the CIMC through the update process. Note that the IOM’s wait until their FI reboots to reboot and update code level.

This is considered the “Bottom Up” method.  Some prefer the “Top Down” method but I have found it much less smooth and harder to recover from if something goes wrong.

Always backup configuration before upgrading code levels.

Should go

1)      CIMC

2)      IOM (which will wait until the FI’s update)

3)      UCSM

4)      FI X (Which ever is the current passive FI)

5)      FI X (Second FI)

Read more:

http://realworlducs.com/page/2/#ixzz1pHYurmep

Then, if everything should run the same FW version, I don't understand the purpose of the Firmware Policies. I thought the purpose of those policies was just the fact of being able to maintain different FW versions in different blades/profiles. But according to your sentence: "You also want all your components within UCS to be the same code level as well." it is not as such...

I'm kinda confused...

Ok, thanks for all your inputs.

Regards,