Cisco Nexus 1000V Installation and Upgrade Guide, Release 4.2(1)SV1(5.1)
Upgrade VSMs and VEMs
Downloads: This chapterpdf (PDF - 652.0KB) The complete bookPDF (PDF - 10.1MB) | Feedback

Upgrading the Cisco Nexus 1000V

Table Of Contents

Upgrading the Cisco Nexus 1000V

Information About the Software Upgrade

Obtaining the Upgrade Software

Prerequisites for the Upgrade

Prerequisites for Upgrading VSMs

Prerequisites for Upgrading VEMs

Guidelines and Limitations for Upgrading the Cisco Nexus 1000V

Upgrade Paths

Upgrading to Release 4.2(1)SV1(5.1)

Upgrading from Releases 4.2(1)SV1(4), 4.2(1)SV1(4a), or 4.2(1)SV1(4b) to Release 4.2(1)SV1(5.1)

Upgrading the VSMs from Release 4.2(1)SV1(4), 4.2(1)SV1(4a), or 4.2(1)SV1(4b) to Release 4.2(1)SV1(5.1)

Upgrading the VEMs from Release 4.2(1)SV1(4), 4.2(1)SV1(4a), or 4.2(1)SV1(4b) to Release 4.2(1)SV1(5.1)

Upgrading from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(5.1)

Upgrading the VEM Software Using VUM

Migrating from Layer 2 to Layer 3

Prerequisites for Migrating from Layer 2 to Layer 3

Layer 3 Advantages

Interface Comparisions Between mgmt0 and control0

Configuring the Layer 3 Interface

Creating a Port Profile with Layer 3 Control Capability

Creating a VMKernel on the Host

Configuring the SVS-Domain in the VSM

Feature History for Upgrading the Cisco Nexus 1000V


Upgrading the Cisco Nexus 1000V


This chapter describes the upgrade procedures for the Cisco Nexus 1000V.


Note An interactive upgrade tool has been provided to assist you in determining the correct upgrade steps based on your current environment and the one to which you want to upgrade.


This chapter includes the following sections:

Information About the Software Upgrade

Prerequisites for the Upgrade

Guidelines and Limitations for Upgrading the Cisco Nexus 1000V

Upgrading to Release 4.2(1)SV1(5.1)

Migrating from Layer 2 to Layer 3

Feature History for Upgrading the Cisco Nexus 1000V

Information About the Software Upgrade

This section provides information on upgrading to the Cisco Nexus 1000V to Release 4.2(1)SV1(5.1).

This section includes the following topic:

Obtaining the Upgrade Software

Obtaining the Upgrade Software

You can obtain your upgrade-related software from the following sources listed in Table 3-1.

Table 3-1 Obtaining the Upgrade Software

Source
Description

Cisco

Download the Cisco Nexus 1000V Release 4.2(1)SV1(5.1) software from Cisco.com.

VMware

Download VMware software from the VMware website.


For information about your software and platform compatibility, see the Cisco Nexus 1000V Compatibility Information, Release 4.2(1)SV1(5.1).

Prerequisites for the Upgrade

This section describes how to upgrade the Cisco Nexus 1000V software on a Virtual Supervisor Module (VSM) virtual machine (VM) and how to upgrade the Virtual Ethernet Module (VEM).

Upgrading the Cisco Nexus 1000V VSMs and VEMs and includes the following topics:

Prerequisites for Upgrading VSMs

Prerequisites for Upgrading VEMs

Prerequisites for Upgrading VSMs

Upgrading the VSMs has the following prerequisites:

Close any active configuration sessions before upgrading the Cisco Nexus 1000V software.

Note that the network and server administrators must coordinate the upgrade procedure with each other.

Saved all changes in the running configuration to the startup configuration, to be preserved through the upgrade.

Saved a backup copy of the running configuration in external storage.

Perform a VSM backup. For more information, see the "Configuring VSM Backup and Recovery" chapter in the Cisco Nexus 1000V System Management Configuration Guide, Release 4.2(1)SV1(5.1).

Use the VSM management IP address to log into VSM and perform management tasks.


Note If you connect to a VSM using the VSA serial port or the "connect host" from the CIMC, do not initiate commands that are CPU intensive, such as copying image from tftp server to bootflash or generate a lot of screen output or updates. Use the VSA serial connections, including CIMC, only for operations such as debugging or basic configuration of the VSA.(CSCti57822)


Prerequisites for Upgrading VEMs

Upgrading the Cisco Nexus 1000V VEM software has the following prerequisites.


Caution If the VMware vCenter Server is hosted on the same ESX/ESXi host as a Cisco Nexus 1000V VEM, a VMware Update Manager (VUM)-assisted upgrade on the host will fail. You should manually vMotion the vCenter Server VM to another host before you perform an upgrade.


Note When you perform any VUM operation on hosts that are a part of a cluster, ensure that VMWare high availability (HA), VMware fault tolerance (FT), and VMware Distributed Power Management (DPM) features are disabled for the entire cluster. Otherwise, VUM will fail to install the hosts in the cluster.


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

Network and server administrators coordinate the VEM upgrade with each other.

You have a copy of your VMware documentation available for installing software on a host.

You have already obtained a copy of the VEM software file from one of the sources listed in Table 2-1.For more information, see the Cisco Nexus 1000V Compatibility Information, Release 4.2(1)SV1(5.1).

You have placed the VEM software file in /tmp on the vSphere host. Placing it in the root (/) directory might interfere with the upgrade. Make sure that the root RAM disk has at least 12 MB of free space as displayed by the vdf command.

On your upstream switches, you must have the following configuration.

On Catalyst 6500 Series Switches with Cisco IOS software:
(config-if) portfast trunk
or
(config-if) portfast edge trunk

On Cisco Nexus 5000 Series Switches with Cisco NX-OS software:
(config-if) spanning-tree port type edge trunk

On your upstream switches, we highly recommend that you globally enable the following:

Global BPDU Filtering

Global BPDU Guard

On your upstream switches where you cannot globally enable BPDU Filtering and BPDU Guard, we highly recommended that you enter the following commands:

(config-if) spanning-tree bpdu filter

(config-if) spanning-tree bpdu guard

For more information about configuring spanning tree, BPDU, or PortFast, see the documentation for your upstream switch.

Guidelines and Limitations for Upgrading the Cisco Nexus 1000V

Before attempting to migrate to any software image version, follow these guidelines:

You are upgrading the Cisco Nexus 1000V software to Release 4.2(1)SV1(5.1).

The VSM and VEMs must be at the same code level to be supported.

Scheduling — Schedule the upgrade when your network is stable and steady. Ensure that everyone who has access to the switch or the network is not configuring the switch or the network during this time. You cannot configure a switch during an upgrade.

Hardware — Avoid power interruptions to the hosts that run the VSM VMs during any installation procedure.

Connectivity to remote servers — do the following:

Copy the kickstart and system images from the remote server to the Cisco Nexus 1000V.

Ensure that the switch has a route to the remote server. The switch and the remote server must be in the same subnetwork if you do not have a router to route traffic between subnets.

Software images — do the following:

Make sure that the system and kickstart images are the same version.

Retrieve the images in one of two ways:

Locally—Images are locally available on the upgrade CD-ROM/ISO image.

Remotely—Images are in a remote location and you specify the destination using the remote server parameters and the filename to be used locally.

Commands to use — do the following:

Verify connectivity to the remote server by using the ping command.

Use the one-step install all command to upgrade your software. This command upgrades the VSMs.

Do not enter another install all command while running the installation. You can run commands other than configuration commands.

During theVSM upgrade, if you try to add a new VEM or any of the VEMs are detached due to uplink flaps, the VEM attachment is queued until the upgrade completes.


Note If the VEMs are not compatible with the software image that you install on the VSM, a traffic disruption occurs in those modules, depending on your configuration. The install all command output identifies these scenarios. You can choose to proceed with the upgrade or end at this point.


Before upgrading the VEMs, note these guidelines and limitations:

The VEM software can be upgraded manually using the CLI, or upgraded automatically using VUM.

During the VEM upgrade process, VEMs reattach to the VSM.

Connectivity to the VSM can be lost during a VEM upgrade when the interfaces of a VSM VM connect to its own Distributed Virtual Switch (DVS).

Connectivity between an active and standby VSM can be lost during a VEM upgrade when the VEM being upgraded provides interface connectivity to one of the VSMs. In this case, both VSMs become active and lose connectivity. To prevent this problem, make sure that you are at the appropriate patch levels. See Table 3-1.

If you are upgrading a VEM using a Cisco Nexus 1000V bundle, follow the instructions in your VMware documentation. For more details about VMware bundled software, see the Cisco Nexus 1000V Compatibility Information, Release 4.2(1)SV1(5.1).


Caution Do not enter the vemlog, vemcmd, or vempkt commands during the VEM upgrade process because these commands impact the upgrade.

Upgrade Paths

This section describes how to upgrade the Cisco Nexus 1000V software on a Virtual Supervisor Module (VSM) virtual machine (VM) and how to upgrade the Virtual Ethernet Module (VEM).

Table 3-2 shows the upgrade procedure you must take to upgrade to Release 4.2(1)SV1(5.1).


Note Upgrades from Cisco Nexus 1000V Release 4.0(4)SV1(1) and Cisco Nexus 1000V Release 4.0(4)SV1(2) are no longer supported. VMware 4.0 is also no longer supported.

For upgrade procedures to ESX/ESXi 4.1.0 and ESXi 5.0.0, see


Cisco does not support simultaneous VMware updates or patches in combination with Cisco Nexus 1000V upgrades. The upgrade process in this document is specifically for Cisco Nexus 1000V upgrades across the same VMware platform. For more information, see Table 3-2. and Table 3-4.

The upgrade process is irrevocable. After the software is upgraded, you can downgrade by removing the current installation and reinstalling the software. For more information, see the "Recreating the Installation" section Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(5.1).


Caution During the upgrade process, the Cisco Nexus 1000V does not support any new additions such as modules, Virtual NICs (vNICs), or VM NICs and does not support any configuration changes. VM NIC and vNIC port-profile changes might render VM NICs and vNICs in an unusable state.

Upgrading to Release 4.2(1)SV1(5.1)

This section describes how to upgrade to Release 4.2(1)SV1(5.1).

This section contains the following topics:

Upgrading from Releases 4.2(1)SV1(4), 4.2(1)SV1(4a), or 4.2(1)SV1(4b) to Release 4.2(1)SV1(5.1)

Upgrading from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(5.1)


Note For ESXi 5.0.0 releases and later releases, the minimum VC/VUM version required is 380461/380316
For ESX/ESXi Release 4.1.0 and later releases, the minimum VC/VUM version required is 258902/256596.

This procedure is different from the upgrade to Release 4.2(1)SV1(4). In this procedure, you upgrade the VSMs first by using the install all command and then you upgrade the VEMs.



Caution If your hosts are running a release prior to VMWare 4.1, upgrade to VMWare 4.1 or VMware 5.0. See

Table 3-4 lists the upgrade steps when upgrading to vSphere 5.0 and Release 4.2(1)SV1(5.1).

Upgrading from Releases 4.2(1)SV1(4), 4.2(1)SV1(4a), or 4.2(1)SV1(4b) to Release 4.2(1)SV1(5.1)

The following section describes how to upgrade the Cisco Nexus 1000V software from Releases 4.2(1)SV1(4), 4.2(1)SV1(4a), or 4.2(1)SV1(4b) to Release 4.2(1)SV1(5.1).

This section contains the following topics:

Upgrading the VSMs from Release 4.2(1)SV1(4), 4.2(1)SV1(4a), or 4.2(1)SV1(4b) to Release 4.2(1)SV1(5.1)

Upgrading the VEMs from Release 4.2(1)SV1(4), 4.2(1)SV1(4a), or 4.2(1)SV1(4b) to Release 4.2(1)SV1(5.1)

Table 3-2 lists the upgrade steps when upgrading to vSphere 4.1 and Release 4.2(1)SV1(5.1).

Table 3-2 Upgrade Procedures to vSphere 4.1 and Release 4.2(1)SV1(5.1) 

If you are running this configuration
Follow these steps

Release 4.2(1)SV1(4) with a vSphere release 4.0 Update 1 or later

1.


BEFORE YOU BEGIN

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

The Upgrade Application cannot be used for the upgrade of the VSMs from Release 4.2(1)SV1(4) to Release 4.2(1)SV1(5.1).

A pair of VSMs in a high availability (HA) pair is required in order to support a nondisruptive upgrade.

A system with a single VSM can only be upgraded in a disruptive manner.

When upgrading the VSM from Release 4.2(1)SV1(4) or later to Release 4.2(1)SV1(5.1), if any of the VEM hosts are running a vSphere version prior to 4.1, the install all command displays that host as incompatible. The incompatibility warning applies only if you do not upgrade the ESX version along with the VEM version. It is possible to manually upgrade the ESX and VEM in one maintenance mode as below:

1. Place the host in maintenance mode.

2. Upgrade the ESX to 4.1 or 5.0, as needed.

3. Install the Release 4.2(1)SV1(5.1) VEM VIB, while the host is still in maintenance mode.

4. Remove the host from maintenance mode.

This paired upgrade procedure is not applicable for VUM-based upgrades.

You can abort the upgrade procedure by pressing Ctrl-C.

PROCEDURE


Step 1 Upgrade the VSMs from Release 4.2(1)SV1(4), 4.2(1)SV1(4a), or 4.2(1)SV1(4b) to Release 4.2(1)SV1(5.1). For this procedure, see the "Upgrading the VSMs from Release 4.2(1)SV1(4), 4.2(1)SV1(4a), or 4.2(1)SV1(4b) to Release 4.2(1)SV1(5.1)" section. See Figure 3-1.

Step 2 Upgrade the VEMs from Release 4.2(1)SV1(4), 4.2(1)SV1(4a), or 4.2(1)SV1(4b) to Release 4.2(1)SV1(5.1). For this procedure, see the "Upgrading the VEMs from Release 4.2(1)SV1(4), 4.2(1)SV1(4a), or 4.2(1)SV1(4b) to Release 4.2(1)SV1(5.1)" section. See Figure 3-1.


Figure 3-1 Upgrading from Release 4.2(1)SV1(4), 4.2(1)SV1(4a), or 4.2(1)SV1(4b) to Release 4.2(1)SV1(5.1)

Upgrading the VSMs from Release 4.2(1)SV1(4), 4.2(1)SV1(4a), or 4.2(1)SV1(4b) to Release 4.2(1)SV1(5.1)

This section includes the following topics:

Software Images

In-Service Software Upgrades on Systems with Dual VSMs

Upgrading a System with Dual VSMs Using ISSU

Upgrading a System with Dual VSMs

Software Images

The software image install procedure is dependent on the following factors:

Software images—The kickstart and system image files reside in directories or folders that you can access from the Cisco Nexus 1000V software prompt.

Image version—Each image file has a version.

Disk—The bootflash: resides on the VSM.

ISO file—If a local ISO file is passed to the install all command, the kickstart and system images are extracted from the ISO file.

In-Service Software Upgrades on Systems with Dual VSMs

The Cisco Nexus 1000V software supports in-service software upgrades (ISSUs) for systems with dual VSMs. An ISSU can update the software images on your switch without disrupting data traffic. Only control traffic is disrupted. If an ISSU causes a disruption of data traffic, the Cisco Nexus 1000V software warns you before proceeding so that you can stop the upgrade and reschedule it to a time that minimizes the impact on your network.


Note On systems with dual VSMs, you should have access to the console of both VSMs to maintain connectivity when the switchover occurs during upgrades. If you are performing the upgrade over Secure Shell (SSH) or Telnet, the connection will drop when the system switchover occurs, and you must reestablish the connection.


An ISSU updates the following images:

Kickstart image

System image

VEM images

All of the following processes are initiated automatically by the upgrade process after the network administrator enters the install all command.

Figure 3-2 shows the ISSU process.

Figure 3-2 ISSU Process

Figure 3-3 provides an example of the VSM status before and after an ISSU switchover.

Figure 3-3 Example of an ISSU VSM Switchover

Upgrading a System with Dual VSMs Using ISSU

The install all command supports an in-service software upgrade (ISSU) on dual VSMs in an HA environment and performs the following actions:

Determines whether the upgrade is disruptive and asks if you want to continue.

Copies the kickstart and system images to the standby VSM. Alternatively, if a local ISO file is passed to the install all command instead, the kickstart and system images are extracted from the file.

Sets the kickstart and system boot variables.

Reloads the standby VSM with the new Cisco Nexus 1000V software.

Causes the active VSM to reload when the switchover occurs.

The install all command provides the following benefits:

You can upgrade the VSM by using just one command.

You can receive descriptive information on the intended changes to your system before you continue with the installation.

You have the option to cancel the command. Once the effects of the command are presented, you can continue or cancel when you see this question (the default is no):

Do you want to continue (y/n) [n]: y
 
   

You can upgrade the VSM using the least disruptive procedure.

You can see the progress of this command on the console, Telnet, and SSH screens:

After a switchover process, you can see the progress from both the VSMs.

Before a switchover process, you can only see the progress from the active VSM.

The install all command automatically checks the image integrity, which includes the running kickstart and system images.

The install all command performs a platform validity check to verify that a wrong image is not used.

The Ctrl-C escape sequence gracefully ends the install all command. The command sequence completes the update step in progress and returns to the switch prompt. (Other upgrade steps cannot be ended by using Ctrl-C.)

After running the install all command, if any step in the sequence fails, the command completes the step in progress and ends.

Upgrading a System with Dual VSMs

This section describes how to upgrade to the latest Cisco Nexus 1000V software on a systems with dual VSMs.

PROCEDURE


Step 1 Log in to the active VSM.

Step 2 Log in to Cisco.com to access the links provided in this document. To log in to Cisco.com, go to the URL http://www.cisco.com/ and click Log In at the top of the page. Enter your Cisco username and password.


Note Unregistered cisco.com users cannot access the links provided in this document.


Step 3 Access the Software Download Center by using this URL: http://www.cisco.com/public/sw-center/index.shtml

Step 4 Navigate to the download site for your system.

You see links to the download images for your switch.

Step 5 Choose and download the Cisco Nexus 1000V zip file and extract the kickstart and system software files to a server.

Step 6 Ensure that the required space is available for the image file(s) to be copied.

switch# dir bootflash:
.
.
.
Usage for bootflash://
  485830656 bytes used
 1109045248 bytes free
 1594875904 bytes total
 
   

Tip We recommend that you have the kickstart and system image files for at least one previous release of the Cisco Nexus 1000V software on the system to use if the new image files do not load successfully.


Step 7 Verify that there is space available on the standby VSM.

switch# dir bootflash://sup-standby/
.
.
.
Usage for bootflash://
  485830656 bytes used
 1109045248 bytes free
 1594875904 bytes total
 
   

Step 8 Delete any unnecessary files to make space available if you need more space on the standby VSM.

Step 9 If you plan to install the images from the bootflash:, copy the Cisco Nexus 1000V kickstart and system images or the ISO image to the active VSM by using a transfer protocol. You can use ftp:, tftp:, scp:, or sftp:. The examples in this procedure use scp:.


Note When you download an image file, change to your FTP environment IP address or DNS name and the path where the files are located.


Copy ISO image.

switch# copy scp://user@scpserver.cisco.com/downloads/nexus-1000v.4.2.1.SV1.5.1.iso 
bootflash:nexus-1000v.4.2.1.SV1.5.1.iso 
 
   

Copy kickstart and system images.

switch# copy 
scp://user@scpserver.cisco.com/downloads/nexus-1000v-kickstart-mz.4.2.1.SV1.5.1.bin
bootflash:nexus-1000v-kickstart-mz.4.2.1.SV1.5.1.bin
switch# copy scp://user@scpserver.cisco.com/downloads/nexus-1000v-mz.4.2.1.SV1.5.1.bin
bootflash:nexus-1000v-mz.4.2.1.SV1.5.1.bin
 
   

Step 10 Check on the impact of the ISSU upgrade for the kickstart and system images or the ISO image.

ISO

switch# show install all impact iso bootflash:nexus-1000v.4.2.1.SV1.5.1.iso 
 
   
Verifying image bootflash:/nexus-1000v-kickstart-4.2.1.SV1.5.1.bin for boot variable 
"kickstart".
[####################] 100% -- SUCCESS
 
   
Verifying image bootflash:/nexus-1000v-4.2.1.SV1.5.1.bin for boot variable "system".
[####################] 100% -- SUCCESS
 
   
Verifying image type.
[####################] 100% -- SUCCESS
 
   
Extracting "system" version from image bootflash:/nexus-1000v-4.2.1.SV1.5.1.bin.
[####################] 100% -- SUCCESS
 
   
Extracting "kickstart" version from image 
bootflash:/nexus-1000v-kickstart-4.2.1.SV1.5.1.bin.
[####################] 100% -- SUCCESS
 
   
Notifying services about system upgrade.
[####################] 100% -- SUCCESS
 
   
 
   
 
   
Compatibility check is done:
Module  bootable          Impact  Install-type  Reason
------  --------  --------------  ------------  ------
     1       yes  non-disruptive         reset  
     2       yes  non-disruptive         reset  
 
   
 
   
Images will be upgraded according to following table:
Module       Image         Running-Version             New-Version  Upg-Required
------  ----------  ----------------------  ----------------------  ------------
     1      system            4.2(1)SV1(4a)           4.2(1)SV1(5.1)           yes
     1   kickstart            4.2(1)SV1(4a)           4.2(1)SV1(5.1)           yes
     2      system            4.2(1)SV1(4a)           4.2(1)SV1(5.1)           yes
     2   kickstart            4.2(1)SV1(4a)           4.2(1)SV1(5.1)           yes
 
   
 
   
Module         Running-Version                                         ESX Version       
VSM Compatibility       ESX Compatibility
------  ----------------------  ----------------------------------------------------  
----------------------  ----------------------
     3           4.2(1)SV1(4a)         VMware ESXi 5.0.0 Releasebuild-469512 (3.0)              
COMPATIBLE              COMPATIBLE
     4           4.2(1)SV1(4a)         VMware ESXi 5.0.0 Releasebuild-469512 (3.0)              
COMPATIBLE              COMPATIBLE
 
   

kickstart and system

switch# show install all impact kickstart 
bootflash:nexus-1000v-kickstart-mz.4.2.1.SV1.5.1.bin system 
bootflash:nexus-1000v-mz.4.2.1.SV1.5.1.bin 
 
   
Verifying image bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.5.1.bin for boot 
variable "kickstart".
[####################] 100% -- SUCCESS
 
   
Verifying image bootflash:/nexus-1000v-mz.4.2.1.SV1.5.1.bin for boot variable 
"system".
[####################] 100% -- SUCCESS
 
   
Verifying image type.
[####################] 100% -- SUCCESS
 
   
Extracting "system" version from image bootflash:/nexus-1000v-mz.4.2.1.SV1.5.1.bin.
[####################] 100% -- SUCCESS
 
   
Extracting "kickstart" version from image 
bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.5.1.bin.
[####################] 100% -- SUCCESS
 
   
Notifying services about system upgrade.
[####################] 100% -- SUCCESS
 
   
 
   
 
   
Compatibility check is done:
Module  bootable          Impact  Install-type  Reason
------  --------  --------------  ------------  ------
     1       yes  non-disruptive         reset  
     2       yes  non-disruptive         reset  
 
   
 
   
Images will be upgraded according to following table:
Module       Image         Running-Version             New-Version  Upg-Required
------  ----------  ----------------------  ----------------------  ------------
     1      system            4.2(1)SV1(4a)           4.2(1)SV1(5.1)           yes
     1   kickstart            4.2(1)SV1(4a)           4.2(1)SV1(5.1)           yes
     2      system            4.2(1)SV1(4a)           4.2(1)SV1(5.1)           yes
     2   kickstart            4.2(1)SV1(4a)           4.2(1)SV1(5.1)           yes
 
   
 
   
Module         Running-Version                                         ESX Version       
VSM Compatibility       ESX Compatibility
------  ----------------------  ----------------------------------------------------  
----------------------  ----------------------
     3           4.2(1)SV1(4a)         VMware ESXi 5.0.0 Releasebuild-469512 (3.0)              
COMPATIBLE              COMPATIBLE
     4           4.2(1)SV1(4a)         VMware ESXi 5.0.0 Releasebuild-469512 (3.0)              
COMPATIBLE              COMPATIBLE
 
   

Step 11 Read the release notes for the related image file. See the Cisco Nexus 1000V Release Notes, Release 4.2(1)SV1(5.1).

Step 12 Determine if the Virtual Security Gateway (VSG) is configured in the deployment.

If the following output is displayed, VSG is configured in the deployment. You must follow the upgrade procedure in the "Complete Upgrade Procedure" section in Chapter 7, "Upgrading the Cisco Virtual Secutiry Gateway and Cisco Virtual Network Management Center" of the Cisco Virtual Security Gateway, Release 4.2(1)VSG1(3.1) and Cisco Virtual Network Management Center Release 1.3 Installation and Upgrade Guide.

switch# show vnm-pa status 
VNM Policy-Agent status is - Installed Successfully. Version 1.2(0.689)-vsm
switch#
 
   

If the following output is displayed, continue to Step 13.

switch# show vnm-pa status 
VNM Policy-Agent status is - Not Installed
switch#
 
   

Step 13 Save the running configuration to the startup configuration.

switch# copy running-config startup-config 
 
   

Step 14 Save the running configuration on the bootflash and externally.

switch# copy running-config bootflash:run-cfg-backup 
switch# copy running-config scp://user@tftpserver.cisco.com/n1kv-run-cfg-backup

Note You can also run a VSM backup. See the "Configuring VSM Backup and Recovery" chapter of the Cisco Nexus 1000V System Management Configuration Guide, Release 4.2(1)SV1(5.1).


Step 15 Perform the upgrade on the active VSM using the ISO or kickstart and system images.

Upgrade using the ISO image.

switch# install all kickstart bootflash:nexus-1000v-kickstart-4.2.1.SV1.5.1.bin system 
bootflash:nexus-1000v.4.2.1.SV1.5.1.iso 
switch# install all iso bootflash:nexus-1000v.4.2.1.SV1.5.1.iso 
 
   

Upgrade using the kickstart and system images.

switch# install all kickstart bootflash:nexus-1000v-kickstart-mz.4.2.1.SV1.5.1.bin 
system bootflash:nexus-1000v-mz.4.2.1.SV1.5.1.bin
 
   
 
   
Verifying image bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.5.1.bin for boot variable 
"kickstart".
[####################] 100% -- SUCCESS
 
   
Verifying image bootflash:/nexus-1000v-mz.4.2.1.SV1.5.1.bin for boot variable "system".
[####################] 100% -- SUCCESS
 
   
Verifying image type.
[####################] 100% -- SUCCESS
 
   
Extracting "system" version from image bootflash:/nexus-1000v-mz.4.2.1.SV1.5.1.bin.
[####################] 100% -- SUCCESS
 
   
Extracting "kickstart" version from image 
bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.5.1.bin.
[####################] 100% -- SUCCESS
 
   
Notifying services about system upgrade.
[####################] 100% -- SUCCESS
 
   
 
   
 
   
Compatibility check is done:
Module  bootable          Impact  Install-type  Reason
------  --------  --------------  ------------  ------
     1       yes  non-disruptive         reset  
     2       yes  non-disruptive         reset  
 
   
 
   
 
   
Images will be upgraded according to following table:
Module       Image         Running-Version             New-Version  Upg-Required
------  ----------  ----------------------  ----------------------  ------------
     1      system            4.2(1)SV1(4a)           4.2(1)SV1(5.1)           yes
     1   kickstart            4.2(1)SV1(4a)           4.2(1)SV1(5.1)           yes
     2      system            4.2(1)SV1(4a)           4.2(1)SV1(5.1)           yes
     2   kickstart            4.2(1)SV1(4a)           4.2(1)SV1(5.1)           yes
 
   
 
   
Module         Running-Version                                         ESX Version       
VSM Compatibility       ESX Compatibility
------  ----------------------  ----------------------------------------------------  
----------------------  ----------------------
     3           4.2(1)SV1(4a)         VMware ESXi 5.0.0 Releasebuild-469512 (3.0)              
COMPATIBLE              COMPATIBLE
     4           4.2(1)SV1(4a)         VMware ESXi 5.0.0 Releasebuild-469512 (3.0)              
COMPATIBLE              COMPATIBLE
 
   
Do you want to continue with the installation (y/n)?  [n]
 
   

Step 16 Continue with the installation by pressing Y.


Note If you press N, the installation exits gracefully.


Install is in progress, please wait.
 
   
Syncing image bootflash:/nexus-1000v-kickstart-4.2.1.SV1.5.1.bin to standby.
[####################] 100% -- SUCCESS
 
   
Syncing image bootflash:/nexus-1000v-4.2.1.SV1.5.1.bin to standby.
[####################] 100% -- SUCCESS
 
   
Setting boot variables.
[####################] 100% -- SUCCESS
 
   
Performing configuration copy.
[####################] 100%2011 Mar 31 03:49:42 BL1-VSM 
%SYSMGR-STANDBY-5-CFGWRITE_STARTED: Configuration copy started (PID 3660).
[####################] 100% -- SUCCESS

Note As part of the upgrade process, the standby VSM is reloaded with new images. Once it becomes the HA standby again, the upgrade process initiates a switchover. The upgrade then continues from the new active VSM with the following output.


Continuing with installation, please wait
 
   
Module 2: Waiting for module online
-- SUCCESS
 
   
Install has been successful 
 
   

Step 17 After the installation operation completes, log in and verify that the switch is running the required software version.

switch# show version
Nexus1000v# show version
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2012, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained herein are owned by
other third parties and are used and distributed under license.
Some parts of this software are covered under the GNU Public
License. A copy of the license is available at
http://www.gnu.org/licenses/gpl.html.
 
   
Software
  loader:    version unavailable [last: loader version not available]
  kickstart: version 4.2(1)SV1(5.1) [build 4.2(1)SV1(5.1)]
  system:    version 4.2(1)SV1(5.1) [build 4.2(1)SV1(5.1)]
  kickstart image file is: bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.5.1.bin
  kickstart compile time:  1/11/2012 3:00:00 [01/11/2012 12:49:49]
  system image file is:    bootflash:/nexus-1000v-mz.4.2.1.SV1.5.1.bin
  system compile time:     1/11/2012 3:00:00 [01/11/2012 13:42:57]
 
   
 
   
Hardware
  cisco Nexus 1000V Chassis ("Virtual Supervisor Module")
  Intel(R) Xeon(R) CPU         with 2075740 kB of memory.
  Processor Board ID T5056B1802D
 
   
  Device name: Nexus1000v
  bootflash:    1557496 kB
 
   
Kernel uptime is 4 day(s), 8 hour(s), 31 minute(s), 3 second(s)
 
   
 
   
plugin
  Core Plugin, Ethernet Plugin, Virtualization Plugin
...
 
   

Step 18 Copy the running configuration to the startup configuration to adjust the startup-cfg size. (CSCtx01740)

switch# copy running-config startup-config 
[########################################] 100% 
switch#
 
   

Step 19 Display the log of the last installation.

switch# show install all status 
This is the log of last installation.
 
   
Verifying image bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.5.1.bin for boot variable 
"kickstart".
 
   
 -- SUCCESS
 
   
Verifying image bootflash:/nexus-1000v-mz.4.2.1.SV1.5.1.bin for boot variable "system".
 
   
 -- SUCCESS
 
   
Verifying image type.
 
   
 -- SUCCESS
 
   
Extracting "system" version from image bootflash:/nexus-1000v-mz.4.2.1.SV1.5.1.bin.
 
   
 -- SUCCESS
 
   
Extracting "kickstart" version from image 
bootflash:/nexus-1000v-kickstart-mz.4.2.1.SV1.5.1.bin.
 
   
 -- SUCCESS
 
   
Notifying services about system upgrade.
 
   
 -- SUCCESS
 
   
 
   
Compatibility check is done:
Module  bootable          Impact  Install-type  Reason
------  --------  --------------  ------------  ------
     1       yes  non-disruptive         reset
     2       yes  non-disruptive         reset
 
   
 
   
 
   
Images will be upgraded according to following table:
Module       Image         Running-Version             New-Version  Upg-Required
------  ----------  ----------------------  ----------------------  ------------
     1      system           4.2(1)SV1(4a)          4.2(1)SV1(5.1)           yes
     1   kickstart           4.2(1)SV1(4a)          4.2(1)SV1(5.1)           yes
     2      system           4.2(1)SV1(4a)          4.2(1)SV1(5.1)           yes
     2   kickstart           4.2(1)SV1(4a)          4.2(1)SV1(5.1)           yes
 
   
 
   
Images will be upgraded according to following table:
Module         Running-Version                                         ESX Version       
VSM Compatibility       ESX Compatibility
------  ----------------------  ----------------------------------------------------  
----------------------  ----------------------
     3           4.2(1)SV1(4a)         VMware ESXi 5.0.0 Releasebuild-469512 (3.0)              
COMPATIBLE              COMPATIBLE
     4           4.2(1)SV1(4a)         VMware ESXi 5.0.0 Releasebuild-469512 (3.0)              
COMPATIBLE              COMPATIBLE
 
   
 
   
Install is in progress, please wait.
 
   
Syncing image bootflash:/nexus-1000v-kickstart-4.2.1.SV1.5.1.bin to standby.
 -- SUCCESS
 
   
Syncing image bootflash:/nexus-1000v-4.2.1.SV1.5.1.bin to standby.
 -- SUCCESS
 
   
Setting boot variables.
 -- SUCCESS
 
   
Performing configuration copy.
 -- SUCCESS
 
   
Module 2: Waiting for module online.
 -- SUCCESS
 
   
Notifying services about the switchover.
 -- SUCCESS
 
   
 
   
"Switching over onto standby".
switch#
switch#
switch#
 
   
switch# attach module 2 
Attaching to module 2 ...
To exit type 'exit', to abort type '$.'
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2011, 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
switch(standby)#
switch(standby)# show in
incompatibility   install           interface         inventory
switch(standby)# show install all status
This is the log of last installation.
 
   
Continuing with installation, please wait
Trying to start the installer...
 
   
Module 2: Waiting for module online.
 -- SUCCESS
 
   
Install has been successful.
switch(standby)#

Upgrading the VEMs from Release 4.2(1)SV1(4), 4.2(1)SV1(4a), or 4.2(1)SV1(4b) to Release 4.2(1)SV1(5.1)

This section describes how to upgrade VEMs from Release 4.2(1)SV1(4), 4.2(1)SV1(4a), or 4.2(1)SV1(4b) to Release 4.2(1)SV1(5.1) and includes the following topics:

Choosing a VEM Software Upgrade Procedure

Upgrading the VEMs Using VMware Update Manager from Release 4.2(1)SV1(4), 4.2(1)SV1(4a), or 4.2(1)SV1(4b) to Release 4.2(1)SV1(5.1)

Upgrading the VEMs Manually from Release 4.2(1)SV1(4), 4.2(1)SV1(4a), or 4.2(1)SV1(4b) to Release 4.2(1)SV1(5.1)

Choosing a VEM Software Upgrade Procedure

This section describes how you can upgrade the ESX/ESXi host with the VEM software installed or install or upgrade the VEM software:

Figure 3-4 and Figure 3-5 show recommended workflows depending on the version of Cisco Nexus 1000V software that you have installed. These workflows are for stateful ESXi hosts. For information on stateless ESXi hosts, see "Installing the VEM Software on a Stateless ESXi Host" section.

Figure 3-4 describes the upgrade workflow with Cisco Nexus 1000V Release 4.2(1)SV1(4), SV1(4a), or SV1(4b) installed.

Figure 3-4 Workflow with a Cisco Nexus 1000V Version 4.2(1)SV1(4), SV1(4a), or SV1(4b) Installed

Figure 3-5 describes the upgrade workflow with Cisco Nexus 1000V Release 4.2(1)SV1(5.1) installed and you are upgrading from VMware 4.1 to 5.0.

Figure 3-5 Workflow with Cisco Nexus 1000V 4.2(1)SV1(5.1) Installed and Upgrading ESX from 4.1 to 5.0


Note The upgrade ISO can be generated by using the procedure in the


You can upgrade the ESX/ESXi host as follows:

Upgrading the ESX/ESXi host with VEM software installed.

If you are using VUM to upgrade the host:

Prior to VMware vSphere 5.0, you must create a host patch baseline and include the appropriate VMware patch or update bulletins and the corresponding Cisco Nexus 1000V VEM bulletin in the baseline. You can then upgrade the host by applying the baseline to the host and remediating.

Beginning with VMware vSphere 5.0, you must create an upgrade ISO with the ESXi image and the VEM image. For information about creating an upgrade ISO, see

If you are using the vCLI, enter the vihostupdate command or the esxupdate command. For more information, see the

Upgrading the VEM software

When VEM upgrades are triggered from the VSM, the VEM software is automatically upgraded on the host.

If you are using the vCLI, enter the vihostupdate command or the esxupdate command. For more information, see the "Upgrading the VEM Software Using the CLI" section.

Upgrading the VEMs Using VMware Update Manager from Release 4.2(1)SV1(4), 4.2(1)SV1(4a), or 4.2(1)SV1(4b) to Release 4.2(1)SV1(5.1)

The following section describes how to update the Cisco Nexus 1000V from Release 4.2(1)SV1(4), 4.2(1)SV1(4a), or 4.2(1)SV1(4b) to Release 4.2(1)SV1(5.1) by using the VUM.

PROCEDURE


Caution If removable media is still connected, for example, if you have installed the VSM using ISO and forgot to remove the media, then host movement to maintenance mode fails and the VUM upgrade fails.


Step 1 Display the current configuration.

switch (config)# show vmware vem upgrade status
Upgrade VIBs: System VEM Image
Upgrade Status: 
Upgrade Notification Sent Time: 
Upgrade Status Time(vCenter):  
Upgrade Start Time: 
Upgrade End Time(vCenter): 
Upgrade Error: 
Upgrade Bundle ID:
    VSM: VEM400-201107031-RG
    DVS: VEM400-201101030-BG

Note The minimum version of Cisco Nexus 1000V for VMware ESXi 5.0.0 hosts is Release 4.2(1)SV1(4a).


Step 2 Coordinate with and notify the server administrator of the VEM upgrade process.

switch (config)# vmware vem upgrade notify 
Warning: 
Please ensure the hosts are running compatible ESX versions for the upgrade. Refer to 
corresponding "Cisco Nexus 1000V and VMware Compatibility Information" guide.
 
   

Step 3 Verify that the upgrade notification was sent.

switch# show vmware vem upgrade status 
Upgrade VIBs: Upgrade VEM Image
Upgrade Status: Upgrade Availability Notified in vCenter
Upgrade Notification Sent Time: Sun May 9 22:04:54 2010
Upgrade Status Time(vCenter):  
Upgrade Start Time: 
Upgrade End Time(vCenter): 
Upgrade Error: 
Upgrade Bundle ID:
    VSM: VEM400-201107031-RG  
    DVS: VEM400-201101030-BG

Note Verify that the Upgrade Status contains the highlighted text. If the text is not present, check the Upgrade Error line and consult the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(5.1).


Step 4 Verify that the server administrator has accepted the upgrade in the vCenter.

For more information about how the server administrator accepts the VEM upgrade, see the "Accepting the VEM Upgrade in the vCenter Server" section.

Coordinate the notification acceptance with the server administrator. After the server administrator accepts the upgrade, proceed with the VEM upgrade.

switch# show vmware vem upgrade status 
Upgrade VIBs: Upgrade VEM Image
Upgrade Status: Upgrade Accepted by vCenter Admin
Upgrade Notification Sent Time: Sun May 9 22:04:54 2010
Upgrade Status Time(vCenter):  Tue May 11 07:42:32 2010
Upgrade Start Time: 
Upgrade End Time(vCenter): 
Upgrade Error: 
Upgrade Bundle ID:
    VSM: VEM400-201107031-RG  
    DVS: VEM400-201101030-BG
 
   

Note Verify that the Upgrade Status contains the highlighted text. If the text is not present, check the Upgrade Error line and consult the Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV1(5.1).


Step 5 Initiate the VUM upgrade process.


Note Before entering the following command, communicate with the server administrator to confirm that the VUM process is operational.


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

switch# vmware vem upgrade proceed
switch# show vmware vem upgrade status 
Upgrade VIBs: Upgrade VEM Image
Upgrade Status: Upgrade In Progress in vCenter
Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010
Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010 
Upgrade Start Time: Wed Mar 17 15:20:06 2010
Upgrade End Time(vCenter): 
Upgrade Error: 
Upgrade Bundle ID:
    VSM: VEM400-201107031-RG  
    DVS: VEM400-201107031-RG  

Note The DVS bundle ID is updated and is highlighted.



Note If the ESX/ESXi host is using ESX/ESXi 4.1.0 or later release and 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. For details about DRS settings required and vMotion of VMs, visit the VMware documentation related to Creating a DRS Cluster.


Step 6 Check for the upgrade complete status.

switch# show vmware vem upgrade status
Upgrade VIBs: System VEM Image
Upgrade Status: Upgrade Complete in vCenter 
Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010
Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010
Upgrade Start Time: Wed Mar 17 15:20:06 2010
Upgrade End Time(vCenter): Wed Mar 17 17:30:48 2010
Upgrade Error:
Upgrade Bundle ID:
    VSM: VEM400-201107031-RG  
    DVS: VEM400-201107031-RG  
 
   

Step 7 Clear the VEM upgrade status after the upgrade process is complete.

switch# vmware vem upgrade complete
switch# show vmware vem upgrade status
Upgrade VIBs: Upgrade VEM Image
Upgrade Status:
Upgrade Notification Sent Time:
Upgrade Status Time(vCenter):
Upgrade Start Time:
Upgrade End Time(vCenter):
Upgrade Error:
Upgrade Bundle ID:
    VSM: VEM400-201107031-RG 
    DVS: VEM400-201107031-RG 
 
   

Step 8 Verify that the upgrade process is complete.

switch#  show module
Mod  Ports  Module-Type                      Model              Status
---  -----  -------------------------------- ------------------ ------------
1    0      Virtual Supervisor Module        Nexus1000V         ha-standby
2    0      Virtual Supervisor Module        Nexus1000V         active *
3    248    Virtual Ethernet Module          NA                 ok
4    248    Virtual Ethernet Module          NA                 ok
 
   
Mod  Sw               Hw 
---  ---------------  ------ 
1    4.2(1)SV1(5.1)     0.0 
2    4.2(1)SV1(5.1)     0.0 
3    4.2(1)SV1(5.1)     VMware ESXi 5.0.0 Releasebuild-260247 (2.0) 
4    4.2(1)SV1(5.1)     VMware ESXi 5.0.0 Releasebuild-260247 (2.0) 
 
   
Mod  MAC-Address(es)                         Serial-Num
---  --------------------------------------  ----------
1    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA 
2    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA 
3    02-00-0c-00-03-00 to 02-00-0c-00-03-80  NA 
4    02-00-0c-00-04-00 to 02-00-0c-00-04-80  NA 
 
   
Mod  Server-IP        Server-UUID                           Server-Name
---  ---------------  ------------------------------------  --------------------
1    10.78.109.100    NA                                    NA
2    10.78.109.100    NA                                    NA
3    10.78.109.104    1ee15784-f2e8-383e-8132-9026577ca1bb  10.78.109.104
4    10.78.109.102    44454c4c-4700-104e-804d-cac04f563153  10.78.109.102
* this terminal session 

Note The line with the bold characters in the preceding example displays that all VEMs are upgraded to Release 4.2(1)SV1(5.1).


The upgrade is complete.


Upgrading the VEMs Manually from Release 4.2(1)SV1(4), 4.2(1)SV1(4a), or 4.2(1)SV1(4b) to Release 4.2(1)SV1(5.1)

The following section describes how to upgrade Cisco Nexus 1000V from Release 4.2(1)SV1(4), 4.2(1)SV1(4a), or 4.2(1)SV1(4b) to Release 4.2(1)SV1(5.1) manually.

BEFORE YOU BEGIN


Note If VUM is installed, it should be disabled.


To manually install or upgrade the Cisco Nexus 1000V VEM on an ESX/ESXi host, follow the steps in the "Upgrading the VEM Software Using the CLI" section.

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 that the VMs are powered off if you are not running the required patch level.



Caution If removable media is still connected, for example, if you have installed the VSM using ISO and forgot to remove the media, host movement to maintenance mode fails and the VEM upgrade fails.

PROCEDURE


Step 1 Coordinate with and notify the server administrator of the VEM upgrade process.

switch (config)# vmware vem upgrade notify
Warning: 
Please ensure the hosts are running compatible ESX versions for the upgrade. Refer to 
corresponding "Cisco Nexus 1000V and VMware Compatibility Information" guide.
 
   

Step 2 Verify that the upgrade notification was sent.

switch (config)# show vmware vem upgrade status
Upgrade Status: Upgrade Availability Notified in vCenter
Upgrade Notification Sent Time: Sun May  9 22:04:54 2010
Upgrade Status Time(vCenter):  
Upgrade Start Time: 
Upgrade End Time(vCenter): 
Upgrade Error: 
Upgrade Bundle ID:
    VSM: VEM400-201107031-RG  
    DVS: VEM400-201101030-RG
 
   

Step 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 Server" section.

After the server administrator accepts the upgrade, proceed with the VEM upgrade.

switch# show vmware vem upgrade status 
Upgrade VIBs: Upgrade VEM Image
Upgrade Status: Upgrade Accepted by vCenter Admin
Upgrade Notification Sent Time: Sun May  9 22:04:54 2010
Upgrade Status Time(vCenter): Tue May 11 07:42:32 2010 
Upgrade Start Time: 
Upgrade End Time(vCenter): 
Upgrade Error: 
Upgrade Bundle ID:
    VSM: VEM400-201107031-RG  
    DVS: VEM400-201101030-BG
 
   

Step 4 Perform on of the following:

If the ESX host is not hosting the VSM, proceed to Step 5.

If the ESX host is hosting the VSM, coordinate with the server administrator to migrate the VSM to a host that is not being upgraded. Proceed to Step 5.

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 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 the VSM.

switch# vmware vem upgrade proceed

Note If VUM is not installed, the "The object or item referred to could not be found" error appears in the vCenter Server's task bar. You can ignore this error message.


switch# show vmware vem upgrade status 
Upgrade VIBs: Upgrade VEM Image
Upgrade Status: Upgrade in Progress in vCenter
Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010
Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010 
Upgrade Start Time: Wed Mar 17 15:20:06 2010
Upgrade End Time(vCenter): 
Upgrade Error: 
Upgrade Bundle ID:
    VSM: VEM400-201107031-RG  
    DVS: VEM400-201107031-RG  
 
   

Step 6 Check for the Upgrade Complete status.

switch# show vmware vem upgrade status
Upgrade VIBs: Upgrade VEM Image
Upgrade Status: Upgrade Complete in vCenter 
Upgrade Notification Sent Time: Wed Mar 17 15:19:05 2010
Upgrade Status Time(vCenter): Wed Mar 17 17:28:46 2010
Upgrade Start Time: Wed Mar 17 15:20:06 2010
Upgrade End Time(vCenter): Wed Mar 17 17:28:48 2010
Upgrade Error:
Upgrade Bundle ID:
    VSM: VEM400-201107031-RG  
    DVS: VEM400-201107031-RG  
 
   

Step 7 Coordinate with and wait until the server administrator upgrades all ESX host VEMs with the new VEM software release and informs you that the upgrade process is complete.

The server administrator performs the manual upgrade using the vihostupdate command or the esxcli command. For more information, see the "Upgrading the VEM Software Using the CLI" section.

Step 8 Clear the VEM upgrade status after the upgrade process is complete.

switch# vmware vem upgrade complete
switch# show vmware vem upgrade status
Upgrade VIBs: Upgrade VEM Image
Upgrade Status:
Upgrade Notification Sent Time:
Upgrade Status Time(vCenter):
Upgrade Start Time:
Upgrade End Time(vCenter):
Upgrade Error:
Upgrade Bundle ID:
    VSM: VEM400-201107031-RG  
    DVS: VEM400-201107031-RG  
 
   

Step 9 Verify that the upgrade process is complete.

switch#  show module
Mod  Ports  Module-Type                      Model              Status
---  -----  -------------------------------- ------------------ ------------
1    0      Virtual Supervisor Module        Nexus1000V         ha-standby
2    0      Virtual Supervisor Module        Nexus1000V         active *
3    248    Virtual Ethernet Module          NA                 ok
4    248    Virtual Ethernet Module          NA                 ok
 
   
Mod  Sw               Hw 
---  ---------------  ------ 
1    4.2(1)SV1(4a)     0.0 
2    4.2(1)SV1(4a)     0.0 
3    4.2(1)SV1(5.1)     VMware ESXi 4.1.0 Releasebuild-260247 (2.0) 
4    4.2(1)SV1(5.1)     VMware ESXi 4.1.0 Releasebuild-260247 (2.0) 
 
   
Mod  MAC-Address(es)                         Serial-Num
---  --------------------------------------  ----------
1    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA 
2    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA 
3    02-00-0c-00-03-00 to 02-00-0c-00-03-80  NA 
4    02-00-0c-00-04-00 to 02-00-0c-00-04-80  NA 
 
   
Mod  Server-IP        Server-UUID                           Server-Name
---  ---------------  ------------------------------------  --------------------
1    10.78.109.100    NA                                    NA
2    10.78.109.100    NA                                    NA
3    10.78.109.104    1ee15784-f2e8-383e-8132-9026577ca1bb  10.78.109.104
4    10.78.109.102    44454c4c-4700-104e-804d-cac04f563153  10.78.109.102
* this terminal session 
 
   

Note The line with the bold characters in the preceding example display that all VEMs are upgraded to Release 4.2(1)SV1(5.1).


The upgrade is complete.


Accepting the VEM Upgrade in the vCenter Server

This section describes the steps that a server administrator follows to accept a VEM upgrade in the vCenter Server.

BEFORE YOU BEGIN

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

The network and server administrators must coordinate the upgrade procedure with each other.

You have received a notification in the vCenter Server 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:


Step 1 In the vCenter Server, choose Inventory > Networking.

Step 2 Click the vSphere Client DVS Summary tab to check for the availability of a software upgrade (see Figure 3-6).

Figure 3-6 vSphere Client DVS Summary Tab

Step 3 Click Apply upgrade.

The following actions occur:

The network administrator is notified that you are ready to apply the upgrade to the VEMs.


Upgrading the VEM Software Using the CLI

You can upgrade the Cisco Nexus 1000V VEM software on an ESX/ESXi host by using the CLI.

BEFORE YOU BEGIN

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

If you are using vCLI, do the following:

You have downloaded and installed the VMware vCLI. For information about installing the vCLI, see the VMware vCLI documentation.

You are logged in to the remote host where the vCLI is installed.


Note The vSphere Command-Line Interface (vCLI) command set allows you to enter common system administration commands against ESX/ESXi systems from any machine with network access to those systems. You can also enter most vCLI commands against a vCenter Server system and target any ESX/ESXi system that the vCenter Server system manages. vCLI commands are especially useful for ESXi hosts because ESXi does not include a service console.


If you are using the esxupdate command:

You are logged in to the ESX host.

Check the Cisco Nexus 1000V Compatibility Information, Release 4.2(1)SV1(5.1) for compatible versions.

You have already copied the VEM software installation file to the /tmp directory. Do not copy the files to the root (/) folder.

You know the name of the VEM software file to be installed.

PROCEDURE


Step 1 Go to the directory where the new VEM software was copied.

[root@serialport -]# cd tmp
[root@serialport tmp]# 
 
   

Step 2 Determine the upgrade method that you want to use and enter the appropriate command:

If you are using the vCLI, enter the vihostupdate command and install the ESX/ ESXi and VEM software simultaneously.

If you are on an ESXi host running ESXi 4.1, enter one of the following commands:

vihostupdate --install --bundle [path to Cisco updated VEM offline bundle]" --server 
[vsphere host IP address]

Note Put the host in maintenance mode before you enter the following command.


[root@serialport tmp]# vihostupdate --install --bundle VEM400-201107401.zip --server 
192.0.2.0
Enter username: root
Enter password:
Please wait installation in progress ...
The update completed successfully, but the system needs to be rebooted for the changes 
to be effective.
[root@serialport tmp]#
 
   

If you are using the esxupdate command, from the ESX host /tmp directory, install the VEM software as shown in the following example:


Note When using the esxupdate command, you must log in to each host and enter the following command.

esxupdate -b [VMware offline update bundle] update

This command loads the software manually onto the host, loads the kernel modules, and starts the VEM Agent on the running system.


Step 3 Display values with which to compare to Cisco Nexus 1000V Compatibility Information, Release 4.2(1)SV1(5.1).

[root@serialport tmp]# vmware -v
VMware ESXi 5.0.0 build-469512
 
   

The highlighted text shows the upgraded Cisco VEM.

root@serialport tmp]# esxupdate query
-----Bulletin ID----- -----Installed----- ----------Summary----------
ESXi400-Update01      2011-07-28T14:30:58 VMware ESXi 4.0 Update 1 
VEM400-201107273451115-BG  2011-07-28T14:48:36 Cisco Nexus 1000V 4.2(1)SV1(4a)
[root@host212 ~]# vem status -v 
Package vssnet-esx4.1.0-00000-release
Version 4.2.1.1.4.1.0-1.9.1
Build 1
Date Wed Jul 27 04:42:14 PDT 2011
 
   
Number of PassThru NICs are 0
VEM modules are loaded
 
   
Switch Name    Num Ports   Used Ports  Configured Ports  MTU     Uplinks
vSwitch0       32          2           32                1500    vmnic0
DVS Name       Num Ports   Used Ports  Configured Ports  Uplinks
byru-215       256         56          256               vmnic2,vmnic1
 
   
Number of PassThru NICs are 0
VEM Agent (vemdpa) is running
 
   
[root@host212 ~]# vem version -v 
Number of PassThru NICs are 0
Running esx version -208167 x86_64
VEM Version: 4.2.1.1.4.1.0-1.9.1
VSM Version: 4.2(1)SV1(4a)
System Version: VMware ESX 4.0.0 Releasebuild-208167
 
   

Step 4 Display that the VEMs were upgraded by entering the following commands from the VSM.

switch# show module
Mod  Ports  Module-Type                      Model              Status
---  -----  -------------------------------- ------------------ ------------
1    0      Virtual Supervisor Module        Nexus1000V         active *
2    0      Virtual Supervisor Module        Nexus1000V         standby
3    248    Virtual Ethernet Module          NA                 ok
Mod  Sw               Hw
---  ---------------  ------
1    4.0(4)SV1(5.1)     0.0 
2    4.0(4)SV1(5.1)     0.0
3    4.2(1)SV1(5.1)    VMware ESXi 4.0.0 build-208167 (1.9) 
 
   
Mod  MAC-Address(es)                         Serial-Num
---  --------------------------------------  ----------
1    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA
4    02-00-0c-00-04-00 to 02-00-0c-00-04-80  NA
 
   
Mod  Server-IP        Server-UUID                           Server-Name
---  ---------------  ------------------------------------  --------------------
1    10.104.62.220    NA                                    NA
4    10.104.62.217    3fa746d4-de2f-11de-bd5d-c47d4f7ca460  visor
 
   

Note The highlighted text in the previous command output confirms that the upgrade was successful.


If the upgrade was successful, the installation procedure is complete.


Upgrading from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(5.1)

Upgrading from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(5.1) is a two-step process.

1. See the Upgrading from Releases 4.0(4)SV1(3, 3a, 3b, 3c, 3d) to Release 4.2(1)SV1(4b) section in the Cisco Nexus 1000V Software Upgrade Guide, Release 4.2(1)SV1(4b).

2. See the "Upgrading to Release 4.2(1)SV1(5.1)" section.

Upgrading the VEM Software Using VUM


Caution If removable media is still connected to the host, for example, if you have installed the VSM by using an ISO image and forgot to remove the media, host movement to maintenance mode fails and the VUM upgrade fails.

When upgrading the VEM software, VMware Update Manager (VUM) automatically selects the correct VEM software to be installed on the host.

The VEM software is upgraded on the host in one of the following procedures:

When upgrading the VEM software, the VUM operation is initiated when the network administrator enters the vmware vem upgrade proceed command.

The VUM operation is initiated when the server administrator adds a new host to the Cisco Nexus 1000V DVS.


Note Make sure that you read the "Prerequisites for Upgrading VEMs" section to ensure that the VUM operation proceeds without failure.


If you are using VUM, the Cisco Nexus 1000V VEM software is installed automatically when the host is added to the Cisco Nexus 1000V DVS. When VEM upgrades are triggered from the VSM, the VEM software automatically upgrades on the host. To determine which VUM upgrade procedure you should follow, see the "Upgrading the VEM Software Using VUM" section.

Migrating from Layer 2 to Layer 3

This section describes how to migrate from a Layer 2 configuration to a Layer 3 configuration.

This section contains the following topics:

Layer 3 Advantages

Interface Comparisions Between mgmt0 and control0

Configuring the Layer 3 Interface

Creating a Port Profile with Layer 3 Control Capability

Creating a VMKernel on the Host

Configuring the SVS-Domain in the VSM

Prerequisites for Migrating from Layer 2 to Layer 3

Only one vmk interface with capability l3-control should be present on each ESX/ESXi host before proceeding with the Layer 2 (L2) to Layer 3 (L3) migration.

The following connections are fine:

Between the VEMs and VSM - Ping from VEM to the l3 control interface IP address of the VSM.

Between the VEMs and the vCenter Server - Enter the ping command from the VEMs to the vCenter Server's IP address.

Between the VSM and the vCenter Server - Enter the ping command from the VSM to the vCenter Server's IP address.

If the VSM is using the control0 interface as the l3 control interface, it must be configured with an IP address before migrating from L2 mode to L3 mode.


Note If any one of the previously mentioned pre-requisites fails, the module is not attached.

The VSM can operate in either L2 or L3 mode only. When migrating, make sure to configure and migrate all the hosts in the setup.

Cisco Nexus 1000V does not support multiple vmk interfaces with capability l3-control. Ensure that only one vmk interface is configured with capability l3-control.


Layer 3 Advantages

The following lists the advantages of using a Layer 3 configuration over a Layer 2 configuration:

The VSM can control the VEMs that are in a different subnets.

The VEMs can be in different subnets.

Since the VEMs can be in different subnets, there is no constraint on the physical location of the hosts.

Minimal VLAN configurations are required for establishing the VSM-VEM connection when compared to Layer 2 control mode. The IP address of the VEM (Layer 3 capable vmknic's IP address) and the VSM's control0/mgmt0 interface are the only required information.

In the VSM, either the mgmt0 or the control0 interface can be used as the Layer 3 control interface. If mgmt0 is used, there is no need for another IP address as the VSM's management IP address is used for VSM-VEM Layer 3 connection.

If the management VMKernel (vmk0) is used as the Layer 3 control interface in the VEM, there is no need for another IP address since the host's management IP address is used for VSM-VEM Layer 3 connectivity.


Note This is applicable only for ESX-Visor hosts. On ESX-Cos hosts, a new VMKernel must be created.


Interface Comparisions Between mgmt0 and control0

The following describes the differences in using a mgmt0 interface versus a control0 interface:

Two ways of connectivity via mgmt0 or control0 interface (on VSM).

Setting mgmt0 as Layer 3 interface uses the mgmt0 interface on the VSM.

The control0 interface is a special interface created for L3 connectivity.

The Layer 3 interface on the VEM is selected by designating the interface with Layer 3 control capability.

The egress control traffic route is decided by the VMware routing stack.

On a VEM, the management vmknic (vmk0) can be used for Layer 3 control connectivity if it is managed by the Cisco Nexus 1000V and is designated with Layer 3 control capability.

Migrating from Layer 2 to Layer 3 consists of four procedures:

1. Configuring the Layer 3 Interface

2. Creating a Port Profile with Layer 3 Control Capability

3. Creating a VMKernel on the Host

4. Configuring the SVS-Domain in the VSM

Configuring the Layer 3 Interface

You can configure a Layer 3 interface with the following procedure.

PROCEDURE


Step 1 Configure either the control0 or mgmt0 interface.

Configuring the control0 interface.


Note When using control0 as the control interface on the VSM, the control0 interface must be assigned with an IP address.


a. Configure the IP address.

VSM_1# configure terminal 
VSM_1(config)# interface control 0 
VSM_1(config-if)# ip address 5.5.5.2 255.255.255.0 
 
   

b. Display the running configuration of the control0 interface.

VSM_1# show running-config interface control 0 
!Command: show running-config interface control0 
!Time: Mon Dec 12 02:41:47 2011 
version 4.2(1)SV1(5.1) 
interface control0 
  ip address 5.5.5.2/24 
 
   

Configuring the mgmt0 interface.


Note When using mgmt0 as the control interface, no configuration on the VSM is required as the mgmt0 interface is assigned with the host's management IP address.


a. Display the running configuration of mgmt0 interface.

VSM_1# show running-config interface mgmt 0 
!Command: show running-config interface mgmt0 
!Time: Mon Dec 12 02:43:25 2011 
version 4.2(1)SV1(5.1) 
interface mgmt0 
  ip address 10.104.249.37/27 

Creating a Port Profile with Layer 3 Control Capability

BEFORE YOU BEGIN

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

You are creating a port profile with Layer 3 control capability.

Allow the VLAN that you use for VSM to VEM connectivity in this port profile.

Configure the VLAN as a system VLAN.

PROCEDURE


Step 1 Create a Layer 3 port profile.

VSM_1# configure terminal 
VSM_1(config)# port-profile type vethernet l3_control 
VSM_1(config-port-prof)# switchport mode access 
VSM_1(config-port-prof)# switchport access vlan 3160 
VSM_1(config-port-prof)# capability l3control 
VSM_1(config-port-prof)# vmware port-group 
VSM_1(config-port-prof)# state enabled 
VSM_1(config-port-prof)# no shutdown 
VSM-1(config-port-prof)# system vlan 3160 
 
   

Step 2 Display the port profile.

VSM_1# show port-profile name l3_control 
port-profile l3_control
 type: Vethernet
 description: 
 status: enabled
 max-ports: 32
 min-ports: 1
 inherit:
 config attributes:
  switchport mode access
  switchport access vlan 3160 (Allow the VLAN in access mode.) 
  no shutdown
 evaluated config attributes:
  switchport mode access
  switchport access vlan 3160
  no shutdown
 assigned interfaces:
  Vethernet1
 port-group: l3_control 
 system vlans: 3160 (Configure the VLAN as a system VLAN.) 
 capability l3control: yes (Configure capability l3 control.) 
 capability iscsi-multipath: no
 capability vxlan: no
 capability l3-vn-service: no
 port-profile role: none port-binding: static
 
   

Creating a VMKernel on the Host

You can use the following procedure to create a VMKernel on a host.

PROCEDURE


Step 1 Log in to the vCenter Server.

Step 2 Choose Home > Inventory > Hosts and Clusters.

Step 3 Choose the host.

Step 4 Click the Configuration tab.

Step 5 In the Hardware pane, choose Networking.

Step 6 Click the vSphere Distributed Switch button.

Step 7 Go to Manage Virtual Adapters.

Step 8 Add and create a new VMKernel.


Note The management VMKernel can also be used as a Layer 3 control interface. This only applies to ESX-Visor hosts.


Step 9 Assign the VMkernel to the port profile created in the "Creating a Port Profile with Layer 3 Control Capability" section.

Step 10 Assign an IP address to the same.


The system VLAN needs to be present on the uplink port profile.

port-profile type ethernet system-uplink
  vmware port-group
  switchport mode trunk
  switchport trunk allow vlan 3160
  channel-group auto mode on mac-pinning
  no shutdown
  system vlan 3160
  state enabled

Configuring the SVS-Domain in the VSM

The control0 or mgmt0 interface can be assigned as the Layer 3 control interface.

Use the following procedure to assign mgmt0 as the Layer 3 control interface.

PROCEDURE


Step 1 Disconnect the VSM to vCenter Server connection.

VSM_1# configure terminal 
VSM_1(config)# svs connection toVC 
VSM_1(config-svs-conn)# no connect 
VSM_1(config-svs-conn)# exit 
 
   

Step 2 Remove the control and the packet VLAN configuration.

VSM_1(config)# svs-domain 
VSM_1(config-svs-domain)# no control vlan 
VSM_1(config-svs-domain)# no packet vlan 
 
   

Step 3 Change the svs mode from Layer 2 to Layer 3 with the mgmt0 interface as the Layer 3 control interface.

VSM_1(config-svs-domain)# svs mode l3 interface mgmt0 
VSM_1(config-svs-domain)# exit 

Note If the control0 interface is being used as the Layer 3 control interface, enter the following command:

VSM_1(config-svs-domain)# svs mode l3 interface control0


Step 4 Restore the VSM to vCenter Server connection.

VSM_1(config)# svs connection toVC 
VSM_1(config-svs-conn)# connect 
VSM_1(config-svs-conn)# end 
 
   

Caution After entering the previous command, the module is detached and reattached in Layer 3 mode. If this delay is more than six seconds, a module flap occurs. This does not affect the data traffic.

Step 5 Display the SVS-Domain configuration.

VSM_1# show svs domain 
SVS domain config: 
  Domain id:    3185 
  Control vlan: 1  
  Packet vlan:  1  
  L2/L3 Control mode: L3 
  L3 control interface: mgmt0
  Status: Config push to VC successful.

Feature History for Upgrading the Cisco Nexus 1000V

Table 3-4 lists the release history for this feature.


Note