Qualche mese fa, dopo un aggiornamento ad VMware vSphere 5.5 su un server Dell PowerEdge R710, mi era capitato uno strano errore: occasionalmente l’host ESXi si disconnetteva dal vCenter (rimanendo nello stato di Not Responding) e non c’era modo di ricollegarlo se non riavviare l’host (il riavvio dei servizi non funzionava). Dopo un certo periodo di tempo, il problema comunque si ripresentava e quindi non era una soluzione stabile.
Anche perché le VM erano ancora funzionanti, ma non vi era il modo il spostarle a caldo per poter poi riavviare l’host.
Nella console di ESXi era ben visibile l’errore: Bootbank cannot be found at path ‘/bootbank’
Cercando su Google, un caso simile con gli stessi sintomi e lo stesso messaggio di errore avevo trovato questo caso: VMware ESXi 4.x and 5.x lose connectivity to Hypervisor – IBM BladeCenter HX5. Che però riguardarva server IBM, benché il problema di Permanent Device Loss (PDL) applicato al dispositivo USB che ospita l’installazione dell’ESXi si poteva concettualmente applicare anche al mio server (le SD usate dai server Dell sono comunque collegate ad una porta USB interna).
Di sicuro era medesimo il messaggio di errore: “Bootbank cannot be found at path ‘/bootbank'”. Con però l’informazione in più che nei log di VMware vSphere Client o VMware vSphere Center era possibile notare anche questo messaggio ‘Configuration Issue’ due to the ‘Lost connectivity to the device mpx.vmhba32:C0:T0:L0’ when ‘backing the boot file system /vmfs/devices/disks/mpx.vmhba32:C0:T0:L0’. Rimane comunque interessante come un problema sul dispositivo di avvio possa (in alcune circostanze) comunque causare problemi seri… in fondo ESXi una volta caricato lavora poi in RAM disk e il dispositivo di avvio non dovrebbe più essere usato, se non periodicamente per memorizzare la configurazione nella partizione di store.
Nel mio caso la KB 1017297 (ESXi/ESX host appears as Not Responding in vCenter Server due to CD/DVD-ROM drive firmware issues) mi ha aiutato a capire il reale problema che era legato ad un firmware bacato del CD. Per verificare se il vostro firmware è potenzialmente affetto da questo problema:
- execute the command esxcfg-scsidevs -l,
- depending on your CD/DVD-ROM drive’s model or revision, you see output similar to:mpx.vmhba1:C0:T0:L0
Device Type: CD-ROM
Size: 0 MB
Display Name: Local TEAC CD-ROM (mpx.vmhba1:C0:T0:L0)
Plugin: NMP
Console Device: /dev/sr0
Devfs Path: /vmfs/devices/genscsi/mpx.vmhba1:C0:T0:L0
Vendor: TEAC Model: DV-28E-V Revis: C.AB
SCSI Level: 5 Is Pseudo: false Status: on
Is RDM Capable: false Is Removable: true
Is Local: true
Other Names:
vml.0005000000766d686261313a303a30
-
Upgrade the CD/DVD-ROM drive firmware to the latest version available
-
Replace the CD/DVD-ROM drive with a different model
-
Disable the CD/DVD-ROM drive within the BIOS of the ESXi/ESX host
La prima purtroppo non era applicabile: il firmware, secondo Dell, era già aggiornato all’ultima versione . La seconda era possibile, ma richiedeva tempo. La terza era la più veloce, anche perché rimaneva comunque possibile usare il CD virtuale della iDRAC.
Rimane curioso come altri due modelli, configurati identici e acquistati nello stesso lotto, non erano invece affetti dal problema, presentando un modello di CD leggermente diverso.
Questo semplice caso dimostra l’importanza della HCL anche su aspetti minimali (che paradossalmente manco sono elencati nella HCL standard), ma soprattutto di non dare per scontato nulla: anche server (appentemente) uguali e dello stesso lotto potrebbero non essere uguali nella composizione hardware e nei relativi firmware.