open-power / skiboot

OPAL boot and runtime firmware for POWER
Apache License 2.0
99 stars 134 forks source link

[RFE] Add support for a per-system persistent UUID #193

Open tbreeds opened 6 years ago

tbreeds commented 6 years ago

On x86_64 systems it's possible to use dmidecode -s system-uuid to get a UUID tied to the hardware. Then inventory management tools can use that UUID as a key to manage the hardware regardless of IP or other changes.

To the best of my knowledge there isn't anything similar on open-power supported hardware. The closest I've found is the system serial number.

Is it possible to get a UUID placed in the device tree as system-uuid generated using the UUID5 model and setting up a namespace for the vendor for example the following is a (python) proposal for a work around until this is available in skiboot

vendor = serial = None
with open('/sys/firmware/devicetree/base/vendor') as f:
    vendor = f.read().rstrip(' \t\r\n\0')
with open('/sys/firmware/devicetree/base/system-id') as f:
    serial = f.read().rstrip(' \t\r\n\0')
root = uuid.UUID(bytes='\x00' * 16)
vendor_uuid = uuid.uuid5(root, vendor)
system_uuid = uuid.uuid5(vendor_uuid, serial)
print(system_uuid)
jk-ozlabs commented 6 years ago

We don't currently get an explicit system UUID from HDAT, but we do get a bunch of other supposedly-unique identifiers in the root VPD node:

VPD: 176 bytes
  RT [04]: Record name
    56 53 59 53                                      |VSYS|
  DR [06]: Description
    53 59 53 54 45 4d                                |SYSTEM|
  BR [02]: Brand
    53 30                                            |S0|
  SE [07]: System serial number
    32 31 31 37 xx xx xx                             |2117XXX|
  SG [07]: System serial number
    20 20 20 20 20 20 20                             |       |
  TM [08]: Type-model
    38 32 34 37 2d 32 32 4c                          |8247-22L|
  TN [08]: Type-model
    20 20 20 20 20 20 20 20                          |        |
  MN [07]: Manufacture date
    20 20 20 20 20 20 20                             |       |
  ID [02]: System ID
    20 20                                            |  |
  SU [06]: System unique ID
    00 04 ac xx xx xx                                |...XXX|
  NN [10]: SSD node ID
    20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20  |                |
  RG [04]: Reserved bytes
    f0 c0 00 00                                      |....|
  RB [04]: Reserved bytes
    33 20 20 20                                      |3   |
  WN [0c]: Worldwide port number
    43 30 35 30 37 36 30 xx xx xx xx xx              |C050760XXXXX|
  FV [20]
    53 56 38 34 30 5f 31 31 38 00 00 00 00 00 00 00  |SV840_118.......|
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
  PF [03]: Pad fill
    00 00 00                                         |...|
tbreeds commented 6 years ago

As you can see I've been using SE [07]: System serial number and generating a namespace from the vendor just in case 2 vendors somehow duplicate serial numbers. I've mostly implemented that in a vacuum so it may be a terrible idea ;P

For my purposes It'd be good to:

  1. Agree that synthesising a UUID from something can be done
  2. Agree where that'll be presented to the guest. To my mind along side system-id but called system-uuid seems like a natural option.
  3. (and for bonus points) Knowing the algorithm so I can implement it in consumers until they're running skiboot with this feature. If I do it right then systems can transition without appearing to change system-uuid's