Cisco Nexus 1000V Software Upgrade Guide, Release 4.0(4) SV1(3d)

Available Languages

Download Options

  • PDF     (393.5 KB)
    View with Adobe Reader on a variety of devices
Updated:May 20, 2011

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Cisco Nexus 1000V Software Upgrade Guide, Release 4.0(4)SV1(3d)

Table Of Contents

Cisco Nexus 1000V Software Upgrade Guide, Release 4.0(4)SV1(3d)

Audience

Obtaining the Software

Information About the Software Upgrade

Upgrading the VSMs

Prerequisites to Upgrading the VSMs

Upgrading the VSM from Release 4.0(4)SV1(2, 3, 3a, 3b, or 3c) to Release 4.0(4)SV1(3d)

Upgrading the VSM from Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d)

Upgrading the VEMs

Prerequisites to Upgrading VEMs

Upgrading the VEMs from Release 4.0(2)SV1(2) or Release 4.0(2)SV1(3) to Release 4.0(4)SV1(3d)

Upgrading the VEMs Using VMware Update Manager (VUM) to Release 4.0(4)SV1(3d)

Upgrading the VEMs Manually to Release 4.0(4)SV1(3d)

Upgrading the VEMs from Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d)

Upgrading the VEMs Using VMware Update Manager (VUM): Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d)

Upgrading the VEMs Manually: Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d)

Changing the Feature Support Level

Prerequisites to Changing the Feature Support Level

Changing the Feature Support Level

Accepting the VEM Upgrade in the vCenter Client

Prerequisites to Accepting the VEM Upgrade

Accepting the VEM Upgrade

Troubleshooting

Non-default (Jumbo) MTU Settings Symptoms and Solutions

Available Documents

Obtaining Documentation and Submitting a Service Request


Cisco Nexus 1000V Software Upgrade Guide, Release 4.0(4)SV1(3d)

Revised: May 21, 2011
OL-23099-01 D0

This document describes how to upgrade the Cisco Nexus 1000V software on a Virtual Supervisor Module (VSM) virtual machine (VM) and includes the following topics:

•Audience

•Obtaining the Software

•Information About the Software Upgrade

•Upgrading the VSMs

•Upgrading the VEMs

•Changing the Feature Support Level

•Accepting the VEM Upgrade in the vCenter Client

•Troubleshooting

•Available Documents

•Obtaining Documentation and Submitting a Service Request

Audience

This guide is for network administrators and server administrators with the following experience and knowledge:

•An understanding of virtualization

•Using VMware tools to create a virtual machine and configure a vSwitch

•A basic understanding of the following:

–Cisco NX-OS based CLI

–VMware ESX/ESXi

–VMware Update Manager

–Cisco Nexus 1000V DVS setup and implementation

For more information about Cisco Nexus 1000V setup and implementation, see the Cisco Nexus 1000V Getting Started Guide, Release 4.0(4)SV1(3).

Obtaining the Software

You can obtain your upgrade-related software from the following sources (Table 1):

Table 1 Obtaining Software

Source
Description

Cisco

Download the Cisco Nexus 1000V Release 4.0(4)SV1(3d) software from the Cisco website.

VMware

Download VMware software from VMware website.


For information about your software and platform compatibility, see the Cisco Nexus 1000V Compatibility Information, Release 4.0(4)SV1(3d).

Information About the Software Upgrade

Note You cannot upgrade from Release 4.2(1)SV1(4) to Release 4.0(4)SV1(3d).

Caution If the VMware vCenter Server is hosted on the same ESX host as a Cisco Nexus 1000V VEM, then a VUM assisted upgrade on the host will fail. You should manually vMotion the VM to another host before performing the upgrade.

This section provides information about the software upgrade.

•A software upgrade consists of adding a new software version first to the Cisco Nexus 1000V VSM and then to its Virtual Ethernet Modules (VEMs). The sequence to upgrade the software is as follows:

–Upgrading the VSMs

–Upgrading the VEMs

This section describes important points about the software upgrade:

•There are two methods of upgrading the software: the non-disruptive method and the disruptive method. An upgrade is non-disruptive or disruptive based on the version of your setup and also the method that you choose for upgrading. An ESX is termed as going through an upgrade when it is connected to a VSM during the upgrade procedure.

An automated upgrade is traffic non-disruptive when you install one of the following:

–VMware patch ESX400/ESXi400-201002001 or the ESX400/ESXi400-201006201-UG or later on the host, and also use VMware vCenter Update Manager 4.0 Update 1 Patch 2, vCLI build 198790, and VSM Release 4.0(4)SV1(2) or later.

Note Even if your ESX/ESXi host has patches greater than ESX/ESXi400-201002001, without installing ESX/ESXi400-201002001 or ESX400/ESXi400-201006201-UG, a non-disruptive upgrade is not supported.

Note Any ESX patches or updates after ESX400/ESXi400-201006201-UG will be backward compatible with the Cisco Nexus 1000V U2 VEM vib (cross_cisco-vem_v121-4.0.4.1.3.1.0-1.20.2.vib).

–VMware release ESX410/ESXi410 on the host, and also use VMware vCenter Update Manager 4.1 and VSM Release 4.0(4)SV1(3).

A manual upgrade is traffic non-disruptive when the following conditions are met: While each vSphere host is attached to the Distributed virtual switch (DVS), migrate any running VMs to another host within the cluster. (As the VSM Release 4.0(4)SV1(1) cannot be Vmotioned, it must be powered off.) Place the host in maintenance mode and upgrade the VEMs. Follow the same method for other hosts in the data center.

Note For details about how to determine what patch level you are using, refer to the Cisco Nexus 1000V Compatibility Information, Release 4.0(4)SV1(3d).

•Cisco does not support simultaneous VMware updates or patches in combination with Nexus 1000V upgrades. This document is designed specifically for Nexus 1000V upgrades across the same VMware platform.

•The upgrade process is irrevocable. After the software is upgraded, you can downgrade by removing the current installation and reinstalling the software. For details, see the "Recreating the Installation" section in the following document:

–Cisco Nexus 1000V Troubleshooting Guide, Release 4.0(4)SV1(3).

Caution During the upgrade process, the Cisco Nexus 1000V does not support new additions of any vNICs, vmnics, or new modules and does not support any configuration changes. vNIC port-profile changes might render the vNIC in an unusable state.

•If you are using a proxy server to connect the VMware Update Manager (VUM) to the Internet, you may need to disable the proxy before starting a VUM upgrade of your VEMs. In VMware versions before the VUM Update 1, the proxy prevents the VUM from communicating locally with the VSM. Therefore, automatic VEM upgrades may fail if the proxy is not disabled first.

•When you upgrade from Release 4.0(4)SV1(3) or Release 4.0(4)SV1(3a) to Release 4.0(4)SV1(3d), licenses apply as follows:

–On a Release 4.0(4)SV1(3) or Release 4.0(4)SV1(3a) VSM, you can install evaluation license files. If these evaluation licenses have not yet expired prior to the upgrade to Release 4.0(4)SV1(3d), these will be carried over after the upgrade to Release 4.0(4)SV1(3d) as is.

–The Release 4.0(4)SV1(3) or Release 4.0(4)SV1(3a) VSM has support for default/built-in evaluation licenses for 16 CPU sockets for a period of 60 days. If these default/built-in evaluation licenses have not yet expired before the upgrade to Release 4.0(4)SV1(3d), these will be carried over after upgrade to Release 4.0(4)SV1(3d) as is.

–Any permanent licenses installed on a Release 4.0(4)SV1(3) or Release 4.0(4)SV1(3a) VSM will be carried over after upgrade to Release 4.0(4)SV1(3d) as is.

•When you upgrade from Release 4.0(4)SV1(2) to Release 4.0(4)SV1(3d), licenses apply as follows:

–On a Release 4.0(4)SV1(2) VSM, you cannot install evaluation license files.

–The Release 4.0(4)SV1(2) VSM has support for default/built-in evaluation licenses for 16 CPU sockets for a period of 60 days. If these default/built-in evaluation licenses have not yet expired before the upgrade to Release 4.0(4)SV1(3d), these will be carried over after upgrade to Release 4.0(4)SV1(3d) as is.

–Any permanent licenses installed on a Release 4.0(4)SV1(2) VSM will be carried over after upgrade to Release 4.0(4)SV1(3d) as is.

•When you upgrade from Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d), licenses apply as follows:

–On a Release 4.0(4)SV1(1) VSM, you can install evaluation license files. If these evaluation licenses have not yet expired prior to the upgrade to Release 4.0(4)SV1(3d), these will be carried over after the upgrade to Release 4.0(4)SV1(3d) as is.

–Any permanent licenses installed on a Release 4.0(4)SV1(1) VSM will be carried over after upgrade to Release 4.0(4)SV1(3d) as is.

For more licensing details, see the Cisco Nexus 1000V License Configuration Guide, Release 4.0(4)SV1(3).

Upgrading the VSMs

This section describes the VSM upgrade steps. The following upgrade methods are described in the following topics:

•Prerequisites to Upgrading the VSMs

•Upgrading the VSM from Release 4.0(4)SV1(2, 3, 3a, 3b, or 3c) to Release 4.0(4)SV1(3d)

•Upgrading the VSM from Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d)

Prerequisites to Upgrading the VSMs

The following are prerequisites to upgrading the VSM:

•You are upgrading the Cisco Nexus 1000V software to Release 4.0(4)SV1(3d).

•Network and server administrators coordinate the upgrade procedure with each other.

•The following files are available in external storage that you can access from the VSM.

–nexus-1000v-mz.4.0.4.SV1.3d.bin

–nexus-1000v-kickstart-mz.4.0.4.SV1.3d.bin

•You have saved all changes in the running configuration to the startup configuration to be preserved through the upgrade.

•You have saved a backup copy of the running configuration in external storage.

For information about backing up a configuration file, see the Cisco Nexus 1000V System Management Configuration Guide, Release 4.0(4)SV1(3).

Upgrading the VSM from Release 4.0(4)SV1(2, 3, 3a, 3b, or 3c) to Release 4.0(4)SV1(3d)

This section describes the VSM upgrade to Release 4.0(4)SV1(3d).

Note For example purposes, the following procedure reflects an upgrade from Release 4.0(4)SV1(3) to Release 4.0(4)SV1(3d).

Note This procedure is performed by the network administrator.

To perform a VSM software upgrade to Release 4.0(4)SV1(3d), follow these steps:

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

switch# dir bootflash:

        154     Jan 27 15:21:06 2010  .ovfconfigured

      77824     Mar 03 07:31:09 2010  accounting.log

      16384     Dec 09 13:56:23 2009  lost+found/

   21408768     Dec 09 13:57:21 2009  nexus-1000v-kickstart-mz.4.0.4.SV1.3.bin

   73068811     Dec 09 13:57:32 2009  nexus-1000v-mz.4.0.4.SV1.3.bin

       4096     Dec 09 13:58:18 2009  vdc_2/

       4096     Dec 09 13:58:18 2009  vdc_3/

       4096     Dec 09 13:58:18 2009  vdc_4/

 

Usage for bootflash://sup-local

  249647552 bytes used

 2138623552 bytes free

 2388271104 bytes total

 

switch# copy scp://root@10.78.27.167/N1K-VSM-images/nexus-1000v-mz.4.0.4.SV1.3d.bin 
bootflash:

Enter vrf (If no input, current vrf 'default' is considered):

root@10.78.27.167's password:

nexus-1000v-mz.4.0.4.SV1.3d.bin                                         100%   20MB   
1.1MB/s   00:19

switch#

 

switch# copy 
scp://root@10.78.27.167/N1K-VSM-images/nexus-1000v-kickstart-mz.4.0.4.SV1.3d.bin 
bootflash:

Enter vrf (If no input, current vrf 'default' is considered):

root@10.78.27.167's password:

nexus-1000v-kickstart-mz.4.0.4.SV1.3d.bin                                         100%   
20MB   1.1MB/s   00:19

switch#

 

switch# dir bootflash:

        154     Jan 27 15:21:06 2010  .ovfconfigured

      77824     Mar 03 07:31:09 2010  accounting.log

      16384     Dec 09 13:56:23 2009  lost+found/

   21408768     Dec 09 13:57:21 2009  nexus-1000v-kickstart-mz.4.0.4.SV1.3.bin

   21982208     Jul 08 18:28:58 2010  nexus-1000v-kickstart-mz.4.0.4.SV1.3d.bin

   73068811     Dec 09 13:57:32 2009  nexus-1000v-mz.4.0.4.SV1.3.bin

   62280256     Jul 08 18:29:35 2010  nexus-1000v-mz.4.0.4.SV1.3d.bin

       4096     Dec 09 13:58:18 2009  vdc_2/

       4096     Dec 09 13:58:18 2009  vdc_3/

       4096     Dec 09 13:58:18 2009  vdc_4/

 

Usage for bootflash://sup-local

  333910016 bytes used

 2054361088 bytes free

 2388271104 bytes total

Step 2 Use the install all command to copy the Release 4.0(4)SV1(3d) images to both active and standby VSMs and to update the boot variables.

Note If available, you can obtain the software images from an outside repository and copy it using the install all command. 

switch# install all system bootflash:nexus-1000v-mz.4.0.4.SV1.3d.bin kickstart 
bootflash:nexus-1000v-kickstart-mz.4.0.4.SV1.3d.bin

System image sync to standby is in progress...

System image is synced to standby.

Kickstart image sync to Standby is in progress...

Kickstart image is synced to standby.

Boot variables are updated to running configuration.

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

switch# copy r s

[########################################] 100%

Step 4 Verify that your configuration is saved. 

switch# show startup-config | include boot

boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3d.bin sup-1

boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3d.bin sup-1

boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3d.bin sup-2

boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3d.bin sup-2


switch# show running-config | include boot

boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3d.bin sup-1

boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3d.bin sup-1

boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3d.bin sup-2

boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3d.bin sup-2

Step 5 Verify the VSM active and standby module status. 

switch# show mod

Mod  Ports  Module-Type                      Model              Status

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

1    0      Virtual Supervisor Module        Nexus1000V         active *

2    0      Virtual Supervisor Module        Nexus1000V         ha-standby

3    248    Virtual Ethernet Module          NA                 ok

4    248    Virtual Ethernet Module          NA                 ok


Mod  Sw               Hw 

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

1    4.0(4)SV1(3)     0.0 

2    4.0(4)SV1(3)     0.0 

3    4.0(4)SV1(3)     1.11 

4    4.0(4)SV1(3)     1.11 


Mod  MAC-Address(es)                         Serial-Num

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

1    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA 

2    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 


Mod  Server-IP        Server-UUID                           Server-Name

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

1    10.78.109.100    NA                                    NA

2    10.78.109.100    NA                                    NA

3    10.78.109.104    1ee15784-f2e8-383e-8132-9026577ca1bb  10.78.109.104

4    10.78.109.102    44454c4c-4700-104e-804d-cac04f563153  10.78.109.102

Note The line with the bold characters in the preceding example displays that the VSM module 2 is at Release 4.0(4)SV1(3).

Step 6 Reload the standby VSM.

Use module 2 in the following example because module 2 is the standby module. After reloading the standby VSM, the active VSM that is running software release 4.0(4)SV1(3), synchronizes with the standby VSM running Release 4.0(4)SV1(3d). 

switch# reload module 2

This command will reboot standby supervisor module. (y/n)?  [n] y 

about to reset standby sup

switch# 2010 Jul 08 09:57:42 n1000v %PLATFORM-2-PFM_MODULE_RESET: Manual restart of Module 
2 from Command Line Interface

2010 Jul 08 09:57:49 n1000v %PLATFORM-2-MOD_REMOVE: Module 2 removed (Serial number 
T5056972D88)

2010 Jul 08 09:57:53 n1000v %(0x436D) for service "netstack" (PID 3176): Connection timed 
out (110).

Note A few sequence failures might be displayed with the preceding message. This is expected and you can ignore it.

Step 7 Verify the VSM active and standby module status and software release version. 

switch# show mod

Mod  Ports  Module-Type                      Model              Status

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

1    0      Virtual Supervisor Module        Nexus1000V         active *

2    0      Virtual Supervisor Module        Nexus1000V         ha-standby

3    248    Virtual Ethernet Module          NA                 ok

4    248    Virtual Ethernet Module          NA                 ok


Mod  Sw               Hw 

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

1    4.0(4)SV1(3)     0.0 

2    4.0(4)SV1(3d)    0.0 

3    4.0(4)SV1(3)     1.11 

4    4.0(4)SV1(3)     1.11 


Mod  MAC-Address(es)                         Serial-Num

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

1    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA 

2    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 


Mod  Server-IP        Server-UUID                           Server-Name

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

1    10.78.109.100    NA                                    NA

2    10.78.109.100    NA                                    NA

3    10.78.109.104    1ee15784-f2e8-383e-8132-9026577ca1bb  10.78.109.104

4    10.78.109.102    44454c4c-4700-104e-804d-cac04f563153  10.78.109.102

* this terminal session

Note The lines with the bold characters in the preceding example, after the reload, display the active and standby modules and that VSM module 2, the standby module, is upgraded to Release 4.0(4)SV1(3d).

Step 8 Enter the system switchover command at the active VSM to force the standby VSM to become active and to reload the active VSM. 

switch# system switchover

When the modules are switched over, the primary module reloads and returns as the standby VSM with the new software version.

Step 9 Verify the system switchover.

In the following example, module 2 is the active module and module 1 is now the standby module. 

switch#  show mod

Mod  Ports  Module-Type                      Model              Status

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

1    0      Virtual Supervisor Module        Nexus1000V         ha-standby

2    0      Virtual Supervisor Module        Nexus1000V         active *

3    248    Virtual Ethernet Module          NA                 ok

4    248    Virtual Ethernet Module          NA                 ok


Mod  Sw               Hw 

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

1    4.0(4)SV1(3d)    0.0 

2    4.0(4)SV1(3d)    0.0 

3    4.0(4)SV1(3)     1.11 

4    4.0(4)SV1(3)     1.11 


Mod  MAC-Address(es)                         Serial-Num

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

1    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA 

2    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 


Mod  Server-IP        Server-UUID                           Server-Name

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

1    10.78.109.100    NA                                    NA

2    10.78.109.100    NA                                    NA

3    10.78.109.104    1ee15784-f2e8-383e-8132-9026577ca1bb  10.78.109.104

4    10.78.109.102    44454c4c-4700-104e-804d-cac04f563153  10.78.109.102

* this terminal session

Note The line with the bold characters in the preceding example displays that the VSM module 1 is upgraded to Release 4.0(4)SV1(3d).
To change to the original status of module 1 as the active module and module 2 as the standby module, use the system switchover command one more time.

Step 10 (Optional) If you have configured non-default (jumbo) MTU settings, see the "Non-default (Jumbo) MTU Settings Symptoms and Solutions" section before proceeding with VEM upgrades.

Step 11 Proceed to upgrade the VEMs.

For details, see the "Upgrading the VEMs" section.

Upgrading the VSM from Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d)

This section describes the VSM upgrade from Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d).

To perform a VSM software upgrade from Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d), follow these steps:

Note This procedure is performed by the network administrator.

Step 1 Power off all VMs except the VSM.

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

switch# dir bootflash:

        154     Jan 27 15:21:06 2010  .ovfconfigured

      77824     Mar 03 07:31:09 2010  accounting.log

      16384     Dec 09 13:56:23 2009  lost+found/

   21408768     Dec 09 13:57:21 2009  nexus-1000v-kickstart-mz.4.0.4.SV1.1.bin

   73068811     Dec 09 13:57:32 2009  nexus-1000v-mz.4.0.4.SV1.1.bin

       4096     Dec 09 13:58:18 2009  vdc_2/

       4096     Dec 09 13:58:18 2009  vdc_3/

       4096     Dec 09 13:58:18 2009  vdc_4/

 

Usage for bootflash://sup-local

  249647552 bytes used

 2138623552 bytes free

 2388271104 bytes total

 

switch#copy scp://root@10.78.27.167/N1K-VSM-images/nexus-1000v-mz.4.0.4.SV1.3d.bin 
bootflash:

Enter vrf (If no input, current vrf 'default' is considered):

root@10.78.27.167's password:

nexus-1000v-mz.4.0.4.SV1.3d.bin                                         100%   20MB   
1.1MB/s   00:19

switch#

 

switch# copy 
scp://root@10.78.27.167/N1K-VSM-images/nexus-1000v-kickstart-mz.4.0.4.SV1.3d.bin 
bootflash:

Enter vrf (If no input, current vrf 'default' is considered):

root@10.78.27.167's password:

nexus-1000v-kickstart-mz.4.0.4.SV1.3d.bin                                         100%   
20MB   1.1MB/s   00:19

switch#

 

switch# dir bootflash:

        154     Jan 27 15:21:06 2010  .ovfconfigured

      77824     Mar 03 07:31:09 2010  accounting.log

      16384     Dec 09 13:56:23 2009  lost+found/

   21408768     Dec 09 13:57:21 2009  nexus-1000v-kickstart-mz.4.0.4.SV1.1.bin

   21982208     Jan 21 18:28:58 2010  nexus-1000v-kickstart-mz.4.0.4.SV1.3d.bin

   73068811     Dec 09 13:57:32 2009  nexus-1000v-mz.4.0.4.SV1.1.bin

   62280256     Jan 21 18:29:35 2010  nexus-1000v-mz.4.0.4.SV1.3d.bin

       4096     Dec 09 13:58:18 2009  vdc_2/

       4096     Dec 09 13:58:18 2009  vdc_3/

       4096     Dec 09 13:58:18 2009  vdc_4/

 

Usage for bootflash://sup-local

  333910016 bytes used

 2054361088 bytes free

 2388271104 bytes total

Step 3 Remove the existing system boot variable and kickstart boot variable. 

switch# config t

switch(config)# no boot system

switch(config)# no boot kickstart

switch(config)#

Step 4 Add the new system boot variable and kickstart boot variable. 

switch(config)# boot system bootflash:nexus-1000v-mzg.4.0.4.SV1.3d.bin

2009 Dec 13 15:50:40.568 n1k-av %BOOTVAR-5-IMAGE_NOTEXISTS: Warning: image 
nexus-1000v-mz.4.0.4.SV1.3d.bin doesn't exist on sup2

2009 Dec 13 15:51:28.236 n1k-av %BOOTVAR-5-AUTOCOPY_SUCCEED: auto-copy of file 
/bootflash/nexus-1000v-mz.4.0.4.SV1.3d.bin to standby supervisor succeed

switch(config)# 

switch(config)# boot kickstart bootflash:nexus-1000v-kickstart-mzg.4.0.4.SV1.3d.bin

2009 Dec 13 15:54:03.093 n1k-av %BOOTVAR-5-IMAGE_NOTEXISTS: Warning: image 
nexus-1000v-kickstart-mz.4.0.4.SV1.3d.bin doesn't exist on sup2

2009 Dec 13 15:54:20.966 n1k-av %BOOTVAR-5-AUTOCOPY_SUCCEED: auto-copy of file 
/bootflash/nexus-1000v-kickstart-mz.4.0.4.SV1.3d.bin to standby supervisor succeed

switch(config)#

Note With dual VSMs, if boot auto-copy is enabled (the default), and terminal monitor is enabled, the image is also copied to the standby VSM. Wait for the second log message to appear before proceeding with the next step.

Caution If you are upgrading dual VSMs, then before you reload the software, make sure that the bootflash file system for the standby VSM has system and kickstart image files that are identical to those in the active VSM. If they are not identical, then the only way to recover the standby VSM is to create a new one from the ISO image and point it to the active VSM.

Step 5 Save the running configuration persistently through reboots and restarts by copying it to the startup configuration. 

switch(config)# copy running-config startup-config

[########################################] 100%

switch(config)#

Step 6 Verify that your configuration is saved. 

switch# show startup-config | include boot

boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3d.bin sup-1

boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3d.bin sup-1

boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3d.bin sup-2

boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3d.bin sup-2


switch# show running-config | include boot

boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3d.bin sup-1

boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3d.bin sup-1

boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3d.bin sup-2

boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3d.bin sup-2

Step 7 Verify the VSM active and standby module status. 

switch# show mod

Mod  Ports  Module-Type                      Model              Status

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

1    0      Virtual Supervisor Module        Nexus1000V         active *

2    0      Virtual Supervisor Module        Nexus1000V         ha-standby

3    248    Virtual Ethernet Module          NA                 ok

4    248    Virtual Ethernet Module          NA                 ok


Mod  Sw               Hw 

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

1    4.0(4)SV1(1)     0.0 

2    4.0(4)SV1(1)     0.0 

3    4.0(4)SV1(1)     1.11 

4    4.0(4)SV1(1)     1.11 


Mod  MAC-Address(es)                         Serial-Num

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

1    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA 

2    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 


Mod  Server-IP        Server-UUID                           Server-Name

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

1    10.78.109.100    NA                                    NA

2    10.78.109.100    NA                                    NA

3    10.78.109.104    1ee15784-f2e8-383e-8132-9026577ca1bb  10.78.109.104

4    10.78.109.102    44454c4c-4700-104e-804d-cac04f563153  10.78.109.102

Note The lines with the bold characters in the preceding example display that VSM modules 1 and 2 are at Release 4.0(4)SV1(1).

Step 8 Reload the VSM. 

switch# reload

This command will reboot the system. (y/n)? [n] y

switch#

The upgraded VSMs start up with the new software version.

Step 9 Verify that the VSMs are upgraded. 

switch#  show mod

Mod  Ports  Module-Type                      Model              Status

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

1    0      Virtual Supervisor Module        Nexus1000V         active *

2    0      Virtual Supervisor Module        Nexus1000V         ha-standby

3    248    Virtual Ethernet Module          NA                 ok

4    248    Virtual Ethernet Module          NA                 ok


Mod  Sw               Hw 

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

1    4.0(4)SV1(3d)     0.0 

2    4.0(4)SV1(3d)     0.0 

3    4.0(4)SV1(1)     1.11 

4    4.0(4)SV1(1)     1.11 


Mod  MAC-Address(es)                         Serial-Num

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

1    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA 

2    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 


Mod  Server-IP        Server-UUID                           Server-Name

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

1    10.78.109.100    NA                                    NA

2    10.78.109.100    NA                                    NA

3    10.78.109.104    1ee15784-f2e8-383e-8132-9026577ca1bb  10.78.109.104

4    10.78.109.102    44454c4c-4700-104e-804d-cac04f563153  10.78.109.102

* this terminal session

Note The lines with the bold characters in the preceding example display that VSM modules 1 and 2 are upgraded to Release 4.0(4)SV1(3d).

Step 10 (Optional) If you have configured non-default (jumbo) MTU settings, see the "Non-default (Jumbo) MTU Settings Symptoms and Solutions" section before proceeding with VEM upgrades.

Step 11 Proceed to upgrade the VEMs.

For details, see the "Upgrading the VEMs" section.

Upgrading the VEMs

This section lists important points about the VEM upgrade and describes the VEM upgrade process including the following topics:

•Prerequisites to Upgrading VEMs

•Upgrading the VEMs from Release 4.0(2)SV1(2) or Release 4.0(2)SV1(3) to Release 4.0(4)SV1(3d)

•Upgrading the VEMs from Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d)

Before upgrading the VEMs, note the following important points:

•The VEM upgrade starts when it is attached to the VSM. During the upgrade process, VEMs re-attach to the VSM.

•VEM software can be upgraded manually using the CLI, or upgraded automatically using VUM. VSM software can control and configure older VEM versions while continuing to support all features in the previous software version.

•To achieve a non-disruptive manual VEM upgrade, from Release 4.0(4)SV1(2) to 4.2(1)SV1(4), the user must vMotion the VMs out of the host that is to be upgraded, and then perform the VEM upgrade. If you are using VUM with the compatible ESX version as shown in the Cisco Nexus 1000V Compatibility Information, Release 4.0(4)SV1(3d) document, the host is automatically put in maintenance mode.

An automated upgrade is traffic non-disruptive when you install one of the following:

–VMware patch ESX/ESXi400-201002001 or the ESX/ESXi400-201006201-UG on the host, and also use VMware vCenter Update Manager 4.0 Update 1 Patch 2, vCLI build 198790, and VSM Release 4.0(4)SV1(2) or later.

Note Even if your ESX/ESXi host has patches greater than ESX/ESXi400-201002001, without installing ESX/ESXi400-201002001, a non-disruptive upgrade is not supported.

–VMware release ESX/ESXi410 on the host, VMware vCenter Update Manager 4.1, and VSM Release 4.0(4)SV1(3).

•Connectivity to the VSM can be lost during a VEM upgrade when the interfaces of a VSM VM connect to its own DVS.

•Connectivity between an active and standby VSM can be lost during a VEM upgrade when the VEM being upgraded provides interface connectivity to one of the VSMs. In this case, both VSMs become active and lose connectivity. To prevent this, use the following workaround:

–Before upgrading the VEM, power off the VSM provided with interface connectivity. The other VSM should be active. If you power off the active VSM, then the standby VSM will become active.

–Manually upgrade the VEM providing the interface connectivity.

–Restart the VSM that was shut down.

•If you are upgrading VEM using a Cisco Nexus 1000V bundle, follow instructions in your VMware documentation. For more details about VMware bundled software, see the Cisco Nexus 1000V Compatibility Information, Release 4.0(4)SV1(3d).

Caution Do not type the vemlog, vemcmd, or vempkt commands during the VEM upgrade process as it may impact the upgrade.

Prerequisites to Upgrading VEMs

The following are prerequisites to upgrading the VEMs:

•You are logged in to the VSM CLI in EXEC mode.

•You have already upgraded the VSM to the new software version.

•Network and server administrators coordinate the VEM upgrade with each other.

•Refer to Cisco Nexus 1000V Compatibility Information, Release 4.0(4)SV1(3d) for compatible versions of the VMware vCenter and VUM software.

Upgrading the VEMs from Release 4.0(2)SV1(2) or Release 4.0(2)SV1(3) to Release 4.0(4)SV1(3d)

This section describes the steps to upgrade VEMs to Release 4.0(4)SV1(3d) and includes the following topics:

•Upgrading the VEMs Using VMware Update Manager (VUM) to Release 4.0(4)SV1(3d)

•Upgrading the VEMs Manually to Release 4.0(4)SV1(3d)

Upgrading the VEMs Using VMware Update Manager (VUM) to Release 4.0(4)SV1(3d)

To upgrade the VEMs using VUM, follow these steps:

Note For example purposes, the following procedure reflects an upgrade from Release 4.0(4)SV1(3) to Release 4.0(4)SV1(3d).

Note This procedure is performed by the network administrator.

Step 1 Power off the VMs if you are running ESX/ESXi with VMware software release prior to patch ESX400/ESXi400-201002001.

If you are running ESX/ESXi with host maintenance mode, then you do not have to power off the VMs, because ESX will be placed in maintenance mode for the upgrade which in turn will Vmotion the VMs to another host.

Step 2 Coordinate with and notify the server administrator of the VEM upgrade process. 

switch (config)# vmware vem upgrade notify

Warning: 

Please ensure the hosts are running compatible ESX versions for the upgrade. Refer to 
corresponding "Cisco Nexus 1000V and VMware Compatibility Information" guide.

Step 3 Verify that the upgrade notification was sent. 

switch (config)# show vmware vem upgrade status

Upgrade VIBs: System VEM Image

Upgrade Status: Upgrade Availability Notified in vCenter

Upgrade Notification Sent Time: Sun May  9 22:04:54 2010

Upgrade Status Time(vCenter):  

Upgrade Start Time: 

Upgrade End Time(vCenter): 

Upgrade Error: 

Upgrade Bundle ID:

    VSM: VEM400-201010100-BG

    DVS: VEM400-201003101-BG

Note The value of the DVS output will change depending on the vCenter version.

Step 4 Verify that the server administrator has accepted the upgrade in vCenter.

For details about how the server administrator accepts the VEM upgrade, see the "Accepting the VEM Upgrade in the vCenter Client" section.

Coordinate the notification acceptance with the server administrator, and after the server administrator accepts the upgrade, proceed with the VEM upgrade. 

switch# show vmware vem upgrade status 

Upgrade VIBs: System VEM Image

Upgrade Status: Upgrade Accepted by vCenter Admin

Upgrade Notification Sent Time: Sun May  9 22:04:54 2010

Upgrade Status Time(vCenter): Tue May 11 07:42:32 2010 

Upgrade Start Time: 

Upgrade End Time(vCenter): 

Upgrade Error: 

Upgrade Bundle ID:

    VSM: VEM400-201010100-BG

    DVS: VEM400-201003101-BG

Step 5 Initiate the VUM upgrade process.

vCenter locks the DVS and triggers VUM to upgrade the VEMs.

Caution Before entering the following command, communicate with the server administrator to confirm that the VUM process is operational.

Note You must enter the following command in order to update the Cisco Nexus 1000V Bundle ID on the VCenter server. 

switch# vmware vem upgrade proceed

switch# show vmware vem upgrade status 

Upgrade VIBs: System VEM Image

Upgrade Status: Upgrade In Progress in vCenter

Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010

Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010 

Upgrade Start Time: Wed Mar 17 15:20:06 2010

Upgrade End Time(vCenter): 

Upgrade Error: 

Upgrade Bundle ID:

    VSM: VEM400-201010100-BG

    DVS: VEM400-201010100-BG

Note If the ESX/ESXi host is using VMware patch ESX400/ESXi400-201002001 or ESX410/ESXi410, and if your DRS settings are enabled to allow it, VUM automatically Vmotions the VMs from the host to another host in the cluster and places the ESX/ESXi in maintenance mode to upgrade the VEM. This process is continued for other hosts in the DRS cluster until all the hosts are upgraded in the cluster.

Step 6 Check for the Upgrade Complete status. 

switch# show vmware vem upgrade status

Upgrade VIBs: System VEM Image

Upgrade Status: Upgrade Complete in vCenter 

Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010

Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010

Upgrade Start Time: Wed Mar 17 15:20:06 2010

Upgrade End Time(vCenter): Wed Mar 17 17:30:48 2010

Upgrade Error:

Upgrade Bundle ID:

    VSM: VEM400-201010100-BG

    DVS: VEM400-201010100-BG

Step 7 Clear the VEM upgrade status after the upgrade process is complete. 

switch# vmware vem upgrade complete

switch# show vmware vem upgrade status

Upgrade VIBs: System VEM Image

Upgrade Status: 

Upgrade Notification Sent Time:

Upgrade Status Time(vCenter):

Upgrade Start Time:

Upgrade End Time(vCenter):

Upgrade Error:

Upgrade Bundle ID:

    VSM: VEM400-201010100-BG

    DVS: VEM400-201010100-BG

Step 8 Verify that the upgrade process is complete. 

switch#  show mod

Mod  Ports  Module-Type                      Model              Status

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

1    0      Virtual Supervisor Module        Nexus1000V         ha-standby

2    0      Virtual Supervisor Module        Nexus1000V         active *

3    248    Virtual Ethernet Module          NA                 ok

4    248    Virtual Ethernet Module          NA                 ok


Mod  Sw               Hw 

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

1    4.0(4)SV1(3d)    0.0 

2    4.0(4)SV1(3d)    0.0 

3    4.0(4)SV1(3d)    1.11 

4    4.0(4)SV1(3d)    1.11 


Mod  MAC-Address(es)                         Serial-Num

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

1    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA 

2    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 


Mod  Server-IP        Server-UUID                           Server-Name

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

1    10.78.109.100    NA                                    NA

2    10.78.109.100    NA                                    NA

3    10.78.109.104    1ee15784-f2e8-383e-8132-9026577ca1bb  10.78.109.104

4    10.78.109.102    44454c4c-4700-104e-804d-cac04f563153  10.78.109.102

* this terminal session

Note The line with the bold characters in the preceding example display that all VSMs and VEMs are upgraded to Release 4.0(4)SV1(3d).

Step 9 Determine if changing the Feature Support Level is required:

•If you are upgrading from Release 4.0(4)SV1(3), you have completed this procedure.

•If you are upgrading from Release 4.0(4)SV1(2), continue to Step 10.

Step 10 (Optional) Change the feature support level to enable the VSM to support all the new features in the new software version.

See the "Changing the Feature Support Level" section for more details.

Upgrading the VEMs Manually to Release 4.0(4)SV1(3d)

The manual upgrade of VEMs involves the Cisco Nexus 1000V using either VMware ESX commands, which are available on the host ESX CLI, or using the VMware vCLI commands. For further details, see the Cisco Nexus 1000V VEM Software Installation and Upgrade Guide, Release 4.0(4)SV1(3d).

To upgrade the VEMs manually, follow these steps:

Note This procedure is performed by the network administrator.

Step 1 Vmotion or power off the VMs if you are running ESX/ESXi with VMware software release prior to patch ESX400/ESXi400-201002001.

If you are running ESX/ESXi with VMware patch ESX400/ESXi400-201002001, then you do not need to power off the VMs. However, the host must be manually placed in maintenance mode before the VEM upgrade.

Step 2 Coordinate with and notify the server administrator of the VEM upgrade process. 

switch (config)# vmware vem upgrade notify

vmware vem upgrade notify

Warning: 

Please ensure the hosts are running compatible ESX versions for the upgrade. Refer to 
corresponding "Cisco Nexus 1000V and VMware Compatibility Information" guide.

Step 3 Verify that the upgrade notification was sent. 

switch (config)# show vmware vem upgrade status

Upgrade VIBs: System VEM Image

Upgrade Status: Upgrade Availability Notified in vCenter

Upgrade Notification Sent Time: Sun May  9 22:04:54 2010

Upgrade Status Time(vCenter):  

Upgrade Start Time: 

Upgrade End Time(vCenter): 

Upgrade Error: 

Upgrade Bundle ID:

    VSM: VEM400-201010100-BG

    DVS: VEM400-201003191-BG

Step 4 Verify that the server administrator has accepted the upgrade in vCenter Server.

For details about the server administrator accepting the VEM upgrade, see the "Accepting the VEM Upgrade in the vCenter Client" section.

After the server administrator accepts the upgrade, proceed with the VEM upgrade. 

switch# show vmware vem upgrade status 

Upgrade VIBs: System VEM Image

Upgrade Status: Upgrade Accepted by vCenter Admin

Upgrade Notification Sent Time: Sun May  9 22:04:54 2010

Upgrade Status Time(vCenter): Tue May 11 07:42:32 2010 

Upgrade Start Time: 

Upgrade End Time(vCenter): 

Upgrade Error: 

Upgrade Bundle ID:

    VSM: VEM400-201010100-BG

    DVS: VEM400-201003191-BG

Step 5 Initiate the manual upgrade process.

Note If VUM is enabled in the vCenter environment, disable it before entering the vmware vem upgrade proceed command to prevent the new VIBs from being pushed to all the hosts.

Enter the vmware vem upgrade proceed command so that the Cisco Nexus 1000V Bundle ID on the vCenter Server gets updated. If VUM is enabled and you do not update the Bundle ID, an incorrect VIB version is pushed to the VEM when you next add the ESX to VSM. 

switch# vmware vem upgrade proceed

switch# show vmware vem upgrade status 

Upgrade VIBs: System VEM Image

Upgrade Status: Upgrade In Progress in vCenter

Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010

Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010 

Upgrade Start Time: Wed Mar 17 15:20:06 2010

Upgrade End Time(vCenter): 

Upgrade Error: 

Upgrade Bundle ID:

    VSM: VEM400-201010100-BG

    DVS: VEM400-201010100-BG

Step 6 Check for the Upgrade Complete status. 

switch# show vmware vem upgrade status

Upgrade VIBs: System VEM Image

Upgrade Status: Upgrade Complete in vCenter 

Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010

Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010

Upgrade Start Time: Wed Mar 17 15:20:06 2010

Upgrade End Time(vCenter): Wed Mar 17 17:28:48 2010

Upgrade Error:

Upgrade Bundle ID:

    VSM: VEM400-201010100-BG

    DVS: VEM400-201010100-BG

Step 7 Coordinate with and wait until the server administrator upgrades all ESX host VEMs with the new VEM software release and informs you that the upgrade process is complete.

The server administrator performs the manual upgrade using the vihostupdate command or the ESX/ESXi update. For details about manually installing the VEM software, see the Cisco Nexus 1000V VEM Software Installation and Upgrade Guide, Release 4.0(4)SV1(3d).

Step 8 Clear the VEM upgrade status after the upgrade process is complete. 

switch# vmware vem upgrade complete

switch# show vmware vem upgrade status

Upgrade VIBs: System VEM Image

Upgrade Status:

Upgrade Notification Sent Time:

Upgrade Status Time(vCenter):

Upgrade Start Time:

Upgrade End Time(vCenter):

Upgrade Error:

Upgrade Bundle ID:

    VSM: VEM400-201010100-BG

    DVS: VEM400-201010100-BG

Step 9 Verify that the upgrade process is complete. 

switch#  show mod

Mod  Ports  Module-Type                      Model              Status

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

1    0      Virtual Supervisor Module        Nexus1000V         ha-standby

2    0      Virtual Supervisor Module        Nexus1000V         active *

3    248    Virtual Ethernet Module          NA                 ok

4    248    Virtual Ethernet Module          NA                 ok


Mod  Sw               Hw 

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

1    4.0(4)SV1(3d)    0.0 

2    4.0(4)SV1(3d)    0.0 

3    4.0(4)SV1(3d)    1.11 

4    4.0(4)SV1(3d)    1.11 


Mod  MAC-Address(es)                         Serial-Num

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

1    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA 

2    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 


Mod  Server-IP        Server-UUID                           Server-Name

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

1    10.78.109.100    NA                                    NA

2    10.78.109.100    NA                                    NA

3    10.78.109.104    1ee15784-f2e8-383e-8132-9026577ca1bb  10.78.109.104

4    10.78.109.102    44454c4c-4700-104e-804d-cac04f563153  10.78.109.102

* this terminal session

Note The line with the bold characters in the preceding example display that all VSMs and VEMs are upgraded to Release 4.0(4)SV1(3d).

Step 10 Determine if changing the Feature Support Level is required:

•If you are upgrading from Release 4.0(4)SV1(3), you have completed this procedure.

•If you are upgrading from Release 4.0(4)SV1(2), continue to Step 11.

Step 11 (Optional) Change the feature support level to enable the VSM to support all the new features in the new software version.

See the "Changing the Feature Support Level" section for more details.

Upgrading the VEMs from Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d)

This section describes the steps to upgrade VEMs from Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d) and includes the following topics:

•Upgrading the VEMs Using VMware Update Manager (VUM): Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d)

•Upgrading the VEMs Manually: Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d)

Upgrading the VEMs Using VMware Update Manager (VUM): Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d)

To upgrade the VEMs using VUM, follow these steps:

Note This procedure is performed by the network administrator. Before proceeding with the upgrade, make sure the VMs are powered off.

Caution This upgrade is only applicable when VSM is not hosted on VEMs that are being upgraded. If the VSM is hosted on a VEM, proceed to the Upgrading the VEMs Manually: Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d)

Step 1 Coordinate with and notify the server administrator of the VEM upgrade process. 

switch (config)# vmware vem upgrade notify

Warning: 

Please ensure the hosts are running compatible ESX versions for the upgrade. Refer to 
corresponding "Cisco Nexus 1000V and VMware Compatibility Information" guide.

Step 2 Verify that the upgrade notification was sent. 

switch (config)# show vmware vem upgrade status

Upgrade VIBs: System VEM Image

Upgrade Status: Upgrade Availability Notified in vCenter

Upgrade Notification Sent Time: Sun May  9 22:04:54 2010

Upgrade Status Time(vCenter):  

Upgrade Start Time: 

Upgrade End Time(vCenter): 

Upgrade Error: 

Upgrade Bundle ID:

    VSM: VEM400-201010100-BG

    DVS: VEM400-200904001-BG

Step 3 Verify that the server administrator has accepted the upgrade in vCenter Server.

For details about the server administrator accepting the VEM upgrade, see the "Accepting the VEM Upgrade in the vCenter Client" section.

Coordinate the notification acceptance with the server administrator, and after the server administrator accepts the upgrade, proceed with the VEM upgrade. 

switch# show vmware vem upgrade status 

Upgrade VIBs: System VEM Image

Upgrade Status: Upgrade Accepted by vCenter Admin

Upgrade Notification Sent Time: Sun May  9 22:04:54 2010

Upgrade Status Time(vCenter): Tue May 11 07:42:32 2010 

Upgrade Start Time: 

Upgrade End Time(vCenter): 

Upgrade Error: 

Upgrade Bundle ID:

    VSM: VEM400-201010100-BG

    DVS: VEM400-200904001-BG

After the server administrator accepts the upgrade, proceed with the VEM upgrade.

Step 4 Initiate the VUM upgrade process.

vCenter locks the DVS and triggers VUM to upgrade the VEMs.

Note Enter the vmware vem upgrade proceed command to update the Cisco Nexus 1000V Bundle ID on the vCenter Server. If you do not update the Bundle ID, an incorrect VIB version is pushed to the VEM when you next add an ESX to the VSM. 

switch# vmware vem upgrade proceed

switch# show vmware vem upgrade status 

Upgrade VIBs: System VEM Image

Upgrade Status: Upgrade In Progress in vCenter

Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010

Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010 

Upgrade Start Time: Wed Mar 17 15:20:06 2010

Upgrade End Time(vCenter): 

Upgrade Error: 

Upgrade Bundle ID:

    VSM: VEM400-201010100-BG

    DVS: VEM400-201010100-BG

Step 5 Check for the Upgrade Complete status. 

switch# show vmware vem upgrade status

Upgrade VIBs: System VEM Image

Upgrade Status: Upgrade Complete in vCenter 

Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010

Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010

Upgrade Start Time: Wed Mar 17 15:20:06 2010

Upgrade End Time(vCenter): Wed Mar 17 17:30:48 2010

Upgrade Error:

Upgrade Bundle ID:

    VSM: VEM400-201010100-BG

    DVS: VEM400-201010100-BG

Step 6 Clear the VEM upgrade status after the upgrade process is complete. 

switch# vmware vem upgrade complete

switch# show vmware vem upgrade status

Upgrade VIBs: System VEM Image

Upgrade Status:

Upgrade Notification Sent Time:

Upgrade Status Time(vCenter):

Upgrade Start Time:

Upgrade End Time(vCenter):

Upgrade Error:

Upgrade Bundle ID:

    VSM: VEM400-201010100-BG

    DVS: VEM400-201010100-BG

Step 7 Verify that the upgrade process is complete. 

switch#  show mod

Mod  Ports  Module-Type                      Model              Status

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

1    0      Virtual Supervisor Module        Nexus1000V         ha-standby

2    0      Virtual Supervisor Module        Nexus1000V         active *

3    248    Virtual Ethernet Module          NA                 ok

4    248    Virtual Ethernet Module          NA                 ok


Mod  Sw               Hw 

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

1    4.0(4)SV1(3d)     0.0 

2    4.0(4)SV1(3d)     0.0 

3    4.0(4)SV1(3d)     1.11 

4    4.0(4)SV1(3d)     1.11 


Mod  MAC-Address(es)                         Serial-Num

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

1    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA 

2    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 


Mod  Server-IP        Server-UUID                           Server-Name

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

1    10.78.109.100    NA                                    NA

2    10.78.109.100    NA                                    NA

3    10.78.109.104    1ee15784-f2e8-383e-8132-9026577ca1bb  10.78.109.104

4    10.78.109.102    44454c4c-4700-104e-804d-cac04f563153  10.78.109.102

* this terminal session

Note The line with the bold characters in the preceding example display that all VSMs and VEMs are upgraded to Release 4.0(4)SV1(3d).

Step 8 Change the feature support level to enable the VSM to support all the new features in the new software version.

See the "Changing the Feature Support Level" section for more details.

Step 9 Power on the VMs.

Upgrading the VEMs Manually: Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d)

The manual upgrade of VEMs involves the Cisco Nexus 1000V either using VMware ESX commands that are available on the host ESX CLI or using the VMware vCLI commands. For more details, see also the Cisco Nexus 1000V VEM Software Installation and Upgrade Guide, Release 4.0(4)SV1(3d).

To upgrade the VEMs manually, perform the following steps as network administrator:

Note This procedure is performed by the network administrator. Before proceeding with the upgrade, make sure the VMs are powered off.

Step 1 Coordinate with and notify the server administrator of the VEM upgrade process. 

switch (config)# vmware vem upgrade notify

Warning: 

Please ensure the hosts are running compatible ESX versions for the upgrade. Refer to 
corresponding "Cisco Nexus 1000V and VMware Compatibility Information" guide.

Step 2 Verify that the upgrade notification was sent. 

switch (config)# show vmware vem upgrade status

Upgrade VIBs: System VEM Image

Upgrade Status: Upgrade Availability Notified in vCenter

Upgrade Notification Sent Time: Sun May  9 22:04:54 2010

Upgrade Status Time(vCenter):  

Upgrade Start Time: 

Upgrade End Time(vCenter): 

Upgrade Error: 

Upgrade Bundle ID:

    VSM: VEM400-201010100-BG

    DVS: VEM400-200904001-BG

Step 3 Verify that the server administrator has accepted the upgrade in vCenter Server.

For details about the server administrator accepting the VEM upgrade, see the "Accepting the VEM Upgrade in the vCenter Client" section.

After the server administrator accepts the upgrade, proceed with the VEM upgrade. 

switch# show vmware vem upgrade status 

Upgrade VIBs: System VEM Image

Upgrade Status: Upgrade Accepted by vCenter Admin

Upgrade Notification Sent Time: Sun May  9 22:04:54 2010

Upgrade Status Time(vCenter): Tue May 11 07:42:32 2010 

Upgrade Start Time: 

Upgrade End Time(vCenter): 

Upgrade Error: 

Upgrade Bundle ID:

    VSM: VEM400-201010100-BG

    DVS: VEM400-200904001-BG

Step 4 If the ESX host is not hosting the VSM, then proceed to Step 5.

If the ESX host is hosting the VSM, coordinate with the server administrator to power off the VSM, upgrade the VEMs on the ESX host using the manual process, and power on the VSM.

Step 5 Initiate the Cisco Nexus 1000V Bundle ID upgrade process.

Note If VUM is enabled in the vCenter environment, disable it before entering the vmware vem upgrade proceed command to prevent the new VIBs from being pushed to all the hosts.

Enter the vmware vem upgrade proceed command to update the Cisco Nexus 1000V Bundle ID on the vCenter Server. If you do not update the Bundle ID, an incorrect VIB version is pushed to the VEM when you next add an ESX to the VSM. 

switch# vmware vem upgrade proceed

switch# show vmware vem upgrade status 

2010 Mar 18 15:37:45 switch %VMS-5-DVS_UPGRADE_INFO: VEM Upgrade is completed successfully 
in vCenter. 


Upgrade VIBs: System VEM Image

Upgrade Status: Upgrade In Progress in vCenter

Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010

Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010 

Upgrade Start Time: Wed Mar 17 15:20:06 2010

Upgrade End Time(vCenter): 

Upgrade Error: 

Upgrade Bundle ID:

    VSM: VEM400-201010100-BG

    DVS: VEM400-201010100-BG

Step 6 Check for the Upgrade Complete status. 

switch# show vmware vem upgrade status

Upgrade VIBs: System VEM Image

Upgrade Status: Upgrade Complete in vCenter 

Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010

Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010

Upgrade Start Time: Wed Mar 17 15:20:06 2010

Upgrade End Time(vCenter): Wed Mar 17 17:28:48 2010

Upgrade Error:

Upgrade Bundle ID:

    VSM: VEM400-201010100-BG

    DVS: VEM400-201010100-BG

Step 7 Coordinate with and wait until the server administrator upgrades all ESX host VEMs with the new VEM software release and informs you that the upgrade process is complete. The server administrator performs the manual upgrade using the vi host update or the ESX/ESXi update. For details, see the Cisco Nexus 1000V VEM Software Installation and Upgrade Guide, Release 4.0(4)SV1(3d).

Step 8 Clear the VEM upgrade status after the upgrade process is complete. 

switch# vmware vem upgrade complete

switch# show vmware vem upgrade status

Upgrade VIBs: System VEM Image

Upgrade Status:

Upgrade Notification Sent Time:

Upgrade Status Time(vCenter):

Upgrade Start Time:

Upgrade End Time(vCenter):

Upgrade Error:

Upgrade Bundle ID:

    VSM: VEM400-201010100-BG

    DVS: VEM400-201010100-BG

Step 9 Verify that the upgrade process is complete. 

switch#  show mod

Mod  Ports  Module-Type                      Model              Status

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

1    0      Virtual Supervisor Module        Nexus1000V         ha-standby

2    0      Virtual Supervisor Module        Nexus1000V         active *

3    248    Virtual Ethernet Module          NA                 ok

4    248    Virtual Ethernet Module          NA                 ok


Mod  Sw               Hw 

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

1    4.0(4)SV1(3d)     0.0 

2    4.0(4)SV1(3d)     0.0 

3    4.0(4)SV1(3d)     1.11 

4    4.0(4)SV1(3d)     1.11 


Mod  MAC-Address(es)                         Serial-Num

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

1    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA 

2    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 


Mod  Server-IP        Server-UUID                           Server-Name

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

1    10.78.109.100    NA                                    NA

2    10.78.109.100    NA                                    NA

3    10.78.109.104    1ee15784-f2e8-383e-8132-9026577ca1bb  10.78.109.104

4    10.78.109.102    44454c4c-4700-104e-804d-cac04f563153  10.78.109.102

* this terminal session

Note The line with the bold characters in the preceding example display that all VSMs and VEMs are upgraded to Release 4.0(4)SV1(3d).

Step 10 Change the feature support level to enable the VSM to support all the new features in the new software version.

See the "Changing the Feature Support Level" section for more details.

Step 11 Power on the VMs.

Changing the Feature Support Level

Note Since Release 4.0(4)SV1(3d) is a maintenance release, it does not have a Feature Support Level. If you are already at Feature Support Level 4.0(4)SV1(3), you do not have to upgrade the Feature Support Level.

This section describes how to change the feature support level and includes the following topics:

•Prerequisites to Changing the Feature Support Level

•Changing the Feature Support Level

After all VEMs in the domain are upgraded, the network administrator changes the feature support level to allow the VSM to support all the new features in the new software version.

Prerequisites to Changing the Feature Support Level

The following are prerequisites to changing the feature support level:

•You are logged in to the CLI in EXEC mode.

•After an upgrade, the VSM default is to support only features in the previous software version. Features added in the new software version are only supported and functional after the network administrator explicitly upgrades the feature support level. This procedure upgrades the feature support level.

•You can configure the VSM to provide support for the lowest VEM software version installed to maintain a consistent level of feature support.

•Before upgrading the feature support level, all VEMs in the VSM domain must be upgraded to the new software version.

•After the VSM feature support level is upgraded, VEMs with other software versions are not allowed to connect with the VSM.

•After the VSM feature support level is upgraded, it cannot be downgraded.

Changing the Feature Support Level

To change the feature support level, follow these steps:

Note This procedure is performed by the network administrator.

Note For example purposes, the following procedure reflects an upgrade from Feature Support Level 4.0(4)SV1(2).

Step 1 Verify the current level of feature support.

switch# show system vem feature level

current feature level: 4.0(4)SV1(2) 

switch#

Note If you are currently at Feature Support Level 4.0(4)SV1(1) or 4.0(4)SV1(2), you may elect to update to Feature Support Level 4.0(4)SV1(3).

Step 2 Display output based on the current VEM feature and the version of the VEMs.

switch# system update vem feature level

1 4.0(4)SV1(2)

2 4.0(4)SV1(3)

Note If all VEMs are upgraded to the new software version, then the feature support can be upgraded to the new software version. If even a single VEM is running the previous software version, then the feature support level cannot be upgraded, and the list will be empty.

Step 3 Change the feature level to the desired index level from the list displayed in Step 2.

switch# system update vem feature level 2

Old feature level: 4.0(4)SV1(2)

New feature level: 4.0(4)SV1(3)

Note After the feature level upgrade, VEMs with versions older than the feature level are no longer allowed to connect to the VSM.

Step 4 Verify the updated level of feature support. 

switch# show system vem feature level

current feature level: 4.0(4)SV1(3)

switch#

Step 5 Verify connectivity to the VEMs. 

switch#  show mod

Mod  Ports  Module-Type                      Model              Status

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

1    0      Virtual Supervisor Module        Nexus1000V         ha-standby

2    0      Virtual Supervisor Module        Nexus1000V         active *

3    248    Virtual Ethernet Module          NA                 ok

4    248    Virtual Ethernet Module          NA                 ok


Mod  Sw               Hw 

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

1    4.0(4)SV1(3d)     0.0 

2    4.0(4)SV1(3d)     0.0 

3    4.0(4)SV1(3d)     1.11 

4    4.0(4)SV1(3d)     1.11 


Mod  MAC-Address(es)                         Serial-Num

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

1    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA 

2    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 


Mod  Server-IP        Server-UUID                           Server-Name

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

1    10.78.109.100    NA                                    NA

2    10.78.109.100    NA                                    NA

3    10.78.109.104    1ee15784-f2e8-383e-8132-9026577ca1bb  10.78.109.104

4    10.78.109.102    44454c4c-4700-104e-804d-cac04f563153  10.78.109.102

* this terminal session

Note The output of the show module command can show either of the following VEM states:
OK—The VEM has connectivity to the VSM.
not-inserted(upgrade)—The VEM is not connected to the VSM.

Step 6 Your software upgrade is complete.

Accepting the VEM Upgrade in the vCenter Client

This section describes the steps that a server administrator follows to accept a VEM upgrade in the vCenter Client and includes the following topics:

•"Prerequisites to Accepting the VEM Upgrade" section

•"Accepting the VEM Upgrade" section

For details about how to upgrade the VEMs see "Upgrading the VEMs" section.

Prerequisites to Accepting the VEM Upgrade

The following are prerequisites to accepting a VEM upgrade:

•You are logged in to the CLI in EXEC mode.

•Network and server administrators are coordinating the upgrade procedure.

•The VSM upgrade has occurred before the VEM upgrade.

•You have received a notification in vCenter that a VEM software upgrade is available.

Accepting the VEM Upgrade

The server administrator accepts the VEM upgrade after the network administrator has upgraded the VSM and notified vCenter server of the availability of the new VEM software version.

To accept a request for a VEM upgrade, follow these steps:

Note This procedure is performed by the server administrator.

Step 1 Click the vSphere Client DVS Summary tab to check for the availability of a software upgrade (see Figure 1).

Figure 1 vSphere Client DVS Summary Tab

Step 2 Click Apply upgrade.

The following actions occur:

•The network administrator is notified that you are ready to apply the upgrade to the VEMs.

•The network administrator notifies vCenter to proceed with the VEM upgrades.

•If you are using VUM, vCenter locks the DVS and triggers VUM to upgrade the VEMs.

For details about the VEM upgrade performed by the network administrator, see the "Upgrading the VEMs" section.

Troubleshooting

This section provides troubleshooting guidelines for problems that may occur during an upgrade. This section includes the following topic:

•Non-default (Jumbo) MTU Settings Symptoms and Solutions

Non-default (Jumbo) MTU Settings Symptoms and Solutions

If you have configured non-default (jumbo) MTU settings, read this section before proceeding with VEM upgrades.

Symptom
Possible Causes
Solution

After rebooting an ESX server, the MTU settings revert to default (1500) for VMNICs (pNICs) attached to the Cisco Nexus 1000V, resulting in loss of traffic and connectivity.

If the MTU for a pNIC attached to the Nexus 1000V is changed from the default value, then an ESX reboot will set it back to the default value of 1500.

Verify the MTU settings on ESX with the esxcfg-nics -l command. Check for MTU settings for the corresponding pNIC.

For system uplinks ports, set the system mtu command in the system port profile applied to the port. This ensures the MTU is preserved for uplink interfaces with system VLANs.

For non-system uplinks, the VSM sets the correct MTU based on the interface configuration.The system mtu command does not apply to non-system profiles or ports.


Available Documents

The following documents are used with the Cisco Nexus 1000 and are available on Cisco.com at the following url:

http://www.cisco.com/en/US/products/ps9902/tsd_products_support_series_home.html

General Information

Cisco Nexus 1000V Documentation Roadmap, Release 4.0(4)SV1(3d)

Cisco Nexus 1000V Release Notes, Release 4.0(4)SV1(3d)

Cisco Nexus 1000V and VMware Compatibility Information, Release 4.0(4)SV1(3d)

Cisco Nexus 1010 Management Software Release Notes, Release 4.0(4)SP1(1)

Install and Upgrade

Cisco Nexus 1000V VSM Software Installation Guide, Release 4.0(4)SV1(3d)

Cisco Nexus 1000V Software Upgrade Guide, Release 4.0(4)SV1(3d)

Cisco Nexus 1000V VEM Software Installation and Upgrade Guide, Release 4.0(4)SV1(3d)

Cisco Nexus 1010 Virtual Services Appliance Hardware Installation Guide

Configuration Guides

Cisco Nexus 1000V Getting Started Guide, Release 4.0(4)SV1(3)

Cisco Nexus 1000V High Availability and Redundancy Configuration Guide, Release 4.0(4)SV1(3)

Cisco Nexus 1000V Interface Configuration Guide, Release 4.0(4)SV1(3)

Cisco Nexus 1000V Layer 2 Switching Configuration Guide, Release 4.0(4)SV1(3)

Cisco Nexus 1000V License Configuration Guide, Release 4.0(4)SV1(3)

Cisco Nexus 1000V Port Profile Configuration Guide, Release 4.0(4)SV1(3)

Cisco Nexus 1000V Quality of Service Configuration Guide, Release 4.0(4)SV1(3)

Cisco Nexus 1000V Security Configuration Guide, Release 4.0(4)SV1(3)

Cisco Nexus 1000V System Management Configuration Guide, Release 4.0(4)SV1(3)

Cisco Nexus 1010 Software Configuration Guide, Release 4.0(4)SP1(1)

Programming Guide

Cisco Nexus 1000V XML API User Guide, Release 4.0(4)SV1(3)

Reference Guides

Cisco Nexus 1000V Command Reference, Release 4.0(4)SV1(3)

Cisco Nexus 1000V MIB Quick Reference

Cisco Nexus 1010 Command Reference, Release 4.0(4)SP1(1)

Troubleshooting and Alerts

Cisco Nexus 1000V Troubleshooting Guide, Release 4.0(4)SV1(3a)

Cisco Nexus 1000V Password Recovery Guide

Cisco NX-OS System Messages Reference

Network Analysis Module Documentation

Cisco Network Analysis Module Software Documentation Guide, 4.2

Cisco Nexus 1000V NAM Virtual Service Blade Installation and Configuration Guide

Network Analysis Module Command Reference Guide, 4.2

User Guide for the Cisco Network Analysis Module Virtual Service Blades, 4.2

Cisco Network Analysis Module Software Release Notes, 4.2

Obtaining Documentation and Submitting a Service Request

For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:

http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html

Subscribe to the What's New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS Version 2.0.

This document is to be used in conjuction with the documents listed in the Available Documents section.

Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2011 Cisco Systems, Inc. All rights reserved.

Was this Document Helpful?

FeedbackFeedback

Contact Cisco

This Document Applies to These Products