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

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.

image

(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.

image

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.

image

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

clip_image001

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

image

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

image

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()
}

image

 

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.

clip_image001[1]

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

image

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

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.

image

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

image

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

image

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

image

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()
}

image

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.

image

Instalando y utilizando ESXi Compatibility Checker

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.

image

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

image

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

clip_image001

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

clip_image001[5]

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

clip_image001[7]

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

clip_image001[11]

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

clip_image001[13]

UTILIZACIÓN

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

image

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

clip_image001[15]

image

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.

image

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.

image

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.

image

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

Distribución de particiones en ESXi 6.5

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)

clip_image002[11]

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

clip_image004[11]

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

clip_image006[11]

Reemplazo De Certificados Para ESXi 6.x

Alguna vez en nuestra profesión hemos tenido clientes que por cumplimiento de las políticas de seguridad en la compañía, requiere reemplazar los certificados auto-firmados de vSphere (VMCA) por certificados customizados firmados por una Autoridad de Certificación (CA) presente en el dominio.

El procedimiento descrito a continuación demuestra los pasos necesarios para el reemplazo de certificados en los host ESXi de la infraestructura, eliminando así la advertencia de sitio inseguro que aparece en los navegadores web al conectarse al host client e incrementando la seguridad de la plataforma.

image

Referencia:

  • Configuring CA signed certificates for ESXi 6.0 hosts (2113926)
  • Configuring OpenSSL for installation and configuration of CA signed certificates in the vSphere environment (2015387)

Nota: Si el vCenter no cuenta con certificados customizados, primero deberá efectuarse el procedimiento para reemplazar los certificados en los componentes de vCenter y PSC. De lo contrario el host quedará desconectado después del siguiente procedimiento y al reconectarlo generará nuevos certificados auto firmados.

 

PASO 1: Configurar OpenSSL en el equipo de trabajo

1. Descargue la versión Light del OpenSSL haciendo click Aquí

image

2. Ejecute el instalador del Win64OpenSSL_Light-1_1_0h.exe descargado, dejando la ubicación de destino por defecto (C:\OpenSSL-Win64).

image

3. Después de instalar el OpenSSL Light, verifique la creación de la carpeta OpenSSL-Win64 en la raíz del disco C:\

image

4. Cree un backup del archivo openssl.cfg ubicado en la ruta C:\OpenSSL-Win64\bin y luego edítelo cambiando únicamente los valores marcados en color rojo, con los datos personalizado para la empresa.

[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:vc50, IP:10.0.0.10, DNS:vc50.vmware.com

[ req_distinguished_name ]
countryName = US
stateOrProvinceName = NY
localityName = New York
0.organizationName = VMWare
organizationalUnitName = vCenterInventoryService
commonName = vc50.vmware.com

image

5. Guarde el archivo y ciérrelo.

6. Genere el Certificate Signing Request para cada uno de los host de la siguiente forma:

  • Abra un Command Prompt y navegue hasta el directorio del OpenSSL configurado en la instalación anterior (C:\OpenSSL-Win32\bin)
  • Ejecute el comando: openssl req -new -nodes -out rui.csr -keyout rui-orig.key -config openssl.cfg
  • Convierta la clave (Key) en formato RSA ejecutando el siguiente comando: openssl rsa -in rui-orig.key -out rui.key
  • Una vez el rui.csr es creado, proceda a firmarlo en la Autoridad de Certificación (CA) de la compañía.

image

 

PASO 2: Firme el Certificado con la CA de la compañía

1. Crea una plantilla personalizada para la creación de certificados. Para obtener más información, consulte Creating a Microsoft Certificate Authority Template for SSL certificate creation in vSphere 6.x (2112009)

2. Inicie sesión en la interfaz web de la autoridad certificadora de CA de Microsoft. Por defecto, es http: //servidorCA_FQDN/CertSrv/.

3. Haga clic en el enlace Request a certificate (.csr ).

clip_image001

4. Haga clic en advanced certificate request.

clip_image002

5. Haga clic en Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.

6. Abra la solicitud de certificado generada anteriormente (rui.csr) en un editor de texto sin formato y copie desde —–BEGIN CERTIFICATE REQUEST—– hasta —–END CERTIFICATE REQUEST—–, sin que queden espacios al final y péguelo en el cuadro Saved Request.

7. Seleccione la plantilla de certificado creada en el punto 1, vSphere 6.5.

clip_image003

8. Haga clic en Submit para enviar la solicitud.

9. Haga clic en Base 64 encoded en la pantalla de Certificado emitido.

10. Haga clic en el enlace Download Certificate.

11. Guarde el certificado como rui.crt.

Nota: No guarde el certificado con otro nombre diferente a rui.crt, ya que no funcionaría.

 

PASO 3: Instalar y configurar los certificados en el host ESXi

1. Inicie sesión en el vCenter Server a través del Web Client y coloque el host en Modo Mantenimiento.

2. Utilizando WinSCP inicie sesión al host ESXi y descargue localmente los archivos rui.crt y el rui.key que se encuentran en la ruta /etc/vmware/ssl, para tener un backup de los mismos.

image

3. Elimine los archivos existentes rui.crt y rui.key de la ruta /etc/vmware/ssl

4. Suba los nuevos archivos rui.crt y rui.key, generados en el PASO 1, a la misma carpeta (/etc/vmware/ssl). Utilice la Opción de Transferencia en modo texto para evitar la aparición de caracteres adicionales.

image

5. Antes de reiniciar los Management Agents para aplicar el reemplazo del certificado, verifique que el nuevo rui.crt y el rui.key no tengan caracteres especiales después de la línea de fin (no debería aparecer ningún carácter erróneo ^M).

imageimage

6. Reinicie los Management Agents del servidor desde DCUI Troubleshooting Options > Restart Management Agents. Presione F11 para reiniciar.

image

7. Verifique la aplicación de los certificados customizados con un navegador como Internet Explorer o Google Chrome.

imageimage

8. Saque el host de Modo Mantenimiento y repita cada uno de los pasos para todos los hosts de la infraestructura.