¿Cómo están estimados? Arrancando el año con todo, ¿no? Se que en el 2020 tuve un poco abandonado el blog (no pretendo excusarme), pero han sido semanas de mucho trabajo y nuevos desafíos, los cuales me insumieron gran cantidad de horas. Por eso una de las metas que me propuse para este año es dedicarle más tiempo a este espacio, y pretendo cumplirlo. Por lo tanto, acá les dejo mi primera publicación de este 2021.
Tal cual indica el título, hoy veremos la explicación y la solución al error «Invalid cluster id: null» que puede aparecer dentro de un entorno NSX for vSphere. Esto me sucedió algunas semanas atrás, cuando tuve que resolver dicho problema en la plataforma NSX-V de un cliente y el cual se presentaba con el siguiente síntoma:
Como verán en la imagen anterior, muestra un error con respecto al estado de un servicio Guest Introspection desplegado sobre un Cluster. A simple vista parece un error común, dentro de los cuales nos podemos topar en una infraestructura que cuenta con el servicio de «GI» (a partir de ahora pondré las siglas al referirme a Guest Introspection) desplegado. Pero si se fijan en la columna «Details», notarán que se encuentra vacía. ¿Qué quiere decir esto?, que si bien en los registros del NSX-V Manager figura que fueron desplegadas unas VMs de GI sobre el inventario del vCenter integrado, no aparece ningún Cluster asociado. Raro, ¿no? Es lo primero que se me vino a la cabeza, pero también pensé: no hay nada que no se puede solucionar con un «delete» y problema resuelto (¡con aires de experimentado…jajaja!). Por lo tanto, procedí con la eliminación de las VMs GI desde el portal del NSX-V Manager:
Lo cual me devolvió el siguiente mensaje:
Por si no se llega a leer, el mensaje de error dice: «Invalid cluster id: null».
¿Y esto por qué sucede? Porque alguien había eliminado el objeto Cluster dentro del inventario de vCenter, sin antes haber removido las VMs de GI desde el NSX-V Manager.
Sabemos que vSphere soporta la integración con varias plataformas (sean de VMware o de otro fabricante), lo cual permite que a través de vCenter se puedan desplegar VMs o ejecutar operaciones. En pocas palabras, si yo despliego una VM desde una plataforma externa a vCenter (en este caso desde NSX-V Manager), también debo eliminarla desde la misma plataforma. ¿Cómo puedo darme cuenta bajo que «dominio» está la VM en cuestión? Simple, puedo hacer click derecho sobre la misma y seleccionar la opción «Edit Settings», lo cual me va a devolver el siguiente mensaje de advertencia:
¿Está más que claro no? ESX Agent Manager administra la VM seleccionada, no se debe efectuar ningún cambio directo (o sea desde el web client de vCenter) y tampoco eliminarla (acá también desde el web client de vCenter). En pocas palabras nos dice que utilicemos la consola de administración de la solución con la cuál fue desplegada. Este error es muy parecido a lo que sucede con VMware SRM (Site Recovery Manager) cuando se elimina la VM «placeholder» directamente desde el inventario de vCenter, y sin antes haberle desactivado la protección desde la propia web de SRM (ya hablaré de este tipo de errores en otra publicación).
Ahora bien, teniendo el error a resolver, me puse a investigar un poco y me topé con la siguiente KB:
https://kb.vmware.com/s/article/2145454
La cual explica el paso a paso que se debe realizar, para poder eliminar el servicio de GI con dicho error. Así que lo que intentaré hacer a continuación, es dar más detalles y una explicación de cómo se debe realizar.
Aclaración: Por motivos de resguardo de los datos del cliente y para una mejor explicación, en algunas ocasiones utilizaré imágenes correspondientes a los HOL de VMware https://labs.hol.vmware.com/
1 – En el primer paso debemos acceder al EAM MOB (ESX Agent Manager/Managed Object Process) del vCenter asociado al NSX-V Manager. Para eso vamos a tener que ingresar en un browser (ej Google Chrome) lo siguiente: https://IP o FQDN del vCenter/eam/mob , con lo cual nos va a solicitar las credenciales correspondientes:
2 – En el segundo paso, una vez que hayamos ingresado, nos vamos a encontrar con lo siguiente:
Lo que tenemos que hacer en este paso es tomar nota de los IDs que figuran en la columna «Value» (lo que está en el recuadro rojo).
3 – En el tercer paso vamos a ingresar a cada uno de los IDs, haciendo click sobre los mismos:
Como podrán observar le hice click al primer ID que aparecía listado, el cual coincide con lo detallado dentro del recuadro en rojo en la siguiente imagen:
Luego hacemos click en el botón «config» (el cual está señalado con una flecha roja en la imagen anterior) y una vez dentro, vamos a ver el siguiente detalle:
En la columna «Value» que pertenece al ítem «agencyName» figura el nombre de uno de los Clusters (RegionA01-MgtEdge01) que se encuentran dentro del inventario de vCenter:
¿Y qué significa el sufijo «VMware Network Fabric»?, que se instalaron las VIBs (vSphere Installation Bundle) de NSX-V sobre los hosts que pertenecen a dicho Cluster:
Si recuerdan en la primera imagen figuraban 3 IDs distintos, los cuales van a variar de acuerdo a las configuraciones que hayan hecho sobre la infraestructura. En este caso hay 2 IDs que están asociados a dos Clusters diferentes dentro del inventario de vCenter, y el tercer ID está relacionado al despliegue de GI sobre uno de ellos:
Para que me crean voy a ingresar en los otros dos que figuran:
El ID «75f87fc2….» está asociado al Cluster «RegionA01-COMP01»
El ID «8dedfb43…» también está asociado al Cluster «RegionA01-COMP01»
¿Y por qué ese Cluster tiene 2 IDs asociados?. Como podrán observar el segundo figura con el sufijo «Guest Introspection». ¿Y a qué se debe?, a que tiene desplegado el servicio de GI sobre el mismo:
En el inventario de vCenter hay 2 VMs GI desplegadas, uno por cada host dentro del Cluster:
¿Por qué no figura el tercer Cluster «Region-A01-NSX-T-Edge» que tengo dentro del inventario de vCenter? Simple, porque no tiene los VIBs de NSX-V instalados:
4 – En el cuarto paso y siguiendo con el procedimiento detallado en la KB, vamos a hacer click en la opción «scope» (botón señalado la flecha en rojo en la primera imagen de abajo) y vamos a tomar nota del valor que figura en el campo «computeResource» (lo que figura dentro del recuadro rojo en la segunda imagen):
Este punto tenemos que hacerlo en cada uno de los IDs listados en la página «Home»:
Si prestan atención hay 2 «Object IDs» que figuran con el mismo valor: «domain-c26». ¿Y a qué se debe esto?. A que ambos están asociados al mismo Cluster «RegionA01-COMP01»
5 – El quinto paso será loguearse al NSX-V Manager mediante el protocolo SSH. Para eso podrán utilizar una herramienta como «Putty», y apuntando a la IP o FQDN del NSX-V Manager:
Si sale una advertencia, le damos click en el botón «Yes»:
Ingresamos el usuario «admin» y la contraseña correspondiente:
Una vez logueados vamos a ejecutar el comando «show cluster all»
El cual devolverá el siguiente resultado:
Como verán, figuran los «Cluster Id», de los cuales teníamos que tomar nota en el paso «4». También figuran los estados de estos, y podrán saber si tienen o no instalados los servicios de NSX-V. En la imagen aparecen los mensajes «Not ready» y «Unknow», lo cual es correcto ya que el Cluster «RegionA01-NSX-T-Edge» no cuenta con la instalación de los servicios de NSX-V.
6 – En el último paso tendremos que eliminar el registro que figure con un «Cluster ID», el cual no coincida con ninguno de los listados en el paso «5». Si bien a modo de ejemplo yo utilicé los HOL para explicar la KB de modo más detallado, cuando ejecuté esta tarea en el cliente hubo un registro el cual figuraba con el valor «domian» vacío, tal cual muestra la siguiente imagen:
Para eliminarlo, una vez dentro del mismo, tenemos que hacer click sobre la opción «void: DestroyAgency» y luego click al botón «InvokeMethod»:
Otro punto interesante para observar en una de las imágenes anteriores es el valor que figuraba como «Unset» (se muestra con el primer recuadro en rojo). Es otro claro indicador que deberíamos eliminar ese registro. Aunque si aún tenemos dudas sobre si debemos eliminarlo o no, un registro que figura de manera correcta debería tener algún valor dentro de esa columna, así como se muestra a continuación:
7 – Al volver al NSX Manager van a encontrar que el registro de GI con error desapareció.
Algunos tips antes de ejecutar la tarea:
- Asegurarse de tener un resguardo (backup) del vCenter y del NSX-V Manager, con el estado más reciente posible antes de ejecutar los pasos detallados.
- Asegurarse de tener un clon realizado de la VM del vCenter y del NSX-V Manager, con el estado más reciente posible.
- Toma nota de todo y no hacer los pasos de manera apresurada, ya que una equivocación podría implicar el borrado de un registro que no corresponde (lo cual tendría graves consecuencias).
- Estos pasos también funcionan en caso de tener desplegado un entorno vSphere configurado con 2 o más vCenters Enhanced Linked Mode.
- Estos pasos también funcionan en caso de tener desplegado NSX for vSphere Multi-Site o Single-Site.
¡Hasta acá llegamos con este post! Cualquier consulta que tengas no dudes en contactarme a través de los comentarios o vía mail. Compartilo con colegas o amigos. ¡Hasta la próxima publicación!
Se autoriza la reproducción de los materiales de este blog citando la fuente e incluyendo un enlace al mismo.
Blog de Cloud Computing y Virtualización 