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.
· 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
A continuación, se presentará la instalación y algunos ejemplos de utilización del producto PowerNSX que nos permitirá automatizar tareas repetitivas en el NSX Manager y ahorrar tiempo valioso en nuestras implementaciones y tareas de administración.
PASO 1: Instalación de PowerNSX
Para comenzar con PowerNSX se requiere un entorno que tenga PowerShell y PowerCLI instalados. PowerCLI Core ahora es compatible, por lo que este puede ser un dispositivo Windows, Linux o macOS.
Los pasos de instalación para las diversas plataformas requieren lo siguiente:
PowerShell y PowerCLI deberían estar instalados para Windows
Al menos PowerShell 3, se recomienda PowerShell 4 (Win7-8.1, Server 2012/R2), PowerShell 5 (Win10, Server2016)
PowerCLI 5.5 ya no es compatible y se requiere mínimo la versión 6.0 R3
PowerShell Core y PowerCLI Core deberían estar instalados para macOS y Linux
Al momento de escribir este artículo, la versión compatible es PowerShell Core alpha 18.
Adicionalmente se requiere la versión PowerCLI Core 1.0
El método recomendado para instalar PowerNSX es ejecutando una línea de PowerShell que descarga e invoca el Instalador PowerNSX directamente desde el repositorio GitHub de VMware. PowerNSX trasladará su mecanismo de distribución a la galería PowerShell en el futuro, por lo que se recomienda verificar https://powernsx.github.io para obtener las últimas instrucciones de instalación específicas de la plataforma.
Nota 1: Al seguir las secciones de ejemplo, copie las instrucciones de instalación apropiadas en https://powernsx.github.io en lugar de copiarlas manualmente desde este documento.
Nota 2: Este módulo no está soportado por VMware y no incluye garantías explícitas o implícitas, por lo que se recomienda probar y validar su funcionalidad en un ambiente de laboratorio antes de usar este producto en un entorno de producción.
Al hacer clic sobre el botón INSTALAR, la página nos llevará al proceso de instalación y a un breve resumen del PowerNSX.
La instalación a través de PowerShell Gallery solo es compatible con Windows en este momento. La Galería PowerShell está disponible de forma nativa en PowerShell 5 y superior, y se puede instalar fácilmente en versiones anteriores.
Instalar PowerNSX a través de la Galería PowerShell – Windows
PowerNSX se puede instalar a través de una serie de métodos. Comenzar con PowerNSX es rápido y eficiente gracias a la distribución a través de la Galería de PowerShell en Windows, mientras que para los usuarios de macOS y Linux esto puede ser a través del script de instalación o ejecutarse manualmente.
Ejecute los siguientes comandos en una ventana de PowerShell para instalar PowerNSX en el usuario actual o para todos los usuarios de acuerdo a su necesidad. Si PowerCLI no está instalado, los componentes requeridos se descargan e instalan automáticamente. La galería PowerShell es el método recomendado para usuarios de Windows.
Ejecute el siguiente comando para instalar PowerNSX en el usuario actual:
Para instalar en todos los usuarios, ejecute PowerShell como administrador:
Find-Module PowerNSX | Install-Module
Paso 2: Trabajando con PowerNSX
Una vez integrada la herramienta con PowerShell, es momento de aprovechar todas las ventajas de automatización que nos ofrece siguiendo algunos ejemplos comunes, que van desde la conexión al NSX Manager para listar sus propiedades hasta la creación de reglas en el Firewall Distribuido para procesos de micro segmentación.
Conectando a NSX Manager
Los administradores pueden aprovechar SSO o una conexión directa para garantizar el nivel correcto de acceso cuando se utiliza la API de NSX Manager. Con una conexión establecida para vCenter y NSX Manager, un administrador puede realizar operaciones con PowerNSX, de manera que es necesaria una cuenta de usuarios con permisos tanto en vCenter como en el NSX Manager.
La conexión con una cuenta SSO requiere una definición explícita del servidor vCenter. La cuenta que se conecta a vCenter se usará para conectarse a la API de NSX, que creará una sesión PowerCLI y PowerNSX con los permisos de SSO aplicados.
En la consola de PowerShell o PowerShell ISE ejecute el siguiente comando para realizar la conexión, a continuación ingrese usuario y contraseña con permisos en vCenter Server y en NSX Manager
Una vez conectado obtendrá una vista como la siguiente
Ejemplos de configuración con PowerNSX
En la página web oficial del PowerNSX, podremos encontrar algunos ejemplos para operar con NSX Manager como crear Logical Switches, DRL, Security Groups entre otros. Se recomienda visitar el enlace https://powernsx.github.io/get-started
Para efectos de mostrar la utilidad de Power NSX y teniendo en cuenta que debo hacer la creación de 150 Security Groups que me agrupen las 150 aplicaciones de un cliente, veo de gran utilidad utilizar esta herramienta ya que aprovisionarlos de forma manual a través de la interface grafica tardaría mayor tiempo y realmente no soy muy amigo de las tareas repetitivas, por lo que prefiero automatizarlas.
Ejemplo 1: Para visualizar los Security Groups creados en el NSX Manager basta con utilizar el siguiente comando
/> Get-NsxSecurityGroup | select name, objectid | ft -auto
Comprobamos que nos muestra lo mismo desde el NSX Manager UI
Ejemplo 2: Podemos ahora comprobar los miembros de un security group de la siguiente forma
El cmdlet Get-NsxSecurityGroupEffectiveMember toma un objeto Security Grupo de la fuente de información y valida las máquinas virtuales que se resuelven. En el ejemplo anterior, las máquinas virtuales que resultan en el security Group SG_KASPERSKY se incluyen como propiedades.
El resultado del Ejemplo anterior devuelve el objeto primario de la membresía. Si bien es posible usar la notación de puntos para atravesar el objeto y encontrar más detalles, hay cmdlets adicionales que logran el mismo resultado.
Nota: Para miembros que contienen espacio se deben escribir el nombre del miembro entre comillas para evitar errores.
Adicionalmente, podríamos definir los miembros en una variable que puede contener una o varias máquinas virtuales de la siguiente forma, para posteriormente adicionarlas al Security Group creado
/> $Member= get-vm -Name ‘VMName’
Seguidamente para adicionar el miembro al security group solo hace falta ejecutar el siguiente comando
Además de verificar con el cmdlet (Get-NsxSecurityGroup -name SecurityGroupName).member.name que la máquina haya sido agregada al Security Group, podemos también corroborar que aparezca incluida desde la interface gráfica
Ejemplo 4: Para un proceso de micro segmentación se recomienda crear nuevas secciones para no modificar la sección por default. Esto lo podemos lograr con PowerNSX de la siguiente forma
La propiedad -position indica que se debe crear la sección antes de la sección por Default
Para obtener más ejemplos de cómo usar el cmdlet puede ejecutar el siguiente comando
/> Get-help New-NsxFirewallSection -Examples
Ejemplo 5: Por último, nos falta crear por lo menos una regla dentro de la sección por lo que nos apoyaremos en el siguiente comando.
Nota: Se debe ser consiente que todos los objetos puede ser Universales o Locales. Una regla de una sección que NO es universal no puede contener objetos universales por lo que si definimos una variable como $Servicename solo como get-nsxservice HTTPS tomará tanto las propiedades universales como locales y al ejecutar el comando de abajo fallará. Es por esta razón que en la variable $Servicename solo guardaremos sus valores locales como se muestra a continuación.
Una vez aclarado lo anterior, procedemos a ejecutar los siguientes comandos que nos crearán una regla con un origen, un destino, el servicio HTTPS, tendrá la acción de permitir el tráfico y estará logueando el tráfico con la Etiqueta «Testing creating a rule»
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.
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.
7. Verifique la aplicación de los certificados customizados con un navegador como Internet Explorer o Google Chrome.
8. Saque el host de Modo Mantenimiento y repita cada uno de los pasos para todos los hosts de la infraestructura.
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.
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
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
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
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.
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.
![clip_image002[11]](https://nachoaprendeit.com/wp-content/uploads/2018/06/clip_image00211.jpg "clip_image002[11]")
![clip_image004[11]](https://nachoaprendeit.com/wp-content/uploads/2018/06/clip_image00411.jpg "clip_image004[11]")
![clip_image006[11]](https://nachoaprendeit.com/wp-content/uploads/2018/06/clip_image00611.jpg "clip_image006[11]")
Nacho Aprende IT 