Cisco Nexus 1000V Troubleshooting Guide, Release 4.2(1)SV2(2.1)
Upgrade
Downloads: This chapterpdf (PDF - 712.0KB) The complete bookPDF (PDF - 6.53MB) | Feedback

Table of Contents

Upgrade

Information about Upgrades

Problems with the In Service Software Upgrade

Problems with the VEM Upgrade

Problems with the GUI Upgrade

Recovering a Secondary VSM with Active Primary

Stopping a VSM Upgrade

Changing Boot Variables

Powering On the VSM

Changing the HA Role

Recovering a Primary VSM with Active Secondary

Disconnecting the Port Groups

Powering Off the VSM

Connecting the Port Groups

Problems with VSM-VEM Layer 2 to 3 Conversion Tool

Upgrade Troubleshooting Commands

Upgrade

This chapter describes how to identify and resolve problems related to upgrading the VSM software, and includes the following sections:

Information about Upgrades

The upgrade for the Cisco Nexus 1000V involves upgrading software on both the VSM and the VEM.

An in service software upgrade (ISSU) is available for a stateful upgrade of the Cisco Nexus 1000V image(s) running on the VSM. A stateful upgrade is one without noticeable interruption of data plane services provided by the switch.

For detailed information, see the following document:

  • Cisco Nexus 1000V Installation and Upgrade Guide, Release 4.2(1)SV2(1.1)

Problems with the In Service Software Upgrade

The following are symptoms, possible causes, and solutions for problems with software upgrade using the manual in service software upgrade (ISSU).

Table 5-1 Problems with the ISSU

Symptom
Possible Causes
Solution

Error Message:

Pre-Upgrade check failed.

Return code 0x40930062 (free space in the filesystem is below threshold).

This error indicates that there is not enough space in the /var/sysmgr partition.

1. Reboot the system.

Error message:

Pre-Upgrade check failed. Return code 0x4093000A (SRG collection failed)

A module is removed during the upgrade.

1. Make sure the module removal is complete.

2. Restart the software upgrade using the detailed instructions in the Cisco Nexus 1000V Installation and Upgrade Guide, Release 4.2(1)SV2(1.1) .

Error message:

Pre-Upgrade check failed. Return code 0x40930076 (Standby sup is offline. ISSU will not proceed)

The standby VSM is not present or is not synchronized with the active VSM, and the VSMs do not form a stable HA pair.

1. Verify the HA synchronization state.

show system redundancy status

The output of the show command must indicate the following:

Active VSM: Active with HA standby

Standby VSM: HA standby

2. If the output of the show command indicates that the VSMs are not synchronized, then see the “Problems with High Availability” section.

3. When the VSMs are synchronized, restart the software upgrade using the detailed instructions in the Cisco Nexus 1000V Installation and Upgrade Guide, Release 4.2(1)SV2(1.1) .

Error message:

Pre-Upgrade check failed. Return code 0x807B0002 (No such file or directory)
 

Error message:

Pre-Upgrade check failed. Return code 0x4093000F (Failed to copy image)

The software image files required for the upgrade are not present or were not copied to the bootflash: repository.

There may not be enough room in bootflash: for the files to be copied.

1. Verify there is enough space in bootflash for the image files.

dir

2. Do one of the following:

If additional space is needed, delete other files from the bootflash repository to make room for the software image files.

delete


Caution Do not delete kickstart or system image files from bootflash. If there are no image files in bootflash, the system cannot reboot if required.

If not, continue with the next step.

3. Download the required images from www.cisco.com to the bootflash: repository.

4. Verify that the correct images are in the bootflash: repository.

show boot

5. When the correct software images are in the bootflash: repository, restart the software upgrade using the detailed instructions in the Cisco Nexus 1000V Installation and Upgrade Guide, Release 4.2(1)SV2(1.1) .

The install command fails with the following error:

Return code 0x4045001F (image MD5 checksum error)

Pre-Upgrade check failed. Return code 0x40930011 (Image verification failed)

The software image file(s) required for the upgrade do not pass the MD5 checksum verification, indicating that the correct file(s) are not present in bootflash: for the upgrade to proceed.

A file can be truncated when copied.

1. Using the README file from the upgrade zip folder at www.cisco.com, verify the MD5 checksum for each of the image files.

show file bootflash: filename md5sum

2. Replace the file(s) that do not match.

3. Verify that the correct images are in the bootflash: repository and that checksums match.

show file bootflash: filename md5sum

4. When the correct software images are in the bootflash: repository, restart the software upgrade using the detailed instructions in the Cisco Nexus 1000V Installation and Upgrade Guide, Release 4.2(1)SV2(1.1) .

Error message:

Install has failed. Return code 0x40970001 (Incompatible image)

You may have used an incorrect filename when entering the install all command.

Restart the software upgrade using the correct filenames for the new software images.

install all kickstart filename1 system filename2

After upgrading, the VSMs are not running the new software version.

The boot variables were not set properly.

1. Verify that the running images and boot variables match the upgrade version.

show version

show boot

2. If needed, download the required images from www.cisco.com to your local bootflash: repository.

3. Verify that the correct images are in the bootflash: repository.

show boot

4. Restart the software upgrade using the detailed instructions in the Cisco Nexus 1000V Installation and Upgrade Guide, Release 4.2(1)SV2(1.1) .

5. If the problem persists, collect details of the upgrade and open a support case.

show system internal log install details

Performing the configuration copy process fails and stops the upgrade.

Performing configuration copy.

[####------------] 30%

Service or system errors.

1. Manually copy the configuration.

copy running-config startup-config

2. Do one of the following:

If the progress bar gets stuck before 100% for over one minute, collect details of the upgrade and open a support case.

show system internal log install details

If the copy succeeds without delays, restart the software upgrade using the detailed instructions in the Cisco Nexus 1000V Installation and Upgrade Guide, Release 4.2(1)SV2(1.1) .

Error message:

Another install procedure may be in progress. (0x401E0007)

Another upgrade session is in progress from a VSM console or SSH/Telnet.

Do one of the following:

  • Continue the first upgrade session in progress.
  • Stop the upgrade and restart one session only using the detailed instructions in the Cisco Nexus 1000V Installation and Upgrade Guide, Release 4.2(1)SV2(1.1) .

Install command fails with following error message:

-- FAIL. Return code 0x4093001E (Standby failed to come online)

Install has failed. Return code 0x4093001E (Standby failed to come online)

The standby VSM fails to boot with the new image.

Do one of the following:

  • Restart the software upgrade using the detailed instructions in the Cisco Nexus 1000V Installation and Upgrade Guide, Release 4.2(1)SV2(1.1) .
  • Postpone the upgrade and reset the boot variables to the original filenames.

boot kickstart filename [sup-1] [sup-2]

Install command fails with following error message:

Install has failed. Return code 0x4093001F (Standby installer failed to take over the installation).
Please identify the cause of the failure, and try “install all” again”

The standby VSM takes more than 10 minutes to come up and form a stable HA pair with the active VSM.

1. Reset the boot variables to the original filenames.

boot kickstart filename [sup-1] [sup-2]

2. If the standby is still running the new software version, reload it.

reload

The standby synchronizes with the active, so that both are running the original software version.

Install command fails with following error message:

Module 2: Waiting for module online.
-- SUCCESS
-- Install has failed. Return code 0x40930000 (Current operation failed to complete within specified time)

A failure at the standby VSM caused it to reload again after the Continuing with installation, please wait message and before the switchover.

1. Inspect logs.

show logging

2. Look for standby reloads caused by process failures.

show cores

If a process crash is observed, collect details of the upgrade and open a support case.

show system internal log install details

3. Restart the software upgrade using the detailed instructions in the Cisco Nexus 1000V Installation and Upgrade Guide, Release 4.2(1)SV2(1.1) .

Pre-Upgrade check failed:

Return code 0x40930062 (free space in the filesystem is below threshold).

1.

Problems with the VEM Upgrade

The following are symptoms, possible causes, and solutions for problems with VEM software upgrade.

Table 5-2 Problems with the VEM Upgrade

Symptom
Possible Causes
Solution

After starting a VEM upgrade from the VSM console, VUM skips upgrading the hosts with the new VEM.

One or more of the following are enabled on the host cluster.

  • VMware High Availability (HA)
  • VMware Fault Tolerance (FT)
  • Vmware Distributed Power Management (DPM)

1. Verify the upgrade failure.

show vmware vem upgrade status

2. From vCenter server, disable HA, FT, and DPM for the cluster.

3. Restart the VEM software upgrade using the detailed instructions in the Cisco Nexus 1000V Installation and Upgrade Guide, Release 4.2(1)SV2(1.1) .

VEM upgrade fails.

 

An incorrect VUM version is in use.

1. Identify the VUM version required for the upgrade using the Cisco Nexus 1000V Compatibility Information, Release 4.2(1)SV2(1.1) .

2. Upgrade to the correct VUM version.

3. Restart the software upgrade using the detailed instructions in the Cisco Nexus 1000V Installation and Upgrade Guide, Release 4.2(1)SV2(1.1) .

After upgrading, the host is not added to the VSM.

An incorrect VEM software version is installed on the host.

1. Identify the VEM software version required for the upgrade using the Cisco Nexus 1000V Compatibility Information, Release 4.2(1)SV2(1.1) .

2. Proceed with the upgrade using the correct VEM software version and the detailed instructions in the Cisco Nexus 1000V Installation and Upgrade Guide, Release 4.2(1)SV2(1.1) .

A message on the ESX/ESXi command line shell and VMkernel logs notifies you that the loading and unloading of modules failed.

The modules were not placed in maintenance mode (all VMs vmotioned over) before starting the upgrade.

1. Place the host in maintenance mode.

2. Proceed with the upgrade using the detailed instructions in the Cisco Nexus 1000V Installation and Upgrade Guide, Release 4.2(1)SV2(1.1) .

The host does not have enough memory to load new modules.

A host requires a minimum of 2 GB of physical RAM. If it also hosts a Cisco Nexus 1000V VSM VM, it needs a minimum of 4 GB of physical RAM. If it also hosts the vCenter Server VM, additional memory may be needed.

1. Verify that the host has sufficient memory to load the new modules.

For more information about allocating RAM and CPU, see the Cisco Nexus 1000V Installation and Upgrade Guide, Release 4.2(1)SV2(1.1) .

2. Proceed with the upgrade using the detailed instructions in the Cisco Nexus 1000V Installation and Upgrade Guide, Release 4.2(1)SV2(1.1) .

Problems with the GUI Upgrade

The following are symptoms, possible causes, and solutions for problems with software upgrade using the GUI upgrade application.


Note If you are upgrading directly from SV1(4) to SV1(4a) the GUI is not used and this section does not apply. This section is only applicable if you use the GUI for an intermediate upgrade from a SV1(3x) release to SV1(4), prior to upgrading to SV1(4a).


 

Table 5-3 Problems with the GUI Upgrade

Symptom
Possible Causes
Solution

The upgrade GUI stops and times out after 10 minutes and displays the following message:

Error: Could not contact the upgraded VSM at n.n.n.n. Please check the connection.

During the upgrade, you configured an unreachable IP address for the mgmt0 interface.

In this case, one VSM in the redundant pair has new software installed and is unreachable; while the other VSM has the original pre-upgrade original pre-upgrade software version installed and is reachable.

1. Use one of the following sets of procedures to return your VSM pair to the previous software version:

“Recovering a Secondary VSM with Active Primary” section

“Recovering a Primary VSM with Active Secondary” section

2. Restart the software upgrade using the detailed instructions in the Cisco Nexus 1000V Installation and Upgrade Guide, Release 4.2(1)SV2(1.1) .

The upgrade GUI stops and times out after 10 minutes and displays the following message:

Error: Could not contact the upgraded VSM at 10.104.244.150. Please check the connection.

After timing out, one VSM comes up in switch(boot) mode.

You have selected incompatible or incorrect VSM software images for the upgrade.

The software images you selected from the GUI selection list included a system image for one software version and a kickstart image for another software version. These images must be for the same software version.

For an example of how software images are selected during the upgrade, see Example 5-1.

1. To continue the upgrade, first recover the VSM using one of the following:

“Recovering a Secondary VSM with Active Primary” section

“Recovering a Primary VSM with Active Secondary” section

2. Restart the software upgrade using the detailed instructions in the Cisco Nexus 1000V Installation and Upgrade Guide, Release 4.2(1)SV2(1.1) .

Example 5-1 Upgrade: Enter Upgrade Information

This example shows how you specify system and kickstart images during the upgrade process. In this example, the images specified are from the same release, SV1.4. If you specify a kickstart image from one release, and a system image from another, then the upgrade cannot proceed.

 

 

Recovering a Secondary VSM with Active Primary

You can use the following process to recover a secondary VSM when the primary VSM is active.


Note The information in this section does not apply when upgrading from Release 4.2(1)SV1(4) to
Release 4.2(1)SV2(1.1).



Step 1 Stop the upgrade on the VSM, using the Stopping a VSM Upgrade

Step 2 Change the boot variables back to the previous version using the Changing Boot Variables

Step 3 From the vCenter Server left-hand panel, right-click the secondary VSM and then choose Delete from Disk.

The secondary VSM is deleted.

Step 4 Create a new VSM by reinstalling the software using the vSphere client Deploy OVF Template wizard, specifying the following:

  • Nexus 1000V Secondary configuration method
    (Configures the secondary VSM in an HA pair using a GUI setup dialog.)
  • The host or cluster of the primary VSM
  • The same domain ID and password as that of the primary VSM.

For a detailed procedure, see the Cisco Nexus 1000V Installation and Upgrade Guide, Release 4.2(1)SV2(1.1) .

The VSM comes up and forms an HA pair with the newly-created standalone VSM. The VSMs have the previous version of the software installed.


 

Stopping a VSM Upgrade

You can use this procedure to stop a VSM upgrade that is in progress.

BEFORE YOU BEGIN

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

Note The information in this section does not apply when upgrading from Release 4.2(1)SV1(4) to
Release 4.2(1)SV2(1.1).


DETAILED STEPS


Step 1 Display upgrade status.

show svs upgrade status

Example:
n1000v# show svs upgrade status
Upgrade State: Start
Upgrade mgmt0 ipv4 addr: 1.1.1.1
Upgrade mgmt0 ipv6 addr:
Upgrade control0 ipv4 addr:
 

Step 2 Stop the upgrade.

configure terminal

no svs upgrade start

Example:
n1000v# configure terminal
n1000v#(config)# no svs upgrade start
WARNING! VSM upgrade process is aborted
n1000v#(config)#
 

Step 3 Display upgrade status.

show svs upgrade status

Example:
n1000v#(config)# show svs upgrade status
Upgrade State: Abort
Upgrade mgmt0 ipv4 addr:
Upgrade mgmt0 ipv6 addr:
Upgrade control0 ipv4 addr:
 

Step 4 You have completed this procedure. Return to the process that pointed you here:


 

Changing Boot Variables

You can use this procedure to replace the software images used to boot the VSM.

BEFORE YOU BEGIN

  • You are logged in to the CLI in EXEC mode.
  • You know the filenames of the pre-upgrade system and kickstart image files to apply.

DETAILED STEPS


Step 1 Display the current boot variables.

show boot

Example:
n1000v# show boot
sup-1
kickstart variable = bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3a.bin
system variable = bootflash:/nexus-1000v-mz.4.0.4.SV1.3a.bin
sup-2
kickstart variable = bootflash:/nexus-1000v-kickstart-mzg.4.2.1.SV1.4.bin
system variable = bootflash:/nexus-1000v-mzg.4.2.1.SV1.4.bin
No module boot variable set
n1000v(config)#
 

Step 2 Remove the current system and kickstart boot variables.

configure terminal

no boot system

no boot kickstart

Example:
n1000v# configure terminal
n1000v(config)# no boot system
n1000v(config)# no boot kickstart
n1000v#(config)#
 

Step 3 Restore the system and kickstart boot variables to the original pre-upgrade filenames.

boot system bootflash: system-boot-variable-name

boot system bootflash: kickstart-boot-variable-name

Example:
n1000v#(config)# boot system bootflash:nexus-1000v-mz.4.0.4.SV1.3a.bin
n1000v#(config)# boot kickstart bootflash:nexus-1000v-kickstart-mz.4.0.4.SV1.3a.bin
n1000v#(config)#
 

Step 4 Copy the running configuration to the startup configuration.

copy run start

Example:
n1000v#(config)# copy run start
[########################################] 100%e
n1000v#(config)#
 

Step 5 Verify the change in the system and kickstart boot variables.

show boot

Example:
n1000v#(config)# show boot
sup-1
kickstart variable = bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3a.bin
system variable = bootflash:/nexus-1000v-mz.4.0.4.SV1.3a.bin
sup-2
kickstart variable = bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3a.bin
system variable = bootflash:/nexus-1000v-mz.4.0.4.SV1.3a.bin
No module boot variable set
n1000v#(config)#
 

Step 6 You have completed this procedure. Return to the process that pointed you here:


 

Powering On the VSM

Use this procedure to power on the newly-created VSM.


Step 1 From the vCenter Server left-hand panel, right-click the VSM and then choose Power > Power On.

The VSM starts.

 

 

Step 2 You have completed this procedure. Return to the “Recovering a Primary VSM with Active Secondary” section.


 

Changing the HA Role

You can use this procedure to change the HA role of the VSM.

BEFORE YOU BEGIN

  • You are logged in to the CLI in EXEC mode.
  • You know the domain ID of the existing VSM.

DETAILED STEPS


Step 1 Go to the domain of the existing VSM.

configure terminal

svs-domain

domain id domain-id

Example:
n1000v# config t
n1000v(config)# svs-domain
n1000v(config-svs-domain)# domain id 1941
Warning: Config saved but not pushed to vCenter Server due to inactive connection!
 

Step 2 Change the HA role.

system redundancy role [primary | secondary | standalone]

Example:
n1000v(config-svs-domain)# system redundancy role secondary
Setting will be activated on next reload.
n1000v(config-svs-domain)#
 
Example:
n1000v(config-svs-domain)# system redundancy role primary
Setting will be activated on next reload.
n1000v(config-svs-domain)#
 

Step 3 Copy the running configuration to the startup configuration.

copy run start

Example:
n1000v#(config-svs-domain)# copy run start
[########################################] 100%e
n1000v#(config-svs-domain)#
 

Step 4 You have completed this procedure. Return to the “Recovering a Primary VSM with Active Secondary” section.


 

Recovering a Primary VSM with Active Secondary

You can use the following process to recover a primary VSM when the secondary VSM is active.


Step 1 Stop the upgrade on the secondary VSM, using the Stopping a VSM Upgrade

Step 2 Change the boot variables back to the previous version using the Changing Boot Variables

Step 3 From the vCenter Server left-hand panel, right-click the primary VSM and then choose Delete from Disk.

The primary VSM is deleted.

Step 4 Create a new VSM by reinstalling the software from the OVA and specifying the following:

  • Manual (CLI) configuration method instead of GUI.
  • The host or cluster of the existing secondary VSM

For a detailed installation procedure, see the Cisco Nexus 1000V Installation and Upgrade Guide, Release 4.2(1)SV2(1.1) .

Step 5 Make sure the port groups between the host server and VSM are not connected when the new VSM is powered on, using the Disconnecting the Port Groups.

Step 6 Power on the newly-created VSM using the Powering On the VSM.

The VSM comes up with the standalone HA role.

Step 7 Change the HA role of the newly-created standalone VSM to primary and save the configuration, using the Changing the HA Role.

Step 8 Power off the newly-created VSM, using the Powering Off the VSM.

Step 9 Make sure the port groups between the host server and VSM are connected when the new VSM is powered on, using the Connecting the Port Groups.

Step 10 Power on the newly-created VSM using the Powering On the VSM.

The VSM comes up, connects with the host server, and forms an HA pair with the existing primary VSM.


 

Disconnecting the Port Groups

Use this procedure to disconnect and prevent port groups to the VSM from connecting to the host server.


Step 1 In vCenter Server, select the VSM and then choose Edit > Settings.

The Virtual Machine Properties dialog box opens.

Step 2 Select the Control port group and uncheck the following Device Settings:

  • Connected
  • Connect at Power On

The connection from the VSM to the host server through the control port is dropped and is not restored when you power on the VSM.

 

 

Step 3 Select the Management port group and uncheck the following Device Settings:

  • Connected
  • Connect at Power On

The connection from the VSM to the host server through the management port is dropped and is not restored when you power on the VSM.

 

 

Step 4 You have completed this procedure. Return to the “Recovering a Primary VSM with Active Secondary” section.


 

Powering Off the VSM

Use this procedure to power off the newly-created VSM.


Step 1 From the vCenter Server left-hand panel, right-click the VSM and then choose Power > Power Off.

The VSM shuts down.

 

Step 2 You have completed this procedure. Return to the “Recovering a Primary VSM with Active Secondary” section.


 

Connecting the Port Groups

Use this procedure to make sure the port groups to the host connect when you power on the VSM.


Step 1 In vCenter Server, select the VSM and then choose Edit > Settings.

The Virtual Machine Properties dialog box opens.

Step 2 Select the Control port group and check the following Device Settings:

  • Connect at Power On

When you power on the VSM, it will connect to the host server through the control port.

 

 

Step 3 Select the Management port group and check the following Device Setting:

  • Connect at Power On

When you power on the VSM, it will connect to the host server through the management port.

 

 

Step 4 You have completed this procedure. Return to the “Recovering a Primary VSM with Active Secondary” section.


 

Problems with VSM-VEM Layer 2 to 3 Conversion Tool

The following is a symptom and solution for a problem with logging in to VSM when using the conversion tool:

Symptom
Solution

When you enter your VSM and VC login credentials for the first time, the VSM-VEM Layer 2 to 3 Conversion Tool may display:

Timeout error. Is device down or unreachable?? ssh_expect

1. Open a command line window and run an ssh command on the VSM ( ssh username@vsmIPaddress ).

2. When prompted, Are you sure you want to continue connecting?, enter yes .

3. Rerun the VSM-VEM Layer 2 to 3 Conversion Tool by reopening the .bat file. Ensure that the error does not reappear.

Upgrade Troubleshooting Commands

Should all examples comply w/issu upgrade? At least for this release, there is still gui upgrade to 4a from pre-sv1(4) releases, correct? Troubleshooting guide needn’t only address sv1(4) upgrade to sv1(4a), correct?

You can use the commands in this section to troubleshoot problems related to upgrade.

 

Command
Description

show boot

Displays boot variable definitions, showing the names of software images used to boot the VSM.

See Example 5-2 on page 5-18 .

show module See

Displays module status for active and standby VSMs.

See Example 5-4 on page 5-18 (ISSU).

See Example 5-4 on page 5-18

show running-config | in boot

Displays the boot variables currently in the running configuration.

See Example 5-5 on page 5-19 .

show startup-config | in boot

Displays the boot variables currently in the startup configuration.

See Example 5-6 on page 5-19 .

show svs connections

Displays the current connections between the VSM and the VMware host server.

See Example 5-7 on page 5-19 .

show svs upgrade status

Displays the upgrade status.

See Example 5-8 on page 5-19 .

show system redundancy status

Displays the current redundancy status for the VSM.

See Example 5-9 on page 5-20 .

show vmware vem upgrade status

Displays the upgrade status.

See Example 5-10 on page 5-20 .

Example 5-2 show boot

n1000v# show boot
sup-1
kickstart variable = bootflash:/nexus-1000v-kickstart-mz.4.0.4.SV1.3a.bin
system variable = bootflash:/nexus-1000v-mz.4.0.4.SV1.3a.bin
sup-2
kickstart variable = bootflash:/nexus-1000v-kickstart-mzg.4.2.1.SV1.4.bin
system variable = bootflash:/nexus-1000v-mzg.4.2.1.SV1.4.bin
No module boot variable set
n1000v#

Example 5-3 show module (VSM upgraded first with ISSU, VEM upgrade pending)

n1000v# 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
Mod Sw Hw
--- --------------- ------
1 4.2(1)SV1(4a) 0.0
2 4.2(1)SV1(4a) 0.0
3 4.2(1)SV1(4) 1.9
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
Mod Server-IP Server-UUID Server-Name
--- --------------- ------------------------------------ --------------------
1 10.78.109.43 NA NA
2 10.78.109.43 NA NA
3 10.78.109.51 4220900d-76d3-89c5-17d7-b5a7d1a2487f 10.78.109.51
n1000v#

Example 5-4 show module (VEM and VSM upgraded)

n1000v# 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
 
Mod Sw Hw
--- --------------- ------
1 4.0(4)SV1(3) 0.0
2 4.0(4)SV1(3) 0.0
3 4.2(1)SV1(4) 1.9
 
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
 
Mod Server-IP Server-UUID Server-Name
--- --------------- ------------------------------------ --------------------
1 10.78.109.43 NA NA
2 10.78.109.43 NA NA
3 10.78.109.51 4220900d-76d3-89c5-17d7-b5a7d1a2487f 10.78.109.51
n1000v#

Example 5-5 show running-config | include boot

n1000v# show running-config | include boot
boot kickstart bootflash:/nexus-1000v-kickstart-mzg.4.2.1.SV1.4a.bin sup-1
boot system bootflash:/nexus-1000v-mzg.4.2.1.SV1.4a.bin sup-1
boot kickstart bootflash:/nexus-1000v-kickstart-mzg.4.2.1.SV1.4a.bin sup-2
boot system bootflash:/nexus-1000v-mzg.4.2.1.SV1.4a.bin sup-2
n1000v#

Example 5-6 show startup-config | include boot

switch# show startup-config | include boot
boot kickstart bootflash:/nexus-1000v-kickstart-mzg.4.2.1.SV1.4a.bin sup-1
boot system bootflash:/nexus-1000v-mzg.4.2.1.SV1.4a.bin sup-1
boot kickstart bootflash:/nexus-1000v-kickstart-mzg.4.2.1.SV1.4a.bin sup-2
boot system bootflash:/nexus-1000v-mzg.4.2.1.SV1.4a.bin sup-2

n1000v#

Example 5-7 show svs connections

n1000v# show svs connections
 
connection vc:
hostname: 172.23.232.139
remote port: 80
protocol: vmware-vim https
certificate: default
datacenter name: Hamilton-DC
DVS uuid: 9b dd 36 50 2e 27 27 8b-07 ed 81 89 ef 43 31 17
config status: Enabled
operational status: Connected
sync status: -
version: -
n1000v#

Example 5-8 show svs upgrade status

n1000v# show svs upgrade status
Upgrade State: Start
Upgrade mgmt0 ipv4 addr: 1.1.1.1
Upgrade mgmt0 ipv6 addr:
Upgrade control0 ipv4 addr:
n1000v#

Example 5-9 show system redundancy status

switch# show system redundancy status

Redundancy role
---------------
administrative: primary
operational: primary
 
Redundancy mode
---------------
administrative: HA
operational: HA
 
This supervisor (sup-1)
-----------------------
Redundancy state: Active
Supervisor state: Active
Internal state: Active with HA standby
 
Other supervisor (sup-2)
-----------------------
Redundancy state: Standby
Supervisor state: HA standby
Internal state: HA standby
 
switch#

Example 5-10 show vmware vem upgrade status

n1000v# 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-201007101-BG
DVS: VEM400-201007101-BG
 
n1000v#