ESXi – Página 2 – Nacho Aprende IT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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í

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

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

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

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.

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

4. Haga clic en advanced certificate request.

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.

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.

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.

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

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