Limpiando particiones en discos para configuración de vSAN

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.

image

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.

image

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.

image

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.

image

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.

image

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.

image

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

Desde el vCenter

image

o desde el Host Client (Clear partition table)

image

Y notará que la tarea finaliza con éxito.

image

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.

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

Silenciar alarmas de health check en vSAN

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

image

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

clip_image001[11]

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.

image

Ejemplo:

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

image

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.

clip_image001

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

image

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’

image

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.

clip_image001[5]

 

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.

Detectar ubicación física de discos que hacen parte de vSAN

Muchas veces nos encontramos con el dilema de no poder rastrear la ubicación de un disco de la vSAN hasta la ubicación real (slot) en el servidor. Esto por lo general ocurre cuando necesitamos reemplazar un disco perteneciente a un Disk Group que se encuentra alarmado o un Storage Device que se muestra como degradado en la configuración de vSphere, pero a nivel físico no se visualiza ninguna alerta. ¿Como hacemos entonces para saber cuál disco es el que debemos cambiar? Pues bien he aquí un procedimiento sencillo que nos puede ayudar a salir de la incertidumbre.

1. Desde el vSphere Web Client seleccionar el host al que se desea realizar la inspección del discos en el mundo físico, sea éste que se encuentre alarmado o no. Vaya a la pestaña Configure | Storage Devices, y tomar nota de nombre canónico (naa.*) del dispositivo en cuestión.

clip_image002

2. Inicie sesión SSH en el host ESXi que se encuentra el disco local que hace parte de la vSAN, con el usuario root y la contraseña configurada, para ejecutar el siguiente comando que mostrará la ruta reclamada por el plugin de multipathing nativo para VMware (NMP: VMware Native Multipath Plugin) perteneciente al Pluggable Storage Architecture.

[root@esxi:~]esxcli storage nmp path list

clip_image004

En la imagen mostrada arriba aparecen varios identificadores sas.*, que de izquierda a derecha el primero corresponde a la dirección SAS de la controladora de discos, la segunda a la dirección SAS del disco y el ultimo el nombre canónico (naa.*) definido por vSphere para cada Storage Device.

De esta manera, si se quiere buscar cuál es la posición física correspondiente a un determinado disco local se debe buscar de manera inversa, esto es; identificar primero el nombre canónico naa.* del disco en vSphere (Paso 1) y posteriormente buscar dicho naa.* en la salida del comando anterior (Paso 2). Una vez encontrado, se debe tomar nota de su correspondiente SAS Address (segunda dirección de izquierda a derecha).

Ejemplo:

Para buscar la ubicación física del Storage Device seleccionado en la siguiente figura

clip_image005

Al ejecutar el comando esxcli storage nmp path list y buscar el nombre canónico en la salida de comando (naa.5002538c40896228) se obtiene lo siguiente

clip_image007

3. Ahora se debe buscar en cada uno de los discos locales del servidor, la dirección sas.* encerrada en color rojo o el target del dispositivo TXX encerrado en color azul, desde la interface de administración del mismo (iLO, CIMC, iDRAC, etc.). A continuación, una muestra de la coincidencia para el caso de un servidor CISCO.

clip_image009

En la imagen anterior se puede observar que el disco corresponde al slot 4 (PD-4), ya que al realizar la búsqueda en cada uno de los discos éste coincide tanto para la Dirección SAS como para el Target (id. del dispositivo para el caso de CISCO).

Nota: Puede haber casos en que debido al firmware sugerido por la matriz de compatibilidad de vSAN para la controladora de discos, la dirección sas.* en salida del comando del Paso 2 aparezca como desconocido (unknown) para la dirección sas de la controladora y de los discos, por lo que nos queda solo rastrear el disco en el mundo físico por su target encerrado en color azul.

Reemplazo de certificados vCenter Server 6.5 U1 con PSC embebido

Existen varias opciones para reemplazar los certificados de la infraestructura vSphere y esta tarea puede contar con más o menos pasos de ejecución, sin ser necesariamente difícil, dependiendo del nivel de seguridad que espera la compañía.

clip_image001[71]

Este artículo está orientado a aplicar el método de reemplazo Hibrido que es suficiente y recomendado para la mayoría de las compañías que buscan cumplir con un estándar de seguridad. Este método se centra en el reemplazado únicamente de los certificados Machine SSL de vCenter dejando la tarea de firmar los Solution User y los Certificados de los hosts a la CA (Certificate Authority) de VMware denominada VMCA (VMware Certificate Authority) alojada en el PSC, conociéndose este proceso como certificados auto firmados.

Para un vCenter Server con PSC (Platform Service Controller) embebido, VMCA estará alojada dentro del mismo Appliance, sin embargo; para un despliegue de vCenter Server Con PSC Externo, estará alojada dentro del appliance de PSC y no dentro del appliance del vCenter.

Para iniciar el proceso de reemplazo de certificados SSL en un vCenter Server 6.5 U1 con Platform Service Controller Embebido o Externo se deben tener en cuenta los siguiente KB oficiales de los cuales se ha extraído de manera simple y grafica los pasos para su correcta aplicación, de manera que no exista problema en la ejecución del mismo.

Nota: Si se cuenta con un despliegue de vCenter con PSC Externo basta con realizar el procedimiento descrito a continuación primero en el PSC y después en el vCenter, pero para mayor entendimiento crearemos un nuevo artículo para ese caso específico.

Referencias:

1. Replacing default certificates with CA signed SSL certificates in vSphere 6.x (2111219)

2. Creating a Microsoft Certificate Authority Template for SSL certificate creation in vSphere 6.x (2112009)

3. Obtaining vSphere certificates from a Microsoft Certificate Authority (2112014)

4. Replacing a vSphere 6.x Machine SSL certificate with a Custom Certificate Authority Signed Certificate (2112277)

PASO 1: Creación de una plantilla Microsoft Certificate Authority para la creación de certificados SSL en vSphere 6.x.

Para realizar esta tarea nos podemos apoyar en el KB2112009 mencionado en las referencias, sin embargo, el procedimiento es detallado a continuación.

1. Al conectarse al servidor CA, generará los certificados a través de una sesión RDP.

2. Haga clic en Inicio> Ejecutar, escriba certtmpl.msc y haga clic en OK.

3. En la Consola de plantilla de certificado, en Nombre de visualización de la plantilla, haga clic con el botón derecho en Web Server y haga clic en Duplicar plantilla.

image

4. En la ventana Plantilla duplicada, seleccione Windows Server 2003 Enterprise para compatibilidad con versiones anteriores.

Nota: Si tiene un nivel de cifrado superior a SHA1, seleccione Windows Server 2008 Enterprise.

clip_image001[3]

5. Haga clic en la pestaña General.

6. En el campo Nombre de visualización de la plantilla, ingrese vSphere 6.x como el nombre de la nueva plantilla.

clip_image001[7]

7. Haga clic en la pestaña Extensiones.

8. Seleccione las políticas de la aplicación y haga clic en Editar.

clip_image001[9]

9. Seleccione Server Authentication y haga clic en Remove, luego en OK.

Nota: Si existe Client Authentication, elimine esto de las Application Policies también.

clip_image001[11]

10. Seleccione Key Usage y haga clic en Editar.

clip_image001[13]

11. Seleccione la opción Signature is proof of origin (nonrepudiation). Deje todas las demás opciones como predeterminadas.

12. Haga clic en OK.

clip_image001[15]

13. Haga clic en la pestaña Subject Name.

14. Asegúrese de que la opción Supply in the request esté seleccionada.

clip_image001[17]

15. Haga clic en OK para guardar la plantilla.

16. Proceda a la sección Adding a new template to certificate templates para que la plantilla de certificado recién creada esté disponible.

clip_image001[19]

image

PASO 2: Generar los Request Certificate para el vCenter Server

Debido a que vamos a necesitar un repositorio para alojar los archivos de Certificate Signing Request (.CSR) y el Private Key, necesitamos ingresar al appliance a través de la herramienta libre WINSCP con usuario root, para crear uno en la carpeta temporal. Este paso no es necesario y puede definirse directamente el destino como /tmp o cualquier otro directorio con permisos de escritura dentro del appliance. Sin embargo, para tener un mejor orden, lo vamos a crear.

Como configuración predeterminada vCenter o PSC Appliances, no permite la conexión remota de WinSCP, por lo que es necesario habilitarlo de la siguiente forma:

1. Inicie una conexión SSH al dispositivo vCenter Server.

2. Proporcione el nombre de usuario y la contraseña del usuario root cuando se le solicite.

3. Ejecute este comando para habilitar el shell Bash:

shell.set –enable True

4. Ejecute este comando para acceder al shell Bash:

Shell

5. En el shell Bash, ejecute este comando para cambiar el shell predeterminado a Bash:

Chsh -s /bin/bash root

clip_image001[21]

Nota: Los pasos anteriormente mencionados corresponden al VMware KB Error when uploading files to vCenter Server Appliance using WinSCP (2107727).

Ahora ya podrá realizar una conexión remota con WinSCP. Una vez inicie sesión vaya al directorio raíz, después nos muévase hasta el directorio /tmp y haga click en el icono de nuevo directorio para crear la carpeta Cert, en la que posteriormente guardaremos y cargaremos nuestros archivos asociados a los certificados.

clip_image001[23]

Nota: Si cuenta con un despliegue de vCenter Server con un PSC Embebido, habrá un certificado de Machine SSL. Sin embargo, Si tiene un vCenter Server con un PSC externo, cada máquina (PSC y vCenter) tendrá su propio certificado Machine SSL. Por lo tanto, debe realizar esta tarea en cada máquina.

6. Para reemplazar el certificado de Machine SSL con el certificado de CA personalizado:

Inicie el vSphere 6.x Certificate Manager:

Para vCenter Server 6.x Appliance:

/usr/lib/vmware-vmca/bin/certificate-manager

Para vCenter Server 6.x Windows:

C:\Archivos de programa\VMware\vCenter Server\vmcad\certificate-manager

7. Seleccione la opción 1 (Reemplazar certificado SSL de máquina con certificado personalizado)

clip_image001[25]

8. Proporcione la contraseña de administrator@vsphere.local cuando se le solicite

9. Seleccione la Opción 1 (Generate Certificate Signing Request(s) and Key(s) for Machine SSL certificate)

10. Ingrese el directorio en el que desea guardar el Certificate Signing Request (solicitud de firma de certificado con extensión. CSR) y el Private Key (clave privada). Para este caso se utilizará el directorio creado anteriormente /tmp/Cert

clip_image001[27]

A continuación, debe seguir un asistente que le preguntará los datos asociados a su compañía para poder crear certificados customizados.

Para este caso de laboratorio se utilizarán los siguientes datos como ejemplo:

Country: CO

Name: mhvcentersa07.xxxxxxx.red

Organization: Lab

OrgUnit: Tecnologia

State: Cundinamarca

Locality: Bogota

IPAddress (optional):

Email: dgt_g_sistemas_operativos@xxxxxxxx.gov.co

Hostname: mhvcentersa07.xxxxxxx.red

VMCA Name: mhvcentersa07.xxxxxxx.red

A diferencia de vSphere 6.0 Update 3, en vSphere 6.5 y versiones siguientes aparecerá el siguiente aviso:

Ingrese el valor correcto para VMCA ‘Nombre’:

Este valor es el FQDN de la máquina en la que se ejecuta la configuración del certificado, para este caso es el FQDN del vCenter Server Appliance.

image

Los archivos creados en el directorio /tmp/Cert tendrán los nombres vmca_issued_csr.csr y vmca_issued_key.key.

Descárguelos localmente con la Opción de Transferencia “Texto” para evitar que se agreguen caracteres al final del archivo.

image

PASO 3: Obtención de certificados de vSphere de una entidad emisora de certificados de Microsoft

1. Proporcione el vmca_issued_csr.csr a su autoridad de certificación para generar un certificado SSL de máquina, asígnele el nombre machine_name_ssl.cer. Para obtener más información, consulte Obtaining vSphere certificates from a Microsoft Certificate Authority (2112014).

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

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

clip_image001[33]

4. Haga clic en advanced certificate request.

clip_image001[35]

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 descargada anteriormente vmca_issued_csr.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.

clip_image001[37]

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

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 Descargar certificado.

Guarde el certificado como con el nombre que desee, para este caso será vspherelab.cer en un directorio de su equipo puede ser C:\Certs\

clip_image001[39]

11. Vuelva a la página de inicio del servidor de certificados y haga clic en Descargar un certificado de CA, cadena de certificados o CRL.

clip_image001[41]

12. Seleccione la opción Base 64.

13. Haga clic en el enlace de la cadena Descargar certificado de CA.

clip_image001[43]

14. Guarde la cadena de certificados como cachainlab.p7b en la carpeta c:\Certs de su equipo.

15. Haga doble clic en el archivo cachainlab.p7b para abrirlo en el Administrador de certificados.

16. Navegue a C: \Certs\cachainlab.p7b> Certificados.

Por lo general las empresas que utilizan Entidades Certificadoras, tiene por lo menos una Enterprise Root CA Standalone y una o varias CA Subordinadas. En este caso se observan efectivamente dos.

image

17. Haga clic con el botón derecho en cada uno de los certificados listados y haga clic en Todas las acciones> Exportar.

image

18. Haga clic en Siguiente.

19. Seleccione X.509 codificado Base-64 (.CER), y luego haga clic en Siguiente.

clip_image001[49]

20. Si tiene más de una entidad certificadora Subordinada, realice los pasos para exportar, en cada uno de los certificados listados, expórtelos y guárdelos con un nombre que diferencie las subordinadas de la Root, como por ejemplo: C: \certs\interm64-1.cer, C:\certs\interm64-2.cer y C:\certs\Root64.cer.

Para este caso se han elegido los nombres SubCA.cer para la Entidad CA Subordinada y RootCA.cer para la principal.

clip_image001[51]

PASO 4: Crear cadena de certificados

Una de los pasos que podría llegar a confundirnos es la creación de la cadena cuando en la compañía existen más de una CA, es decir una o varias subordinadas de la Root.

Para este caso se debe crear un nuevo certificado que denominaremos RootChain.cer y el cual contendrá la información tanto de la principal como de su subordinada(s) teniendo en cuenta el siguiente orden don de Intermediate son las CA Subordinadas y Root es la Principal:

clip_image001[53]

1. Realice una copia del certificado exportado en el paso anterior para la CA Root y cámbiele el nombre a RootChain.cer

2. Abra el archivo creado RootChain.cer con un editor de texto sin formato

3. También abra el archivo exportado para SubCA.cer con un editor de texto sin formato y copie el contenido desde —–BEGIN CERTIFICATE REQUEST—– hasta —–END CERTIFICATE REQUEST—–, sin que queden espacios al final.

4. Vaya a la ventana del RootChain.cer abierto anteriormente en el editor de texto y pegue el contenido justo encima de —–BEGIN CERTIFICATE REQUEST—–

clip_image001[55]

Recuerde que si tiene más de una CA Subordinada se debe copiar el contenido de cada una de ellas dentro del certificado RootChain.cer respetando el orden ya indicado.

5. Haga click en Archivo -> Guardar y déjelo abierto para posterior uso

6. Una vez creada la cadena RootChain.cer se debe adicionar el contenido de este archivo al certificado emitido por la CA para nuestro vCenter Server Appliance.

Para esto cree una copia del certificado de vCenter obtenido de la CA y cambie el nombre para identificarlo del original, por ejemplo vspherelabfull.cer

clip_image001[57]

7. Vuelva a la ventana de RootChain.cer en el editor de texto y copie todo el contenido del archivo

8. Abra el archivo creado vspherelabfull.cer con un editor de texto sin formato y pegue el contenido del certificado RootChain.cer creado anteriormente, justo debajo de la línea —–END CERTIFICATE REQUEST—– del certificado customizado de vCenter Server.

clip_image001[59]

9. Haga click en Archivo -> Guardar

PASO 5: Importar Certificados Customizados

Ya estamos listos para importar, los certificados al vCenter y ahora se deben cargar los archivos RootChain.cer y vspherelabfull.cer al directorio temporal /tmp/Cert del vCenter Server Appliance a través del WinSCP.

1. Vuelva a la sesión realizada hacia el vCenter Server con el WinSCP

2. Cargue los archivos RootChain.cer y vspherelabfull.cer al directorio temporal /tmp/Cert

Nota: Utilice la Opción de Transferencia “Texto” para evitar adicionar caracteres a los archivos

image

3. Regrese al vSphere 6.x Certificate Manager y seleccione la Opción 1 (Continue to importing Custom certificate(s) and key(s) for Machine SSL certificate).

4. Proporcione la ruta completa a vspherelabfull.cer y vmca_issued_key.key y del certificado RootChain.cer

5. Responda Yes (Y) para continuar la operación

image

6. Espere a que se realice el proceso. Esto puede tardar varios minutos, pero puede ver como se actualizan algunos servicios

image

7. Abra Internet Explorer o Google Chrome, si los tenía abiertos ciérrelos y vuélvalos a abrir. A continuación, digite el FQDN del vCenter y observará que ya no aparece el error de certificado y muestra el sitio como seguro.

Vista desde Internet Explorer

image

Vista desde Google Chrome

image

8. En Internet Explorer haga click sobre el candado y luego Ver Certificados

9. Para obtener más detalle y verificar el cambio haga click en la pestaña Ruta de Certificación

image