Guest

Cisco Nexus 1000V Switch for VMware vSphere

Cisco Nexus 1000V Software Upgrade Guide, Release 4.2(1)SV1(4)

  • Viewing Options

  • PDF (2.2 MB)
  • Feedback
Cisco Nexus 1000V Software Upgrade Guide, Release 4.2(1) SV1(4)

Table Of Contents

Cisco Nexus 1000V Software Upgrade Guide, Release 4.2(1) SV1(4)

Audience

Obtaining the Software

Running the Pre-Upgrade Utility

Prerequisites for Running the Pre-Upgrade Utility

Running the Pre-Upgrade Utility on a Microsoft Windows Platform

Running the Pre-Upgrade Utility Using the Cygwin Application

Installing the Cygwin Application

Running the Pre-Upgrade Utility in the Cygwin Application

Running the Pre-Upgrade Utility on a UNIX Platform

Information About the Software Upgrade

Information About Licensing

Upgrading to Release 4.2(1)SV1(4)

Upgrading from Release 4.0(4)SV1(3, 3a, or 3b) to Release 4.2(1)SV1(4)

Upgrading from Release 4.0(4)SV1(2) to Release 4.2(1)SV1(4)

Upgrading from Release 4.0(4)SV1(1) to Release 4.2(1)SV1(4)

Upgrading the VSMs

Upgrading the VSMs: Release 4.0(4)SV1(2) to Release 4.0(4)SV1(3b)

Prerequisites to Upgrading the VSMs

Upgrading the VSMs: Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3b)

Prerequisites to Upgrading the VSMs

Upgrading the VEMs

Upgrading the VEMs: Release 4.0(4)SV1(2, 3, 3a, 3b) to Release 4.2(1)SV1(4)

Prerequisites to Upgrading VEMs

Upgrading the VEMs Using VMware Update Manager (VUM): Release 4.0(4)SV1(2, 3, 3a, or 3b) to Release 4.2(1)SV1(4)

Upgrading the VEMs Manually: Release 4.0(4)SV1(2, 3, 3a, or 3b) to Release 4.2(1)SV1(4)

Upgrading the VEMs: Release 4.0(4)SV1(1) to Release 4.2(1)SV1(4)

Prerequisites to Upgrading VEMs

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

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

Upgrading the VSMs to Release 4.2(1)SV1(4) Using the Upgrade Application

Prerequisites to Using the Cisco Nexus 1000V Upgrade Application

Upgrading the VSMs Manually on a Cisco Nexus 1000V from Release 4.0(4)SV1(3, 3a, or 3b) to Release 4.2(1)SV1(4)

Prerequisites to Upgrading the VSMs

Upgrading the VSMs Manually on a Cisco Nexus 1010 from Release 4.0(4)SV1(3, 3a, or 3b) to Release 4.2(1)SV1(4)

Prerequisites to Upgrading the VSMs

Upgrading the VSMs Manually on a Cisco Nexus 1000V from Release 4.0(4)SV1(3, 3a, or 3b) to Release 4.2(1)SV1(4)

Prerequisites to Upgrading the VSMs

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.2(1) SV1(4)


Revised: May 9, 2013
OL-22826-01

Caution The upgrade procedure for Release 4.2(1)SV1(4) has changed. You must run the Pre-Upgrade Utility prior to beginning the upgrade. It is highly recommended that you read this document thoroughly before beginning the upgrade. For an overview of the new upgrade procedure, see the Understanding the Upgrade Process for the Cisco Nexus 1000V Release 4.2(1)SV1(4) video.

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

Audience

Obtaining the Software

Running the Pre-Upgrade Utility

Information About the Software Upgrade

Upgrading to Release 4.2(1)SV1(4)

Upgrading the VSMs

Upgrading the VEMs

Upgrading the VSMs Manually on a Cisco Nexus 1010 from Release 4.0(4)SV1(3, 3a, or 3b) to Release 4.2(1)SV1(4)

Upgrading the VSMs Manually on a Cisco Nexus 1000V from Release 4.0(4)SV1(3, 3a, or 3b) to Release 4.2(1)SV1(4)

Accepting the VEM Upgrade in the vCenter Client

Troubleshooting

Available Documents

Obtaining Documentation and Submitting a Service Request, page 85

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 Distributed Virtual Switch (DVS) setup and implementation

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

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.2(1)SV1(4) 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.2(1)SV1(4).

Running the Pre-Upgrade Utility


Note The Pre-Upgrade Utility is compatible with Tcl8.4 and Tcl8.5.



Note Access to third-party websites identified in this document is provided solely as a courtesy to customers and others. Cisco Systems, Inc. and its affiliates are not in any way responsible or liable for the functioning of any third-party website, or the download, performance, quality, functioning or support of any software program or other item accessed through the website, or any damages, repairs, corrections or costs arising out of any use of the website or any software program or other item accessed through the website. Cisco's End User License Agreement does not apply to the terms and conditions of use of a third-party website or any software program or other item accessed through the website.


In Release 4.2(1)SV1(4), many feature enhancements have been incorporated for smoother operation. The feature checks performed by this script were not present in previous versions of the Cisco Nexus 1000V software. The Pre-Upgrade script checks for discrepancies and writes errors or notifications to the Pre-Upgrade-Check-Logs file in the PreUpgradeUtility folder. Errors must be corrected manually. If not corrected manually, notifications will be handled during the upgrade process.

The pre-upgrade utility checks for the following:

1. If the number of system port profiles exceeds 32

2. Interface override configurations on port channel interfaces

3. License status of modules

4. Global existence of NetFlow monitors used in port profiles

5. Global existence of Quality of Service (QoS) policies used in port profiles

6. The presence of the vlan dot1Q tag native command in global configurations

7. Non-system native VLAN in system port profiles

8. Virtual Supervisor Module (VSM) status

9. Sufficient space on the bootflash: of the active and standby VSMs

10. Authentication usage

11. IP address in SVS connections

12. Subnet routes from control0 interface under the management virtual routing and forwarding (VRF)

13. Channel group configurations under physical interfaces

14. Interfaces that have the shutdown command as an override configuration

15. ERSPAN sessions with no ERSPAN ID

16. QoS and access control list (ACL) statistics

Prerequisites for Running the Pre-Upgrade Utility

The Pre-Upgrade Utility has the following prerequisite:

You must download the PreUpgradeUtility zip file from the Cisco Nexus 1000V first customer ship (FCS) package and unzip the file.

This utility can be run on the following platforms:

Microsoft Windows - see Running the Pre-Upgrade Utility on a Microsoft Windows Platform.

UNIX - see Running the Pre-Upgrade Utility on a UNIX Platform.


Note The Pre-Upgrade-App.exe is not supported.


Running the Pre-Upgrade Utility on a Microsoft Windows Platform

The Pre-Upgrade Utility must be run using the following open-source Cygwin application:

Cygwin - An open-source freeware tool that needs to be installed from http://www.cygwin.com. Cygwin is supported for commercially released x86 32-bit and 64-bit versions of Windows (except Windows CE). This is the recommended method. See Running the Pre-Upgrade Utility Using the Cygwin Application.

Running the Pre-Upgrade Utility Using the Cygwin Application

Running the Pre-Upgrade Utility using the Cygwin application is a two-step process:

1. Installing the Cygwin Application.

2. Running the Pre-Upgrade Utility in the Cygwin Application.

Installing the Cygwin Application


Step 1 To download the application, go to this URL: http://www.cygwin.com.

Step 2 Click the setup.exe file link and save it to your desktop.

You may choose the latest version.


Note If there are any questions related to the third-party website or any item accessed on the website, contact the Cygwin support team.


Step 3 Double-click the setup.exe file downloaded in Step 2.

The Cygwin Setup window opens. See Figure 1.

Figure 1 Cygwin Setup Screen

Step 4 Click Next.

The Choose a Download Source window opens. See Figure 2.

Figure 2 Choose a Download Source Screen

Step 5 Choose an appropriate download source and click Next.


Note Choosing the default Install from Internet radio button causes the files you choose in a later step to be downloaded first, validated, and installed.


The Select Root Install Directory window opens. See Figure 3.

Figure 3 Select Root Install Directory Screen

Step 6 Select a Root Directory for installation and click Next.

The Select Local Package Directory window opens. See Figure 4.


Note Do not choose a location that contains spaces in its path name.


Figure 4 Select Local Package Directory Screen

Step 7 In the Local Package Directory field, browse to the local package directory and click Next.

The Select Your Internet Connection window opens. See Figure 5.

Figure 5 Select Your Internet Connection Screen

Step 8 Select an appropriate Internet connection and click Next.

The Choose a Download Site window opens. See Figure 6.

Figure 6 Choose A Download Site Screen

Step 9 In the Available Download Sites area, choose a download site and click Next.

The Progress window opens. See Figure 7.

The installer downloads a list of available packages from the site that you selected.

Figure 7 Progress Screen

Figure 8 Setup Alert Screen

Step 10 If you are installing for the first time and the Setup Alert dialog box opens, click OK.

The Select Packages window opens. See Figure 9.

For a basic installation, some packages are selected by default.


Tip Do not press the Enter key until you have selected all four packages.


Figure 9 Select Packages Screen

Step 11 Enter Inetutils in the Search field.

As you enter the package name, the screen updates with the available packages. See Figure 10.


Note If you choose src packages in addition to binaries, your download time might increase.


Figure 10 Select Packages Screen

Step 12 Expand the Category if necessary and check the Bin? check box.

Step 13 Enter openssh in the Search field. See Figure 11.

Figure 11 Select OpenSSH Packages Screen

Step 14 Expand the Category if necessary and check the Bin? check box.

Step 15 Enter tcl in the Search field. See Figure 12.

Figure 12 Select Tcl Packages Screen

Step 16 Expand the Category if necessary and check the Bin? check boxes.

Step 17 Enter Expect in the Search field. See Figure 13.

Figure 13 Select Expect Packages Screen

Step 18 Expand the Category if necessary and check the Bin? check box.

Step 19 Click Next.

In Cygwin 1.7, you might see a screen that displays a warning ("Resolving Dependencies") and a list of additional packages that are required by the packages that you have already selected.

The Resolving Dependencies screen opens. See Figure 14.

Figure 14 Resolving Dependencies Screen

Step 20 At the bottom of the screen, be sure that the Select required packages (RECOMMENDED) check box is checked and click Next.

The downloading process begins after you choose the packages.

Figure 15 Download Progress Screen


Note The downloading and installation process takes several minutes to complete depending on the speed of your Internet connection. Make sure that all three progress bars have completed.


Following package installation, any installation dependent configuration scripts are run to complete the setup process.


Note There might be lengthy pauses during this step without any indication of progress.


The Create Icons window opens. See Figure 16.

Figure 16 Create Icons Screen

Step 21 Check appropriate shortcut check boxes and click Finish.


Running the Pre-Upgrade Utility in the Cygwin Application

Prerequisites:

You have downloaded the PreUpgradeUtility zip file from the Cisco Nexus 1000V FCS package and unzipped the file.


Step 1 Copy the pre-upgrade-check-4.2(1)SV1(4).tcl file to C:\cygwin or the main directory where the user has installed Cygwin.

Step 2 Double-click the Cygwin shortcut on your desktop to start the Cygwin application.

The Cygwin application window opens. See Figure 17.

Figure 17 Terminal Window

Step 3 Telnet or SSH to the Cisco Nexus 1000V VSM and exit before continuing with Step 4.

Step 4 Navigate to the location where you saved the Pre-Upgrade script and run the following command:

$ expect pre-upgrade-check-4.2\(1\)SV1\(4\).tcl ip-address username password  
  [telnet | ssh]
 

ip-address is the IP address of the VSM.

username and password are the login credentials.


Note The following window displays this command being run with the Telnet option.


Figure 18 Telnet Option Window


Note Two methods of connectivity can be used. Both Telnet or SSH ensure that the service is enabled on the VSM before using Cygwin.


Step 5 Perform one of the following options:

If no errors are found, continue with the upgrade.

If error are found, correct them.

Step 6 Rerun the script and correct any additional errors until no errors are displayed.

Step 7 Continue with the upgrade.


Running the Pre-Upgrade Utility on a UNIX Platform


Caution While the Pre-Upgrade script is running, do not execute any system commands.


Step 1 Download the PreUpgradeUtility zip file from the Cisco Nexus 1000V FCS package and unzip.

Step 2 Download and install Tcl 8.4 and Expect.


Note Download Tcl 8.4 at http://www.activestate.com/activetcl/downloads. If there are any questions related to the third-party website or any item accessed on the website, contact the ActiveState Software Inc. support team.


Step 3 Run the following command:

tclsh pre-upgrade-check-4.2(1)SV1(4).tcl ip-address username password [telnet | ssh]
 
   

ip-address is the IP address of the VSM.

username and password are the login credentials.

Example:
tclsh pre-upgrade-check-4.2(1)SV1(4).tcl 10.0.0.2 user1 mynewpassword telnet 
 
   

The checks being performed and the results are displayed . If there are any errors, possible corrective actions are listed. The log file containing the errors and notifications is Pre-Upgrade-App-date-time.txt. in the PreUpgradeUtility/Pre-Upgrade-Check-Logs folder.

Step 4 Perform one of the following steps:

If no errors are found, continue with the upgrade.

If errors are found, correct them.

Step 5 Rerun the script and correct the errors until no errors are displayed.

Step 6 Continue with the upgrade.


Information About the Software Upgrade


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 when running ESX 4.0.0 Update 1. This issue has been resolved in the ESX 4.1.0 release.

Figure 19

Non-Disruptive Upgrade Steps

This section provides information about the software upgrade. 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.

A non-disruptive upgrade takes place when you install one of the following VMware releases listed in Table 2.


Note Even if your have your ESX/ESXi host patch levels greater than the values in the Table 2, without installing ESX/ESXi400-201002001 or upgrade-from-esxi4.0-4.0_update02 a non-disruptive upgrade is not supported. Any patch level for 4.1.0 ensures a non-disruptive upgrade.

Table 2 Non-Disruptive Patch Level

ESX/ESXi
Non-Disruptive Patch Level

4.0.0

ESX/ESXi400-201002001

upgrade-from-esxi4.0-4.0_update02

4.1.0

Any patch level




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


The minimum ESX/ESXi patch level that is supported for upgrade is ESX/ESXi 4.0.0 Update 1.

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.2(1)SV1(4)


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

During the upgrade from Release 4.0(4)SV1(2, 3, 3a, or 3b) to Release 4.2(1)SV1(4), the interface configuration will be stored in the bootflash:system_eth.cfg.orig file. Modules which are present during the upgrade will automatically obtain the interface overrides from this configuration file. If any module comes on line after the upgrade, the user can use the interface configuration file to replay the needed configuration.

Information About Licensing

The following table summarizes licensing information following the upgrade.

Table 3 Post Upgrade License Status

Nexus 1000V Release
Evaluation Licenses
Permanent Licenses

SV1(3)
SV1(3a)
SV1(3b)

Carried over until expiration date

Carried over

SV1(2)

Carried over until expiration date

Carried over

SV1(1)

New licenses for 16 sockets are valid for 60 days

Carried over (Retires any evaluation licenses)


This release supports installation of additional evaluation license files.

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

For information about limitations and caveats, see the Cisco Nexus 1000V Release Notes, Release 4.2(1)SV1(4).

Upgrading to Release 4.2(1)SV1(4)

The upgrade procedures for the previous releases are covered in the following sections.


Note Is is highly recommended that you view the screencast on upgrading to Release 4.2(1)SV1(4) at http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_2_1_s_v_1_4/upgrade/screencast/guide/n1000v_upgrade_screencasts.html.


Upgrading from Release 4.0(4)SV1(3, 3a, or 3b) to Release 4.2(1)SV1(4)


Note To upgrade from Release 4.0(4)SV1(3c) to Release 4.2(1)SV1(4), use this procedure.



Note For ESX/ESXi 4.1.0 releases and later, the minimum VC/VUM version required is 258902/256596
For ESX/ESXi 4.0.0 releases and later, the minimum VC/VUM version required is 208111/282702.



Caution If you are upgrading on a Cisco Nexus 1010, make sure that the secondary VSM is active and the primary VSM is standby prior to initiating the upgrade. If the primary VSM is active, run the system switchover command to make the secondary VSM active.

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


Step 1 Upgrading the VEMs: Release 4.0(4)SV1(2, 3, 3a, 3b) to Release 4.2(1)SV1(4)

Step 2 Upgrading the VSMs to Release 4.2(1)SV1(4) Using the Upgrade Application


Figure 20

Upgrading from Release 4.0(4)SV1(3, 3a, or 3b) to Release 4.2(1)SV1(4)

Upgrading from Release 4.0(4)SV1(2) to Release 4.2(1)SV1(4)


Note For ESX/ESXi 4.1.0 releases and later, the minimum VC/VUM version required is 258902/256596
For ESX/ESXi 4.0.0 releases and later, the minimum VC/VUM version required is 208111/282702.


To perform the software upgrade from Release 4.0(4)SV1(2) to Release 4.2(1)SV1(4), follow these steps:


Step 1 Upgrading the VSMs: Release 4.0(4)SV1(2) to Release 4.0(4)SV1(3b)

Step 2 Upgrading the VEMs: Release 4.0(4)SV1(2, 3, 3a, 3b) to Release 4.2(1)SV1(4)

Step 3 Upgrading the VSMs to Release 4.2(1)SV1(4) Using the Upgrade Application


Figure 21

Upgrading from Release 4.0(4)SV1(2) to Release 4.2(1)SV1(4)

Upgrading from Release 4.0(4)SV1(1) to Release 4.2(1)SV1(4)


Note For ESX/ESXi 4.1.0 releases and later, the minimum VC/VUM version required is 258902/256596
For ESX/ESXi 4.0.0 releases and later, the minimum VC/VUM version required is 208111/282702.


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


Step 1 Upgrading the VSMs: Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3b)

Step 2 Upgrading the VEMs: Release 4.0(4)SV1(1) to Release 4.2(1)SV1(4)

Step 3 Upgrading the VSMs to Release 4.2(1)SV1(4) Using the Upgrade Application


Figure 22

Upgrading from Release 4.0(4)SV1(1) to Release 4.2(1)SV1(4)

Upgrading the VSMs

This section describes the VSM upgrade procedures that are supported in this release:

Upgrading the VSMs: Release 4.0(4)SV1(2) to Release 4.0(4)SV1(3b)

Upgrading the VSMs: Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3b)

Upgrading the VSMs to Release 4.2(1)SV1(4) Using the Upgrade Application

Upgrading the VSMs Manually on a Cisco Nexus 1010 from Release 4.0(4)SV1(3, 3a, or 3b) to Release 4.2(1)SV1(4)

Upgrading the VSMs: Release 4.0(4)SV1(2) to Release 4.0(4)SV1(3b)

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

Prerequisites to Upgrading the VSMs

The following are prerequisites to upgrading the VSMs:

Executing and correcting errors from the PreUpgradeUtility.

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

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

The following files have been copied to bootflash:

nexus-1000v-mz.4.0.4.SV1.3b.bin

nexus-1000v-kickstart-mz.4.0.4.SV1.3b.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.

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


Note This procedure is performed by the network administrator.



Note If you are upgrading on a Cisco Nexus 1010, make sure that the Secondary VSM is Active and the Primary VSM is Standby prior to initiating the upgrade.



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

switch# copy scp://root@192.0.2.13/N1K-VSM-images/nexus-1000v-mz.4.0.4.SV1.3b.bin 
bootflash:
Enter vrf (If no input, current vrf 'default' is considered):
root@192.0.2.13's password:
nexus-1000v-mz.4.0.4.SV1.3b.bin                                         100%   20MB   
1.1MB/s   00:19
switch#
 
switch# copy 
scp://root@192.0.2.13/N1K-VSM-images/nexus-1000v-kickstart-mz.4.0.4.SV1.3b.bin bootflash:
Enter vrf (If no input, current vrf 'default' is considered):
root@192.0.2.13's password:
nexus-1000v-kickstart-mz.4.0.4.SV1.3b.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.2.bin
   21982208     Jan 21 18:28:58 2010  nexus-1000v-kickstart-mz.4.0.4.SV1.3b.bin
   73068811     Dec 09 13:57:32 2009  nexus-1000v-mz.4.0.4.SV1.2.bin
   62280256     Jan 21 18:29:35 2010  nexus-1000v-mz.4.0.4.SV1.3b.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(3b) 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.3b.bin kickstart 
bootflash:nexus-1000v-kickstart-mz.4.0.4.SV1.3b.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 running-config startup-config
[########################################] 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.3b.bin sup-1
boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3b.bin sup-1
boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3b.bin sup-2
boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3b.bin sup-2
 
   
switch# show running-config | include boot
boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3b.bin sup-1
boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3b.bin sup-1
boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3b.bin sup-2
boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3b.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(2)     0.0 
2    4.0(4)SV1(2)     0.0 
3    4.0(4)SV1(2)     1.11 
4    4.0(4)SV1(2)     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
 
   

Step 6 Reload the standby VSM.

Used 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(2), synchronizes with the standby VSM running Release 4.0(4)SV1(3b).

switch# reload module 2
This command will reboot standby supervisor module. (y/n)?  [n] y 
about to reset standby sup
switch# 2010 Feb 11 09:57:42 n1000v %PLATFORM-2-PFM_MODULE_RESET: Manual restart of Module 
2 from Command Line Interface
2010 Feb 11 09:57:49 n1000v %PLATFORM-2-MOD_REMOVE: Module 2 removed (Serial number 
T5056972D88)
2010 Feb 11 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(2)     0.0 
2    4.0(4)SV1(3b)    0.0 
3    4.0(4)SV1(2)     1.11 
4    4.0(4)SV1(2)     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(3b).


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(3b)    0.0 
2    4.0(4)SV1(3b)    0.0 
3    4.0(4)SV1(2)     1.11 
4    4.0(4)SV1(2)     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(3b).

Use the system switchover command, to set module 1 as the active module and module 2 as the standby module.


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 to Release 4.2(1)SV1(4).

For details, see the "Upgrading the VEMs: Release 4.0(4)SV1(2, 3, 3a, 3b) to Release 4.2(1)SV1(4)" section.


Upgrading the VSMs: Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3b)

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

Prerequisites to Upgrading the VSMs

The following are prerequisites to upgrading the VSMs:

Executing and correcting errors from the PreUpgradeUtility.

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

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 VSMs.

nexus-1000v-mz.4.0.4.SV1.3b.bin

nexus-1000v-kickstart-mz.4.0.4.SV1.3b.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.2(1)SV1(4).

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


Note This procedure is performed by the network administrator.



Step 1 Backup the configuration to an external server.

Step 2 Power off all VMs except the VSM and VC.

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
 
   

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

switch(config)# boot system bootflash:nexus-1000v-mzg.4.0.4.SV1.3b.bin
2009 Dec 13 15:50:40.568 n1k-av %BOOTVAR-5-IMAGE_NOTEXISTS: Warning: image 
nexus-1000v-mz.4.0.4.SV1.3b.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.3b.bin to standby supervisor succeed
switch(config)# boot kickstart bootflash:nexus-1000v-kickstart-mzg.4.0.4.SV1.3b.bin
2009 Dec 13 15:54:03.093 n1k-av %BOOTVAR-5-IMAGE_NOTEXISTS: Warning: image 
nexus-1000v-kickstart-mz.4.0.4.SV1.3b.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.3b.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/OVA/OVF 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.3b.bin sup-1
boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3b.bin sup-1
boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3b.bin sup-2
boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3b.bin sup-2
 
   
switch# show running-config | include boot
boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3b.bin sup-1
boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3b.bin sup-1
boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3b.bin sup-2
boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3b.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(3b).


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(3b)     0.0 
2    4.0(4)SV1(3b)     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(3b).


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 to Release 4.2(1)SV1(4).

For details, see the "Upgrading the VEMs: Release 4.0(4)SV1(1) to Release 4.2(1)SV1(4)" section.


Upgrading the VEMs

This section describes the VEM upgrade procedures that are supported in this release:

Upgrading the VEMs: Release 4.0(4)SV1(2, 3, 3a, 3b) to Release 4.2(1)SV1(4)

Upgrading the VEMs: Release 4.0(4)SV1(1) to Release 4.2(1)SV1(4)

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.

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, make sure that you are at the appropriate patch levels. See Table 2.

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.2(1)SV1(4).


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

Upgrading the VEMs: Release 4.0(4)SV1(2, 3, 3a, 3b) to Release 4.2(1)SV1(4)

This section describes the steps to upgrade VEMs from Release 4.0(4)SV1(2, 3, 3a, 3b) to Release 4.2(1)SV1(4) and includes the following topics:

Upgrading the VEMs Using VMware Update Manager (VUM): Release 4.0(4)SV1(2, 3, 3a, or 3b) to Release 4.2(1)SV1(4)

Upgrading the VEMs Manually: Release 4.0(4)SV1(2, 3, 3a, or 3b) to Release 4.2(1)SV1(4)

Prerequisites to Upgrading VEMs

The following are prerequisites to upgrading the VEMs:

Executing and correcting errors from the PreUpgradeUtility.

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

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

Upgrading the VEMs Using VMware Update Manager (VUM): Release 4.0(4)SV1(2, 3, 3a, or 3b) to Release 4.2(1)SV1(4)

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 if you are not running the required patch level.



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



Caution If removable media is still connected, for example, if you have installed the VSM using ISO and forgot to remove the media, then host movement to maintenance mode fails and the VUM upgrade fails.


Step 1 Upload the vem-release_final.tar.gz file, system and kickstart images to the VSM's bootflash.

These files will be present in the zip folder of the FCS.

Step 2 Display the current configuration.

switch (config)# 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-201007101-BG
    DVS: VEM400-201007101-BG
 
   

Step 3 Update the ESX host version.

switch (config)# vmware vem upgrade update-vibs bootflash:vem-release_final.tar.gz
 
   

Step 4 Verify that the upgrade notification was sent.

switch (config)# show vmware vem upgrade status
Upgrade VIBs: Upgrade 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-201101030-RG  
    DVS: VEM400-201007101-BG
 
   

Note The VSM Bundle ID now deploys the Release 4.2(1)SV1(4) Bundle ID.


Step 5 Send upgrade notification to VC.

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 6 Verify that the upgrade notification was sent.

switch# show vmware vem upgrade status 
Upgrade VIBs: Upgrade 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-201101030-RG  
    DVS: VEM400-201007101-BG

Note Verify that the Upgrade Status contains the highlighted text. If the text is not present, check the Upgrade Error line and consult the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4).


Step 7 Verify that the server administrator has accepted the upgrade in the 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. After the server administrator accepts the upgrade, proceed with the VEM upgrade.

switch# show vmware vem upgrade status 
Upgrade VIBs: Upgrade 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-201101030-RG  
    DVS: VEM400-201007101-BG
 
   

Note Verify that Upgrade Status contains the highlighted text. If the text is not present, check the Upgrade Error line and consult the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4).


Step 8 Initiate the VUM upgrade process.


Caution Before entering the vmware vem upgrade proceed command, disable VMware High Availability (HA), Fault Tolerance (FT), and Distributed Power Management (DPM) in the cluster.

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

switch# vmware vem upgrade proceed
switch# show vmware vem upgrade status 
Upgrade VIBs: Upgrade 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-201101030-RG  
    DVS: VEM400-201101030-RG  

Note If the ESX/ESXi host is using VMware patch ESX/ESXi400-201002001, ESX/ESXi400-201006201, or ESX/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.



Note If VC/VUM version 4.0.0 Update1 or Update2 are hosted on ESX/ESXi, then VUM upgrade will fail for this host. You need to migrate the vCenter to another host that was successfully upgraded and run the vmware vem upgrade proceed command again.


Step 9 Check for the Upgrade Complete status.


Note If the upgrade status is not complete, see the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4).


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-201101030-RG  
    DVS: VEM400-201101030-RG 

Note The DVS bundle ID is updated and is highlighted. Before entering the following command, communicate wit the server administrator to confirm that the VUM process is operational.


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

switch# vmware vem upgrade complete
switch# show vmware vem upgrade status
Upgrade VIBs: Upgrade 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: VSM130-201010110-BG
    DVS: VSM130-201010110-BG 
 
   

Step 11 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.2(1)SV1(3b)     0.0 
2    4.2(1)SV1(3b)     0.0 
3    4.2(1)SV1(4)     VMware ESXi 4.0.0 Releasebuild-261974 (1.20) 
4    4.2(1)SV1(4)     VMware ESXi 4.1.0 Releasebuild-260247 (2.0) 
 
   
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 VEMs are upgraded to Release 4.2(1)SV1(4).


Step 12 Proceed to upgrade the VSM.


Caution If any VEM is not upgraded to Release 4.2(1)SV1(4) by VUM, perform a manual upgrade of the VEM before continuing with the VSM upgrade.

For details, see the "Upgrading the VSMs to Release 4.2(1)SV1(4) Using the Upgrade Application" section.


Upgrading the VEMs Manually: Release 4.0(4)SV1(2, 3, 3a, or 3b) to Release 4.2(1)SV1(4)

To manually install or upgrade the Cisco Nexus 1000V VEM on an ESX/ESXi host, follow the steps in the "Installing or Upgrading the VEM Software Using the CLI" section in the Cisco Nexus 1000V Virtual Ethernet Module Software Installation and Upgrade Guide, Release 4.2(1)SV1(4).

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 if you are not running the required patch level.



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



Caution If removable media is still connected, for example, if you have installed the VSM using ISO and forgot to remove the media, then host movement to maintenance mode fails and the VUM upgrade fails.


Step 1 Upload the vem-release_final.tar.gz file, system and kickstart images to the VSM's bootflash.

These files will be present in the zip folder of the FCS.

Step 2 Update the ESX host version.

switch (config)# vmware vem upgrade update-vibs bootflash:vem-release_final.tar.gz
 
   

Step 3 Send upgrade notification to VC.

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 4 Verify that the upgrade notification was sent.

switch (config)# show vmware vem upgrade status
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-201101030-RG  
    DVS: VEM400-201007101-BG
 
   

Step 5 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: Upgrade 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-201101030-RG  
    DVS: VEM400-201007101-BG
 
   

Step 6 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 esxupdate command. For details, see the Cisco Nexus 1000V Virtual Ethernet Module Software Installation and Upgrade Guide, Release 4.2(1)SV1(4).

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

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 7 Initiate the Cisco Nexus 1000V Bundle ID upgrade process.


Note If VUM is enabled in the vCenter environment, disable it before running 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

Note If VUM is not installed, the "The object or item referred to could not be found. A general system error occurred: unknown internal error" error appears in the vCenter Server's task bar and can be safely ignored.


switch# show vmware vem upgrade status 
Upgrade VIBs: Upgrade VEM Image
Upgrade Status: Upgrade Errored in vCenter. Please check UpgradeError for more details.
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: [VMware vCenter Server 4.1.0 build-258902] A general system error occurred: 
unknown internal error.
Upgrade Bundle ID:
    VSM: VEM400-201101030-RG  
    DVS: VEM400-201101030-RG  
 
   

Step 8 Check for the Upgrade Complete status.


Note If the upgrade status is not complete, see the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4).


switch# show vmware vem upgrade status
Upgrade VIBs: Upgrade 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-201101030-RG  
    DVS: VEM400-201101030-RG  
 
   

Step 9 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 Virtual Ethernet Module Software Installation and Upgrade Guide, Release 4.2(1)SV1(4).

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

switch# vmware vem upgrade complete
switch# show vmware vem upgrade status
Upgrade VIBs: Upgrade 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-201101030-RG  
    DVS: VEM400-201101030-RG  
 
   

Step 11 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.2(1)SV1(3b)     0.0 
2    4.2(1)SV1(3b)     0.0 
3    4.2(1)SV1(4)     VMware ESXi 4.0.0 Releasebuild-261974 (1.20) 
4    4.2(1)SV1(4)     VMware ESXi 4.1.0 Releasebuild-260247 (2.0) 
 
   
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 VEMs are upgraded to Release 4.2(1)SV1(4).


Step 12 Proceed to upgrade the VSM.


Caution Do not proceed with the VSM upgrade if all VEMs are not upgraded to Release 4.2(1)SV1(4). Upgrade all VEMs to Release 4.2(1)SV1(4) before upgrading the VSMs.

For details, see the "Upgrading the VSMs to Release 4.2(1)SV1(4) Using the Upgrade Application" section.


Upgrading the VEMs: Release 4.0(4)SV1(1) to Release 4.2(1)SV1(4)

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

Upgrading the VEMs: Release 4.0(4)SV1(1) to Release 4.2(1)SV1(4)

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

Prerequisites to Upgrading VEMs

The following are prerequisites to upgrading the VEMs:

Executing and correcting errors from the PreUpgradeUtility.

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

You have already upgraded the VSM to Release 4.0(4)SV1(3b).

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

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

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 and VC are 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.2(1)SV1(4).


Step 1 Power off all virtual machines.

Step 2 Update the VEM host version.

switch (config)# vmware vem upgrade update-vibs bootflash:vem-release_final.tar.gz 
 
   

Step 3 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 4 Verify that the upgrade notification was sent.

switch (config)# show vmware vem upgrade status
Upgrade VIBs: Upgrade 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-20100830100-BG
    DVS: VEM400-200904001-BG

Note Verify that Upgrade Status contains the highlighted text. If the text is not present, check the Upgrade Error line and consult the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4).


Step 5 Verify that the server administrator has accepted the upgrade in the 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. After the server administrator accepts the upgrade, proceed with the VEM upgrade.

switch (config)# show vmware vem upgrade status
Upgrade VIBs: Upgrade 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-20100830100-BG
    DVS: VEM400-200904001-BG
 
   

Step 6 Initiate the VUM upgrade process.

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


Note 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: Upgrade 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): 
Upgrade Error: 
Upgrade Bundle ID:
    VSM: VSM130-201010110-BG
    DVS: VSM130-201010110-BG
 
   

Step 7 Check for the Upgrade Complete status.


Note If VUM is not installed, the "The object or item referred to could not be found. A general system error occurred: unknown internal error" error appears in the vCenter Server's task bar and can be safely ignored.


switch# show vmware vem upgrade status 
Upgrade VIBs: Upgrade 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: VSM130-201010110-BG
    DVS: VSM130-201010110-BG
 
   

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: Upgrade 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: VSM130-201010110-BG
    DVS: VSM130-201010110-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.2(1)SV1(3b)     0.0 
2    4.2(1)SV1(3b)     0.0 
3    4.2(1)SV1(4)     VMware ESXi 4.0.0 Releasebuild-261974 (1.20) 
4    4.2(1)SV1(4)     VMware ESXi 4.1.0 Releasebuild-260247 (2.0) 
 
   
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 all VEMs are upgraded to Release 4.2(1)SV1(4).


Step 10 Proceed to upgrade the VSM.


Caution If any VEM is not upgraded to Release 4.2(1)SV1(4) by VUM, perform a manual upgrade of the VEM before continuing with the VSM upgrade.

For details, see the "Upgrading the VSMs to Release 4.2(1)SV1(4) Using the Upgrade Application" section.


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

To upgrade the VEMs manually, the network administrator initiates the upgrade process as described below.


Note Before proceeding with the upgrade, make sure the VMs are powered off. The VSM must be upgraded to Release 4.0(4)SV1(3b).



Step 1 Update the ESX host version.

switch (config)# vmware vem upgrade update-vibs bootflash:vem-release_final.tar.gz
 
   

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: Upgrade VEM Image
Upgrade Status: Upgrade Availability Notified in vCenter
Upgrade Notification Sent Time: 
Upgrade Status Time(vCenter):  
Upgrade Start Time: 
Upgrade End Time(vCenter): 
Upgrade Error: 
Upgrade Bundle ID:
    VSM: VEM400-201101030-RG  
    DVS: VEM400-200904001-BG

Note Verify that Upgrade Status contains the highlighted text. If the text is not present, check the Upgrade Error line and consult the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4).


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: Upgrade VEM Image
Upgrade Status: Upgrade In Progress in vCenter
Upgrade Notification Sent Time: 
Upgrade Status Time(vCenter):  
Upgrade Start Time: Thu Mar 18 15:37:31 2010
Upgrade End Time(vCenter): 
Upgrade Error: 
Upgrade Bundle ID:
    VSM: VEM400-201101030-RG  
    DVS: VEM400-201003101-BG 
 
   

Step 5 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 Virtual Ethernet Module Software Installation and Upgrade Guide, Release 4.2(1)SV1(4).

If the ESX host is not hosting the VSM/VC, then proceed to Step 6.

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

Step 6 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.
If VUM is disabled, any error in the output of the show vmware vem upgrade status command when entering the vmware vem upgrade proceed command can be ignored.


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 to 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 
2010 Mar 18 15:37:45 switch %VMS-5-DVS_UPGRADE_INFO: VEM Upgrade is completed successfully 
in vCenter. 
 
   
Upgrade VIBs: Upgrade VEM Image
Upgrade Status: Upgrade Complete in vCenter
Upgrade Notification Sent Time: 
Upgrade Status Time(vCenter):  
Upgrade Start Time: Thu Mar 18 15:37:31 2010
Upgrade End Time(vCenter): Thu Mar 18 17:47:07 2010
Upgrade Error: 
Upgrade Bundle ID:
    VSM: VEM400-201101030-RG  
    DVS: VEM400-201101030-RG  

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: Upgrade VEM Image
Upgrade Status:
Upgrade Notification Sent Time:
Upgrade Status Time(vCenter):
Upgrade Start Time:
Upgrade End Time(vCenter):
Upgrade Error:
 
   

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.2(1)SV1(3b)     0.0 
2    4.2(1)SV1(3b)     0.0 
3    4.2(1)SV1(4)     VMware ESXi 4.0.0 Releasebuild-261974 (1.20) 
4    4.2(1)SV1(4)     VMware ESXi 4.1.0 Releasebuild-260247 (2.0) 
 
   
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.2(1)SV1(4).


Step 9 Proceed to upgrade the VSM.


Caution Do not proceed with the VSM upgrade if all VEMs are not upgraded to Release 4.2(1)SV1(4). Upgrade all VEMs to Release 4.2(1)SV1(4) before upgrading the VSMs.

For details, see "Upgrading the VSMs to Release 4.2(1)SV1(4) Using the Upgrade Application" section.


Upgrading the VSMs to Release 4.2(1)SV1(4) Using the Upgrade Application


Note This upgrade procedure applies to upgrades from Release 4.0(4)SV1(3), Release 4.0(4)SV1(3a), or Release 4.0(4)SV1(3b).


This section describes upgrading the VSM from Release 4.0(4)SV1(3b) to Release 4.2(1)SV1(4). The Upgrade Application is the recommended method of upgrading the VSM from Release 4.0(4)SV1(3), Release 4.0(4)SV1(3a), or Release 4.0(4)SV1(3b) to Release 4.2(1)SV1(4).


Caution If you are upgrading on a Cisco Nexus 1010, make sure that the secondary VSM is active and the primary VSM is standby prior to initiating the upgrade. If the primary VSM is active, run the system switchover command to make the secondary VSM active.

Prerequisites to Using the Cisco Nexus 1000V Upgrade Application

The following are prerequisites to using the upgrade application:

Executing and correcting errors from the PreUpgradeUtility.

VEMs are upgraded to Release 4.2(1)SV1(4) first to complete the VEM upgrade.

Upload the VSM (kickstart and system) images to the bootflash.

You might need up to three additional IP addresses in the same subnet as the VSM mgmt0 and control0.

You will need to enter additional IP addresses that are in the same subnet depending on your L2 or L3 setup. This additional IP address is required since one VSM will be on a previous release and the other VSM will be on Release 4.2(1)SV1(4).


Caution If the IP addresses are not in the same subnet, the system will be in an inconsistent state. See the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4) to recover the system.

SSH enabled on the VSM.

A synchronized HA pair is mandatory prior to starting the Upgrade Application.

If Authentication, Authorization, and Accounting (AAA) servers are used for authentication, add the temporary IP address used in the upgrade to the authentication database.


Note During this hitless VSM upgrade procedure, the VEMs connected via L3 will flap during the upgrade when temporary IP addresses are programmed. Traffic flow will not be affected.


To perform a VSM software upgrade from Release 4.0(4)SV1(3), Release 4.0(4)SV1(3a), or Release 4.0(4)SV1(3b) to Release 4.2(1)SV1(4) by using the Upgrade Application, follow these steps:


Note This procedure is performed by the network administrator.



Note If you are upgrading on a Cisco Nexus 1010, make sure that the Secondary VSM is Active and the Primary VSM is Standby prior to initiating the upgrade. For more information about upgrade the Cisco Nexus 1010, see Upgrading the VSMs Manually on a Cisco Nexus 1010 from Release 4.0(4)SV1(3, 3a, or 3b) to Release 4.2(1)SV1(4).



Caution If removable media is still connected, for example, if you have installed the VSM using ISO and forgot to remove the media, then host movement to maintenance mode fails and the VUM upgrade fails.


Step 1 Perform a backup of the configuration to external storage.

Step 2 In the browser address field, enter the VSM IP address and press Enter.

The Cisco Nexus 1000V screen opens.

Figure 23

Cisco Nexus 1000V Upgrade Application: Initial Window

Step 3 Click the Launch Upgrade Application link.

The application download begins.


Note If no VEMs are attached, the Launch Upgrade Application link is not present. If you still wish to upgrade, you can run the Upgrade Application from the http://<vsm-ip-address>/cgi-bin/upgrade.jnlp directory.


Step 4 Click Run in the Warning - Security window.

The Enter VSM Credentials screen opens.

Figure 24

Nexus 1000v Upgrade: Enter VSM Credentials

Step 5 Enter the VSM password and click Next.

The Verify Module Upgrade screen opens.

Figure 25

Nexus 1000v Upgrade: Verify Module Upgrade

Step 6 Verify that the module count is correct.

Step 7 If you have an L2 configuration, continue with Step 8. If you have an L3 configuration, proceed to Step 9.

Figure 26

Nexus 1000v Upgrade: Enter Upgrade Information for L2

Step 8 Perform the following sub-steps:

a. Enter a temporary IPv4 IP address for interface mgmt0.

b. Select nexus-1000v-mz.4.2.1.SV1.4.bin from the New System Image drop-down.

c. Select nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin from the New Kickstart Image drop-down.

d. Click Next. The Summary: Please Review Configurations screen opens.

e. Proceed to Step 10.

Figure 27

Nexus 1000v Upgrade: Enter Upgrade Information for L3

Step 9 Perform the following sub-steps:

a. Enter a temporary IPv4 IP address for interface mgmt0.

b. Enter a temporary IPv4 IP address for L3 interface control0.

c. Select nexus-1000v-mz.4.2.1.SV1.4.bin from the New System Image drop-down.

d. Select nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin from the New Kickstart Image drop-down.

e. Click Next. The Summary: Please Review Configurations screen opens.

f. Continue to Step 10.

If you have an L2 configuration, Figure 28 opens. If you have an L3 configuration, Figure 29 opens.

Figure 28

Nexus 1000v Upgrade: Layer 2 - Please Review Configurations

Figure 29

Nexus 1000v Upgrade: Layer 3 - Please Review Configurations

Step 10 Confirm the settings and click Next.

The Upgrade Progress screen opens and the upgrade of the secondary VSM begins. Continue to Step 11.


Caution This step will take a few minutes to complete. If you close this window, your setup will be left in an inconsistent state.

Figure 30

Nexus 1000V Upgrade: Secondary VSM Upgrade Progress


Note Depending on the number of VEMs, this portion of the upgrade might take a few minutes.


Step 11 When the upgrade process completes, click Next.

The Verify Module Insertion screen opens.

Figure 31

Nexus 1000v Upgrade: Verify Module Insertion

Step 12 If you are having L3 connectivity using control0 to connect to VEMs, then continue with this step, otherwise move to Step 13.

a. Log in to the temporary IP address of the VSM or console of Release 4.2(1)SV1(4) VSM.

b. Check if there are sub-net or default routes associated with the control0 interface. This can be achieved by:

Running the show running-config command

Look for routes under vrf context management

vrf context management
  ip route 0.0.0.0/0 10.78.108.129
  ip route 192.168.1.0/24 192.168.2.1 

Note The highlighted IP address is the subnet route for VEM connectivity via control0 interface.


c. Select only the routes that are used for VEM connectivity and move them under global config context.

VSM(config)# ip route 192.168.1.0/24 192.168.2.1
VSM(config)# vrf context management 
VSM(config-vrf)# no ip route 192.168.1.0/24 192.168.2.1
 
   

Caution Do not save the running configuration to the startup configuration until the upgrade procedure is complete.

Step 13 Log in to the temporary IP address of the VSM or console of Release 4.2(1)SV1(4) VSM and check if the module status is "ok"'.

If the module status is not "ok", refer to the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4). Do not proceed unless all modules are in status "ok".

Step 14 Click Finish when all modules in the temporary IP VSM display a status of "ok".


Note If you decide not to upgrade, click the Override: Force Upgrade button to leave the VEMs on a previous release. If you take this action, your VEMs will be in an inconsistent state which is not a supported model for the Cisco Nexus 1000V.


When finished, click Next.

Step 15 Log in to the temporary IP address or console of the Release 4.2(1)SV1(4) VSM and check if the module status is 'ok'. If not "ok", refer to Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4). Do not proceed unless all modules are in status "ok".

Step 16 If you are having L3 control mode of the testbed, then continue with this step, otherwise continue with Step 19.

Step 17 Click Finish when all modules in temporary IP VSM are displaying a status = ok.

Step 18 At this point in the upgrade process, you will see one of two screens:

If the screen contains one table with the heading of The following modules have been attached, click Finish and the upgrade of the second VSM will begin.

If the screen contains a second table with the heading of The following modules are missing, you should click Refresh List. Prior to clicking Finish, log in to the VSM and run the show module command.

If the module status is OK, click Finish.

The Verify Module Insertion window opens for the second VSM upgrade.

If the module status is not OK, proceed to the troubleshooting section before clicking Finish.

Figure 32

Nexus 1000v Upgrade: Second VSM Upgrade


Note This step can take several minutes to complete. Do not cancel the wizard.


When the upgrade of the second VSM completes, the Summary screen opens.

Figure 33

Nexus 1000v Upgrade: Summary

Step 19 Click Close.

The upgrade of the VSMs is complete.

Step 20 To display the virtual device context ID of the VSM, run the following command:

switch(config)# sho run | include vdc
vdc N1KV-VSM id 1
 
   

Step 21 To be able to support 2048 VLANs, run the following command.

switch(config)# vdc NIKV-VSM id 1
switch(config-vdc)# limit-resource vlan minimum 16 maximum 2049
 
   

The upgrade is complete.


Upgrading the VSMs Manually on a Cisco Nexus 1000V from Release 4.0(4)SV1(3, 3a, or 3b) to Release 4.2(1)SV1(4)

This section describes how to manually upgrade to Release 4.2(1)SV1(4) from Release 4.0(4)SV1(3, 3a, or 3b) by using the CLI.

Prerequisites to Upgrading the VSMs

The following are prerequisites to upgrading the VSMs:

Executing and correcting errors from the PreUpgradeUtility.

VEMs are upgraded to Release 4.2(1)SV1(4).

The kickstart and system images have been uploaded to the bootflash.

You might need up to three additional IP addresses in the same subnet as the VSM mgmt0 and control0.


Caution If the IP addresses are not in the same subnet, the system will be in an inconsistent state. See the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4).

SSH is enabled on the VSM.

A VSM HA environment is mandatory for the upgrade to proceed.

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

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.

If Authentication, Authorization, and Accounting (AAA) servers are used for authentication, add the temporary IP address used in the upgrade to the authentication database.


Note The Upgrade Application is the recommended method of upgrading.


The two VSMs are identified as VSM1 and VSM2 which are the active and standby VSMs respectively.

To manually upgrade to Release 4.2(1)SV1(4), follow these steps:


Step 1 Log in to the VSM.

Step 2 Copy the kickstart and isan images to the bootflash: file system.

switch# copy scp:root@192.0.2.13/N1K-VSM-images/nexus-1000v-mz.4.2.1.SV1.4.bin bootflash:

switch# copy scp:root@192.0.2.13/N1K-VSM-images/nexus-1000v-kickstart.mz.4.2.1.SV1.4.bin bootflash:

Step 3 Display the current redundancy status.

switch# show module

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
 
   
Mod  Sw               Hw 
---  ---------------  ------ 
1    4.0(4)SV1(3b)    0.0 
2    4.0(4)SV1(3b)    0.0 
3    4.2(1)SV1(4)     VMware ESXi 4.1.0 Releasebuild-260247 (2.0) 1.9 
 
   
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 
 
   
Mod  Server-IP       Server-UUID                           Server-Name
---  -------------   ------------------------------------  --------------------
1    172.23.233.64   NA                                    NA
2    172.23.233.64 	NA                                    NA
3    172.23.232.72 	33393935-3234-5553-4538-35314e323554 172.23.232.72
* this terminal session 
 
   

switch# show system redundancy status

bl-n1000v# show system redun status
Redundancy role
---------------
      administrative:   primary
         operational:   primary
 
   
Redundancy mode
---------------
      administrative:   HA
         operational:   HA
 
   
This supervisor (sup-1)
-----------------------
    Redundancy state:   Active
    Supervisor state:   Active
      Internal state:   Active with HA standby
 
   
Other supervisor (sup-2)
-----------------------
    Redundancy state:   Standby
    Supervisor state:   HA standby
      Internal state:   HA standby
 
   

Step 4 Display the current connections to the Cisco Nexus 1000V.

switch# show svs connections
connection vcenter:
    ip address: 192.0.2.10
    remote port: 80
    protocol: vmware-vim https
    certificate: default
    datacenter name: sachinDC
    DVS uuid: 0c bf 0b 50 0b 4a b7 76-88 13 be 45 14 e8 9b 4e
    config status: Enabled
    operational status: Connected
    sync status: Complete
    version: VMware vCenter Server 4.0.0 build-208111

Step 5 Inform the VEMs that the upgrade process is starting and assign the temporary IP address to VSM2.


Note If you are using Layer 3 mode with the control0 interface, assign the temporary IP address to mgmt0 and control0 by using the svs upgrade start mgmt0 ip ipaddr control0 ipaddr command.


switch# configure terminal


Note The value of ipaddr in the following command is the temporary IP address that will be used to access VSM2 while the HA pair is split.


switch(config)# svs upgrade start mgmt0 ip ipaddr

WARNING!
1. Please do not change the configuration of the system from this point onwards
2. Ensure that all relevant ports, including uplinks, vmknics, and vsifs used for control, 
packet, management, storage as well as VSM ports, are all configured with system profiles
3. Ensure there is network connectivity between VC, VSM pair, and the hosts/modules
4. Ensure all the hosts/modules are upgraded with the next version of VEM software package
switch(config)# end

Step 6 Update the system and kickstart boot variables.

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

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.

Upgrade in process, hence Active boot variables are not updated.

Boot variables are updated to running configuration.

Step 7 Copy the running configuration to the startup configuration and verify.

switch# copy running-config startup-config

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

switch# show start | in boot

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

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

boot kickstart bootflash:/nexus-1000v-kickstart-mzg.4.2.1.SV1.4.bin sup-2

boot system bootflash:/nexus-1000v-mzg.4.2.1.SV1.4.bin sup-2


Note The following commands display that the active VSM (sup-1) is still on Release 4.0(4)SV1(3b) and the standby VSM is now on Release 4.2(1)SV1(4).


Step 8 Reload the VSM whose boot variables are set to Release 4.2(1)SV1(4).

switch# reload module slot

This command will reboot standby supervisor module. (y/n)? [n] y
2010 June 14 20:11:51 av1-vsm %PLATFORM-2-PFM_MODULE_RESET: Manual restart of Module 2 
from Command Line Interface
switch# 2010 Jun 14 20:11:58 av1-vsm %PLATFORM-2-MOD_REMOVE: Module 2 removed (Serial 
number T50569A5039

Step 9 Log in to VSM2 using the temporary IP address.

Step 10 Confirm that VSM2 is now standalone.

switch# show system redundancy status

Redundancy role

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

    administrative:  standalone

       operational:  standalone

Redundancy mode

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

    administrative:  HA

       operational:  None

This supervisor (sup1)

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

   Redundancy state:  Active

   Supervisor state:  Active

     Internal state:  Active with no standby

Other supervisor (sup-2)

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

    Redundancy State:  Not present

Step 11 On VSM1, remove the connection between VSM1 and the vCenter Server.


Caution This step is being performed to prevent opaque data from being pushed to the vCenter Server. Not performing this step could adversely impact the VEMs.

switch# show running-config

svs-domain

  domain id 470

  control vlan 233

  packet vlan 233

  svs mod L2

  svs upgrade start mgmt0 ip 172.23.231.133.66

svs connection vc

  protocol vmware-vim

  remote up address 172.23.231.133 port 80

  vmware dvs uuid "0c bf 0e 50 0b 4a b7 76-88 13 be 45 14 e8 9b 4e" datacenter-name 
sachinDC
  connect

switch# config t

switch# (config)# svs connection vc

switch# (config-svs-conn)# no connect

Step 12 Change VSM1's role to secondary.

switch(config-svs-conn)# end

switch(config)# end

switch# system redundancy role secondary

Setting will be activated on next reload

switch# show run | in boot

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

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

boot kickstart bootflash:/nexus-1000v-kickstart-mzg.4.2.1.SV1.4.bin sup-2

boot system bootflash:/nexus-1000v-mzg.4.2.1.SV1.4.bin sup-2

Step 13 Change the boot variables on VSM1 to point to the Release 4.2(1)SV1(4) images.

switch# config t

Enter configuration commands, one per line. End with CNTL/Z.

switch(config)# boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin

switch(config)# no boot system bootflash:/nexus-1000v.mzg.4.0.4.SV1.3b.bin sup-1

switch(config)# boot system bootflash:/nexus-1000v-mz.4.2.1.SV1.4.bin sup-1

switch(config)# end

switch# show run | in boot

boot kickstart bootflash:/nexus-1000v-kickstart-mzg.4.2.1.SV1.4.bin sup-1

boot system bootflash:/nexus-1000v-mzg.4.2.1.SV1.4.bin sup-1

boot kickstart bootflash:/nexus-1000v-kickstart-mzg.4.2.1.SV1.4.bin sup-2

boot system bootflash:/nexus-1000v-mzg.4.2.1.SV1.4.bin sup-2

Step 14 Save the configuration on VSM1.

switch# copy running-config startup-config

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

Step 15 Display the current connections on VSM2.

switch# config t

Enter configuration commands, one per line. End with CNTL/Z.

switch(config)# show svs connect

connection vcenter:

ip address: 172.23.231.133

remote port: 80

protocol: vmware-vim https

certificate: default

datacenter name: n1000vDC

DVS uuid: 0c bf 0b 50 0b 4a b7 76-88 13 be 45 14 e8 9b 4e

config status: Enabled

operational status: Disconnected

sync status: -

version: -

Step 16 If you are having L3 connectivity using control0 to connect to VEMs, then continue with this step, otherwise move to Step 17.

a. Log in to the temporary IP address of the VSM or console of Release 4.2(1)SV1(4) VSM.

b. Check if there are sub-net or default routes associated with the control0 interface. This can be achieved by:

Running the show running-config command

Look for routes under vrf context management

vrf context management
  ip route 0.0.0.0/0 10.78.108.129
  ip route 192.168.1.0/24 192.168.2.1 

Note The highlighted IP address is the subnet route for VEM connectivity via control0 interface.


c. Select only the routes that are used for VEM connectivity and move them under global config context.

VSM(config)# ip route 192.168.1.0/24 192.168.2.1
VSM(config)# vrf context management 
VSM(config-vrf)# no ip route 192.168.1.0/24 192.168.2.1
 
   

Caution Do not save the running configuration to the startup configuration until the upgrade procedure is complete.

Step 17 Log in to the temporary IP address of the VSM or console of Release 4.2(1)SV1(4) VSM and check if the module status is "ok"'.

If the module status is not "ok", refer to the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4). Do not proceed unless all modules are in status "ok".

Step 18 Inform the VEMs that the upgrade process has completed.


Note Make sure that all the VEMs are attached to the Release 4.2(1)SV1(4) VSM. Verify by comparing the number of VEMs that were attached to the Release 4.0(4)SV1(3b) VSM match the number of VEMs that are attached to the Release 4.2(1)SV1(4) VSM. Check for module status = "ok".


switch# config t

Enter configuration commands, one per line. End with CNTL/Z.

switch(config)# svs upgrade complete

Warning: Config saved but not pushed to vCenter Server due to inactive connection!

switch(config)# end

switch# show run | in svs

svs-domain

  svs mode L2

  svs upgrade complete

svs connection vc

switch# config t

Enter configuration commands, one per line. End with CNTL/Z.

switch(config)# svs connection name

switch(config-svs-conn)# connect

switch(config-svs-conn)# end

switch(config)# end

switch# show module

Mod  Ports  Module-Type                      Model              Status
---  -----  -------------------------------- ------------------ ------------
1    0      Virtual Supervisor Module        Nexus1000V         active *
3    248    Virtual Ethernet Module          NA                 ok
 
   
Mod  Sw               Hw 
---  ---------------  ------ 
1    4.2(1)SV1(3b) 0.0 
3    4.2(1)SV1(4)     VMware ESXi 4.0.0 Releasebuild-208167 (1.9)1.9 
 
   
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 
 
   
Mod  Server-IP 					Server-UUID                           Server-Name
---  ------------- 	------------------------------------  --------------------
1    172.23.233.64 	NA                                    NA
3    172.23.232.72 	33393935-3234-5553-4538-35314e323554 sfish-srvr-72
* this terminal session 

Step 19 Change VSM2 role to primary.

switch# system redundancy role primary

Step 20 Reload VSM1.

switch# show module

switch# show run int mgmt0

!Command: show running-config interface mgmt0

!Time: Mon Jun 14 20:27:27 2010

version 4.2(1)SV1(4)

interface mgmt0

  ip address 192.0.2.11/24

switch# reload

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

switch# copy running-config startup-config

switch# reload

Step 21 Change VSM2's mgmt0 IP address back to the shared IP address.

switch# show run int mgmt0

switch# config t

switch(config)# int mgmt0

switch(config-if)# ip address 192.0.2.11 255.255.255.0

Step 22 Confirm upgraded HA pair.

switch# show system redundancy status

Redundancy role
---------------
      administrative:   primary
         operational:   primary
 
   
Redundancy mode
---------------
      administrative:   HA
         operational:   None
 
   
This supervisor (sup-1)
-----------------------
    Redundancy state:   Active
    Supervisor state:   Active
      Internal state:   Active with HA standby
 
   
Other supervisor (sup-2)
-----------------------
    Redundancy state:   Standby
    Supervisor state:   HA standby
      Internal state:   HA standby
 
   

Step 23 Save the configuration.

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

Upgrading the VSMs Manually on a Cisco Nexus 1010 from Release 4.0(4)SV1(3, 3a, or 3b) to Release 4.2(1)SV1(4)

This section describes the VSM manual upgrade procedure from Release 4.0(4)SV1(3, 3a, or 3b) to Release 4.2(1)SV1(4).

Prerequisites to Upgrading the VSMs

The following are prerequisites to upgrading the VSMs:

Executing and correcting errors from the PreUpgradeUtility.

VEMs are upgraded to Release 4.2(1)SV1(4) first to complete the VEM upgrade.

Upload the kickstart and system images to the bootflash.

You might need up to additional IP addresses in the same subnet as the VSM mgmt0 and control0 depending on your Layer 2 or Layer 3 setup. The additional IP address is required since one VSM will be on a previous release and the other VSM will be on Release 4.2(1)SV1(4).


Caution If the IP addresses are not in the same subnet, the system will be in an inconsistent state. See the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4) to recover the system.

SSH is enabled on the VSM.

The Cisco Nexus 1010 systems are in an HA configuration.

Make sure the the secondary VSM is active and the primary VSM is standby.

You have saved all changes in the running configuration to the startup configuration.

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


Note The Upgrade Application is the recommended method of upgrading.

This procedure is performed by the network administrator.

The two VSMs are identified as VSM1 and VSM2 which are the active and standby VSMs respectively.


To perform a manual upgrade to Release 4.2(1)SV1(4), follow these steps:


Step 1 Log in to the VSM.

Step 2 Copy the kickstart and isan images to the bootflash: file system.

switch# copy scp://root@192.0.2.13/N1K-VSM-images/nexus-1000v-mz.4.2.1.SV1.4.bin 
bootflash:
Enter vrf (If no input, current vrf 'default' is considered):
root@192.0.2.13's password:
nexus-1000v-mz.4.2.1.SV1.4.bin                                         100%   20MB   
1.1MB/s   00:19
switch#
 
switch# copy scp://root@192.0.2.13/N1K-VSM-images/nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin 
bootflash:
Enter vrf (If no input, current vrf 'default' is considered):
root@192.0.2.13's password:
nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin                                         100%   
20MB   1.1MB/s   00:19
switch#
 
   

Step 3 Display the current redundancy status.

switch# show module
switch# show module 
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
 
   
Mod  Sw               Hw      
---  ---------------  ------  
1    4.0(4)SV1(3)     0.0    
2    4.0(4)SV1(3)     0.0    
3    4.2(1)SV1(4)     1.9    
 
   
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         
 
   
Mod  Server-IP        Server-UUID                           Server-Name
---  ---------------  ------------------------------------  --------------------
1    192.0.2.11     NA                                    NA
2    192.0.2.11     NA                                    NA
3    10.78.109.51     4220900d-76d3-89c5-17d7-b5a7d1a2487f  10.78.109.51
 
   
switch# show system redundancy status 
Redundancy role
---------------
      administrative:   secondary
         operational:   secondary
 
   
Redundancy mode
---------------
      administrative:   HA
         operational:   HA
 
   
This supervisor (sup-2)
-----------------------
    Redundancy state:   Active
    Supervisor state:   Active
      Internal state:   Active with HA standby                  
 
   
Other supervisor (sup-1)
------------------------
    Redundancy state:   Standby
    Supervisor state:   HA standby
      Internal state:   HA standby  
 
   

Step 4 Display the current connections to the Cisco Nexus 1000V.

switch# show svs connections 
connection vcenter:
    ip address: 192.0.2.10
    remote port: 80
    protocol: vmware-vim https
    certificate: default
    datacenter name: SWAMY
    DVS uuid: 5e ca 20 50 bc 28 07 fb-0b 1d 98 56 40 cb fd 85
    config status: Enabled
    operational status: Connected
    sync status: Complete
    version: VMware vCenter Server 4.0.0 build-258672
 
   
 
   

Step 5 Inform the VEMs that the upgrade process is starting and assign the temporary IP address to VSM2.

If you are using Layer 3 mode with control0, go to Step 6.


Note If Authentication, Authorization, and Accounting (AAA) servers are used for authentication, add the temporary IP address used in the upgrade to the authentication database.


switch# configure terminal

Note The value of ipaddr in the following command is the temporary IP address that will be used to access VSM2 while the HA pair is split.


switch(config)# svs upgrade start mgmt0 ip ipaddr 
WARNING!
1. Please do not change the configuration of the system from this point onwards
2. Ensure that all relevant ports, including uplinks, vmknics, and vsifs used for control, 
packet, management, storage as well as VSM ports, are all configured with system profiles
3. Ensure there is network connectivity between VC, VSM pair, and the hosts/modules
4. Ensure all the hosts/modules are upgraded with the next version of VEM software package
switch(config)# end
 
   

Go to Step 7.

Step 6 Inform the VEMs that the upgrade process is starting and assign the temporary IP address to VSM2 mgmt0 and control0 interfaces.

switch(config)# svs upgrade start mgmt0 ip ipaddr control0 ip ipaddr 
WARNING!
1. Please do not change the configuration of the system from this point onwards
2. Ensure that all relevant ports, including uplinks, vmknics, and vsifs used for control, 
packet, management, storage as well as VSM ports, are all configured with system profiles
3. Ensure there is network connectivity between VC, VSM pair, and the hosts/modules
4. Ensure all the hosts/modules are upgraded with the next version of VEM software package
switch(config)# end
 
   

Step 7 Update the system and kickstart boot variables.

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 
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.
Upgrade in progress, hence Active boot variables are not updated.
Boot variables are updated to running configuration.
 
   

Step 8 Copy the running configuration to the startup configuration and verify.

switch# copy running-config startup-config 
[########################################] 100%
switch# show startup-config | in boot 
boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin sup-1
boot system bootflash:/nexus-1000v-mz.4.2.1.SV1.4.bin sup-1
boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3.bin sup-2
boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3.bin sup-2

Note The following commands displays that the active VSM (sup-2) is still on Release 4.0(4)SV1(3) and the standby VSM is now on Release 4.2(1)SV1(4).


Step 9 Reload the VSM whose boot variables are set to Release 4.2(1)SV1(4).

switch# reload module slot 
This command will reboot standby supervisor module. (y/n)?  [n] y
about to reset standby sup
switch# 2011 Jan  7 14:07:38 switch %$ VDC-1 %$ %PLATFORM-2-PFM_MODULE_RESET: Manual 
restart of Module 1 from Command Line Interface
2011 Jan  7 14:07:46 switch %$ VDC-1 %$ %PLATFORM-2-MOD_REMOVE: Module 1 removed (Serial 
number T023D73E802)
 
   

Step 10 Log in to VSM2 using the temporary IP address.

Step 11 Confirm that VSM2 is now standalone.

switch# show system redundancy status 
Redundancy role
---------------
    administrative: standalone
       operational: standalone
 
   
Redundancy mode
---------------
    administrative: HA
       operational: None
 
   
This supervisor (sup1)
----------------------
   Redundancy state: Active
   Supervisor state: Active
     Internal state: Active with no standby
 
   
Other supervisor (sup-2)
------------------------
Redundancy State: Not present
 
   

Step 12 Change the boot variables on VSM2 to point to the Release 4.2(1)SV1(4) images.

switch# config t 
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)# no boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3.bin 
sup-2 
switch(config)# no boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3.bin sup-2 
switch(config)# boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin sup-2 
switch(config)# boot system bootflash:/nexus-1000v-mz.4.2.1.SV1.4.bin sup-2 
switch(config)# end 
switch# show running-config | in boot 
boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin sup-1
boot system bootflash:/nexus-1000v-mz.4.2.1.SV1.4.bin sup-1
boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin sup-2
boot system bootflash:/nexus-1000v-mz.4.2.1.SV1.4.bin sup-2
 
   

Step 13 Save the configuration.

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

Step 14 On VSM1 which is running a release prior to Release 4.2(1)SV1(4), remove the connection between it and the vCenter Server.

switch# show running-config 
 
   
svs-domain
  domain id 1291
  control vlan 1291
  packet vlan 1292
  svs mode L2  
  svs upgrade start mgmt0 ip 192.0.2.12 
  svs connection vcenter
  protocol vmware-vim
  remote ip address 192.0.2.10 port 80
  vmware dvs uuid "5e ca 20 50 bc 28 07 fb-0b 1d 98 56 40 cb fd 85" datacenter-name SWAMY
  connect
 
   
switch# config t 
switch# (config)# svs connection name 
switch# (config-svs-conn)# no connect 
 
   

Step 15 Change VSM1's role to secondary.

VSM1 is running a release prior to Release 4.2(1)SV1(4).

switch# (config-svs-conn)# end 
switch# (config)# end 
switch# system redundancy role secondary 
 
   

Step 16 Change the boot variables on VSM1 to point to the Release 4.2(1)SV1(4) images.

switch# config t 
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)# no boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3.bin 
sup-2 
switch(config)# no boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3.bin sup-2 
switch(config)# boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin sup-2 
switch(config)# boot system bootflash:/nexus-1000v-mz.4.2.1.SV1.4.bin sup-2 
switch(config)# end 
switch# show running-config | in boot 
boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin sup-1
boot system bootflash:/nexus-1000v-mz.4.2.1.SV1.4.bin sup-1
boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin sup-2
boot system bootflash:/nexus-1000v-mz.4.2.1.SV1.4.bin sup-2
 
   

Step 17 Save the configuration on VSM1.

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

Step 18 Display the current connections on VSM2.

switch(config)# show svs connections 
connection vcenter:
    ip address: 192.0.2.10
    remote port: 80
    protocol: vmware-vim https
    certificate: default
    datacenter name: DC1
    DVS uuid: 5e ca 20 50 bc 28 07 fb-0b 1d 98 56 40 cb fd 85
    config status: Disabled
    operational status: Disconnected
    sync status: -
    version: -
 
   

Step 19 If you have L3 connectivity using control0 to connect to VEMs, then continue with this step, otherwise move to Step 20.

a. Log in to the temporary IP address of the VSM or console of Release 4.2(1)SV1(4) VSM.

b. Check if there are sub-net or default routes associated with the control0 interface. This can be achieved by:

Running the show running-config command

Look for routes under vrf context management

vrf context management
  ip route 0.0.0.0/0 10.78.108.129
  ip route 192.168.1.0/24 192.168.2.1 

Note The highlighted IP address is the subnet route for VEM connectivity via the control0 interface.


c. Select only the routes that are used for VEM connectivity and move them under the global config context.

VSM(config)# ip route 192.168.1.0/24 192.168.2.1
VSM(config)# vrf context management 
VSM(config-vrf)# no ip route 192.168.1.0/24 192.168.2.1

Caution Do not save the running configuration to the startup configuration until the upgrade procedure is complete.

Step 20 Log in to the temporary IP address of the VSM or console of Release 4.2(1)SV1(4) VSM and check if the module status is ok.

If the module status is not ok, refer to the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4). Do not proceed unless all modules are in status ok.

Step 21 Connect to VSM2.


Note Make sure that all the VEMs are attached to the Release 4.2(1)SV1(4) VSM. Verify by comparing the number of VEMs that were attached to the Release 4.0(4)SV1(3) VSM. This number should match the number of VEMs that are attached to the Release 4.2(1)SV1(4) VSM.


switch(config)# svs upgrade complete 
Warning: Config saved but not pushed to vCenter Server due to inactive connection!
switch(config)# show running-config | in svs
svs-domain
  svs mode L2  
  svs upgrade complete 
svs connection vcenter
switch(config)# svs connection name 
switch(config-svs-conn)# connect 
switch(config-svs-conn)# end 
switch# show module 
Mod  Ports  Module-Type                       Model               Status
---  -----  --------------------------------  ------------------  ------------
1    0      Virtual Supervisor Module         Nexus1000V          active *
3    248    Virtual Ethernet Module           NA                  ok
 
   
Mod  Sw                Hw      
---  ----------------  ------------------------------------------------  
1    4.2(1)SV1(4)      0.0                                              
3    4.2(1)SV1(4)      VMware ESX 4.0.0 Releasebuild-208167 (1.9)       
 
   
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-04-00 to 02-00-0c-00-04-80  NA
 
   
Mod  Server-IP        Server-UUID                           Server-Name
---  ---------------  ------------------------------------  --------------------
1    192.0.2.12       NA                                    NA
3    10.78.109.51     4220900d-76d3-89c5-17d7-b5a7d1a2487f  ESX40U1COS
* this terminal session 
 
   

Step 22 Change VSM2 role to primary.

switch# system redundancy role primary 
 
   

Step 23 Reload VSM1.

switch# show module 
 
   
Mod  Ports  Module-Type                      Model              Status
---  -----  -------------------------------- ------------------ ------------
2    0      Virtual Supervisor Module        Nexus1000V         active *
 
   
Mod  Sw               Hw      
---  ---------------  ------  
2    4.0(4)SV1(3)     0.0    
 
   
Mod  MAC-Address(es)                         Serial-Num
---  --------------------------------------  ----------
2    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA         
 
   
Mod  Server-IP        Server-UUID                           Server-Name
---  ---------------  ------------------------------------  --------------------
2    192.0.2.11       NA                                    NA
 
   
switch# reload 
This command will reboot the system. (y/n)?  [n] y
2011 Jan  7 18:07:11 switch %$ VDC-1 %$ %PLATFORM-2-PFM_SYSTEM_RESET: Manual system 
restart from Command Line Interface
 
   

Step 24 Change VSM2's mgmt0 IP address back to the shared IP address.

switch# show run int mgmt0 
switch# config t 
switch(config)# int mgmt0 
switch(config-if)# ip address 192.0.2.11 255.255.255.240 
switch(config-if)# end 
 
   

Step 25 Log in to VSM2 by using the shared IP address.

switch# show system redundancy status 
Redundancy role
---------------
      administrative:   primary
         operational:   primary
 
   
Redundancy mode
---------------
      administrative:   HA
         operational:   HA
 
   
This supervisor (sup-1)
-----------------------
    Redundancy state:   Active
    Supervisor state:   Active
      Internal state:   Active with HA standby                  
 
   
 
   
Other supervisor (sup-2)
------------------------
     Redundancy state:   Standby
     Supervisor state:   HA standby
       Internal state:   HA standby                              
 
   
switch# show module 
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
 
   
Mod  Sw                Hw      
---  ----------------  ------------------------------------------------  
1    4.2(1)SV1(4)      0.0                                              
2    4.2(1)SV1(4)      0.0                                              
3    4.2(1)SV1(4)      VMware ESX 4.0.0 Releasebuild-208167 (1.9)       
 
   
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-04-00 to 02-00-0c-00-04-80  NA
 
   
Mod  Server-IP        Server-UUID                           Server-Name
---  ---------------  ------------------------------------  --------------------
1    192.0.2.11       NA                                    NA
2    192.0.2.11       NA                                    NA
3    10.78.109.51     4220900d-76d3-89c5-17d7-b5a7d1a2487f  10.78.109.51
* this terminal session 
 
   

Step 26 Save the configuration.

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

Upgrading the VSMs Manually on a Cisco Nexus 1000V from Release 4.0(4)SV1(3, 3a, or 3b) to Release 4.2(1)SV1(4)

This section describes how to manually upgrade to Release 4.2(1)SV1(4) from Release 4.0(4)SV1(3, 3a, or 3b) by using the CLI.

Prerequisites to Upgrading the VSMs

The following are prerequisites to upgrading the VSMs:

Executing and correcting errors from the PreUpgradeUtility.

VEMs are upgraded to Release 4.2(1)SV1(4).

The kickstart and system images have been uploaded to the bootflash.

You might need up to three additional IP addresses in the same subnet as the VSM mgmt0 and control0.


Caution If the IP addresses are not in the same subnet, the system will be in an inconsistent state. See the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4).

SSH is enabled on the VSM.

A VSM HA environment is mandatory for the upgrade to proceed.

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

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.

If Authentication, Authorization, and Accounting (AAA) servers are used for authentication, add the temporary IP address used in the upgrade to the authentication database.


Note The Upgrade Application is the recommended method of upgrading.


The two VSMs are identified as VSM1 and VSM2 which are the active and standby VSMs respectively.

To manually upgrade to Release 4.2(1)SV1(4), follow these steps:


Step 1 Log in to the VSM.

Step 2 Copy the kickstart and isan images to the bootflash: file system.

switch# copy scp:root@192.0.2.13/N1K-VSM-images/nexus-1000v-mz.4.2.1.SV1.4.bin bootflash:

switch# copy scp:root@192.0.2.13/N1K-VSM-images/nexus-1000v-kickstart.mz.4.2.1.SV1.4.bin bootflash:

Step 3 Display the current redundancy status.

switch# show module

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
 
   
Mod  Sw               Hw 
---  ---------------  ------ 
1    4.0(4)SV1(3b)    0.0 
2    4.0(4)SV1(3b)    0.0 
3    4.2(1)SV1(4)     VMware ESXi 4.1.0 Releasebuild-260247 (2.0) 1.9 
 
   
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 
 
   
Mod  Server-IP       Server-UUID                           Server-Name
---  -------------   ------------------------------------  --------------------
1    172.23.233.64   NA                                    NA
2    172.23.233.64 	NA                                    NA
3    172.23.232.72 	33393935-3234-5553-4538-35314e323554 172.23.232.72
* this terminal session 
 
   

switch# show system redundancy status

bl-n1000v# show system redun status
Redundancy role
---------------
      administrative:   primary
         operational:   primary
 
   
Redundancy mode
---------------
      administrative:   HA
         operational:   HA
 
   
This supervisor (sup-1)
-----------------------
    Redundancy state:   Active
    Supervisor state:   Active
      Internal state:   Active with HA standby
 
   
Other supervisor (sup-2)
-----------------------
    Redundancy state:   Standby
    Supervisor state:   HA standby
      Internal state:   HA standby
 
   

Step 4 Display the current connections to the Cisco Nexus 1000V.

switch# show svs connections
connection vcenter:
    ip address: 172.23.231.133
    remote port: 80
    protocol: vmware-vim https
    certificate: default
    datacenter name: sachinDC
    DVS uuid: 0c bf 0b 50 0b 4a b7 76-88 13 be 45 14 e8 9b 4e
    config status: Enabled
    operational status: Connected
    sync status: Complete
    version: VMware vCenter Server 4.0.0 build-208111

Step 5 Inform the VEMs that the upgrade process is starting and assign the temporary IP address to VSM2.

If you are using L3 mode with control0, go to Step 6.


Note If Authentication, Authorization, and Accounting (AAA) servers are used for authentication, add the temporary IP address used in the upgrade to the authentication database.


switch# configure terminal


Note The value of ipaddr in the following command is the temporary IP address that will be used to access VSM2 while the HA pair is split.


switch(config)# svs upgrade start mgmt0 ip ipaddr

WARNING!
1. Please do not change the configuration of the system from this point onwards
2. Ensure that all relevant ports, including uplinks, vmknics, and vsifs used for control, 
packet, management, storage as well as VSM ports, are all configured with system profiles
3. Ensure there is network connectivity between VC, VSM pair, and the hosts/modules
4. Ensure all the hosts/modules are upgraded with the next version of VEM software package
switch(config)# end

Step 6 Update the system and kickstart boot variables.

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

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.

Upgrade in process, hence Active boot variables are not updated.

Boot variables are updated to running configuration.

Step 7 Copy the running configuration to the startup configuration and verify.

switch# copy running-config startup-config

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

switch# show start | in boot

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

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

boot kickstart bootflash:/nexus-1000v-kickstart-mzg.4.2.1.SV1.4.bin sup-2

boot system bootflash:/nexus-1000v-mzg.4.2.1.SV1.4.bin sup-2


Note The following commands display that the active VSM (sup-1) is still on Release 4.0(4)SV1(3b) and the standby VSM is now on Release 4.2(1)SV1(4).


Step 8 Reload the VSM whose boot variables are set to Release 4.2(1)SV1(4).

switch# reload module slot

This command will reboot standby supervisor module. (y/n)? [n] y
2010 June 14 20:11:51 av1-vsm %PLATFORM-2-PFM_MODULE_RESET: Manual restart of Module 2 
from Command Line Interface
switch# 2010 Jun 14 20:11:58 av1-vsm %PLATFORM-2-MOD_REMOVE: Module 2 removed (Serial 
number T50569A5039

Step 9 Log in to VSM2 using the temporary IP address.

Step 10 Confirm that VSM2 is now standalone.

switch# show system redundancy status

Redundancy role

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

    administrative:  standalone

       operational:  standalone

Redundancy mode

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

    administrative:  HA

       operational:  None

This supervisor (sup1)

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

   Redundancy state:  Active

   Supervisor state:  Active

     Internal state:  Active with no standby

Other supervisor (sup-2)

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

    Redundancy State:  Not present

Step 11 On VSM1, running the pre-Release 4.2(1)SV1(4) image, remove the connection between it and the vCenter Server.

switch# show running-config

svs-domain

  domain id 470

  control vlan 233

  packet vlan 233

  svs mod L2

  svs upgrade start mgmt0 ip 192.0.2.12

svs connection vc

  protocol vmware-vim

  remote up address 192.0.2.10 port 80

  vmware dvs uuid "0c bf 0e 50 0b 4a b7 76-88 13 be 45 14 e8 9b 4e" datacenter-name 
sachinDC
  connect

switch# config t

switch# (config)# svs connection vc

switch# (config-svs-conn)# no connect

Step 12 Change VSM1's role to secondary.

switch(config-svs-conn)# end

switch(config)# end

switch# system redundancy role secondary

Setting will be activated on next reload

switch# show run | in boot

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

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

boot kickstart bootflash:/nexus-1000v-kickstart-mzg.4.2.1.SV1.4.bin sup-2

boot system bootflash:/nexus-1000v-mzg.4.2.1.SV1.4.bin sup-2

Step 13 Change the boot variables on VSM1 to point to the Release 4.2(1)SV1(4) images.

switch# config t

Enter configuration commands, one per line. End with CNTL/Z.

switch(config)# boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin

switch(config)# no boot system bootflash:/nexus-1000v.mzg.4.0.4.SV1.3b.bin sup-1

switch(config)# boot system bootflash:/nexus-1000v-mz.4.2.1.SV1.4.bin sup-1

switch(config)# end

switch# show run | in boot

boot kickstart bootflash:/nexus-1000v-kickstart-mzg.4.2.1.SV1.4.bin sup-1

boot system bootflash:/nexus-1000v-mzg.4.2.1.SV1.4.bin sup-1

boot kickstart bootflash:/nexus-1000v-kickstart-mzg.4.2.1.SV1.4.bin sup-2

boot system bootflash:/nexus-1000v-mzg.4.2.1.SV1.4.bin sup-2

Step 14 Save the configuration on VSM1.

switch# copy running-config startup-config

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

Step 15 Display the current connections on VSM2.

switch# config t

Enter configuration commands, one per line. End with CNTL/Z.

switch(config)# show svs connect

connection vcenter:

ip address: 192.0.2.10

remote port: 80

protocol: vmware-vim https

certificate: default

datacenter name: n1000vDC

DVS uuid: 0c bf 0b 50 0b 4a b7 76-88 13 be 45 14 e8 9b 4e

config status: Enabled

operational status: Disconnected

sync status: -

version: -

Step 16 If you have L3 connectivity using control0 to connect to the VEMs, then continue with this step, otherwise move to Step 17.

a. Log in to the temporary IP address of the VSM or console of Release 4.2(1)SV1(4) VSM.

b. Check if there are sub-net or default routes associated with the control0 interface. This can be achieved by:

Running the show running-config command

Look for routes under vrf context management

vrf context management
  ip route 0.0.0.0/0 10.78.108.129
  ip route 192.168.1.0/24 192.168.2.1 

Note The highlighted IP address is the subnet route for VEM connectivity via control0 interface.


c. Select only the routes that are used for VEM connectivity and move them under global config context.

VSM(config)# ip route 192.168.1.0/24 192.168.2.1
VSM(config)# vrf context management 
VSM(config-vrf)# no ip route 192.168.1.0/24 192.168.2.1
 
   

Caution Do not save the running configuration to the startup configuration until the upgrade procedure is complete.

Step 17 Log in to the temporary IP address of the VSM or console of Release 4.2(1)SV1(4) VSM and check if the module status is ok.

If the module status is not ok, refer to the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4). Do not proceed unless all modules are in status ok.

Step 18 Connect VSM2 to the vCenter Server.


Note Make sure that all the VEMs are attached to the Release 4.2(1)SV1(4) VSM. Verify by comparing the number of VEMs that were attached to the Release 4.0(4)SV1(3b) VSM match the number of VEMs that are attached to the Release 4.2(1)SV1(4) VSM. Check for module status = ok.


switch# config t

Enter configuration commands, one per line. End with CNTL/Z.

switch(config)# svs upgrade complete

Warning: Config saved but not pushed to vCenter Server due to inactive connection!

switch(config)# end

switch# show run | in svs

svs-domain

  svs mode L2

  svs upgrade complete

svs connection vc

switch# config t

Enter configuration commands, one per line. End with CNTL/Z.

switch(config)# svs connection name

switch(config-svs-conn)# connect

switch(config-svs-conn)# end

switch(config)# end

switch# show module

Mod  Ports  Module-Type                      Model              Status
---  -----  -------------------------------- ------------------ ------------
1    0      Virtual Supervisor Module        Nexus1000V         active *
3    248    Virtual Ethernet Module          NA                 ok
 
   
Mod  Sw               Hw 
---  ---------------  ------ 
1    4.2(1)SV1(3b) 0.0 
3    4.2(1)SV1(4)     VMware ESXi 4.0.0 Releasebuild-208167 (1.9)1.9 
 
   
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 
 
   
Mod  Server-IP 					Server-UUID                           Server-Name
---  ------------- 	------------------------------------  --------------------
1    172.23.233.64 	NA                                    NA
3    172.23.232.72 	33393935-3234-5553-4538-35314e323554 sfish-srvr-72
* this terminal session 

Step 19 Change VSM2 role to primary.

switch# system redundancy role primary

Step 20 Reload VSM1.

switch# show module

switch# show run int mgmt0

!Command: show running-config interface mgmt0

!Time: Mon Jun 14 20:27:27 2010

version 4.2(1)SV1(4)

interface mgmt0

  ip address 192.0.2.11/24

switch(config)# show version

switch# reload

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

switch# copy running-config startup-config

switch# reload

Step 21 Change VSM2's mgmt0 IP address back to the shared IP address.

switch# show run int mgmt0

switch# config t

switch(config)# int mgmt0

switch(config-if)# ip address 192.0.2.11 255.255.255.0

Step 22 Confirm upgraded HA pair.

switch# show system redundancy status

Redundancy role
---------------
      administrative:   primary
         operational:   primary
 
   
Redundancy mode
---------------
      administrative:   HA
         operational:   None
 
   
This supervisor (sup-1)
-----------------------
    Redundancy state:   Active
    Supervisor state:   Active
      Internal state:   Active with HA standby
 
   
Other supervisor (sup-2)
-----------------------
    Redundancy state:   Standby
    Supervisor state:   HA standby
      Internal state:   HA standby
 
   

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 if you are upgrading from Release 4.0(4)SV1(1) or Release 4.0(4)SV1(2).

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 34).

Figure 34 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 some troubleshooting guidelines for problems that may occur during the Cisco Nexus 1000V upgrade process. This section includes the following topic:

Non-default (Jumbo) MTU Settings Symptoms and Solutions

Non-default (Jumbo) MTU Settings Symptoms and Solutions

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 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 mtu command does not apply to non-system profiles or ports.


Available Documents

This section lists the documents used with the Cisco Nexus 1000V and 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.2(1)SV1(4)

Cisco Nexus 1000V Release Notes, Release 4.2(1)SV1(4)

Cisco Nexus 1000V Compatibility Information, Release 4.2(1)SV1(4)

Cisco Nexus 1010 Management Software Release Notes, Release 4.2(1)SP1(2)

Install and Upgrade

Cisco Nexus 1000V Virtual Supervisor Module Software Installation Guide, Release 4.2(1)SV1(4)

Cisco Nexus 1000V Software Upgrade Guide, Release 4.2(1)SV1(4)

Cisco Nexus 1000V VEM Software Installation and Upgrade Guide, Release 4.2(1)SV1(4)

Cisco Nexus 1010 Virtual Services Appliance Hardware Installation Guide

Cisco Nexus 1010 Software Installation and Upgrade Guide, Release 4.2(1)SP1(2)

Configuration Guides

Cisco Nexus 1000V License Configuration Guide, Release 4.2(1)SV1(4)

Cisco Nexus 1000V Getting Started Guide, Release 4.2(1)SV1(4)

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

Cisco Nexus 1000V Interface Configuration Guide, Release 4.2(1)SV1(4)

Cisco Nexus 1000V Layer 2 Switching Configuration Guide, Release 4.2(1)SV1(4)

Cisco Nexus 1000V Port Profile Configuration Guide, Release 4.2(1)SV1(4)

Cisco Nexus 1000V Quality of Service Configuration Guide, Release 4.2(1)SV1(4)

Cisco Nexus 1000V Security Configuration Guide, Release 4.2(1)SV1(4)

Cisco Nexus 1000V System Management Configuration Guide, Release 4.2(1)SV1(4)

Cisco Nexus 1010 Software Configuration Guide, Release 4.2(1)SP1(2)

Programming Guide

Cisco Nexus 1000V XML API User Guide, Release 4.2(1)SV1(4)

Reference Guides

Cisco Nexus 1000V Command Reference, Release 4.2(1)SV1(4)

Cisco Nexus 1000V MIB Quick Reference

Cisco Nexus 1010 Command Reference, Release 4.2(1)SP1(2)

Troubleshooting and Alerts

Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4)

Cisco Nexus 1000V Password Recovery Guide

Cisco NX-OS System Messages Reference

Virtual Security Gateway Documentation

Cisco Virtual Security Gateway for Nexus 1000V Series Switch Release Notes, Release 4.2(1)VSG(1)

Cisco Virtual Security Gateway, Release 4.2(1)VSG1(1) and Cisco Virtual Network Management Center, Release 1.0.1 Installation Guide

Cisco Virtual Security Gateway for Nexus 1000V Series Switch License Configuration Guide, Release 4.2(1)VSG1(1)

Cisco Virtual Security Gateway for Nexus 1000V Series Switch Configuration Guide, Release 4.2(1)VSG1(1)

Cisco Virtual Security Gateway for Nexus 1000V Series Switch Command Reference, Release 4.2(1)VSG1(1)

Virtual Network Management Center

Release Notes for Cisco Virtual Network Management Center, Release 1.0.1

Cisco Virtual Security Gateway, Release 4.2(1)VSG1(1) and Cisco Virtual Network Management Center, Release 1.0.1 Installation Guide

Cisco Virtual Network Management Center CLI Configuration Guide, Release 1.0.1

Cisco Virtual Network Management Center GUI Configuration Guide, Release 1.0.1

Cisco Virtual Network Management Center XML API Reference Guide, Release 1.0.1

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.