2.0 Upgrade

Unanswered Question
Sep 20th, 2011

Has anyone completed the upgrade to 2.0?  And if so, how was your experience?

I have the firmware bundles downloaded and am preparing to run the upgrade but wanted to know if anyone has run into any issues.  I have checked and do not have any FCoE VLAN overlap. 

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 1 (1 ratings)
v-crsimp@micros... Tue, 09/20/2011 - 09:40

We will be upgrading this week in our test lab (6120 4 chassis), and than moving onto production (6140 14 chassis). Will keep everyone posted.

Craig

peter.robertson Tue, 09/20/2011 - 10:31

I went ahead and ran the upgrade this morning.  We only have a couple of production VMs running on our UCS as we wanted to wait for 2.0 before migrating our entire production environment.

I used the 1.4 to 2.0 upgrade instructions as my point of reference but the process is no different than a usual minor version upgrade.  Everything went well. The process took around an hour for me to do both FIs, UCSM and our blades (we have one chassis).  Both VMs remained up and fully accessible the entire time except for one icmp time out during a vMotion between hosts to allow me to reboot all blades.  

I will let you know if I run into any post-upgrade issues.

roberbur Wed, 09/21/2011 - 10:50

Craig/Peter,

We greatly value your feedback.  Please do let us know if you have any questions or issues with the upgrade.

Look forward to hearing back once you've deployed UCSM 2.0

Regards,

Robert

peter.robertson Wed, 09/21/2011 - 11:11

Robert,

So far I have not run into any issues... but then again I have not yet tried to take advantage of any of the new features in 2.0 or made any significant config changes.  I have merely upgraded each component and then ensured that my pre-upgrade configuration is running stable; which it appears to be. 

My only comment so far is that the process of applying the service profile to the blade, and all the other POST/memory test/configuration that occur when you power on a blade, seems to take considerably longer.  The O/S itself boots just as quickly but it takes a while to get to that stage.

Regards,

Pete

roberbur Wed, 09/21/2011 - 11:20

Peter,

That's the first I've heard/seen that.  Let me chase up development to see if there were any BIOS/POST changes to increased the diags.

==> Have you already updated the blade BIOS to the latest also?

Thanks for the feedback.

Regards,

Robert

peter.robertson Wed, 09/21/2011 - 11:31

==> Have you already updated the blade BIOS to the latest also?

I created a Host Firmware Packages and a Management Firmware Package for my B200 M2s.  In the host firmware package I selected 2.0(1m) for the Palo, S5500.2.0.1a.0.08112011606 for the B200 M2 BIOS.  For the Management Firmware Package I selected 2.0(1m) for the B200 M2.   I applied both of these packages to my service profiles and restarted.   Is there anything else I need to do?

roberbur Wed, 09/21/2011 - 14:27

No Peter  - You have all the bases covered.

I discussed this with our BIOS team and with the new EP BIOS on B200's there are some additional steps in the POST process which explain the slightly longer diag.  Also, we've switched from using an internal PXE boot to using vMedia for the association & blade programming process.  All this will improve stability, but comes at a slight increase in time for POST.  I have also discussed this with other colleagues and this has been noticed - so it's expected behavior.

Hope this helps.

Regards,

Robert

erikhilton Thu, 09/22/2011 - 00:30

Hi!

I did the upgrade yesterday. I had the overlapping FCoE VLAN in my default VSAN. So far I have noticed one problem:

On our ESXi servers we use the Palo (M81KR) adapter. After updating BIOS, Adapter and CIMC our vNICs have changed their PCI numbering. Here is what I see looking in the esx.conf file in ESXi:

Before upgrade:

vmnic0 - 08:00.0

vmnic1 - 09:00.0

vmnic2 - 10:00.0

vmnic3 - 11:00.0

vmnic4 - 12:00.0

vmnic5 - 13:00.0

vmhba1 - 14:00.0

vmhba2 - 15:00.0

After upgrade (notice how ESXi changed the vmnic names since the PCI address changed):

vmnic0 - 08:00.0

vmnic6 - 08:00.1

vmnic7 - 08:00.2

vmnic8 - 08:00.3

vmnic9 - 08:00.4

vmnic10 - 08:00.5

vmhba3 - 08:00.6

vmhba4 - 08:00.7

Since vmnic0 still has its old PCI address I can still reach my admin interface on ESXi, but my other vSwitches have problems with the new names.

Anyone else seeing this?

Regards

Erik

Jeremy Waldrop Thu, 09/22/2011 - 03:34

Are you using a vNIC/vHBA placement policy to force your vNICs/vHBAs to be deteceted in a specific order?

Jeremy Waldrop Thu, 09/22/2011 - 03:57

That is probably why the PCIe ordering changed then. With a placement policy you can force the correct order so that you can gaurantee vmincX will always be dedected by ESXi as the same adapter.

erikhilton Thu, 09/22/2011 - 04:25

Thanks for your answer.

I am not sure that is the problem. The order is the same, but the PCI numbering changed. Look at for example vmnic1:

Before:

vmnic1 - 09:00.0

After:

vmnic6 - 08:00.1

So to me it looks like the order is still the same, but instead of numbering them 08, 09, 10 it has changed to 08:00.0, 08:00:1, 08:00:2 etc.

skumar7193 Thu, 09/22/2011 - 06:24

Erik,

Could you please let me know what blade model was this observed on?

I have a test result on a B440, after the the upgrade to 2.0(1m) ESXi renumbered from 0,1,2,3 to vmnic 4,5,6,7.

I have also seen the same being affected for B230 as well. This disrupted all network access to hosts. I had to manually edit the /etc/vmware/esx.conf file return the values to its original

Thanks









erikhilton Thu, 09/22/2011 - 06:35

Hi skumar7193!

I have B200 M2 blades with Palo, M81KR, adapters. I have tried to downgrade CIMC, Adapter and BIOS on the blade. Still the same PCIe numbering. I then reinstalled ESXi. No change... Whatever happened I can not get the "old" numbering back.

Do you have any vNIC/vHBA placement policies?

roberbur Thu, 09/22/2011 - 06:36

Can you both also advise if youi're using one or two adaptors (in case of B250/B440).

Thanks,

Robert

skumar7193 Thu, 09/22/2011 - 06:41

I have a dual adapter and yes,I have a placement policy. The ESX version is 5 if it matters, I missed that in my earlier post

-Sukesh Kumar

erikhilton Thu, 09/22/2011 - 06:42

Hi Robert!

Since we only have B200 M2 there is only one adapter in my case.

/Erik

roberbur Thu, 09/22/2011 - 06:44

Let me fire this up in my lab and get back to you today.  I'll test both blades with ESX 4 & 5.

Stay tuned.

Regards,

Robert

kg6itcraig Thu, 09/22/2011 - 10:16

Update went well in our lab (6120 with 4 chassis). Did note that the IOM's were in "Updating" Status for like 15 minutes simultaneously after FI’s rebooted. That was odd, but no interruption to chassis traffic. Other than that, went like any other code update. We are not doing any virtualization at this time, so cannot comment on that. 

Will be doing our production system (6140 with 4 chassis) that is under heavy load. That will be the real test.

Craig

kg6itcraig Thu, 09/22/2011 - 14:03

In our lab after the update this critical error showed up. Appears and FCOE vlan and default VLAN have ID of 1.

calopez2 Thu, 09/22/2011 - 14:31

Overlapping FCOE VLAN and Ethernet VLANs  no longer allowed with UCS 2.0.

kg6itcraig Thu, 09/22/2011 - 15:28

So best fix for that (we are not using FCOE) would be to change FCOE vlan to and unused?

Craig

calopez2 Thu, 09/22/2011 - 16:34

Changing the FCOE vlan-id will clear the overlapping issue.

Jeremy Waldrop Fri, 09/23/2011 - 02:53

Yes, that is a best practice anyway that should have been followed pre-2.0. If you were to deploy Nexus 5ks with FCoE you would have to do the same for FCoE traffic.

roberbur Fri, 09/23/2011 - 11:56

The FCoE VLAN Change was documented in the release notes:

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

There was also a Software Advisory in the Release notes pertaining to this change. 

http://www.cisco.com/web/software/datacenter/ucs/UCS_2_0_Software_Advisory.htm

As Jermey pointed out, your FCoE VLAN should never be used for anything other than FCoE, and does not need to exist outside of UCS.

Regards,

Robert

roberbur Tue, 09/27/2011 - 11:23

In regards to the PCI re-ordering issue we've identified two bugs.

CSCts86890 - B230-M1: PCI bus numbers change after an upgrade from 1.4 to 2.0

Description:       

When the BIOS is upgraded on a B230-M1 blade from 1.4 release to 2.0 release, the PCI bus enumeration will shift by one bus number.  This can potentially cause  certain OS like VMWARE ESX, Windows to see the old VNIC’s and VHBA’s with new PCI address and could result in those interfaces being non operable unless the configuration is changed in the OS.  In case of ESX, a workaround would be edit the esx.conf with the new PCI address  and to modify the vswitch configuration.

Workaround: 

At this time there are only two ways to correct the issue

1. In case of ESX, manually modifying the ESX.conf file to re-map the vmnic numbering.

2. Revert entire UCS System from 2.x -> to 1.4.x : VMware & Windows PCI ordering reverted back to original mapping and old NIC numbering restored Additional workarounds are under investigation.

CSCts96949 - PCI Device address changes after an upgrade from 1.4 to 2.0 release on VIC device

Description:       

When a system is upgraded from UCS 1.4 and earlier releases,  the PCI device address of existing Service Profile VNICs and VHBAs in case of VIC adapters changes.  This can potentially cause certain OSes such as VMware ESX and Windows to see the old VNICs and VHBAs with new PCI addresses, which could result in those interfaces being non operable unless the configuration is changed in the OS.  In the case of ESX, a workaround would be to edit the esx.conf with the new PCI address and to modify the vswitch configuration.

Workaround:

There are two current workarounds.

1. In case of vSphere, manually modifying the ESX.conf to re-map the PCI -> vmnic numbering

2. Downgrading the BIOS of the blade from 2.x -> 1.4.x

**Software patches for these two issues are currently being developed and will be made availalbe as soon as possible once they clear QA.

I will update this thread as soon as the patches have been released.

Regards,

Robert

kg6itcraig Wed, 09/28/2011 - 08:50

On our 6104 UCS with 14 Chassis of B200 M2 Blades we ran into bug

(CSCTR74091)

http://www.cisco.com/web/software/datacenter/ucs/UCS_2_0_Software_Advisory.htm

Right after our first step the UCSM activation all the blades went into re-config and went offline (crashed the OS). Many had re-numbered NIC's.

FCoE VLAN was changed to 2 before update. There were no VLAN overlaps etc, UCS was perfect before update, 0 errors across top left of screen. After UCSM Activeate to 2.0 Code all blades has this error:

http://realworlducs.com/images/619207123.png

In the end we had to disassociate and associate all the service profiles to get the blades back online. These are all Windows 2008R2 machines in an Armada 4.1 encoding farm.

Also one of our vNIC pin groups will not work on failover mode after rollback. Had to switch to one fabric, and not check Enable Failover. Will work with TAC to figure that out.

TAC said a patched version of 2.0 will be out in 1 to 2 weeks that does not crash your UCS while updating. Looking forward to that.

A picture is worth a thousand words so I will summarize our 2.0 upgrade with this:

http://blogs.e-rockford.com/applesauce/files/2011/05/car-flying-off-cliff.jpg

Craig

jwhannell Thu, 09/29/2011 - 15:41

Would you summarize this as "completed, but not working?"

In all seriousness, thanks for the information, hopefully we can avoid our own trainwreck.  Andy L found your articles/posts and shared them with us via facebook.  Good stuff.

llozanos81 Fri, 09/30/2011 - 10:02

Hi Craig, do you figured out the  Pin Group Issue? i think i have the same problem, i created a Pin Group  for 2 Uplinks, at service profile 1 nic is pinned to FIA and the other  one is pinned to FIB, all Blades are ESXi 4.1.

I  tried the Failover feature of UCS disabling one Uplink port of two in  the Pin Group in this case was FIA, Mgmt traffic failover to FIB and was  working, when i tried to get it back VMware detects that the first NIC  is online and it tries to forward trafic to the restored Uplink but its  not working, i had to disable the FIA uplink to get ESXi Management  Console to get the cluster up again.

Is this kind of your scenario?

Regrads

Luis Lozano

roberbur Mon, 10/17/2011 - 08:36

Greetings All,

The UCS 2.0 patch 2.0(1q) has been released which addressed the two major bugs detailed above.

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)

BIOS

When the BIOS is upgraded on a B230-M1 blade from Release 1.x to Release 2.0, the PCI address is preserved. (CSCts86890)

A  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)

Regards,

Robert

kg6itcraig Fri, 09/30/2011 - 13:58

Since the code update been trying to figure out why if we select “Enable Failover” for our MetaData vNIC template (updating), or corresponding vNIC’s in service profiles traffic will not flow between upstream switch and FI’s. I can try downing a port-channel and that does not fix issue. Have tried each. Have to select an FI and not enable failover for traffic to flow. This was not the case before update.

Upstream 3750 switch config for MetaData VLAN.

!

interface Port-channel8

description UCS trunk to FIA

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 512

switchport mode trunk

!

interface Port-channel9

description UCS trunk to FIB

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 512

switchport mode trunk

!

############################

Corresponding UCS CLI output below.

UCS02-A(nxos)# show cdp neighbors

Capability Codes: R - Router, T - Trans-Bridge, B - Source-Route-Bridge

                  S - Switch, H - Host, I - IGMP, r - Repeater,

                  V - VoIP-Phone, D - Remotely-Managed-Device,

                  s - Supports-STP-Dispute

Device-ID             Local Intrfce Hldtme Capability  Platform      Port ID

UCS02-B(SSI135004JB)  mgmt3         144    S I s     N10-S6200     mgmt3

VLP127C7000NS002(JAF1429CKER)Eth3/3        164    R S I s   N7K-C7010     Eth10/26

VLP127C7000NS002(JAF1429CKER)Eth3/4        164    R S I s   N7K-C7010     Eth10/25

SAN127C3750NS001      Eth3/5        176    S I       WS-C3750X-48  Ten3/1/1

SAN127C3750NS001      Eth3/6        176    S I       WS-C3750X-48  Ten3/1/2

UCS02-B(nxos)# show cdp neighbors

Capability Codes: R - Router, T - Trans-Bridge, B - Source-Route-Bridge

                  S - Switch, H - Host, I - IGMP, r - Repeater,

                  V - VoIP-Phone, D - Remotely-Managed-Device,

                  s - Supports-STP-Dispute

Device-ID             Local Intrfce Hldtme Capability  Platform      Port ID

UCS02-A(SSI15120GEM)  mgmt3         166    S I s     N10-S6200     mgmt3

VLP127C7000NS002(JAF1429CKER)Eth3/3        136    R S I s   N7K-C7010     Eth10/28

VLP127C7000NS002(JAF1429CKER)Eth3/4        136    R S I s   N7K-C7010     Eth10/27

SAN127C3750NS001      Eth3/5        146    S I       WS-C3750X-48  Ten2/1/1

SAN127C3750NS001      Eth3/6        146    S I       WS-C3750X-48  Ten2/1/2

#####################

UCS02-A /eth-uplink # show pin-group MetaData expand

Ethernet Pin Group:

    Name: MetaData

    Ethernet Pin Target:

        Fabric Endpoint

        ------ --------

        A      fabric/lan/A/pc-2

        B      fabric/lan/B/pc-2

#####################

UCS02-A /eth-uplink # show interface

Member Port:

Fabric ID  Port-channel Slot  Port  Oper State    State Reason                        Lic State            Grace Period

---------- ------------ ----- ----- ------------- ----------------------------------- -------------------- ------------

A          1            3     3     Up                                                Unknown                            0

A          1            3     4     Up                                                Unknown                            0

A          2            3     5     Up                                                Unknown                            0

A          2            3     6     Up                                                Unknown                            0

B          1            3     3     Up                                                Unknown                            0

B          1            3     4     Up                                                Unknown                            0

B          2            3     5     Up                                                Unknown                            0

B          2            3     6     Up                                                Unknown                            0

####################

UCS02-A# scope eth-uplink

UCS02-A /eth-uplink # scope fabric a

UCS02-A /eth-uplink/fabric # show port-channel detail

Port Channel:

    Port Channel Id: 1

    Name:

    Admin State: Enabled

    Oper State: Up

    Speed: 10 Gbps

    Speed: 10 Gbps

    State Reason:

    flow control policy: default

    Port Channel Id: 2

    Name:

    Admin State: Enabled

    Oper State: Up

    Speed: 10 Gbps

    Speed: 10 Gbps

    State Reason:

    flow control policy: default

UCS02-A /eth-uplink/fabric # show port-channel expand

Port Channel:

    Port Channel Id: 1

    Name:

    Admin State: Enabled

    Oper State: Up

    State Reason:

    Member Port:

        Slot Id Port Id Membership Oper State State Reason  Lic State Grace Period

        ------- ------- ---------- ---------- ------------- --------- ------------

        3       3       Up         Up                       Unknown              0

        3       4       Up         Up                       Unknown              0

    Port Channel Id: 2

    Name:

    Admin State: Enabled

    Oper State: Up

    State Reason:

    Member Port:

        Slot Id Port Id Membership Oper State State Reason  Lic State Grace Period

        ------- ------- ---------- ---------- ------------- --------- ------------

        3       5       Up         Up                       Unknown              0

        3       6       Up         Up                       Unknown              0

####

UCS02-A /eth-uplink/fabric # show port-channel detail

Port Channel:

    Port Channel Id: 1

    Name:

    Admin State: Enabled

    Oper State: Up

    Speed: 10 Gbps

    Speed: 10 Gbps

    State Reason:

    flow control policy: default

    Port Channel Id: 2

    Name:

    Admin State: Enabled

    Oper State: Up

    Speed: 10 Gbps

    Speed: 10 Gbps

    State Reason:

    flow control policy: default

UCS02-A /eth-uplink/fabric # show port-channel expand

Port Channel:

    Port Channel Id: 1

    Name:

    Admin State: Enabled

    Oper State: Up

    State Reason:

    Member Port:

        Slot Id Port Id Membership Oper State State Reason  Lic State Grace Period

        ------- ------- ---------- ---------- ------------- --------- ------------

        3       3       Up         Up                       Unknown              0

        3       4       Up         Up                       Unknown              0

    Port Channel Id: 2

    Name:

    Admin State: Enabled

    Oper State: Up

    State Reason:

    Member Port:

        Slot Id Port Id Membership Oper State State Reason  Lic State Grace Period

        ------- ------- ---------- ---------- ------------- --------- ------------

        3       5       Up         Up                       Unknown              0

        3       6       Up         Up                       Unknown              0

The VLAN for MetaData is 512

UCS02-A(nxos)# show vlan id 512

VLAN Name                             Status    Ports

---- -------------------------------- --------- -------------------------------

512  VLAN0512                         active    Po1, Po2

Remote SPAN VLAN

----------------

Disabled

Primary  Secondary  Type             Ports

-------  ---------  ---------------  -------------------------------------------

UCS02-B(nxos)# show vlan id 512

VLAN Name                             Status    Ports

---- -------------------------------- --------- -------------------------------

512  VLAN0512                         active    Po1, Po2

Remote SPAN VLAN

----------------

Disabled

Primary  Secondary  Type             Ports

-------  ---------  ---------------  -------------------------------------------

####

UCS02-A(nxos)# show vlan brief

VLAN Name                             Status    Ports

---- -------------------------------- --------- -------------------------------

1    default                          active    Po1, Po2, Eth1/21, Eth1/22

                                                Eth1/23, Eth1/24, Eth1/25

                                                Eth1/26, Eth1/27, Eth1/28

                                                Eth1/29, Eth1/30, Eth1/31

                                                Eth1/32, Eth1/33, Eth1/34

                                                Eth1/35, Eth1/36, Eth1/37

                                                Eth1/38, Eth1/39, Eth1/40

                                                Eth3/1, Eth3/2, Eth1/1/1

                                                Eth1/1/2, Eth1/1/3, Eth1/1/4

                                                Eth1/1/5, Eth1/1/6, Eth1/1/7

                                                Eth1/1/8, Eth2/1/1, Eth2/1/2

                                                Eth2/1/3, Eth2/1/4, Eth2/1/5

                                                Eth2/1/6, Eth2/1/7, Eth2/1/8

                                                Eth3/1/1, Eth3/1/2, Eth3/1/3

                                                Eth3/1/4, Eth3/1/5, Eth3/1/6

                                                Eth3/1/7, Eth3/1/8, Eth4/1/1

                                                Eth4/1/2, Eth4/1/3, Eth4/1/4

                                                Eth4/1/5, Eth4/1/6, Eth4/1/7

                                                Eth4/1/8, Eth5/1/1, Eth5/1/2

                                                Eth5/1/3, Eth5/1/4, Eth5/1/5

                                                Eth5/1/6, Eth5/1/7, Eth5/1/8

                                                Eth6/1/1, Eth6/1/2, Eth6/1/3

                                                Eth6/1/4, Eth6/1/5, Eth6/1/6

                                                Eth6/1/7, Eth6/1/8, Eth7/1/1

                                                Eth7/1/2, Eth7/1/3, Eth7/1/4

                                                Eth7/1/5, Eth7/1/6, Eth7/1/7

                                                Eth7/1/8, Eth8/1/1, Eth8/1/2

                                                Eth8/1/3, Eth8/1/4, Eth8/1/5

                                                Eth8/1/6, Eth8/1/7, Eth8/1/8

                                                Eth9/1/1, Eth9/1/2, Eth9/1/3

                                                Eth9/1/4, Eth9/1/5, Eth9/1/6

                                                Eth9/1/7, Eth9/1/8, Eth10/1/1

                                                Eth10/1/2, Eth10/1/3, Eth10/1/4

                                                Eth10/1/5, Eth10/1/6, Eth10/1/7

                                                Eth10/1/8

2    fcoe-vsan-2                      active    veth11560, veth11568, veth11576

                                                veth11584, veth11592, veth11600

                                                veth11608, veth11616, veth11624

                                                veth11632, veth11640, veth11688

                                                veth11690, veth11706, veth11708

                                                veth11716, veth11718, veth11726

                                                veth11728, veth11736, veth11738

                                                veth11746, veth11748, veth11756

                                                veth11758, veth11766, veth11768

                                                veth11776, veth11784, veth11792

                                                veth11800, veth11808, veth11816

                                                veth11832, veth11840, veth11848

                                                veth11856, veth11864, veth11872

                                                veth11880, veth11888, veth11896

                                                veth11904, veth11912, veth11920

                                                veth11928, veth11936, veth11944

                                                veth11952, veth11960, veth11968

                                                veth11976, veth11984, veth11992

                                                veth12000, veth12008, veth12016

                                                veth12024, veth12032, veth12040

                                                veth12048, veth12056, veth12064

                                                veth12072, veth12080, veth12088

                                                veth12096, veth12104, veth12112

                                                veth12120, veth12128, veth12201

7    VLAN0007                         active    Po1, Po2

10   VLAN0010                         active    Po1, Po2

20   VLAN0020                         active    Po1, Po2

512  VLAN0512                         active    Po1, Po2

4044 SAM-vlan-management              active    Eth1/1/9, Eth2/1/9, Eth3/1/9

                                                Eth4/1/9, Eth5/1/9, Eth6/1/9

                                                Eth7/1/9, Eth8/1/9, Eth9/1/9

                                                Eth10/1/9

4047 SAM-vlan-boot                    active

4048 VLAN4048                         active    Po1, Po2

Totally do not get why this is happening.

Craig

v-crsimp@micros... Mon, 10/17/2011 - 11:01

In the end it was a config error I didn't notice until the update. Had a VLAN not global, but only one one FI. Was nothing todo with the code update.

kg6itcraig Tue, 02/21/2012 - 09:17

2/21/2012

After taking a break to let some code updates roll, ran the 2.0(1w) code update without error. Nice and smooth like usual.

My standard order for code updates.

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)

Craig

roberbur Tue, 02/21/2012 - 09:23

Thanks for the feedback Craig (as always).

Don't forget to update the blade components (Adaptors, BIOS and Board Controllers) after the FIs are completed

Rob

lorenzobexer Thu, 02/23/2012 - 01:52

Hi,

we have a UCS Infrastructure consisting of 2 FI (6120XP) and 2 chassis. We are currently on 1.4(3l) and want to upgrade to UCS 2.0(t).

I think we have a case of VLAN overlapping here, can someone confirm that by this screenshots:

We use B200-M2 Blades with ESXi running on them, and all VM disks + ESXi boot disks are located in the SAN.

So i wondered if it really is such a good idea to change the default VSAN and so disabling the disks of all VMs for a moment. We already had problems with Linux systems setting their filesystem to read-only after a short SAN failure.

Isn't it a better idea to just change the default Ethernet VLAN and to only risk a short network connectivity outage?

Also I'm a little worried by the experience of Craig back in September. Even after the VLAN overlapping was fixed, all of the blades crashed during the upgrade.

That's just something that can't happen to our production environment as it would take weeks to fix all the problems this would cause.

Has this issue been fixed or would it be better to go to the latest 1.4 firmware?

Thanks in advance and Regards

kg6itcraig Fri, 02/24/2012 - 23:20

Yes you are stuck with the overlap issue.

Don't think you can remove/change VLAN 1. It is hardcoded I believe on Cisco.

You are stuck with changing the VSAN to two. UCSM will tell you if a change is going to reboot stuff and you can cancel. We changed for the code update and all servers were off. I don't remember what happened when we changed, sorry. Maybe try the simulator, or just call TAC. TAC has been beaten up quite a good deal over this and has the answers.

1.4m to 2.0(1w) went fine and didn't bother our Hyper-V servers. We don't do ESX. Was a very smooth update. None of the PCI Bus renumbering that caused issues first 2.0 code level appeared.

One bit of worry was blades show to be "Configuring" as each FI/IOM's reboot. But they are up.

Craig

rob.elmes Sat, 02/25/2012 - 09:42

We recently upgrade a test/demo environment from 1.3(1c) to 2.0(1w).  Normal update process followed, but when it came to the Fabrics the first one upgraded ok but the second fabric crashed and wouldn't upgrade.

Raised issue with TAC but we needed to get on with the upgrade, as we only had a short test window on this system, so in the end powered off/on the failed fabric.  This resolved the issue and the fabric upgraded.  TAC have now come back to us with information on the reason.  New bug: CSCty19988.

kg6itcraig Sat, 02/25/2012 - 09:49

Robert Elmes,

Is there anything unique about your environment that caused this? What do you have attached to your FI's? Are you boot from SAN, do you use SAN (and if so what switches are attached), do you have port-channels etc? If you don't mind me asking.

We have a few more UCS's to upgrade in the next few weeks. We try to load our test UCS up with as tricky a configuration as possbile, so it will run into issues the production ones might.

But still, once in a while...

Craig

Actions

Login or Register to take actions

This Discussion

Posted September 20, 2011 at 6:38 AM
Stats:
Replies:41 Avg. Rating:1
Views:5869 Votes:0
Shares:0
Tags: No tags.
Categories: General UCS Hardware
+

Discussions Leaderboard