Buenas! Tras la actualización de los host desde la versión 6.7U3 a la versión 7.0U2 me he encontrado con una lentitud progresiva en los host, terminando básicamente en que cualquier tipo de tarea se quedaba atascada, y no avanzaba. El host lo tengo instalado en una tarjeta SD, viendo los problemas que me han generado en el pasado, he empezado a investigar por aquí.
Además si tienes un clúster con vSAN en Health Check te acabaran saliendo errores tales como los 2 siguientes errores:
- vSphere cluster member match vSAN cluster members
- Host issue retrieving hardware information»
Como acabamos de comentar, realizar cualquier tarea en el host se volvía infernal, desde realizar un vMotion, hasta lanzar un comando tipo » df -h». Con el lanzamiento de comandos tenia mas suerte, ya que con el paso de los minutos me devolvía el resultado, lo que hacia que pudiese seguir investigando.
Decidi comenzar la investigacion por el log vmkernel.log
En el podemos observar como hemos perdido la conectividad con nuestra tarjeta SD
2021-08-17T06:21:58.992Z cpu3:2098243)ScsiDeviceIO: 4315: Cmd(0x45deec5e23c0) 0x28, cmdId.initiator=0x430a82173200 CmdSN 0x1 from world 2103255 to dev "mpx.vmhba32:C0:T0:L0" failed H:0x5 D:0x0 P:0x0 Cancelled from path layer. Cmd count Active:1 2021-08-17T06:21:58.992Z cpu3:2098243)Queued:0 2021-08-17T06:21:58.992Z cpu96:2107370)LVM: 6817: Forcing APD unregistration of devID 6101917c-f1499044-23c3-48df37c9097c in state 1. 2021-08-17T06:21:58.992Z cpu96:2107370)LVM: 6192: Could not open device mpx.vmhba32:C0:T0:L0:7, vol [6101917b-68e5d1bc-ca47-48df37c9097c, 6101917b-68e5d1bc-ca47-48df37c9097c, 1]: Timeout 2021-08-17T06:21:58.992Z cpu96:2107370)Vol3: 2129: Could not open device 'mpx.vmhba32:C0:T0:L0:7' for volume open: Not found 2021-08-17T06:21:58.992Z cpu96:2107370)Vol3: 4339: Failed to get object 28 type 1 uuid 6101917c-00e92b00-f7e6-48df37c9097c FD 0 gen 0 :Not found 2021-08-17T06:21:58.992Z cpu96:2107370)WARNING: Fil3: 1534: Failed to reserve volume f533 28 1 6101917c e92b00 df48f7e6 7c09c937 0 0 0 0 0 0 0 2021-08-17T06:21:58.992Z cpu96:2107370)Vol3: 4339: Failed to get object 28 type 2 uuid 6101917c-00e92b00-f7e6-48df37c9097c FD 4 gen 1 :Not found 2021-08-17T06:22:00.714Z cpu167:3980809)osfs: OSFS_GetMountPointList:3726: mountPoints[0] inUse pid [ vsan], cid 529bfec6c9143d45-df3d7da873ad8d36 2021-08-17T06:22:00.967Z cpu34:2100049)WARNING: NvmeScsi: 156: SCSI opcode 0x1a (0x45beefbc2f40) on path vmhba1:C0:T0:L0 to namespace t10.NVMe____EO000375KWJUC___________________________0001D20CC4E4D25C failed with NVMe error status: 0x2 2021-08-17T06:22:00.967Z cpu34:2100049)WARNING: translating to SCSI error H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x24 0x0 2021-08-17T06:22:01.026Z cpu14:2101604)WARNING: NvmeScsi: 156: SCSI opcode 0x1a (0x45beefbc2f40) on path vmhba2:C0:T0:L0 to namespace t10.NVMe____EO000375KWJUC___________________________0001D284E6E4D25C failed with NVMe error status: 0x2
SOLUCION TEMPORAL
1º Debemos re-escanear nuestra HBA, para ello debemos estar de seguro de cual es, en mi caso es la «vmhba32»
Una vez localizado procedemos a lanzar el escaneo de nuestra HBA, como podemos observar nos da un error, ya que algún proceso esta haciendo uso del mismo.
[root@XXX:~] esxcfg-rescan -d vmhba32 Rescan complete, however some dead paths were not removed because they were in use by the system. Please use the 'storage core device world list' command to see the VMkernel worlds still using these paths.
2º Ahora lanzamos el siguiente para obtener los procesos que haciendo uso de del dispositivo.
[root@XXX:~] localcli storage core device world list | grep mpx mpx.vmhba32:C0:T0:L0 2098200 1 OCFlush mpx.vmhba32:C0:T0:L0 2098905 1 Vol3JournalExtendMgrWorld mpx.vmhba32:C0:T0:L0 2103267 1 hostd
Como podemos observar tenemos 3 procesos haciendo uso del dispositivo.
3º Para desbloquear estos procesos procedemos a lanzar el siguiente comando
[root@XXX:~] /etc/init.d/hostd restart watchdog-hostd: Terminating watchdog process with PID 2098200 2098905 2103267 hostd stopped. /usr/lib/vmware/hostd/bin/create-statsstore.py:30: DeprecationWarning: pyvsilib is replaced by vmware.vsi import pyvsilib as vsi hostd started.
4º Una vez desbloqueados estos procesos, volvemos a lanzar el comando del paso 2. Como hemos comentado anteriormente el lanzamiento de comandos puede que tarde unos cuantos minutos.
Si nos fijamos en log de vobd.log, veremos como el host a vuelto a montar nuestras tarjetas SD y estas vuelven a estar accesibles desde el host.
021-08-17T09:26:38.624Z: [scsiCorrelator] 812951777583us: [vob.scsi.scsipath.remove] Remove path: vmhba32:C0:T0:L0 2021-08-17T09:27:26.994Z: [scsiCorrelator] 813000146952us: [vob.scsi.scsipath.add] Add path: vmhba32:C0:T0:L0 2021-08-17T09:27:26.995Z: [scsiCorrelator] 813000149172us: [vob.scsi.scsipath.pathstate.on] scsiPath vmhba32:C0:T0:L0 changed state from dead 2021-08-17T09:27:31.782Z: [vmfsCorrelator] 813004935635us: [vob.vmfs.volume.mounted] File system '[LOCKER-6101917c-00e92b00-f7e6-48df37c9097c, 6101917c-00e92b00-f7e6-48df37c9097c]' (LV 6101917b-68e5d1bc-ca47-48df37c9097c) mounted in 'rw' mode. 2021-08-17T09:27:31.783Z: [vmfsCorrelator] 813010094893us: [esx.audit.vmfs.volume.mounted] File system [LOCKER-6101917c-00e92b00-f7e6-48df37c9097c, 6101917c-00e92b00-f7e6-48df37c9097c] on volume 6101917b-68e5d1bc-ca47-48df37c9097c has been mounted in 'rw' mode. The datastore is now accessible on this host.
5º Si todo ha ido bien, nuestro host habrá vuelto a la vida y las tareas cotidianas tales como: Snapshot, vMotion, poner el host en mantenimiento, API/Script se podrán volver a realizar.
Consecuencias
No todo iba a ser gratis, después de conseguir sacar el host de esta tremenda lentitud, y devolver a la vida, nos encontraremos con el siguiente » problema». Para solventar este problema deberemos reiniciar el host para que vuelva a la normalidad.
Para terminar me gustaría comentar, si estáis ante un despliegue de una nueva infraestructura, no hagais uso de las memoria SD, ya que solo generan problema, ya sea por esta problemática(aun sin solucionar) como para todo el tema de los logs, coredump,etc. Por ello mi recomendación es utilizar discos M2 para albergar nuestros sistema operativo y la partición scratch.
Como acabamos de comentar aun no una solución por parte de vMware, así que tocara esperar hasta solventar esta problemática.
ACTUALIZACION
En la version de vSphere 7.0U2c se ha solventado el error mencionado, en este post. Asi que mi recomendacion es actualizar cuantos antes.
