UCS 2.0(1q) Patch Released

[Robert Burns]

Greetings All,

The UCS 2.0 patch 2.0(1q) has been released which addressed a couple major bugs detailed in the thread here.

Release Notes:

http://www.cisco.com/en/US/docs/unified_computing/ucs/release/notes/OL_25363.html#wp232083

Software:

http://www.cisco.com/cisco/software/release.html?mdfid=283612660&flowid=22121&softwareid=283655658&release=2.0%281q%29&relind=AVAILABLE&rellifecycle=&reltype=latest

Highlights of major issues fixed:

-Using the UCSM GUI, you are now able to disassociate a service profile that is currently bound to a template. (CSCts95454)

-When you assign an org to a locale from the GUI, the operation sometimes   fails due to an internal error.  This error is now corrected.   (CSCts60863)-The PCI Device address of a VNIC will not change after an upgrade of UCS   Manager from Release 1.x to Release 2.0(1q). (CSCts96949)-When the DHCP server is using an option 67 (RFC 2132) to report the  bootfile  name to the gPXE client, gPXE will receive the boot parameters  and the  boot will function normally. (CSCts86689)-When the BIOS is upgraded on a B230-M1 blade from Release 1.x to Release 2.0, the PCI address is preserved. (CSCts86890)

-B230-M1 blade discovered while running 1.4 BIOS release image and now   running a UCS 2.0 release BIOS image will associate and disassociate   normally. (CSCtj54470)

-A Blade with a service profile with a 22 character or longer name will   boot as expected from the local disk after upgrading the BIOS from a  1.x  release to the BIOS in the 2.0(1q) release. (CSCtt13313)

Any issues with this release, please let us know.

Regards,

Robert

[its-networking]

I hate to bump a thread as old as this one, but after upgrading from 1.4 to 2.0(1w) I've also been seeing failed flogi warnings being reported.

Running 'show interface vfc ' shows the trunked VSAN as 'Trunks vsans (initializing)' rather than 'Trunk vsans (up)'.

A 'show flogi database | in ' and 'show flogi database fcid details' on the upstream fabric switch shows the flogi to be in a normal state.

Rebooting the hosts tends to clear the warning.  I'm happy to raise a case but just wondered if anyone else was still seeing this problem or had any ideas.

[varrow_jgillow]

I have still seen some of these messages with 2.0(1w), usually they are false alarms and can be ignored.  Although today I had a esxi 5.0 blade that was logged into SAN fabric A but not fabric B, had to reboot the blade then it logged into both as it should have.

[gballard]

I was told by a Cisco consultant that resetting the DCE interface(s) should clear the error. But it'll come back (probably) if you reboot the server later. Next time I do system maintenance I will try that.

Dismaying to hear about w still having that problem though. I have to upgrade to w when I get my new 440 blade in (thank you thermal event recall) and I was hoping that the false flogi alerts would go away.

[suneeel86]

Hello,

I still have following issue with B200 M2 blade with M81KR card

-When the DHCP server is using an option 67 (RFC 2132) to report the   bootfile  name to the gPXE client, gPXE will receive the boot  parameters  and the  boot will function normally. (CSCts86689)

The firmware version is 2.0 (2q)

Im trying to Pxe Boot the blades with ESX5 using AutoDeploy sw ..

can anyone confirm if this issue exists in the above firmware still ??

[Robert Burns]

Santosh - Yes, that particular bug was fixed in 2.0(1q).

regards,

Robert