Table Of Contents
Cisco Nexus 1000V Software Upgrade Guide, Release 4.2(1)SV1(4b)
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
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)
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
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 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 from Release 4.0(4)SV1(1, 2) to Release 4.0(4)SV1(3d)
Prerequisites to Upgrading the VSMs
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)
Prerequisites to Using the Cisco Nexus 1000V Upgrade Application
Prerequisites to Upgrading the VSMs
Accepting the VEM Upgrade in the vCenter Client
Prerequisites to Accepting the VEM Upgrade
Nondefault (Jumbo) MTU Settings Symptoms and Solutions
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:
•Obtaining the Software for the Upgrade
•Running the Pre-Upgrade Utility
•Information About the Software Upgrade
•Upgrading to Release 4.2(1)SV1(4b)
•Accepting the VEM Upgrade in the vCenter Client
•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
Procedure Document VideoNew Installation
Cisco Nexus 1000V Software Installation Guide, Release 4.2(1)SV1(4b)
Installing a Redundant Pair of VSMs from an OVA File Using the Installer Application video
Upgrading from Release 4.0(1)SV1(3) through Release 4.0(1)SV1(3d) 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 Release 4.0(4)SV1(3, 3a, or 3b) to Release 4.2(1)SV1(4) video
Upgrading 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)
Cisco Nexus 1000 Upgrade from Release 4.2(1)SV1(4) to Release 4.2(1)SV1(4a) Video
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 DescriptionCisco
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 Level4.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.
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 to4.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:
•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
•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-local1957335040 bytes used1240604672 bytes free3197939712 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-standby1956005040 bytes used1240603332 bytes free2096608372 bytes totalStep 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-backupStep 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% -- SUCCESSVerifying image bootflash:/nexus-1000v-mz.4.2.1.SV1.4b.bin for boot variable "system".[####################] 100% -- SUCCESSVerifying image type.[####################] 100% -- SUCCESSExtracting "system" version from image bootflash:/nexus-1000v-mz.4.2.1.SV1.4b.bin.[####################] 100% -- SUCCESSExtracting "kickstart" version from image bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4b.bin.[####################] 100% -- SUCCESSNotifying services about system upgrade.[####################] 100% -- SUCCESSCompatibility check is done:Module bootable Impact Install-type Reason------ -------- -------------- ------------ ------1 yes non-disruptive reset2 yes non-disruptive resetImages 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) yes1 kickstart 4.2(1)SV1(4) 4.2(1)SV1(4b) yes2 system 4.2(1)SV1(4) 4.2(1)SV1(4b) yes2 kickstart 4.2(1)SV1(4) 4.2(1)SV1(4b) yesModule Running-Version ESX Version VSM Compatibility ESX Compatibility------ ---------------------- ---------------------------------------------------- ---------------------- ----------------------3 4.2(1)SV1(4) VMware ESXi 4.0.0 Releasebuild-208167 (1.9) COMPATIBLE COMPATIBLEDo 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% -- SUCCESSSyncing image bootflash:/nexus-1000v-mzg.4.2.1.SV1.4b.bin to standby.[####################] 100% -- SUCCESSSetting boot variables.[####################] 100% -- SUCCESSPerforming 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 waitModule 2: Waiting for module online-- SUCCESSInstall has been successfulStep 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) SoftwareTAC support: http://www.cisco.com/tacCopyright (c) 2002-2011, Cisco Systems, Inc. All rights reserved.The copyrights to certain works contained herein are owned byother third parties and are used and distributed under license.Some parts of this software are covered under the GNU PublicLicense. A copy of the license is available athttp://www.gnu.org/licenses/gpl.html.Softwareloader: 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.binkickstart 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.binsystem compile time: 3/27/2011 14:00:00 [03/28/2011 00:56:08]Hardwarecisco Nexus 1000V Chassis ("Virtual Supervisor Module")Intel(R) Xeon(R) CPU with 2075740 kB of memory.Processor Board ID T5056B050BBDevice name: BL1-VSMbootflash: 3122988 kBKernel uptime is 0 day(s), 0 hour(s), 6 minute(s), 23 second(s)pluginCore 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-local1957335040 bytes used1240604672 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: standaloneoperational: standaloneRedundancy mode---------------administrative: HAoperational: NoneThis supervisor (sup-1)-----------------------Redundancy state: ActiveSupervisor state: ActiveInternal state: Active with no standbyOther supervisor (sup-2)------------------------Redundancy state: Not presentStep 11 Save the running configuration to the start configuration.
switch# copy running-config startup-configStep 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% -- SUCCESSVerifying image bootflash:/nexus-1000v-mzg.4.2.1.SV1.4b.bin for boot variable "system".[####################] 100% -- SUCCESSVerifying image type.[####################] 100% -- SUCCESSExtracting "system" version from image bootflash:/nexus-1000v-mzg.4.2.1.SV1.4b.bin.[####################] 100% -- SUCCESSExtracting "kickstart" version from image bootflash:/nexus-1000v-kickstart-mzg.4.2.1.SV1.4b.bin.[####################] 100% -- SUCCESSNotifying services about system upgrade.[####################] 100% -- SUCCESSCompatibility check is done:Module bootable Impact Install-type Reason------ -------- -------------- ------------ ------1 yes disruptive reset Reset due to single supervisorImages 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) yes1 kickstart 4.2(1)SV1(4) 4.2(1)SV1(4b) yesModule Running-Version ESX Version VSM Compatibility ESX Compatibility------ ---------------------- ---------------------------------------------------- ---------------------- ----------------------3 4.2(1)SV1(4) VMware ESXi 4.0.0 Releasebuild-208167 (1.9) COMPATIBLE COMPATIBLESwitch 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% -- SUCCESSPerforming configuration copy.[####################] 100% -- SUCCESSFinishing 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) SoftwareTAC support: http://www.cisco.com/tacCopyright (c) 2002-2011, Cisco Systems, Inc. All rights reserved.The copyrights to certain works contained herein are owned byother third parties and are used and distributed under license.Some parts of this software are covered under the GNU PublicLicense. A copy of the license is available athttp://www.gnu.org/licenses/gpl.html.Softwareloader: 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.binkickstart 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.binsystem compile time: 3/27/2011 14:00:00 [03/28/2011 00:56:08]Hardwarecisco Nexus 1000V Chassis ("Virtual Supervisor Module")Intel(R) Xeon(R) CPU with 2075740 kB of memory.Processor Board ID T5056B050BBDevice name: BL1-VSMbootflash: 3122988 kBKernel uptime is 0 day(s), 0 hour(s), 6 minute(s), 23 second(s)pluginCore 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 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 ImageUpgrade 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 ImageUpgrade Status: Upgrade Availability Notified in vCenter
Upgrade Notification Sent Time: Sun May 9 22:04:54 2010Upgrade 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 ImageUpgrade Status: Upgrade Accepted by vCenter Admin
Upgrade Notification Sent Time: Sun May 9 22:04:54 2010Upgrade Status Time(vCenter): Tue May 11 07:42:32 2010Upgrade 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 ImageUpgrade Status: Upgrade In Progress in vCenterUpgrade Notification Sent Time: Wed Mar 17 15:19:05 2010Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010Upgrade Start Time: Wed Mar 17 15:20:06 2010Upgrade 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 ImageUpgrade Status: Upgrade Complete in vCenter
Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010Upgrade Start Time: Wed Mar 17 15:20:06 2010Upgrade End Time(vCenter): Wed Mar 17 17:30:48 2010Upgrade 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 ImageUpgrade Status:Upgrade Notification Sent Time:Upgrade Status Time(vCenter):Upgrade Start Time:Upgrade End Time(vCenter):Upgrade Error:Upgrade Bundle ID:VSM: VEM400-201107031-RGDVS: VEM400-201107031-RGStep 8 Verify that the upgrade process is complete.
switch# show module
Mod Ports Module-Type Model Status--- ----- -------------------------------- ------------------ ------------1 0 Virtual Supervisor Module Nexus1000V ha-standby2 0 Virtual Supervisor Module Nexus1000V active *3 248 Virtual Ethernet Module NA ok4 248 Virtual Ethernet Module NA okMod Sw Hw--- --------------- ------1 4.2(1)SV1(4b) 0.02 4.2(1)SV1(4b) 0.03 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 NA2 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA3 02-00-0c-00-03-00 to 02-00-0c-00-03-80 NA4 02-00-0c-00-04-00 to 02-00-0c-00-04-80 NAMod Server-IP Server-UUID Server-Name--- --------------- ------------------------------------ --------------------1 10.78.109.100 NA NA2 10.78.109.100 NA NA3 10.78.109.104 1ee15784-f2e8-383e-8132-9026577ca1bb 10.78.109.1044 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 vCenterUpgrade Notification Sent Time: Sun May 9 22:04:54 2010Upgrade Status Time(vCenter):Upgrade Start Time:Upgrade End Time(vCenter):Upgrade Error:Upgrade Bundle ID:VSM: VEM400-201107031-RG
DVS: VEM400-201101030-RGStep 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 ImageUpgrade Status: Upgrade Accepted by vCenter AdminUpgrade Notification Sent Time: Sun May 9 22:04:54 2010Upgrade Status Time(vCenter): Tue May 11 07:42:32 2010Upgrade Start Time:Upgrade End Time(vCenter):Upgrade Error:Upgrade Bundle ID:VSM: VEM400-201107031-RG
DVS: VEM400-201101030-BGStep 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 ImageUpgrade Status: Upgrade in Progress in vCenterUpgrade Notification Sent Time: Wed Mar 17 15:19:05 2010Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010Upgrade Start Time: Wed Mar 17 15:20:06 2010Upgrade 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 ImageUpgrade Status: Upgrade Complete in vCenter
Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010Upgrade Start Time: Wed Mar 17 15:20:06 2010Upgrade End Time(vCenter): Wed Mar 17 17:28:48 2010Upgrade 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 ImageUpgrade 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-standby2 0 Virtual Supervisor Module Nexus1000V active *3 248 Virtual Ethernet Module NA ok4 248 Virtual Ethernet Module NA okMod Sw Hw--- --------------- ------1 4.2(1)SV1(4b) 0.02 4.2(1)SV1(4b) 0.03 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 NA2 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA3 02-00-0c-00-03-00 to 02-00-0c-00-03-80 NA4 02-00-0c-00-04-00 to 02-00-0c-00-04-80 NAMod Server-IP Server-UUID Server-Name--- --------------- ------------------------------------ --------------------1 10.78.109.100 NA NA2 10.78.109.100 NA NA3 10.78.109.104 1ee15784-f2e8-383e-8132-9026577ca1bb 10.78.109.1044 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-1kickstart variable = bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4.binsystem variable = bootflash:/nexus-1000v-mz.4.2.1.SV1.4.binsup-2kickstart variable = bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4.binsystem variable = bootflash:/nexus-1000v-mz.4.2.1.SV1.4.binNo module boot variable setBoot Variables on next reload:sup-1kickstart variable = bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4b.binsystem variable = bootflash:/nexus-1000v-mz.4.2.1.SV1.4b.binsup-2kickstart variable = bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4b.binsystem variable = bootflash:/nexus-1000v-mz.4.2.1.SV1.4b.binNo 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 imagesThis 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)
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 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 tswitch(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 sup22009 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 succeedswitch(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 sup22009 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 succeedswitch(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-1boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3d.bin sup-1boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3d.bin sup-2boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3d.bin sup-2switch# show running-config | include boot
boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3d.bin sup-1boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3d.bin sup-1boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3d.bin sup-2boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3d.bin sup-2Step 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-standby3 248 Virtual Ethernet Module NA ok4 248 Virtual Ethernet Module NA okMod Sw Hw--- --------------- ------1 4.0(4)SV1(1) 0.02 4.0(4)SV1(1) 0.03 4.0(4)SV1(1) 1.114 4.0(4)SV1(1) 1.11Mod MAC-Address(es) Serial-Num--- -------------------------------------- ----------1 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA2 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA3 02-00-0c-00-03-00 to 02-00-0c-00-03-80 NA4 02-00-0c-00-04-00 to 02-00-0c-00-04-80 NAMod Server-IP Server-UUID Server-Name--- --------------- ------------------------------------ --------------------1 10.78.109.100 NA NA2 10.78.109.100 NA NA3 10.78.109.104 1ee15784-f2e8-383e-8132-9026577ca1bb 10.78.109.1044 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-standby3 248 Virtual Ethernet Module NA ok4 248 Virtual Ethernet Module NA okMod 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.114 4.0(4)SV1(1) 1.11Mod MAC-Address(es) Serial-Num--- -------------------------------------- ----------1 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA2 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA3 02-00-0c-00-03-00 to 02-00-0c-00-03-80 NA4 02-00-0c-00-04-00 to 02-00-0c-00-04-80 NAMod Server-IP Server-UUID Server-Name--- --------------- ------------------------------------ --------------------1 10.78.109.100 NA NA2 10.78.109.100 NA NA3 10.78.109.104 1ee15784-f2e8-383e-8132-9026577ca1bb 10.78.109.1044 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 ImageUpgrade 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-BGStep 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 ImageUpgrade 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 ImageUpgrade Status: Upgrade Availability Notified in vCenter
Upgrade Notification Sent Time: Sun May 9 22:04:54 2010Upgrade 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 ImageUpgrade Status: Upgrade Accepted by vCenter Admin
Upgrade Notification Sent Time: Sun May 9 22:04:54 2010Upgrade Status Time(vCenter): Tue May 11 07:42:32 2010Upgrade 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 ImageUpgrade Status: Upgrade In Progress in vCenterUpgrade Notification Sent Time: Wed Mar 17 15:19:05 2010Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010Upgrade Start Time: Wed Mar 17 15:20:06 2010Upgrade End Time(vCenter):Upgrade Error:Upgrade Bundle ID:VSM: VEM400-201203031-RGDVS: VEM400-201203031-RGIf 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 ImageUpgrade Status: Upgrade Complete in vCenter
Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010Upgrade Start Time: Wed Mar 17 15:20:06 2010Upgrade End Time(vCenter):Upgrade Error:Upgrade Bundle ID:VSM: VEM400-201203031-RGDVS: 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 ImageUpgrade Status:Upgrade Notification Sent Time:Upgrade Status Time(vCenter):Upgrade Start Time:Upgrade End Time(vCenter):Upgrade Error:Upgrade Bundle ID:VSM: VEM400-201107031-RGDVS: VSM400-201107031-RGStep 11 Verify that the upgrade process is complete.
switch# show module
Mod Ports Module-Type Model Status--- ----- -------------------------------- ------------------ ------------1 0 Virtual Supervisor Module Nexus1000V ha-standby2 0 Virtual Supervisor Module Nexus1000V active *3 248 Virtual Ethernet Module NA ok4 248 Virtual Ethernet Module NA okMod Sw Hw--- --------------- ------1 4.2(1)SV1(3d) 0.02 4.2(1)SV1(3d) 0.03 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 NA2 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA3 02-00-0c-00-03-00 to 02-00-0c-00-03-80 NA4 02-00-0c-00-04-00 to 02-00-0c-00-04-80 NAMod Server-IP Server-UUID Server-Name--- --------------- ------------------------------------ --------------------1 10.78.109.100 NA NA2 10.78.109.100 NA NA3 10.78.109.104 1ee15784-f2e8-383e-8132-9026577ca1bb 10.78.109.1044 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 vCenterUpgrade Notification Sent Time: Sun May 9 22:04:54 2010Upgrade Status Time(vCenter):Upgrade Start Time:Upgrade End Time(vCenter):Upgrade Error:Upgrade Bundle ID:VSM: VEM400-201107031-RG
DVS: VEM400-201105124101-BGStep 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 ImageUpgrade Status: Upgrade Accepted by vCenter AdminUpgrade Notification Sent Time: Sun May 9 22:04:54 2010Upgrade Status Time(vCenter): Tue May 11 07:42:32 2010Upgrade Start Time:Upgrade End Time(vCenter):Upgrade Error:Upgrade Bundle ID:VSM: VEM400-201107031-RG
DVS: VEM400-201105124101-BGStep 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 ImageUpgrade Status: Upgrade Errored in vCenter. Please check UpgradeError for more details.Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010Upgrade Start Time: Wed Mar 17 15:20:06 2010Upgrade 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 ImageUpgrade Status: Upgrade Complete in vCenter
Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010Upgrade Start Time: Wed Mar 17 15:20:06 2010Upgrade End Time(vCenter): Wed Mar 17 17:28:48 2010Upgrade 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 ImageUpgrade 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-standby2 0 Virtual Supervisor Module Nexus1000V active *3 248 Virtual Ethernet Module NA ok4 248 Virtual Ethernet Module NA okMod Sw Hw--- --------------- ------1 4.2(1)SV1(3d) 0.02 4.2(1)SV1(3d) 0.03 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 NA2 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA3 02-00-0c-00-03-00 to 02-00-0c-00-03-80 NA4 02-00-0c-00-04-00 to 02-00-0c-00-04-80 NAMod Server-IP Server-UUID Server-Name--- --------------- ------------------------------------ --------------------1 10.78.109.100 NA NA2 10.78.109.100 NA NA3 10.78.109.104 1ee15784-f2e8-383e-8132-9026577ca1bb 10.78.109.1044 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 ImageUpgrade Status: Upgrade Availability Notified in vCenter
Upgrade Notification Sent Time: Sun May 9 22:04:54 2010Upgrade Status Time(vCenter):Upgrade Start Time:Upgrade End Time(vCenter):Upgrade Error:Upgrade Bundle ID:VSM: VEM400-201107031-RGDVS: 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 ImageUpgrade Status: Upgrade Accepted by vCenter AdminUpgrade Notification Sent Time: Sun May 9 22:04:54 2010Upgrade Status Time(vCenter): Tue May 11 07:42:32 2010Upgrade Start Time:Upgrade End Time(vCenter):Upgrade Error:Upgrade Bundle ID:VSM: VEM400-201107031-RGDVS: VEM400-200912267-BGStep 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 ImageUpgrade Status: Upgrade Complete in vCenterUpgrade Notification Sent Time: Wed Mar 17 15:19:05 2010Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010Upgrade Start Time: Wed Mar 17 15:20:06 2010Upgrade End Time(vCenter):Upgrade Error:Upgrade Bundle ID:VSM: VEM400-201107031-RGDVS: VEM400-201107031-RGStep 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 ImageUpgrade Status: Upgrade Complete in vCenter
Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010Upgrade Start Time: Wed Mar 17 15:20:06 2010Upgrade End Time(vCenter): Wed Mar 17 17:30:48 2010Upgrade Error:Upgrade Bundle ID:VSM: VEM400-201107031-RGDVS: VEM400-201107031-RGStep 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 ImageUpgrade Status:Upgrade Notification Sent Time:Upgrade Status Time(vCenter):Upgrade Start Time:Upgrade End Time(vCenter):Upgrade Error:Upgrade Bundle ID:VSM: VEM400-201107031-RGDVS: VEM400-201107031-RGStep 9 Verify that the upgrade process is complete.
switch# show module
Mod Ports Module-Type Model Status--- ----- -------------------------------- ------------------ ------------1 0 Virtual Supervisor Module Nexus1000V ha-standby2 0 Virtual Supervisor Module Nexus1000V active *3 248 Virtual Ethernet Module NA ok4 248 Virtual Ethernet Module NA okMod Sw Hw--- --------------- ------1 4.2(1)SV1(3d) 0.02 4.2(1)SV1(3d) 0.03 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 NA2 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA3 02-00-0c-00-03-00 to 02-00-0c-00-03-80 NA4 02-00-0c-00-04-00 to 02-00-0c-00-04-80 NAMod Server-IP Server-UUID Server-Name--- --------------- ------------------------------------ --------------------1 10.78.109.100 NA NA2 10.78.109.100 NA NA3 10.78.109.104 1ee15784-f2e8-383e-8132-9026577ca1bb 10.78.109.1044 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 ImageUpgrade 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 ImageUpgrade Status: Upgrade In Progress in vCenterUpgrade Notification Sent Time:Upgrade Status Time(vCenter):Upgrade Start Time: Thu Mar 18 15:37:31 2010Upgrade End Time(vCenter):Upgrade Error:Upgrade Bundle ID:VSM: VEM400-201107031-RG
DVS: VEM400-200912267-BGStep 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 ImageUpgrade Status: Upgrade Complete in vCenterUpgrade Notification Sent Time:Upgrade Status Time(vCenter):Upgrade Start Time: Thu Mar 18 15:37:31 2010Upgrade End Time(vCenter): Thu Mar 18 17:47:07 2010Upgrade 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 ImageUpgrade 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-standby2 0 Virtual Supervisor Module Nexus1000V active *3 248 Virtual Ethernet Module NA ok4 248 Virtual Ethernet Module NA okMod Sw Hw--- --------------- ------1 4.2(1)SV1(3d) 0.02 4.2(1)SV1(3d) 0.03 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 NA2 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA3 02-00-0c-00-03-00 to 02-00-0c-00-03-80 NA4 02-00-0c-00-04-00 to 02-00-0c-00-04-80 NAMod Server-IP Server-UUID Server-Name--- --------------- ------------------------------------ --------------------1 10.78.109.100 NA NA2 10.78.109.100 NA NA3 10.78.109.104 1ee15784-f2e8-383e-8132-9026577ca1bb 10.78.109.1044 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 managementip route 0.0.0.0/0 10.78.108.129ip 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-standby3 248 Virtual Ethernet Module NA ok4 248 Virtual Ethernet Module NA ok5 248 Virtual Ethernet Module NA ok6 248 Virtual Ethernet Module NA ok7 248 Virtual Ethernet Module NA ok8 248 Virtual Ethernet Module NA ok9 248 Virtual Ethernet Module NA ok10 248 Virtual Ethernet Module NA ok11 248 Virtual Ethernet Module NA ok12 248 Virtual Ethernet Module NA ok13 248 Virtual Ethernet Module NA ok14 248 Virtual Ethernet Module NA ok15 248 Virtual Ethernet Module NA ok16 248 Virtual Ethernet Module NA okMod Sw Hw--- ---------------- ------------------------------------------------1 4.2(1)SV1(3d) 0.02 4.2(1)SV1(4b) 0.0switch# 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 PortInterface Ch #--------------------------------------------------------------------------------Eth3/4 1 eth trunk up none 10G 10Eth3/5 1 eth trunk up none 10G 10Eth4/2 1 eth trunk up none 10G 11Eth5/3 1 eth trunk up none 10G 13Eth5/4 1 eth trunk up none 10G 13Eth6/3 1 eth trunk up none 10G 5Eth6/4 1 eth trunk up none 10G 5Eth7/3 1 eth trunk up none 10G 7Eth7/4 1 eth trunk up none 10G 7Eth8/2 1 eth trunk up none 10G 8Eth9/2 1 eth trunk up none 10G 1Eth10/3 1 eth trunk up none 10G 12Eth10/4 1 eth trunk up none 10G 12Eth11/4 1 eth trunk up none 10G 9Eth11/5 1 eth trunk up none 10G 9Eth12/11 1 eth trunk up none 10G 2Eth12/12 1 eth trunk up none 10G 2Eth13/2 1 eth trunk up none 10G 14Eth14/2 1 eth trunk up none 10G 3Eth15/2 1 eth trunk up none 10G 4Eth16/4 1 eth trunk up none 10G 6Eth16/5 1 eth trunk up none 10G 6--------------------------------------------------------------------------------Port-channel VLAN Type Mode Status Reason Speed ProtocolInterface--------------------------------------------------------------------------------Po1 1 eth trunk up none a-10G(D) nonePo2 1 eth trunk up none a-10G(D) nonePo3 1 eth trunk up none a-10G(D) nonePo4 1 eth trunk up none a-10G(D) nonePo5 1 eth trunk up none a-10G(D) nonePo6 1 eth trunk up none a-10G(D) nonePo7 1 eth trunk up none a-10G(D) nonePo8 1 eth trunk up none a-10G(D) nonePo9 1 eth trunk up none a-10G(D) nonePo10 1 eth trunk up none a-10G(D) nonePo11 1 eth trunk up none a-10G(D) nonePo12 1 eth trunk up none a-10G(D) nonePo13 1 eth trunk up none a-10G(D) nonePo14 1 eth trunk up none a-10G(D) none--------------------------------------------------------------------------------Vethernet VLAN Type Mode Status Reason Speed--------------------------------------------------------------------------------Veth1 1117 virt pvlan up none autoVeth2 464 virt access up none autoVeth3 464 virt access up none autoVeth4 464 virt access up none autoVeth5 464 virt access up none autoVeth6 464 virt access up none autoVeth7 464 virt access up none autoVeth8 464 virt access up none autoVeth9 464 virt access up none autoVeth10 464 virt access up none autoVeth11 464 virt access up none autoVeth12 464 virt access up none auto...Veth998 464 virt access up none autoVeth999 1403 virt access up none autoVeth1000 464 virt access up none autoVeth1001 464 virt access up none autoVeth1002 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 1Step 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 statusRedundancy role---------------administrative: primaryoperational: primaryRedundancy mode---------------administrative: HAoperational: HAThis supervisor (sup-1)-----------------------Redundancy state: ActiveSupervisor state: ActiveInternal state: Active with HA standbyOther supervisor (sup-2)-----------------------Redundancy state: StandbySupervisor state: HA standbyInternal state: HA standbyStep 4 Display the current connections to the Cisco Nexus 1000V.
switch# show svs connections
connection vcenter:ip address: 192.0.2.10remote port: 80protocol: vmware-vim httpscertificate: defaultdatacenter name: DCDVS uuid: 0c bf 0b 50 0b 4a b7 76-88 13 be 45 14 e8 9b 4econfig status: Enabledoperational status: Connectedsync status: Completeversion: 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 onwards2. 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 profiles3. Ensure there is network connectivity between VC, VSM pair, and the hosts/modules4. Ensure all the hosts/modules are upgraded with the next version of VEM software packageswitch(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] y2011 June 14 20:11:51 av1-vsm %PLATFORM-2-PFM_MODULE_RESET: Manual restart of Module 2 from Command Line Interfaceswitch# 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-standby3 248 Virtual Ethernet Module NA ok4 248 Virtual Ethernet Module NA ok5 248 Virtual Ethernet Module NA ok6 248 Virtual Ethernet Module NA ok7 248 Virtual Ethernet Module NA ok8 248 Virtual Ethernet Module NA ok9 248 Virtual Ethernet Module NA ok10 248 Virtual Ethernet Module NA ok11 248 Virtual Ethernet Module NA ok12 248 Virtual Ethernet Module NA ok13 248 Virtual Ethernet Module NA ok14 248 Virtual Ethernet Module NA ok15 248 Virtual Ethernet Module NA ok16 248 Virtual Ethernet Module NA okStep 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-vimremote 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 DCconnectswitch# 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 managementip route 0.0.0.0/0 10.78.108.129ip 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 okMod Sw Hw--- --------------- ------1 4.2(1)SV1(3d) 0.03 4.2(1)SV1(4b) VMware ESXi 4.0.0 Releasebuild-208167 (1.9)1.9Mod MAC-Address(es) Serial-Num--- -------------------------------------- ----------1 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA3 02-00-0c-00-03-00 to 02-00-0c-00-03-80 NAMod Server-IP Server-UUID Server-Name--- ------------- ------------------------------------ --------------------1 172.23.233.64 NA NA3 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 imagesswitch(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-1boot system bootflash:/nexus-1000v-mz.4.2.1.SV1.4b.bin sup-1boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4b.bin sup-2boot system bootflash:/nexus-1000v-mz.4.2.1.SV1.4b.bin sup-2Step 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: primaryoperational: primaryRedundancy mode---------------administrative: HAoperational: NoneThis supervisor (sup-1)-----------------------Redundancy state: ActiveSupervisor state: ActiveInternal state: Active with HA standbyOther supervisor (sup-2)-----------------------Redundancy state: StandbySupervisor state: HA standbyInternal state: HA standbyStep 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
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.
This document is to be used in conjunction with the documents listed in the Available Documents section.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2009-2012 Cisco Systems, Inc. All rights reserved.