Deshacer ELM (Enhanced Linked Mode) en PSC Embedded Windows 6.x (Topología No Soportada)

en 4 marzo, 202020 septiembre, 2024 por Diego Felipe Tunubalá Medinaen vCenter Server, vSphereDeja un comentario

En nuestra oficio como consultores de TI, siempre estamos buscando alinear al cliente con las mejores prácticas del fabricante. Es por esta razón que cuando encontramos clientes con arquitecturas extrañas y fuera de soporte, es nuestro deber realizar el mejor esfuerzo por corregir y traer devuelta al cliente en la dirección correcta.

Pues bien, esta es la historia de un cliente que implementó sus vCenter Servers basados en Windows (version 6.0.x) con Platform Services Controller (PSC) Embebido en una configuración de Enhanced Linked Mode, creando sin saberlo una topología NO Soportada por VMware (KB2108548).

Desafortunadamente, este error puede ser creado ya que en el momento de la implementación el asistente de configuración no realiza una validación de la topología y es responsabilidad del consultor tener en cuenta las mejores prácticas.

Recordemos que Enhanced Linked Mode con PSC Embedded comenzó a ser soportado desde la versión 6.5U2 y para la versión VCSA (vCenter Server Appliance), no para Windows (Ver). Y es ahí donde nos preguntamos: ¿Que hacia un ELM configurado en esos vCenters 6.0?. «¡De todo se ve en la viña del señor!». A continuación explicaremos el procedimiento (no soportado), para romper el ELM y poder realizar una actualización hacia la version 6.5.

Nota 1: Al ser una topología no soportada, el procedimiento tampoco esta soportado. Sin embargo, es una manera de deshacer el Enhanced Linked Mode de forma segura, pero deberá aplicarlo bajo su propio riesgo.

En este punto podrá surgir la pregunta, ¿Para qué querría separar el ELM si esta funcionando?, las respuestas son básicamente tres:

1. No es una buena práctica, por lo cual no se recomienda configurar en la version 6.0 de vCenter Server basa en Windows.

2. Es una topología No Soportada y si tienes un problema con los vCenter Server, no hay mucho que el fabricante pueda hacer si abrimos un caso con ellos.

3. Al intentar realizar una actualización hacia la versión 6.5.x o posteriores, obtendrá el siguiente error: «You have embedded vCenter configuration with VMware Single Sign On linked to some other node. Unlink single sign on before to upgrading«. Y es esta la razón, por la cual estamos escribiendo este post.

Como podríamos evidenciar, el error es generado en los primeros pasos de la actualización, por lo cual no quedará mas remedio que corregir el error antes de intentar de nuevo la actualización.

Nota 2: Para aclarar un poco las topologías antes de iniciar con el procedimiento, mostraré cual es la topología actual No Soportada y cual será la Topología después del procedimiento.

Topología Actual (No Soportada)

Topología futura (Soportada)

ANTES DE COMENZAR

Existen diferentes caminos para migrar hacia una topología soportada, entre los cuales podríamos tener:

1. Implementar un Platform Services Controller (PSC) Externo en cada sitio, conectados al mismo dominio de Single Sign On, para después re apuntar los vCenters de cada sitio hacia sus correspondientes nuevos PSC Externos KB2113917. Para este caso deberá validar qué soluciones VMware (vRealize Operation, vSphere Replication, Site Recovery Manager, etc) tiene conectadas al PSC Embedded de los vCenter, ya que tendrá que garantizar el trafico desde dichas soluciones hacia el nuevo direccionamiento de los PSC Externos. Podría necesitar creación nuevas reglas en el FW que no se tenían configuradas.

2. Si su vCenter cuenta con los prerrequisitos para migrar a la versión vCenter Server Appliance (Ver), llevarlo a una versión superior o igual a VCSA 6.5U2, garantizaría la misma Topología pero esta vez soportada por VMware (Ver). De manera que intentar realizar una actualización y migración no suena descabellado.

Nota 3: Si ninguno de los caminos presentados anteriormente es una opción viable, o por el contrario es un requerimiento de la organización deshacer el ELM, continúe con el procedimiento.

PROCEDIMIENTO PARA DESHACER ELM

Para nuestro caso de laboratorio hemos construido la misma Topología del cliente (No soportada) con las maquinas virtuales vm06 para el vCenter Server del Sitio-1y vm07 para el vCenter Server del Sitio-2.

1. Tome un snapshot de las VMs asociadas a los vCenter Server del Sitio-1 y Sitio-2, con el fin de tener un mecanismo de rollback si algo va mal. Si tiene soluciones VMware adicionales conectadas a los vCenter, tome un snapshot para esas maquinas también.

2. Abra un navegador web con dos pestañas nuevas, en una inicie sesión hacia el vSphere Web Client de vCenter Server del Sitio-1 (https://vm06.lab.local/vsphere-client/?csp) y en la otra inicie sesión hacia el vSphere Web Client de vCenter Server del Sitio-2 (https://vm07.lab.local/vsphere-client/?csp). Verifique que el estado de los servicios en Home|Administration|System Configuration es saludable para los dos nodos.

3. Apague uno de los vCenter Server. En este caso, comenzaremos realizando el procedimiento en el vCenter Server del Sitio-2 (vm07) por lo cual apagaremos de manera controlada la VM de vCenter Server del Sitio-1 (vm06). Una vez apagado el servidor, al refrescar la vista del vSphere Web Client de Sitio-2, podrá observar que ahora aparece una notificación indicándole que no se puede conectar al nodo https://vm06.lab.local:443/sdk (esto es normal).

4. Inicie conexión RDP hacia el servidor Windows Server en donde esta instalado el vCenter Server del Sitio-2 (vm07).

5. Abra una interface de línea comandos CMD como administrador y ejecute los siguientes comando:

cd C:\Program Files\VMware\vCenter Server\bin\
cmsso-util unregister --node-pnid Platform_Services_Controller_System_Name_Site1 --username administrator@your_domain_name --passwd vCenter_Single_Sign_On_password


Ejemplo:
cmsso-util unregister --node-pnid vm06.lab.local --username administrator@vsphere.local --passwd VMware1!

Nota 4: La salida de comando debería ser Success.

6. Cierre sesión sobre el vSphere Web Client de vCenter del Sitio-2 que esta encendido (vm07) y luego inicie sesión nuevamente. Ahora puede observar que en Home|Administration|System Configuration, aparece un único nodo y la notificación de la parte superior ya no aparece.

6. Encienda la máquina de vCenter Server del Sitio-1 (vm06), y espere que inicialice el servicio de vSphere Web Client para poder iniciar sesión.

8. Inicie Sesión en el vSphere Web Client del vCenter Sitio-1 (vm06) aproximadamente 10 min después de haber encendido la VM. Vaya hasta Home|Administration|System Configuration y podrá observar que este nodo aún continua viendo la conexión ELM. Esto es normal ya que al haberlo apagado no se dio cuenta del cambio, pero de haber ejecutado el comando con la VM encendida el PSC de este vCenter estaría muerto. Así que continuemos!

9. Apague de manera controlada ahora la máquina del vCenter Server del Sitio-2 (vm07). Ya que el procedimiento se realizará ahora sobre la VM de vCenter Server del Sitio-1 (vm06), que aún ve la configuración ELM (aunque ya no esta replicando en el dominio de SSO). Una vez apagado el servidor, al refrescar la vista del vSphere Web Client del vCenter del Sitio-1 (vm06), nuevamente podrá observar una notificación en la parte superior indicándole que no se puede conectar ahora al nodo https://vm07.lab.local:443/sdk (esto nuevamente es normal).

10. Inicie conexión RDP hacia el servidor Windows Server en donde esta instalado el vCenter Server del Sitio-1 (vm06).

11. Abra una interface de línea comandos CMD como administrador y ejecute los siguientes comando:

cd C:\Program Files\VMware\vCenter Server\bin\
cmsso-util unregister --node-pnid Platform_Services_Controller_System_Name_Site2 --username administrator@your_domain_name --passwd vCenter_Single_Sign_On_password


Ejemplo:
cmsso-util unregister --node-pnid vm07.lab.local --username administrator@vsphere.local --passwd VMware1!

Nota 5: La salida de comando debería ser Success.

12. Cierre sesión sobre el vSphere Web Client de vCenter del Sitio-1 que esta encendido (vm06) y luego inicie sesión nuevamente. Ahora puede observar que en Home|Administration|System Configuration, aparece un único nodo y la notificación de la parte superior ya no aparece.

13. Encienda el vCenter del Sitio-2 (vm07), y espere que inicialice el servicio de vSphere Web Client para poder iniciar sesión.

14. Inicie Sesión en el vSphere Web Client del vCenter del Sitio-2 (vm07) aproximadamente 10 min después de haber encendido la VM. Vaya hasta Home|Administration|System Configuration y podrá observar que el nodo ya ha sido separado y no muestra ninguna dependencia con el vCenter Server del Sitio-1.

De igual forma el vCenter Server del Sitio-1 (vm06) no muestra ninguna dependencia con el vCenter Server del Sitio-2.

15. (Opcional) Si ahora ejecutamos nuevamente el asistente de actualización sobre cualquiera de los vCenter Server Windows, no obtendrá el error mencionado anteriormente y la actualización se desarrollará de manera satisfactoria. Es así como podemos pasar de una Topología No Soportada a una Topología Soportada.

CONCLUSIÓN

El KB2106736, indica explícitamente que el comando cmsso no deber ser utilizado para deshacer una configuración ELM, por esta razón este procedimiento no esta soportado. Por otra parte, existe una alternativa si se realizan los pasos como se indicaron.

Si por alguna razón ejecuta el comando con las VMs de ambos sitios encendidas, el resultado será que el vCenter donde ejecutó el comando quedará separado y funcionando. Sin embargo, la suerte para el otro vCenter no será la misma ya que el PSC del otro vCenter tendrá afectación y su vCenter asociado no funcionará mas. Y obtendrá un error como el siguiente:

Configurar notificaciones en vRealize Automation 7.x con cuenta Gmail

en 24 octubre, 201920 septiembre, 2024 por Diego Felipe Tunubalá Medinaen vRealize Automation/Aria AutomationDeja un comentario

¿Por qué utilizar una cuenta externa?

En la mayoría de las ocasiones, cuando tenemos un ambiente de Laboratorio, no tenemos los recursos disponibles en la infraestructura para crear nuestro propio servidor de correo, ya sea por capacidad de procesamiento, memoria, storage, licencias, experiencia en la configuración del mismo o simplemente no contamos con el tiempo suficiente para hacerlo.

Es por esta razón, que en este post explicaremos el procedimiento para emplear una cuenta de Gmail (100% gratis) como Email Server, Inbound (usada para responder a las notificaciones y completar tareas) y Outbound (usada para enviar notificaciones basadas en eventos del sistema), de la solución vRealize Automation 7.x y de esta manera poder notificar a los administradores acerca de lo que sucede en la infraestructura.

Nota 1: No se recomienda utilizar cuentas de correo externo para ambientes productivos.

PROCEDIMIENTO

Dicho lo anterior, veamos cada uno de los pasos involucrado en la configuración de las notificaciones para vRealize Automation, empleando una cuenta Gmail.

1. Cree una cuenta Gmail o utilice una cuenta de correo existente.

Para efectos de laboratorio he decido crear una cuenta nueva únicamente para este fin. Para crear una cuenta nueva haga clic aquí. Una vez creada, inicie sesión en su cuenta recientemente creada y siga las instrucciones del asistente de configuración de Gmail.

2. Habilite en la cuenta el acceso IMAP (Internet Message Access Protocol)

El Protocolo de Acceso a Mensajes de Internet (IMAP), es un protocolo de aplicación que permite el acceder los mensajes almacenados en un servidor de Internet y permite tener acceso al correo electrónico desde cualquier equipo que tenga una conexión a Internet.

Por defecto, la cuenta Gmail esta configurada con IMAP deshabilitado por lo que será necesario habilitarlo como sigue:

a) En su computadora, abra Gmail.
b) En la esquina superior derecha, haga clic en Configuración .
c) Haga clic en Configuración.
d) Haga clic en la pestaña Reenvío y correo POP/IMAP.
e) En la sección «Acceso IMAP», haga clic en Habilitar IMAP.
f) Por ultimo, haga clic en Guardar cambios.

Nota 2: Tenga en cuenta que para configurar el cliente IMAP vamos necesitar mas adelante los siguientes datos propios de Gmail y de la cuenta asociada.

3. Active el acceso de apps menos seguras en la cuenta Gmail.

Si una app o un sitio no cumplen con los estándares de seguridad, es posible que Google bloquee a las personas que intenten acceder a su cuenta desde ellos. Las apps menos seguras pueden permitir que los hackers accedan a la cuenta con más facilidad. Es importante bloquear los accesos desde ellas con el fin de mantener su cuenta protegida.

Dicho lo anterior, la cuenta Gmail por defecto es configurada para denegar el acceso de app menos seguras. Sin embargo, para este fin, debe ser habilitado como sigue:

Nota 3: No realice este procedimiento en su cuenta de correo electrónico personal.

a) En su computadora, abra Gmail.
b) En la esquina superior derecha, haga clic en Google Apps.
c) Haga clic en Cuenta.
d) Haga clic en Seguridad y baje hasta la sección Acceso de Apps menos seguras.
e) Haga clic en Activar el acceso (no se recomienda).
f) Por ultimo, haga clic en el botón Permitir el acceso de apps menos seguras.

4. Configure Email Servers en vRealize Automation appliance

Una vez realizado lo anterior, podrá configurar los Email Servers Inbound y Outbound en vRealize Automation 7.x como sigue:

a) Inicie sesión en el Tenant deseado https://IPóHostname_vRA/vcac/org/nombre_tenant con un usuario Tenant Administrator. (si es el default tenant entonces https://IPóHostname_vRA/vcac/ ).
b) Haga clic en la pestaña Administration.
c) Haga clic en la sección Notifications y luego clic en Email Servers.
d) Clic en New () y seleccione Email – Inbound.
e) Configure el servidor IMAP con los datos suministrados en la Nota 2 y los datos de la cuenta de correo electrónico creada en el paso 1.
f) Haga click en el botón TEST CONNECTION. Si la conexión es exitosa ( Connection tested successfully) haga clic en OK.

Nota 4: El test debería pasar, si no es así verifique la contraseña. Si la contraseña es correcta y recibe el mensaje Invalid username or password, revise los pasos anteriores para la configuración de IMAP y Acceso de app menos seguras.

g) Clic en New () y seleccione Email – Outbound.
h) Configure el servidor SMTP con los datos suministrados en la Nota 2 y los datos de la cuenta de correo electrónico creada en el paso 1.
i) Haga click en el botón TEST CONNECTION. Si la conexión es exitosa ( Connection tested successfully) haga clic en OK.

Nota 5: El test debería pasar, si no es así verifique la contraseña. Si la contraseña es correcta y recibe el mensaje Invalid username or password, revise los pasos anteriores para la configuración Acceso de app menos seguras. Adicionalmente, si no ha permitido el Acceso de app menos seguras, recibirá un correo con una advertencia de inicio de sesión.

Por ultimo, al finalizar la configuración de Email Servers, la vista deberá lucir de la siguiente forma.

5. Seleccione los escenarios de notificación

En la pestaña Administration | Notifications | Scenarios, seleccione de la lista, la fuente de notificación que desea Activar o Suspender mediante los botones o .

6. Configure una dirección de correo electrónico a los usuarios

vRealize Automation enviará las notificaciones a las cuentas de correo electrónico configurada para cada uno de los usuarios. De esta manera si se han configurado usuarios de dominio, esta configuración deberá realizarse en el Active Directory.

Para visualizar el cambio realizado en el AD desde vRealize Automation será necesario forzar una sincronización, para esto debemos realizar los siguientes pasos:

Si por el contrario, esta usando únicamente usuarios locales (no recomendado), defina una cuenta de correo electrónico para los usuarios locales del Tenant, iniciando sesión como System Administrator (Administrator) en https://IPóHostname_vRA/vcac/ .

a) Vaya a la Sección Tenants.
b) Seleccione el nombre del Tenant y clic en editar.
c) Seleccione la pestaña Local Users.
d) Seleccione el usuario local y defina una cuenta de correo electrónico.

7. (Opcional) Cree o edite un Custom Group

Los Custom Group proporcionan un control más granular sobre el acceso dentro de vRealize Automation, que los Business Groups que corresponden a una línea de negocio, departamento u otra unidad organizativa; debido a que los Custom Groups permite centralizar la asignación de roles dentro del Tenant.

Para efectos de laboratorio, se ha creado un Custom group LAB-vRA-Admins para agrupar todos los usuarios de dominio con permiso de administrador, y se le han otorgado todos los roles (esto es valido para entorno de laboratorio), para un ambiente productivo deberá segregarse cada uno de los roles. Cree un Custom Group siguiendo los pasos descritos aquí.

En los miembros asignados al Custom Group se encuentra el usuario de dominio Diego Tunubalá (diego.tunubala@lab.local) que como observamos muestra el email diego.tunubala@xxxx.com configurado en el Active Directory.

8. (Opcional) Cree o edite un Business Group

Los Business Groups se utilizan para asociar un conjunto de servicios y recursos a un conjunto de usuarios. Estos grupos a menudo corresponden a una línea de negocio, departamento u otra unidad organizativa. Puede crear un Business Group para poder configurar reservas y autorizar a los usuarios a aprovisionar elementos del catálogo de servicios para los miembros del grupo empresarial. Cree un Custom Business Group siguiendo los pasos descritos aquí.

En nuestro ambiente de laboratorio se ha creado el Business Group LAB-BS-Group01 cuyos miembros son el Custom Group LAB-vRA-Admins, con el Role Manager asignado, y el grupo de dominio gvarusers@lab.local con el role de usuario.

Con el fin de verificar las notificaciones tanto del lado del administrador como del lado del usuario, adicionaremos el usuario pruebavra@lab.local al group de dominio gvarusers@lab.local en el Active Directory.

Nota 6: Al usuario pruebavra@lab.local le fue configurado una cuenta de correo electrónico del mismo modo a lo explicado en el paso 6, pero con una cuenta de correo diferente.

9. Verificar la llegada de notificaciones

La verificación de las notificaciones es una tarea muy sencilla, ya que basta con iniciar sesión en el Tenant con un usuario autorizado y realizar la solicitud de un ítem del catalogo. Para este prueba utilizaremos el usuario pruebavra@lab.local y realizaremos una solicitud de despliegue.

Debido a que la solicitud de ítems del catalogo tiene configurada un Approval Policy, la solicitud quedará a la espera de la respuesta del usuario Aprobador configurado en el Tenant (para este caso de laboratorio, es el mismo Tenant Administrator) y será enviada una notificación.

En este punto podemos pasar a verificar los mensajes enviados en la cuenta de Gmail configurada y observaremos que desde la cuenta se ha enviado un mail tanto al usuario Administrador del Tenant como al usuario solicitante.

En la cuenta de correo asociada al Administrador del Tenant diego.tunubala (mismo usuario aprobador), llegará un correo con dos acciones disponibles Approve y Reject. Que permitirán Aceptar o rechazar el despliegue y enviar un comentario al usuario.

Mientras tanto en la cuenta de correo asociada al usuario de prueba pruebavra llegará una notificación indicando que la solicitud ha sido presentada.

10. Aprobar solicitud a través de email.

Debido a que el usuario de dominio diego.tunubala@lab.local tienen configurado el role de Aprobador, al hacer clic en el enlace Approve, nos dará la opción de enviar un mensaje adjunto a la aprobación que será enviada a vRealize Automation de manera inmediata sin necesidad de entrar al portal de vRA. Lo mismo sucede si elegimos la opción Reject.

Una vez aprobada la solicitud, el usuario será notificado mediante un correo con el status Approved.

Después de la aprobación de la solicitud el flujo de despliegue continuará, finalizando nuevamente con una notificación vía correo electrónico al usuario, esta vez con la información de la VM o servicio solicitado desde el catálogo.

Automatizando configuración de Dump Collector en ESXi 6.x

en 31 enero, 201920 septiembre, 2024 por Diego Felipe Tunubalá Medinaen ESXi, vSphereDeja un comentario

De manera similar a como funciona Syslog Collector el cual recolecta todos los archivos Logs de los hosts ESXi, Dump Collector recopila el estados de la memoria VMkernel (Core Dumps) que generan los hosts cuando el sistema encuentra una falla crítica y se produce la conocida PSOD (Purple Screen of Death) o pantalla de la muerte.

Antes de comenzar con la configuración, debemos saber que durante la instalación del hipervisor ESXi se crean dos particiones (Diagnostic Patition) encargadas de almacenar estos archivos, una Primaria de (110 MB) y una Secundaria de (2.5 GB). Sin embargo, es recomendable configurar un servidor remoto (Log Server) para transferir estos archivos a través de la red con el fin de tener una mayor retención de los mismos y poder realizar un mejor proceso de seguimiento y troubleshooting en la detección de la causa raíz de la falla. Para mayor información acerca del diseño de particiones de ESXi haga click Aquí.

Por suerte sino contamos con un Log Server en nuestra infraestructura a dónde dirigir estos Dumps, podemos utilizar la partición incluida en el vCenter Server Appliance dedicada para este propósito. Para mayor información de los servicios incluidos en vCenter Server consulte Componentes y Servicios de vCenter Server.

(Opcional) CONFIGURAR SERVICIO DUMP COLLECTOR EN VCENTER SERVER APPLIANCE

Si vamos a utilizar la partición del vCenter para almacenar los Core Dumps, debemos tener en cuenta que el servicio Dump Collector no viene activo por defecto por lo que será necesario iniciarlo y dejarlo en modo automático para que se inicie con el Sistema Operativo. Para esto sigamos los siguientes pasos:

1. Inicie sesión en el vCenter Server Appliance (VCSA) desde el vSphere Web Client con un usuario que cuente con permisos de administrador y luego vaya a Home > Administration > System Configuration > Services.

2. En el panel de servicios del lado izquierdo haga click en el servicio VMware vSphere ESXi Dump Collector.

3. En el panel central haga click en Actions > Edit Startup Type…,seleccione Automatic y click en OK.

4. (Opcional) Haga click en la pestaña Manage para verificar el tamaño asignado al repositorio. Si desea cambiarlo haga click en el botón Edit… El valor por defecto es 2 y el máximo 10.

5. Haga click en icono Start the Service para iniciar el servicio

CONFIGURAR ESXi DUMP COLLECTOR

Si ya configuramos el servicio de Dump Collector en el VCSA o si por el contrario tenemos un Log Server disponible en la infraestructura, podremos iniciar con la configuración en cada uno de los ESXi como sigue, utilizando como es costumbre la línea de comandos ESXCLI o PowerCLI para automatizar la configuración en todos los hosts del vCenter.

ESXCLI

La utilidad de línea de comando esxcli puede ser utilizada en la consola del host ESXi, en el vCLI (vSphere CLI) o en el vMA (vSphere Management Assistant).

1. Inicie una sesión SSH al host ESXi que desea configurar ESXi Dump Collector

2. Configure el ESXi con la dirección IP del servidor remoto que será utilizado como Dump Collector ejecutando la siguiente línea de comandos:

esxcli system coredump network set --interface-name vmkX --server-ip xx.xx.xx.xx --server-port 6500

Nota 1: Como mejor practica se recomienda utilizar un puerto VMkernel diferente al de gestión (vmk0). Sin embargo, para ambientes de laboratorio utilizaremos el mismo.

Nota 2: La dirección IP del servidor remoto puede ser IPv4 o IPv6 ya que ambas son soportadas. Para el ejemplo la dirección IP será la dirección del VCSA.

3. Habilite ESXi Dump Collector ejecutando la siguiente línea:

esxcli system coredump network set --enable true

4. (Opcional) Verifique que ESXi Dump Collector esté configurado correctamente ejecutando la siguiente línea de comandos:

esxcli system coredump network check

PowerCLI

Con el fin de automatizar la tarea en todos los hosts del vCenter, podemos apoyarnos en la herramienta PowerCLI ejecutando script que se muestra a continuación:

1. Instale PowerCLI sino lo tiene instalado, con ayuda del siguiente video haciendo click aquí.

2. Inicie sesión hacia el vCenter desde el panel de script de PowerShell ISE ejecutando los siguientes cmdlets y espere a que le solicite usuario y contraseña:

Connect-VIServer FQDN_IP_vCenterServer

3. Ejecute el siguiente script para configurar ESXi Dump Collector en todos los hosts del vCenter

#Configurar ESXi Dump Collector

$MyLogServer= “IP_FQDN_Remote_Server”

Foreach ($hostx in (Get-VMHost)){
Write-Host "Configuring Dump Collenctor in $hostx" -ForegroundColor Yellow
$esxcli = Get-EsxCli -vmhost $hostx
$esxcli.system.coredump.network.set($null, “vmk0”, $null, $MyLogServer, 6500)
$esxcli.system.coredump.network.set($true)
$esxcli.system.coredump.network.get()
}

4. Verifique la configuración ejecutando el siguiente script

#Check ESXi Dump Collector

Foreach ($hostx in (Get-VMHost)){
Write-Host "Checking dump collector in host $hostx" -ForegroundColor Yellow
$esxcli = Get-EsxCli -vmhost $hostx
$esxcli.system.coredump.network.get()
}

VERIFICACIÓN DE LA TRANSFERENCIA DE CORE DUMPS

Una manera de verificar que los archivos Dump están siendo enviados de manera correcta al servidor remoto configurado, es generar un crash o PSOD en el servidor de manera controlada como sigue:

1. Abra la consola remota del servidor (iLO, CIMC, iDRAC, etc.) en el que desea simular la falla, para monitorear el comportamiento del servidor.

2. Inicie una sesión SSH en el host ESXi y ejecute la siguiente línea de comandos:

vsish -e set /reliability/crashMe/Panic 1

3. Espere que se genere el archivo dump y reinicie el servidor.

4. Verifique en el servidor remoto configurado, la existencia del archivo zdump generado.

5. (Opcional) Si utilizó VCSA como repositorio de los archivos Dump inicie sesión SSH al vCenter Server, active la interfaz shell digitando Shell en la pantalla y verifique el log netdumper.log ejecutando la siguiente línea de comandos para verificar que el archivo haya sido transferido y validar su ruta de destino:

cat /var/log/vmware/netdumper/netdumper.log

Nota 3: El nombre del archivo generado contiene el nombre zdump y para el ejemplo con Dump Collector configurado en el VCSA, los archivos son alojados en la siguiente ruta /var/core/netdumps/ffff/AA/BB/CC/DD o lo que es lo mismo /storage/core/netdumps/ffff/AA/BB/CC/DD donde AA.BB.CC.DD indican los octetos de la dirección IP del host ESXi.

Resolviendo los Errores: “The VM failed to resume on the destination during early power on” y «Unable to create a swap file. The value of ‘sched.swap.dir’ specified in the VM’s configuration file is invalid»

en 14 noviembre, 201820 septiembre, 2024 por Diego Felipe Tunubalá Medinaen vSphereDeja un comentario

En esta ocasión nos vamos a centrar en la solución de un par de errores que me han aparecido varias veces en los últimos días durante una actualización de infraestructura en la cual se debía constantemente liberar hosts entrándolos en modo mantenimiento para que a través de las funcionalidades de DRS y vMotion evacúe las VMs y de esta manera poder realizar la correspondiente actualización del hipervisor. Es por esta razón hemos replicado su comportamiento en un ambiente controlado de laboratorio.

Pues bien, el problema radica en que algunas máquinas fallan en la tarea de vMotion con el error: “The VM failed to resume on the destination during early power on”, impidiéndonos hacer el movimiento en caliente y como consecuencia no podemos ingresar el host en modo mantenimiento. Hasta ahí un parte del problema ya que al apagar la VM esta se migra como es de esperarse, pero no enciende indicando ahora que no es posible crear el archivo .vswp con el error “Unable to create a swap file. The value of ‘sched.swap.dir’ specified in the VM’s configuration file is invalid”

A los que no les ha pasado que suertudos son. Sin embargo, pueda que en algún momento les pase y en ese momento !que no panda el cunico!, siguiendo el procedimiento a continuación saldremos adelante.

CAUSA #1

Este problema se produce cuando se realiza un Storage vMotion para mover los disco de la máquina virtual a otro Datastore mientras el Change Block Tracking (CBT) está habilitado y la máquina virtual está encendida. Esto provoca que los archivos de configuración de la máquina virtual permanezcan en la ubicación original y adicionalmente los archivos Disk-Name.ctk de la máquina virtual queden en un estado bloqueado, lo que evita que las futuras operaciones de vMotion tengan éxito.

SOLUCIÓN #1

Una vez entendido por qué no podemos mover la maquina, vamos a resolver el problema siguiendo los siguientes pasos:

1. Apague la máquina virtual de manera controlada

2. Click derecho sobre la máquina y Edit Settings

3. Click en la pestaña VM Options

4. Expanda la opción Advanced y click en Edit Configuration… frente a Configuration Parameters

5. Para filtrar la búsqueda escriba ctkEnabled en el campo superior derecho

6. Verifique que los valores de ctkEnabled y scsix:x.ctkEnabled se encuentren en False, sino es así cámbielos. y haga click en OK

7. Verifique que en la opción ‘Swap File location’ se encuentre en la opción Default, a no ser que en su infraestructura tenga un datastore con discos de estado solido dedicado a los archivos swap. Haga click en OK para aceptar el cambio en la configuración

8. Migre la máquina a otro host disponible y enciéndala

9. Verifique que la VM se pueda mover entre diferentes hosts en el estado Powered On.

Nota: Si después de realizar el procedimiento anterior no presenta ningún problema, usted ha sido bendecido y puede irse a tomar un café con la satisfacción de haber resuelto el problema.

Pero si por el contrario, luego de hacer el procedimiento anterior la máquina no enciende en el otro host con el siguiente error “An unexpected error was received from the ESX host while powering on VM vm-xxxxx,
Failed to power on VM, Unable to create a swap file. The value of ‘sched.swap.dir’ specified in the VM’s configuration file is invalid”, entonces continúe con el procedimiento.

CAUSA #2

Este problema ocurre cuando la ruta sched.swap.dir no se actualiza en el archivo .vmx de la máquina virtual después de migrarla.

SOLUCIÓN #2

1. Apague la máquina virtual de manera controlada

2. Migre la máquina a otro Datastore de manera temporal o definitiva

3. Inicie sesión en el host en donde se aloja la VM. Utilice SSH con Putty.exe si es amante de la línea de comandos o una sesión SFTP con WinSCP si prefiere la interfaz grafica. Navegue hasta la siguiente ruta

/vmfs/volumes/datastore/virtual_machine/, donde datastore es el nombre del datastore y virtual_machine es el nombre de la máquina

4. Si utiliza Putty.exe, ejecute el comando vi virtual_machine.vmx para ingresar y editar el archivo de configuración de la máquina. Por otra parte, si utiliza WinSCP haga doble click en el archivo virtual_machine.vmx para abrirlo

5. Cualquiera que haya sido el método para ingresar al archivo de configuracion .vmx, busque la entrada nombrada como sched.swap.dir. Podrá observar que la ruta indicada para dicha entrada no corresponde con el datastore que almacena los archivos de la maquina. Proceda entonces a borrar el contenido dentro de las comillas para forzar a que en el próximo encendido se actualice la entrada.

6. Si usó Putty.exe y el comando vi para editar el archivo, presione la tecla Esc, luego escriba :wq! para guardar y salir. Si por el contrario usó WinSCP haga click en el icono de guardar

7. Recargue el archivo de configuración de la máquina virtual en el host ESXi ejecutando el siguiente comando a través de una sesión SSH en el host que aloja la VM

for a in $(vim-cmd vmsvc/getallvms 2>&1 |grep invalid |awk ‘{print $4}’|cut -d \’ -f2);do vim-cmd vmsvc/reload $a;done

8. Antes de encender la maquina volvamos a Edit Settings | VM Options | Advanced | Configuration Parameter | Edit Configuration… y verifique que los valores de ctkEnabled y scsix:x.ctkEnabled se encuentren en False, sino es así cámbielos. y haga click en OK hasta cerrar la ventana de configuración de la VM.

9. Encienda la máquina virtual. Si todo ha ido bien la máquina encenderá sin problemas y podrá hacer el vMotion en el estado Powered On como debe ser.

ATENCIÓN!!!

TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO TEMPORAL, UTILIZADO PARA FINES DE ESTUDIO.

REFERENCIAS

Desbloquear usuario root en vSphere Replication (Photon OS)

en 5 octubre, 201820 septiembre, 2024 por Diego Felipe Tunubalá Medinaen vSphere, vSphere ReplicationDeja un comentario

Hace unas semanas publiqué una entrada para reiniciar la contraseña de root de vSphere Replication Appliance 8.1 o Appliances basados en Photon OS. Sin embargo en algunas ocasiones el problema no es olvidar la contraseña sino bloquear la cuenta de usuario por numerosos intentos fallidos debido a algún carácter especial y la configuración del teclado. De esta manera aunque reiniciemos la clave si el usuario está bloqueado, continuaremos sin poder ingresar a la consola de administración. Si el usuario se encuentra bloqueado la consola de la maquina virtual mostrará un mensaje indicándolo y deberá seguir el siguiente procedimiento.

PROCEDIMIENTO

1. Edite la configuración de la máquina virtual asociada a vSphere Replication, haciendo click derecho –>Edit settings –>VM Options. Adicione un tiempo de retardo en milisegundos en Boot Delay para tener tiempo de ejecutar el menú GRUB (GRand Unified Bootloader), el cual es un gestor de arranque múltiple que permite elegir el sistema operativo a iniciar.

2. Tome un Snapshot de la máquina virtual antes de proceder con el siguiente paso de manera que tengamos un punto de control en caso de llegar a necesitarlo

3. Reinicie de manera controlada el virtual appliance haciendo click en Actions -> Guest OS -> Restart

4. Permanezca atento al momento en que aparece el logo de Photon, para presionar la tecla ‘e’ inmediatamente y de esta manera evitar que el sistema operativo del appliance inicie y debamos realizar un reinicio controlado nuevamente

5. Una vez dentro de la pantalla GNU GRUB ubique el cursor al final de la segunda línea, adicione rw init=/bin/bash para montar la partición con permisos de lectura y escritura. Luego presione F10 como se muestra a continuación para cargar la configuración

6. Ejecute el comando pam_tally2 –user=root –reset para desbloquear el usuario root

7. (Opcional) Si además de desbloquear el usuario root desea cambiar su contraseña, ejecute el comando passwd para cambiarla, solicitandole un nuevo password y la confirmación del mismo

8. Ejecute el comando umount / para desmontar el filesystem

9. Reinicie el virtual appliance ejecutando el comando reboot –f

10. Por último, inicie sesión en la consola de administración y si todo ha salido bien remueva el Snapshot de la máquina virtual tomado anteriormente

Nota: El procedimiento anterior indicó el paso a paso que debe seguirse para restablecer la contraseña de vSphere Replication Appliance 8.1, pero que además puede aplicarse de igual forma a un vCenter Server Appliance o cualquier Appliance basado en Photon OS.

ATENCIÓN!!!

TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO TEMPORAL, UTILIZADO PARA FINES DE ESTUDIO.

Instalando y utilizando ESXi Compatibility Checker

en 13 septiembre, 201820 septiembre, 2024 por Diego Felipe Tunubalá Medinaen ESXi, vSphere3 comentarios

Una de las tareas mas importantes al iniciar un nuevo proyecto de implementación es el levantamiento de información. Un correcto levantamiento de información nos llevará a cumplir las expectativas del cliente, realizar un diseño apropiado y garantizar la disponibilidad de la solución. Es esta última en la cual juega un papel muy importante la matriz de compatibilidad que debemos presentar al cliente como prerrequisito para una implementación greenfield (desde cero) o brownfield (infraestructura existente), permitiéndonos estar seguros que los componentes de hardware, firmware y drivers utilizados en la infraestructura ya han sido probados y avalados por los fabricante.

A mi modo de ver, la creación de esta matriz de compatibilidad siempre fue una tarea muy tediosa al ser manual y repetitiva. Y aunque podemos apoyarnos en scripts para obtener la información de los servidores de manera automática seguía existiendo la tarea de verificar múltiples paginas web en el VMware Compatibility Guide para verifica la compatibilidad de las versiones de la infraestructura.

Hace un par de meses había leído algo acerca de ESXi Compatibility Checker y su capacidad para realizar el levantamiento de esta matriz de manera automática, pero fue hasta hace unas semanas que debido a los múltiples proyectos decidí probarla para optimizar el tiempo, y desde entonces me ha parecido muy útil en el proceso inicial del levantamiento de información.

¿Que es ESXi Compatibility Checker?

Básicamente es un script python que puede validar la compatibilidad del hardware directamente en la matriz de VMware para detectar posibles problemas en la actualización del hipervisor ESXi, permitiéndonos generar un reporte bastante claro que incluye el estado de compatibilidad, detalles del hardware, versiones de drivers e incluso enlaces directos hacia la matriz de VMware para cada uno de los componentes del servidor.

ESXi Compatibility Checker es capaz de generar un reporte para múltiples servidores ESXi que hacen parte de un vCenter Server e incluso múltiples vCenter y de esta manera validar rápidamente la compatibilidad de todos los hosts en la versión actual o hacia una version superior de hipervisor. ¡Bastante prometedor!

INSTALACIÓN

1. Descargue el último paquete de Python directamente desde el python download. Haga click en Download y seleccione el sistema operativo de su equipo desktop. Para el ejemplo la instalación se realizará en un equipo Windows por lo cual se descarga el ejecutable para este sistema operativo.

2. Una vez descargado ejecute el instalador del paquete de Python y asegúrese de marcar el check Add Python 3.x to PATH que se encuentran en la parte inferior para crear la variable de entorno en el equipo al realizar la instalación

3. Haga click en Install Now y espere que termine el proceso de instalación

4. Desde un Command Prompt navegue hasta el directorio \AppData\Local\Programs, y ejecute el comando Python –v para validar la versión del python instalada

5. Instale ahora el paquete Pyvmomi ejecutando el siguiente comando python.exe -m pip install pyvmomi

6. Continue con la instalación del paquete crypto ejecutando el comando python.exe -m pip install crypto

7. Por último instale el paquete pyopenssl ejecutando el comando python.exe -m pip install pyopenssl

UTILIZACIÓN

1. Una vez instalado el python descargue el script desde el link oficial de ESXi Compatibility Checker haciendo click en Download

2. Descomprima el archivo .zip descargado anteriormente y desde la consola de Command Prompt navegue hasta el directorio que acaba de extraer

3. Solo queda lanzar el script con extensión .py con algunos de los argumentos disponibles. Por ejemplo, para conectarnos a un vCenter 6.5 U2 y obtener la matriz de compatibilidad con la version ESXi 6.7 basta con ejecutar el siguiente comando: python compchecker.py -s IP_FQDN_HOST -u USER –r –v 6.7, donde –r genera un reporte y –v valida la compatibilidad con una versión especifica.

Ejemplo: python compchecker.py -s 10.123.123.120 -u administrator@vsphere.local –r –v 6.7, para evaluar la compatibilidad de los host conectados a un vCenter.

Una vez ejecute el comando le solicitará aceptar una advertencia de certificados para lo cual deberá escribir yes y a continuación la contraseña de usuario para conectarse al vCenter Server o Host.

4. Como resultado de la ejecución del script con los argumentos –r y -v se generan dos archivos con extensiones .csv y .html respectivamente.

5. Abra el archivo con extensión .html o .csv para visualizar el reporte de compatibilidad y analice la información generada. Para nuestro ejemplo nos muestra que la versión de procesador de los hosts Nutanix 3050 analizados podrían no ser compatibles con la version 6.7 de ESXi y que las versiones de drivers de los componentes de IO no están alineados con la matriz de compatibilidad de VMware, dándonos el link para visualizar directamente la versión correcta de firmware y driver, sin la necesidad de tener que obtener el vendor ID de cada componente y luego realizar la búsqueda manual.

6. Por ultimo, dejo el link de un video en el que se muestra el funcionamiento de la herramienta en solo dos minutos.

Nota: Algunos de los argumentos disponibles se listan a continuación seguidos de su descripción

Uso: compchecker.py [-h] -s HOST [-o PORT] -u USER [-r] [-v TOVERSION]

Argumentos estándar para comunicación con vCenter/ESX

-h	Ayuda	Muestra este mensaje de ayuda
-s	Host	Servicio vSphere a conectar
-o	Puerto	Puerto de conexión
-u	Usuario	Nombre de usuario para la conexión al host/vCenter
-r	Reporte	Genera un reporte de compatibilidad de hardware en .csv y .html
-v	a versión	Version de vSphere con la cual se desea validar la compatibilidad

ATENCIÓN!!!

TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO TEMPORAL, UTILIZADO PARA FINES DE ESTUDIO.

Reiniciar contraseña de vSphere Replication 8.1

en 8 agosto, 201820 septiembre, 2024 por Diego Felipe Tunubalá Medinaen vSphere, vSphere ReplicationDeja un comentario

Alguna vez nos hemos encontrado con el problema de olvidar la contraseña de root o no verificar la ubicación de los caracteres especiales en el teclado cuando la cambiamos, provocando que no podamos ingresar nuevamente a la consola de administración o a la interfaz gráfica. El procedimiento a continuación indica el paso a paso que debe seguirse para restablecer la contraseña de vSphere Replication Appliance 8.1, pero que además puede aplicarse de igual forma a un vCenter Server Appliance basado en Photon OS.

PROCEDIMIENTO

2. Tome un Snapshot de la máquina virtual antes de proceder con el siguiente paso

3. Reinicie de manera controlada el virtual appliance

4. Permanezca atento al momento en que aparece el logo de Photon, para presionar la tecla ‘e’ inmediatamente

6. Ejecute el comando passwd para cambiar la contraseña

7. Ingrese la nueva contraseña y confírmela escribiéndola nuevamente cuando se le solicite

8. Ejecute el comando umount / para desmontar el filesystem

9. Reinicie el virtual appliance ejecutando el comando reboot –f

10. Verifique el acceso desde el VAMI (Virtual Appliance Management Interface), al cual puede ingresar desde un navegador web a través de la URL https://FQDN_IP_vSphereReplication:5480

11. Por último, remueva el Snapshot de la máquina virtual

Aplicación Lanza PuTTY

en 31 julio, 201820 septiembre, 2024 por Diego Felipe Tunubalá Medinaen Tools, vSphereDeja un comentario

Lanza Putty nació hace un par de años por la necesidad de tener que agregar un usuario con permisos específicos en más de doscientos blades distribuidos en aproximadamente veinte enclosures de la marca HP (Hewlett Packard) en la compañía para la cual me desempeñaba como administrador de infraestructura. Una tarea que por supuesto no tenía ningún sentido realizar manualmente en cada uno de los blades desde la interfaz de administración. Por esta razón, decidí desarrollar una herramienta que utiliza PuTTY.exe y Plink.exe para lanzar múltiples conexiones SSH, Telnet, Rlogin o RAW; y envía uno o varios comandos a una lista de instancias remotas desde una única interfaz.

Lanza Putty es una herramienta desarrollada en lenguaje LabVIEW y aunque fue inicialmente pensada para facilitar la administración de chasis y bahías en la infraestructura, puede ser también útil para administrar cualquier sistema basado en Linux, incluso en ocasiones la utilizo para enviar comandos ESXCLI a múltiples hipervisores.

¿Por qué en LabVIEW?

La respuesta es muy simple, necesitaba resolver el problema rápidamente y el lenguaje de desarrollo que mejor manejaba en ese entonces por su ventajas en cuanto al tiempo de desarrollo era LabVIEW. Hoy en día aunque nos apoyamos con herramienta más especializadas como PowerShell y PowerCLI para la implementación y administración de vSphere, me sigue siendo de gran utilidad esta herramienta.

FUNCIONAMIENTO

1. Descargue el Run-Time Engine de LabVIEW (versión 2011) de la página oficial o desde aquí, e instálelo en su ordenador para poder ejecutar el .exe de la aplicación.

2. Descargue la aplicación desde el repositorio compartido haciendo click Aquí.

3. Cree un archivo *.txt con la lista de FQDNs o IPs de las instancias remotas que desea administrar, y guárdelo en la carpeta \Lanza_PuTTY_APP\Data

4. Ejecute la aplicación LanzaPuTTY.exe que se encuentra en el directorio raíz y seleccione el archivo creado anteriormente.

5. Ingrese usuario y contraseña de las instancias remotas

6. Seleccione el protocolo a utilizar. El valor por defecto es el protocolo SSH

7. Ingrese los comandos que desea ejecutar en las instancias remotas. Por ejemplo si utilizamos la herramienta para verificar el driver, firmware o vendor ID de varios hipervisores podemos incluir los siguientes comandos en el campo “Comandos a Ejecutar”

#ESXi Hostname hostname #ESXi Version vmware -v -l #NICs esxcli network nic list #Drivers y firmware NICs esxcli network nic get -n vmnic0 #Vendor ID NICs for a in $(esxcfg-nics -l |awk '{print $1}' |grep [0-9]) ;do vmkchdev -l |grep $a; done

8. Haga click en Archivo->Ejecutar para realizar ejecución con salida en Command Prompt (cmd), se recomienda que la primera vez que se accede a la instancia remota a través de esta herramienta se realice con este modo de
ejecución debido a que la sesión solicita una confirmación de seguridad de PuTTY, que debe ser aceptada escribiendo Y y luego presionando Enter.

9. La opción Archivo->Ejecutar sin CMD, realiza una ejecución con salida en el indicador “Salida de Comandos”, que automáticamente crea un fichero con el nombre Log_Putty.txt con estas salidas de comando. Este modo de ejecución se debe utilizar si ya se ha accedido a las instancias por lo menos una vez con PuTTY.exe, de lo contrario el programa se quedara esperando la confirmación de la alerta de seguridad de PuTTY, sin mostrar ninguna notificación debido a que el programa estará ejecutándose de manera oculta. Esta opción se recomienda para generar Logs después de haber realizado acciones con el modo indicado en el paso anterior.

10. Verifique el contenido del Log_Putty.txt ubicado en la carpeta raíz de la aplicación

Silenciar alarmas de health check en vSAN

en 25 julio, 201820 septiembre, 2024 por Diego Felipe Tunubalá Medinaen VSAN, vSphereDeja un comentario

En esta ocasión se presenta un procedimiento fácil y rápido para silenciar las alarmas generadas por el health check de vSAN, que puede ser utilizado en ambientes Nested (ESXi virtualizados) o en ambientes de laboratorio propiamente dichos. Esta puede ser una opción para omitir algunas de la verificaciones debido a que no siempre contamos con las condiciones de hardware, firmware y drivers apropiados para implementar la solución; ni mucho menos contamos con vSAN ReadyNodes disponibles para una POC (Proof of Concept).

¡CUIDADO! En ningún momento se recomienda este procedimiento en ambientes vSAN productivos ya que todos los componentes de hardware, drivers y firmware deben coincidir con la Guía de Compatibilidad de VSAN indicada para los nodos que conforman la solución.

Antes de iniciar el procedimiento comentemos un poco acerca de RVC (Ruby vSphere Console). Es una consola de línea de comando para VMware vSphere y Virtual Center. Ruby vSphere Console es basada en la popular interface RbVmomi Ruby para vSphere API. RbVmomi fue creada para reducir drásticamente la cantidad de codificación requerida para realizar tareas rutinarias, así como aumentar la eficacia de la ejecución de tareas, al tiempo que permite la máxima potencia de la API cuando es necesario. RVC se encuentra incluida en el vCenter Server Appliance (VCSA) y la versión de Windows de vCenter Server, y se ha convirtiendo en una de las principales herramientas para administrar y solucionar problemas de entornos Virtual SAN (vSAN).

RVC tiene muchas de las capacidades que se esperan de una interfaz de línea de comandos.

Finalización de tabulación
Comodines
Marcas
Modo Ruby
Modo Python
Introspección VMODL
Conexiones múltiples

Extensibilidad

Guiones de Ruby de una sola línea
Casos de uso y ventajas de RVC
Funcionalidad Virtual SAN cubierta
Configuración de VSAN y políticas de almacenamiento
Comandos de monitorización / resolución de problemas
Monitoreo del desempeño a través de VSAN Observer

Ventajas

Más información detallada sobre Virtual SAN vSphere Web Client
Vista de grupo de VSAN mientras que esxcli solo puede ofrecer una perspectiva de servidor
Operaciones masivas a través de comodines
Funciona directamente contra ESX host, incluso si VC no funciona

NOTA: Para mayor información acerca de la utilización de RVC aplicada a vSAN podemos consultar la guía oficial VMware Ruby vSphere Console Command Reference for Virtual SAN.

PROCEDIMIENTO

1. Tenga presente que existe una lista de checks o validaciones que están disponibles para ser configurados y se encuentran consignados en la siguiente tabla. De manera que primero debemos verificar si la alarma que muestra el monitor de salud de vSAN se encuentra en éste listado.

Descripción	Check ID
Cloud Health
Controller utility is installed on host	vendortoolpresence
Controller with pass-through and RAID disks	mixedmode
Customer experience improvement program (CEIP)	vsancloudhealthceipexception
Disks usage on storage controller	diskusage
Online health connectivity	vsancloudhealthconnectionexception
vSAN and VMFS datastores on a Dell H730 controller with the lsi_mr3 driver	mixedmodeh730
vSAN configuration for LSI-3108 based controller	h730
vSAN max component size	smalldiskstest
Cluster
Advanced vSAN configuration in sync	advcfgsync
Deduplication and compression configuration consistency	physdiskdedupconfig
Deduplication and compression usage health	physdiskdedupusage
Disk format version	upgradelowerhosts
ESXi vSAN Health service installation	healtheaminstall
Resync operations throttling	resynclimit
Software version compatibility	upgradesoftware
Time is synchronized across hosts and VC	timedrift
vSAN CLOMD liveness	clomdliveness
vSAN Disk Balance	diskbalance
vSAN Health Service up-to-date	healthversion
vSAN cluster configuration consistency	consistentconfig
vSphere cluster members match vSAN cluster members	clustermembership
Data
vSAN VM health	vmhealth
vSAN object health	objecthealth
Encryption
CPU AES-NI is enabled on hosts	hostcpuaesni
vCenter and all hosts are connected to Key Management Servers	kmsconnection
Hardware compatibility
Controller disk group mode is VMware certified	controllerdiskmode
Controller driver is VMware certified	controllerdriver
Controller firmware is VMware certified	controllerfirmware
Controller is VMware certified for ESXi release	controllerreleasesupport
Host issues retrieving hardware info	hclhostbadstate
SCSI controller is VMware certified	controlleronhcl
vSAN HCL DB Auto Update	autohclupdate
vSAN HCL DB up-to-date	hcldbuptodate
Limits
After 1 additional host failure	limit1hf
Current cluster situation	limit0hf
Host component limit	nodecomponentlimit
Network
Active multicast connectivity check	multicastdeepdive
All hosts have a vSAN vmknic configured	vsanvmknic
All hosts have matching multicast settings	multicastsettings
All hosts have matching subnets	matchingsubnet
Hosts disconnected from VC	hostdisconnected
Hosts with connectivity issues	hostconnectivity
Multicast assessment based on other checks	multicastsuspected
Network latency check	hostlatencycheck
vMotion: Basic (unicast) connectivity check	vmotionpingsmall
vMotion: MTU check (ping with large packet size)	vmotionpinglarge
vSAN cluster partition	clusterpartition
vSAN: Basic (unicast) connectivity check	smallping
vSAN: MTU check (ping with large packet size)	largeping
Performance service
All hosts contributing stats	hostsmissing
Performance data collection	collection
Performance service status	perfsvcstatus
Stats DB object	statsdb
Stats DB object conflicts	renameddirs
Stats master election	masterexist
Verbose mode	verbosemode
Physical disk
Component limit health	physdiskcomplimithealth
Component metadata health	componentmetadata
Congestion	physdiskcongestion
Disk capacity	physdiskcapacity
Memory pools (heaps)	lsomheap
Memory pools (slabs)	lsomslab
Metadata health	physdiskmetadata
Overall disks health	physdiskoverall
Physical disk health retrieval issues	physdiskhostissues
Software state health	physdisksoftware
Stretched cluster
Invalid preferred fault domain on witness host	witnesspreferredfaultdomaininvalid
Invalid unicast agent	hostwithinvalidunicastagent
No disk claimed on witness host	witnesswithnodiskmapping
Preferred fault domain unset	witnesspreferredfaultdomainnotexist
Site latency health	siteconnectivity
Unexpected number of fault domains	clusterwithouttwodatafaultdomains
Unicast agent configuration inconsistent	clusterwithmultipleunicastagents
Unicast agent not configured	hostunicastagentunset
Unsupported host version	hostwithnostretchedclustersupport
Witness host fault domain misconfigured	witnessfaultdomaininvalid
Witness host not found	clusterwithoutonewitnesshost
Witness host within vCenter cluster	witnessinsidevccluster
vSAN Build Recommendation
vSAN Build Recommendation Engine Health	vumconfig
vSAN build recommendation	vumrecommendation
vSAN iSCSI target service
Home object	iscsihomeobjectstatustest
Network configuration	iscsiservicenetworktest
Service runtime status	iscsiservicerunningtest

2. Inicie sesión SSH en el vCenter Server Appliance y conéctese al Ruby vSphere Console (RVC) ejecutando el siguiente comando (sin habilitar el Shell)

rvc username@localhost

Ejemplo:

Command> rvc administrator@vsphere.local@localhost

3. Ingrese el password del usuario administrator@vsphere.local

Se utilizarán los siguientes comandos RVC para verificar y silenciar las alarmas

vsan.health.silent_health_check_status
vsan.health.silent_health_check_configure

4. Verifique el estado de las alertas con el primer comando, para el cual se debe conocer la ruta de cluster a analizar. Puede apoyarse de los comando cd y ls para navegar hasta encontrar la ruta correcta del cluster vSAN.

Ejemplo:

vsan.health.silent_health_check_status /localhost/Datacenter-Lab01/computers/vSAN-Cluster

5. Desde el vSphere Web Client navegue hasta el NombredelCluster|vSAN|Health para identificar el nombre de la alerta que se desea silenciar, teniendo en cuenta por supuesto que la misma no sea de impacto para la operación normal de la solución, de lo contrario deberá realizarse una adecuada investigación y solución del problema.

Para este caso al ser un ambiente de laboratorio virtualizado, se tiene la alerta SCSI controller is VMware certified que nos indica acerca de la incompatibilidad de la controladora de discos para el uso de vSAN, que no podemos solucionar debido a que la controladora es virtual; por lo tanto puede ser ignorada o silenciada. (¡Recuerde! Esto acción no debe ser realizada en ambientes productivos).

6. En la salida del comando anterior se muestra el mismo listado de Health Checks disponibles para configurar y su estado actual. De manera que para silenciar la verificación SCSI controller is VMware certified, se debe utilizar su correspondiente identificador o Check ID controlleronhcl

7. Ahora solo queda ejecutar el comando de configuración vsan.health.silent_health_check_configure de la siguiente manera para silenciar la alarma

vsan.health.silent_health_check_configure /localhost/Datacenter-Lab01/computers/vSAN-Cluster –a ‘controlleronhcl’

Utilice los parámetros de configuración disponibles, de acuerdo a su necesidad.

-a	–add-checks=	Agregar verificación a la lista silenciosa, uso: -a [Health Check Id].
-r	–remove-cheques=	Eliminar verificación de la lista silenciosa, uso: -r [Health Check Id]. Para restaurar la lista de verificación silenciosa, utilizando ‘-r all’
-i	–interactive-add	Usa el modo interactivo para agregar verificación a la lista silenciosa
-n	–interactive-remove	Usa el modo interactivo para eliminar las verificaciones de la lista silenciosa
-h	–help	Muestra este mensaje

8. Regrese al vSphere Web Client y haga click en Retest en el Health monitor de vSAN para validar el cambio y podrá observar que la alerta aparece ahora como Skipped y no como Warning.

Distribución de particiones en ESXi 6.5

en 28 junio, 201820 septiembre, 2024 por Diego Felipe Tunubalá Medinaen ESXi, vSphereDeja un comentario

Este artículo pretende identificar de manera sencilla las particiones que hacen parte de la instalación del Hipervisor ESXi, y la función que cada una cumple dentro del mismo.

Independientemente del método de instalación que haya elegido para su host (Instalación interactiva, desatendida o utilizando Auto Deploy), una vez que se haya instalado ESXi en el dispositivo de destino, se creará una distribución de partición específica en el disco. No es posible modificar el diseño de las particiones durante el proceso de instalación y todas las particiones se crean automáticamente.

Para identificar el diseño de particiones creado por el instalador en vSphere 6.5, debe usar el comando partedUtil, ya que el comando fdisk era compatible con versiones anteriores.

Con la introducción de la partición GUID Partition Table (GPT) de ESXi 5.x, el comando fdisk ha quedado obsoleto y ya no funciona.

Para visualizar la tabla de particiones, debe acceder a la consola ESXi y ejecutar los siguientes comandos:

1. Abra una sesión SSH hacia el servidor ESXi y ejecute el comando ls /dev/disks -lh para identificar el nombre del disco del sistema (por lo general, es el único disco con más particiones)

2. Una vez que haya identificado el disco del sistema (identificador mostrador en color azul que comienza por ‘vml.’ hasta el ‘:‘), puede usar comando partedUtil con la opción getptbl para ver el tamaño de la partición. Si observa en el screenshot en la salida del comando anterior, el tamaño de la partición ya era visible

Al observar la captura de pantalla anterior, el diseño de la partición de host de ESXi 6.5 creado por el instalador de ESXi puede estar compuesto hasta por ocho particiones. Las particiones 2 y 3 pueden no ser visibles si el host está instalado en tarjetas SD o unidades flash USB. Cada una de las particiones cumple las siguientes funciones

· 1 (systemPartition 4 MB): Partición necesaria para el arranque.

· 5 (linuxNative 250 MB – / bootbank): Hipervisor central VMkernel.

· 6 (linuxNative 250 MB – / altbootbank): Inicialmente vacío.

· 7 (vmkDiagnostic 110 MB): Partición utilizada para escribir el archivo de volcado de host en caso de un crash del ESXi.

· 8 (linuxNative 286 MB – / store): Esta partición contiene los archivos ISO de VMware Tools para OS soportados.

· 9 (vmkDiagnostic 2.5 GB): Segunda partición de diagnóstico.

· 2 (linuxNative 4.5 GB – / scratch): Partición creada para almacenar la salida de vm-support necesaria para el soporte de VMware. Esta partición no es creada en tarjetas SD o unidades flash USB, cuando la instalación ESXi se realiza sobre estos dispositivos.

· 3 (VMFS Datastores XX GB): Espacio disponible y no asignado del disco es formateado como VMFS5 o VMFS, según la versión ESXi. No es creado en tarjetas SD o Unidades flash USB, cuando la instalación ESXi se realiza sobre estos dispositivos:

A continuación, una representación gráfica de cada una de las particiones en el hipervisor ESXi