Cisco Nexus 1000v Standalone VSM upgrade to Release 4.2(1) SV1(4)

Cisco Nexus team released the update to the Nexus 1000v product taking it to release 4.2(1) SV1(4). They did a great job of documenting the entire upgrade process both in docs and in a series of screencasts. Check it out it’s really worth your time.

However one obvious thing that they have missed so far is how to upgrade if your VSM is in standalone mode. Part of the problem is the Upgrade application (GUI) does not support standalone mode and the upgrade document does not address the manual upgrade (CLI) method for standalone VSM.

Here is a quick guide on how to upgrade your standalone VSM from 4.0(4) SV1(3, 3a, or 3b) to 4.2(1) SV1(4).

Before you start make sure you have run the pre-upgrade check script against your 1000v configuration to make sure you don’t run into the 7 configurations that are incompatible with Nexus 4.0.x to 4.2.x code.

Now the actual steps:

Step 0 Do a show mod and make sure you have already upgraded all the VEM modules. Remember this has changed from earlier releases. You HAVE to upgrade the VEM first and VSM second to upgrade to release 4.2(1) SV1(4).

show mod
Mod  Ports  Module-Type                       Model               Status
---  -----  --------------------------------  ------------------  ------------
1    0      Virtual Supervisor Module         Nexus1000V          active *
3    248    Virtual Ethernet Module           NA                  ok
4    248    Virtual Ethernet Module           NA                  ok
5    248    Virtual Ethernet Module           NA                  ok
6    248    Virtual Ethernet Module           NA                  ok

Mod  Sw                Hw
---  ----------------  ------------------------------------------------
1    4.0(4)SV1(3b)      0.0
3    4.2(1)SV1(4)      VMware ESXi 4.1.0 Releasebuild-320137 (2.0)
4    4.2(1)SV1(4)      VMware ESXi 4.1.0 Releasebuild-320137 (2.0)
5    4.2(1)SV1(4)      VMware ESXi 4.1.0 Releasebuild-320137 (2.0)
6    4.2(1)SV1(4)      VMware ESXi 4.1.0 Releasebuild-320137 (2.0)

Mod  MAC-Address(es)                         Serial-Num
---  --------------------------------------  ----------
1    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA
3    02-00-0c-00-03-00 to 02-00-0c-00-03-80  NA
4    02-00-0c-00-04-00 to 02-00-0c-00-04-80  NA
5    02-00-0c-00-05-00 to 02-00-0c-00-05-80  NA
6    02-00-0c-00-06-00 to 02-00-0c-00-06-80  NA

Mod  Server-IP        Server-UUID                           Server-Name
---  ---------------  ------------------------------------  --------------------
1    172.16.165.55    NA                                    NA
3    172.16.165.91    dcedbaac-1dc0-11df-0000-00000000000e  172.16.165.91
4    172.16.165.92    dcedbaac-1dc0-11df-0000-00000000000d  172.16.165.92
5    172.16.165.93    dcedbaac-1dc0-11df-0000-00000000000c  172.16.165.93
6    172.16.165.94    dcedbaac-1dc0-11df-0000-00000000000b  172.16.165.94

Step 1 Copy the new software release system image and kickstart image files to the bootflash file system of the VSM.

switch# copy scp:root@172.16.165.51/srv/n1kv-images/nexus-1000v-mz.4.2.1.SV1.4.bin bootflash:
switch# copy scp:root@172.16.165.51/srv/n1kv-imagess/nexus-1000v-kickstart.mz.4.2.1.SV1.4.bin bootflash:

Step 2 Use the install all command to update the boot variables to release 4.2(1)SV1(4) images.

switch# install all system bootflash: nexus-1000v-mz.4.2.1.SV1.4.bin kickstart bootflash:nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin
Boot variables are updated to running configuration.

Step 3 Save your configuration by copying the running configuration to the startup configuration.

switch# copy running-config startup-config
[########################################] 100%

Step 4 Reload VSM.

switch# reload
This command will reboot the system. (y/n)? [n] y
switch#show mod
Mod  Ports  Module-Type                       Model               Status
---  -----  --------------------------------  ------------------  ------------
1    0      Virtual Supervisor Module         Nexus1000V          active *
3    248    Virtual Ethernet Module           NA                  ok
4    248    Virtual Ethernet Module           NA                  ok
5    248    Virtual Ethernet Module           NA                  ok
6    248    Virtual Ethernet Module           NA                  ok

Mod  Sw                Hw
---  ----------------  ------------------------------------------------
1    4.2(1)SV1(4)      0.0
3    4.2(1)SV1(4)      VMware ESXi 4.1.0 Releasebuild-320137 (2.0)
4    4.2(1)SV1(4)      VMware ESXi 4.1.0 Releasebuild-320137 (2.0)
5    4.2(1)SV1(4)      VMware ESXi 4.1.0 Releasebuild-320137 (2.0)
6    4.2(1)SV1(4)      VMware ESXi 4.1.0 Releasebuild-320137 (2.0)

Mod  MAC-Address(es)                         Serial-Num
---  --------------------------------------  ----------
1    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA
3    02-00-0c-00-03-00 to 02-00-0c-00-03-80  NA
4    02-00-0c-00-04-00 to 02-00-0c-00-04-80  NA
5    02-00-0c-00-05-00 to 02-00-0c-00-05-80  NA
6    02-00-0c-00-06-00 to 02-00-0c-00-06-80  NA

Mod  Server-IP        Server-UUID                           Server-Name
---  ---------------  ------------------------------------  --------------------
1    172.16.165.55    NA                                    NA
3    172.16.165.91    dcedbaac-1dc0-11df-0000-00000000000e  172.16.165.91
4    172.16.165.92    dcedbaac-1dc0-11df-0000-00000000000d  172.16.165.92
5    172.16.165.93    dcedbaac-1dc0-11df-0000-00000000000c  172.16.165.93
6    172.16.165.94    dcedbaac-1dc0-11df-0000-00000000000b  172.16.165.94

That’s it the VSM upgrade is complete to 4.2(1)SV1(4).

As an aside. These steps compare extremely well when contrasted with the HA based VSM manual upgrade which is 22+ steps. I actually had the VSMs in a HA pair and deleted the secondary, upgraded the primary as a standalone and deployed a new 4.2(1)SV1(4) VSM VM using the OVF files and powered it up and called it secondary and it happily synced with the primary and the upgrade is complete.

10 comments

  1. Nice job on this..question. When you deleted the secondary VSM, did you go back to Primary VSM and change its HA redundancy role to standalone, rebooted, then did the upgrade, then changed the redundancy role back to Primary?

    1. That step is not required for an manual upgrade.. it is safe to delete the secondary and deploy another VSM and add it to the HA pair. And that is all you are doing, if you are following this guide.

  2. Hi Jay,

    I just wanted to let you know how the second try went on december the 25th. I waited (untill now) because i wanted to post the solution or at least the reason for the partial config loss, however i am still talking to Cisco TAC about this.

    As expected the same thing occured the 25th again, but the partial config loss was now only the following:
    – the management address (strictly it was there, but the line “interface mgmt0” was missing, so the management address was “floating” as TAC called it)
    – the “sub-group id” command was gone again on all the phisical interfaces from the VEM’s, however i was prepared for it and close to zero downtime this time:-)

    I made extensive logfiles and backups of startup-config and running-config files during all steps and sent them to the TAC engineers. So we are now still waiting for the final conclusion but our upgrade succeeded and we can now upgrade our vSphere to version 5 and implement the Cisco UCS and 1000v best practises.

    Thank you for sharing your thoughts with me, sticking your neck out and linking me to a TAC support engineer!

    Marcel

    1. Hi Jay,

      Last week i was informed by Cisco TAC that after multiple attempts they were finally able to recreate the issue and is now filed as a software defect. Cisco engineering is contacted to debug the faulty setup and to investigate the root cause.

      I just wanted to let you know the current status.

      Marcel

      1. Hi Marcel,

        Thanks for the update. I did follow up with the team and they have already identified the root cause the the fix should be available in the next update release (4b) release.

Leave a Reply