cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2814
Views
4
Helpful
4
Replies

ESX on Dell blade change UUID after patch!

sokarlsson
Level 1
Level 1

Have anyone else seen this?

One of my customers have esx 5.0 installed on several Dell B610 and B620 servers. After installing a ESX patch the uuid of the hosts changed!
This resulted in several of the hosts not being licened in the N1000v (because the module number changed) and all nics blocked on the VMs attached to those VEMs.

I had to use "svs licence transfer" to fix the issue. Both I and the customer have done some searching around but can not find anyone else that have run into the same problem.

Shouldn't the UUID be related to the hardware and pulled from BIOS or is the UUID calculated from some number in bios?

1 Accepted Solution

Accepted Solutions

VMware changed the way the SMBIOS reads the UUID.

http://www.vmware.com/support/vsphere5/doc/vsp_esxi50_u2_rel_notes.html

SMBIOS UUID reported by ESXi 5.0 hosts might be different  from the actual SMBIOS UUID

If 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 is a VMware problem, the 1000v utilizes this UUID for unique distinction between hosts.  They essentially change their ID method which impacts 1000v hosts.

Robert

View solution in original post

4 Replies 4

sokarlsson
Level 1
Level 1

Some more info: This is what happened to the uuid

Before: "44454c4c-5900-1050-8056-c7c04f46354a"

After:    "4c4c4544-0059-5010-8056-c7c04f46354a"

If one look carefully some parts have been mirrored. We have opened a case with WMware for this.

N1k VEM uses the UUID from BIOS.  You can confirm this by:

~ # vemcmd show card | grep UUID  

Card UUID type  2: b0e12784-911d-11df-3000-000000000007

~ # esxcfg-info | grep "BIOS UUID"

      |----BIOS UUID................................................0xb0 0xe1 0x27 0x84 0x91 0x1d 0x11 0xdf 0x30 0x0 0x0 0x0 0x0 0x0 0x0 0x7

We've heard reports of this in the past & appears to be a VMware issue.

VMware changed the way the SMBIOS reads the UUID.

http://www.vmware.com/support/vsphere5/doc/vsp_esxi50_u2_rel_notes.html

SMBIOS UUID reported by ESXi 5.0 hosts might be different  from the actual SMBIOS UUID

If 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 is a VMware problem, the 1000v utilizes this UUID for unique distinction between hosts.  They essentially change their ID method which impacts 1000v hosts.

Robert

Thanks Robert

Then it's like we suspected. The VMware have reported the wrong uuid before and it's now corrected with SP2.

Review Cisco Networking for a $25 gift card