Table Of Contents
Cisco Nexus 1000V Software Upgrade Guide, Release 4.2(1) SV1(4)
Running the Pre-Upgrade Utility
Prerequisites for Running the Pre-Upgrade Utility
Running the Pre-Upgrade Utility on a Microsoft Windows Platform
Running the Pre-Upgrade Utility Using the Cygwin Application
Installing the Cygwin Application
Running the Pre-Upgrade Utility in the Cygwin Application
Running the Pre-Upgrade Utility on a UNIX Platform
Information About the Software Upgrade
Upgrading to Release 4.2(1)SV1(4)
Upgrading from Release 4.0(4)SV1(3, 3a, or 3b) to Release 4.2(1)SV1(4)
Upgrading from Release 4.0(4)SV1(2) to Release 4.2(1)SV1(4)
Upgrading from Release 4.0(4)SV1(1) to Release 4.2(1)SV1(4)
Upgrading the VSMs: Release 4.0(4)SV1(2) to Release 4.0(4)SV1(3b)
Prerequisites to Upgrading the VSMs
Upgrading the VSMs: Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3b)
Prerequisites to Upgrading the VSMs
Upgrading the VEMs: Release 4.0(4)SV1(2, 3, 3a, 3b) to Release 4.2(1)SV1(4)
Prerequisites to Upgrading VEMs
Upgrading the VEMs Manually: Release 4.0(4)SV1(2, 3, 3a, or 3b) to Release 4.2(1)SV1(4)
Upgrading the VEMs: Release 4.0(4)SV1(1) to Release 4.2(1)SV1(4)
Prerequisites to Upgrading VEMs
Upgrading the VEMs Using VMware Update Manager (VUM): Release 4.0(4)SV1(1) to Release 4.2(1)SV1(4)
Upgrading the VEMs Manually: Release 4.0(4)SV1(1) to Release 4.2(1)SV1(4)
Upgrading the VSMs to Release 4.2(1)SV1(4) Using the Upgrade Application
Prerequisites to Using the Cisco Nexus 1000V Upgrade Application
Prerequisites to Upgrading the VSMs
Prerequisites to Upgrading the VSMs
Prerequisites to Upgrading the VSMs
Accepting the VEM Upgrade in the vCenter Client
Prerequisites to Accepting the VEM Upgrade
Non-default (Jumbo) MTU Settings Symptoms and Solutions
Obtaining Documentation and Submitting a Service Request
Cisco Nexus 1000V Software Upgrade Guide, Release 4.2(1) SV1(4)
Revised: May 9, 2013
OL-22826-01
Caution The upgrade procedure for Release 4.2(1)SV1(4) has changed. You must run the Pre-Upgrade Utility prior to beginning the upgrade. It is highly recommended that you read this document thoroughly before beginning the upgrade. For an overview of the new upgrade procedure, see the Understanding the Upgrade Process for the Cisco Nexus 1000V Release 4.2(1)SV1(4) video.
This document describes how to upgrade the Cisco Nexus 1000V software on a Virtual Supervisor Module (VSM) virtual machine (VM) and upgrading the Virtual Ethernet Module (VEM) which includes the following topics:
•Running the Pre-Upgrade Utility
•Information About the Software Upgrade
•Upgrading to Release 4.2(1)SV1(4)
•Accepting the VEM Upgrade in the vCenter Client
•Obtaining Documentation and Submitting a Service Request, page 85
Audience
This guide is for network administrators and server administrators with the following experience and knowledge:
•An understanding of virtualization
•Using VMware tools to create a virtual machine and configure a vSwitch
•A basic understanding of the following:
–Cisco NX-OS based CLI
–VMware ESX/ESXi
–VMware Update Manager
–Cisco Nexus 1000V Distributed Virtual Switch (DVS) setup and implementation
For more information about Cisco Nexus 1000V setup and implementation, see the Cisco Nexus 1000V Getting Started Guide, Release 4.2(1)SV1(4).
Obtaining the Software
You can obtain your upgrade-related software from the following sources (Table 1):
Table 1 Obtaining Software
Source DescriptionCisco
Download the Cisco Nexus 1000V Release 4.2(1)SV1(4) software from the Cisco website.
VMware
Download VMware software from VMware website.
For information about your software and platform compatibility, see the Cisco Nexus 1000V Compatibility Information, Release 4.2(1)SV1(4).
Running the Pre-Upgrade Utility
Note The Pre-Upgrade Utility is compatible with Tcl8.4 and Tcl8.5.
Note Access to third-party websites identified in this document is provided solely as a courtesy to customers and others. Cisco Systems, Inc. and its affiliates are not in any way responsible or liable for the functioning of any third-party website, or the download, performance, quality, functioning or support of any software program or other item accessed through the website, or any damages, repairs, corrections or costs arising out of any use of the website or any software program or other item accessed through the website. Cisco's End User License Agreement does not apply to the terms and conditions of use of a third-party website or any software program or other item accessed through the website.
In Release 4.2(1)SV1(4), many feature enhancements have been incorporated for smoother operation. The feature checks performed by this script were not present in previous versions of the Cisco Nexus 1000V software. The Pre-Upgrade script checks for discrepancies and writes errors or notifications to the Pre-Upgrade-Check-Logs file in the PreUpgradeUtility folder. Errors must be corrected manually. If not corrected manually, notifications will be handled during the upgrade process.
The pre-upgrade utility checks for the following:
1. If the number of system port profiles exceeds 32
2. Interface override configurations on port channel interfaces
3. License status of modules
4. Global existence of NetFlow monitors used in port profiles
5. Global existence of Quality of Service (QoS) policies used in port profiles
6. The presence of the vlan dot1Q tag native command in global configurations
7. Non-system native VLAN in system port profiles
8. Virtual Supervisor Module (VSM) status
9. Sufficient space on the bootflash: of the active and standby VSMs
10. Authentication usage
11. IP address in SVS connections
12. Subnet routes from control0 interface under the management virtual routing and forwarding (VRF)
13. Channel group configurations under physical interfaces
14. Interfaces that have the shutdown command as an override configuration
15. ERSPAN sessions with no ERSPAN ID
16. QoS and access control list (ACL) statistics
Prerequisites for Running the Pre-Upgrade Utility
The Pre-Upgrade Utility has the following prerequisite:
•You must download the PreUpgradeUtility zip file from the Cisco Nexus 1000V first customer ship (FCS) package and unzip the file.
This utility can be run on the following platforms:
•Microsoft Windows - see Running the Pre-Upgrade Utility on a Microsoft Windows Platform.
•UNIX - see Running the Pre-Upgrade Utility on a UNIX Platform.
Note The Pre-Upgrade-App.exe is not supported.
Running the Pre-Upgrade Utility on a Microsoft Windows Platform
The Pre-Upgrade Utility must be run using the following open-source Cygwin application:
•Cygwin - An open-source freeware tool that needs to be installed from http://www.cygwin.com. Cygwin is supported for commercially released x86 32-bit and 64-bit versions of Windows (except Windows CE). This is the recommended method. See Running the Pre-Upgrade Utility Using the Cygwin Application.
Running the Pre-Upgrade Utility Using the Cygwin Application
Running the Pre-Upgrade Utility using the Cygwin application is a two-step process:
1. Installing the Cygwin Application.
2. Running the Pre-Upgrade Utility in the Cygwin Application.
Installing the Cygwin Application
Step 1 To download the application, go to this URL: http://www.cygwin.com.
Step 2 Click the setup.exe file link and save it to your desktop.
You may choose the latest version.
Note If there are any questions related to the third-party website or any item accessed on the website, contact the Cygwin support team.
Step 3 Double-click the setup.exe file downloaded in Step 2.
The Cygwin Setup window opens. See Figure 1.
Figure 1 Cygwin Setup Screen
Step 4 Click Next.
The Choose a Download Source window opens. See Figure 2.
Figure 2 Choose a Download Source Screen
Step 5 Choose an appropriate download source and click Next.
Note Choosing the default Install from Internet radio button causes the files you choose in a later step to be downloaded first, validated, and installed.
The Select Root Install Directory window opens. See Figure 3.
Figure 3 Select Root Install Directory Screen
Step 6 Select a Root Directory for installation and click Next.
The Select Local Package Directory window opens. See Figure 4.
Note Do not choose a location that contains spaces in its path name.
Figure 4 Select Local Package Directory Screen
Step 7 In the Local Package Directory field, browse to the local package directory and click Next.
The Select Your Internet Connection window opens. See Figure 5.
Figure 5 Select Your Internet Connection Screen
Step 8 Select an appropriate Internet connection and click Next.
The Choose a Download Site window opens. See Figure 6.
Figure 6 Choose A Download Site Screen
Step 9 In the Available Download Sites area, choose a download site and click Next.
The Progress window opens. See Figure 7.
The installer downloads a list of available packages from the site that you selected.
Figure 7 Progress Screen
Figure 8 Setup Alert Screen
Step 10 If you are installing for the first time and the Setup Alert dialog box opens, click OK.
The Select Packages window opens. See Figure 9.
For a basic installation, some packages are selected by default.
Tip Do not press the Enter key until you have selected all four packages.
Figure 9 Select Packages Screen
Step 11 Enter Inetutils in the Search field.
As you enter the package name, the screen updates with the available packages. See Figure 10.
Note If you choose src packages in addition to binaries, your download time might increase.
Figure 10 Select Packages Screen
Step 12 Expand the Category if necessary and check the Bin? check box.
Step 13 Enter openssh in the Search field. See Figure 11.
Figure 11 Select OpenSSH Packages Screen
Step 14 Expand the Category if necessary and check the Bin? check box.
Step 15 Enter tcl in the Search field. See Figure 12.
Figure 12 Select Tcl Packages Screen
Step 16 Expand the Category if necessary and check the Bin? check boxes.
Step 17 Enter Expect in the Search field. See Figure 13.
Figure 13 Select Expect Packages Screen
Step 18 Expand the Category if necessary and check the Bin? check box.
Step 19 Click Next.
In Cygwin 1.7, you might see a screen that displays a warning ("Resolving Dependencies") and a list of additional packages that are required by the packages that you have already selected.
The Resolving Dependencies screen opens. See Figure 14.
Figure 14 Resolving Dependencies Screen
Step 20 At the bottom of the screen, be sure that the Select required packages (RECOMMENDED) check box is checked and click Next.
The downloading process begins after you choose the packages.
Figure 15 Download Progress Screen
Note The downloading and installation process takes several minutes to complete depending on the speed of your Internet connection. Make sure that all three progress bars have completed.
Following package installation, any installation dependent configuration scripts are run to complete the setup process.
Note There might be lengthy pauses during this step without any indication of progress.
The Create Icons window opens. See Figure 16.
Figure 16 Create Icons Screen
Step 21 Check appropriate shortcut check boxes and click Finish.
Running the Pre-Upgrade Utility in the Cygwin Application
Prerequisites:
•You have downloaded the PreUpgradeUtility zip file from the Cisco Nexus 1000V FCS package and unzipped the file.
Step 1 Copy the pre-upgrade-check-4.2(1)SV1(4).tcl file to C:\cygwin or the main directory where the user has installed Cygwin.
Step 2 Double-click the Cygwin shortcut on your desktop to start the Cygwin application.
The Cygwin application window opens. See Figure 17.
Figure 17 Terminal Window
Step 3 Telnet or SSH to the Cisco Nexus 1000V VSM and exit before continuing with Step 4.
Step 4 Navigate to the location where you saved the Pre-Upgrade script and run the following command:
$ expect pre-upgrade-check-4.2\(1\)SV1\(4\).tcl ip-address username password [telnet | ssh]
•ip-address is the IP address of the VSM.
•username and password are the login credentials.
Note The following window displays this command being run with the Telnet option.
Figure 18 Telnet Option Window
Note Two methods of connectivity can be used. Both Telnet or SSH ensure that the service is enabled on the VSM before using Cygwin.
Step 5 Perform one of the following options:
•If no errors are found, continue with the upgrade.
•If error are found, correct them.
Step 6 Rerun the script and correct any additional errors until no errors are displayed.
Step 7 Continue with the upgrade.
Running the Pre-Upgrade Utility on a UNIX Platform
Caution While the Pre-Upgrade script is running, do not execute any system commands.
Step 1 Download the PreUpgradeUtility zip file from the Cisco Nexus 1000V FCS package and unzip.
Step 2 Download and install Tcl 8.4 and Expect.
Note Download Tcl 8.4 at http://www.activestate.com/activetcl/downloads. If there are any questions related to the third-party website or any item accessed on the website, contact the ActiveState Software Inc. support team.
Step 3 Run the following command:
tclsh pre-upgrade-check-4.2(1)SV1(4).tcl ip-address username password [telnet | ssh]•ip-address is the IP address of the VSM.
•username and password are the login credentials.
Example:tclsh pre-upgrade-check-4.2(1)SV1(4).tcl 10.0.0.2 user1 mynewpassword telnet
The checks being performed and the results are displayed . If there are any errors, possible corrective actions are listed. The log file containing the errors and notifications is Pre-Upgrade-App-date-time.txt. in the PreUpgradeUtility/Pre-Upgrade-Check-Logs folder.
Step 4 Perform one of the following steps:
•If no errors are found, continue with the upgrade.
•If errors are found, correct them.
Step 5 Rerun the script and correct the errors until no errors are displayed.
Step 6 Continue with the upgrade.
Information About the Software Upgrade
Caution If the VMware vCenter Server is hosted on the same ESX host as a Cisco Nexus 1000V VEM, then a VUM assisted upgrade on the host will fail. You should manually vMotion the VM to another host before performing the upgrade when running ESX 4.0.0 Update 1. This issue has been resolved in the ESX 4.1.0 release.
Figure 19
Non-Disruptive Upgrade Steps
This section provides information about the software upgrade. This section describes important points about the software upgrade:
•There are two methods of upgrading the software: the non-disruptive method and the disruptive method. An upgrade is non-disruptive or disruptive based on the version of your setup and also the method that you choose for upgrading.
A non-disruptive upgrade takes place when you install one of the following VMware releases listed in Table 2.
Note Even if your have your ESX/ESXi host patch levels greater than the values in the Table 2, without installing ESX/ESXi400-201002001 or upgrade-from-esxi4.0-4.0_update02 a non-disruptive upgrade is not supported. Any patch level for 4.1.0 ensures a non-disruptive upgrade.
Table 2 Non-Disruptive Patch Level
ESX/ESXi Non-Disruptive Patch Level4.0.0
ESX/ESXi400-201002001
upgrade-from-esxi4.0-4.0_update02
4.1.0
Any patch level
Note For details about how to determine what patch level you are using, refer to the Cisco Nexus 1000V Compatibility Information, Release 4.2(1)SV1(4).
•The minimum ESX/ESXi patch level that is supported for upgrade is ESX/ESXi 4.0.0 Update 1.
•Cisco does not support simultaneous VMware updates or patches in combination with Nexus 1000V upgrades. This document is designed specifically for Nexus 1000V upgrades across the same VMware platform.
•The upgrade process is irrevocable. After the software is upgraded, you can downgrade by removing the current installation and reinstalling the software. For details, see the "Recreating the Installation" section in the following document:
–Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4)
Caution During the upgrade process, the Cisco Nexus 1000V does not support any new additions such as, modules, vnics or vmnics and does not support any configuration changes. vmnic and vnic port-profile changes might render vmnics and vnics in an unusable state.
•During the upgrade from Release 4.0(4)SV1(2, 3, 3a, or 3b) to Release 4.2(1)SV1(4), the interface configuration will be stored in the bootflash:system_eth.cfg.orig file. Modules which are present during the upgrade will automatically obtain the interface overrides from this configuration file. If any module comes on line after the upgrade, the user can use the interface configuration file to replay the needed configuration.
Information About Licensing
The following table summarizes licensing information following the upgrade.
This release supports installation of additional evaluation license files.
For more licensing details, see the Cisco Nexus 1000V License Configuration Guide, Release 4.2(1)SV1(4).
For information about limitations and caveats, see the Cisco Nexus 1000V Release Notes, Release 4.2(1)SV1(4).
Upgrading to Release 4.2(1)SV1(4)
The upgrade procedures for the previous releases are covered in the following sections.
Note Is is highly recommended that you view the screencast on upgrading to Release 4.2(1)SV1(4) at http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_2_1_s_v_1_4/upgrade/screencast/guide/n1000v_upgrade_screencasts.html.
Upgrading from Release 4.0(4)SV1(3, 3a, or 3b) to Release 4.2(1)SV1(4)
Note To upgrade from Release 4.0(4)SV1(3c) to Release 4.2(1)SV1(4), use this procedure.
Note For ESX/ESXi 4.1.0 releases and later, the minimum VC/VUM version required is 258902/256596
For ESX/ESXi 4.0.0 releases and later, the minimum VC/VUM version required is 208111/282702.
Caution If you are upgrading on a Cisco Nexus 1010, make sure that the secondary VSM is active and the primary VSM is standby prior to initiating the upgrade. If the primary VSM is active, run the system switchover command to make the secondary VSM active.
To perform a software upgrade from Release 4.0(4)SV1(3, 3a, or 3b) to Release 4.2(1)SV1(4), follow these steps:
Step 1 Upgrading the VEMs: Release 4.0(4)SV1(2, 3, 3a, 3b) to Release 4.2(1)SV1(4)
Step 2 Upgrading the VSMs to Release 4.2(1)SV1(4) Using the Upgrade Application
Figure 20
Upgrading from Release 4.0(4)SV1(3, 3a, or 3b) to Release 4.2(1)SV1(4)
Upgrading from Release 4.0(4)SV1(2) to Release 4.2(1)SV1(4)
Note For ESX/ESXi 4.1.0 releases and later, the minimum VC/VUM version required is 258902/256596
For ESX/ESXi 4.0.0 releases and later, the minimum VC/VUM version required is 208111/282702.
To perform the software upgrade from Release 4.0(4)SV1(2) to Release 4.2(1)SV1(4), follow these steps:
Step 1 Upgrading the VSMs: Release 4.0(4)SV1(2) to Release 4.0(4)SV1(3b)
Step 2 Upgrading the VEMs: Release 4.0(4)SV1(2, 3, 3a, 3b) to Release 4.2(1)SV1(4)
Step 3 Upgrading the VSMs to Release 4.2(1)SV1(4) Using the Upgrade Application
Figure 21
Upgrading from Release 4.0(4)SV1(2) to Release 4.2(1)SV1(4)
Upgrading from Release 4.0(4)SV1(1) to Release 4.2(1)SV1(4)
Note For ESX/ESXi 4.1.0 releases and later, the minimum VC/VUM version required is 258902/256596
For ESX/ESXi 4.0.0 releases and later, the minimum VC/VUM version required is 208111/282702.
To perform a software upgrade from Release 4.0(4)SV1(1) to Release 4.2(1)SV1(4), follow these steps:
Step 1 Upgrading the VSMs: Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3b)
Step 2 Upgrading the VEMs: Release 4.0(4)SV1(1) to Release 4.2(1)SV1(4)
Step 3 Upgrading the VSMs to Release 4.2(1)SV1(4) Using the Upgrade Application
Figure 22
Upgrading from Release 4.0(4)SV1(1) to Release 4.2(1)SV1(4)
Upgrading the VSMs
This section describes the VSM upgrade procedures that are supported in this release:
•Upgrading the VSMs: Release 4.0(4)SV1(2) to Release 4.0(4)SV1(3b)
•Upgrading the VSMs: Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3b)
•Upgrading the VSMs to Release 4.2(1)SV1(4) Using the Upgrade Application
Upgrading the VSMs: Release 4.0(4)SV1(2) to Release 4.0(4)SV1(3b)
This section describes the VSM upgrade from Release 4.0(4)SV1(2) to Release 4.0(4)SV1(3b).
Prerequisites to Upgrading the VSMs
The following are prerequisites to upgrading the VSMs:
•Executing and correcting errors from the PreUpgradeUtility.
•You are upgrading the Cisco Nexus 1000V software to Release 4.0(4)SV1(3b).
•Network and server administrators coordinate the upgrade procedure with each other.
•The following files have been copied to bootflash:
–nexus-1000v-mz.4.0.4.SV1.3b.bin
–nexus-1000v-kickstart-mz.4.0.4.SV1.3b.bin
•You have saved all changes in the running configuration to the startup configuration to be preserved through the upgrade.
•You have saved a backup copy of the running configuration in external storage.
To perform a VSM software upgrade from Release 4.0(4)SV1(2) to Release 4.0(4)SV1(3b), follow these steps:
Note This procedure is performed by the network administrator.
Note If you are upgrading on a Cisco Nexus 1010, make sure that the Secondary VSM is Active and the Primary VSM is Standby prior to initiating the upgrade.
Step 1 Copy the new software release system image and kickstart image files to the bootflash file system of the active VSM.
switch# copy scp://root@192.0.2.13/N1K-VSM-images/nexus-1000v-mz.4.0.4.SV1.3b.bin bootflash:
Enter vrf (If no input, current vrf 'default' is considered):root@192.0.2.13's password:nexus-1000v-mz.4.0.4.SV1.3b.bin 100% 20MB 1.1MB/s 00:19switch#switch# copy scp://root@192.0.2.13/N1K-VSM-images/nexus-1000v-kickstart-mz.4.0.4.SV1.3b.bin bootflash:Enter vrf (If no input, current vrf 'default' is considered):root@192.0.2.13's password:nexus-1000v-kickstart-mz.4.0.4.SV1.3b.bin 100% 20MB 1.1MB/s 00:19switch#switch# dir bootflash:
154 Jan 27 15:21:06 2010 .ovfconfigured77824 Mar 03 07:31:09 2010 accounting.log16384 Dec 09 13:56:23 2009 lost+found/21408768 Dec 09 13:57:21 2009 nexus-1000v-kickstart-mz.4.0.4.SV1.2.bin21982208 Jan 21 18:28:58 2010 nexus-1000v-kickstart-mz.4.0.4.SV1.3b.bin73068811 Dec 09 13:57:32 2009 nexus-1000v-mz.4.0.4.SV1.2.bin62280256 Jan 21 18:29:35 2010 nexus-1000v-mz.4.0.4.SV1.3b.bin4096 Dec 09 13:58:18 2009 vdc_2/4096 Dec 09 13:58:18 2009 vdc_3/4096 Dec 09 13:58:18 2009 vdc_4/Usage for bootflash://sup-local333910016 bytes used2054361088 bytes free2388271104 bytes totalStep 2 Use the install all command to copy the Release 4.0(4)SV1(3b) images to both active and standby VSMs and to update the boot variables.
Note If available, you can obtain the software images from an outside repository and copy it using the install all command.
switch# install all system bootflash:nexus-1000v-mz.4.0.4.SV1.3b.bin kickstart bootflash:nexus-1000v-kickstart-mz.4.0.4.SV1.3b.bin
System image sync to standby is in progress...System image is synced to standby.Kickstart image sync to Standby is in progress...Kickstart image is synced to standby.Boot variables are updated to running configuration.Step 3 Save your configuration by copying the running configuration to the startup configuration.
switch# copy running-config startup-config
[########################################] 100%Step 4 Verify that your configuration is saved.
switch# show startup-config | include boot
boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3b.bin sup-1boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3b.bin sup-1boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3b.bin sup-2boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3b.bin sup-2switch# show running-config | include boot
boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3b.bin sup-1boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3b.bin sup-1boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3b.bin sup-2boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3b.bin sup-2Step 5 Verify the VSM active and standby module status.
switch# show mod
Mod Ports Module-Type Model Status--- ----- -------------------------------- ------------------ ------------1 0 Virtual Supervisor Module Nexus1000V active *2 0 Virtual Supervisor Module Nexus1000V ha-standby3 248 Virtual Ethernet Module NA ok4 248 Virtual Ethernet Module NA okMod Sw Hw--- --------------- ------1 4.0(4)SV1(2) 0.02 4.0(4)SV1(2) 0.03 4.0(4)SV1(2) 1.114 4.0(4)SV1(2) 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.102Step 6 Reload the standby VSM.
Used module 2 in the following example because module 2 is the standby module. After reloading the standby VSM, the active VSM that is running software release 4.0(4)SV1(2), synchronizes with the standby VSM running Release 4.0(4)SV1(3b).
switch# reload module 2
This command will reboot standby supervisor module. (y/n)? [n] y
about to reset standby supswitch# 2010 Feb 11 09:57:42 n1000v %PLATFORM-2-PFM_MODULE_RESET: Manual restart of Module 2 from Command Line Interface2010 Feb 11 09:57:49 n1000v %PLATFORM-2-MOD_REMOVE: Module 2 removed (Serial number T5056972D88)2010 Feb 11 09:57:53 n1000v %(0x436D) for service "netstack" (PID 3176): Connection timed out (110).
Note A few sequence failures might be displayed with the preceding message. This is expected and you can ignore it.
Step 7 Verify the VSM active and standby module status and software release version.
switch# show mod
Mod Ports Module-Type Model Status--- ----- -------------------------------- ------------------ ------------1 0 Virtual Supervisor Module Nexus1000V active *2 0 Virtual Supervisor Module Nexus1000V ha-standby
3 248 Virtual Ethernet Module NA ok4 248 Virtual Ethernet Module NA okMod Sw Hw--- --------------- ------1 4.0(4)SV1(2) 0.02 4.0(4)SV1(3b) 0.0
3 4.0(4)SV1(2) 1.114 4.0(4)SV1(2) 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, after the reload, display the active and standby modules and that VSM module 2, the standby module, is upgraded to Release 4.0(4)SV1(3b).
Step 8 Enter the system switchover command at the active VSM to force the standby VSM to become active and to reload the active VSM.
switch# system switchover
When the modules are switched over, the primary module reloads and returns as the standby VSM with the new software version.
Step 9 Verify the system switchover.
In the following example, module 2 is the active module and module 1 is now the standby module.
switch# show mod
Mod Ports Module-Type Model Status--- ----- -------------------------------- ------------------ ------------1 0 Virtual Supervisor Module Nexus1000V ha-standby2 0 Virtual Supervisor Module Nexus1000V active *3 248 Virtual Ethernet Module NA ok4 248 Virtual Ethernet Module NA okMod Sw Hw--- --------------- ------1 4.0(4)SV1(3b) 0.0
2 4.0(4)SV1(3b) 0.03 4.0(4)SV1(2) 1.114 4.0(4)SV1(2) 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 line with the bold characters in the preceding example displays that the VSM module 1 is upgraded to Release 4.0(4)SV1(3b).
Use the system switchover command, to set module 1 as the active module and module 2 as the standby module.
Step 10 (Optional) If you have configured non-default (jumbo) MTU settings, see the "Non-default (Jumbo) MTU Settings Symptoms and Solutions" section before proceeding with VEM upgrades.
Step 11 Proceed to upgrade the VEMs to Release 4.2(1)SV1(4).
For details, see the "Upgrading the VEMs: Release 4.0(4)SV1(2, 3, 3a, 3b) to Release 4.2(1)SV1(4)" section.
Upgrading the VSMs: Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3b)
This section describes the VSM upgrade from Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3b).
Prerequisites to Upgrading the VSMs
The following are prerequisites to upgrading the VSMs:
•Executing and correcting errors from the PreUpgradeUtility.
•You are upgrading the Cisco Nexus 1000V software to Release 4.0(4)SV1(3b).
•Network and server administrators coordinate the upgrade procedure with each other.
•The following files are available in external storage that you can access from the VSMs.
–nexus-1000v-mz.4.0.4.SV1.3b.bin
–nexus-1000v-kickstart-mz.4.0.4.SV1.3b.bin
•You have saved all changes in the running configuration to the startup configuration to be preserved through the upgrade.
•You have saved a backup copy of the running configuration in external storage.
For information about backing up a configuration file, see the Cisco Nexus 1000V System Management Configuration Guide, Release 4.2(1)SV1(4).
To perform a VSM software upgrade from Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3b), follow these steps:
Note This procedure is performed by the network administrator.
Step 1 Backup the configuration to an external server.
Step 2 Power off all VMs except the VSM and VC.
Step 3 Remove the existing system boot variable and kickstart boot variable.
switch# config 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.3b.bin
2009 Dec 13 15:50:40.568 n1k-av %BOOTVAR-5-IMAGE_NOTEXISTS: Warning: image nexus-1000v-mz.4.0.4.SV1.3b.bin doesn't exist on 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.3b.bin to standby supervisor succeedswitch(config)# boot kickstart bootflash:nexus-1000v-kickstart-mzg.4.0.4.SV1.3b.bin
2009 Dec 13 15:54:03.093 n1k-av %BOOTVAR-5-IMAGE_NOTEXISTS: Warning: image nexus-1000v-kickstart-mz.4.0.4.SV1.3b.bin doesn't exist on 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.3b.bin to standby supervisor succeedswitch(config)#
Note With dual VSMs, if boot auto-copy is enabled (the default), and terminal monitor is enabled, the image is also copied to the standby VSM. Wait for the second log message to appear before proceeding with the next step.
Caution If you are upgrading dual VSMs, then before you reload the software, make sure that the bootflash file system for the standby VSM has system and kickstart image files that are identical to those in the active VSM. If they are not identical, then the only way to recover the standby VSM is to create a new one from the ISO/OVA/OVF image and point it to the active VSM.
Step 5 Save the running configuration persistently through reboots and restarts by copying it to the startup configuration.
switch(config)# copy running-config startup-config
[########################################] 100%switch(config)#Step 6 Verify that your configuration is saved.
switch# show startup-config | include boot
boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3b.bin sup-1boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3b.bin sup-1boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3b.bin sup-2boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3b.bin sup-2switch# show running-config | include boot
boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3b.bin sup-1boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3b.bin sup-1boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3b.bin sup-2boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3b.bin sup-2Step 7 Verify the VSM active and standby module status.
switch# show mod
Mod Ports Module-Type Model Status--- ----- -------------------------------- ------------------ ------------1 0 Virtual Supervisor Module Nexus1000V active *2 0 Virtual Supervisor Module Nexus1000V ha-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(3b).
Step 8 Reload the VSM.
switch# reload
This command will reboot the system. (y/n)? [n] y
switch#The upgraded VSMs start up with the new software version.
Step 9 Verify that the VSMs are upgraded.
switch# show mod
Mod Ports Module-Type Model Status--- ----- -------------------------------- ------------------ ------------1 0 Virtual Supervisor Module Nexus1000V active *2 0 Virtual Supervisor Module Nexus1000V ha-standby3 248 Virtual Ethernet Module NA ok4 248 Virtual Ethernet Module NA okMod Sw Hw--- --------------- ------1 4.0(4)SV1(3b) 0.0
2 4.0(4)SV1(3b) 0.0
3 4.0(4)SV1(1) 1.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(3b).
Step 10 (Optional) If you have configured non-default (jumbo) MTU settings, see the "Non-default (Jumbo) MTU Settings Symptoms and Solutions" section before proceeding with VEM upgrades.
Step 11 Proceed to upgrade the VEMs to Release 4.2(1)SV1(4).
For details, see the "Upgrading the VEMs: Release 4.0(4)SV1(1) to Release 4.2(1)SV1(4)" section.
Upgrading the VEMs
This section describes the VEM upgrade procedures that are supported in this release:
•Upgrading the VEMs: Release 4.0(4)SV1(2, 3, 3a, 3b) to Release 4.2(1)SV1(4)
•Upgrading the VEMs: Release 4.0(4)SV1(1) to Release 4.2(1)SV1(4)
Before upgrading the VEMs, note the following important points:
•The VEM upgrade starts when it is attached to the VSM. During the upgrade process, VEMs re-attach to the VSM.
•VEM software can be upgraded manually using the CLI, or upgraded automatically using VUM.
•Connectivity to the VSM can be lost during a VEM upgrade when the interfaces of a VSM VM connect to its own DVS.
•Connectivity between an active and standby VSM can be lost during a VEM upgrade when the VEM being upgraded provides interface connectivity to one of the VSMs. In this case, both VSMs become active and lose connectivity. To prevent this, make sure that you are at the appropriate patch levels. See Table 2.
•If you are upgrading VEM using a Cisco Nexus 1000V bundle, follow instructions in your VMware documentation. For more details about VMware bundled software, see the Cisco Nexus 1000V Compatibility Information, Release 4.2(1)SV1(4).
Caution Do not run the vemlog, vemcmd, or vempkt commands during the VEM upgrade process as it might impact the upgrade.
Upgrading the VEMs: Release 4.0(4)SV1(2, 3, 3a, 3b) to Release 4.2(1)SV1(4)
This section describes the steps to upgrade VEMs from Release 4.0(4)SV1(2, 3, 3a, 3b) to Release 4.2(1)SV1(4) and includes the following topics:
•Upgrading the VEMs Manually: Release 4.0(4)SV1(2, 3, 3a, or 3b) to Release 4.2(1)SV1(4)
Prerequisites to Upgrading VEMs
The following are prerequisites to upgrading the VEMs:
•Executing and correcting errors from the PreUpgradeUtility.
•You are logged in to the VSM CLI in EXEC mode.
•Network and server administrators coordinate the VEM upgrade with each other.
Upgrading the VEMs Using VMware Update Manager (VUM): Release 4.0(4)SV1(2, 3, 3a, or 3b) to Release 4.2(1)SV1(4)
To upgrade the VEMs using VUM, follow these steps:
Note This procedure is performed by the network administrator. Before proceeding with the upgrade, make sure the VMs are powered off if you are not running the required patch level.
Note For example purposes, the following procedure reflects an upgrade from Release 4.0(4)SV1(3b) to Release 4.2(1)SV1(4).
Caution If removable media is still connected, for example, if you have installed the VSM using ISO and forgot to remove the media, then host movement to maintenance mode fails and the VUM upgrade fails.
Step 1 Upload the vem-release_final.tar.gz file, system and kickstart images to the VSM's bootflash.
These files will be present in the zip folder of the FCS.
Step 2 Display the current configuration.
switch (config)# show vmware vem upgrade status
Upgrade VIBs: System VEM ImageUpgrade Status:Upgrade Notification Sent Time:Upgrade Status Time(vCenter):Upgrade Start Time:Upgrade End Time(vCenter):Upgrade Error:Upgrade Bundle ID:VSM: VEM400-201007101-BGDVS: VEM400-201007101-BGStep 3 Update the ESX host version.
switch (config)# vmware vem upgrade update-vibs bootflash:vem-release_final.tar.gz
Step 4 Verify that the upgrade notification was sent.
switch (config)# show vmware vem upgrade status
Upgrade VIBs: Upgrade VEM ImageUpgrade Status:Upgrade Notification Sent Time:Upgrade Status Time(vCenter):Upgrade Start Time:Upgrade End Time(vCenter):Upgrade Error:Upgrade Bundle ID:VSM: VEM400-201101030-RG
DVS: VEM400-201007101-BG
Note The VSM Bundle ID now deploys the Release 4.2(1)SV1(4) Bundle ID.
Step 5 Send upgrade notification to VC.
switch (config)# vmware vem upgrade notify
Warning:Please ensure the hosts are running compatible ESX versions for the upgrade. Refer to corresponding "Cisco Nexus 1000V and VMware Compatibility Information" guide.Step 6 Verify that the upgrade notification was sent.
switch# show vmware vem upgrade status
Upgrade VIBs: Upgrade VEM 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-201101030-RG
DVS: VEM400-201007101-BG
Note Verify that the Upgrade Status contains the highlighted text. If the text is not present, check the Upgrade Error line and consult the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4).
Step 7 Verify that the server administrator has accepted the upgrade in the vCenter.
For details about how the server administrator accepts the VEM upgrade, see the "Accepting the VEM Upgrade in the vCenter Client" section.
Coordinate the notification acceptance with the server administrator. After the server administrator accepts the upgrade, proceed with the VEM upgrade.
switch# show vmware vem upgrade status
Upgrade VIBs: Upgrade VEM 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-201101030-RG
DVS: VEM400-201007101-BG
Note Verify that Upgrade Status contains the highlighted text. If the text is not present, check the Upgrade Error line and consult the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4).
Step 8 Initiate the VUM upgrade process.
Caution Before entering the vmware vem upgrade proceed command, disable VMware High Availability (HA), Fault Tolerance (FT), and Distributed Power Management (DPM) in the cluster.
vCenter locks the DVS and triggers VUM to upgrade the VEMs.
switch# vmware vem upgrade proceed
switch# show vmware vem upgrade status
Upgrade VIBs: Upgrade VEM 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-201101030-RG
DVS: VEM400-201101030-RG
Note If the ESX/ESXi host is using VMware patch ESX/ESXi400-201002001, ESX/ESXi400-201006201, or ESX/ESXi410, and if your DRS settings are enabled to allow it, VUM automatically vMotions the VMs from the host to another host in the cluster and places the ESX/ESXi in maintenance mode to upgrade the VEM. This process is continued for other hosts in the DRS cluster until all the hosts are upgraded in the cluster.
Note If VC/VUM version 4.0.0 Update1 or Update2 are hosted on ESX/ESXi, then VUM upgrade will fail for this host. You need to migrate the vCenter to another host that was successfully upgraded and run the vmware vem upgrade proceed command again.
Step 9 Check for the Upgrade Complete status.
Note If the upgrade status is not complete, see the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4).
switch# show vmware vem upgrade status
Upgrade VIBs: System VEM 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-201101030-RG
DVS: VEM400-201101030-RG
Note The DVS bundle ID is updated and is highlighted. Before entering the following command, communicate wit the server administrator to confirm that the VUM process is operational.
Step 10 Clear the VEM upgrade status after the upgrade process is complete.
switch# vmware vem upgrade complete
switch# show vmware vem upgrade status
Upgrade VIBs: Upgrade VEM ImageUpgrade Status:Upgrade Notification Sent Time:Upgrade Status Time(vCenter):Upgrade Start Time:Upgrade End Time(vCenter):Upgrade Error:Upgrade Bundle ID:VSM: VSM130-201010110-BGDVS: VSM130-201010110-BGStep 11 Verify that the upgrade process is complete.
switch# show mod
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(3b) 0.02 4.2(1)SV1(3b) 0.03 4.2(1)SV1(4) VMware ESXi 4.0.0 Releasebuild-261974 (1.20)
4 4.2(1)SV1(4) VMware ESXi 4.1.0 Releasebuild-260247 (2.0)
Mod MAC-Address(es) Serial-Num--- -------------------------------------- ----------1 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 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(4).
Step 12 Proceed to upgrade the VSM.
Caution If any VEM is not upgraded to Release 4.2(1)SV1(4) by VUM, perform a manual upgrade of the VEM before continuing with the VSM upgrade.
For details, see the "Upgrading the VSMs to Release 4.2(1)SV1(4) Using the Upgrade Application" section.
Upgrading the VEMs Manually: Release 4.0(4)SV1(2, 3, 3a, or 3b) to Release 4.2(1)SV1(4)
To manually install or upgrade the Cisco Nexus 1000V VEM on an ESX/ESXi host, follow the steps in the "Installing or Upgrading the VEM Software Using the CLI" section in the Cisco Nexus 1000V Virtual Ethernet Module Software Installation and Upgrade Guide, Release 4.2(1)SV1(4).
To upgrade the VEMs manually, perform the following steps as network administrator:
Note This procedure is performed by the network administrator. Before proceeding with the upgrade, make sure the VMs are powered off if you are not running the required patch level.
Note For example purposes, the following procedure reflects an upgrade from Release 4.0(4)SV1(3b) to Release 4.2(1)SV1(4).
Caution If removable media is still connected, for example, if you have installed the VSM using ISO and forgot to remove the media, then host movement to maintenance mode fails and the VUM upgrade fails.
Step 1 Upload the vem-release_final.tar.gz file, system and kickstart images to the VSM's bootflash.
These files will be present in the zip folder of the FCS.
Step 2 Update the ESX host version.
switch (config)# vmware vem upgrade update-vibs bootflash:vem-release_final.tar.gz
Step 3 Send upgrade notification to VC.
switch (config)# vmware vem upgrade notify
Warning:Please ensure the hosts are running compatible ESX versions for the upgrade. Refer to corresponding "Cisco Nexus 1000V and VMware Compatibility Information" guide.Step 4 Verify that the upgrade notification was sent.
switch (config)# show vmware vem upgrade status
Upgrade Status: Upgrade Availability Notified in 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-201101030-RG
DVS: VEM400-201007101-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-201101030-RG
DVS: VEM400-201007101-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 Virtual Ethernet Module Software Installation and Upgrade Guide, Release 4.2(1)SV1(4).
•If the ESX host is not hosting the VSM, then proceed to Step 7.
•If the ESX host is hosting the VSM, coordinate with the server administrator to power off the VSM, upgrade the VEMs on the ESX host using the manual process, and power on the VSM.
Step 7 Initiate the Cisco Nexus 1000V Bundle ID upgrade process.
Note If VUM is enabled in the vCenter environment, disable it before running the vmware vem upgrade proceed command to prevent the new VIBs from being pushed to all the hosts.
Enter the vmware vem upgrade proceed command so that the Cisco Nexus 1000V Bundle ID on the vCenter Server gets updated. If VUM is enabled and you do not update the Bundle ID, an incorrect VIB version is pushed to the VEM when you next add the ESX to VSM.
switch# vmware vem upgrade proceed
Note If VUM is not installed, the "The object or item referred to could not be found. A general system error occurred: unknown internal error" error appears in the vCenter Server's task bar and can be safely ignored.
switch# show vmware vem upgrade status
Upgrade VIBs: Upgrade VEM 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 internal error.Upgrade Bundle ID:VSM: VEM400-201101030-RG
DVS: VEM400-201101030-RG
Step 8 Check for the Upgrade Complete status.
Note If the upgrade status is not complete, see the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4).
switch# show vmware vem upgrade status
Upgrade VIBs: Upgrade VEM 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-201101030-RG
DVS: VEM400-201101030-RG
Step 9 Coordinate with and wait until the server administrator upgrades all ESX host VEMs with the new VEM software release and informs you that the upgrade process is complete.
The server administrator performs the manual upgrade using the vi host update or the ESX/ESXi update. For details, see the Cisco Nexus 1000V Virtual Ethernet Module Software Installation and Upgrade Guide, Release 4.2(1)SV1(4).
Step 10 Clear the VEM upgrade status after the upgrade process is complete.
switch# vmware vem upgrade complete
switch# show vmware vem upgrade status
Upgrade VIBs: Upgrade VEM ImageUpgrade Status:Upgrade Notification Sent Time:Upgrade Status Time(vCenter):Upgrade Start Time:Upgrade End Time(vCenter):Upgrade Error:Upgrade Bundle ID:VSM: VEM400-201101030-RG
DVS: VEM400-201101030-RG
Step 11 Verify that the upgrade process is complete.
switch# show mod
Mod Ports Module-Type Model Status--- ----- -------------------------------- ------------------ ------------1 0 Virtual Supervisor Module Nexus1000V ha-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(3b) 0.02 4.2(1)SV1(3b) 0.03 4.2(1)SV1(4) VMware ESXi 4.0.0 Releasebuild-261974 (1.20)
4 4.2(1)SV1(4) VMware ESXi 4.1.0 Releasebuild-260247 (2.0)
Mod MAC-Address(es) Serial-Num--- -------------------------------------- ----------1 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 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(4).
Step 12 Proceed to upgrade the VSM.
Caution Do not proceed with the VSM upgrade if all VEMs are not upgraded to Release 4.2(1)SV1(4). Upgrade all VEMs to Release 4.2(1)SV1(4) before upgrading the VSMs.
For details, see the "Upgrading the VSMs to Release 4.2(1)SV1(4) Using the Upgrade Application" section.
Upgrading the VEMs: Release 4.0(4)SV1(1) to Release 4.2(1)SV1(4)
This section describes the steps to upgrade VEMs from Release 4.0(4)SV1(1) to Release 4.2(1)SV1(4) and includes the following topics:
•Upgrading the VEMs: Release 4.0(4)SV1(1) to Release 4.2(1)SV1(4)
•Upgrading the VEMs Manually: Release 4.0(4)SV1(1) to Release 4.2(1)SV1(4)
Prerequisites to Upgrading VEMs
The following are prerequisites to upgrading the VEMs:
•Executing and correcting errors from the PreUpgradeUtility.
•You are logged in to the VSM CLI in EXEC mode.
•You have already upgraded the VSM to Release 4.0(4)SV1(3b).
•Network and server administrators coordinate the VEM upgrade with each other.
Upgrading the VEMs Using VMware Update Manager (VUM): Release 4.0(4)SV1(1) to Release 4.2(1)SV1(4)
To upgrade the VEMs using VUM, follow these steps:
Note This procedure is performed by the network administrator. Before proceeding with the upgrade, make sure the VMs are powered off.
Caution This upgrade is only applicable when VSM and VC are not hosted on VEMs that are being upgraded. If the VSM is hosted on a VEM, proceed to the Upgrading the VEMs Manually: Release 4.0(4)SV1(1) to Release 4.2(1)SV1(4).
Step 1 Power off all virtual machines.
Step 2 Update the VEM host version.
switch (config)# vmware vem upgrade update-vibs bootflash:vem-release_final.tar.gz
Step 3 Coordinate with and notify the server administrator of the VEM upgrade process.
switch (config)# vmware vem upgrade notify
Warning:Please ensure the hosts are running compatible ESX versions for the upgrade. Refer to corresponding "Cisco Nexus 1000V and VMware Compatibility Information" guide.Step 4 Verify that the upgrade notification was sent.
switch (config)# show vmware vem upgrade status
Upgrade VIBs: Upgrade VEM 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-20100830100-BGDVS: VEM400-200904001-BG
Note Verify that Upgrade Status contains the highlighted text. If the text is not present, check the Upgrade Error line and consult the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4).
Step 5 Verify that the server administrator has accepted the upgrade in the vCenter Server.
For details about the server administrator accepting the VEM upgrade, see the "Accepting the VEM Upgrade in the vCenter Client" section.
Coordinate the notification acceptance with the server administrator. After the server administrator accepts the upgrade, proceed with the VEM upgrade.
switch (config)# show vmware vem upgrade status
Upgrade VIBs: Upgrade VEM 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-20100830100-BGDVS: VEM400-200904001-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: VSM130-201010110-BGDVS: VSM130-201010110-BGStep 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: VSM130-201010110-BGDVS: VSM130-201010110-BGStep 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: VSM130-201010110-BGDVS: VSM130-201010110-BGStep 9 Verify that the upgrade process is complete.
switch# show mod
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(3b) 0.02 4.2(1)SV1(3b) 0.03 4.2(1)SV1(4) VMware ESXi 4.0.0 Releasebuild-261974 (1.20)
4 4.2(1)SV1(4) VMware ESXi 4.1.0 Releasebuild-260247 (2.0)
Mod MAC-Address(es) Serial-Num--- -------------------------------------- ----------1 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 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(4).
Step 10 Proceed to upgrade the VSM.
Caution If any VEM is not upgraded to Release 4.2(1)SV1(4) by VUM, perform a manual upgrade of the VEM before continuing with the VSM upgrade.
For details, see the "Upgrading the VSMs to Release 4.2(1)SV1(4) Using the Upgrade Application" section.
Upgrading the VEMs Manually: Release 4.0(4)SV1(1) to Release 4.2(1)SV1(4)
To upgrade the VEMs manually, the network administrator initiates the upgrade process as described below.
Note Before proceeding with the upgrade, make sure the VMs are powered off. The VSM must be upgraded to Release 4.0(4)SV1(3b).
Step 1 Update the ESX host version.
switch (config)# vmware vem upgrade update-vibs bootflash:vem-release_final.tar.gz
Step 2 Coordinate with and notify the server administrator of the VEM upgrade process.
switch (config)# vmware vem upgrade notify
Warning:Please ensure the hosts are running compatible ESX versions for the upgrade. Refer to corresponding "Cisco Nexus 1000V and VMware Compatibility Information" guide.Step 3 Verify that the upgrade notification was sent.
switch (config)# show vmware vem upgrade status
Upgrade VIBs: Upgrade VEM 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-201101030-RG
DVS: VEM400-200904001-BG
Note Verify that Upgrade Status contains the highlighted text. If the text is not present, check the Upgrade Error line and consult the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4).
Step 4 Verify that the server administrator has accepted the upgrade in vCenter Server.
For details about the server administrator accepting the VEM upgrade, see the "Accepting the VEM Upgrade in the vCenter Client" section.
After the server administrator accepts the upgrade, proceed with the VEM upgrade.
switch# show vmware vem upgrade status
Upgrade VIBs: Upgrade VEM 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-201101030-RG
DVS: VEM400-201003101-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 Virtual Ethernet Module Software Installation and Upgrade Guide, Release 4.2(1)SV1(4).
•If the ESX host is not hosting the VSM/VC, then proceed to Step 6.
•If the ESX host is hosting the VSM/VC, coordinate with the server administrator to power off the VSM/VC, upgrade the VEMs on the ESX host using the manual process, and power on the VSM/VC.
Step 6 Initiate the Cisco Nexus 1000V Bundle ID upgrade process.
Note If VUM is enabled in the vCenter environment, disable it before entering the vmware vem upgrade proceed command to prevent the new VIBs from being pushed to all the hosts.
If VUM is disabled, any error in the output of the show vmware vem upgrade status command when entering the vmware vem upgrade proceed command can be ignored.
Enter the vmware vem upgrade proceed command so that the Cisco Nexus 1000V Bundle ID on the vCenter Server gets updated. If VUM is enabled and you to not update the Bundle ID, an incorrect VIB version is pushed to the VEM when you next add the ESX to VSM.
switch# vmware vem upgrade proceed
switch# show vmware vem upgrade status
2010 Mar 18 15:37:45 switch %VMS-5-DVS_UPGRADE_INFO: VEM Upgrade is completed successfully in vCenter.Upgrade VIBs: Upgrade VEM 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-201101030-RG
DVS: VEM400-201101030-RG
Step 7 Clear the VEM upgrade status after the upgrade process is complete.
switch# vmware vem upgrade complete
switch# show vmware vem upgrade status
Upgrade VIBs: Upgrade VEM 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 mod
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(3b) 0.02 4.2(1)SV1(3b) 0.03 4.2(1)SV1(4) VMware ESXi 4.0.0 Releasebuild-261974 (1.20)
4 4.2(1)SV1(4) VMware ESXi 4.1.0 Releasebuild-260247 (2.0)
Mod MAC-Address(es) Serial-Num--- -------------------------------------- ----------1 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 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(4).
Step 9 Proceed to upgrade the VSM.
Caution Do not proceed with the VSM upgrade if all VEMs are not upgraded to Release 4.2(1)SV1(4). Upgrade all VEMs to Release 4.2(1)SV1(4) before upgrading the VSMs.
For details, see "Upgrading the VSMs to Release 4.2(1)SV1(4) Using the Upgrade Application" section.
Upgrading the VSMs to Release 4.2(1)SV1(4) Using the Upgrade Application
Note This upgrade procedure applies to upgrades from Release 4.0(4)SV1(3), Release 4.0(4)SV1(3a), or Release 4.0(4)SV1(3b).
This section describes upgrading the VSM from Release 4.0(4)SV1(3b) to Release 4.2(1)SV1(4). The Upgrade Application is the recommended method of upgrading the VSM from Release 4.0(4)SV1(3), Release 4.0(4)SV1(3a), or Release 4.0(4)SV1(3b) to Release 4.2(1)SV1(4).
Caution If you are upgrading on a Cisco Nexus 1010, make sure that the secondary VSM is active and the primary VSM is standby prior to initiating the upgrade. If the primary VSM is active, run the system switchover command to make the secondary VSM active.
Prerequisites to Using the Cisco Nexus 1000V Upgrade Application
The following are prerequisites to using the upgrade application:
•Executing and correcting errors from the PreUpgradeUtility.
•VEMs are upgraded to Release 4.2(1)SV1(4) first to complete the VEM upgrade.
•Upload the VSM (kickstart and system) images to the bootflash.
•You might need up to three additional IP addresses in the same subnet as the VSM mgmt0 and control0.
•You will need to enter additional IP addresses that are in the same subnet depending on your L2 or L3 setup. This additional IP address is required since one VSM will be on a previous release and the other VSM will be on Release 4.2(1)SV1(4).
Caution If the IP addresses are not in the same subnet, the system will be in an inconsistent state. See the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4) to recover the system.
•SSH enabled on the VSM.
•A synchronized HA pair is mandatory prior to starting the Upgrade Application.
•If Authentication, Authorization, and Accounting (AAA) servers are used for authentication, add the temporary IP address used in the upgrade to the authentication database.
Note During this hitless VSM upgrade procedure, the VEMs connected via L3 will flap during the upgrade when temporary IP addresses are programmed. Traffic flow will not be affected.
To perform a VSM software upgrade from Release 4.0(4)SV1(3), Release 4.0(4)SV1(3a), or Release 4.0(4)SV1(3b) to Release 4.2(1)SV1(4) by using the Upgrade Application, follow these steps:
Note This procedure is performed by the network administrator.
Note If you are upgrading on a Cisco Nexus 1010, make sure that the Secondary VSM is Active and the Primary VSM is Standby prior to initiating the upgrade. For more information about upgrade the Cisco Nexus 1010, see Upgrading the VSMs Manually on a Cisco Nexus 1010 from Release 4.0(4)SV1(3, 3a, or 3b) to Release 4.2(1)SV1(4).
Caution If removable media is still connected, for example, if you have installed the VSM using ISO and forgot to remove the media, then host movement to maintenance mode fails and the VUM upgrade fails.
Step 1 Perform a backup of the configuration to external storage.
Step 2 In the browser address field, enter the VSM IP address and press Enter.
The Cisco Nexus 1000V screen opens.
Figure 23
Cisco Nexus 1000V Upgrade Application: Initial Window
Step 3 Click the Launch Upgrade Application link.
The application download begins.
Note If no VEMs are attached, the Launch Upgrade Application link is not present. If you still wish to upgrade, you can run the Upgrade Application from the http://<vsm-ip-address>/cgi-bin/upgrade.jnlp directory.
Step 4 Click Run in the Warning - Security window.
The Enter VSM Credentials screen opens.
Figure 24
Nexus 1000v Upgrade: Enter VSM Credentials
Step 5 Enter the VSM password and click Next.
The Verify Module Upgrade screen opens.
Figure 25
Nexus 1000v Upgrade: Verify Module Upgrade
Step 6 Verify that the module count is correct.
Step 7 If you have an L2 configuration, continue with Step 8. If you have an L3 configuration, proceed to Step 9.
Figure 26
Nexus 1000v Upgrade: Enter Upgrade Information for L2
Step 8 Perform the following sub-steps:
a. Enter a temporary IPv4 IP address for interface mgmt0.
b. Select nexus-1000v-mz.4.2.1.SV1.4.bin from the New System Image drop-down.
c. Select nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin from the New Kickstart Image drop-down.
d. Click Next. The Summary: Please Review Configurations screen opens.
e. Proceed to Step 10.
Figure 27
Nexus 1000v Upgrade: Enter Upgrade Information for L3
Step 9 Perform the following sub-steps:
a. Enter a temporary IPv4 IP address for interface mgmt0.
b. Enter a temporary IPv4 IP address for L3 interface control0.
c. Select nexus-1000v-mz.4.2.1.SV1.4.bin from the New System Image drop-down.
d. Select nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin from the New Kickstart Image drop-down.
e. Click Next. The Summary: Please Review Configurations screen opens.
f. Continue to Step 10.
If you have an L2 configuration, Figure 28 opens. If you have an L3 configuration, Figure 29 opens.
Figure 28
Nexus 1000v Upgrade: Layer 2 - Please Review Configurations
Figure 29
Nexus 1000v Upgrade: Layer 3 - Please Review Configurations
Step 10 Confirm the settings and click Next.
The Upgrade Progress screen opens and the upgrade of the secondary VSM begins. Continue to Step 11.
Caution This step will take a few minutes to complete. If you close this window, your setup will be left in an inconsistent state.
Figure 30
Nexus 1000V Upgrade: Secondary VSM Upgrade Progress
Note Depending on the number of VEMs, this portion of the upgrade might take a few minutes.
Step 11 When the upgrade process completes, click Next.
The Verify Module Insertion screen opens.
Figure 31
Nexus 1000v Upgrade: Verify Module Insertion
Step 12 If you are having L3 connectivity using control0 to connect to VEMs, then continue with this step, otherwise move to Step 13.
a. Log in to the temporary IP address of the VSM or console of Release 4.2(1)SV1(4) VSM.
b. Check if there are sub-net or default routes associated with the control0 interface. This can be achieved by:
–Running the show running-config command
–Look for routes under vrf context management
vrf context 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.1VSM(config)# vrf context managementVSM(config-vrf)# no ip route 192.168.1.0/24 192.168.2.1
Caution Do not save the running configuration to the startup configuration until the upgrade procedure is complete.
Step 13 Log in to the temporary IP address of the VSM or console of Release 4.2(1)SV1(4) VSM and check if the module status is "ok"'.
If the module status is not "ok", refer to the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4). Do not proceed unless all modules are in status "ok".
Step 14 Click Finish when all modules in the temporary IP VSM display a status of "ok".
Note If you decide not to upgrade, click the Override: Force Upgrade button to leave the VEMs on a previous release. If you take this action, your VEMs will be in an inconsistent state which is not a supported model for the Cisco Nexus 1000V.
When finished, click Next.
Step 15 Log in to the temporary IP address or console of the Release 4.2(1)SV1(4) VSM and check if the module status is 'ok'. If not "ok", refer to Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4). Do not proceed unless all modules are in status "ok".
Step 16 If you are having L3 control mode of the testbed, then continue with this step, otherwise continue with Step 19.
Step 17 Click Finish when all modules in temporary IP VSM are displaying a status = ok.
Step 18 At this point in the upgrade process, you will see one of two screens:
•If the screen contains one table with the heading of The following modules have been attached, click Finish and the upgrade of the second VSM will begin.
•If the screen contains a second table with the heading of The following modules are missing, you should click Refresh List. Prior to clicking Finish, log in to the VSM and run the show module command.
–If the module status is OK, click Finish.
The Verify Module Insertion window opens for the second VSM upgrade.
–If the module status is not OK, proceed to the troubleshooting section before clicking Finish.
Figure 32
Nexus 1000v Upgrade: Second VSM Upgrade
Note This step can take several minutes to complete. Do not cancel the wizard.
When the upgrade of the second VSM completes, the Summary screen opens.
Figure 33
Nexus 1000v Upgrade: Summary
Step 19 Click Close.
The upgrade of the VSMs is complete.
Step 20 To display the virtual device context ID of the VSM, run the following command:
switch(config)# sho run | include vdc
vdc N1KV-VSM id 1Step 21 To be able to support 2048 VLANs, run the following command.
switch(config)# vdc NIKV-VSM id 1
switch(config-vdc)# limit-resource vlan minimum 16 maximum 2049
The upgrade is complete.
Upgrading the VSMs Manually on a Cisco Nexus 1000V from Release 4.0(4)SV1(3, 3a, or 3b) to Release 4.2(1)SV1(4)
This section describes how to manually upgrade to Release 4.2(1)SV1(4) from Release 4.0(4)SV1(3, 3a, or 3b) by using the CLI.
Prerequisites to Upgrading the VSMs
The following are prerequisites to upgrading the VSMs:
•Executing and correcting errors from the PreUpgradeUtility.
•VEMs are upgraded to Release 4.2(1)SV1(4).
•The kickstart and system images have been uploaded to the bootflash.
•You might need up to three additional IP addresses in the same subnet as the VSM mgmt0 and control0.
Caution If the IP addresses are not in the same subnet, the system will be in an inconsistent state. See the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4).
•SSH is enabled on the VSM.
•A VSM HA environment is mandatory for the upgrade to proceed.
•Network and server administrators coordinate the upgrade procedure with each other.
•You have saved all changes in the running configuration to the startup configuration to be preserved through the upgrade.
•You have saved a backup copy of the running configuration in external storage.
•If Authentication, Authorization, and Accounting (AAA) servers are used for authentication, add the temporary IP address used in the upgrade to the authentication database.
Note The Upgrade Application is the recommended method of upgrading.
The two VSMs are identified as VSM1 and VSM2 which are the active and standby VSMs respectively.
To manually upgrade to Release 4.2(1)SV1(4), follow these steps:
Step 1 Log in to the VSM.
Step 2 Copy the kickstart and isan images to the bootflash: file system.
switch# copy scp:root@192.0.2.13/N1K-VSM-images/nexus-1000v-mz.4.2.1.SV1.4.bin bootflash:
switch# copy scp:root@192.0.2.13/N1K-VSM-images/nexus-1000v-kickstart.mz.4.2.1.SV1.4.bin bootflash:
Step 3 Display the current redundancy status.
switch# show module
Mod Ports Module-Type Model Status--- ----- -------------------------------- ------------------ ------------1 0 Virtual Supervisor Module Nexus1000V active *2 0 Virtual Supervisor Module Nexus1000V ha-standby3 248 Virtual Ethernet Module NA okMod Sw Hw--- --------------- ------1 4.0(4)SV1(3b) 0.02 4.0(4)SV1(3b) 0.03 4.2(1)SV1(4) VMware ESXi 4.1.0 Releasebuild-260247 (2.0) 1.9Mod 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 NAMod Server-IP Server-UUID Server-Name--- ------------- ------------------------------------ --------------------1 172.23.233.64 NA NA2 172.23.233.64 NA NA3 172.23.232.72 33393935-3234-5553-4538-35314e323554 172.23.232.72* this terminal sessionswitch# 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: sachinDCDVS 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 will be used to access VSM2 while the HA pair is split.
switch(config)# svs upgrade start mgmt0 ip ipaddr
WARNING!1. Please do not change the configuration of the system from this point 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
Step 6 Update the system and kickstart boot variables.
switch# install all system bootflash: nexus-1000v-mz.4.2.1.SV1.4.bin kickstart bootflash:nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin
System image sync to standby is in progress...
System image is synced to standby.
Kickstart image sync to Standby is in progress...
Kickstart image is synced to standby.
Upgrade in process, hence Active boot variables are not updated.
Boot variables are updated to running configuration.
Step 7 Copy the running configuration to the startup configuration and verify.
switch# copy running-config startup-config
[########################################] 100%switch# show start | in boot
boot kickstart bootflash:/nexus-1000v-kickstart-mzg.4.0.4.SV1.3b.bin sup-1
boot system bootflash:/nexus-1000v-mzg.4.0.4.SV1.3b.bin sup-1
boot kickstart bootflash:/nexus-1000v-kickstart-mzg.4.2.1.SV1.4.bin sup-2
boot system bootflash:/nexus-1000v-mzg.4.2.1.SV1.4.bin sup-2
Note The following commands display that the active VSM (sup-1) is still on Release 4.0(4)SV1(3b) and the standby VSM is now on Release 4.2(1)SV1(4).
Step 8 Reload the VSM whose boot variables are set to Release 4.2(1)SV1(4).
switch# reload module slot
This command will reboot standby supervisor module. (y/n)? [n] y2010 June 14 20:11:51 av1-vsm %PLATFORM-2-PFM_MODULE_RESET: Manual restart of Module 2 from Command Line Interfaceswitch# 2010 Jun 14 20:11:58 av1-vsm %PLATFORM-2-MOD_REMOVE: Module 2 removed (Serial number T50569A5039
Step 9 Log in to VSM2 using the temporary IP address.
Step 10 Confirm that VSM2 is now standalone.
switch# show system redundancy status
Redundancy role
---------------
administrative: standalone
operational: standalone
Redundancy mode
---------------
administrative: HA
operational: None
This supervisor (sup1)
----------------------
Redundancy state: Active
Supervisor state: Active
Internal state: Active with no standby
Other supervisor (sup-2)
------------------------
Redundancy State: Not present
Step 11 On VSM1, remove the connection between VSM1 and the vCenter Server.
Caution This step is being performed to prevent opaque data from being pushed to the vCenter Server. Not performing this step could adversely impact the VEMs.
switch# show running-config
svs-domain
domain id 470
control vlan 233
packet vlan 233
svs mod L2
svs upgrade start mgmt0 ip 172.23.231.133.66
svs connection vc
protocol vmware-vimremote up address 172.23.231.133 port 80
vmware dvs uuid "0c bf 0e 50 0b 4a b7 76-88 13 be 45 14 e8 9b 4e" datacenter-name sachinDCconnectswitch# config t
switch# (config)# svs connection vc
switch# (config-svs-conn)# no connect
Step 12 Change VSM1's role to secondary.
switch(config-svs-conn)# end
switch(config)# end
switch# system redundancy role secondary
Setting will be activated on next reload
switch# show run | in boot
boot kickstart bootflash:/nexus-1000v-kickstart-mzg.4.0.4.SV1.3b.bin sup-1
boot system bootflash:/nexus-1000v-mzg.4.0.4.SV1.3b.bin sup-1
boot kickstart bootflash:/nexus-1000v-kickstart-mzg.4.2.1.SV1.4.bin sup-2
boot system bootflash:/nexus-1000v-mzg.4.2.1.SV1.4.bin sup-2
Step 13 Change the boot variables on VSM1 to point to the Release 4.2(1)SV1(4) images.
switch# config t
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)# boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin
switch(config)# no boot system bootflash:/nexus-1000v.mzg.4.0.4.SV1.3b.bin sup-1
switch(config)# boot system bootflash:/nexus-1000v-mz.4.2.1.SV1.4.bin sup-1
switch(config)# end
switch# show run | in boot
boot kickstart bootflash:/nexus-1000v-kickstart-mzg.4.2.1.SV1.4.bin sup-1
boot system bootflash:/nexus-1000v-mzg.4.2.1.SV1.4.bin sup-1
boot kickstart bootflash:/nexus-1000v-kickstart-mzg.4.2.1.SV1.4.bin sup-2
boot system bootflash:/nexus-1000v-mzg.4.2.1.SV1.4.bin sup-2
Step 14 Save the configuration on VSM1.
switch# copy running-config startup-config
[########################################] 100%
Step 15 Display the current connections on VSM2.
switch# config t
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)# show svs connect
connection vcenter:
ip address: 172.23.231.133
remote port: 80
protocol: vmware-vim https
certificate: default
datacenter name: n1000vDC
DVS uuid: 0c bf 0b 50 0b 4a b7 76-88 13 be 45 14 e8 9b 4e
config status: Enabled
operational status: Disconnected
sync status: -
version: -
Step 16 If you are having L3 connectivity using control0 to connect to VEMs, then continue with this step, otherwise move to Step 17.
a. Log in to the temporary IP address of the VSM or console of Release 4.2(1)SV1(4) VSM.
b. Check if there are sub-net or default routes associated with the control0 interface. This can be achieved by:
–Running the show running-config command
–Look for routes under vrf context management
vrf context 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
Caution Do not save the running configuration to the startup configuration until the upgrade procedure is complete.
Step 17 Log in to the temporary IP address of the VSM or console of Release 4.2(1)SV1(4) VSM and check if the module status is "ok"'.
If the module status is not "ok", refer to the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4). Do not proceed unless all modules are in status "ok".
Step 18 Inform the VEMs that the upgrade process has completed.
Note Make sure that all the VEMs are attached to the Release 4.2(1)SV1(4) VSM. Verify by comparing the number of VEMs that were attached to the Release 4.0(4)SV1(3b) VSM match the number of VEMs that are attached to the Release 4.2(1)SV1(4) VSM. Check for module status = "ok".
switch# config t
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)# svs upgrade complete
Warning: Config saved but not pushed to vCenter Server due to inactive connection!
switch(config)# end
switch# show run | in svs
svs-domain
svs mode L2
svs upgrade complete
svs connection vc
switch# config t
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)# svs connection name
switch(config-svs-conn)# connect
switch(config-svs-conn)# end
switch(config)# end
switch# show module
Mod Ports Module-Type Model Status--- ----- -------------------------------- ------------------ ------------1 0 Virtual Supervisor Module Nexus1000V active *3 248 Virtual Ethernet Module NA okMod Sw Hw--- --------------- ------1 4.2(1)SV1(3b) 0.03 4.2(1)SV1(4) 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 role to primary.
switch# system redundancy role primary
Step 20 Reload VSM1.
switch# show module
switch# show run int mgmt0
!Command: show running-config interface mgmt0
!Time: Mon Jun 14 20:27:27 2010
version 4.2(1)SV1(4)
interface mgmt0
ip address 192.0.2.11/24
switch# reload
This command will reboot the system. (y/n)? [n] y
switch# copy running-config startup-config
switch# reload
Step 21 Change VSM2's mgmt0 IP address back to the shared IP address.
switch# show run int mgmt0
switch# config t
switch(config)# int mgmt0
switch(config-if)# ip address 192.0.2.11 255.255.255.0
Step 22 Confirm upgraded HA pair.
switch# show system redundancy status
Redundancy role---------------administrative: 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 23 Save the configuration.
switch# copy running-config startup-config
[########################################] 100%
Upgrading the VSMs Manually on a Cisco Nexus 1010 from Release 4.0(4)SV1(3, 3a, or 3b) to Release 4.2(1)SV1(4)
This section describes the VSM manual upgrade procedure from Release 4.0(4)SV1(3, 3a, or 3b) to Release 4.2(1)SV1(4).
Prerequisites to Upgrading the VSMs
The following are prerequisites to upgrading the VSMs:
•Executing and correcting errors from the PreUpgradeUtility.
•VEMs are upgraded to Release 4.2(1)SV1(4) first to complete the VEM upgrade.
•Upload the kickstart and system images to the bootflash.
•You might need up to additional IP addresses in the same subnet as the VSM mgmt0 and control0 depending on your Layer 2 or Layer 3 setup. The additional IP address is required since one VSM will be on a previous release and the other VSM will be on Release 4.2(1)SV1(4).
Caution If the IP addresses are not in the same subnet, the system will be in an inconsistent state. See the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4) to recover the system.
•SSH is enabled on the VSM.
•The Cisco Nexus 1010 systems are in an HA configuration.
•Make sure the the secondary VSM is active and the primary VSM is standby.
•You have saved all changes in the running configuration to the startup configuration.
•You have saved a backup copy of the running configuration in external storage.
Note The Upgrade Application is the recommended method of upgrading.
This procedure is performed by the network administrator.
The two VSMs are identified as VSM1 and VSM2 which are the active and standby VSMs respectively.
To perform a manual upgrade to Release 4.2(1)SV1(4), follow these steps:
Step 1 Log in to the VSM.
Step 2 Copy the kickstart and isan images to the bootflash: file system.
switch# copy scp://root@192.0.2.13/N1K-VSM-images/nexus-1000v-mz.4.2.1.SV1.4.bin bootflash:
Enter vrf (If no input, current vrf 'default' is considered):root@192.0.2.13's password:nexus-1000v-mz.4.2.1.SV1.4.bin 100% 20MB 1.1MB/s 00:19switch#switch# copy scp://root@192.0.2.13/N1K-VSM-images/nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin bootflash:Enter vrf (If no input, current vrf 'default' is considered):root@192.0.2.13's password:nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin 100% 20MB 1.1MB/s 00:19switch#Step 3 Display the current redundancy status.
switch# show moduleswitch# 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 okMod Sw Hw--- --------------- ------1 4.0(4)SV1(3) 0.02 4.0(4)SV1(3) 0.03 4.2(1)SV1(4) 1.9Mod 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 NAMod Server-IP Server-UUID Server-Name--- --------------- ------------------------------------ --------------------1 192.0.2.11 NA NA2 192.0.2.11 NA NA3 10.78.109.51 4220900d-76d3-89c5-17d7-b5a7d1a2487f 10.78.109.51switch# show system redundancy status
Redundancy role---------------administrative: secondaryoperational: secondaryRedundancy mode---------------administrative: HAoperational: HAThis supervisor (sup-2)-----------------------Redundancy state: ActiveSupervisor state: ActiveInternal state: Active with HA standbyOther supervisor (sup-1)------------------------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: SWAMYDVS uuid: 5e ca 20 50 bc 28 07 fb-0b 1d 98 56 40 cb fd 85config status: Enabledoperational status: Connectedsync status: Completeversion: VMware vCenter Server 4.0.0 build-258672Step 5 Inform the VEMs that the upgrade process is starting and assign the temporary IP address to VSM2.
If you are using Layer 3 mode with control0, go to Step 6.
Note If Authentication, Authorization, and Accounting (AAA) servers are used for authentication, add the temporary IP address used in the upgrade to the authentication database.
switch# configure terminal
Note The value of ipaddr in the following command is the temporary IP address that will be used to access VSM2 while the HA pair is split.
switch(config)# svs upgrade start mgmt0 ip ipaddrWARNING!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
Go to Step 7.
Step 6 Inform the VEMs that the upgrade process is starting and assign the temporary IP address to VSM2 mgmt0 and control0 interfaces.
switch(config)# svs upgrade start mgmt0 ip ipaddr control0 ip ipaddrWARNING!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
Step 7 Update the system and kickstart boot variables.
switch# install all system bootflash:nexus-1000v-mz.4.2.1.SV1.4.bin kickstart bootflash:nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin
System image sync to standby is in progress...System image is synced to standby.Kickstart image sync to Standby is in progress...Kickstart image is synced to standby.Upgrade in progress, hence Active boot variables are not updated.Boot variables are updated to running configuration.Step 8 Copy the running configuration to the startup configuration and verify.
switch# copy running-config startup-config
[########################################] 100%switch# show startup-config | in boot
boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin sup-1boot system bootflash:/nexus-1000v-mz.4.2.1.SV1.4.bin sup-1boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3.bin sup-2boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3.bin sup-2
Note The following commands displays that the active VSM (sup-2) is still on Release 4.0(4)SV1(3) and the standby VSM is now on Release 4.2(1)SV1(4).
Step 9 Reload the VSM whose boot variables are set to Release 4.2(1)SV1(4).
switch# reload module slot
This command will reboot standby supervisor module. (y/n)? [n] yabout to reset standby supswitch# 2011 Jan 7 14:07:38 switch %$ VDC-1 %$ %PLATFORM-2-PFM_MODULE_RESET: Manual restart of Module 1 from Command Line Interface2011 Jan 7 14:07:46 switch %$ VDC-1 %$ %PLATFORM-2-MOD_REMOVE: Module 1 removed (Serial number T023D73E802)Step 10 Log in to VSM2 using the temporary IP address.
Step 11 Confirm that VSM2 is now standalone.
switch# show system redundancy status
Redundancy role---------------administrative: standaloneoperational: standaloneRedundancy mode---------------administrative: HAoperational: NoneThis supervisor (sup1)----------------------Redundancy state: ActiveSupervisor state: ActiveInternal state: Active with no standbyOther supervisor (sup-2)------------------------Redundancy State: Not presentStep 12 Change the boot variables on VSM2 to point to the Release 4.2(1)SV1(4) images.
switch# config t
Enter configuration commands, one per line. End with CNTL/Z.switch(config)# no boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3.bin sup-2
switch(config)# no boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3.bin sup-2
switch(config)# boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin sup-2
switch(config)# boot system bootflash:/nexus-1000v-mz.4.2.1.SV1.4.bin sup-2
switch(config)# end
switch# show running-config | in boot
boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin sup-1boot system bootflash:/nexus-1000v-mz.4.2.1.SV1.4.bin sup-1boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin sup-2boot system bootflash:/nexus-1000v-mz.4.2.1.SV1.4.bin sup-2Step 13 Save the configuration.
switch# copy running-config startup-config
[########################################] 100%Step 14 On VSM1 which is running a release prior to Release 4.2(1)SV1(4), remove the connection between it and the vCenter Server.
switch# show running-config
svs-domaindomain id 1291control vlan 1291packet vlan 1292svs mode L2svs upgrade start mgmt0 ip 192.0.2.12svs connection vcenterprotocol vmware-vimremote ip address 192.0.2.10 port 80vmware dvs uuid "5e ca 20 50 bc 28 07 fb-0b 1d 98 56 40 cb fd 85" datacenter-name SWAMYconnectswitch# config t
switch# (config)# svs connection name
switch# (config-svs-conn)# no connect
Step 15 Change VSM1's role to secondary.
VSM1 is running a release prior to Release 4.2(1)SV1(4).
switch# (config-svs-conn)# end
switch# (config)# end
switch# system redundancy role secondary
Step 16 Change the boot variables on VSM1 to point to the Release 4.2(1)SV1(4) images.
switch# config t
Enter configuration commands, one per line. End with CNTL/Z.switch(config)# no boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3.bin sup-2
switch(config)# no boot system bootflash:/nexus-1000v-mz.4.0.4.SV1.3.bin sup-2
switch(config)# boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin sup-2
switch(config)# boot system bootflash:/nexus-1000v-mz.4.2.1.SV1.4.bin sup-2
switch(config)# end
switch# show running-config | in boot
boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin sup-1boot system bootflash:/nexus-1000v-mz.4.2.1.SV1.4.bin sup-1boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin sup-2boot system bootflash:/nexus-1000v-mz.4.2.1.SV1.4.bin sup-2Step 17 Save the configuration on VSM1.
switch# copy running-config startup-config
[########################################] 100%Step 18 Display the current connections on VSM2.
switch(config)# show svs connections
connection vcenter:ip address: 192.0.2.10remote port: 80protocol: vmware-vim httpscertificate: defaultdatacenter name: DC1DVS uuid: 5e ca 20 50 bc 28 07 fb-0b 1d 98 56 40 cb fd 85config status: Disabledoperational status: Disconnectedsync status: -version: -Step 19 If you have L3 connectivity using control0 to connect to VEMs, then continue with this step, otherwise move to Step 20.
a. Log in to the temporary IP address of the VSM or console of Release 4.2(1)SV1(4) VSM.
b. Check if there are sub-net or default routes associated with the control0 interface. This can be achieved by:
–Running the show running-config command
–Look for routes under vrf context management
vrf context 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 the control0 interface.
c. Select only the routes that are used for VEM connectivity and move them under the global config context.
VSM(config)# ip route 192.168.1.0/24 192.168.2.1
VSM(config)# vrf context management
VSM(config-vrf)# no ip route 192.168.1.0/24 192.168.2.1
Caution Do not save the running configuration to the startup configuration until the upgrade procedure is complete.
Step 20 Log in to the temporary IP address of the VSM or console of Release 4.2(1)SV1(4) VSM and check if the module status is ok.
If the module status is not ok, refer to the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4). Do not proceed unless all modules are in status ok.
Step 21 Connect to VSM2.
Note Make sure that all the VEMs are attached to the Release 4.2(1)SV1(4) VSM. Verify by comparing the number of VEMs that were attached to the Release 4.0(4)SV1(3) VSM. This number should match the number of VEMs that are attached to the Release 4.2(1)SV1(4) VSM.
switch(config)# svs upgrade complete
Warning: Config saved but not pushed to vCenter Server due to inactive connection!switch(config)# show running-config | in svs
svs-domainsvs mode L2svs upgrade completesvs connection vcenterswitch(config)# svs connection name
switch(config-svs-conn)# connect
switch(config-svs-conn)# end
switch# show module
Mod Ports Module-Type Model Status--- ----- -------------------------------- ------------------ ------------1 0 Virtual Supervisor Module Nexus1000V active *3 248 Virtual Ethernet Module NA okMod Sw Hw--- ---------------- ------------------------------------------------1 4.2(1)SV1(4) 0.03 4.2(1)SV1(4) VMware ESX 4.0.0 Releasebuild-208167 (1.9)Mod MAC-Address(es) Serial-Num--- -------------------------------------- ----------1 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA3 02-00-0c-00-04-00 to 02-00-0c-00-04-80 NAMod Server-IP Server-UUID Server-Name--- --------------- ------------------------------------ --------------------1 192.0.2.12 NA NA3 10.78.109.51 4220900d-76d3-89c5-17d7-b5a7d1a2487f ESX40U1COS* this terminal sessionStep 22 Change VSM2 role to primary.
switch# system redundancy role primary
Step 23 Reload VSM1.
switch# show module
Mod Ports Module-Type Model Status--- ----- -------------------------------- ------------------ ------------2 0 Virtual Supervisor Module Nexus1000V active *Mod Sw Hw--- --------------- ------2 4.0(4)SV1(3) 0.0Mod MAC-Address(es) Serial-Num--- -------------------------------------- ----------2 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NAMod Server-IP Server-UUID Server-Name--- --------------- ------------------------------------ --------------------2 192.0.2.11 NA NAswitch# reload
This command will reboot the system. (y/n)? [n] y2011 Jan 7 18:07:11 switch %$ VDC-1 %$ %PLATFORM-2-PFM_SYSTEM_RESET: Manual system restart from Command Line InterfaceStep 24 Change VSM2's mgmt0 IP address back to the shared IP address.
switch# show run int mgmt0
switch# config t
switch(config)# int mgmt0
switch(config-if)# ip address 192.0.2.11 255.255.255.240
switch(config-if)# end
Step 25 Log in to VSM2 by using the shared IP address.
switch# show system redundancy status
Redundancy role---------------administrative: 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 standbyswitch# 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 okMod Sw Hw--- ---------------- ------------------------------------------------1 4.2(1)SV1(4) 0.02 4.2(1)SV1(4) 0.03 4.2(1)SV1(4) VMware ESX 4.0.0 Releasebuild-208167 (1.9)Mod MAC-Address(es) Serial-Num--- -------------------------------------- ----------1 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA2 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA3 02-00-0c-00-04-00 to 02-00-0c-00-04-80 NAMod Server-IP Server-UUID Server-Name--- --------------- ------------------------------------ --------------------1 192.0.2.11 NA NA2 192.0.2.11 NA NA3 10.78.109.51 4220900d-76d3-89c5-17d7-b5a7d1a2487f 10.78.109.51* this terminal sessionStep 26 Save the configuration.
switch# copy running-config startup-config
[########################################] 100%
Upgrading the VSMs Manually on a Cisco Nexus 1000V from Release 4.0(4)SV1(3, 3a, or 3b) to Release 4.2(1)SV1(4)
This section describes how to manually upgrade to Release 4.2(1)SV1(4) from Release 4.0(4)SV1(3, 3a, or 3b) by using the CLI.
Prerequisites to Upgrading the VSMs
The following are prerequisites to upgrading the VSMs:
•Executing and correcting errors from the PreUpgradeUtility.
•VEMs are upgraded to Release 4.2(1)SV1(4).
•The kickstart and system images have been uploaded to the bootflash.
•You might need up to three additional IP addresses in the same subnet as the VSM mgmt0 and control0.
Caution If the IP addresses are not in the same subnet, the system will be in an inconsistent state. See the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4).
•SSH is enabled on the VSM.
•A VSM HA environment is mandatory for the upgrade to proceed.
•Network and server administrators coordinate the upgrade procedure with each other.
•You have saved all changes in the running configuration to the startup configuration to be preserved through the upgrade.
•You have saved a backup copy of the running configuration in external storage.
•If Authentication, Authorization, and Accounting (AAA) servers are used for authentication, add the temporary IP address used in the upgrade to the authentication database.
Note The Upgrade Application is the recommended method of upgrading.
The two VSMs are identified as VSM1 and VSM2 which are the active and standby VSMs respectively.
To manually upgrade to Release 4.2(1)SV1(4), follow these steps:
Step 1 Log in to the VSM.
Step 2 Copy the kickstart and isan images to the bootflash: file system.
switch# copy scp:root@192.0.2.13/N1K-VSM-images/nexus-1000v-mz.4.2.1.SV1.4.bin bootflash:
switch# copy scp:root@192.0.2.13/N1K-VSM-images/nexus-1000v-kickstart.mz.4.2.1.SV1.4.bin bootflash:
Step 3 Display the current redundancy status.
switch# show module
Mod Ports Module-Type Model Status--- ----- -------------------------------- ------------------ ------------1 0 Virtual Supervisor Module Nexus1000V active *2 0 Virtual Supervisor Module Nexus1000V ha-standby3 248 Virtual Ethernet Module NA okMod Sw Hw--- --------------- ------1 4.0(4)SV1(3b) 0.02 4.0(4)SV1(3b) 0.03 4.2(1)SV1(4) VMware ESXi 4.1.0 Releasebuild-260247 (2.0) 1.9Mod 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 NAMod Server-IP Server-UUID Server-Name--- ------------- ------------------------------------ --------------------1 172.23.233.64 NA NA2 172.23.233.64 NA NA3 172.23.232.72 33393935-3234-5553-4538-35314e323554 172.23.232.72* this terminal sessionswitch# 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: 172.23.231.133remote port: 80protocol: vmware-vim httpscertificate: defaultdatacenter name: sachinDCDVS 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.
If you are using L3 mode with control0, go to Step 6.
Note If Authentication, Authorization, and Accounting (AAA) servers are used for authentication, add the temporary IP address used in the upgrade to the authentication database.
switch# configure terminal
Note The value of ipaddr in the following command is the temporary IP address that will be used to access VSM2 while the HA pair is split.
switch(config)# svs upgrade start mgmt0 ip ipaddr
WARNING!1. Please do not change the configuration of the system from this point 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
Step 6 Update the system and kickstart boot variables.
switch# install all system bootflash: nexus-1000v-mz.4.2.1.SV1.4.bin kickstart bootflash:nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin
System image sync to standby is in progress...
System image is synced to standby.
Kickstart image sync to Standby is in progress...
Kickstart image is synced to standby.
Upgrade in process, hence Active boot variables are not updated.
Boot variables are updated to running configuration.
Step 7 Copy the running configuration to the startup configuration and verify.
switch# copy running-config startup-config
[########################################] 100%switch# show start | in boot
boot kickstart bootflash:/nexus-1000v-kickstart-mzg.4.0.4.SV1.3b.bin sup-1
boot system bootflash:/nexus-1000v-mzg.4.0.4.SV1.3b.bin sup-1
boot kickstart bootflash:/nexus-1000v-kickstart-mzg.4.2.1.SV1.4.bin sup-2
boot system bootflash:/nexus-1000v-mzg.4.2.1.SV1.4.bin sup-2
Note The following commands display that the active VSM (sup-1) is still on Release 4.0(4)SV1(3b) and the standby VSM is now on Release 4.2(1)SV1(4).
Step 8 Reload the VSM whose boot variables are set to Release 4.2(1)SV1(4).
switch# reload module slot
This command will reboot standby supervisor module. (y/n)? [n] y
2010 June 14 20:11:51 av1-vsm %PLATFORM-2-PFM_MODULE_RESET: Manual restart of Module 2 from Command Line Interfaceswitch# 2010 Jun 14 20:11:58 av1-vsm %PLATFORM-2-MOD_REMOVE: Module 2 removed (Serial number T50569A5039
Step 9 Log in to VSM2 using the temporary IP address.
Step 10 Confirm that VSM2 is now standalone.
switch# show system redundancy status
Redundancy role
---------------
administrative: standalone
operational: standalone
Redundancy mode
---------------
administrative: HA
operational: None
This supervisor (sup1)
----------------------
Redundancy state: Active
Supervisor state: Active
Internal state: Active with no standby
Other supervisor (sup-2)
------------------------
Redundancy State: Not present
Step 11 On VSM1, running the pre-Release 4.2(1)SV1(4) image, remove the connection between it and the vCenter Server.
switch# show running-config
svs-domain
domain id 470
control vlan 233
packet vlan 233
svs mod L2
svs upgrade start mgmt0 ip 192.0.2.12
svs connection vc
protocol vmware-vimremote up address 192.0.2.10 port 80
vmware dvs uuid "0c bf 0e 50 0b 4a b7 76-88 13 be 45 14 e8 9b 4e" datacenter-name sachinDCconnectswitch# config t
switch# (config)# svs connection vc
switch# (config-svs-conn)# no connect
Step 12 Change VSM1's role to secondary.
switch(config-svs-conn)# end
switch(config)# end
switch# system redundancy role secondary
Setting will be activated on next reload
switch# show run | in boot
boot kickstart bootflash:/nexus-1000v-kickstart-mzg.4.0.4.SV1.3b.bin sup-1
boot system bootflash:/nexus-1000v-mzg.4.0.4.SV1.3b.bin sup-1
boot kickstart bootflash:/nexus-1000v-kickstart-mzg.4.2.1.SV1.4.bin sup-2
boot system bootflash:/nexus-1000v-mzg.4.2.1.SV1.4.bin sup-2
Step 13 Change the boot variables on VSM1 to point to the Release 4.2(1)SV1(4) images.
switch# config t
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)# boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin
switch(config)# no boot system bootflash:/nexus-1000v.mzg.4.0.4.SV1.3b.bin sup-1
switch(config)# boot system bootflash:/nexus-1000v-mz.4.2.1.SV1.4.bin sup-1
switch(config)# end
switch# show run | in boot
boot kickstart bootflash:/nexus-1000v-kickstart-mzg.4.2.1.SV1.4.bin sup-1
boot system bootflash:/nexus-1000v-mzg.4.2.1.SV1.4.bin sup-1
boot kickstart bootflash:/nexus-1000v-kickstart-mzg.4.2.1.SV1.4.bin sup-2
boot system bootflash:/nexus-1000v-mzg.4.2.1.SV1.4.bin sup-2
Step 14 Save the configuration on VSM1.
switch# copy running-config startup-config
[########################################] 100%
Step 15 Display the current connections on VSM2.
switch# config t
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)# show svs connect
connection vcenter:
ip address: 192.0.2.10
remote port: 80
protocol: vmware-vim https
certificate: default
datacenter name: n1000vDC
DVS uuid: 0c bf 0b 50 0b 4a b7 76-88 13 be 45 14 e8 9b 4e
config status: Enabled
operational status: Disconnected
sync status: -
version: -
Step 16 If you have L3 connectivity using control0 to connect to the VEMs, then continue with this step, otherwise move to Step 17.
a. Log in to the temporary IP address of the VSM or console of Release 4.2(1)SV1(4) VSM.
b. Check if there are sub-net or default routes associated with the control0 interface. This can be achieved by:
–Running the show running-config command
–Look for routes under vrf context management
vrf context 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.1VSM(config)# vrf context managementVSM(config-vrf)# no ip route 192.168.1.0/24 192.168.2.1
Caution Do not save the running configuration to the startup configuration until the upgrade procedure is complete.
Step 17 Log in to the temporary IP address of the VSM or console of Release 4.2(1)SV1(4) VSM and check if the module status is ok.
If the module status is not ok, refer to the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4). Do not proceed unless all modules are in status ok.
Step 18 Connect VSM2 to the vCenter Server.
Note Make sure that all the VEMs are attached to the Release 4.2(1)SV1(4) VSM. Verify by comparing the number of VEMs that were attached to the Release 4.0(4)SV1(3b) VSM match the number of VEMs that are attached to the Release 4.2(1)SV1(4) VSM. Check for module status = ok.
switch# config t
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)# svs upgrade complete
Warning: Config saved but not pushed to vCenter Server due to inactive connection!
switch(config)# end
switch# show run | in svs
svs-domain
svs mode L2
svs upgrade complete
svs connection vc
switch# config t
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)# svs connection name
switch(config-svs-conn)# connect
switch(config-svs-conn)# end
switch(config)# end
switch# show module
Mod Ports Module-Type Model Status--- ----- -------------------------------- ------------------ ------------1 0 Virtual Supervisor Module Nexus1000V active *3 248 Virtual Ethernet Module NA okMod Sw Hw--- --------------- ------1 4.2(1)SV1(3b) 0.03 4.2(1)SV1(4) 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 role to primary.
switch# system redundancy role primary
Step 20 Reload VSM1.
switch# show module
switch# show run int mgmt0
!Command: show running-config interface mgmt0
!Time: Mon Jun 14 20:27:27 2010
version 4.2(1)SV1(4)
interface mgmt0
ip address 192.0.2.11/24
switch(config)# show version
switch# reload
This command will reboot the system. (y/n)? [n] y
switch# copy running-config startup-config
switch# reload
Step 21 Change VSM2's mgmt0 IP address back to the shared IP address.
switch# show run int mgmt0
switch# config t
switch(config)# int mgmt0
switch(config-if)# ip address 192.0.2.11 255.255.255.0
Step 22 Confirm upgraded HA pair.
switch# show system redundancy status
Redundancy role---------------administrative: 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 standby
Accepting the VEM Upgrade in the vCenter Client
This section describes the steps that a server administrator follows to accept a VEM upgrade in the vCenter Client and includes the following topics:
•"Prerequisites to Accepting the VEM Upgrade" section
•"Accepting the VEM Upgrade" section
For details about how to upgrade the VEMs see "Upgrading the VEMs" section.
Prerequisites to Accepting the VEM Upgrade
The following are prerequisites to accepting a VEM upgrade:
•You are logged in to the CLI in EXEC mode.
•Network and server administrators are coordinating the upgrade procedure.
•The VSM upgrade has occurred before the VEM upgrade if you are upgrading from Release 4.0(4)SV1(1) or Release 4.0(4)SV1(2).
•You have received a notification in vCenter that a VEM software upgrade is available.
Accepting the VEM Upgrade
The server administrator accepts the VEM upgrade after the network administrator has upgraded the VSM and notified vCenter server of the availability of the new VEM software version.
To accept a request for a VEM upgrade, follow these steps:
Note This procedure is performed by the server administrator.
Step 1 Click the vSphere Client DVS Summary tab to check for the availability of a software upgrade (see Figure 34).
Figure 34 vSphere Client DVS Summary Tab
Step 2 Click Apply upgrade.
The following actions occur:
•The network administrator is notified that you are ready to apply the upgrade to the VEMs.
•The network administrator notifies vCenter to proceed with the VEM upgrades.
•If you are using VUM, vCenter locks the DVS and triggers VUM to upgrade the VEMs.
For details about the VEM upgrade performed by the network administrator, see the "Upgrading the VEMs" section.
Troubleshooting
This section provides some troubleshooting guidelines for problems that may occur during the Cisco Nexus 1000V upgrade process. This section includes the following topic:
•Non-default (Jumbo) MTU Settings Symptoms and Solutions
Non-default (Jumbo) MTU Settings Symptoms and Solutions
Available Documents
This section lists the documents used with the Cisco Nexus 1000V and available on Cisco.com at the following url:
http://www.cisco.com/en/US/products/ps9902/tsd_products_support_series_home.html
General Information
Cisco Nexus 1000V Documentation Roadmap, Release 4.2(1)SV1(4)
Cisco Nexus 1000V Release Notes, Release 4.2(1)SV1(4)
Cisco Nexus 1000V Compatibility Information, Release 4.2(1)SV1(4)
Cisco Nexus 1010 Management Software Release Notes, Release 4.2(1)SP1(2)
Install and Upgrade
Cisco Nexus 1000V Virtual Supervisor Module Software Installation Guide, Release 4.2(1)SV1(4)
Cisco Nexus 1000V Software Upgrade Guide, Release 4.2(1)SV1(4)
Cisco Nexus 1000V VEM Software Installation and Upgrade Guide, Release 4.2(1)SV1(4)
Cisco Nexus 1010 Virtual Services Appliance Hardware Installation Guide
Cisco Nexus 1010 Software Installation and Upgrade Guide, Release 4.2(1)SP1(2)
Configuration Guides
Cisco Nexus 1000V License Configuration Guide, Release 4.2(1)SV1(4)
Cisco Nexus 1000V Getting Started Guide, Release 4.2(1)SV1(4)
Cisco Nexus 1000V High Availability and Redundancy Configuration Guide, Release 4.2(1)SV1(4)
Cisco Nexus 1000V Interface Configuration Guide, Release 4.2(1)SV1(4)
Cisco Nexus 1000V Layer 2 Switching Configuration Guide, Release 4.2(1)SV1(4)
Cisco Nexus 1000V Port Profile Configuration Guide, Release 4.2(1)SV1(4)
Cisco Nexus 1000V Quality of Service Configuration Guide, Release 4.2(1)SV1(4)
Cisco Nexus 1000V Security Configuration Guide, Release 4.2(1)SV1(4)
Cisco Nexus 1000V System Management Configuration Guide, Release 4.2(1)SV1(4)
Cisco Nexus 1010 Software Configuration Guide, Release 4.2(1)SP1(2)
Programming Guide
Cisco Nexus 1000V XML API User Guide, Release 4.2(1)SV1(4)
Reference Guides
Cisco Nexus 1000V Command Reference, Release 4.2(1)SV1(4)
Cisco Nexus 1000V MIB Quick Reference
Cisco Nexus 1010 Command Reference, Release 4.2(1)SP1(2)
Troubleshooting and Alerts
Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(4)
Cisco Nexus 1000V Password Recovery Guide
Cisco NX-OS System Messages Reference
Virtual Security Gateway Documentation
Cisco Virtual Security Gateway for Nexus 1000V Series Switch Release Notes, Release 4.2(1)VSG(1)
Virtual Network Management Center
Release Notes for Cisco Virtual Network Management Center, Release 1.0.1
Cisco Virtual Network Management Center CLI Configuration Guide, Release 1.0.1
Cisco Virtual Network Management Center GUI Configuration Guide, Release 1.0.1
Cisco Virtual Network Management Center XML API Reference Guide, Release 1.0.1
Network Analysis Module Documentation
Cisco Network Analysis Module Software Documentation Guide, 4.2
Cisco Nexus 1000V NAM Virtual Service Blade Installation and Configuration Guide
Network Analysis Module Command Reference Guide, 4.2
User Guide for the Cisco Network Analysis Module Virtual Service Blades, 4.2
Cisco Network Analysis Module Software Release Notes, 4.2
Obtaining Documentation and Submitting a Service Request
For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:
http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html
Subscribe to the What's New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS Version 2.0.
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.
© 2011 Cisco Systems, Inc. All rights reserved.