El otro día escribi sobre una advertencia en el cluster al dar de baja datastore antiguos, si estáis interesados aquí, también es interesante este enlace de como dar de baja un datastore de fibra.
Bien esta vez vamos con un error un poco mas entretenido y que, como yo, podéis encontrar en versiones algo mas antiguas de vmware.
El error es este:
Lo primero que os recomiendo es que reviséis este listado de cosas a tener en cuenta al eliminar un datastore:
- Ninguna máquina virtual, plantilla, instantánea o imagen de CD / DVD está en el datastore
- El datastore no forma parte de un clúster de datastores (vSAN)
- El control de I/O de almacenamiento está deshabilitado para el datastore
- El datastore no se usa para vSphere HA heartbeat
- El LUN no se usa como RDM
- El datastore no se almacena VM swap.
- El datastore no se usa como una ubicación temporal
- El datastore no se utiliza vsantraced (/ vsantrace /)
- El datastore no se utiliza VMkernel Dump (/ vmkdump /)
- El datastore no se utiliza Scratch
Eliminar vsantraced
Vamos a usar el comando lsof que es un comando de Linux para buscar y revisar lo ficheros abiertos de vsan
~ # lsof |grep vsantraced |grep volumesxxxx vsantraced FILE 7 /vmfs/volumes/xxxxx/vsantraces/vsantraces--xxx-xx-xxxxx.gz
bueno una vez comprobado que tenemos un fichero abierto pro el sistemas y esta relacionado con vsan vamos a a parar el servicio
~ # /etc/init.d/vsantraced stop
Eliminamos el datastore y volvemos a arrancar el vsan
~ # /etc/init.d/vsantraced start
Eliminar ficheros dump
Primero vamos a ver si existen lo ficheros dump en nuestra plataforma. Para ello ponemos el comando:
~ # esxcli system coredump file list Path Active Configured Size ----------------------------------------------------- ------ ---------- ---------- /vmfs/volumes/datastore/vmkdump/xxxxxxxxx.dumpfile false false xxxxxx
Bien tenemos localizado el dump que nos esta dando problemas, ahora debemos localizar donde esta físicamente
~ # vmkfstools -D /vmfs/volumes/datastore/vmkdump/xxxxx.dumpfile Lock [type xxxxxx offset xxxxxx v 10, hb offset xxxxx gen 3, mode 1, owner 72acd052-23b119c0-0173-016076021581 mtime 250 num 0 gblnum 0 gblgen 0 gblbrk 0] Addr <4, xxx, 0>, gen 1, links 1, type reg, flags 0, uid 0, gid 0, mode xxx len xxxx, nb 1635 tbz 0, cow 0, newSinceEpoch xxx, zla 3, bs xxxxx
Bien para localizar nuestro esxi afectado en powecli ponemos lo siguiente:
Get-View -ViewType HostSystem -Propert Name, hardware.systeminfo | select { $_.name, $_.hardware.systeminfo.uuid }
Nos mostrara algo así
$_.name, $_.hardware.systeminfo.uuid -------------------------------------- {xxxxxxx, 35333036-3936-5a43-4a31-343731303248} {xxxxxxxxxxx, 72acd052-23b119c0-0173-016076021581}
Esto lo que localiza él es numero que uuid de nuestro esxi
Una vez encontrado nos logamos en ese esxi por ssh y ejecutamos lo siguiente:
~ # esxcli system coredump file remove --force
Esto nos elimina el dichoso dump
Cambiar ubicación de ScratchConfig
Bien la última y un poco la mas engorrosa seria esta, vamos a modificar la ubicación de los espacios de memoria que usan los esxi
Un poco de cultura general, el espacio de memoria virtual se configura automáticamente durante la instalación o el primer arranque de un host ESXi, y no es necesario configurarlo manualmente.
Durante la instalación, ESXi crea una partición FAT16 de 4 GB en el dispositivo de destino si hay espacio suficiente y si el dispositivo se considera Local.
Crea un enlace simbólico /scratch enlace simbólico que apunta a la partición de 4 GB. El valor por defecto de ScratchConfig.CurrentScratchLocation es la partición que /scratch .
Para corregir esto vamos al host que utiliza nuestro datastore ocupado, vamos a la pestaña manage, en el panel de la izquierda bajamos hasta system y haga clic en la opción advanced settings Buscamos la sección «ScratchConfig» y cambiamos a otra ubicación.
Reiniciamos el host.
Ahora podríamos eliminar el almacén de datos.
Espero que os sirva.