Verificar integridad de medios de instalación VMware (checksum)

en 23 abril, 202116 julio, 2022 por Diego Tunubaláen vSphereDeja un comentario

Como ya sabemos, una suma de verificación o checksum, es el resultado de ejecutar una función hash criptográfica dentro de un archivo, que tiene como propósito principal detectar cambios en una secuencia de datos para proteger su integridad. La particularidad de esto es que un pequeño cambio en el archivo provoca una salida totalmente distinta.

Dicho esto, checksum nos permite verificar la integridad del medio de instalación y estar seguros que el contenido del mismo no ha sido alterado y es tal y como lo indica su fabricante.

Lo importante a tener en cuenta en este post es que el objetivo no es garantizar una procedencia confiable del medio de instalación, sino verificar la integridad del archivo descargado.

Dejando un lado la teoría vamos a lo que nos interesa…

PROCEDIMIENTO

Utilizando la línea de comando de Windows (CMD) y la herramienta CertUtil incluida en las versiones mas recientes del sistema operativo. Ejecute el siguiente comando.

CertUtil -hashfile "Ubicacion_y_nombre_del_archivo" MD5

Nota 1: Para no tener que escribir el nombre del archivo, podemos simplemente seleccionarlo y arrastrarlo dentro de la consola de CMD de Windows y de esta manera incluirá la ubicación completa del mismo.

El resultado del comando nos devuelve un número de verificación similar al siguiente. Selecciónelo y cópielo para el siguiente paso (el de su Command Prompt).

e05748cea32d60566f0738a5b811cfdc

Para verificar que el archivo no ha sufrido ninguna modificación durante la descarga o posterior a ella, vaya a la página de descargas de VMware, donde descargó el medio de instalación, utilice la función Buscar… (ctrl+f o command+f) y dentro del campo de búsqueda pegue el numero que devolvió la salida del comando anterior.

De esta manera podemos buscar rápidamente si el numero que nos devolvió la herramienta CertUtil corresponde con el numero de verificación (MD5SUM) publicado por el fabricante.

Nota 2: Sino puede ver los detalles del medio de instalación en pagina de descargas. Haga clic en el enlace Read more para visualizar la información publicada por VMware.

Si el numero es encontrado como en la imagen anterior, el medio de instalación es apto para ser usado. Sino es así, vuelva a descargar el medio de instalación porque seguramente esta corrupto.

Nota 3: Puede utilizar la herramienta CertUtil para la suma de verificación de otros algoritmos hash cambiando el parámetro MD5 en el comando por cualquiera de los siguientes. VMware en su página de descargas publica la información para MD5SUM, SHA1SUM y SHA256SUM.

MD2
MD4
MD5
SHA1
SHA256
SHA384
SHA512

Por ultimo y como recomendación, realice este procedimiento para evitar algunos dolores de cabeza y perder tiempo tratando de solucionar problemas que probablemente vienen del medio de instalación y no del proceso de instalación o actualización.

Limpiando particiones en discos para configuración de vSAN

en 8 julio, 202016 julio, 2022 por Diego Tunubaláen VSAN, vSphereDeja un comentario

En esta oportunidad explicaremos como abordar una situación en la cual al intentar crear el cluster vSAN de forma manual a través del asistente de configuración, no tenemos disponibles algunos discos que deberían aparecer para la creación de los Disk Groups. En ese momento nos preguntaremos ¿Por qué no aparecen todos los discos disponibles?, pues bien lo más probable es que el o los discos que no aparecen listados para ser Claimed por vSAN no están vacíos y deban ser formateados para poderlos liberar.

Es aquí donde nos podríamos encontrar con un error común que puede convertirse en un dolor de cabeza sino conocemos su causa raíz. El error básicamente se produce al intentar ejecutar la acción Erase Partitions en la configuración del host en el apartado Configure->Storage->Storage Devices, como se muestra en la siguiente imagen.

Al hacer clic sobre la opción anterior nos mostrará un resumen de las particiones con las que cuenta este disco y razón por la cual no esta disponible para el asistente de configuración de VSAN.

Al hacer click sobre el botón OK, en la mayoría de los casos, las particiones serán eliminadas y el disco quedará disponible para vSAN. Una forma rápida de verificarlo es que al hacer nuevamente clic sobre Erase Partition, no debería listar ninguna partición y el asistente de configuración de vSAN debería ahora listar el o los discos.

¿Y SI FALLA?…

Es ahora cuando aparece el problema ¿Que hacemos si esta tarea falla y nos muestra el siguiente error: “Cannot change the host configuration”? Primero que todo ¡calma, calma!, no tenemos que ir a ninguna línea de comandos a intentar limpiar estas particiones, la solución es mucho más sencilla que eso.

Nota 1: Para las versiones de ESXi anteriores a 7,0, scratch partition es un espacio temporal que se configura automáticamente durante la instalación o el primer arranque de un host ESXi. El instalador de ESXi crea una partición FAT16 de 4GB en el dispositivo de destino durante la instalación si hay suficiente espacio y si el dispositivo se considera local. Esta partición no es creada cuando el hipervisor se instala en tarjetas SD o unidades flash USB.

Nota 2: Si no existe espacio temporal persistente disponible en el disco local o la partición no es creada (en el caso de SD, Flash USB), ESXi almacenará estos datos temporales en la memoria RAM. Esto puede ser problemático en situaciones con poca memoria, pero no es fundamental para el funcionamiento de ESXi.

Explicado lo anterior, el problema pudo haberse producido si ese disco o discos, en algún momento fueron formateados como Datastore (VMFS), y esto hace que el hipervisor configure ese datastore como su mejor candidato para ubicar el Scratch Partition (Partición creada para almacenar la salida de vm-support necesaria para el soporte de VMware).

Por esta razón, la solución a este problema se basa en cambiar la configuración asociada a la opción avanzada del hipervisor ScratchConfig.ConfiguredScratchLocation, que probablemente estará apuntando al datastore local que en algún momento se configuró en dicho disco.

SOLUCIÓN

1. Si ya tiene vCenter instalado navegue en el inventario hasta el Host –> Configure –> Advanced System Settings. Clic en Edit… y en el filtro escriba ScratchConfig.ConfiguredScratchLocation.

2. Sino tiene instalado un vCenter aún, inicie sesión en el Host Client del host en cuestión (en cualquier navegador web https://IP_FQDN_Host ) y navegue hasta Manage->System-> Advanced Settings y en el buscador escriba ScratchConfig.ConfiguredScratchLocation o simplemente Scratch.

3. Independientemente de si se realizó el paso anterior desde el vCenter o desde el Host Client, podrá ver que en el campo value aparecerá la ruta hacia un datastore, lo único que debemos hacer es editar este valor y colocar /tmp, para redireccionarlo a la memoria RAM (no recomendado) o especificar la ruta de un almacenamiento persistente diferente.

Nota 3: Al editar el valor de ScratchConfig.ConfiguredScratchLocation será /tmp, mientras el valor de ScratchConfig.CurrentScratchLocation permanecerá sin cambios. Esto se debe a que es necesario realizar un reinicio del host para que los mismo sean aplicados.

4. Una vez realizado el reinicio, inicie sesión nuevamente en el Host Client y navegue hasta Manage->System-> Advanced Settings. En el buscador escriba ScratchConfig.ConfiguredScratchLocation o simplemente Scratch.

En la columna value podrá observar que el valor tanto para ScratchConfig.ConfiguredScratchLocation como para ScratchConfig.CurrentScratchLocation es /tmp.

5. Por ultimo, intente nuevamente la acción Erase Partition.

Desde el vCenter

o desde el Host Client (Clear partition table)

Y notará que la tarea finaliza con éxito.

En este momento ya habrá liberado el o los discos y ahora estarán disponibles para ser reclamados por VSAN desde el asistente de configuración.

ATENCIÓN!!!

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

Solucionando error en EMC Unisphere session: The System can not be managed for the following reasons. Certificate has invalid date.

en 11 junio, 202016 julio, 2022 por Diego Tunubaláen EMC Unisphere, SAN, vSphere8 comentarios

Como su nombre lo indica este post se enfoca en la solución de un problema de vencimiento de certificados para la consola de administración (EMC Unisphere) de nuestro VNX5200 . Sin embargo no hay de que preocuparse, ¡El mensaje de error asusta más que el problema en sí!.

Al intentar ingresar a la consola de administración del EMC Unisphere aparece el siguiente error: «The System can not be managed for the following reasons. Certificate has invalid date» y simplemente no permite continuar con el inicio de sesión.

El problema básicamente radica en que el certificado ha expirado y no permite el inicio de sesión de ninguna manera.

SOLUCIÓN

La solución se centra en forzar la generación de un nuevo certificado a través de una interfaz de línea de comandos.

1. Descargue la herramienta EMC Navisphere CLI desde aquí. Iniciando sesión con una cuenta de usuario registrada para poder realizar la descarga.

2. Instale EMC Navisphere CLI en su ordenador siguiendo cada uno de los pasos del asistente.

Nota 1: Tenga presente la ruta de instalación de la herramienta (la usaremos más adelante). La ruta por default es C:\Program Files (x86)\EMC\Navisphere CLI.

Nota 2: En el Paso 3. Deje la validación del certificado en Low para que no verifique el certificado. (Solo para este caso, porque esta vencido).

3. Una vez finalizada la instalación. Abra una línea de comandos en Command Prompt (CMD) y navegue hasta la ubicación de instalación de la herramienta Navisphere CLI utilizando el siguiente comando:

cd C:\Program Files (x86)\EMC\Navisphere CLI

4. Ejecute ahora la herramienta NaviSECCLI.exe utilizando la siguiente línea de comandos:

NaviSECCli.exe -address [IP_Unisphere] -User [usuario] -Password [Contraseña] -Scope 0 security -SPcertificate -generate

Nota 3: Verifique que el resultado de la operación sea SPCertificate is generated: Sucess.

Nota 4: Si el equipo cuenta con mas de una controladora, ejecute el comando para cada una de las IPs asociadas a las mismas.

5. Abra una ventana en su navegador web e intente realizar la conexión hacia la consola de administración EMC Unisphere nuevamente.

6. Revise los detalles del nuevo certificado y notará que es valido por cinco años, a partir de la fecha.

7. Haga clic en Accept Always, para aceptar el certificado.

8. Por último, inicie sesión en su consola y verifique que el problema ha sido resuelto.

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

en 4 marzo, 20206 septiembre, 2022 por Diego Tunubaláen 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:

Configurando Direct Attached Storage (DAS) en Cisco UCS (Unified Computing System)

en 21 agosto, 201916 julio, 2022 por Diego Tunubaláen Cisco UCS, vSphereDeja un comentario

Algunos de nosotros en el rol de consultor, hemos tenido que realizar implementaciones con diferentes tipos de hardware, HP, DELL, Huawei, Intel; pero no es sino hasta que nos encontramos con una infraestructura basada en Cisco Unified Computing System (UCS), con su UCS Manager, FI (Fabric Interconnect), Switches, chasis, blades, IO Modules, que nuestra primera impresión es decir, “Esto es otro mundo!”.

Pues bien, este es uno de los casos en donde la primera impresión no cuenta demasiado, y mas que complejo este tipo de infraestructuras resulta ser muy robusta y a la vez versátil. Alguno de sus beneficios se resumen en la siguiente lista. (Para ver mas información).

Aumento de la productividad del personal de TI y la agilidad empresarial a través del aprovisionamiento justo a tiempo y la igualdad de soporte para ambientes virtualizados y bare-metal.
TCO (Total Cost of Ownership) reducido a nivel de plataforma, sitio y organización a través de la
consolidación de infraestructura.
Un sistema unificado e integrado que se gestiona, repara y prueba como un
todo.
Un ecosistema de gestión integral que admite completo
aprovisionamiento y administración de infraestructura que puede hacer a sus instancias de Cisco UCS cualquier cosa, desde un motor de aplicaciones empresariales sin formato hasta un entorno multicloud contenedorizado.
Escalabilidad mediante la capacidad de administrar hasta 10,000 servidores con Cisco
UCS Central Software y escalar el ancho de banda de I/O para satisfacer la demanda.
Estándares abiertos de la industria respaldados por un ecosistema partner de industrias lideres.
Un sistema que se adapta para satisfacer las futuras necesidades del Centro de Datos como, potencia de computo, memoria y ancho de banda de E/S, etc.

Dicho lo anterior, veamos como configurar de manera sencilla una arquitectura DAS para poder presentar nuestro almacenamiento a los servidores UCS, sin tener que conectarlos a Switches de SAN y realizar las configuración a nivel de Zoning que esto conlleva.

En versiones de UCS anteriores a 2.1, se tenía la opción de usar DAS con UCS. Sin embargo, se necesitaba un Switch SAN conectado a los FI (Fabric Interconnect) para que el Switch pudiera enviar la base de datos de zonas a los FI. Es decir, la plataforma UCS no podía construir una base de datos de zonas por si misma. Por suerte, desde la version 2.1 en adelante UCS ahora tiene la capacidad de construir su propia base de datos de zonas de manera automática. Por lo tanto podemos tener DAS (Direct Attached Storage) con UCS sin la necesidad de un Switch SAN para crear la configuración de zonificación. Esta topología luce de la siguiente forma:

PROCEDIMIENTO DE CONFIGURACIÓN

1. Aunque suene obvio el primer paso es realizar las conexiones entre el almacenamiento y las interfaces de los FI.

2. Configurar FI en FC Switch Mode

Inicie sesión en el USC Manager y navegue hasta Equipment.
Expanda Fabric Interconnects.
Click en Fabric Interconnect A.
En la pestaña General click en Set FC Switching Mode

Repita los pasos 2(2-4) para el Fabric B.

3. Crear VSAN Requerido

Nota 1: VSAN (Virtual Storage Area Network) es una red de área de almacenamiento virtual. Las VSAN proporcionan aislamiento entre dispositivos que están físicamente conectados a la misma estructura. Con VSAN se pueden crear múltiples SAN lógicas sobre una infraestructura física común y se pueden diseñar múltiples VSAN con diferentes topologías.

Nota 2: Storage VSANs deberían ser creados solo bajo Storage Cloud y no debería ser permitido en los enlaces ascendentes FC, si es que los hay.

En el UCSM, navegue hasta la pestaña SAN.
Expanda Storage Cloud.
Expanda Fabric A.
Click derecho en VSANs, y seleccione Create Storage VSAN.
Ingrese el nombre de la VSAN.
Seleccione Enabled para FC Zoning.
Seleccione Fabric A.
Ingrese el VSAN ID y un VLAN ID para Fiber Channel over Ethernet (FCoE) para el Fabric A. Asegúrese que el FCoE VLAN ID es un VLAN ID que no esté actualmente usado en la red.

Repita los pasos 3(2-8) para el Fabric B.

4. Configure el rol del puerto en UCS

En este punto vamos a seleccionar los puertos de los FI conectados al almacenamiento para configurarlos como FC Storage Ports.

En el UCSM, navegue hasta la pestaña Equipment.
Expanda Fabric Interconnects.
Expanda Fabric Interconnect A.
Click derecho sobre el puerto conectado al almacenamiento, y seleccione Configure as FC Storage Port.
Seleccione la VSAN correcta para este puerto desde la lista desplegable.
Repita los pasos 4(1-5) para el Fabric B.

Si el puerto está configurado correctamente y está en arriba en el almacenamiento, el puerto de almacenamiento FC en UCS debería estar en línea.

5. Confirme que la WWPN del Storage Port haya iniciado sesión en el Fabric

Inicie sesión a través del shell seguro (SSH) o establezca una conexión Telnet a la IP virtual (VIP) del UCS.
Ingrese el comando
```
connect nxos {a | b}
```
, donde a | b representa FI A o FI B.
Ingrese el comando
```
show flogi database vsan vsan_ID
```
, donde vsan ID es el identificador del VSAN. En este ejemplo el identificador es 600.

La siguiente imagen muestra la salida de estos dos comandos, tanto para el Fabric A como para el B y en ellas se observa que la WWPN del puerto de almacenamiento ahora está conectada a la VSAN 600. Asegúrese de confirmar el inicio de sesión de los puerto de almacenamiento en ambos Fabrics.

6. Cree Storage Connection Policy.

En el UCSM, navegue hasta la pestaña SAN.
Expanda Policies, expanda Root, click derecho en Storage Connection Policies, y seleccione Create Storage Connection Policy.

La ventana Create Storage Connection Policy se abre para permitirle definir las WWPN Target del almacenamiento y los detalles del Fabric.

Ingrese el Nombre del Storage Connection Policy.
Seleccione un tipo de Zoning desde las tres opciones:

None: Use esta opción cuando no tenga zonas creadas en el FI, pero tenga zonas usadas para trafico ascendente del FC switch para una VSAN particular.
Single Initiator Single Target: Use esta opción cuando solo tenga un puerto de almacenamiento conectado a un Fabric.
Single Initiator Multiple Targets: Use esta opción cuando tenga más de un puerto de almacenamiento conectado a una Fabric. (Para el ejemplo tenemos dos conexiones hacia el almacenamiento desde cada Fabric).

Click en el signo mas (+)Add, para abrir la ventana que permite crear el FC Target Endpoint.
Ingrese la WWPN del FC target (almacenamiento).
Click en Path para el Fabric A.
Seleccione el VSAN ID correspondiente desde la lista desplegable.
Haga click en OK para guardar los cambio y repita los pasos e-h para agregar más WWPNs del almacenamiento (en el caso de haber seleccionado Single Initiator Multiple Targets).

Repita los pasos 6(5-9) pero esta vez seleccionando el Path en el Fabric B y agregando las WWNP Target del almacenamiento conectadas al Fabric B.

7. Edite el Service Profile.

Si ya tenemos hosts con Service Profiles asignados, solo necesitamos editarlos de la siguiente forma:

En el UCSM navegue hasta la pestaña Servers.
Expanda Servers, expanda Service Profiles, expanda root y seleccione el Service Profile asociado al host al cual desea conectar el almacenamiento.

Nota 3: Si todos los Service Profile de los hosts pertenecen a un mismo Service Profile Template, puede optar por modificar el Template y aplicar los cambios a todos los Service Perfiles desplegados desde esa plantilla.

Haga click en la pestaña Storage del panel central y luego click en vHBA Initiator Groups.
Click en (+) Add, Elija un nombre para el grupo de iniciadores y una descripción.
En Select vHBA Initiators, seleccione la vHBA conectada al Fabric A.
En Storage Connection Policy, seleccione la política creada en el paso anterior para el Fabric A y click en OK.

Repita los pasos 7(4-6) seleccionando esta vez la vHBA conectada al Fabric B y la Storage Connection Policy creada para ese Fabric.

Como resultado obtendrá una vista como la siguiente.

Expanda ahora el Service Profile, expanda vHBAs y seleccione una de las vHBAs del Service Profile (ejemplo vHBA vHBA0).
Haga click en la pestaña General del panel central y luego en la propiedad VSAN seleccione desde la lista desplegable la VSAN correspondiente al Fabric al cual se encuentra conectada (para el ejemplo Test_VSAN_Fabric_A, creada anteriormente).

Repita los paso 7(9-10) para la demás vHBAs configuradas en el Service Profile teniendo en cuenta seleccionar en la propiedad VSAN, la correspondiente de acuerdo a la conexión física hacia el Fabric.

8. Verifique la creación de las Zonas

En este punto las zonas deben haber sido creadas de manera automática por los FI y para verificarlas solo siga los siguientes pasos:

En el UCSM navegue hasta la pestaña Servers.
Expanda Servers, expanda Service Profiles, expanda root y seleccione el Service Profile asociado al host al cual presentó el almacenamiento.
Click en la pestaña FC Zone, y verifique la creación de las Zonas de manera automática.

Adicionalmente, puede también verificar las Zonas desde CLI de la siguiente forma:

Inicie sesión a través del shell seguro (SSH) a la IP virtual (VIP) del UCS.
Ingrese el comando
```
connect nxos {a | b}
```
, donde a | b representa FI A o FI B.
Ingrese el comando

show zoneset active vsan vsan_ID>

, donde vsan ID es el identificador para el VSAN. (En este ejemplo, el identificador VSAN es 600).

La siguiente imagen es un ejemplo de la salida de estos dos comandos.

Por último, solo debemos realizar rescan a las HBAs del host para visualizar las LUNs presentadas desde el almacenamiento. En este caso dado que es un host ESXi lo haremos de la siguiente forma:

Inicie sesión al vCenter con un usuario administrador.
Navegue hasta el host ESXi y haga click en Configure y luego en Rescan Storage…
Haga click en cada una de las vmhbas y podrá observar que ahora en la pestaña Devices se muestran las LUNs presentadas. Para el ejemplo, solo una LUN de 512GB.

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

en 31 enero, 201916 julio, 2022 por Diego Tunubaláen PowerCLI, 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.

Automatizando configuración de Syslog en ESXi 6.5/6.7

en 29 enero, 201916 julio, 2022 por Diego Tunubaláen vSphereDeja un comentario

Una buena practica al momento de realizar una implementación de vSphere consiste en almacenar los registros o logs en un servidor remoto, de manera que nos permita la gestión centralizada de los mismos y tener una mayor retención de los archivos para efectos de troubleshooting. Pues bien, VMware ESXi desde la versión 5.0 en adelante ejecuta un servicio llamado syslog (vmsyslogd) que proporciona un mecanismo para registrar los mensajes de vmkernel y demás componentes del sistema. Pero antes de indicar el procedimiento de configuración veamos un poco como funciona.

Por defecto los archivos son almacenados en un volumen local, scratch partition, que es una partición usada para almacenar temporalmente data, incluyendo logs, información de diagnostico (vm-support) y system swap. Debemos tener en cuenta que scratch partition se crea durante la instalación de ESXi. Sin embargo, si el dispositivo de destino de la instalación del hipervisor es una USB Stick o un SD Card esta partición no se creará y /scratch quedará localizada en ramdisk enlazada a /tmp/scratch generando un alerta desde la interfaz gráfica indicando que debe configurar almacenamiento persistente para logs del sistema. Omitir la alerta afectará el rendimiento y optimización de la memoria.

Dicho lo anterior existen cinco opciones para configurar Syslog en ESXi:

Syslog.global.logDir: Es la ubicación en un almacén de datos local o remoto (VMFS, NFS, FAT) y la ruta donde se deben guardar los registros. Tiene el formato [NombreDatastore] NombreDirectorio que mapea a /vmfs/volumes/NombreDatastore/NombreDirectorio/. Si el NombreDirectorio especificado no existe, será creado. Si /scratch está definido, el valor predeterminado es []/scratch/log. Para obtener más información sobre el scratch, consulte Creación de una ubicación de scratch persistente para ESXi (1033696).
Syslog.global.logHost: Es una lista delimitada por comas de servidores remotos donde los registros se envían a través de la red utilizando el protocolo Syslog. Si el campo logHost está en blanco, los logs no se reenvían. Incluya el protocolo y el puerto, similar a tcp://hostname:514, udp://hostname:514 o ssl://hostname:514.
Syslog.global.logDirUnique: Es una opción booleana que controla si un directorio del host específico se crea dentro del logDir configurado. El nombre del directorio es el hostname del host ESXi. Un directorio único es útil si varios hosts ESXi usan el mismo directorio compartido. El valor predeterminado es false.
Syslog.global.defaultRotate: Es el número máximo de archivos de registro para mantener localmente en el host ESXi en el logDir configurado. No afecta la retención del servidor de syslog remoto. El valor predeterminado es 8.
Syslog.global.defaultSize: Es el tamaño máximo en kilobytes de cada archivo de registro local antes de ser rotado. No afecta la retención del servidor de syslog remoto. El valor predeterminado es 1024 KB.

Nota 1: En caso de no tener un Syslog Server en la infraestructura, podemos utilizar el servicio de Syslog Collector incluido en el vCenter Server (únicamente basado en Windows). Sin embargo, el máximo numero de hosts recomendado para recopilar es de 30. Para mayor información de los servicios incluidos en vCenter Server consulte Componentes y Servicios de vCenter Server.

Nota 2: Sino tenemos un Syslog Server y nuestro vCenter Server no es basado en Windows podemos redirigir los Logs a una carpeta especifica dentro de un datastore mediante las opciones de configuración Syslog.global.logDir y Syslog.global.logDirUnique anteriormente mencionadas.

CONFIGURAR SYSLOG EN ESXi

¡Es momento de la parte practica! En esta ocasión se mostrará la configuración de syslog en los host ESXi utilizando como es costumbre las interfaces de línea de comandos ESXCLI y PowerCLI.

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 el servicio de syslog

2. Verifique si existe alguna de las cinco configuraciones aplicadas en el host ejecutando los siguientes comandos:

esxcli system syslog config get

3. Establezca una nueva configuración de host, especificando las opciones que desee cambiar, ejecutando el comando:

esxcli system syslog config set --logdir=/path/to/vmfs/directory/ --loghost=RemoteHostname --logdir-unique=true|false --default-rotate=NNN --default-size=NNN

Ejemplo 1:

Para configurar un servidor syslog remoto utilizando TCP en el puerto 514 basta con ejecutar la siguiente línea:

esxcli system syslog config set --loghost='tcp://xx.xx.xx.xx:514

Ejemplo 2:

Para configurar un datastore como repositorio de Logs de manera persistente basta con ejecutar la siguiente línea:

esxcli system syslog config set --logdir='/vmfs/volumes/Nombre_Datastore/Nombre_Directorio' --logdir-unique=true

Nota 3: Si el directorio especificado no existe, se creará automáticamente.

4. Cargue la nueva configuración ejecutando la siguiente línea:

esxcli system syslog reload

5. Si configuró un servidor remoto (Ejemplo 1), abra los puertos del firewall del ESXi para el servicio syslog ejecutando los siguientes comandos:

esxcli network firewall ruleset set --ruleset-id=syslog --enabled=true
esxcli network firewall refresh

6. (Opcional) Verifique que el puerto es alcanzable desde el host ESXi hacia el servidor remoto ejecutando la siguiente línea:

nc -z IP_FQDN_Remote 514

PowerCLI

Si lo anterior les pareció fácil, con el siguiente script activaremos el servicio syslog en todos los host de nuestra infraestructura

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 los siguientes scripts para configurar syslog en todos los hosts del vCenter de acuerdo a su necesidad

Ejemplo 3:

Para configurar un servidor syslog remoto utilizando TCP en el puerto 514:

Foreach ($hostx in (get-VMHost)){

    #Display ESXi running
    Write-Host "Configuring Syslog in $hostx" -ForegroundColor Yellow
    #Set syslog server
    $hostx | Get-AdvancedSetting -Name Syslog.global.logHost | Set-AdvancedSetting -Value $MySyslog -Confirm:$false
    #Restart syslog service
    $esxcli = Get-EsxCli -vmhost $hostx
    $esxcli.system.syslog.reload()
    #Open Firewall ports from ESXi
    Get-VMHostFireWallException -VMHost $hostx -Name Syslog | Set-VMHostFirewallException -Enabled:$True
}

Ejemplo 4:

Para configurar un Datastore de la infraestructura como repositorio de Logs:

#Set my Datastore path
$MySyslog= “[Nombre_Datastore]/ESXi_Logs”

Foreach ($hostx in (Get-VMHost)){

    #Display ESXi running
    Write-Host "Configuring Syslog in $hostx" -ForegroundColor Yellow
    #Set path
    $hostx | Get-AdvancedSetting -Name Syslog.global.logDir | Set-AdvancedSetting -Value $MySyslog -Confirm:$false
    #Creates a subdirectory with the name of the ESXi host under the directory specified by Syslog.global.LogDir
    $hostx | Get-AdvancedSetting -Name Syslog.global.logDirUnique | Set-AdvancedSetting -Value "true" -Confirm:$false
    #Restart syslog service
    $esxcli = Get-EsxCli -vmhost $hostx
    $esxcli.system.syslog.reload()
}

4. Verifique la aplicación de la configuración ejecutando el siguiente script

Foreach ($hostx in (Get-VMHost)){

    Write-Host "Checking Syslog in host $hostx" -ForegroundColor Yellow
    $esxcli = Get-EsxCli -vmhost $hostx.name
    $esxcli.system.syslog.config.get()
}

VERIFICACIÓN DE LA TRANSFERENCIA DE LOGS

Una vez configurados los hosts, podremos ver que los Logs serán enviados al servidor remoto o ruta en el Datastore especificado, creando una carpeta con el nombre hostname del host ESXi siempre y cuando la configuración avanzada Syslog.global.logDirUnique haya sido especificada como True.

A continuación, una muestra de cómo se visualizan los Logs que han sido transferidos de manera inmediata a la carpeta indicada dentro de un datastore.

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, 201816 julio, 2022 por Diego Tunubaláen 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, 201816 julio, 2022 por Diego Tunubaláen 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.

Instalando y utilizando ESXi Compatibility Checker

en 13 septiembre, 201816 julio, 2022 por Diego Tunubaláen 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

Nacho Aprende Virtualización

Categoría: vSphere