cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
9962
Views
1
Helpful
41
Replies

2.0 Upgrade

peter.robertson
Level 1
Level 1

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. 

41 Replies 41

v-crsimp
Level 1
Level 1

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
Level 1
Level 1

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.

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

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

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

==> 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?

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
Level 1
Level 1

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

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

No, I am not using vNIC / vHBA placement policies.

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.

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.

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

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?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: