Cisco Nexus 1000V Troubleshooting Guide, Release 4.0(4)SV(1)
Troubleshooting System Issues
Downloads: This chapterpdf (PDF - 148.0KB) The complete bookPDF (PDF - 4.05MB) | Feedback

System

Table Of Contents

System

Information About the System

General Restrictions for vCenter Server

Extension Key

Recovering a DVS

Problems Related to VSM and vCenter Server Connectivity

VSM Creation

Port Profiles

Problems with Port Profiles

Problems with Hosts

Problems with VM Traffic

VEM Troubleshooting Commands

VEM Log Commands

Error Messages


System


This chapter describes how to identify and resolve problems related to the system.

This chapter includes the following sections:

Information About the System

General Restrictions for vCenter Server

Problems Related to VSM and vCenter Server Connectivity

VSM Creation

Port Profiles

Problems with Hosts

Problems with VM Traffic

VEM Troubleshooting Commands

VEM Log Commands

Error Messages

Information About the System

The Cisco Nexus 1000V provides Layer 2 switching functions in a virtualized server environment. The Cisco Nexus 1000V replaces virtual switches within ESX servers and allows users to configure and monitor the virtual switch using the Cisco NX-OS command line interface. The Cisco Nexus 1000V also gives you visibility into the networking components of the ESX servers and access to the virtual switches within the network.

The Cisco Nexus 1000V manages a data center defined by the vCenter Server. Each server in the Datacenter is represented as a linecard in the Cisco Nexus 1000V and can be managed as if it were a line card in a physical Cisco switch.

The Cisco Nexus 1000V implementation consists of two components:

Virtual supervisor module (VSM) - This is the control software of the Cisco Nexus 1000V distributed virtual switch. It runs on a virtual machine (VM) and is based on NX-OS.

Virtual Ethernet module (VEM) - This is the part of Cisco Nexus 1000V that actually switches data traffic. It runs on a VMware ESX 4.0 host. Several VEMs are controlled by one VSM. All the VEMs that form a switch domain should be in the same virtual Datacenter as defined by VMware vCenter Server.

For a detailed overview of how the Cisco Nexus 1000V works with VMware ESX software, see the Cisco Nexus 1000V Getting Started Guide, Release 4.0(4)SV1(1).

General Restrictions for vCenter Server

When you are troubleshooting issues related to vCenter Server, make sure that you observe the following restrictions:

The name of a distributed virtual switch (DVS) name must be unique across Datacenters

You create a DVS in a network folder

A Datacenter cannot be removed unless the DVS folder or the underlying DVS is deleted.

A DVS can be deleted only with the help of VSM using the no vmware dvs command in config-svs-conn mode.

The no vmware dvs command can succeed only if there are no VMs using the DVS port-groups.

A port group on vCenter Server can be deleted only if there are no interfaces associated with it.

A sync operation performed in conjunction with the connect command helps VSM keep in sync with vCenter Server.

Each VSM uses a unique extension key to communicate with vCenter Server and perform operations on a DVS.

Extension Key

The VSM uses the extension key when communicating with the vCenter Server. Each VSM has its own unique extension key, such as Cisco_Nexus_1000V_32943215

Use the show vmware vc extension-key command to find the extension key of the VSM. It is also listed in the .xml file.

The extension key registered on the vCenter Server can be found through the MOB.

The same extension key cannot be used to create more than one DVS on the vCenter Server.

Recovering a DVS

If you have a DVS that was created by a VSM VM, and it existed on vCenter Server, but the VSM VM was lost or needs to be replaced, then you must create a new VSM. To enable the new VSM to interact with the old DVS, follow these steps:


Step 1 Restore the backed up configuration (if present). If the configuration is not present, the switchname needs to be set with the DVS name.

Step 2 Find the extension key through the MOB.

Step 3 Enter the extension key tied to the DVS, as in this example:

n1000v(config)# vmware vc extension-key Cisco_Nexus_1000V_32943215

Step 4 Set the svs connections to point to the datacenter.

Delete the extension key present on the VC using MOB (unregister extension API).

Step 5 Go to the extension manager [https://<vc-ip>/mob/?moid=ExtensionManager] and click Unregister Extension. [https://<vc-ip>/mob/?moid=ExtensionManager&method=unregisterExtension]

Step 6 Paste Cisco_Nexus_1000V_32943215 (your extension key attached to the DVS) and click Invoke Method

Step 7 Re-register the new extension key from the new VSM VM.

Step 8 Enter the connect command.

You can now use the old DVS or remove it.


Problems Related to VSM and vCenter Server Connectivity

Symptom
Solution

The vCenter Server connection seems to succeed, but does not.

Make sure that the domain ID is configured correctly.

The svs connection command fails.

Make sure you have configured all parameters for the svs connection command.

 

Make sure you can ping the vCenter Server IP address.

 

Make sure that the proxy.xml file is correct for both the IP address and length.

 

Restart the vCenter Server

The host does not show up in the Add host to DVS screen.

Make sure that the Host is installed with VMware Enterprise plus

license containing the Distributed Virtual Switch feature.

Add host to DVS returns an error.

Confirm that the VEM software is installed on the ESX server,

The server name column of the show module command output shows the IP address.

The server name shows the host-name or IP address, whichever was used to add the host to the DVS on the vCenter Server.


Example 17-1 shows the show vms internal event-history errors command that is useful for examining VC errors in detail. It shows whether an error is caused by a VSM (client) or the server.

Example 17-1 show vms internal event-history error Command

n1000v# show vms internal event-history errors

Event:E_DEBUG, length:239, at 758116 usecs after Tue Feb  3 18:21:58 2009
    [102] convert_soap_fault_to_err(1179): SOAP 1.1 fault: "":ServerFaultCode [VMWARE-VIM] 
A DVS n1000v with spec.name as n1000v already exists, cannot create DVS n1000v. A 
specified parameter was not correct.spec.name

Event:E_DEBUG, length:142, at 824006 usecs after Tue Feb  3 18:18:30 2009
    [102] convert_soap_fault_to_err(1179): SOAP 1.1 fault: SOAP-ENV:Client [VMWARE-VIM] 
Operation could not be completed due to connection failure.

Event:E_DEBUG, length:134, at 468208 usecs after Tue Feb  3 18:15:37 2009
    [102] convert_soap_fault_to_err(1179): SOAP 1.1 fault: "":ServerFaultCode [VMWARE-VIM] 
Extension key was not registered before its use.

VSM Creation

Symptom
Possible Causes
Solution

The VSM VM is stuck at the boot prompt.

Make sure that you have three e1000 NICs.

The VSM VM cannot ping itself.

Configure the mgmt0 interface.

The VSM VM can ping itself, but not the gateway.

Make sure the NIC order is correct: control, mgmt, inband.

The VSM VM can ping the gateway, but not the outside subnet.

Configure vrf context management.


Port Profiles

When creating a port profile, use the following commands to create the corresponding port groups on the vCenter Server:

vmware port-group

state enabled

capability uplink (if there is an uplink port-profile)

Profiles that have the system VLAN configuration allow the VEM to communicate with the VSM.

Make sure that the system port-profile is defined with the right system VLANS.

Use the show port-profile and show port-profile usage commands to collect basic required information.

Problems with Port Profiles

Symptom
Possible Causes
Solution

You receive an error message "Possible failure in communication with vCenter Server."

The VSM is not connected to the vCenter Server.

Issue the svs connection vc command to connect to the vCenter Server.

The port group name is not unique.

Port group names must be unique within a vCenter Server Datacenter.

Port profile or port groups do not appear on the vCenter Server.

Make sure you have issued the vmware port-group command and state enable command.


Problems with Hosts

Symptom
Solution

You receive an error message, DVS Operation failed for one or more members."

Issue the vem status -v command to verify if the VEM is running on the host.

Issue the vem unload command to unload the VEM.

In the vSphere Client, remove the stale DVS:

1. Go to the Host tab Networking->Configuration->
Distributed Virtual Switch

2. Click Remove.

The host is visible on the vCenter Server, but not the VSM.

Issue the vemcmd show trunk command to verify that there is an uplink carrying the control VLAN. The profile applied to the uplink must be a system profile with a control VLAN as a system VLAN.

Verify the control VLAN in the upstream switch port and the path to the VSM VM. Make sure that one uplink at most carries the control VLAN, or that all uplinks and upstream ports carrying the control VLAN are in port channels.

A module flap occurs.

The VSM may be overloaded. Make sure that you have 1 GB of memory and CPU shares for the VSM VM on the vCenter Server.


Problems with VM Traffic

When troubleshooting problems with intra-host VM traffic, follow these guidelines:

Make sure that at least one of the VM vnics is on the correct DVS port groups, and make certain that the vnic is connected.

If the vnic is down, determine if there is a conflict between the MAC address configured in the OS and the MAC address assigned by VMware. You can see the assigned MAC addresses in the vmx file.

When troubleshooting problems with inter-host VM traffic, follow these guidelines:

Determine if there is exactly one uplink sharing a VLAN with the VM vnic. If there is more than one, they must be in a port channel.

Ping a SVI on the upstream switch using the show intX counters command.

VEM Troubleshooting Commands

Use the following commands to display VEM information:

vemlog - displays and controls VEM kernel logs

vemcmd - displays configuration and status information

vem-support all - collects support information

vem status- collects status information

vem version- collects version information

vemlog show last number-of-entries - displays the circular buffer

Example 17-2 vemlog show last Command

[root@esx-cos1 ~]# vemlog show last 5
Timestamp                  Entry CPU  Mod Lv         Message
Oct 13 13:15:52.615416      1095   1    1  4 Warning vssnet_port_pg_data_ ...
Oct 13 13:15:52.620028      1096   1    1  4 Warning vssnet_port_pg_data_ ...
Oct 13 13:15:52.630377      1097   1    1  4 Warning svs_switch_state ...
Oct 13 13:15:52.633201      1098   1    1  8    Info vssnet new switch ...
Oct 13 13:16:24.990236      1099   1    0  0         Suspending log

vemlog show info - displays information about entries in the log

Example 17-3 vemcmd show info Command

[root@esx-cos1 ~]# vemlog show info
          Enabled: Yes
    Total Entries: 1092
  Wrapped Entries: 0
     Lost Entries: 0
  Skipped Entries: 0
Available Entries: 6898
 Stop After Entry: Not Specified

vemcmd help - displays the type of information you can display

Example 17-4 vemcmd help Command

[root@esx-cos1 ~]# vemcmd help
show card              Show the card's global info
show vlan [vlan]       Show the VLAN/BD table
show bd [bd]           Show the VLAN/BD table
show l2 <bd-number>    Show the L2 table for a given BD/VLAN
show l2 all            Show the L2 table
show port [priv|vsm]   Show the port table
show pc                Show the port channel table
show portmac           Show the port table MAC entries
show trunk [priv|vsm]  Show the trunk ports in the port table
show stats             Show port stats

VEM Log Commands

Use the following commands to control the vemlog:

vemlog stop - stops the log

vemlog clear - clear s the log

vemlog start number-of-entries - starts the log and stops it after the specified number of entries

vemlog stop number-of-entries - stops the log after the next specified number of entries

vemlog resume - starts the log, but does not clear the stop value

Error Messages

On the vSphere Client, you can see error messages under the recent tasks tab. You can find detailed description of the error under the Tasks and Events tab. The same messages are also propagated to the VSM.

Table 17-1 lists error messages that you might see on the VSM.

Table 17-1 Error Messages on the VSM

Error
Description

ERROR: [VMWARE-VIM] Extension key was not registered before its use

This error indicates that VSM extension key is not registered.

ERROR: [VMWARE-VIM] A DVS n1000v with spec.name as n1000v already exists, cannot create DVS n1000v. A specified parameter was not correct. spec.name.

This error is displayed after you enter the first connect command, and indicates that a DVS already exists with the same name.

ERROR: [VMWARE-VIM] A DVS n1000v with spec.extensionKey as Cisco_Nexus_1000V_2055343757 already exists, cannot create DVS new-n1000v. A specified parameter was not correct. spec.extensionKey

This error is displayed when the VSM tries to create a different DVS after changing the switch name.

ERROR: [VMWARE-VIM] A DVS n1000v with name as n1000v already exists, cannot reconfigure DVS test. A specified parameter was not correct. Spec.name

This error indicates that a DVS with the same name already exists.

Warning: Operation succeeded locally but update failed on vCenter server.[VMWARE-VIM] DVPortgroup test port 0 is in use. The resource vim.dvs.DistributedVirtualPort 0 is in use.

This warning is displayed when the VSM tries to delete the port profile if the VSM is not aware of the nics attached to the port groups.