Hi Tim, I don't think patching kubernetes-master will resolve this
issue. Mainly because the issue happens on kubernetes-workers.

We were seeing PVCs failing with: "No VM found". When we look into the
logs, actually kubernetes was trying to learn about its kubernetes-
workers through SystemUUID.


Recovers UUID from SystemUUID, which according to 
Comes from product_serial

However, because of this dmidecode issue, the first half of the bytes are 
inversed (big endian vs. small endian).
What we saw on kubernetes-controller-manager log then was k8s grabbing a 
half-wrong UUID and trying to fetch it using FindVMUUID method. Of course that 
broke, since product_uuid held the right values.

To fix that, we have two ways:
1) work-around: run VMs with compatibility set for ESXi 5.5 and later; that 
forces vsphere to setup those VMs with older HW version (10) and there is no 
issue with dmidecode
2) Find out why dmidecode diverges when going to version 13 and fix it

You received this bug notification because you are a member of Kernel
Packages, which is subscribed to dmidecode in Ubuntu.

  dmidecode decodes /sys/class/dmi/id/product_serial incorrectly

Status in dmidecode package in Ubuntu:

Bug description:

  On VMWare 6.5 and higher (HW version 13 and higher) when decoding
  /sys/class/dmi/id/product_serial dmidecode produces an output whereby
  the first 16 characters have been reversed in comparison to

  This manifests itself by breaking provisioning in Kubernetes and could
  cause other issues down the line. Other OS such as redhat have already
  patched this in their releases.

  A demonstration of the issue can be found in this pastebin:


  VMWare Issue: https://kb.vmware.com/s/article/53609


To manage notifications about this bug go to:

Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to