Schlecht. Ein ESXi-Host sollte zwecks Update „mal schnell“ neu gestartet werden, doch nun sind mehr als 30 Minuten vergangen und es gibt noch immer kein Lebenszeichen. Selbst für Server etwas ungewöhnlich und lange genug um den VMWare-Updater in einen Timeout laufen zu lassen. Nach einiger Zeit war das System zwar wieder korrekt gebootet und zeigte keine weiteren Auffälligkeiten, eine solche Wartezeit wäre bei Störungen jedoch sehr hinderlich, also gehen wir mal auf Quellensuche.
Im Log finden sich mehrere Einträge, welche durch die Zeitstempel massive Wartezeiten erkennen lassen:
***T09:53:18.467Z cpu1:***)vmw_psp_mru: psp_mruSelectPathToActivateInt:346: Changing active path from NONE to vmhba0:xx:xx:xx for device "Unregistered Device". ***T09:53:18.467Z cpu1:***)StorageApdHandler: xxx: APD Handle Created with lock[StorageApd-0xxxx] ***T09:53:18.467Z cpu1:***)ScsiEvents: 501: Event Subsystem: Device Events, Created! ***T09:53:18.467Z cpu1:***)VMWARE SCSI Id: Id for vmhba1:xx:xx:xx xxxxx ***T09:53:18.467Z cpu1:***)VMWARE SCSI Id: Id for vmhba0:xx:xx:xx xxxxx ***T09:53:58.506Z cpu2:***)ScsiDeviceIO: xxx: Cmd(0xxxx) 0x1a, CmdSN 0x1 from world 0 to dev "naa.xxx" failed H:0x5 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0. ***T09:53:58.506Z cpu1:***)ScsiDeviceIO: xxx: Could not detect setting of QErr for device naa.xxx. Error Timeout. ***T09:54:08.631Z cpu19:***)NMP: nmp_ResetDeviceLogThrottling:3343: Error status H:0x0 D:0x18 P:0x0 Sense Data: 0x0 0x0 0x0 from dev "naa.xxx" occurred 989 times(of 989 commands) ***T09:54:38.524Z cpu2:***)ScsiDeviceIO: xxx: Cmd(0xxxx) 0x1a, CmdSN 0x2 from world 0 to dev "naa.xxx" failed H:0x5 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0. ***T09:54:38.524Z cpu1:***)ScsiDeviceIO: xxx: Could not detect setting of sitpua for device naa.xxx. Error Timeout.
Das Ganze wiederholt sich dann mehrfach. Also ein SCSI-Timeout? Der Host ist per FibreChannel an diverse Storage-Systeme angebunden, sollte jedoch auch nur die für ihn relevanten LUNs sehen. Zumal nach dem langem boot auch alle Datastores verfügbar und VMs ohne Fehler online waren.
Nach einigem Suchen dann die Erkenntnis: Die angekreideten LUNs gehören zu einem Windows-Cluster und sind als RDM vorgesehen. ESXi versucht nun beim Booten diese LUNs zu scannen, was jedoch nicht gelingt da der Cluster auf einem anderen Host aktiv und die Partition somit dauerhaft gesperrt ist. Zur Abhilfe muss man diesen Scan beim Boot explizit für die betroffenen LUNs auf jedem Host deaktivieren:
esxcli storage core device setconfig -d naa.xxxx --perennially-reserved=true