Guest

Cisco Nexus 1000V Switch for VMware vSphere

Nexus 1000v VSM and Host UUID Changes

Document ID: 116257

Updated: Aug 19, 2013

Contributed by Joe LeBlanc, Cisco TAC Engineer.

   Print

Introduction

This document describes how the virtual supervisor module (VSM) of a Cisco Nexus 1000v Series switch handles a change in host UUID. If the appropriate number or type of licenses is not available, traffic flow might be interrupted.

The VSM of a Nexus 1000v switch issues licensing to hosts based on the universally unique identifier (UUID) of the hardware. This means that, if a host UUID changes for whatever reason, it is viewed as a new host by the VSM. While it is unusual for a host UUID to change during its lifetime, Cisco is aware of two situations that can cause a UUID change - a VMware software defect in ESXi 5.0 and a Cisco Unified Computing System (UCS) firmware defect on M3 blades.

When the UUID changes, the VSM sees the previously loaded module as a new host. The host is loaded as a new module and assigned a new module number and new license. If no licenses are available, the host is assigned an overdraft license; if there are no overdrafts available, the host is not assigned a license at all. If there are production virtual machines (VMs) on this host, they can no longer pass traffic, because unlicensed hosts cannot receive programming from the VSM.

VMware Issue

If the system management BIOS (SMBIOS) version of the VMware ESXi 5.0 system is version 2.6 or later, the SMBIOS UUID reported by the ESXi 5.0 host might be different from the actual SMBIOS UUID. The byte order of the first three fields of the UUID is not correct.

The SMBIOS specification extends the BIOS interface on x86 architecture systems and addresses how motherboard and system vendors present management information about their products in a standard format. The information is intended to allow generic instrumentation to deliver this information to management applications that use desktop management interface (DMI), Common Information Model (CIM) or direct access and to eliminate the need for error-prone operations such as probing system hardware for presence detection.

The SMBIOS specification is intended to provide enough information so that BIOS developers may implement the necessary extensions in order to allow the hardware on their products and other system-related information to be accurately determined by users of the defined interfaces.

The VMkernel interacts with the hardware that uses the CIM and passes this information up. The virtual Ethernet module (VEM) interacts with the VMkernel in order to read the UUID information that was first gathered from hardware by CIM in the VMkernel. The VEM UUID is equal to the ESXi UUID.

If you start or restart the VEM (vem start/restart), the function startDpa is called. The startDpa function calls a script in /opt/cisco/vXXX/nexus/vem-vXXX/shell/vssnet-functions and extracts the UUID from the ESXi host:

setBiosUuid()
{
local UUID
UUID=$(esxcfg-info -u | awk '{print tolower($1)}')
if [ "${UUID}" != "" ] ; then
doCommand ${VEMCMD} card uuid vmware ${UUID}
fi
}

Notes:

  • The fix is in VMware ESXi 5.0 update 2.
  • See Cisco bug ID CSCue57972, N1KV uses up licensing due to ESXi Host UUID Change.
  • Search for VMware PR 859249 in the VMware knowledge base.

B200, B220, B440 M3 Blade Issue

The UUID is translated incorrectly when you upgrade VMwave ESXi 4.1 or ESXi 5.1 on the Cisco UCS B200 M3, B220 M3, or B440 M3 blade servers. This is a display issue only and does not affect the service profiles associated with the blades.

Notes:

Resolution

This procedure describes how to resolve the problems caused by a change in UUID:

  1. Enter these commands in order to identify the issue:

    # show module vem mapping <-- old UUID shows unlicensed
    # show vms internal info host-table
    ~ # esxcfg-info |grep UUID <-- new UUID of host
  2. Enter these commands in order to remove the VEM number mapped to the old UUID:

    Nexus1000v# conf t
    Nexus1000v(config)# no vem 'x'
  3. Enter this command in order to determine the lowest available module number:

    Nexus1000v# show module vem mapping
    Mod Status UUID License Status
    --- ----------- ------------------------------------ --------------
    3 powered-up 24266920-d498-11e0-0000-00000000000f licensed
    4 powered-up 24266920-d498-11e0-0000-00000000000e licensed

    Note: Only 3 and 4 are in use.

  4. Enter these commands in order to configure the new UUID configuration on the VSM:

    Nexus1000v# conf t
    Nexus1000v(config)# vem <lowest unused module #>
    Nexus1000v(config-vem-slot)# host vmware id <uuid>
    Use the new UUID of the host, as shown in Step 1:

    ~ # esxcfg-info |grep UUID

Relevant Logs

VEM_MGR-2-VEM_MGR_REMOVE_NO_HB  Removing VEM 15 (heartbeats lost)
ETH_PORT_CHANNEL-5-PORT_DOWN port-channel15: Ethernet15/1 is down
VEM_MGR-2-MOD_OFFLINE Module 15 is offline
VIM-5-IF_DETACHED Interface Vethernet248 is detached
VEM_MGR-2-VEM_MGR_DETECTED Host ?hostname? detected as module 32
VEM_MGR-2-VEM_MGR_UNLICENSED License for VEM 32 could not be obtained. Please contact your Cisco
account team or partner to purchase Licenses. To activate your purchased licenses, click on
www.cisco.com/go/license .
VEM_MGR-2-MOD_ONLINE Module 32 is online
Updated: Aug 19, 2013
Document ID: 116257