When upgrading vSAN OSA hosts from vSphere version 7.x/8.x to vSphere 8.0 Update 3 and vSphere 8.0 Update3b, ONLY the first reboot after the upgrade will take longer to initialize disk-groups during boot sequence and all other subsequent reboots will NOT be affected by this.
The reboot time may vary between 5mins to 45 mins depending on the type of workload running on the hosts prior to upgrade.
Logs messages indicate that Fast recovery failed with "Invalid metadata" at first reboot:
Sample:
2024-07-22T16:45:50.752Z In(182) vmkernel:cpu11:2099668)LSOMCommon:LSOMFbIsValidSerializedHdr:155:loggerId(disk/comp): ########-####-####-####-########2ab6 Invalid serialized hdr, magic 0x0
2024-07-22T16:45:50.752Z In(182) vmkernel:cpu11:2099668)LSOMCommon:Bucketlist_Deserialize:508:loggerId(disk/comp):########-####-####-####-########2ab6 Invalid header for serialized bucketlist
2024-07-22T16:45:50.752Z In(182) vmkernel: cpu11:2099668)PLOG: PLOGState_Deserialize:1313: loggerId(disk/comp): ########-####-####-####-########2ab6 Failed to de-serialize data elevator debug retired Table: Invalid metadata
2024-07-22T16:45:50.752Z In(182) vmkernel: cpu11:2099668)PLOG: PLOGFbDeserializeMDPLOGStates:2128: loggerId(disk/comp): ########-####-####-####-########2d4c Failed to deserialize plog state, md uuid 52994d35-a2c2-8ac4-bde1-a06df24c2ab6
2024-07-22T16:45:50.752Z In(182) vmkernel: cpu11:2099668)LSOMCommon: LSOMFbFreeCtx:259: loggerId(disk/comp): ########-####-####-####-########2d4c Freeing fastboot context: 0x45022dee2578
2024-07-22T16:45:50.752Z In(182) vmkernel: cpu11:2099668)LSOMCommon: LSOMFbClose:407: loggerId(disk/comp): ########-####-####-####-########2d4c LSOM Fastboot Context 0x45022ded2358 close
2024-07-22T16:45:50.752Z In(182) vmkernel: cpu11:2099668)PLOG: PLOGRecoverDeviceLogsDispatch:5790: disk: ########-####-####-####-########2d4c Fast recovery failed : Invalid metadata
Upgrades from below vSphere versions are affected by this issue :
vSAN OSA 7.x (7.0U1/U2/U3)
vSAN OSA 8.0U1
vSAN OSA 8.0 U2
vSAN OSA 8.0 U3b
This issue is planned to be addressed in a future release.
There is no workaround needed as the issue does not exist on any subsequent reboots.