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

Cisco Nexus 1000V Software Upgrade Guide, Release 4.0(4)SV1(3d) Revised: May 21, 2011 This document describes how to upgrade the Cisco Nexus 1000V software on a Virtual Supervisor Module (VSM) virtual machine (VM) and includes the following topics: Audience, page 1 Obtaining the Software, page 2 Information About the Software Upgrade, page 2 Upgrading the VSMs, page 4 Upgrading the VEMs, page 14 Changing the Feature Support Level, page 26 Accepting the VEM Upgrade in the vcenter Client, page 28 Troubleshooting, page 29 Available Documents, page 30 Obtaining Documentation and Submitting a Service Request, page 31 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 Americas Headquarters: Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA

Obtaining the Software VMware Update Manager Cisco Nexus 1000V DVS setup and implementation For more information about Cisco Nexus 1000V setup and implementation, see the Cisco Nexus 1000V Getting Started Guide, Release 4.0(4)SV1(3). Obtaining the Software Table 1 You can obtain your upgrade-related software from the following sources (Table 1): Obtaining Software Source Cisco VMware Description Download the Cisco Nexus 1000V Release 4.0(4)SV1(3d) software from the Cisco website. Download VMware software from VMware website. For information about your software and platform compatibility, see the Cisco Nexus 1000V Compatibility Information, Release 4.0(4)SV1(3d). Information About the Software Upgrade You cannot upgrade from Release 4.2(1)SV1(4) to Release 4.0(4)SV1(3d). Caution If the VMware vcenter Server is hosted on the same ESX host as a Cisco Nexus 1000V VEM, then a VUM assisted upgrade on the host will fail. You should manually vmotion the VM to another host before performing the upgrade. This section provides information about the software upgrade. A software upgrade consists of adding a new software version first to the Cisco Nexus 1000V VSM and then to its Virtual Ethernet Modules (VEMs). The sequence to upgrade the software is as follows: Upgrading the VSMs, page 4 Upgrading the VEMs, page 14 This section describes important points about the software upgrade: There are two methods of upgrading the software: the non-disruptive method and the disruptive method. An upgrade is non-disruptive or disruptive based on the version of your setup and also the method that you choose for upgrading. An ESX is termed as going through an upgrade when it is connected to a VSM during the upgrade procedure. An automated upgrade is traffic non-disruptive when you install one of the following: VMware patch ESX400/ESXi400-201002001 or the ESX400/ESXi400-201006201-UG or later on the host, and also use VMware vcenter Update Manager 4.0 Update 1 Patch 2, vcli build 198790, and VSM Release 4.0(4)SV1(2) or later. 2

Information About the Software Upgrade Even if your ESX/ESXi host has patches greater than ESX/ESXi400-201002001, without installing ESX/ESXi400-201002001 or ESX400/ESXi400-201006201-UG, a non-disruptive upgrade is not supported. Any ESX patches or updates after ESX400/ESXi400-201006201-UG will be backward compatible with the Cisco Nexus 1000V U2 VEM vib (cross_cisco-vem_v121-4.0.4.1.3.1.0-1.20.2.vib). VMware release ESX410/ESXi410 on the host, and also use VMware vcenter Update Manager 4.1 and VSM Release 4.0(4)SV1(3). A manual upgrade is traffic non-disruptive when the following conditions are met: While each vsphere host is attached to the Distributed virtual switch (DVS), migrate any running VMs to another host within the cluster. (As the VSM Release 4.0(4)SV1(1) cannot be Vmotioned, it must be powered off.) Place the host in maintenance mode and upgrade the VEMs. Follow the same method for other hosts in the data center. For details about how to determine what patch level you are using, refer to the Cisco Nexus 1000V Compatibility Information, Release 4.0(4)SV1(3d). Cisco does not support simultaneous VMware updates or patches in combination with Nexus 1000V upgrades. This document is designed specifically for Nexus 1000V upgrades across the same VMware platform. The upgrade process is irrevocable. After the software is upgraded, you can downgrade by removing the current installation and reinstalling the software. For details, see the "Recreating the Installation" section in the following document: Cisco Nexus 1000V Troubleshooting Guide, Release 4.0(4)SV1(3). Caution During the upgrade process, the Cisco Nexus 1000V does not support new additions of any vnics, vmnics, or new modules and does not support any configuration changes. vnic port-profile changes might render the vnic in an unusable state. If you are using a proxy server to connect the VMware Update Manager (VUM) to the Internet, you may need to disable the proxy before starting a VUM upgrade of your VEMs. In VMware versions before the VUM Update 1, the proxy prevents the VUM from communicating locally with the VSM. Therefore, automatic VEM upgrades may fail if the proxy is not disabled first. When you upgrade from Release 4.0(4)SV1(3) or Release 4.0(4)SV1(3a) to Release 4.0(4)SV1(3d), licenses apply as follows: On a Release 4.0(4)SV1(3) or Release 4.0(4)SV1(3a) VSM, you can install evaluation license files. If these evaluation licenses have not yet expired prior to the upgrade to Release 4.0(4)SV1(3d), these will be carried over after the upgrade to Release 4.0(4)SV1(3d) as is. The Release 4.0(4)SV1(3) or Release 4.0(4)SV1(3a) VSM has support for default/built-in evaluation licenses for 16 CPU sockets for a period of 60 days. If these default/built-in evaluation licenses have not yet expired before the upgrade to Release 4.0(4)SV1(3d), these will be carried over after upgrade to Release 4.0(4)SV1(3d) as is. 3

Upgrading the VSMs Any permanent licenses installed on a Release 4.0(4)SV1(3) or Release 4.0(4)SV1(3a) VSM will be carried over after upgrade to Release 4.0(4)SV1(3d) as is. When you upgrade from Release 4.0(4)SV1(2) to Release 4.0(4)SV1(3d), licenses apply as follows: On a Release 4.0(4)SV1(2) VSM, you cannot install evaluation license files. The Release 4.0(4)SV1(2) VSM has support for default/built-in evaluation licenses for 16 CPU sockets for a period of 60 days. If these default/built-in evaluation licenses have not yet expired before the upgrade to Release 4.0(4)SV1(3d), these will be carried over after upgrade to Release 4.0(4)SV1(3d) as is. Any permanent licenses installed on a Release 4.0(4)SV1(2) VSM will be carried over after upgrade to Release 4.0(4)SV1(3d) as is. When you upgrade from Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d), licenses apply as follows: On a Release 4.0(4)SV1(1) VSM, you can install evaluation license files. If these evaluation licenses have not yet expired prior to the upgrade to Release 4.0(4)SV1(3d), these will be carried over after the upgrade to Release 4.0(4)SV1(3d) as is. Any permanent licenses installed on a Release 4.0(4)SV1(1) VSM will be carried over after upgrade to Release 4.0(4)SV1(3d) as is. For more licensing details, see the Cisco Nexus 1000V License Configuration Guide, Release 4.0(4)SV1(3). Upgrading the VSMs This section describes the VSM upgrade steps. The following upgrade methods are described in the following topics: Prerequisites to Upgrading the VSMs, page 4 Upgrading the VSM from Release 4.0(4)SV1(2, 3, 3a, 3b, or 3c) to Release 4.0(4)SV1(3d), page 5 Upgrading the VSM from Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d), page 10 Prerequisites to Upgrading the VSMs The following are prerequisites to upgrading the VSM: You are upgrading the Cisco Nexus 1000V software to Release 4.0(4)SV1(3d). Network and server administrators coordinate the upgrade procedure with each other. The following files are available in external storage that you can access from the VSM. nexus-1000v-mz.4.0.4.sv1.3d.bin nexus-1000v-kickstart-mz.4.0.4.sv1.3d.bin You have saved all changes in the running configuration to the startup configuration to be preserved through the upgrade. You have saved a backup copy of the running configuration in external storage. For information about backing up a configuration file, see the Cisco Nexus 1000V System Management Configuration Guide, Release 4.0(4)SV1(3). 4

Upgrading the VSMs Upgrading the VSM from Release 4.0(4)SV1(2, 3, 3a, 3b, or 3c) to Release 4.0(4)SV1(3d) This section describes the VSM upgrade to Release 4.0(4)SV1(3d). For example purposes, the following procedure reflects an upgrade from Release 4.0(4)SV1(3) to Release 4.0(4)SV1(3d). This procedure is performed by the network administrator. To perform a VSM software upgrade to Release 4.0(4)SV1(3d), follow these steps: Step 1 Copy the new software release system image and kickstart image files to the bootflash file system of the active VSM. switch# dir bootflash: 154 Jan 27 15:21:06 2010.ovfconfigured 77824 Mar 03 07:31:09 2010 accounting.log 16384 Dec 09 13:56:23 2009 lost+found/ 21408768 Dec 09 13:57:21 2009 nexus-1000v-kickstart-mz.4.0.4.sv1.3.bin 73068811 Dec 09 13:57:32 2009 nexus-1000v-mz.4.0.4.sv1.3.bin 4096 Dec 09 13:58:18 2009 vdc_2/ 4096 Dec 09 13:58:18 2009 vdc_3/ 4096 Dec 09 13:58:18 2009 vdc_4/ Usage for bootflash://sup-local 249647552 bytes used 2138623552 bytes free 2388271104 bytes total switch# copy scp://root@10.78.27.167/n1k-vsm-images/nexus-1000v-mz.4.0.4.sv1.3d.bin bootflash: Enter vrf (If no input, current vrf 'default' is considered): root@10.78.27.167's password: nexus-1000v-mz.4.0.4.sv1.3d.bin 100% 20MB 1.1MB/s 00:19 switch# switch# copy scp://root@10.78.27.167/n1k-vsm-images/nexus-1000v-kickstart-mz.4.0.4.sv1.3d.bin bootflash: Enter vrf (If no input, current vrf 'default' is considered): root@10.78.27.167's password: nexus-1000v-kickstart-mz.4.0.4.sv1.3d.bin 100% 20MB 1.1MB/s 00:19 switch# switch# dir bootflash: 154 Jan 27 15:21:06 2010.ovfconfigured 77824 Mar 03 07:31:09 2010 accounting.log 16384 Dec 09 13:56:23 2009 lost+found/ 21408768 Dec 09 13:57:21 2009 nexus-1000v-kickstart-mz.4.0.4.sv1.3.bin 21982208 Jul 08 18:28:58 2010 nexus-1000v-kickstart-mz.4.0.4.sv1.3d.bin 73068811 Dec 09 13:57:32 2009 nexus-1000v-mz.4.0.4.sv1.3.bin 62280256 Jul 08 18:29:35 2010 nexus-1000v-mz.4.0.4.sv1.3d.bin 4096 Dec 09 13:58:18 2009 vdc_2/ 5

Upgrading the VSMs 4096 Dec 09 13:58:18 2009 vdc_3/ 4096 Dec 09 13:58:18 2009 vdc_4/ Usage for bootflash://sup-local 333910016 bytes used 2054361088 bytes free 2388271104 bytes total Step 2 Use the install all command to copy the Release 4.0(4)SV1(3d) images to both active and standby VSMs and to update the boot variables. If available, you can obtain the software images from an outside repository and copy it using the install all command. switch# install all system bootflash:nexus-1000v-mz.4.0.4.sv1.3d.bin kickstart bootflash:nexus-1000v-kickstart-mz.4.0.4.sv1.3d.bin System image sync to standby is in progress... System image is synced to standby. Kickstart image sync to Standby is in progress... Kickstart image is synced to standby. Boot variables are updated to running configuration. Step 3 Step 4 Save your configuration by copying the running configuration to the startup configuration. switch# copy r s [########################################] 100% Verify that your configuration is saved. switch# show startup-config include boot boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.sv1.3d.bin sup-1 boot system bootflash:/nexus-1000v-mz.4.0.4.sv1.3d.bin sup-1 boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.sv1.3d.bin sup-2 boot system bootflash:/nexus-1000v-mz.4.0.4.sv1.3d.bin sup-2 switch# show running-config include boot boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.sv1.3d.bin sup-1 boot system bootflash:/nexus-1000v-mz.4.0.4.sv1.3d.bin sup-1 boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.sv1.3d.bin sup-2 boot system bootflash:/nexus-1000v-mz.4.0.4.sv1.3d.bin sup-2 Step 5 Verify the VSM active and standby module status. switch# show mod Mod Ports Module-Type Model Status --- ----- -------------------------------- ------------------ ------------ 1 0 Virtual Supervisor Module Nexus1000V active * 2 0 Virtual Supervisor Module Nexus1000V ha-standby 3 248 Virtual Ethernet Module NA ok 4 248 Virtual Ethernet Module NA ok Mod Sw Hw --- --------------- ------ 1 4.0(4)SV1(3) 0.0 2 4.0(4)SV1(3) 0.0 3 4.0(4)SV1(3) 1.11 4 4.0(4)SV1(3) 1.11 Mod MAC-Address(es) Serial-Num --- -------------------------------------- ---------- 1 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA 2 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA 6

Upgrading the VSMs 3 02-00-0c-00-03-00 to 02-00-0c-00-03-80 NA 4 02-00-0c-00-04-00 to 02-00-0c-00-04-80 NA Mod Server-IP Server-UUID Server-Name --- --------------- ------------------------------------ -------------------- 1 10.78.109.100 NA NA 2 10.78.109.100 NA NA 3 10.78.109.104 1ee15784-f2e8-383e-8132-9026577ca1bb 10.78.109.104 4 10.78.109.102 44454c4c-4700-104e-804d-cac04f563153 10.78.109.102 The line with the bold characters in the preceding example displays that the VSM module 2 is at Release 4.0(4)SV1(3). Step 6 Reload the standby VSM. Use module 2 in the following example because module 2 is the standby module. After reloading the standby VSM, the active VSM that is running software release 4.0(4)SV1(3), synchronizes with the standby VSM running Release 4.0(4)SV1(3d). switch# reload module 2 This command will reboot standby supervisor module. (y/n)? [n] y about to reset standby sup switch# 2010 Jul 08 09:57:42 n1000v %PLATFORM-2-PFM_MODULE_RESET: Manual restart of Module 2 from Command Line Interface 2010 Jul 08 09:57:49 n1000v %PLATFORM-2-MOD_REMOVE: Module 2 removed (Serial number T5056972D88) 2010 Jul 08 09:57:53 n1000v %(0x436D) for service "netstack" (PID 3176): Connection timed out (110). A few sequence failures might be displayed with the preceding message. This is expected and you can ignore it. Step 7 Verify the VSM active and standby module status and software release version. switch# show mod Mod Ports Module-Type Model Status --- ----- -------------------------------- ------------------ ------------ 1 0 Virtual Supervisor Module Nexus1000V active * 2 0 Virtual Supervisor Module Nexus1000V ha-standby 3 248 Virtual Ethernet Module NA ok 4 248 Virtual Ethernet Module NA ok Mod Sw Hw --- --------------- ------ 1 4.0(4)SV1(3) 0.0 2 4.0(4)SV1(3d) 0.0 3 4.0(4)SV1(3) 1.11 4 4.0(4)SV1(3) 1.11 Mod MAC-Address(es) Serial-Num --- -------------------------------------- ---------- 1 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA 2 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA 3 02-00-0c-00-03-00 to 02-00-0c-00-03-80 NA 4 02-00-0c-00-04-00 to 02-00-0c-00-04-80 NA Mod Server-IP Server-UUID Server-Name --- --------------- ------------------------------------ -------------------- 1 10.78.109.100 NA NA 2 10.78.109.100 NA NA 7

Upgrading the VSMs 3 10.78.109.104 1ee15784-f2e8-383e-8132-9026577ca1bb 10.78.109.104 4 10.78.109.102 44454c4c-4700-104e-804d-cac04f563153 10.78.109.102 * this terminal session The lines with the bold characters in the preceding example, after the reload, display the active and standby modules and that VSM module 2, the standby module, is upgraded to Release 4.0(4)SV1(3d). Step 8 Step 9 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. Verify the system switchover. In the following example, module 2 is the active module and module 1 is now the standby module. switch# show mod Mod Ports Module-Type Model Status --- ----- -------------------------------- ------------------ ------------ 1 0 Virtual Supervisor Module Nexus1000V ha-standby 2 0 Virtual Supervisor Module Nexus1000V active * 3 248 Virtual Ethernet Module NA ok 4 248 Virtual Ethernet Module NA ok Mod Sw Hw --- --------------- ------ 1 4.0(4)SV1(3d) 0.0 2 4.0(4)SV1(3d) 0.0 3 4.0(4)SV1(3) 1.11 4 4.0(4)SV1(3) 1.11 Mod MAC-Address(es) Serial-Num --- -------------------------------------- ---------- 1 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA 2 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA 3 02-00-0c-00-03-00 to 02-00-0c-00-03-80 NA 4 02-00-0c-00-04-00 to 02-00-0c-00-04-80 NA Mod Server-IP Server-UUID Server-Name --- --------------- ------------------------------------ -------------------- 1 10.78.109.100 NA NA 2 10.78.109.100 NA NA 3 10.78.109.104 1ee15784-f2e8-383e-8132-9026577ca1bb 10.78.109.104 4 10.78.109.102 44454c4c-4700-104e-804d-cac04f563153 10.78.109.102 * this terminal session The line with the bold characters in the preceding example displays that the VSM module 1 is upgraded to Release 4.0(4)SV1(3d). To change to the original status of module 1 as the active module and module 2 as the standby module, use the system switchover command one more time. Step 10 Step 11 (Optional) If you have configured non-default (jumbo) MTU settings, see the Non-default (Jumbo) MTU Settings Symptoms and Solutions section on page 30 before proceeding with VEM upgrades. Proceed to upgrade the VEMs. 8

For details, see the Upgrading the VEMs section on page 14. Upgrading the VSMs 9

Upgrading the VSMs Upgrading the VSM from Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d) This section describes the VSM upgrade from Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d). To perform a VSM software upgrade from Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d), follow these steps: This procedure is performed by the network administrator. Step 1 Step 2 Power off all VMs except the VSM. Copy the new software release system image and kickstart image files to the bootflash file system of the active VSM. switch# dir bootflash: 154 Jan 27 15:21:06 2010.ovfconfigured 77824 Mar 03 07:31:09 2010 accounting.log 16384 Dec 09 13:56:23 2009 lost+found/ 21408768 Dec 09 13:57:21 2009 nexus-1000v-kickstart-mz.4.0.4.sv1.1.bin 73068811 Dec 09 13:57:32 2009 nexus-1000v-mz.4.0.4.sv1.1.bin 4096 Dec 09 13:58:18 2009 vdc_2/ 4096 Dec 09 13:58:18 2009 vdc_3/ 4096 Dec 09 13:58:18 2009 vdc_4/ Usage for bootflash://sup-local 249647552 bytes used 2138623552 bytes free 2388271104 bytes total switch#copy scp://root@10.78.27.167/n1k-vsm-images/nexus-1000v-mz.4.0.4.sv1.3d.bin bootflash: Enter vrf (If no input, current vrf 'default' is considered): root@10.78.27.167's password: nexus-1000v-mz.4.0.4.sv1.3d.bin 100% 20MB 1.1MB/s 00:19 switch# switch# copy scp://root@10.78.27.167/n1k-vsm-images/nexus-1000v-kickstart-mz.4.0.4.sv1.3d.bin bootflash: Enter vrf (If no input, current vrf 'default' is considered): root@10.78.27.167's password: nexus-1000v-kickstart-mz.4.0.4.sv1.3d.bin 100% 20MB 1.1MB/s 00:19 switch# switch# dir bootflash: 154 Jan 27 15:21:06 2010.ovfconfigured 77824 Mar 03 07:31:09 2010 accounting.log 16384 Dec 09 13:56:23 2009 lost+found/ 21408768 Dec 09 13:57:21 2009 nexus-1000v-kickstart-mz.4.0.4.sv1.1.bin 21982208 Jan 21 18:28:58 2010 nexus-1000v-kickstart-mz.4.0.4.sv1.3d.bin 73068811 Dec 09 13:57:32 2009 nexus-1000v-mz.4.0.4.sv1.1.bin 62280256 Jan 21 18:29:35 2010 nexus-1000v-mz.4.0.4.sv1.3d.bin 4096 Dec 09 13:58:18 2009 vdc_2/ 4096 Dec 09 13:58:18 2009 vdc_3/ 4096 Dec 09 13:58:18 2009 vdc_4/ Usage for bootflash://sup-local 333910016 bytes used 10

Upgrading the VSMs 2054361088 bytes free 2388271104 bytes total Step 3 Step 4 Remove the existing system boot variable and kickstart boot variable. switch# config t switch(config)# no boot system switch(config)# no boot kickstart switch(config)# Add the new system boot variable and kickstart boot variable. switch(config)# boot system bootflash:nexus-1000v-mzg.4.0.4.sv1.3d.bin 2009 Dec 13 15:50:40.568 n1k-av %BOOTVAR-5-IMAGE_NOTEXISTS: Warning: image nexus-1000v-mz.4.0.4.sv1.3d.bin doesn't exist on sup2 2009 Dec 13 15:51:28.236 n1k-av %BOOTVAR-5-AUTOCOPY_SUCCEED: auto-copy of file /bootflash/nexus-1000v-mz.4.0.4.sv1.3d.bin to standby supervisor succeed switch(config)# switch(config)# boot kickstart bootflash:nexus-1000v-kickstart-mzg.4.0.4.sv1.3d.bin 2009 Dec 13 15:54:03.093 n1k-av %BOOTVAR-5-IMAGE_NOTEXISTS: Warning: image nexus-1000v-kickstart-mz.4.0.4.sv1.3d.bin doesn't exist on sup2 2009 Dec 13 15:54:20.966 n1k-av %BOOTVAR-5-AUTOCOPY_SUCCEED: auto-copy of file /bootflash/nexus-1000v-kickstart-mz.4.0.4.sv1.3d.bin to standby supervisor succeed switch(config)# 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 Step 5 Step 6 If you are upgrading dual VSMs, then before you reload the software, make sure that the bootflash file system for the standby VSM has system and kickstart image files that are identical to those in the active VSM. If they are not identical, then the only way to recover the standby VSM is to create a new one from the ISO image and point it to the active VSM. 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)# Verify that your configuration is saved. switch# show startup-config include boot boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.sv1.3d.bin sup-1 boot system bootflash:/nexus-1000v-mz.4.0.4.sv1.3d.bin sup-1 boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.sv1.3d.bin sup-2 boot system bootflash:/nexus-1000v-mz.4.0.4.sv1.3d.bin sup-2 switch# show running-config include boot boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.sv1.3d.bin sup-1 boot system bootflash:/nexus-1000v-mz.4.0.4.sv1.3d.bin sup-1 boot kickstart bootflash:/nexus-1000v-kickstart-mz.4.0.4.sv1.3d.bin sup-2 boot system bootflash:/nexus-1000v-mz.4.0.4.sv1.3d.bin sup-2 Step 7 Verify the VSM active and standby module status. switch# show mod Mod Ports Module-Type Model Status --- ----- -------------------------------- ------------------ ------------ 11

Upgrading the VSMs 1 0 Virtual Supervisor Module Nexus1000V active * 2 0 Virtual Supervisor Module Nexus1000V ha-standby 3 248 Virtual Ethernet Module NA ok 4 248 Virtual Ethernet Module NA ok Mod Sw Hw --- --------------- ------ 1 4.0(4)SV1(1) 0.0 2 4.0(4)SV1(1) 0.0 3 4.0(4)SV1(1) 1.11 4 4.0(4)SV1(1) 1.11 Mod MAC-Address(es) Serial-Num --- -------------------------------------- ---------- 1 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA 2 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA 3 02-00-0c-00-03-00 to 02-00-0c-00-03-80 NA 4 02-00-0c-00-04-00 to 02-00-0c-00-04-80 NA Mod Server-IP Server-UUID Server-Name --- --------------- ------------------------------------ -------------------- 1 10.78.109.100 NA NA 2 10.78.109.100 NA NA 3 10.78.109.104 1ee15784-f2e8-383e-8132-9026577ca1bb 10.78.109.104 4 10.78.109.102 44454c4c-4700-104e-804d-cac04f563153 10.78.109.102 The lines with the bold characters in the preceding example display that VSM modules 1 and 2 are at Release 4.0(4)SV1(1). Step 8 Step 9 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. Verify that the VSMs are upgraded. switch# show mod Mod Ports Module-Type Model Status --- ----- -------------------------------- ------------------ ------------ 1 0 Virtual Supervisor Module Nexus1000V active * 2 0 Virtual Supervisor Module Nexus1000V ha-standby 3 248 Virtual Ethernet Module NA ok 4 248 Virtual Ethernet Module NA ok Mod Sw Hw --- --------------- ------ 1 4.0(4)SV1(3d) 0.0 2 4.0(4)SV1(3d) 0.0 3 4.0(4)SV1(1) 1.11 4 4.0(4)SV1(1) 1.11 Mod MAC-Address(es) Serial-Num --- -------------------------------------- ---------- 1 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA 2 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA 3 02-00-0c-00-03-00 to 02-00-0c-00-03-80 NA 4 02-00-0c-00-04-00 to 02-00-0c-00-04-80 NA Mod Server-IP Server-UUID Server-Name 12

Upgrading the VSMs --- --------------- ------------------------------------ -------------------- 1 10.78.109.100 NA NA 2 10.78.109.100 NA NA 3 10.78.109.104 1ee15784-f2e8-383e-8132-9026577ca1bb 10.78.109.104 4 10.78.109.102 44454c4c-4700-104e-804d-cac04f563153 10.78.109.102 * this terminal session The lines with the bold characters in the preceding example display that VSM modules 1 and 2 are upgraded to Release 4.0(4)SV1(3d). Step 10 Step 11 (Optional) If you have configured non-default (jumbo) MTU settings, see the Non-default (Jumbo) MTU Settings Symptoms and Solutions section on page 30 before proceeding with VEM upgrades. Proceed to upgrade the VEMs. For details, see the Upgrading the VEMs section on page 14. 13

Upgrading the VEMs Upgrading the VEMs This section lists important points about the VEM upgrade and describes the VEM upgrade process including the following topics: Prerequisites to Upgrading VEMs, page 15 Upgrading the VEMs from Release 4.0(2)SV1(2) or Release 4.0(2)SV1(3) to Release 4.0(4)SV1(3d), page 15 Upgrading the VEMs from Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d), page 21 Before upgrading the VEMs, note the following important points: The VEM upgrade starts when it is attached to the VSM. During the upgrade process, VEMs re-attach to the VSM. VEM software can be upgraded manually using the CLI, or upgraded automatically using VUM. VSM software can control and configure older VEM versions while continuing to support all features in the previous software version. To achieve a non-disruptive manual VEM upgrade, from Release 4.0(4)SV1(2) to 4.2(1)SV1(4), the user must vmotion the VMs out of the host that is to be upgraded, and then perform the VEM upgrade. If you are using VUM with the compatible ESX version as shown in the Cisco Nexus 1000V Compatibility Information, Release 4.0(4)SV1(3d) document, the host is automatically put in maintenance mode. An automated upgrade is traffic non-disruptive when you install one of the following: VMware patch ESX/ESXi400-201002001 or the ESX/ESXi400-201006201-UG on the host, and also use VMware vcenter Update Manager 4.0 Update 1 Patch 2, vcli build 198790, and VSM Release 4.0(4)SV1(2) or later. Even if your ESX/ESXi host has patches greater than ESX/ESXi400-201002001, without installing ESX/ESXi400-201002001, a non-disruptive upgrade is not supported. VMware release ESX/ESXi410 on the host, VMware vcenter Update Manager 4.1, and VSM Release 4.0(4)SV1(3). Connectivity to the VSM can be lost during a VEM upgrade when the interfaces of a VSM VM connect to its own DVS. Connectivity between an active and standby VSM can be lost during a VEM upgrade when the VEM being upgraded provides interface connectivity to one of the VSMs. In this case, both VSMs become active and lose connectivity. To prevent this, use the following workaround: Before upgrading the VEM, power off the VSM provided with interface connectivity. The other VSM should be active. If you power off the active VSM, then the standby VSM will become active. Manually upgrade the VEM providing the interface connectivity. Restart the VSM that was shut down. If you are upgrading VEM using a Cisco Nexus 1000V bundle, follow instructions in your VMware documentation. For more details about VMware bundled software, see the Cisco Nexus 1000V Compatibility Information, Release 4.0(4)SV1(3d). 14

Upgrading the VEMs Caution Do not type the vemlog, vemcmd, or vempkt commands during the VEM upgrade process as it may impact the upgrade. Prerequisites to Upgrading VEMs The following are prerequisites to upgrading the VEMs: You are logged in to the VSM CLI in EXEC mode. You have already upgraded the VSM to the new software version. Network and server administrators coordinate the VEM upgrade with each other. Refer to Cisco Nexus 1000V Compatibility Information, Release 4.0(4)SV1(3d) for compatible versions of the VMware vcenter and VUM software. Upgrading the VEMs from Release 4.0(2)SV1(2) or Release 4.0(2)SV1(3) to Release 4.0(4)SV1(3d) This section describes the steps to upgrade VEMs to Release 4.0(4)SV1(3d) and includes the following topics: Upgrading the VEMs Using VMware Update Manager (VUM) to Release 4.0(4)SV1(3d), page 15 Upgrading the VEMs Manually to Release 4.0(4)SV1(3d), page 18 Upgrading the VEMs Using VMware Update Manager (VUM) to Release 4.0(4)SV1(3d) To upgrade the VEMs using VUM, follow these steps: For example purposes, the following procedure reflects an upgrade from Release 4.0(4)SV1(3) to Release 4.0(4)SV1(3d). This procedure is performed by the network administrator. Step 1 Step 2 Step 3 Power off the VMs if you are running ESX/ESXi with VMware software release prior to patch ESX400/ESXi400-201002001. If you are running ESX/ESXi with host maintenance mode, then you do not have to power off the VMs, because ESX will be placed in maintenance mode for the upgrade which in turn will Vmotion the VMs to another host. 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. Verify that the upgrade notification was sent. 15

Upgrading the VEMs switch (config)# show vmware vem upgrade status Upgrade Status: Upgrade Availability Notified in vcenter Upgrade Notification Sent Time: Sun May 9 22:04:54 2010 Upgrade Status Time(vCenter): Upgrade Start Time: Upgrade End Time(vCenter): DVS: VEM400-201003101-BG Step 4 Step 5 The value of the DVS output will change depending on the vcenter version. Verify that the server administrator has accepted the upgrade in vcenter. For details about how the server administrator accepts the VEM upgrade, see the Accepting the VEM Upgrade in the vcenter Client section on page 28. Coordinate the notification acceptance with the server administrator, and after the server administrator accepts the upgrade, proceed with the VEM upgrade. switch# show vmware vem upgrade status Upgrade Status: Upgrade Accepted by vcenter Admin Upgrade Notification Sent Time: Sun May 9 22:04:54 2010 Upgrade Status Time(vCenter): Tue May 11 07:42:32 2010 Upgrade Start Time: Upgrade End Time(vCenter): DVS: VEM400-201003101-BG Initiate the VUM upgrade process. vcenter locks the DVS and triggers VUM to upgrade the VEMs. Caution Before entering the following command, communicate with the server administrator to confirm that the VUM process is operational. You must enter the following command in order to update the Cisco Nexus 1000V Bundle ID on the VCenter server. switch# vmware vem upgrade proceed switch# show vmware vem upgrade status Upgrade Status: Upgrade In Progress in vcenter Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010 Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010 Upgrade Start Time: Wed Mar 17 15:20:06 2010 Upgrade End Time(vCenter): DVS: VEM400-201010100-BG 16

Upgrading the VEMs Step 6 Step 7 Step 8 If the ESX/ESXi host is using VMware patch ESX400/ESXi400-201002001 or ESX410/ESXi410, and if your DRS settings are enabled to allow it, VUM automatically Vmotions the VMs from the host to another host in the cluster and places the ESX/ESXi in maintenance mode to upgrade the VEM. This process is continued for other hosts in the DRS cluster until all the hosts are upgraded in the cluster. Check for the Upgrade Complete status. switch# show vmware vem upgrade status Upgrade Status: Upgrade Complete in vcenter Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010 Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010 Upgrade Start Time: Wed Mar 17 15:20:06 2010 Upgrade End Time(vCenter): Wed Mar 17 17:30:48 2010 DVS: VEM400-201010100-BG Clear the VEM upgrade status after the upgrade process is complete. switch# vmware vem upgrade complete switch# show vmware vem upgrade status Upgrade Status: Upgrade Notification Sent Time: Upgrade Status Time(vCenter): Upgrade Start Time: Upgrade End Time(vCenter): DVS: VEM400-201010100-BG Verify that the upgrade process is complete. switch# show mod Mod Ports Module-Type Model Status --- ----- -------------------------------- ------------------ ------------ 1 0 Virtual Supervisor Module Nexus1000V ha-standby 2 0 Virtual Supervisor Module Nexus1000V active * 3 248 Virtual Ethernet Module NA ok 4 248 Virtual Ethernet Module NA ok Mod Sw Hw --- --------------- ------ 1 4.0(4)SV1(3d) 0.0 2 4.0(4)SV1(3d) 0.0 3 4.0(4)SV1(3d) 1.11 4 4.0(4)SV1(3d) 1.11 Mod MAC-Address(es) Serial-Num --- -------------------------------------- ---------- 1 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA 2 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA 3 02-00-0c-00-03-00 to 02-00-0c-00-03-80 NA 4 02-00-0c-00-04-00 to 02-00-0c-00-04-80 NA Mod Server-IP Server-UUID Server-Name --- --------------- ------------------------------------ -------------------- 1 10.78.109.100 NA NA 2 10.78.109.100 NA NA 17

Upgrading the VEMs 3 10.78.109.104 1ee15784-f2e8-383e-8132-9026577ca1bb 10.78.109.104 4 10.78.109.102 44454c4c-4700-104e-804d-cac04f563153 10.78.109.102 * this terminal session The line with the bold characters in the preceding example display that all VSMs and VEMs are upgraded to Release 4.0(4)SV1(3d). Step 9 Step 10 Determine if changing the Feature Support Level is required: If you are upgrading from Release 4.0(4)SV1(3), you have completed this procedure. If you are upgrading from Release 4.0(4)SV1(2), continue to Step 10. (Optional) Change the feature support level to enable the VSM to support all the new features in the new software version. See the Changing the Feature Support Level section on page 26 for more details. Upgrading the VEMs Manually to Release 4.0(4)SV1(3d) The manual upgrade of VEMs involves the Cisco Nexus 1000V using either VMware ESX commands, which are available on the host ESX CLI, or using the VMware vcli commands. For further details, see the Cisco Nexus 1000V VEM Software Installation and Upgrade Guide, Release 4.0(4)SV1(3d). To upgrade the VEMs manually, follow these steps: This procedure is performed by the network administrator. Step 1 Step 2 Step 3 Vmotion or power off the VMs if you are running ESX/ESXi with VMware software release prior to patch ESX400/ESXi400-201002001. If you are running ESX/ESXi with VMware patch ESX400/ESXi400-201002001, then you do not need to power off the VMs. However, the host must be manually placed in maintenance mode before the VEM upgrade. Coordinate with and notify the server administrator of the VEM upgrade process. switch (config)# vmware vem upgrade notify vmware vem upgrade notify Warning: Please ensure the hosts are running compatible ESX versions for the upgrade. Refer to corresponding "Cisco Nexus 1000V and VMware Compatibility Information" guide. Verify that the upgrade notification was sent. switch (config)# show vmware vem upgrade status Upgrade Status: Upgrade Availability Notified in vcenter Upgrade Notification Sent Time: Sun May 9 22:04:54 2010 Upgrade Status Time(vCenter): Upgrade Start Time: Upgrade End Time(vCenter): DVS: VEM400-201003191-BG 18

Upgrading the VEMs Step 4 Step 5 Verify that the server administrator has accepted the upgrade in vcenter Server. For details about the server administrator accepting the VEM upgrade, see the Accepting the VEM Upgrade in the vcenter Client section on page 28. After the server administrator accepts the upgrade, proceed with the VEM upgrade. switch# show vmware vem upgrade status Upgrade Status: Upgrade Accepted by vcenter Admin Upgrade Notification Sent Time: Sun May 9 22:04:54 2010 Upgrade Status Time(vCenter): Tue May 11 07:42:32 2010 Upgrade Start Time: Upgrade End Time(vCenter): DVS: VEM400-201003191-BG Initiate the manual upgrade process. If VUM is enabled in the vcenter environment, disable it before entering the vmware vem upgrade proceed command to prevent the new VIBs from being pushed to all the hosts. Enter the vmware vem upgrade proceed command so that the Cisco Nexus 1000V Bundle ID on the vcenter Server gets updated. If VUM is enabled and you do not update the Bundle ID, an incorrect VIB version is pushed to the VEM when you next add the ESX to VSM. switch# vmware vem upgrade proceed switch# show vmware vem upgrade status Upgrade Status: Upgrade In Progress in vcenter Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010 Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010 Upgrade Start Time: Wed Mar 17 15:20:06 2010 Upgrade End Time(vCenter): DVS: VEM400-201010100-BG Step 6 Step 7 Check for the Upgrade Complete status. switch# show vmware vem upgrade status Upgrade Status: Upgrade Complete in vcenter Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010 Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010 Upgrade Start Time: Wed Mar 17 15:20:06 2010 Upgrade End Time(vCenter): Wed Mar 17 17:28:48 2010 DVS: VEM400-201010100-BG Coordinate with and wait until the server administrator upgrades all ESX host VEMs with the new VEM software release and informs you that the upgrade process is complete. The server administrator performs the manual upgrade using the vihostupdate command or the ESX/ESXi update. For details about manually installing the VEM software, see the Cisco Nexus 1000V VEM Software Installation and Upgrade Guide, Release 4.0(4)SV1(3d). 19

Upgrading the VEMs Step 8 Step 9 Clear the VEM upgrade status after the upgrade process is complete. switch# vmware vem upgrade complete switch# show vmware vem upgrade status Upgrade Status: Upgrade Notification Sent Time: Upgrade Status Time(vCenter): Upgrade Start Time: Upgrade End Time(vCenter): DVS: VEM400-201010100-BG Verify that the upgrade process is complete. switch# show mod Mod Ports Module-Type Model Status --- ----- -------------------------------- ------------------ ------------ 1 0 Virtual Supervisor Module Nexus1000V ha-standby 2 0 Virtual Supervisor Module Nexus1000V active * 3 248 Virtual Ethernet Module NA ok 4 248 Virtual Ethernet Module NA ok Mod Sw Hw --- --------------- ------ 1 4.0(4)SV1(3d) 0.0 2 4.0(4)SV1(3d) 0.0 3 4.0(4)SV1(3d) 1.11 4 4.0(4)SV1(3d) 1.11 Mod MAC-Address(es) Serial-Num --- -------------------------------------- ---------- 1 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA 2 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA 3 02-00-0c-00-03-00 to 02-00-0c-00-03-80 NA 4 02-00-0c-00-04-00 to 02-00-0c-00-04-80 NA Mod Server-IP Server-UUID Server-Name --- --------------- ------------------------------------ -------------------- 1 10.78.109.100 NA NA 2 10.78.109.100 NA NA 3 10.78.109.104 1ee15784-f2e8-383e-8132-9026577ca1bb 10.78.109.104 4 10.78.109.102 44454c4c-4700-104e-804d-cac04f563153 10.78.109.102 * this terminal session The line with the bold characters in the preceding example display that all VSMs and VEMs are upgraded to Release 4.0(4)SV1(3d). Step 10 Step 11 Determine if changing the Feature Support Level is required: If you are upgrading from Release 4.0(4)SV1(3), you have completed this procedure. If you are upgrading from Release 4.0(4)SV1(2), continue to Step 11. (Optional) Change the feature support level to enable the VSM to support all the new features in the new software version. See the Changing the Feature Support Level section on page 26 for more details. 20

Upgrading the VEMs from Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d) Upgrading the VEMs This section describes the steps to upgrade VEMs from Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d) and includes the following topics: Upgrading the VEMs Using VMware Update Manager (VUM): Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d), page 21 Upgrading the VEMs Manually: Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d), page 23 Upgrading the VEMs Using VMware Update Manager (VUM): Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d) To upgrade the VEMs using VUM, follow these steps: This procedure is performed by the network administrator. Before proceeding with the upgrade, make sure the VMs are powered off. Caution This upgrade is only applicable when VSM is not hosted on VEMs that are being upgraded. If the VSM is hosted on a VEM, proceed to the Upgrading the VEMs Manually: Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d), page 23 Step 1 Step 2 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. Verify that the upgrade notification was sent. switch (config)# show vmware vem upgrade status Upgrade Status: Upgrade Availability Notified in vcenter Upgrade Notification Sent Time: Sun May 9 22:04:54 2010 Upgrade Status Time(vCenter): Upgrade Start Time: Upgrade End Time(vCenter): DVS: VEM400-200904001-BG 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 on page 28. Coordinate the notification acceptance with the server administrator, and after the server administrator accepts the upgrade, proceed with the VEM upgrade. switch# show vmware vem upgrade status Upgrade Status: Upgrade Accepted by vcenter Admin Upgrade Notification Sent Time: Sun May 9 22:04:54 2010 Upgrade Status Time(vCenter): Tue May 11 07:42:32 2010 21

Upgrading the VEMs Upgrade Start Time: Upgrade End Time(vCenter): DVS: VEM400-200904001-BG Step 4 After the server administrator accepts the upgrade, proceed with the VEM upgrade. Initiate the VUM upgrade process. vcenter locks the DVS and triggers VUM to upgrade the VEMs. Enter the vmware vem upgrade proceed command to update the Cisco Nexus 1000V Bundle ID on the vcenter Server. If you do not update the Bundle ID, an incorrect VIB version is pushed to the VEM when you next add an ESX to the VSM. switch# vmware vem upgrade proceed switch# show vmware vem upgrade status Upgrade Status: Upgrade In Progress in vcenter Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010 Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010 Upgrade Start Time: Wed Mar 17 15:20:06 2010 Upgrade End Time(vCenter): DVS: VEM400-201010100-BG Step 5 Step 6 Step 7 Check for the Upgrade Complete status. switch# show vmware vem upgrade status Upgrade Status: Upgrade Complete in vcenter Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010 Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010 Upgrade Start Time: Wed Mar 17 15:20:06 2010 Upgrade End Time(vCenter): Wed Mar 17 17:30:48 2010 DVS: VEM400-201010100-BG Clear the VEM upgrade status after the upgrade process is complete. switch# vmware vem upgrade complete switch# show vmware vem upgrade status Upgrade Status: Upgrade Notification Sent Time: Upgrade Status Time(vCenter): Upgrade Start Time: Upgrade End Time(vCenter): DVS: VEM400-201010100-BG Verify that the upgrade process is complete. switch# show mod Mod Ports Module-Type Model Status 22

Upgrading the VEMs --- ----- -------------------------------- ------------------ ------------ 1 0 Virtual Supervisor Module Nexus1000V ha-standby 2 0 Virtual Supervisor Module Nexus1000V active * 3 248 Virtual Ethernet Module NA ok 4 248 Virtual Ethernet Module NA ok Mod Sw Hw --- --------------- ------ 1 4.0(4)SV1(3d) 0.0 2 4.0(4)SV1(3d) 0.0 3 4.0(4)SV1(3d) 1.11 4 4.0(4)SV1(3d) 1.11 Mod MAC-Address(es) Serial-Num --- -------------------------------------- ---------- 1 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA 2 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA 3 02-00-0c-00-03-00 to 02-00-0c-00-03-80 NA 4 02-00-0c-00-04-00 to 02-00-0c-00-04-80 NA Mod Server-IP Server-UUID Server-Name --- --------------- ------------------------------------ -------------------- 1 10.78.109.100 NA NA 2 10.78.109.100 NA NA 3 10.78.109.104 1ee15784-f2e8-383e-8132-9026577ca1bb 10.78.109.104 4 10.78.109.102 44454c4c-4700-104e-804d-cac04f563153 10.78.109.102 * this terminal session The line with the bold characters in the preceding example display that all VSMs and VEMs are upgraded to Release 4.0(4)SV1(3d). Step 8 Step 9 Change the feature support level to enable the VSM to support all the new features in the new software version. See the Changing the Feature Support Level section on page 26 for more details. Power on the VMs. Upgrading the VEMs Manually: Release 4.0(4)SV1(1) to Release 4.0(4)SV1(3d) The manual upgrade of VEMs involves the Cisco Nexus 1000V either using VMware ESX commands that are available on the host ESX CLI or using the VMware vcli commands. For more details, see also the Cisco Nexus 1000V VEM Software Installation and Upgrade Guide, Release 4.0(4)SV1(3d). To upgrade the VEMs manually, perform the following steps as network administrator: This procedure is performed by the network administrator. Before proceeding with the upgrade, make sure the VMs are powered off. Step 1 Coordinate with and notify the server administrator of the VEM upgrade process. switch (config)# vmware vem upgrade notify Warning: Please ensure the hosts are running compatible ESX versions for the upgrade. Refer to corresponding "Cisco Nexus 1000V and VMware Compatibility Information" guide. 23

Upgrading the VEMs Step 2 Step 3 Verify that the upgrade notification was sent. switch (config)# show vmware vem upgrade status Upgrade Status: Upgrade Availability Notified in vcenter Upgrade Notification Sent Time: Sun May 9 22:04:54 2010 Upgrade Status Time(vCenter): Upgrade Start Time: Upgrade End Time(vCenter): DVS: VEM400-200904001-BG 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 on page 28. After the server administrator accepts the upgrade, proceed with the VEM upgrade. switch# show vmware vem upgrade status Upgrade Status: Upgrade Accepted by vcenter Admin Upgrade Notification Sent Time: Sun May 9 22:04:54 2010 Upgrade Status Time(vCenter): Tue May 11 07:42:32 2010 Upgrade Start Time: Upgrade End Time(vCenter): DVS: VEM400-200904001-BG Step 4 If the ESX host is not hosting the VSM, then proceed to Step 5. If the ESX host is hosting the VSM, coordinate with the server administrator to power off the VSM, upgrade the VEMs on the ESX host using the manual process, and power on the VSM. Step 5 Initiate the Cisco Nexus 1000V Bundle ID upgrade process. If VUM is enabled in the vcenter environment, disable it before entering the vmware vem upgrade proceed command to prevent the new VIBs from being pushed to all the hosts. Enter the vmware vem upgrade proceed command to update the Cisco Nexus 1000V Bundle ID on the vcenter Server. If you do not update the Bundle ID, an incorrect VIB version is pushed to the VEM when you next add an ESX to the VSM. switch# vmware vem upgrade proceed switch# show vmware vem upgrade status 2010 Mar 18 15:37:45 switch %VMS-5-DVS_UPGRADE_INFO: VEM Upgrade is completed successfully in vcenter. Upgrade Status: Upgrade In Progress in vcenter Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010 Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010 Upgrade Start Time: Wed Mar 17 15:20:06 2010 Upgrade End Time(vCenter): DVS: VEM400-201010100-BG 24

Upgrading the VEMs Step 6 Step 7 Step 8 Step 9 Check for the Upgrade Complete status. switch# show vmware vem upgrade status Upgrade Status: Upgrade Complete in vcenter Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010 Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010 Upgrade Start Time: Wed Mar 17 15:20:06 2010 Upgrade End Time(vCenter): Wed Mar 17 17:28:48 2010 DVS: VEM400-201010100-BG Coordinate with and wait until the server administrator upgrades all ESX host VEMs with the new VEM software release and informs you that the upgrade process is complete. The server administrator performs the manual upgrade using the vi host update or the ESX/ESXi update. For details, see the Cisco Nexus 1000V VEM Software Installation and Upgrade Guide, Release 4.0(4)SV1(3d). Clear the VEM upgrade status after the upgrade process is complete. switch# vmware vem upgrade complete switch# show vmware vem upgrade status Upgrade Status: Upgrade Notification Sent Time: Upgrade Status Time(vCenter): Upgrade Start Time: Upgrade End Time(vCenter): DVS: VEM400-201010100-BG Verify that the upgrade process is complete. switch# show mod Mod Ports Module-Type Model Status --- ----- -------------------------------- ------------------ ------------ 1 0 Virtual Supervisor Module Nexus1000V ha-standby 2 0 Virtual Supervisor Module Nexus1000V active * 3 248 Virtual Ethernet Module NA ok 4 248 Virtual Ethernet Module NA ok Mod Sw Hw --- --------------- ------ 1 4.0(4)SV1(3d) 0.0 2 4.0(4)SV1(3d) 0.0 3 4.0(4)SV1(3d) 1.11 4 4.0(4)SV1(3d) 1.11 Mod MAC-Address(es) Serial-Num --- -------------------------------------- ---------- 1 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA 2 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA 3 02-00-0c-00-03-00 to 02-00-0c-00-03-80 NA 4 02-00-0c-00-04-00 to 02-00-0c-00-04-80 NA Mod Server-IP Server-UUID Server-Name --- --------------- ------------------------------------ -------------------- 1 10.78.109.100 NA NA 2 10.78.109.100 NA NA 3 10.78.109.104 1ee15784-f2e8-383e-8132-9026577ca1bb 10.78.109.104 4 10.78.109.102 44454c4c-4700-104e-804d-cac04f563153 10.78.109.102 25

Changing the Feature Support Level * this terminal session The line with the bold characters in the preceding example display that all VSMs and VEMs are upgraded to Release 4.0(4)SV1(3d). Step 10 Step 11 Change the feature support level to enable the VSM to support all the new features in the new software version. See the Changing the Feature Support Level section on page 26 for more details. Power on the VMs. Changing the Feature Support Level Since Release 4.0(4)SV1(3d) is a maintenance release, it does not have a Feature Support Level. If you are already at Feature Support Level 4.0(4)SV1(3), you do not have to upgrade the Feature Support Level. This section describes how to change the feature support level and includes the following topics: Prerequisites to Changing the Feature Support Level, page 26 Changing the Feature Support Level, page 26 After all VEMs in the domain are upgraded, the network administrator changes the feature support level to allow the VSM to support all the new features in the new software version. Prerequisites to Changing the Feature Support Level The following are prerequisites to changing the feature support level: Changing the Feature Support Level You are logged in to the CLI in EXEC mode. After an upgrade, the VSM default is to support only features in the previous software version. Features added in the new software version are only supported and functional after the network administrator explicitly upgrades the feature support level. This procedure upgrades the feature support level. You can configure the VSM to provide support for the lowest VEM software version installed to maintain a consistent level of feature support. Before upgrading the feature support level, all VEMs in the VSM domain must be upgraded to the new software version. After the VSM feature support level is upgraded, VEMs with other software versions are not allowed to connect with the VSM. After the VSM feature support level is upgraded, it cannot be downgraded. To change the feature support level, follow these steps: 26

Changing the Feature Support Level This procedure is performed by the network administrator. For example purposes, the following procedure reflects an upgrade from Feature Support Level 4.0(4)SV1(2). Step 1 Verify the current level of feature support. switch# show system vem feature level current feature level: 4.0(4)SV1(2) switch# Step 2 If you are currently at Feature Support Level 4.0(4)SV1(1) or 4.0(4)SV1(2), you may elect to update to Feature Support Level 4.0(4)SV1(3). Display output based on the current VEM feature and the version of the VEMs. switch# system update vem feature level 1 4.0(4)SV1(2) 2 4.0(4)SV1(3) If all VEMs are upgraded to the new software version, then the feature support can be upgraded to the new software version. If even a single VEM is running the previous software version, then the feature support level cannot be upgraded, and the list will be empty. Step 3 Change the feature level to the desired index level from the list displayed in Step 2. switch# system update vem feature level 2 Old feature level: 4.0(4)SV1(2) New feature level: 4.0(4)SV1(3) Step 4 Step 5 After the feature level upgrade, VEMs with versions older than the feature level are no longer allowed to connect to the VSM. Verify the updated level of feature support. switch# show system vem feature level current feature level: 4.0(4)SV1(3) switch# Verify connectivity to the VEMs. switch# show mod Mod Ports Module-Type Model Status --- ----- -------------------------------- ------------------ ------------ 1 0 Virtual Supervisor Module Nexus1000V ha-standby 2 0 Virtual Supervisor Module Nexus1000V active * 3 248 Virtual Ethernet Module NA ok 4 248 Virtual Ethernet Module NA ok Mod Sw Hw --- --------------- ------ 1 4.0(4)SV1(3d) 0.0 2 4.0(4)SV1(3d) 0.0 3 4.0(4)SV1(3d) 1.11 27

Accepting the VEM Upgrade in the vcenter Client 4 4.0(4)SV1(3d) 1.11 Mod MAC-Address(es) Serial-Num --- -------------------------------------- ---------- 1 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA 2 00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8 NA 3 02-00-0c-00-03-00 to 02-00-0c-00-03-80 NA 4 02-00-0c-00-04-00 to 02-00-0c-00-04-80 NA Mod Server-IP Server-UUID Server-Name --- --------------- ------------------------------------ -------------------- 1 10.78.109.100 NA NA 2 10.78.109.100 NA NA 3 10.78.109.104 1ee15784-f2e8-383e-8132-9026577ca1bb 10.78.109.104 4 10.78.109.102 44454c4c-4700-104e-804d-cac04f563153 10.78.109.102 * this terminal session Step 6 The output of the show module command can show either of the following VEM states: OK The VEM has connectivity to the VSM. not-inserted(upgrade) The VEM is not connected to the VSM. Your software upgrade is complete. Accepting the VEM Upgrade in the vcenter Client This section describes the steps that a server administrator follows to accept a VEM upgrade in the vcenter Client and includes the following topics: Prerequisites to Accepting the VEM Upgrade section on page 28 Accepting the VEM Upgrade section on page 28 For details about how to upgrade the VEMs see Upgrading the VEMs section on page 14. Prerequisites to Accepting the VEM Upgrade The following are prerequisites to accepting a VEM upgrade: You are logged in to the CLI in EXEC mode. Network and server administrators are coordinating the upgrade procedure. The VSM upgrade has occurred before the VEM upgrade. You have received a notification in vcenter that a VEM software upgrade is available. Accepting the VEM Upgrade The server administrator accepts the VEM upgrade after the network administrator has upgraded the VSM and notified vcenter server of the availability of the new VEM software version. To accept a request for a VEM upgrade, follow these steps: 28

Troubleshooting This procedure is performed by the server administrator. Step 1 Click the vsphere Client DVS Summary tab to check for the availability of a software upgrade (see Figure 1). Figure 1 vsphere Client DVS Summary Tab Step 2 Click Apply upgrade. The following actions occur: The network administrator is notified that you are ready to apply the upgrade to the VEMs. The network administrator notifies vcenter to proceed with the VEM upgrades. If you are using VUM, vcenter locks the DVS and triggers VUM to upgrade the VEMs. For details about the VEM upgrade performed by the network administrator, see the Upgrading the VEMs section on page 14. Troubleshooting This section provides troubleshooting guidelines for problems that may occur during an upgrade. This section includes the following topic: Non-default (Jumbo) MTU Settings Symptoms and Solutions, page 30 29