Table Of Contents
Cisco Nexus 1000V Software Upgrade Guide, Release 4.0(4)SV1(3b)
Information About the Software Upgrade
Prerequisites to Upgrading the VSMs
Upgrading the VSM from Release 4.0(4)SV1(1) to Release 4.0(4) SV1(3b)
Prerequisites to Upgrading VEMs
Upgrading the VEMs from Release 4.0(2)SV1(2) or Release 4.0(2)SV1(3) to Release 4.0(4) SV1(3b)
Upgrading the VEMs Using VMware Update Manager (VUM) to Release 4.0(4) SV1(3b)
Upgrading the VEMs Manually to Release 4.0(4) SV1(3b)
Upgrading the VEMs from Release 4.0(4)SV1(1) to Release 4.0(4) SV1(3b)
Upgrading the VEMs Using VMware Update Manager (VUM): Release 4.0(4)SV1(1) to Release 4.0(4) SV1(3b)
Upgrading the VEMs Manually: Release 4.0(4)SV1(1) to Release 4.0(4) SV1(3b)
Changing the Feature Support Level
Prerequisites to Changing the Feature Support Level
Changing the Feature Support Level
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.0(4)SV1(3b)
Revised: November 29, 2010
OL-23099-01-A0This document describes how to upgrade the Cisco Nexus 1000V software on a Virtual Supervisor Module (VSM) virtual machine (VM) and includes the following topics:
•
Information About the Software Upgrade
•
Changing the Feature Support Level
•
Accepting the VEM Upgrade in the vCenter Client
•
Obtaining Documentation and Submitting a Service Request
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 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
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.0(4) SV1(3b) 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.0(4)SV1(3b).
Information About the Software Upgrade
![]()
CautionIf 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:
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.
![]()
Note
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.
![]()
Note
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.
![]()
Note
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(3b).
•
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).
![]()
CautionDuring 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(3b), 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(3b), these will be carried over after the upgrade to Release 4.0(4) SV1(3b) 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(3b), these will be carried over after upgrade to Release 4.0(4) SV1(3b) as is.
–
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(3b) as is.
•
When you upgrade from Release 4.0(4)SV1(2) to Release 4.0(4) SV1(3b), 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(3b), these will be carried over after upgrade to Release 4.0(4) SV1(3b) 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(3b) as is.
•
When you upgrade from Release 4.0(4)SV1(1) to Release 4.0(4) SV1(3b), 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(3b), these will be carried over after the upgrade to Release 4.0(4) SV1(3b) 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(3b) 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
•
Upgrading the VSM 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 VSM:
•
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 VSM.
–
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.0(4)SV1(3).
Upgrading the VSM from Release 4.0(4)SV1(2), Release 4.0(4)SV1(3), or Release 4.0(4) SV1(3a) to Release 4.0(4) SV1(3b)
This section describes the VSM upgrade to Release 4.0(4) SV1(3b).
![]()
Note
For example purposes, the following procedure reflects an upgrade from Release 4.0(4)SV1(3) to Release 4.0(4) SV1(3b).
![]()
Note
This procedure is performed by the network administrator.
To perform a VSM software upgrade to Release 4.0(4) SV1(3b), 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 .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.3.bin73068811 Dec 09 13:57:32 2009 nexus-1000v-mz.4.0.4.SV1.3.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-local249647552 bytes used2138623552 bytes free2388271104 bytes totalswitch# copy scp://root@10.78.27.167/N1K-VSM-images/nexus-1000v-mz.4.0.4.SV1.3b.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.3b.bin 100% 20MB 1.1MB/s 00:19switch#switch# copy scp://root@10.78.27.167/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@10.78.27.167'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.3.bin21982208 Jul 08 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.3.bin62280256 Jul 08 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 r s
[########################################] 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(3) 0.02 4.0(4)SV1(3) 0.0
3 4.0(4)SV1(3) 1.114 4.0(4)SV1(3) 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 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(3b).
switch# reload module 2
This command will reboot standby supervisor module. (y/n)? [n] y
about to reset standby supswitch# 2010 Jul 08 09:57:42 n1000v %PLATFORM-2-PFM_MODULE_RESET: Manual restart of Module 2 from Command Line Interface2010 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).![]()
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(3) 0.02 4.0(4)SV1(3b) 0.0
3 4.0(4)SV1(3) 1.114 4.0(4)SV1(3) 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(3) 1.114 4.0(4)SV1(3) 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).
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
(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.
For details, see the "Upgrading the VEMs" section.
Upgrading the VSM from 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).
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
Power off all VMs except the VSM.
Step 2
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 .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.1.bin73068811 Dec 09 13:57:32 2009 nexus-1000v-mz.4.0.4.SV1.1.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-local249647552 bytes used2138623552 bytes free2388271104 bytes totalswitch#copy scp://root@10.78.27.167/N1K-VSM-images/nexus-1000v-mz.4.0.4.SV1.3b.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.3b.bin 100% 20MB 1.1MB/s 00:19switch#switch# copy scp://root@10.78.27.167/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@10.78.27.167'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.1.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.1.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 3
Remove the existing system boot variable and kickstart boot variable.
switch# config tswitch(config)# no boot system
switch(config)# no boot kickstart
switch(config)#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)#switch(config)# boot kickstart bootflash:nexus-1000v-kickstart-mzg.4.0.4.SV1.3b.bin
2009 Dec 13 15:54:03.093 n1k-av %BOOTVAR-5-IMAGE_NOTEXISTS: Warning: image nexus-1000v-kickstart-mz.4.0.4.SV1.3b.bin doesn't exist on 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.
![]()
CautionIf 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.
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.0
2 4.0(4)SV1(1) 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![]()
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(1).
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.
For details, see the "Upgrading the VEMs" section.
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
•
Upgrading the VEMs from Release 4.0(2)SV1(2) or Release 4.0(2)SV1(3) to Release 4.0(4) SV1(3b)
•
Upgrading the VEMs from Release 4.0(4)SV1(1) to Release 4.0(4) SV1(3b)
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(3b) 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.
![]()
Note
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(3b).
![]()
CautionDo 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(3b) 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(3b)
This section describes the steps to upgrade VEMs to Release 4.0(4) SV1(3b) and includes the following topics:
•
Upgrading the VEMs Using VMware Update Manager (VUM) to Release 4.0(4) SV1(3b)
•
Upgrading the VEMs Manually to Release 4.0(4) SV1(3b)
Upgrading the VEMs Using VMware Update Manager (VUM) to Release 4.0(4) SV1(3b)
To upgrade the VEMs using VUM, follow these steps:
![]()
Note
For example purposes, the following procedure reflects an upgrade from Release 4.0(4)SV1(3) to Release 4.0(4) SV1(3b).
![]()
Note
This procedure is performed by the network administrator.
Step 1
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.
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: System VEM ImageUpgrade 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-201010100-BGDVS: VEM400-201003101-BG
![]()
Note
The value of the DVS output will change depending on the vCenter version.
Step 4
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.
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 VIBs: System 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-201010100-BGDVS: VEM400-201003101-BGStep 5
Initiate the VUM upgrade process.
vCenter locks the DVS and triggers VUM to upgrade the VEMs.
![]()
CautionBefore entering the following command, communicate with the server administrator to confirm that the VUM process is operational.
![]()
Note
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 VIBs: System 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-201010100-BGDVS: VEM400-201010100-BG![]()
Note
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.
Step 6
Check for the Upgrade Complete status.
switch# show vmware vem upgrade status
Upgrade VIBs: System VEM ImageUpgrade Status: Upgrade Complete in vCenter
Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010Upgrade Start Time: Wed Mar 17 15:20:06 2010Upgrade End Time(vCenter): Wed Mar 17 17:30:48 2010Upgrade Error:Upgrade Bundle ID:VSM: VEM400-201010100-BGDVS: VEM400-201010100-BGStep 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: 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-201010100-BGDVS: VEM400-201010100-BGStep 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.0(4)SV1(3b) 0.0
2 4.0(4)SV1(3b) 0.0
3 4.0(4)SV1(3b) 1.11
4 4.0(4)SV1(3b) 1.11
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.0(4) SV1(3b).
Step 9
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.
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 for more details.
Upgrading the VEMs Manually to Release 4.0(4) SV1(3b)
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 Virtual Ethernet Module Software Installation Guide, Release 4.0(4)SV1(3b).
To upgrade the VEMs manually, follow these steps:
![]()
Note
This procedure is performed by the network administrator.
Step 1
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.
Step 2
Coordinate with and notify the server administrator of the VEM upgrade process.
switch (config)# vmware vem upgrade notify
vmware vem upgrade notifyWarning: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: System VEM ImageUpgrade 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-201010100-BGDVS: VEM400-201003191-BGStep 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: System 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-201010100-BGDVS: VEM400-201003191-BGStep 5
Initiate the manual 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.
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: System 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-201010100-BGDVS: VEM400-201010100-BGStep 6
Check for the Upgrade Complete status.
switch# show vmware vem upgrade status
Upgrade VIBs: System VEM ImageUpgrade Status: Upgrade Complete in vCenter
Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010Upgrade Start Time: Wed Mar 17 15:20:06 2010Upgrade End Time(vCenter): Wed Mar 17 17:28:48 2010Upgrade Error:Upgrade Bundle ID:VSM: VEM400-201010100-BGDVS: VEM400-201010100-BGStep 7
Coordinate with and wait until the server administrator upgrades all ESX host VEMs with the new VEM software release and informs you that the upgrade process is complete.
The server administrator performs the manual upgrade using the vihostupdate command or the ESX/ESXi update. For details about manually installing the VEM software, see the Cisco Nexus 1000V Virtual Ethernet Module Software Installation Guide, Release 4.0(4)SV1(3b).
Step 8
Clear the VEM upgrade status after the upgrade process is complete.
switch# vmware vem upgrade complete
switch# show vmware vem upgrade status
Upgrade VIBs: 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-201010100-BGDVS: VEM400-201010100-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.0(4)SV1(3b) 0.0
2 4.0(4)SV1(3b) 0.0
3 4.0(4)SV1(3b) 1.11
4 4.0(4)SV1(3b) 1.11
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.0(4) SV1(3b).
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 11.
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 for more details.
Upgrading the VEMs from Release 4.0(4)SV1(1) to Release 4.0(4) SV1(3b)
This section describes the steps to upgrade VEMs from Release 4.0(4)SV1(1) to Release 4.0(4) SV1(3b) 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(3b)
•
Upgrading the VEMs Manually: Release 4.0(4)SV1(1) to Release 4.0(4) SV1(3b)
Upgrading the VEMs Using VMware Update Manager (VUM): Release 4.0(4)SV1(1) to Release 4.0(4) SV1(3b)
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.
![]()
CautionThis 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(3b)
Step 1
Coordinate with and notify the server administrator of the VEM upgrade process.
switch (config)# vmware vem upgrade notify
Warning:Please ensure the hosts are running compatible ESX versions for the upgrade. Refer to corresponding "Cisco Nexus 1000V and VMware Compatibility Information" guide.Step 2
Verify that the upgrade notification was sent.
switch (config)# show vmware vem upgrade status
Upgrade VIBs: System VEM ImageUpgrade 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-201010100-BGDVS: VEM400-200904001-BGStep 3
Verify that the server administrator has accepted the upgrade in vCenter Server.
For details about the server administrator accepting the VEM upgrade, see the "Accepting the VEM Upgrade in the vCenter Client" section.
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 VIBs: System 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-201010100-BGDVS: VEM400-200904001-BGAfter the server administrator accepts the upgrade, proceed with the VEM upgrade.
Step 4
Initiate the VUM upgrade process.
vCenter locks the DVS and triggers VUM to upgrade the VEMs.
![]()
Note
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 VIBs: System 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-201010100-BGDVS: VEM400-201010100-BGStep 5
Check for the Upgrade Complete status.
switch# show vmware vem upgrade status
Upgrade VIBs: System VEM ImageUpgrade Status: Upgrade Complete in vCenter
Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010Upgrade Start Time: Wed Mar 17 15:20:06 2010Upgrade End Time(vCenter): Wed Mar 17 17:30:48 2010Upgrade Error:Upgrade Bundle ID:VSM: VEM400-201010100-BGDVS: VEM400-201010100-BGStep 6
Clear the VEM upgrade status after the upgrade process is complete.
switch# vmware vem upgrade complete
switch# 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-201010100-BGDVS: VEM400-201010100-BGStep 7
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.0(4)SV1(3b) 0.0
2 4.0(4)SV1(3b) 0.0
3 4.0(4)SV1(3b) 1.11
4 4.0(4)SV1(3b) 1.11
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.0(4) SV1(3b).
Step 8
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 for more details.
Step 9
Power on the VMs.
Upgrading the VEMs Manually: Release 4.0(4)SV1(1) to Release 4.0(4) SV1(3b)
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 Virtual Ethernet Module Software Installation Guide, Release 4.0(4)SV1(3b).
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.
Step 1
Coordinate with and notify the server administrator of the VEM upgrade process.
switch (config)# vmware vem upgrade notify
Warning:Please ensure the hosts are running compatible ESX versions for the upgrade. Refer to corresponding "Cisco Nexus 1000V and VMware Compatibility Information" guide.Step 2
Verify that the upgrade notification was sent.
switch (config)# show vmware vem upgrade status
Upgrade VIBs: System VEM ImageUpgrade 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-201010100-BGDVS: VEM400-200904001-BGStep 3
Verify that the server administrator has accepted the upgrade in vCenter Server.
For details about the server administrator accepting the VEM upgrade, see the "Accepting the VEM Upgrade in the vCenter Client" section.
After the server administrator accepts the upgrade, proceed with the VEM upgrade.
switch# show vmware vem upgrade status
Upgrade VIBs: System 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-201010100-BGDVS: VEM400-200904001-BGStep 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.
![]()
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.
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 VIBs: System 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-201010100-BGDVS: VEM400-201010100-BGStep 6
Check for the Upgrade Complete status.
switch# show vmware vem upgrade status
Upgrade VIBs: System VEM ImageUpgrade Status: Upgrade Complete in vCenter
Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010Upgrade Start Time: Wed Mar 17 15:20:06 2010Upgrade End Time(vCenter): Wed Mar 17 17:28:48 2010Upgrade Error:Upgrade Bundle ID:VSM: VEM400-201010100-BGDVS: VEM400-201010100-BGStep 7
Coordinate with and wait until the server administrator upgrades all ESX host VEMs with the new VEM software release and informs you that the upgrade process is complete. The server administrator performs the manual upgrade using the vi host update or the ESX/ESXi update. For details, see the Cisco Nexus 1000V Virtual Ethernet Module Software Installation Guide, Release 4.0(4)SV1(3b).
Step 8
Clear the VEM upgrade status after the upgrade process is complete.
switch# vmware vem upgrade complete
switch# show vmware vem upgrade status
Upgrade VIBs: 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-201010100-BGDVS: VEM400-201010100-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.0(4)SV1(3b) 0.0
2 4.0(4)SV1(3b) 0.0
3 4.0(4)SV1(3b) 1.11
4 4.0(4)SV1(3b) 1.11
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.0(4) SV1(3b).
Step 10
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 for more details.
Step 11
Power on the VMs.
Changing the Feature Support Level
![]()
Note
Since Release 4.0(4) SV1(3b) 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
•
Changing the Feature Support Level
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:
•
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.
Changing the Feature Support Level
To change the feature support level, follow these steps:
![]()
Note
This procedure is performed by the network administrator.
![]()
Note
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#![]()
Note
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).
Step 2
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)
![]()
Note
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)
![]()
Note
After the feature level upgrade, VEMs with versions older than the feature level are no longer allowed to connect to the VSM.
Step 4
Verify the updated level of feature support.
switch# show system vem feature level
current feature level: 4.0(4)SV1(3)switch#Step 5
Verify connectivity to the VEMs.
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.02 4.0(4)SV1(3b) 0.03 4.0(4)SV1(3b) 1.114 4.0(4)SV1(3b) 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 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.
Step 6
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
•
"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.
•
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 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.
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
Non-default (Jumbo) MTU Settings Symptoms and Solutions
If you have configured non-default (jumbo) MTU settings, read this section before proceeding with VEM upgrades.
Available Documents
The following documents are used with the Cisco Nexus 1000 and are 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.0(4)SV1(3a)
Cisco Nexus 1000V Release Notes, Release 4.0(4)SV1(3a)
Cisco Nexus 1000V Compatibility Information, Release 4.0(4)SV1(3a)
Cisco Nexus 1010 Management Software Release Notes, Release 4.0(4)SP1(1)
Install and Upgrade
Cisco Nexus 1000V Virtual Supervisor Module Software Installation Guide, Release 4.0(4)SV1(3a)
Cisco Nexus 1000V Software Upgrade Guide, Release 4.0(4)SV1(3a)
Cisco Nexus 1000V Virtual Ethernet Module Software Installation Guide, Release 4.0(4)SV1(3a)
Cisco Nexus 1010 Virtual Services Appliance Installation Guide
Configuration Guides
Cisco Nexus 1000V License Configuration Guide, Release 4.0(4)SV1(3)
Cisco Nexus 1000V Getting Started Guide, Release 4.0(4)SV1(3)
Cisco Nexus 1000V High Availability and Redundancy Configuration Guide, Release 4.0(4)SV1(3)
Cisco Nexus 1000V Interface Configuration Guide, Release 4.0(4)SV1(3)
Cisco Nexus 1000V Layer 2 Switching Configuration Guide, Release 4.0(4)SV1(3)
Cisco Nexus 1000V Port Profile Configuration Guide, Release 4.0(4)SV1(3)
Cisco Nexus 1000V Quality of Service Configuration Guide, Release 4.0(4)SV1(3)
Cisco Nexus 1000V Security Configuration Guide, Release 4.0(4)SV1(3)
Cisco Nexus 1000V System Management Configuration Guide, Release 4.0(4)SV1(3)
Cisco Nexus 1010 Software Configuration Guide, Release 4.0(4)SP1(1)
Programming Guide
Cisco Nexus 1000V XML API User Guide, Release 4.0(4)SV1(3)
Reference Guides
Cisco Nexus 1000V Command Reference, Release 4.0(4)SV1(3)
Cisco Nexus 1000V MIB Quick Reference
Cisco Nexus 1010 Command Reference, Release 4.0(4)SP1(1)
Troubleshooting and Alerts
Cisco Nexus 1000V Troubleshooting Guide, Release 4.0(4)SV1(3a)
Cisco Nexus 1000V Password Recovery Guide
Cisco NX-OS System Messages Reference
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 conjuction with the documents listed in the Available Documents section.
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at 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. (1005R)
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.
© 2010 Cisco Systems, Inc. All rights reserved.