Guest

Cisco Nexus 1000V Switch for VMware vSphere

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

  • Viewing Options

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

Table Of Contents

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

Audience

Obtaining the Software for the Upgrade

Information About the Pre-Upgrade Utility

Running the Pre-Upgrade Utility

Prerequisites for Running the Pre-Upgrade Utility

Running the Pre-Upgrade Utility on a Microsoft Windows Platform

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(4b)

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

Upgrading the VSMs from Release 4.2(1)SV1(4) or 4.2(1)SV1(4a) to Release 4.2(1)SV1(4b)

Software Images

In-Service Software Upgrades on Devices with Dual VSMs

Prerequisites for Upgrading the Cisco Nexus 1000V Software

Cisco Nexus 1000V Software Upgrade Guidelines

Upgrading a Device with Dual VSMs

Detailed Upgrade Procedure

Upgrading a Device with a Single VSM

Upgrading the VEMs from Release 4.2(1)SV1(4) or 4.2(1)SV1(4a) to Release 4.2(1)SV1(4b)

Prerequisites to Upgrading VEMs

Upgrading the VEMs Using VMware Update Manager from Release 4.2(1)SV1(4) or 4.2(1)SV1(4a) to Release 4.2(1)SV1(4b)

Upgrading the VEMs Manually from Release 4.2(1)SV1(4) or 4.2(1)SV1(4a) to Release 4.2(1)SV1(4b)

Downgrading from Release 4.2(1)SV1(4b) to Release 4.2(1)SV1(4)

Downgrading the VEMs from Release 4.2(1)SV1(4b) to Release 4.2(1)SV1(4)

Downgrading the VSMs from Release 4.2(1)SV1(4b) to Release 4.2(1)SV1(4)

Changing Boot Variables Manually

Upgrading from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b)

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

Upgrading the VSMs

Upgrading the VSMs from Release 4.0(4)SV1(1, 2) to Release 4.0(4)SV1(3d)

Prerequisites to Upgrading the VSMs

Upgrading the VEMs

Upgrading the VEMs from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b)

Prerequisites to Upgrading VEMs

Upgrading the VEMs Using VUM from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b)

Upgrading the VEMs Manually from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b)

Upgrading the VEMs from Releases 4.0(4)SV1(1, 2) to Release 4.2(1)SV1(4b)

Prerequisites to Upgrading VEMs

Upgrading the VEMs Using VUM from Releases 4.0(4)SV1(1, 2) to Release 4.2(1)SV1(4b)

Upgrading the VEMs Manually from Releases 4.0(4)SV1(1, 2) to Release 4.2(1)SV1(4b)

Upgrading the VSMs from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b) Using the Upgrade Application

Prerequisites to Using the Cisco Nexus 1000V Upgrade Application

Upgrading the VSMs from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b) Using the Manual Upgrade Procedure

Prerequisites to Upgrading the VSMs

Accepting the VEM Upgrade in the vCenter Client

Prerequisites to Accepting the VEM Upgrade

Accepting the VEM Upgrade

Troubleshooting

Nondefault (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(4b)


Revised: May 9, 2013
OL-25769-01

Caution The upgrade procedure for Release 4.2(1)SV1(4b) has changed. We highly recommend that you read this document thoroughly before beginning the upgrade.


Note An interactive upgrade tool has been provided to assist you in determing the correct upgrade steps based on your current environment and the one to which you want to upgrade.


This document describes how to upgrade the Cisco Nexus 1000V software on a Virtual Supervisor Module (VSM) virtual machine (VM) and how to upgrade the Virtual Ethernet Module (VEM).

This document includes the following sections:

Audience

Obtaining the Software for the Upgrade

Running the Pre-Upgrade Utility

Information About the Software Upgrade

Upgrading to Release 4.2(1)SV1(4b)

Upgrading the VSMs

Upgrading the VEMs

Upgrading the VSMs from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b) Using the Manual Upgrade Procedure

Accepting the VEM Upgrade in the vCenter Client

Troubleshooting

Available Documents

Obtaining Documentation and Submitting a Service Request, page 91

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(4b).


Caution Table 1 lists the documents and videos that you need to utilize when performing a new installation or upgrading to Release 4.2(1)SV1(4b).

Table 1 Installation and Upgrade Documentation and Videos


Obtaining the Software for the Upgrade

You can obtain your upgrade-related software from the following sources listed in Table 2.

Table 2 Obtaining Software for the Upgrade

Source
Description

Cisco

Download the Cisco Nexus 1000V Release 4.2(1)SV1(4b) software from Cisco.com.

VMware

Download VMware software from the VMware website.


For information about your software and platform compatibility, see the Cisco Nexus 1000V Compatibility Information, Release 4.2(1)SV1(4b).

Information About the Pre-Upgrade Utility

To upgrade the Cisco Nexus 1000 software, follow these steps:


Step 1 Obtain the software, For more information, see the "Installing the Cygwin Application" section section.

Step 2 Run the pre-upgrade utility. For more information, see the "Running the Pre-Upgrade Utility in the Cygwin Application" section section.



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


Running the Pre-Upgrade Utility


Note You do not need to run the Pre-Upgrade Utility if you are upgrading from Release 4.2(1)SV1(4) or Release 4.2(1)SV1(4a) to Release 4.2(1)SV1(4b).


This section includes the following topics:

Prerequisites for Running the Pre-Upgrade Utility

Running the Pre-Upgrade Utility on a Microsoft Windows Platform

Running the Pre-Upgrade Utility on a UNIX Platform

This section describes how to install the pre-upgrade utility for your Cisco Nexus 1000.


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(4b), 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 1000 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 the "Running the Pre-Upgrade Utility on a Microsoft Windows Platform" section.

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


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


Running the Pre-Upgrade Utility on a Microsoft Windows Platform

This section contains the following topics:

Installing the Cygwin Application

Running the Pre-Upgrade Utility in the Cygwin Application

This section describes how to run the pre-upgrade utility on a Microsoft Windows platform. To run this utility on this platform, you must use the Cygwin application, which is 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).

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 the "Running the Pre-Upgrade Utility" section.

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 Cygwin 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 you have 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 that you downloaded in Step 2.

The Cygwin Setup screen opens. See Figure 1.

Figure 1 Cygwin Setup Screen

Step 4 Click Next.

The Choose a Download Source screen 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 that you choose in a later step to be downloaded first, validated, and installed.


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

Figure 3 Select Root Install Directory Screen

Step 6 In the Root Directory field, browse to the root directory that you want to install and click Next.

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


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


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 screen opens. See Figure 5.

Figure 5 Select Your Internet Connection Screen

Step 8 Choose an appropriate Internet connection and click Next.

The Choose a Download Site screen 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 screen 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 screen 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 ssh 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.


After the 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 screen 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

BEFORE YOU BEGIN

Before beginning this procedure you must know or do the following:

You must download the PreUpgradeUtility zip file from the Cisco Nexus 1000V FCS package and unzip the file.


Step 1 Copy the pre-upgrade-check-4.2(1)SV1(4).tcl file to C:\cygwin or the main directory where you 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 Use Telnet or Secure Shell (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 enter the following command:

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

where

ip-address is the IP address of the VSM.

username and password are the login credentials.


Note Figure 18 displays this command being run with the Telnet option.


Figure 18 Telnet Option Window


Note You can use one of two methods of connectivity. 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 appear, continue with the upgrade.

If errors appear, correct them.

Step 6 Rerun the script and correct any additional errors.

Step 7 Go to the "Information About the Software Upgrade" section.


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 1000 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]
 
   

where

ip-address is the IP address of the VSM.

username and password are the login credentials.

This example shows how to run the pre-upgrade utility.

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

The utility performs the checks and the results are displayed. If there are any errors, possible corrective actions are listed. The log file that contains the errors and notifications is called 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 appear, go to the "Information About the Software Upgrade" section.

If errors appear, correct them and rerun the script until no errors appear.

Step 5 Go to the "Information About the Software Upgrade" section.


Information About the Software Upgrade


Caution If the VMware vCenter Server is hosted on the same ESX host as a Cisco Nexus 1000V Virtual Ethernet Module (VEM), a VMware Update Manager (VUM) assisted upgrade on the host will fail. You should manually perform a vMotion of 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.

This section describes important points about the software upgrade:

You can use one of two methods to upgrade the software: the nondisruptive method and the disruptive method. An upgrade is nondisruptive or disruptive based on the version of your setup and also the method that you choose for upgrading.

A nondisruptive upgrade takes place when you install one of the following VMware releases listed in Table 3.

To determine what patch level you are using, see the Cisco Nexus 1000V Compatibility Information, Release 4.2(1)SV1(4b).


Note Even if your ESX/ESXi host patch levels are greater than the values listed in Table 3, you must install ESX/ESXi400-201002001 or upgrade-from-esxi4.0-4.0_update02, or your nondisruptive upgrade will not be supported. Any patch level for 4.1.0 ensures a nondisruptive upgrade.

Table 3 Nondisruptive Patch Level

ESX/ESXi
Nondisruptive Patch Level

4.0.0

ESX/ESXi400-201002001

upgrade-from-esxi4.0-4.0_update02

4.1.0

Any patch level



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

Cisco does not support simultaneous VMware updates or patches in combination with Cisco Nexus 1000 upgrades. The upgrade process in this document is specifically for Cisco Nexus 1000 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 Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4b).


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

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

Information About Licensing

Table 4 summarizes licensing information following the upgrade.

Table 4 Post Upgrade License Status

Nexus 1000V Release
Evaluation Licenses
Permanent Licenses

SV1(2)
SV1(3)
SV1(3a)
SV1(3b)
SV1(3c)
SV1(3d)
SV1(4)
SV1(4a)
SV1(4b)

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 the installation of additional evaluation license files. For more licensing details, see the Cisco Nexus 1000V License Configuration Guide, Release 4.2(1)SV1(4a). For information about limitations and caveats, see the Cisco Nexus 1000V Release Notes, Release 4.2(1)SV1(4b).

Upgrading to Release 4.2(1)SV1(4b)

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

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

Upgrading from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b)

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

If you are upgrading from Release
Go to

4.2(1)SV1(4)
4.2(1)SV1(4a)

Upgrading to Release 4.2(1)SV1(5.1) (Recommended)

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

4.0(4)SV1(3)
4.0(4)SV1(3a)
4.0(4)SV1(3b)
4.0(4)SV1(3c)
4.0(4)SV1(3d)

Upgrading from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b)

4.0(4)SV1(1)
4.0(4)SV1(2)

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


This section includes the following topics:

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

Upgrading the VSMs from Release 4.2(1)SV1(4) or 4.2(1)SV1(4a) to Release 4.2(1)SV1(4b)

Upgrading the VEMs from Release 4.2(1)SV1(4) or 4.2(1)SV1(4a) to Release 4.2(1)SV1(4b)

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

This section describes how to upgrade from Release 4.2(1)SV1(4) or 4.2(1)SV1(4a) to Release 4.2(1)SV1(4b).


Note It is recommended that you upgrade the vSphere software to VMware version 4.1 or 5.0 Update 1.



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



Note This procedure is different from the upgrade to Release 4.2(1)SV1(4). In this procedure, you upgrade the VSMs first by using the install all command and then you upgrade the VEMs.


BEFORE YOU BEGIN

Before beginning this procedure, you must know or do the following:

You are running primary and secondary VSMs as an active-standby pair or a standalone VSM.

The Upgrade Application cannot be used for the upgrade of the VSMs from Release 4.2(1)SV1(4) or 4.2(1)SV1(4a) to Release 4.2(1)SV1(4b).

A pair of VSMs in HA synchronization is required in order to support a nondisruptive upgrade.

A system with a single VSM can only be upgraded in a disruptive manner.

You can abort the upgrade procedure by pressing Ctrl-C.

To downgrade from Release 4.2(1)SV1(4b) to Release 4.2(1)SV1(4) in the event of an upgrade failure or abort, see the "Downgrading from Release 4.2(1)SV1(4b) to Release 4.2(1)SV1(4)" section.

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


Step 1 Upgrading the VSMs for Release 4.2(1)SV1(4) or 4.2(1)SV1(4a) to Release 4.2(1)SV1(4b). For this procedure, see "Upgrading the VSMs from Release 4.2(1)SV1(4) or 4.2(1)SV1(4a) to Release 4.2(1)SV1(4b)" section.

Step 2 Upgrading the VEMs for Release 4.2(1)SV1(4) or 4.2(1)SV1(4a) to Release 4.2(1)SV1(4b). For this procedure, see "Upgrading the VEMs from Release 4.2(1)SV1(4) or 4.2(1)SV1(4a) to Release 4.2(1)SV1(4b)" section.


Figure 19 Upgrading from Release 4.2(1)SV1(4) or 4.2(1)SV1(4a) to Release 4.2(1)SV1(4b)

Upgrading the VSMs from Release 4.2(1)SV1(4) or 4.2(1)SV1(4a) to Release 4.2(1)SV1(4b)

This section includes the following topics:

Software Images

In-Service Software Upgrades on Devices with Dual VSMs

Prerequisites for Upgrading the Cisco Nexus 1000V Software

Cisco Nexus 1000V Software Upgrade Guidelines

Upgrading a Device with Dual VSMs

Detailed Upgrade Procedure

Upgrading a Device with a Single VSM

Software Images

The software image install procedure is dependent on the following factors:

Software images—The kickstart and system image files reside in directories or folders that you can access from the Cisco Nexus 1000V software prompt.

Image version—Each image file has a version.

Disk—The bootflash: resides on the VSM.

VSM—There are single or dual VSMs.


Note On devices with dual VSMs, you should have access to the console of both VSMs to maintain connectivity when switchovers occur during upgrades. If you are performing the upgrade over Secure Shell (SSH) or Telnet, the connection will drop when the system switchover occurs, and you must reestablish the connection.


In-Service Software Upgrades on Devices with Dual VSMs

The Cisco Nexus 1000V software supports in-service software upgrades (ISSUs) for systems with dual VSMs. An ISSU can update the software images on your switch without disrupting data traffic. Only control traffic is disrupted. If an ISSU will cause a disruption of data traffic, the Cisco Nexus 1000V software warns you before proceeding so that you can stop the upgrade and reschedule it to a time that minimizes the impact on your network.

An ISSU updates the following images:

Kickstart image

System image

VEM images

Figure 20 shows the ISSU process.

Figure 20 ISSU Process

Figure 21 provides an example of the VSM status before and after an ISSU switchover.

Figure 21 Example of an ISSU VSM Switchover

Prerequisites for Upgrading the Cisco Nexus 1000V Software

Upgrading the Cisco Nexus 1000V software has the following prerequisite:

· Close any active configuration sessions before upgrading the Cisco Nexus 1000V software.

Cisco Nexus 1000V Software Upgrade Guidelines

Before attempting to migrate to any software image version, follow these guidelines:

Scheduling

Schedule the upgrade when your network is stable and steady. Ensure that everyone who has access to the switch or the network is not configuring the switch or the network during this time. You cannot configure a switch during an upgrade.

Space

Verify that sufficient space is available in the location where you are copying the images.

Check that the bootflash: has approximately 200 MB of free space available both in active and standby VSMs.

Hardware

Avoid power interruptions to the hosts running the VSM VMs during any installation procedure.

Connectivity to remote servers

Copy the kickstart and system images from the remote server to the Cisco Nexus 1000.

Configure the IPv4 IP address for the mgmt0 interface

Ensure that the mgmt0 interface of the Cisco Nexus 1000 is working.

Ensure that the switch has a route to the remote server. The switch and the remote server must be in the same subnetwork if you do not have a router to route traffic between subnets.

Software images

Ensure that the specified system and kickstart images are compatible with each other.

Retrieve the images in one of two ways:

Locally—Images are locally available on the switch.

Remotely—Images are in a remote location and you specify the destination using the remote server parameters and the filename to be used locally.

Commands to use:

Verify connectivity to the remote server by using the ping command.

Ensure that the required space is available for the image files to be copied by using the dir command.

Use the one-step install all command to upgrade your software. This command upgrades the VSMs.

Run only one installation on a switch at a time.

Do not issue another install command while running the installation. You can run commands other than configuration.

Do the installation on the active VSM, not the standby VSM.

VEMs

During the upgrade, if you try to add a new VEM or any of the VEMs are detached due to uplink flaps, the VEM attachment is queued until the upgrade completes.


Note If the VEMs are not compatible with the software image that you install on the VSM, a traffic disruption will occur in those modules, depending on your configuration. The install all command output identifies these scenarios. You can choose to proceed with the upgrade or end at this point


Local Authentication

We recommend the you use local authentication during the upgrade process. If a remote server is needed, you must make sure that the "admin" account is configured with network-admin privileges.

Upgrading a Device with Dual VSMs

The install all command supports in-service software upgrade (ISSU) on dual VSMs in an HA environment and performs the following actions:

Determines whether the upgrade is disruptive and asks if you want to continue.

Copies the kickstart and system images to the standby VSM. Alternatively, if a local ISO file is passed to the install all command instead, the kickstart and system images are extracted from the file.

Sets the kickstart and system boot variables.

Reloads the standby VSM with the new Cisco Nexus 1000V software.

Causes the active VSM to reload when the switchover occurs.

Benefits of Using the install all Command

The install all command provides the following benefits:

You can upgrade the VSM by using just one command.

You can receive descriptive information on the intended changes to your system before you continue with the installation.

You have the option to cancel the command. Once the effects of the command are presented, you can continue or cancel when you see this question (the default is no):

Do you want to continue (y/n) [n]: y
 
   

You can upgrade the VSM using the least disruptive procedure.

You can see the progress of this command on the console, Telnet, and SSH screens:

After a switchover process, you can see the progress from both the VSMs.

Before a switchover process, you can only see the progress from the active VSM.

The install all command automatically checks the image integrity, which includes the running kickstart and system images.

The install all command performs a platform validity check to verify that a wrong image is not used.

The Ctrl-C escape sequence gracefully ends the install all command. The command sequence completes the update step in progress and returns to the switch prompt. (Other upgrade steps cannot be ended by using Ctrl-C.)

After running the install all command, if any step in the sequence fails, the command completes the step in progress and ends.

Detailed Upgrade Procedure

This section describes how to upgrade to the latest Cisco Nexus 1000V software on a device with dual VSMs.


Step 1 Log in to the active VSM.

Step 2 Log in to Cisco.com to access the links provided in this document. To log in to Cisco.com, go to the URL http://www.cisco.com/ and click Log In at the top of the page. Enter your Cisco username and password.


Note Unregistered cisco.com users cannot access the links provided in this document.


Step 3 Access the Software Download Center by using this URL: http://www.cisco.com/public/sw-center/index.shtml

Step 4 Navigate to the download site for your device.

You see links to the download images for your switch.

Step 5 Select and download the Cisco Nexus 1000V zip file and extract the kickstart and system software files to a server.

Step 6 Ensure that the required space is available for the image file(s) to be copied.

switch# dir bootflash:
.
.
.
Usage for bootflash://sup-local
1957335040 bytes used
1240604672 bytes free
3197939712 bytes total
 
   

Tip We recommend that you have the kickstart and system image files for at least one previous release of the Cisco Nexus 1000V software on the device to use if the new image files do not load successfully.


Step 7 If you need more space on the active VSM, delete unnecessary files to make space available.

Step 8 Verify that there is space available on the standby VSM.

switch# dir bootflash://sup-standby/
.
.
.
Usage for bootflash://sup-standby
1956005040 bytes used
1240603332 bytes free
2096608372 bytes total
 
   

Step 9 If you need more space on the standby VSM, delete any unnecessary files to make space available.

Step 10 If you plan to install the images from the bootflash:, copy the Cisco Nexus 1000 kickstart and system images to the active VSM by using a transfer protocol. You can use ftp:, tftp:, scp:, or sftp:. The examples in this procedure use scp:.


Note When you download an image file, change to your FTP environment IP address or DNS name and the path where the files are located.


switch# copy 
scp://user@scpserver.cisco.com/downloads/nexus-1000v-kickstart-mz.4.2.1.SV1.4b.bin
bootflash:nexus-1000v-kickstart-mz.4.2.1.SV1.4b.bin
switch# copy scp://user@scpserver.cisco.com/downloads/nexus-1000v-mz.4.2.1.SV1.4b.bin
bootflash:nexus-1000v-mz.4.2.1.SV1.4b.bin
 
   

Step 11 Read the release notes for the related image file. See the Cisco Nexus 1000V Release Notes, Release 4.2(1)SV1(4b).

Step 12 Save the running configuration to the startup configuration.

switch# copy running-config startup-config 
 
   

Step 13 Save the running configuration on the bootflash and externally.

switch# copy running-config bootflash:run-cfg-backup 
switch# copy running-config scp://user@tftpserver.cisco.com/n1kv-run-cfg-backup
 
   

Step 14 Perform the upgrade on the active VSM.

switch# install all kickstart bootflash:nexus-1000v-kickstart-mz.4.2.1.SV1.4b.bin system 
bootflash:nexus-1000v-mz.4.2.1.SV1.4b.bin
 
   
Verifying image bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4b.bin for boot variable 
"kickstart".
[####################] 100% -- SUCCESS
 
   
Verifying image bootflash:/nexus-1000v-mz.4.2.1.SV1.4b.bin for boot variable "system".
[####################] 100% -- SUCCESS
 
   
Verifying image type.
[####################] 100% -- SUCCESS
 
   
Extracting "system" version from image bootflash:/nexus-1000v-mz.4.2.1.SV1.4b.bin.
[####################] 100% -- SUCCESS
 
   
Extracting "kickstart" version from image 
bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4b.bin.
[####################] 100% -- SUCCESS
 
   
Notifying services about system upgrade.
[####################] 100% -- SUCCESS
 
   
 
   
 
   
Compatibility check is done:
Module  bootable          Impact  Install-type  Reason
------  --------  --------------  ------------  ------
     1       yes  non-disruptive         reset  
     2       yes  non-disruptive         reset  
 
   
 
   
 
   
Images will be upgraded according to following table:
Module       Image         Running-Version             New-Version  Upg-Required
------  ----------  ----------------------  ----------------------  ------------
     1      system            4.2(1)SV1(4)           4.2(1)SV1(4b)           yes
     1   kickstart            4.2(1)SV1(4)           4.2(1)SV1(4b)           yes
     2      system            4.2(1)SV1(4)           4.2(1)SV1(4b)           yes
     2   kickstart            4.2(1)SV1(4)           4.2(1)SV1(4b)           yes
 
   
 
   
Module         Running-Version                                         ESX Version       
VSM Compatibility       ESX Compatibility
------  ----------------------  ----------------------------------------------------  
----------------------  ----------------------
     3            4.2(1)SV1(4)         VMware ESXi 4.0.0 Releasebuild-208167 (1.9)              
COMPATIBLE              COMPATIBLE
 
   
Do you want to continue with the installation (y/n)?  [n]
 
   

Step 15 If you want to continue with the installation, press Y.


Note If you press N, the installation exits gracefully.


Install is in progress, please wait.
 
   
Syncing image bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4b.bin to standby.
[####################] 100% -- SUCCESS
 
   
Syncing image bootflash:/nexus-1000v-mzg.4.2.1.SV1.4b.bin to standby.
[####################] 100% -- SUCCESS
 
   
Setting boot variables.
[####################] 100% -- SUCCESS
 
   
Performing configuration copy.
[####################] 100%2011 Mar 31 03:49:42 BL1-VSM 
%SYSMGR-STANDBY-5-CFGWRITE_STARTED: Configuration copy started (PID 3660).
[####################] 100% -- SUCCESS

Note As part of the upgrade process, the standby VSM is reloaded with new images. Once it becomes the HA standby again, the upgrade process initiates a switchover. The upgrade then continues from the new active VSM with the following output.


Continuing with installation, please wait
 
   
Module 2: Waiting for module online
-- SUCCESS
 
   
Install has been successful 
 
   

Step 16 After the installation operation completes, log in and verify that the switch is running the required software version.

switch# show version
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2011, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained herein are owned by
other third parties and are used and distributed under license.
Some parts of this software are covered under the GNU Public
License. A copy of the license is available at
http://www.gnu.org/licenses/gpl.html.
 
   
Software
  loader:    version unavailable [last: loader version not available]
  kickstart: version 4.2(1)SV1(4b)
  system:    version 4.2(1)SV1(4b)
  kickstart image file is: bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4b.bin
  kickstart compile time:  3/27/2011 14:00:00 [03/27/2011 22:26:45]
  system image file is:    bootflash:/nexus-1000v-mz.4.2.1.SV1.4b.bin
  system compile time:     3/27/2011 14:00:00 [03/28/2011 00:56:08]
 
   
 
   
Hardware
  cisco Nexus 1000V Chassis ("Virtual Supervisor Module")
  Intel(R) Xeon(R) CPU         with 2075740 kB of memory.
  Processor Board ID T5056B050BB
 
   
  Device name: BL1-VSM
  bootflash:    3122988 kB
 
   
Kernel uptime is 0 day(s), 0 hour(s), 6 minute(s), 23 second(s)
 
   
 
   
plugin
  Core Plugin, Ethernet Plugin, Virtualization Plugin
...

Upgrading a Device with a Single VSM


Note This procedure is applicable only if the VSM is in standalone mode. This procedure does not work if the VSM is primary or secondary and the standby is shut down.


This section describes how to upgrade a Cisco Nexus 1000V device with a single VSM.

The best practice for deployment of VSMs is in an HA pair in a production environment. The VSM standalone redundancy role can be used in a test or demo environment, but we recommend that you deploy VSMs in an HA pair in such environments.

Upgrade Procedure Summary

To upgrade a device that has a single VSM to the latest Cisco Nexus 1000V software, follow these steps:


Step 1 Log in to the console port on the standalone VSM.

Step 2 Log in to www.cisco.com and download the latest Cisco Nexus 1000V kickstart and system images to a server.

Step 3 Download the Cisco Nexus 1000V kickstart and system images from the server to either the VSM bootflash or to a location from which they can be retrieved by the install all command.

Step 4 Save the switch configuration by using the copy running-config startup-config command.

Step 5 Enter the install all command at the VSM command prompt to upgrade the Cisco Nexus 1000V software on your switch.


Caution Reloading the device disrupts traffic on the device.

Detailed Upgrade Procedure

To upgrade to the latest Cisco Nexus 1000V software on a device with a single VSM, follow these steps:


Step 1 Log in to the VSM on the console.

Step 2 Log in to Cisco.com to access the links provided in this document. To log in to Cisco.com, go to the URL http://www.cisco.com/ and click Log In at the top of the page. Enter your Cisco username and password.


Note Unregistered Cisco.com users cannot access the links provided in this document.


Step 3 Access the Software Download Center by using this URL: http://www.cisco.com/public/sw-center/index.shtml

Step 4 Navigate to the download site for your switch.

You see links to the download images for your switch.

Step 5 Select and download the Cisco Nexus 1000 zip file and extract the kickstart and system software files to a server.

Step 6 Ensure that the required space is available for the image files to be copied.

switch# dir bootflash:
.
.
.
Usage for bootflash://sup-local
1957335040 bytes used
1240604672 bytes free 
3197939712 bytes total

Tip We recommend that you have the kickstart and system image files for at least one previous release of the Cisco Nexus 1000V software on the device to use if the new image files do not load successfully.


Step 7 If you need more space on the VSM bootflash, delete unnecessary files to make space available.

Step 8 If you plan to install the images from the bootflash:, copy the Cisco Nexus 1000 kickstart and system images to the active VSM bootflash using a transfer protocol. You can use ftp:, tftp:, scp:, or sftp:. The examples in this procedure use scp:.


Note When you download an image file, change to your FTP environment IP address or DNS name and the path where the files are located.


switch# copy 
scp://user@scpserver.cisco.com//downloads/nexus-1000v-kickstart-mz.4.2.1.SV1.4b.bin
bootflash:nexus-1000v-kickstart-mz.4.2.1.SV1.4b.bin
switch# copy scp://user@scpserver.cisco.com//downloads/nexus-10000v-mz.4.2.1.SV1.4b.bin
bootflash:nexus-1000v-mz.4.2.1.SV1.4b.bin
 
   

Step 9 Read the release notes for the related image file. See the Cisco Nexus 1000V Release Notes, Release 4.2(1)SV1(4b).

Step 10 Determine the VSM status.

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

Step 11 Save the running configuration to the start configuration.

switch# copy running-config startup-config 
 
   

Step 12 To update the boot variables and module images on the VSM.

switch# install all kickstart bootflash:nexus-1000v-kickstart-mzg.4.2.1.SV1.4b.bin system 
bootflash:nexus-1000v-mzg.4.2.1.SV1.4b.bin 
 
   
Verifying image bootflash:/nexus-1000v-kickstart-mzg.4.2.1.SV1.4b.bin for boot variable 
"kickstart".
[####################] 100% -- SUCCESS
 
   
Verifying image bootflash:/nexus-1000v-mzg.4.2.1.SV1.4b.bin for boot variable "system".
[####################] 100% -- SUCCESS
 
   
Verifying image type.
[####################] 100% -- SUCCESS
 
   
Extracting "system" version from image bootflash:/nexus-1000v-mzg.4.2.1.SV1.4b.bin.
[####################] 100% -- SUCCESS
 
   
Extracting "kickstart" version from image 
bootflash:/nexus-1000v-kickstart-mzg.4.2.1.SV1.4b.bin.
[####################] 100% -- SUCCESS
 
   
Notifying services about system upgrade.
[####################] 100% -- SUCCESS
 
   
 
   
 
   
Compatibility check is done:
Module  bootable          Impact  Install-type  Reason
------  --------  --------------  ------------  ------
     1       yes      disruptive         reset  Reset due to single supervisor
 
   
 
   
 
   
Images will be upgraded according to following table:
Module       Image         Running-Version             New-Version  Upg-Required
------  ----------  ----------------------  ----------------------  ------------
     1      system            4.2(1)SV1(4)           4.2(1)SV1(4b)           yes
     1   kickstart            4.2(1)SV1(4)           4.2(1)SV1(4b)           yes
 
   
 
   
Module         Running-Version                                         ESX Version       
VSM Compatibility       ESX Compatibility
------  ----------------------  ----------------------------------------------------  
----------------------  ----------------------
     3            4.2(1)SV1(4)         VMware ESXi 4.0.0 Releasebuild-208167 (1.9)              
COMPATIBLE              COMPATIBLE
 
   
Switch will be reloaded for disruptive upgrade.
Do you want to continue with the installation (y/n)?  [n]
 
   

Step 13 If you want to continue with the installation, press Y.


Note If you press N, the installation exits gracefully.


Install is in progress, please wait.
 
   
Setting boot variables.
[####################] 100% -- SUCCESS
 
   
Performing configuration copy.
[####################] 100% -- SUCCESS
 
   
Finishing the upgrade, switch will reboot in 10 seconds.
 
   

Step 14 After the switch completes the reload operation, log in and verify that the switch is running the required software version.

switch# show version
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2011, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained herein are owned by
other third parties and are used and distributed under license.
Some parts of this software are covered under the GNU Public
License. A copy of the license is available at
http://www.gnu.org/licenses/gpl.html.
 
   
Software
  loader:    version unavailable [last: loader version not available]
  kickstart: version 4.2(1)SV1(4b)
  system:    version 4.2(1)SV1(4b)
  kickstart image file is: bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4b.bin
  kickstart compile time:  3/27/2011 14:00:00 [03/27/2011 22:26:45]
  system image file is:    bootflash:/nexus-1000v-mz.4.2.1.SV1.4b.bin
  system compile time:     3/27/2011 14:00:00 [03/28/2011 00:56:08]
 
   
 
   
Hardware
  cisco Nexus 1000V Chassis ("Virtual Supervisor Module")
  Intel(R) Xeon(R) CPU         with 2075740 kB of memory.
  Processor Board ID T5056B050BB
 
   
  Device name: BL1-VSM
  bootflash:    3122988 kB
 
   
Kernel uptime is 0 day(s), 0 hour(s), 6 minute(s), 23 second(s)
 
   
 
   
plugin
  Core Plugin, Ethernet Plugin, Virtualization Plugin
...
 
   

Step 15 Continue to the "Upgrading the VEMs from Release 4.2(1)SV1(4) or 4.2(1)SV1(4a) to Release 4.2(1)SV1(4b)" section.


Upgrading the VEMs from Release 4.2(1)SV1(4) or 4.2(1)SV1(4a) to Release 4.2(1)SV1(4b)

This section describes how to upgrade VEMs from Release 4.2(1)SV1(4) or 4.2(1)SV1(4a) to Release 4.2(1)SV1(4b) and includes the following topics:

Upgrading the VEMs Using VMware Update Manager from Release 4.2(1)SV1(4) or 4.2(1)SV1(4a) to Release 4.2(1)SV1(4b)

Upgrading the VEMs Manually from Release 4.2(1)SV1(4) or 4.2(1)SV1(4a) to Release 4.2(1)SV1(4b)

Prerequisites to Upgrading VEMs

Upgrading VEMs has the following prerequisites:

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 from Release 4.2(1)SV1(4) or 4.2(1)SV1(4a) to Release 4.2(1)SV1(4b)

To upgrade the VEMs using VMware Update Manager (VUM), follow these steps:


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

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# 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-201107031-RG  
    DVS: VEM400-201101030-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(4b).


Step 4 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-201107031-RG  
    DVS: VEM400-201101030-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(4b).


Step 5 Initiate the VUM upgrade process.

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-201107031-RG  
    DVS: VEM400-201107031-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, the 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 6 Check for the upgrade complete status.

switch# show vmware vem upgrade status
Upgrade VIBs: System VEM Image
Upgrade Status: Upgrade Complete in vCenter 
Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010
Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010
Upgrade Start Time: Wed Mar 17 15:20:06 2010
Upgrade End Time(vCenter): Wed Mar 17 17:30:48 2010
Upgrade Error:
Upgrade Bundle ID:
    VSM: VEM400-201107031-RG  
    DVS: VEM400-201107031-RG  
 
   

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


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:
Upgrade Bundle ID:
    VSM: VEM400-201107031-RG 
    DVS: VEM400-201107031-RG 
 
   

Step 8 Verify that the upgrade process is complete.

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
4    248    Virtual Ethernet Module          NA                 ok
 
   
Mod  Sw               Hw 
---  ---------------  ------ 
1    4.2(1)SV1(4b)     0.0 
2    4.2(1)SV1(4b)     0.0 
3    4.2(1)SV1(4b)     VMware ESXi 4.0.0 Releasebuild-261974 (1.20) 
4    4.2(1)SV1(4b)     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 displays that all VEMs are upgraded to Release 4.2(1)SV1(4b).


Step 9 Run the VSM Backup procedure.

See the "Configuring VSM Backup and Recovery" chapter of the Cisco Nexus 1000V System Management Configuration Guide, Release 4.2(1)SV1(4b).

The upgrade is complete.


Upgrading the VEMs Manually from Release 4.2(1)SV1(4) or 4.2(1)SV1(4a) to Release 4.2(1)SV1(4b)

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 VEM Software Installation and Upgrade Guide, Release 4.2(1)SV1(4b).

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.



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 Coordinate with and notify the server administrator of the VEM upgrade process.

switch (config)# vmware vem upgrade notify
Warning: 
Please ensure the hosts are running compatible ESX versions for the upgrade. Refer to 
corresponding "Cisco Nexus 1000V and VMware Compatibility Information" guide.
 
   

Step 2 Verify that the upgrade notification was sent.

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

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

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

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

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

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

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

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


Note If VUM is enabled in the vCenter environment, disable it before 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" error appears in the vCenter Server's task bar. You can ignore this error message.


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

Step 6 Check for the Upgrade Complete status.

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

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

The server administrator performs the manual upgrade using the vi host update or the ESX/ESXi update. For details, see the Cisco Nexus 1000V VEM Software Installation and Upgrade Guide, Release 4.2(1)SV1(4b).

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

Step 9 Verify that the upgrade process is complete.

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
4    248    Virtual Ethernet Module          NA                 ok
 
   
Mod  Sw               Hw 
---  ---------------  ------ 
1    4.2(1)SV1(4b)     0.0 
2    4.2(1)SV1(4b)     0.0 
3    4.2(1)SV1(4b)     VMware ESXi 4.0.0 Releasebuild-261974 (1.20) 
4    4.2(1)SV1(4b)     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(4b).


Step 10 Run the VSM Backup procedure.

See the "Configuring VSM Backup and Recovery" chapter of the Cisco Nexus 1000V System Management Configuration Guide, Release 4.2(1)SV1(4b).

The upgrade is complete.


Downgrading from Release 4.2(1)SV1(4b) to Release 4.2(1)SV1(4)

This section describes how to downgrade the VSMs and VEMs from Release 4.2(1)SV1(4b) to Release 4.2(1)SV1(4).

BEFORE YOU BEGIN

Before running these procedures, you must know or do the following:

The downgrade will be hitful and will have an impact on the VM traffic.

You have aborted the upgrade from Release 4.2(1)SV1(4) to Release 4.2(1)SV1(4b).

The upgrade from Release 4.2(1)SV1(4) to Release 4.2(1)SV1(4b) failed.

The reason that the downgrading procedures are being run in the reverse order of the upgrade is because VSM Release 4.2(1)SV1(4) is not compatible with VEM Release 4.2(1)SV1(4b). If you were to revert the VSM to the earlier release first, none of the modules would reinsert.

Downgrading the VEMs from Release 4.2(1)SV1(4b) to Release 4.2(1)SV1(4)

To downgrade the VEMs, follow these steps:


Step 1 Disable VUM.

Step 2 Put the host in Maintenance Mode from the vCenter Server by right-clicking the host and choosing Enter Maintenance Mode in the Host and Clusters section.

Step 3 In the vCenter Server, from the Home > Inventory > Networking, choose the DVS and click the Host tab.

Step 4 Right-click the host and choose Remove from vSphere Distributed Switch.

Step 5 Remove the Nexus 1000V VEM bits by using SSH or the host console.

switch# vem remove -r -d
 
   

Step 6 Power cycle the host.

switch# reboot
 
   

Step 7 Install the 4.2(1)SV1(4) version of VEM on the host. See the Cisco Nexus 1000V VEM Software Installation and Upgrade Guide, Release 4.2(1)SV1(4b).

Step 8 Disable VUM.

Step 9 Add the host back to DVS.

Step 10 Exit the host from Maintenance mode.

Step 11 Repeat Step 2 through Step 10 for each host.


Downgrading the VSMs from Release 4.2(1)SV1(4b) to Release 4.2(1)SV1(4)

To downgrade the VSMs, follow these steps:


Step 1 Make a backup of the VSM running configuration.

For safety reasons, we recommended that you make both a local backup (bootflash) and a copy to a remote server.

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

See the "Changing Boot Variables Manually" section for details.

Step 3 Reload system with the reload command.

Step 4 Update the DVS bundleID with the Release 4.2(1)SV1(4) ID.

switch# vmware vem upgrade notify
switch# vmware vem upgrade proceed 
switch# vmware vem upgrade complete 
 
   

Step 5 If VUM was disabled, reenable it.


Changing Boot Variables Manually

In certain cases you might need to set the boot variables manually such as when an ISSU upgrade attempt fails and you want to postpone or if you want to revert the system to an earlier image.


Note Reverting the system to an earlier image is not a hitless operation and we do not recommended that you do so.



Step 1 Set boot variables.

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

Step 2 Display the current boot variables.

switch# show boot 
Current Boot Variables:
 
   
sup-1
kickstart variable = bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin
system variable = bootflash:/nexus-1000v-mz.4.2.1.SV1.4.bin
sup-2
kickstart variable = bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin
system variable = bootflash:/nexus-1000v-mz.4.2.1.SV1.4.bin
No module boot variable set
 
   
Boot Variables on next reload:
 
   
sup-1
kickstart variable = bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4b.bin
system variable = bootflash:/nexus-1000v-mz.4.2.1.SV1.4b.bin
sup-2
kickstart variable = bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4b.bin
system variable = bootflash:/nexus-1000v-mz.4.2.1.SV1.4b.bin
No module boot variable set

Boot variables are part of the configuration and they take effect on the next reload only when the configuration is saved by using the copy running-config startup-config command.

When changing the boot variables manually, you might see the following message:

Note: system and kickstart bootvars are pointing to incompatible images
 
   

This occurs because kickstart and system images must be updated individually and each kickstart image is only compatible with one system image and vice versa. After updating one of them, a temporary incompatible situation occurs. However, you must ensure that both kickstart and system images are set to compatible images (the same version) before saving the configuration, which makes the changes persistent.

Upgrading from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b)

Figure 22 depicts the upgrade process of Release 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b).

Figure 22 Upgrading from 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to 4.2(1)SV1(4b)


Note For ESX/ESXi Release 4.1.0 and later releases, the minimum VC/VUM version required is 258902/256596
For ESX/ESXi Release 4.0.0 and later releases, 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, enter the system switchover command to make the secondary VSM active.

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


Step 1 Upgrading the VEMs for Releases 4.0(4)SV(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b). See the "Upgrading the VEMs from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b)" section.

Step 2 Upgrading the VSMs for Releases 4.0(4)SV(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b). See the "Upgrading the VSMs from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b) Using the Upgrade Application" section.


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

The following diagram depicts the upgrade process of Releases 4.0(4)SV1(1, 2) to Release 4.2(1)SV1(4b).

Figure 23 Upgrading from Release 4.0(4)SV1(1, 2) to Release 4.2(1)SV1(4b)


Note For ESX/ESXi Release 4.1.0 and later releases, the minimum VC/VUM version required is 258902/256596
For ESX/ESXi Release 4.0.0 and later releases, 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(4b), follow these steps:


Step 1 Upgrading the VSMs from Release 4.0(4)SV1(1, 2) to Release 4.0(4)SV1(3d)

Step 2 Upgrading the VEMs from Releases 4.0(4)SV1(1, 2) to Release 4.2(1)SV1(4b)

Step 3 Upgrading the VSMs from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b) Using the Upgrade Application


Upgrading the VSMs

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

Upgrading the VSMs from Release 4.2(1)SV1(4) or 4.2(1)SV1(4a) to Release 4.2(1)SV1(4b)

Upgrading the VSMs from Release 4.0(4)SV1(1, 2) to Release 4.0(4)SV1(3d)

Upgrading the VSMs from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b) Using the Upgrade Application

Upgrading the VSMs from Release 4.0(4)SV1(1, 2) to Release 4.0(4)SV1(3d)

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

Prerequisites to Upgrading the VSMs

The following are prerequisites to upgrading the VSMs:

Execute and correct errors from the PreUpgradeUtility.

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

Note that the network and server administrators must 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.3d.bin

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

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

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

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

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


Note This procedure is performed by the network administrator.



Step 1 Back up the configuration to an external server.

Step 2 Power off all VMs except the VSM and vCenter (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.3d.bin
2009 Dec 13 15:50:40.568 n1k-av %BOOTVAR-5-IMAGE_NOTEXISTS: Warning: image 
nexus-1000v-mz.4.0.4.SV1.3d.bin doesn't exist on sup2
2009 Dec 13 15:51:28.236 n1k-av %BOOTVAR-5-AUTOCOPY_SUCCEED: auto-copy of file 
/bootflash/nexus-1000v-mz.4.0.4.SV1.3d.bin to standby supervisor succeed
switch(config)# boot kickstart bootflash:nexus-1000v-kickstart-mzg.4.0.4.SV1.3d.bin
2009 Dec 13 15:54:03.093 n1k-av %BOOTVAR-5-IMAGE_NOTEXISTS: Warning: image 
nexus-1000v-kickstart-mz.4.0.4.SV1.3d.bin doesn't exist on sup2
2009 Dec 13 15:54:20.966 n1k-av %BOOTVAR-5-AUTOCOPY_SUCCEED: auto-copy of file 
/bootflash/nexus-1000v-kickstart-mz.4.0.4.SV1.3d.bin to standby supervisor succeed
switch(config)# 
 
   

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, 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, 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.3d.bin sup-1
boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3d.bin sup-1
boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3d.bin sup-2
boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3d.bin sup-2
 
   
switch# show running-config | include boot
boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3d.bin sup-1
boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3d.bin sup-1
boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3d.bin sup-2
boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3d.bin sup-2
 
   

Step 7 Verify the VSM active and standby module status.

switch# show 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
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(3d).


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 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
4    248    Virtual Ethernet Module          NA                 ok
 
   
Mod  Sw               Hw 
---  ---------------  ------ 
1    4.0(4)SV1(3d)     0.0 
2    4.0(4)SV1(3d)     0.0 
3    4.0(4)SV1(1)     1.11 
4    4.0(4)SV1(1)     1.11 
 
   
Mod  MAC-Address(es)                         Serial-Num
---  --------------------------------------  ----------
1    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA 
2    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA 
3    02-00-0c-00-03-00 to 02-00-0c-00-03-80  NA 
4    02-00-0c-00-04-00 to 02-00-0c-00-04-80  NA 
 
   
Mod  Server-IP        Server-UUID                           Server-Name
---  ---------------  ------------------------------------  --------------------
1    10.78.109.100    NA                                    NA
2    10.78.109.100    NA                                    NA
3    10.78.109.104    1ee15784-f2e8-383e-8132-9026577ca1bb  10.78.109.104
4    10.78.109.102    44454c4c-4700-104e-804d-cac04f563153  10.78.109.102
* this terminal session 

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


Step 10 (Optional) If you have configured nondefault (jumbo) MTU settings, see the "Nondefault (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(4b).

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


Upgrading the VEMs

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

Upgrading the VEMs from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b)

Upgrading the VEMs from Releases 4.0(4)SV1(1, 2) to Release 4.2(1)SV1(4b)

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

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(4b).


Caution Do not run the vemlog, vemcmd, or vempkt commands during the VEM upgrade process because these commands impact the upgrade.

Upgrading the VEMs from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b)

This section describe show how to upgrade VEMs from Release 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b) and includes the following topics:

Upgrading the VEMs Using VUM from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b)

Upgrading the VEMs Manually from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b)

Prerequisites to Upgrading VEMs

The following are prerequisites to upgrading the VEMs:

Execute and correct errors from the PreUpgradeUtility.

Log in to the VSM CLI in EXEC mode.

Note that network and server administrators must coordinate the VEM upgrade with each other.

Upgrading the VEMs Using VUM from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b)

To upgrade the VEMs using VMware Update Manager (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.



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.

In this example, you are upgrading from Release 4.0(4)SV1(3d) to Release 4.2(1)SV1(4b).


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

These files are 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-201105124101-BG
    DVS: VEM400-201105124101-BG
 
   

Step 3 Update the VSM bundle ID by entering the following command.

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

Step 4 Verify that the upgrade notification was sent.

switch(config-port-prof)# show vmware vem upgrade status 
 
Upgrade VIBs: Upgraded 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-201203031-RG 
    DVS: VEM400-201105124101-BG 


Note The VSM Bundle ID now deploys the Release 4.2(1)SV1(4b) 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-201107031-RG  
    DVS: VEM400-201105124101-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(4b).


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-201107031-RG  
    DVS: VEM400-201105124101-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(4b).


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

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 uses vMotion to move 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, the VUM upgrade fails 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(4b).


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

The DVS bundle ID is updated and is highlighted. Before entering the following command, communicate with 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: VEM400-201107031-RG
    DVS: VSM400-201107031-RG 
 
   

Step 11 Verify that the upgrade process is complete.

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
4    248    Virtual Ethernet Module          NA                 ok
 
   
Mod  Sw               Hw 
---  ---------------  ------ 
1    4.2(1)SV1(3d)     0.0 
2    4.2(1)SV1(3d)     0.0 
3    4.2(1)SV1(4b)     VMware ESXi 4.0.0 Releasebuild-261974 (1.20) 
4    4.2(1)SV1(4b)     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 displays that all VEMs are upgraded to Release 4.2(1)SV1(4b).


Step 12 Proceed to upgrade the VSM.


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

For details, see the "Upgrading the VSMs from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b) Using the Upgrade Application" section.


Upgrading the VEMs Manually from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b)

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 VEM Software Installation and Upgrade Guide, Release 4.2(1)SV1(4b).

To upgrade the VEMs manually, 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.



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.

In this example, you are upgrading from Release 4.0(4)SV1(3d) to Release 4.2(1)SV1(4b).


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-201107031-RG  
    DVS: VEM400-201105124101-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-201107031-RG  
    DVS: VEM400-201105124101-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 VEM Software Installation and Upgrade Guide, Release 4.2(1)SV1(4b).

If the ESX host is not hosting the VSM, 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 entering the vmware vem upgrade proceed command to prevent the new vSphere Installation Bundles (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 interal error.
Upgrade Bundle ID:
    VSM: VEM400-201107031-RG  
    DVS: VEM400-201107031-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(4b).


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-201107031-RG  
    DVS: VEM400-201107031-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 VEM Software Installation and Upgrade Guide, Release 4.2(1)SV1(4b).

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

Step 11 Verify that the upgrade process is complete.

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
4    248    Virtual Ethernet Module          NA                 ok
 
   
Mod  Sw               Hw 
---  ---------------  ------ 
1    4.2(1)SV1(3d)     0.0 
2    4.2(1)SV1(3d)     0.0 
3    4.2(1)SV1(4b)     VMware ESXi 4.0.0 Releasebuild-261974 (1.20) 
4    4.2(1)SV1(4b)     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(4b).


Step 12 Proceed to upgrade the VSM.


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

For details, see the "Upgrading the VSMs from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b) Using the Upgrade Application" section.


Upgrading the VEMs from Releases 4.0(4)SV1(1, 2) to Release 4.2(1)SV1(4b)

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

Upgrading the VEMs from Releases 4.0(4)SV1(1, 2) to Release 4.2(1)SV1(4b)

Upgrading the VEMs Manually from Releases 4.0(4)SV1(1, 2) to Release 4.2(1)SV1(4b)

Prerequisites to Upgrading VEMs

The following are prerequisites to upgrading the VEMs:

Execute and correct errors from the PreUpgradeUtility.

Log in to the VSM CLI in EXEC mode.

Upgraded the VSM to Release 4.0(4)SV1(3d).

Note that network and server administrators must coordinate the VEM upgrade with each other.

Upgrading the VEMs Using VUM from Releases 4.0(4)SV1(1, 2) to Release 4.2(1)SV1(4b)

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, go to the "Upgrading the VEMs Manually from Releases 4.0(4)SV1(1, 2) to Release 4.2(1)SV1(4b)" section.

In this example, you are upgrading from Release 4.0(4)SV1(2) to Release 4.2(1)SV1(4b).


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-201107031-RG
    DVS: VEM400-200912267-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(4b).


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

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

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

Step 9 Verify that the upgrade process is complete.

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
4    248    Virtual Ethernet Module          NA                 ok
 
   
Mod  Sw               Hw 
---  ---------------  ------ 
1    4.2(1)SV1(3d)     0.0 
2    4.2(1)SV1(3d)     0.0 
3    4.2(1)SV1(4b)     VMware ESXi 4.0.0 Releasebuild-261974 (1.20) 
4    4.2(1)SV1(4b)     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(4b).


Step 10 Proceed to upgrade the VSM.


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

For details, see the "Upgrading the VSMs from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b) Using the Upgrade Application" section.


Upgrading the VEMs Manually from Releases 4.0(4)SV1(1, 2) to Release 4.2(1)SV1(4b)

To upgrade the VEMs manually, follow these steps:


Note This procedure is initiated by the network administrator. Before proceeding with the upgrade, make sure the VMs are powered off. The VSM must be upgraded to Release 4.0(4)SV1(3d).



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-201107031-RG  
    DVS: VEM400-200912267-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(4b).


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-201107031-RG  
    DVS: VEM400-200912267-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 VEM Software Installation and Upgrade Guide, Release 4.2(1)SV1(4b).

If the ESX host is not hosting the VSM/vCenter Server (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 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 
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-201107031-RG  
    DVS: VEM400-201107031-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 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
4    248    Virtual Ethernet Module          NA                 ok
 
   
Mod  Sw               Hw 
---  ---------------  ------ 
1    4.2(1)SV1(3d)     0.0 
2    4.2(1)SV1(3d)     0.0 
3    4.2(1)SV1(4b)     VMware ESXi 4.0.0 Releasebuild-261974 (1.20) 
4    4.2(1)SV1(4b)     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(4b).


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(4b)

For details, see the "Upgrading the VSMs from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b) Using the Upgrade Application" section.


Upgrading the VSMs from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b) Using the Upgrade Application

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

If you are upgrading from Release 4.0(4)SV1(1) or Release 4.0(4)SV1(2), you should have already upgraded the VSM to Release 4.0(4)SV1(3d). See the "Upgrading the VSMs from Release 4.0(4)SV1(1, 2) to Release 4.0(4)SV1(3d)" section.

During this hitless VSM upgrade procedure, the VEMs that are connected via Layer 3 will flap during the upgrade when temporary IP addresses are programmed. Traffic flow is not affected.


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, enter 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:

Execute and correct errors from the PreUpgradeUtility.

Upgrade VEMs to Release 4.2(1)SV1(4b) 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 must enter additional IP addresses that are in the same subnet depending on your Layer 2 or Layer 3 setup. This additional IP address is required because one VSM will be on a previous release and the other VSM is on Release 4.2(1)SV1(4b).


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(4b) to recover the system.

Enable SSH on the VSM.

Ensure that you have a synchronized HA pair 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 by Layer 3 will flap during the upgrade when the temporary IP addresses are programmed. Traffic flow is not affected.


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


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.

This procedure is performed by the network administrator.


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 window opens. See Figure 24.

Figure 24 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 does not appear in the window. If you still want to upgrade, you can run the Upgrade Application from the http://<vsm-ip-address>/cgi-bin/upgrade.jnlp directory.

If the VEMs are not upgraded to Release 4.2(1)SV1(4b), the Launch Upgrade Application link is not seen in the window.


Step 4 Click Run in the Warning - Security screen.

The Enter VSM Credentials screen opens. See Figure 25.

Figure 25 Enter VSM Credentials Screen

Step 5 Enter the VSM password and click Next.

The Verify Module Upgrade screen opens. See Figure 26

Figure 26 Verify Module Upgrade Screen

Step 6 Verify that the module count is correct.

Step 7 If you are having Layer 3 connectivity using control0 to connect to VEMs, then continue with this step; otherwise go to Step 8.

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

b. Check if there are subnet or default routes associated with the control0 interface as follows:

Entering 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
 
   

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


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

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

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


Note If you decide not to upgrade, click Override: Force Upgrade 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.

Depending on whether you have a Layer 2 or Layer 3 configuration, the Nexus 1000V Upgrade: Layer2-Enter Upgrade Information screen opens (see Figure 27) or the Nexus 1000V Upgrade: Layer3-Enter Upgrade Information screen in Step 12 opens (see Figure 28).

Step 10 If you have a Layer 2 configuration, continue with Step 11. If you have a Layer 3 configuration, proceed to Step 12.

Figure 27 Layer 2 - Enter Upgrade Information for L2 Screen

Step 11 Perform the following for your Layer 2 configuration:

a. In the Current VSM IP Address field, enter a temporary IPv4 IP address for interface mgmt0.

b. From the New System Image drop-down list, choose nexus-1000v-mz.4.2.1.SV1.4b.bin.

c. From the New Kickstart Image drop-down list, choose nexus-1000v-kickstart-mz.4.2.1.SV1.4b.bin.

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

e. Go to Step 13.

Figure 28 Nexus 1000V Upgrade: Layer 3 - Enter Upgrade Information for L3 Screen

Step 12 Perform the following for your Layer 3 configuration:

a. In the Temporary Upgrade Ipv4 address for interface mgmt0 0 field, enter a temporary IPv4 IP address for interface mgmt0.

b. In the Temporary Upgrade Ipv4 address for L3 interface control 0 field, enter a temporary IPv4 IP address for L3 interface control0.

c. From the New System Image drop-down list, choose nexus-1000v-mz.4.2.1.SV1.4b.bin.

d. From the New Kickstart Image drop-down list, choose nexus-1000v-kickstart-mz.4.2.1.SV1.4b.bin.

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

f. Go to Step 13.


Note If you have a Layer 2 configuration, the Nexus 1000V Upgrade: Layer 2 - Please Review Configurations screen opens. See Figure 29. If you have a Layer 3 configuration, the Nexus 1000V Upgrade: Layer 3 - Please Review Configurations screen opens. See Figure 30.


Figure 29 Nexus 1000V Upgrade: Layer 2 - Please Review Configurations Screen

Figure 30 Nexus 1000V Upgrade: Layer 3 - Please Review Configurations Screen

Step 13 Confirm the settings and click Next. The Upgrade Progress screen opens and the upgrade of the first VSM begins. Go to Step 14.


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

Figure 31 Nexus 1000V Upgrade: Second VSM Upgrade Progress Screen

When the upgrade process completes, the Nexus 1000V Upgrade: Verify Module Insertion screen opens. See Figure 32.

Figure 32 Nexus 1000V Upgrade: Verify Module Insertion Screen

To refesh this screen, press the Refresh List button.


Caution Do not click the Override: Force Upgrade button.

 
   

Step 14 Log in to the temporary IP address or console of the Release 4.2(1)SV1(4b) VSM and enter to check if the module status displays as ok for the VEMs and that all interfaces are in the up 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
4    248    Virtual Ethernet Module           NA                  ok
5    248    Virtual Ethernet Module           NA                  ok
6    248    Virtual Ethernet Module           NA                  ok
7    248    Virtual Ethernet Module           NA                  ok
8    248    Virtual Ethernet Module           NA                  ok
9    248    Virtual Ethernet Module           NA                  ok
10   248    Virtual Ethernet Module           NA                  ok
11   248    Virtual Ethernet Module           NA                  ok
12   248    Virtual Ethernet Module           NA                  ok
13   248    Virtual Ethernet Module           NA                  ok
14   248    Virtual Ethernet Module           NA                  ok
15   248    Virtual Ethernet Module           NA                  ok
16   248    Virtual Ethernet Module           NA                  ok
 
   
Mod  Sw                Hw      
---  ----------------  ------------------------------------------------  
1    4.2(1)SV1(3d)   0.0                                              
2    4.2(1)SV1(4b)   0.0
 
   
switch# show interface brief 
 
   
--------------------------------------------------------------------------------
Port     VRF          Status IP Address                            Speed    MTU
--------------------------------------------------------------------------------
mgmt0    --           up     10.78.1.141                           1000     1500
 
   
--------------------------------------------------------------------------------
Ethernet      VLAN   Type Mode   Status  Reason                   Speed     Port
Interface                                                                   Ch #
--------------------------------------------------------------------------------
Eth3/4        1      eth  trunk  up      none                        10G     10
Eth3/5        1      eth  trunk  up      none                        10G     10
Eth4/2        1      eth  trunk  up      none                        10G     11
Eth5/3        1      eth  trunk  up      none                        10G     13
Eth5/4        1      eth  trunk  up      none                        10G     13
Eth6/3        1      eth  trunk  up      none                        10G      5
Eth6/4        1      eth  trunk  up      none                        10G      5
Eth7/3        1      eth  trunk  up      none                        10G      7
Eth7/4        1      eth  trunk  up      none                        10G      7
Eth8/2        1      eth  trunk  up      none                        10G      8
Eth9/2        1      eth  trunk  up      none                        10G      1
Eth10/3       1      eth  trunk  up      none                        10G     12
Eth10/4       1      eth  trunk  up      none                        10G     12
Eth11/4       1      eth  trunk  up      none                        10G      9
Eth11/5       1      eth  trunk  up      none                        10G      9
Eth12/11      1      eth  trunk  up      none                        10G      2
Eth12/12      1      eth  trunk  up      none                        10G      2
Eth13/2       1      eth  trunk  up      none                        10G     14
Eth14/2       1      eth  trunk  up      none                        10G      3
Eth15/2       1      eth  trunk  up      none                        10G      4
Eth16/4       1      eth  trunk  up      none                        10G      6
Eth16/5       1      eth  trunk  up      none                        10G      6
 
   
--------------------------------------------------------------------------------
Port-channel VLAN  Type Mode   Status  Reason                    Speed  Protocol
Interface                                                                
--------------------------------------------------------------------------------
Po1          1     eth  trunk  up      none                       a-10G(D)  none
Po2          1     eth  trunk  up      none                       a-10G(D)  none
Po3          1     eth  trunk  up      none                       a-10G(D)  none
Po4          1     eth  trunk  up      none                       a-10G(D)  none
Po5          1     eth  trunk  up      none                       a-10G(D)  none
Po6          1     eth  trunk  up      none                       a-10G(D)  none
Po7          1     eth  trunk  up      none                       a-10G(D)  none
Po8          1     eth  trunk  up      none                       a-10G(D)  none
Po9          1     eth  trunk  up      none                       a-10G(D)  none
Po10         1     eth  trunk  up      none                       a-10G(D)  none
Po11         1     eth  trunk  up      none                       a-10G(D)  none
Po12         1     eth  trunk  up      none                       a-10G(D)  none
Po13         1     eth  trunk  up      none                       a-10G(D)  none
Po14         1     eth  trunk  up      none                       a-10G(D)  none
 
   
--------------------------------------------------------------------------------
Vethernet     VLAN   Type Mode   Status  Reason                   Speed
--------------------------------------------------------------------------------
Veth1         1117   virt pvlan  up      none                       auto 
Veth2         464    virt access up      none                       auto 
Veth3         464    virt access up      none                       auto 
Veth4         464    virt access up      none                       auto 
Veth5         464    virt access up      none                       auto 
Veth6         464    virt access up      none                       auto 
Veth7         464    virt access up      none                       auto 
Veth8         464    virt access up      none                       auto 
Veth9         464    virt access up      none                       auto 
Veth10        464    virt access up      none                       auto 
Veth11        464    virt access up      none                       auto 
Veth12        464    virt access up      none                       auto
.
.
.
Veth998       464    virt access up      none                       auto 
Veth999       1403   virt access up      none                       auto 
Veth1000      464    virt access up      none                       auto 
Veth1001      464    virt access up      none                       auto 
Veth1002      1403   virt access up      none                       auto

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


Step 15 If you have L3 control mode of the testbed, then continue with this step. Otherwise, continue with Step 17.

Figure 33 All Modules Attached Screen

Step 16 Click Finish when all modules in the temporary IP VSM are displaying a status of ok.

The Verify Module Insertion screen opens (see Figure 34) for the second VSM upgrade.

Figure 34 Nexus 1000V Upgrade: Second VSM Upgrade Screen


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. See Figure 35.

Figure 35 Nexus 1000V Upgrade: Summary Screen

Step 17 1Click Close.

The upgrade of the VSMs is complete.

Step 18 Display the virtual device context ID of the VSM, by entering the following command:

switch(config)# show running-config | include vdc
vdc N1KV-VSM id 1
 
   

Step 19 Configure support for 2048 VLANs, by entering the following command:

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

Step 20 Run the VSM Backup procedure.

See the "Configuring VSM Backup and Recovery" chapter of the Cisco Nexus 1000V System Management Configuration Guide, Release 4.2(1)SV1(4b).

The upgrade is complete.


Upgrading the VSMs from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b) Using the Manual Upgrade Procedure

This section describes how to manually upgrade a VSM to Release 4.2(1)SV1(4b) from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) 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(4b).

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.

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(4b), follow these steps:


Step 1 Log in to the VSM.

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

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

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

Step 3 Display the current redundancy status.

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: DC
    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 is 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

switch(config)# show svs upgrade status

Upgrade State: Start

Upgrade mgmt0 ipv4 addr: 192.168.50.3

Upgrade mgmt0 ipv6 addr:

Upgrade control0 ipv4 addr: 191.168.50.3

Step 6 Update the system and kickstart boot variables.

switch# install all system bootflash: nexus-1000v-mz.4.2.1.SV1.4b.bin kickstart bootflash:nexus-1000v-kickstart-mz.4.2.1.SV1.4b.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.3d.bin sup-1

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

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

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


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


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

switch# reload module slot

This command will reboot standby supervisor module. (y/n)? [n] y
2011 June 14 20:11:51 av1-vsm %PLATFORM-2-PFM_MODULE_RESET: Manual restart of Module 2 
from Command Line Interface
switch# 2011 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 and enter the show module command to check for a status of ok on all VEMs.

AV5-VSM# 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
4    248    Virtual Ethernet Module           NA                  ok
5    248    Virtual Ethernet Module           NA                  ok
6    248    Virtual Ethernet Module           NA                  ok
7    248    Virtual Ethernet Module           NA                  ok
8    248    Virtual Ethernet Module           NA                  ok
9    248    Virtual Ethernet Module           NA                  ok
10   248    Virtual Ethernet Module           NA                  ok
11   248    Virtual Ethernet Module           NA                  ok
12   248    Virtual Ethernet Module           NA                  ok
13   248    Virtual Ethernet Module           NA                  ok
14   248    Virtual Ethernet Module           NA                  ok
15   248    Virtual Ethernet Module           NA                  ok
16   248    Virtual Ethernet Module           NA                  ok
 
   

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 it and the vCenter.


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 192.0.2.1

svs connection vc

  protocol vmware-vim

  remote up address 192.0.2.133 port 80

  vmware dvs uuid "0c bf 0e 50 0b 4a b7 76-88 13 be 45 14 e8 9b 4e" datacenter-name DC
  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.3d.bin sup-1

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

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

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

Step 13 Change the boot variables on VSM1 to point to the Release 4.2(1)SV1(4b) 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.4b.bin

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

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

switch(config)# end

switch# show run | in boot

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

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

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

boot system bootflash:/nexus-1000v-mzg.4.2.1.SV1.4b.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 have Layer 3 connectivity and are using control0 to connect to VEMs, continue with this step. Otherwise, go to Step 17.

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

b. Check if there are subnet or default routes associated with the control0 interface as follows:

Enter 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 the global config context.

    switch(config)# ip route 192.168.1.0/24 192.168.2.1 
    switch(config)# vrf context management 
    switch(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(4b) VSM and check if the module status is ok.

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

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


Note Make sure that all the VEMs are attached to the Release 4.2(1)SV1(4b) VSM. Verify by comparing that the number of VEMs that were attached to the Release 4.0(4)SV1(3d) VSM match the number of VEMs that are attached to the Release 4.2(1)SV1(4b) 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(3d) 0.0 
3    4.2(1)SV1(4b)     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's role to primary.

switch# system redundancy role primary

switch(config-svs-conn)# show running-config | i boot

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

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

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

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

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

switch(config-svs-conn)# configure terminal 
 
   
switch(config)# boot kickstart bootflash:nexus-1000v-kickstart-mz.4.2.1.SV1.4b.bin 
Note: system and kickstart bootvars are pointing to incompatible images
switch(config)# no boot system bootflash:nexus-1000v-mz.4.0.4.SV1.3c.bin sup-2 
switch(config)# boot system bootflash:nexus-1000v-mz.4.2.1.SV1.4b.bin sup-2 
 
   
 
   
switch(config)# show running-config | i boot 
boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4b.bin sup-1
boot system bootflash:/nexus-1000v-mz.4.2.1.SV1.4b.bin sup-1
boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4b.bin sup-2
boot system bootflash:/nexus-1000v-mz.4.2.1.SV1.4b.bin sup-2
 
   

Step 21 Copy running configuration to startup configuration.

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

Step 22 Reload VSM1.

switch# show version | grep version

version 4.0(4)SV1(3d)

switch# show run int mgmt0

!Command: show running-config interface mgmt0

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

version 4.2(1)SV1(4b)

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 23 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 24 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 25 Save the configuration.

switch# copy running-config startup-config

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

Step 26 Run the VSM Backup procedure.

See the "Configuring VSM Backup and Recovery" chapter of the Cisco Nexus 1000V System Management Configuration Guide, Release 4.2(1)SV1(4b).


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 the "Upgrading the VEMs" section.

Prerequisites to Accepting the VEM Upgrade

The following are prerequisites to accepting a VEM upgrade:

Log in to the CLI in EXEC mode.

Note that the network and server administrators must coordinate the upgrade procedure with each other.

Upgrade the VSM 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 36).

Figure 36 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 might occur during the Cisco Nexus 1000V upgrade process. This section includes the following topic:

Nondefault (Jumbo) MTU Settings Symptoms and Solutions

Nondefault (Jumbo) MTU Settings Symptoms and Solutions

Symptom
Possible Causes
Solution

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

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

Verify the MTU settings on ESX by entering 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 to ensure that the MTU is preserved for uplink interfaces with system VLANs.

For nonsystem uplinks, the VSM sets the correct MTU that is 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 1000 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(4a)

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

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

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

Install and Upgrade

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

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

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

Cisco Nexus 1010 Virtual Services Appliance Hardware Installation Guide

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

Configuration Guides

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

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

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

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

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(4a)

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(4b)

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

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

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(4)

Troubleshooting and Alerts

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

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

Virtual Network Management Center

Cisco Virtual Network Management Center

Network Analysis Module Documentation

Cisco Prime Network Analysis Module Software Documentation Guide, 5.1

Cisco Prime Network Analysis Module (NAM) for Nexus 1010 Installation and Configuration Guide, 5.1

Cisco Prime Network Analysis Module Command Reference Guide 5.1

Cisco Prime Network Analysis Module Software 5.1 Release Notes

Cisco Prime Network Analysis Module Software 5.1 User Guide

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.