It looks like VMware ESXi 5.0 had an open issue with the way it was calculating the UUID that is sent to the VSM and displayed as the VMware host ID when a VEM module is connected.
Buried in the resolved issues area of the Update 2 Release notes is :
SMBIOS UUID reported by ESXi 5.0 hosts might be different from the actual SMBIOS UUIDIf the SMBIOS version of the ESXi 5.0 system is of 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 3 fields of the UUID is not correct.
This issue is resolved in this release.
As you update ESXi hosts to update 2.0 they will come back with a different VEM number if the host has calculated the UUID in a new way. If you are running the advanced edition of the 1000v this will eat into your available licenses, and then your overdraft licenses. If you consume all of your overdraft licenses you will probably experience a service interruption on some of the hosts you update. The "
show license usage license" command will show you the usage of overdraft licensing.
show license usage NEXUS1000V_LAN_SERVICES_PKG
----------------------------------------
Feature Usage Info
----------------------------------------
Installed Licenses : 16
Default Eval Licenses : 0
Max Overdraft Licenses : 16
Installed Licenses in Use : 16
Overdraft Licenses in Use : 4
Default Eval Lic in Use : 0
Default Eval days left : 0
Licenses Available : 12
Shortest Expiry : Never
----------------------------------------
There are a couple of ways to deal with the issue.
- Transfer the license directly from the old VEM # to the new VEM # with the "svs license transfer src-vem vem_no dst-vem vem_no" command before removing the old vem number.
- Renumber the VEM module by powering off the host, and then changing the VMware host ID of the old VEM number while it is offline.
Since our hosts are in a very specific VEM number order I'm going to go to the trouble of renumbering the VEMs during the upgrade.
Posts
