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

Table Of Contents

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

Audience

Document Conventions

Information About the Software Upgrade

About the VSM Upgrade

About the VEM Upgrade

VMware Update Manager

Manual VEM Upgrade

Guidelines and Limitations

Upgrading the Software

Prerequisites

Upgrading the VSM

Prerequisites

Flow Chart: Upgrading the VSM

Copying the Software Files to the VSM

Updating the Boot Variables in the Startup Configuration

Reloading the Software

Initiating and Monitoring the VEM Software Upgrade

Changing the Feature Support Level

Verifying Connectivity to the VEMs

Upgrading the VEMs

Prerequisites

Flow Chart: Upgrading VEMs with a Standalone VSM

Flow Chart: Upgrading VEMs with Dual VSMs

Accepting the VEM Upgrade

Related Documentation

Obtaining Documentation and Submitting a Service Request

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

---

Revised: September 29, 2010,
OL-20750-03

This document describes how to upgrade the Cisco Nexus 1000V software on a VSM virtual machine.

This document includes the following topics:

•Audience

•Document Conventions

•Information About the Software Upgrade

•Guidelines and Limitations

•Upgrading the Software

•Related Documentation

•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:

–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(2).

Document Conventions

Command descriptions use these conventions:

boldface font	Commands and keywords are in boldface.
italic font	Arguments for which you supply values are in italics.
{ }	Elements in braces are required choices.
[ ]	Elements in square brackets are optional.
x | y | z	Alternative, mutually exclusive elements are separated by vertical bars.
string	A nonquoted set of characters. Do not use quotation marks around the string or the string will include the quotation marks.

Screen examples use these conventions:

screen font	Terminal sessions and information the device displays are in screen font.
boldface screen font	Information you must enter is in boldface screen font.
italic screen font	Arguments for which you supply values are in italic screen font.
< >	Nonprinting characters, such as passwords, are in angle brackets.
[ ]	Default responses to system prompts are in square brackets.
!, #	An exclamation point (!) or a pound sign (#) at the beginning of a line of code indicates a comment line.

This document uses the following conventions for notes and cautions:

---

Note Means reader take note. Notes contain helpful suggestions or references to material not covered in the manual.

---

Information About the Software Upgrade

---

Caution If the VMware vCenter Server is hosted on the same ESX host as a Cisco Nexus 1000V VEM, then a VUM assisted upgrade on the host will fail. You should manually vMotion the VM to another host before performing the upgrade.

---

---

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_v110-4.0.4.1.2.0.90-1.20.19.vib).

---

A software upgrade consists of adding a new software version first to the Cisco Nexus 1000V VSM and then to its VEMs. The following steps describe the overall software upgrade.

---

Step 1 The Server Administrator shuts down the VMs on the hosts running the VEM software.

Step 2 The Network Administrator upgrades the VSM.

Step 3 The Server Administrator upgrades the VEMs.

Step 4 The Server Administrator restarts the VMs on the hosts running the VEM software.

---

---

Caution Network service for the VMs may be unavailable for the duration of the upgrade, until all the VEM have been upgraded. Because network service is not guaranteed to be restored in all scenarios until the upgrade is complete, we recommend that you shut down the VMs during the upgrade procedure to avoid inconsistencies in service availability.

---

This section includes the following topics:

•About the VSM Upgrade

•About the VEM Upgrade

About the VSM Upgrade

The following steps describe the VSM upgrade.

---

Step 1 The Server Administrator shuts down the virtual machines on the hosts running the VEM software.

---

Note If VMs are not shutdown, there will be interruption of service for those VMs during the VSM and VEM upgrades.

---

Step 2 The Network Administrator copies the new software files to the bootflash file system of the active VSM.

Step 3 The Network Administrator updates the boot variables in the startup configuration of the active VSM to reflect the names of the new software files. This causes the system to load the new software when reloading or rebooting. The boot variables on the standby VSM are automatically updated also.

Step 4 The Network Administrator reloads the software on the active and standby VSMs with the following results:

–The upgraded VSMs are running the new software version.

–All VEMs in the VSM domain are running an older software version than the VSM.

Step 5 The Network Administrator initiates and monitors the progress of the VEM upgrade.

---

About the VEM Upgrade

VEM software can be upgraded manually using the CLI, or automatically using VUM. VSM software can control and configure older VEM versions while continuing to support all features in the previous software version.

The VSM software can be upgraded without also upgrading the VEM software. However, the new features introduced are only available when the following conditions are met:

•All VEMs are also upgraded to the new software version.

•The Network Administrator updates the VSM feature level to the new software version.

You can configure the VSM to provide support for the lowest VEM software version installed to maintain a consistent level of feature support.

---

Note 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 and VMware Compatibility Information, Release 4.0(4)SV1(2).

---

VMware Update Manager

VMware Update Manager (VUM) can automatically update all VEMs in a VSM domain to a new software version. The following steps describe the process for upgrading VEM with VUM.

---

Step 1 After installing the new VSM software version, the Network Administrator sends a message to vCenter notifying the Server Administrator that a new VEM software version is available.

Step 2 The Server Administrator sends an instruction from vSphere Client to either accept or reject the upgrade.

Step 3 If accepted, the Network Administrator sends an instruction to vCenter to start the upgrade.

Step 4 vCenter triggers VUM to start the upgrade.

Step 5 The Network Administrator monitors the upgrade process from the VSM.

Step 6 Once all VEMs are upgraded, the Network Administrator does the following:

•Changes the support level so that the VSM supports all features in the new software version.

•Verifies VEM connectivity with the VSM.

---

Manual VEM Upgrade

A manual VEM upgrade is done without the use of VUM. Once upgraded, the VSM reconnects with each VEM.

The following steps describe the manual VEM upgrade process.

---

Step 1 After installing the new VSM software version, the Network Administrator sends a command to vCenter to notify the Server Administrator that a new VEM software version is available.

Step 2 The Server Administrator sends an instruction from vSphere Client to either accept or reject the upgrade.

Step 3 The Network Administrator monitors the upgrade process from the VSM.

Step 4 The Server Administrator manually upgrades the first VEM.

---

Note If you did not shutdown the VMs during the VSM upgrade, and the following conditions are met:
- The system is now in a state where it is running software release 4.0(4)SV1(2) on the VSM.
- All the modules running software release 4.0(4)SV1(1) are reconnected properly.
Then you may use Vmotion of the VMs to avoid further service interruption while the VEMs are upgraded. This applies to VMs that do not have VSMs.

---

Step 5 The VEM reconnects with the VSM.

Step 6 The Server Administrator repeats Step 4 for each remaining VEM.

Step 7 Once all VEMs are upgraded, the Network Administrator does the following:

•Changes the support level so that the VSM supports all features in the new software version.

•Verifies VEM connectivity with the VSM.

---

Guidelines and Limitations

The following are guidelines and limitations for the software upgrade.

•After an upgrade, the VSM feature level, by default, is set to support the previous software version. Features added in the new software version are only functional after the Network Administrator explicitly upgrades the feature support level to support the new software version.

•After the VSM feature support level is upgraded, VEMs with other versions are not allowed to connect with the VSM.

•The upgrade process is irrevocable. After the software is upgraded, you can perform a downgrade by removing the current installation and reinstalling the software. For details, see the "Recreating the Installation" section in the Cisco Nexus 1000V Troubleshooting Guide, Release 4.0(4)SV1(2).

•After the VSM feature support level is upgraded, it cannot be downgraded.

•Evaluation licenses installed prior to the upgrade are invalidated after the upgrade.

•After the upgrade, licenses for 16 CPU sockets are available for a period of 60 days. These licenses are used only if there are no permanent licenses installed on the VSM. The evaluation period of 60 days starts when you upgrade the software.

•If you are using a proxy server to connect VUM to the Internet, you may need to disable the proxy before starting a VUM upgrade of your VEMs. In VMware versions before VUM Update 1, the proxy prevents VUM from communicating locally with the VSM. For this reason automatic VEM upgrades may fail if the proxy is not disabled first.

•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 would become active.

–Manually upgrade the VEM providing the interface connectivity.

–Restart the VSM that was shut down.

---

Caution Network service for the VMs may be unavailable for the duration of the upgrade, until all the VEM have been upgraded. Because network service is not guaranteed to be restored in all scenarios until the upgrade is complete, we recommend that you shut down the VMs during the upgrade procedure to avoid inconsistencies in service availability.

---

Upgrading the Software

Network and Server Administrators use this section to upgrade to a new software version.

Prerequisites

The following are prerequisites to upgrading the software:

•You have a previous version of Cisco Nexus 1000V software installed in your network.

•Network and Server Administrators have agreed to a timeframe for the upgrade.

•The VSM upgrade should occur immediately before the VEM upgrade.

Figure 1 Flow Chart:   Upgrading the Software

Upgrading the VSM

The Network Administrator uses this section to upgrade the VSM to a new software version.

Prerequisites

The following are prerequisites to upgrading the software:

•You have a previous version of Cisco Nexus 1000V software installed in your network.

•Network and Server Administrators have agreed to a timeframe for the upgrade.

•The following files are available in external storage reachable from the VSM.

–nexus-1000v-mz.4.0.4.SV1.2.bin

–nexus-1000v-kickstart-mz.4.0.4.SV1.2.bin

•You have saved any 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 and restoring a configuration file, see the Cisco Nexus 1000V System Management Configuration Guide, Release 4.0(4)SV1(2).

•The VSM upgrade should occur right before the VEM upgrade.

Flow Chart: Upgrading the VSM

The following flow chart will guide you through this process. After completing each procedure, return to the flow chart to make sure you complete all required procedures in the correct sequence.

Figure 2 Flow Chart:   Upgrading the VSM

Copying the Software Files to the VSM

The Network Administrator uses this procedure to add the software files to the active VSM.

BEFORE YOU BEGIN

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

•You are logged in to the CLI in EXEC mode.

•You have a copies of the following software files:

–nexus-1000v-mzg.4.0.4.SV1.2.bin

–nexus-1000v-kickstart-mzg.4.0.4.SV1.2.bin

•This procedure requires you to copy the system image to bootflash. This may result in the following incorrect error message which can be ignored. The copy actually completes as expected.

Unable to sync data to remote device:no such file or directory (unknown server)

---

Step 1 List the files in the bootflash file system.

dir bootflash:

Example:

switch# dir bootflash:

      77824     Apr 15 17:58:14 2009  accounting.log

      16384     Apr 15 16:55:30 2009  lost+found/

   22175744     Apr 15 16:55:35 2009  nexus-1000v-kickstart-mzg.4.0.4.SV1.1.bin

   50160669     Apr 15 17:46:11 2009  nexus-1000v-mzg.4.0.4.SV1.1.bin

       4096     Apr 15 16:56:09 2009  vdc_2/

       4096     Apr 15 16:56:09 2009  vdc_3/

       4096     Apr 15 16:56:09 2009  vdc_4/

Usage for bootflash://sup-local

  269848576 bytes used

 2928091136 bytes free

 3197939712 bytes total

Step 2 Copy the system image to the bootflash file system.

copy [source filesystem:] filename   [destination filesystem:] filename

Example:

switch# copy scp://admin@10.71.8.8/ws/n1kv_images/nexus-1000v-mzg.4.0.4.SV1.2.bin 
bootflash:

Enter vrf (If no input, current vrf 'default' is considered): 

admin@10.71.8.8's password: 

nexus-1000v-mzg.4.0.4.SV1.2.bin                                                                                          
100%   48MB   1.2MB/s   00:39    

switch#

Step 3 Copy the kickstart image to the bootflash file system.

copy [source filesystem:] filename   [destination filesystem:] filename

Example:

switch# copy 
scp://admin@10.71.8.8/ws/n1kv_images/nexus-1000v-kickstart-mzg.4.0.4.SV1.2.bin bootflash:

Enter vrf (If no input, current vrf 'default' is considered): 

admin@10.71.8.8's password: 

nexus-1000v-kickstart-mzg.4.0.4.SV1.2.bin                                                                                
100%   19MB   1.1MB/s   00:17 

switch#

Step 4 Verify that the new system image is present in the bootflash file system for the active VSM.

dir bootflash:

Example:

switch# dir bootflash:

      77824     Apr 15 17:58:14 2009  accounting.log

      16384     Apr 15 16:55:30 2009  lost+found/

   22175744     Apr 15 16:55:35 2009  nexus-1000v-kickstart-mzg.4.0.4.SV1.1.bin

   20389888     Apr 22 16:38:15 2009  nexus-1000v-kickstart-mzg.4.0.4.SV1.2.bin

   50160669     Apr 15 17:46:11 2009  nexus-1000v-mzg.4.0.4.SV1.1.bin

   50161232     Apr 22 16:33:10 2009  nexus-1000v-mzg.4.0.4.SV1.2.bin

       4096     Apr 15 16:56:09 2009  vdc_2/

       4096     Apr 15 16:56:09 2009  vdc_3/

       4096     Apr 15 16:56:09 2009  vdc_4/

Usage for bootflash://sup-local

  340480000 bytes used

 2857459712 bytes free

 3197939712 bytes total

You have completed this procedure. Return to Figure 2.

---

Updating the Boot Variables in the Startup Configuration

The Network Administrator uses this procedure to update the boot variable names in the startup configuration with the names of the new software files. This causes the system to load the new software version when reloading or rebooting.

BEFORE YOU BEGIN

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

•You are logged in to the CLI in EXEC mode.

•You have already copied the new software files into the bootflash file system, using the "Copying the Software Files to the VSM" procedure.

SUMMARY STEPS

1. config t

2. no boot system

3. no boot kickstart

4. boot system bootflash: system-filename

5. boot kickstart bootflash: kickstart-filename

6. show boot

7. copy running-config startup-config

DETAILED STEPS

	Command	Purpose
Step 1	config t Example: n1000v# config t n1000v(config)#	Places you in CLI Global Configuration mode.
Step 2	no boot system Example: n1000v(config)# no boot system n1000v(config)#	Removes the existing system boot variable.
Step 3	no boot kickstart Example: n1000v(config)# no boot kickstart n1000v(config)#	Removes the existing kickstart boot variable.
Step 4	boot system bootflash: system-filename Example: n1000v(config)# boot system bootflash:nexus-1000v-mzg.4.0.4.SV1.2.bin 2009 Dec 13 15:50:40.568 n1k-av %BOOTVAR-5-IMAGE_NOTEXISTS: Warning: image nexus-1000v-mz.4.0.4.SV1.2.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.2.bin to standby supervisor succeed n1000v(config)#	Adds the new system boot variable. 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.
Step 5	boot kickstart bootflash: kickstart-filename Example: n1000v(config)# boot kickstart bootflash:nexus-1000v-kickstart-mzg.4.0.4. SV1.2.bin 2009 Dec 13 15:54:03.093 n1k-av %BOOTVAR-5-IMAGE_NOTEXISTS: Warning: image nexus-1000v-kickstart-mz.4.0.4.SV1.2.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.2.bin to standby supervisor succeed n1000v(config)#	Adds the new kickstart boot variable. 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.
Step 6	dir bootflash://sup-standby dir bootflash://sup-remote Example: switch# dir bootflash://sup-standby 77824 Apr 15 17:58:14 2009 accounting.log 16384 Apr 15 16:55:30 2009 lost+found/    20389888 Apr 22 16:38:15 2009 nexus-1000v-kickstart-mzg.4.0.4.SV1.2.bin 50161232 Apr 22 16:33:10 2009 nexus-1000v-mzg.4.0.4.SV1.2.bin 4096 Apr 15 16:56:09 2009 Usage for bootflash://sup-standby 340480000 bytes used 2857459712 bytes free 3197939712 bytes total	Verifies that the new image is in the bootflash directory on the standby VSM.
Step 7	show boot Example: n1000v(config)# show boot sup-1 kickstart variable = bootflash:/nexus-1000v-kickstart-mzg.4.0.4 .SV1.2.bin system variable = bootflash:/nexus-1000v-mzg.4.0.4.SV1.2.bin sup-2 kickstart variable = bootflash:/nexus-1000v-kickstart-mzg.4.0.4 .SV1.2.bin system variable = bootflash:/nexus-1000v-mzg.4.0.4.SV1.2.bin No module boot variable set n1000v(config)#	(Optional) Displays the system and kickstart boot variables for verification.
Step 8	copy running-config startup-config Example: n1000v(config)# copy running-config startup-config [########################################] 100% n1000v(config)#	Saves the running configuration persistently through reboots and restarts by copying it to the startup configuration.
	You have completed this procedure. Return to Figure 2.

Reloading the Software

The Network Administrator uses this procedure to reload the new VSM software.

BEFORE YOU BEGIN

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

•You are logged in to the VSM in EXEC mode.

•You have already copied the new software files into the bootflash file system, using the "Copying the Software Files to the VSM" procedure.

•You have already reconfigurd the boot variables so that the system will look for the new software files when rebooting or reloading. See the "Updating the Boot Variables in the Startup Configuration" procedure.

•You have made sure that the boot settings in the VM of the VSM are set so that it boots fromthe hard disk.

---

Caution If you are upgrading dual VSMs, then before you reload the software, make sure that the bootflash file system for the standby VSM has system and kickstart image files that are identical to those in the active VSM. If they are not identical, then the only way to recover the standby VSM is to create a new one from the ISO image and point it to the active VSM.

---

SUMMARY STEPS

1. show boot

2. dir bootflash://sup-remote/

3. reload

4. show version

DETAILED STEPS

---

Step 1 Display the system and kickstart boot variables for verification. If your system has dual supervisor modules in HA mode, the boot variables are synchronized automatically.

show boot

Example:

switch# show boot

sup-1

kickstart variable = bootflash:/nexus-1000v-kickstart-mzg.4.0.4.SV1.2.bin

system variable = bootflash:/nexus-1000v-mz.4.0.4.SV1.2.bin;bootflash:/nexus-1000v-mz.4.

0.4.SV1.1.123.bin

sup-2

kickstart variable = bootflash:/nexus-1000v-kickstart-mzg.4.0.4.SV1.2.bin

system variable = bootflash:/nexus-1000v-mz.4.0.4.SV1.2.bin;bootflash:/nexus-1000v-mzg.4.

0.4.SV1.1.bin

No module boot variable set

switch# 

Step 2 Do one of the following:

•If the boot variables display the new software version, continue with the next step.

•If not, update the boot variables using the "Updating the Boot Variables in the Startup Configuration" procedure, and then restart this procedure.

Step 3 Verify that the new software files are in the bootflash file system for the standby supervisor.

dir bootflash://sup-remote/

If the new software files are not present in bootflash, then the synchronization between the active and standby supervisors is not complete.

Example:

switch# dir bootflash://sup-remote/ 

      77824     Apr 15 17:58:41 2009  accounting.log

      16384     Apr 15 15:16:11 2009  lost+found/

   22175744     Apr 15 15:16:14 2009  nexus-1000v-kickstart-mzg.4.0.4.SV1.1.bin

   20389888     Apr 22 16:43:20 2009  nexus-1000v-kickstart-mzg.4.0.4.SV1.2.bin

   50160669     Apr 15 17:46:57 2009  nexus-1000v-mzg.4.0.4.SV1.1.bin

   50161232     Apr 22 16:44:04 2009  nexus-1000v-mzg.4.0.4.SV1.2.bin

       4096     Apr 15 15:16:47 2009  vdc_2/

       4096     Apr 15 15:16:47 2009  vdc_3/

       4096     Apr 15 15:16:47 2009  vdc_4/

Usage for bootflash://sup-remote

  340484096 bytes

 2857459712 bytes free

 3197943808 bytes total

Step 4 Do one of the following:

•If the new software files are in the bootflash file system, continue with the next step.

•If not, copy the software files using the "Copying the Software Files to the VSM" procedure, and then restart this procedure.

Step 5 Reload the VSM.

---

Caution Make sure that the boot settings in the VM of the VSM are set so that it boots from the hard disk. If it is set to boot from the CD, then the reload of the upgraded software will fail.

---

reload

y

Example:

switch# reload

This command will reboot the system. (y/n)?  [n] y

switch# 

The upgraded VSMs start up with the new software version.

Step 6 Verify that the new software version is present on the VSM.

show version

Example:

switch# show version

        Cisco Nexus Operating System (NX-OS) Software

        TAC support: http://www.cisco.com/tac

        Copyright (c) 2002-2009, Cisco Systems, Inc. All rights reserved.

        The copyrights to certain works contained in this software are

        owned by other third parties and used and distributed under

        license. Certain components of this software are licensed under

        the GNU General Public License (GPL) version 2.0 or the GNU

        Lesser General Public License (LGPL) Version 2.1. A copy of each

        such license is available at

        http://www.opensource.org/licenses/gpl-2.0.php and

        http://www.opensource.org/licenses/lgpl-2.1.php

        Software

          loader:    version 1.2(2) [last: image booted through mgmt0]

          kickstart: version 4.0(4)SV1(2) 

          system:    version 4.0(4)SV1(2) 

          kickstart image file is:

          kickstart compile time:  8/10/2009 15:00:00

          system image file is:    bootflash:/s78-mz.bin

          system compile time:     8/10/2009 15:00:00 [08/11/2009 02:42:38]

        Hardware

          Cisco Nexus 1000V Chassis ("Virtual Supervisor Module")

          Intel(R) Xeon(R) CPU         with 2075012 kB of memory.

          Processor Board ID T5056AF0C29

          Device name: switch

          bootflash:    3122988 kB

        Kernel uptime is 1 day(s), 0 hour(s), 15 minute(s), 15 second(s)

        plugin

          Core Plugin, Ethernet Plugin

switch#

Step 7 Do one of the following:

•If the new software version is present on the VSM, continue with the next step.

•If not, then return to Step 1.

Step 8 You have completed this procedure. Return to Figure 2.

---

Initiating and Monitoring the VEM Software Upgrade

The Network Administrator uses this procedure to initiate and monitor the upgrade of the VEMs to a new software version.

BEFORE YOU BEGIN

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

•The VEM upgrade is started when it is attached to the VSM. During the upgrade process, VEMs re-attach to the VSM.

•You are logged in to the CLI in EXEC mode.

•You have already upgraded the VSM to the new software version.

•Network and Server Administrators have agreed upon a window of time for the VEM upgrade.

---

Step 1 Using the following command, notify the vCenter Server that the software on the VSM has been upgraded, and a VEM upgrade is available.

vmware vem upgrade notify

Example:

n1000v# vmware vem upgrade notify

n1000v#

Step 2 Verify that the upgrade notification was sent.

show vmware vem upgrade status

Example:

n1000v# show vmware vem upgrade status

Upgrade Status: Upgrade Availability Notified in vCenter

Upgrade Notification Sent Time: Tue Sep  8 17:37:23 2009

Upgrade Status Time(vCenter):

Upgrade Start Time:

Upgrade End Time(vCenter):

Upgrade Error:

n1000v#

The Server Administrator is notified that an upgrade is available.
The Server Administrator can accept or reject the upgrade.

Step 3 Verify that the Server Administrator has accepted the upgrade.

show vmware vem upgrade status

Example:

n1000v# show vmware vem upgrade status

Upgrade Status: Upgrade Accepted by vCenter Admin

Upgrade Notification Sent Time: Tue Sep  8 17:37:23 2009

Upgrade Status Time(vCenter): Tue Sep  8 17:40:13 2009

Upgrade Start Time:

Upgrade End Time(vCenter):

Upgrade Error:

n1000v#

Once the Server Administrator accepts the upgrade, the VEM upgrade can proceed.

Step 4 Using the following command, start the upgrade of the VEM.

vmware vem upgrade proceed

Example:

n1000v# vmware vem upgrade proceed

n1000v#

vCenter locks the DVS and triggers VUM to upgrade the VEMs.

Step 5 Verify that the upgrade has started.

show vmware vem upgrade status

Example:

n1000v# show vmware vem upgrade status

Upgrade Status: Upgrade In Progress in vCenter

Upgrade Notification Sent Time: Tue Sep  8 17:37:23 2009

Upgrade Status Time(vCenter): Tue Sep  8 17:52:10 2009

Upgrade Start Time: Tue Sep  8 17:52:08 2009

Upgrade End Time(vCenter):

Upgrade Error:

n1000v#

When the VEM upgrade is complete, the status is updated in the VSM.

Step 6 Verify that the upgrade completed.

show vmware vem upgrade status

Example:

n1000v# show vmware vem upgrade status

Upgrade Status: Upgrade Complete in vCenter

Upgrade Notification Sent Time: Tue Sep  8 17:37:23 2009

Upgrade Status Time(vCenter): Tue Sep  8 17:45:05 2009

Upgrade Start Time: Tue Sep  8 17:42:02 2009

Upgrade End Time(vCenter): Tue Sep  8 17:45:02 2009

Upgrade Error:

n1000v#

When the VEM upgrade is complete, you can clear the status in the VSM.

Step 7 Do one of the following:

•If the upgrade was successfully completed, continue with the next step.

•If not, repeat Step 4 through Step 6.

Step 8 Using the following command, clear the VEM upgrade status.

vmware vem upgrade complete

---

Note Once you have cleared the upgrade status, you cannot repeat this procedure.

---

Example:

n1000v# vmware vem upgrade complete

n1000v#

The VEM upgrade status is cleared.

Step 9 Verify that the VEM status is cleared.

show vmware vem upgrade status

Example:

n1000v# show vmware vem upgrade status

Upgrade Status:

Upgrade Notification Sent Time:

Upgrade Status Time(vCenter):

Upgrade Start Time:

Upgrade End Time(vCenter):

Upgrade Error:n1000v#

You have completed this procedure. Return to Figure 2.

---

Changing the Feature Support Level

The Network Administrator uses this procedure, after all VEMs in the domain are upgraded, to allow the VSM to support all of the new features in the new software version.

BEFORE YOU BEGIN

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

•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.

•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.

SUMMARY STEPS

1. show system vem feature level

2. system update vem feature level

3. system update vem feature level feature level index

4. show system vem feature level

DETAILED STEPS

	Command	Purpose
Step 1	show system vem feature level Example: n1000v# show system vem feature level current feature level: 4.0(4)SV1(1) n1000v#	Displays the current level of feature support.
Step 2	system update vem feature level Example: n1000v# system update vem feature level 1 4.0(4)SV1(2)	Displays output based on the current VEM feature and the version of the VEMs. If all VEMs are upgraded to the new software version, then the feature support can be upgraded to the new software version. If even one VEM is still running the previous software version, then the feature support level cannot be upgraded, and the list will be empty.
Step 3	system update vem feature level feature levelindex Example: n1000v# old feature level: 4.0(4)SV1(1)new feature level: 4.0(4)SV1(2)	This command changes the feature level to the one indicated by the index from the list displayed when you type the system update vem feature level command. After the feature level upgrade, VEMs with versions older than the feature level are no longer allowed to connect to the VSM.
Step 4	show system vem feature level Example: n1000v# show system vem feature level current feature level: 4.0(4)SV1(2) n1000v#	Displays the updated level of feature support.
	You have completed this procedure. Return to Figure 2.

Verifying Connectivity to the VEMs

The Network Administator uses this procedure to verify that all VEMs have reconnected with the VSM.

BEFORE YOU BEGIN

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

•You are logged in to the CLI in EXEC mode.

•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 1 Verify that the VEM status is OK in the output of the following command.

show module

Example:

switch# show module

Mod  Ports  Module-Type                      Model              Status

---  -----  -------------------------------- ------------------ ------------

1    0      Virtual Supervisor Module        Nexus1000V         active *

2    0      Supervisor/Fabric-1                                 ha-standby

3    248    Virtual Ethernet Module          NA                 ok

4    248    Virtual Ethernet Module          NA                 ok 

5    248    Virtual Ethernet Module          NA                 ok

Mod  Sw               Hw

---  ---------------  ------

1    4.0(4)SV1(2)     0.0

3    4.0(4)SV1(2)     0.4 

4    4.0(4)SV1(2)     0.4 

5    4.0(4)SV1(2)     0.4

Mod  MAC-Address(es)                         Serial-Num

---  --------------------------------------  ----------

1    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA

3    02-00-0c-00-03-00 to 02-00-0c-00-03-80  NA

4    02-00-0c-00-04-00 to 02-00-0c-00-04-80  NA

5    02-00-0c-00-05-00 to 02-00-0c-00-05-80  NA

Mod  Server-IP        Server-UUID                           Server-Name

---  ---------------  ------------------------------------  --------------------

1    10.78.27.97      NA                                    NA

3    10.78.27.94      44454c4c-4800-104e-804d-b1c04f563153  10.78.27.94

4    10.78.27.95      44454c4c-5100-104c-8036-b3c04f593153  10.78.27.95

5    10.78.27.96      44454c4c-5300-104b-8044-c3c04f573153  10.78.27.96

* this terminal session

switch#

You have completed this procedure. Return to Figure 2.

---

Upgrading the VEMs

The Server Administrator uses this section to upgrade the VEMs to a new software version.

Prerequisites

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

•You are logged in to the CLI in EXEC mode.

•Network and Server Administrators have agreed to a timeframe for the upgrade.

•The VSM upgrade should occur right before the VEM upgrade.

•You have received a notification in vCenter that a VEM software upgrade is available.

•If you are not using VUM, but are instead manually upgrading the VEM software, you have a copy of the Cisco Nexus 1000V Virtual Ethernet Module Software Installation Guide, Release 4.0(4)SV1(2)

•If you are using a proxy server to connect VUM to the Internet, you may need to disable the proxy before starting a VUM upgrade of your VEMs. In VMware versions before VUM Update 1, the proxy prevents VUM from communicating locally with the VSM. For this reason automatic VEM upgrades may fail if the proxy is not disabled first.

•Connectivity to the VSM can be lost during a VEM upgrade when the VSM VM interfaces connect to its own DVS.

•Connectivity between the active and standby VSM can be lost during a VEM upgrade when the VEM being upgraded provides interface connectivity to one VSM in the pair. In this case, both VSMs become active and lose connectivity. Use the following workaround:

–Power off the VSM connected to the VEM.

–Manually upgrade the VEM that provides interface connectivity to one VSM in the pair.

Flow Chart: Upgrading VEMs with a Standalone VSM

The following flow chart will guide you through this process. After completing each procedure, return to the flow chart to make sure you complete all required procedures in the correct sequence.

Figure 3 Flow Chart:   Upgrading VEMs with a Standalone VSM

Flow Chart: Upgrading VEMs with Dual VSMs

The following flow chart will guide you through this process. After completing each procedure, return to the flow chart to make sure you complete all required procedures in the correct sequence.

Figure 4 Flow Chart:   Upgrading VEMs with Dual VSMs

Accepting the VEM Upgrade

The Server Administrator uses this procedure to accept the VEM upgrade after the Network Administrator has upgraded the VSM and notified vCenter server of the availability of the new VEM software version.

BEFORE YOU BEGIN

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

•You are logged in to vCenter client.

•The Network Administrator has already upgraded the VSM to the new software version.

•If you are using a proxy server to connect VUM to the Internet, you may need to disable the proxy before starting a VUM upgrade of your VEMs. In VMware versions before VUM Update 1, the proxy prevents VUM from communicating locally with the VSM. For this reason automatic VEM upgrades may fail if the proxy is not disabled first.

DETAILED STEPS

---

Step 1 In the vSphere Client DVS Summary tab, check for the availability of a software upgrade.

The following message appears in the Summary tab:

An upgrade for the Distributed Virtual Switch in datacenter is available.

Step 2 Click Apply upgrade.

The following actions are triggered:

•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.

You have completed this procedure. Return to the flow chart that directed you here:

•Flow Chart:   Upgrading VEMs with a Standalone VSM

•Flow Chart:   Upgrading VEMs with Dual VSMs

---

Related Documentation

Cisco Nexus 1000V includes the following documents available on Cisco.com:

General Information

Cisco Nexus 1000V Release Notes, Release 4.0(4)SV1(2)

Cisco Nexus 1000V Compatibility Information, Release 4.0(4)SV1(2)

Install and Upgrade

Cisco Nexus 1000V Software Installation Guide, Release 4.0(4)SV1(2)

Cisco Nexus 1000V Virtual Ethernet Module Software Installation Guide, Release 4.0(4)SV1(2)

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

Configuration Guides

Cisco Nexus 1000V License Configuration Guide, Release 4.0(4)SV1(2)

Cisco Nexus 1000V Getting Started Guide, Release 4.0(4)SV1(2)

Cisco Nexus 1000V Interface Configuration Guide, Release 4.0(4)SV1(2)

Cisco Nexus 1000V Layer 2 Switching Configuration Guide, Release 4.0(4)SV1(2)

Cisco Nexus 1000V Port Profile Configuration Guide, Release 4.0(4)SV1(2)

Cisco Nexus 1000V Quality of Service Configuration Guide, Release 4.0(4)SV1(2)

Cisco Nexus 1000V Security Configuration Guide, Release 4.0(4)SV1(2)

Cisco Nexus 1000V System Management Configuration Guide, Release 4.0(4)SV1(2)

Cisco Nexus 1000V High Availability and Redundancy Configuration Guide, Release 4.0(4)SV1(2)

Cisco Nexus 1000V XML API User Guide, Release 4.0(4)SV1(2)

Programming Guide

Cisco Nexus 1000V XML API User Guide, Release 4.0(4)SV1(2)

Reference Guides

Cisco Nexus 1000V Command Reference, Release 4.0(4)SV1(2)

Cisco Nexus 1000V MIB Quick Reference

Troubleshooting and Alerts

Cisco Nexus 1000V Troubleshooting Guide, Release 4.0(4)SV1(2)

Cisco Nexus 1000V Password Recovery Guide

Cisco NX-OS System Messages Reference

Obtaining Documentation and Submitting a Service Request

For information about obtaining documentation, submitting a service request, and gathering additional information, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:

http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html

Subscribe to the What's New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS version 2.0.

---

This document is to be used in conjunction with the documents listed in the "Related Documentation" section.

CCDE, CCENT, CCSI, Cisco Eos, Cisco Explorer, Cisco HealthPresence, Cisco IronPort, the Cisco logo, Cisco Nurse Connect, Cisco Pulse, Cisco SensorBase, Cisco StackPower, Cisco StadiumVision, Cisco TelePresence, Cisco TrustSec, Cisco Unified Computing System, Cisco WebEx, DCE, Flip Channels, Flip for Good, Flip Mino, Flipshare (Design), Flip Ultra, Flip Video, Flip Video (Design), Instant Broadband, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn, Cisco Capital, Cisco Capital (Design), Cisco:Financed (Stylized), Cisco Store, Flip Gift Card, and One Million Acts of Green are service marks; and Access Registrar, Aironet, AllTouch, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Lumin, Cisco Nexus, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, Continuum, EtherFast, EtherSwitch, Event Center, Explorer, Follow Me Browsing, GainMaker, iLYNX, IOS, iPhone, IronPort, the IronPort logo, Laser Link, LightStream, Linksys, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, PCNow, PIX, PowerKEY, PowerPanels, PowerTV, PowerTV (Design), PowerVu, Prisma, ProConnect, ROSA, SenderBase, SMARTnet, Spectrum Expert, StackWise, WebEx, and the WebEx logo are registered trademarks of Cisco and/or its affiliates in the United States and certain other countries.

All other trademarks mentioned in this document or website 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. (1002R)

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