Solucionando precheck fallido: Disk space on Service-Logs partition needs to be increased – vRA Upgrade 8.x

En esta oportunidad vamos a resolver rápidamente un problema que suele ocurrir durante la validación que vRealize Lifecycle Manager (vLCM) realiza en el proceso de actualización de vRealize Automation 8.x (vRA).

El proceso de validación falla aunque la partición de logs tiene suficiente espacio libre. De acuerdo al precheck realizado por vLCM durante el proceso, el disco debería tener mas de 22GB y solo tiene 8GB.

Pues bien, si hacemos clic en VIEW en la columna Recommendations, podremos obtener la recomendación para la solución a nuestro problema. Donde básicamente nos indica que crezcamos en este caso el disco VM Disk 3 y después ejecutemos el comando vracli disk-mgr resize, en el Appliance con el error (en este caso lo muestra para los tres appliances del cluster de vRealize Automation 8.x).

Nota: El problema realmente ocurre cuando nuestra versión de vRA es 8.0.1 o 8.1. Que es nuestro caso (8.1). Pero afortunadamente existe un workaround que consiste de los siguientes pasos.

1. Inicie sesión SSH hacia cada uno de los appliances de cluster vRA y ejecute los siguientes comandos para verificar el espacio de los disco en vRA.

vracli disk-mgr

También puede utilizar el comando df -h

2. Crezca el tamaño del disco indicado desde vCenter Server en cada una de las VM asociadas al cluster de vRA 8.x.

3. Vuelva a la sesión ssh y ejecute el siguiente comando en cada uno de los appliances del cluster de vRA.

vracli disk-mgr resize

Verifique el log con  el comand cat /var/log/disk_resize.logdf -h

Si obtiene alguno de los siguientes errores durante el Resizing continúe con los siguientes pasos.

"ERROR: Error resizing file system"

"Extending logical volume services-logs... New size (5119 extents) matches existing size (5119 extents)"

"ERROR: Error resizing logical volume."

4. Ejecute los siguientes comando en cada uno de los appliances de vRA

/usr/sbin/resize2fs /dev/mapper/logs_vg-services--logs

rm /var/vmware/prelude/disk-management/disk_stats

vracli disk-mgr

(Opcional) df -h

Ejemplo: Nodo vRA 01

Ejemplo: Nodo vRA 02

Ejemplo: Nodo vRA 03

Después de haber realizado el procedimiento anterior, podrá realizar el precheck nuevamente y este debería mostrar el mensaje "All validations passed for this environment".

Referencia

https://kb.vmware.com/s/article/79925

Reset password expirado en VMware Identity Manager vía API

En esta ocasión venimos a solucionar un problema que hace un par de días me consumió toda una tarde, primero porque no tenia ni idea de como configurar Postman y segundo porque no sabia como utilizar las API calls disponibles para VMware Identity Manager (vIDM).

Escenario:  El usuario default Tenant (confiadmin) o cualquier usuario local creado en vIDM para el entorno de vRA tiene su contraseña expirada.

Antes de continuar debemos aclarar que si tenemos un SMTP configurado en la solución vIDM, el reset del password no seria un problemas debido a que simplemente hacemos login en la URL del Tenant de vIDM con el usuario admin, vamos a la sección User & Groups, seleccionamos el usuario que tiene el password expirado y hacemos clic en reset password. Esta acción envía una notificación por email y desde allá podremos restaurar la clave.

El problema realmente viene cuando no tenemos un SMTP configurado, por lo tanto VMware Identity Manager (vIDM) no es capas de enviar la notificación al usuario y no podemos restaurar la contraseña de esta manera. El error generado cuando esto pasa dice los siguiente: Password reset email could not be sent due to "Error sending email".

Como el nombre del post lo indica, la clave aquí es usar API calls utilizando la herramienta Postman. Al final notará que resulta ser la forma mas fácil de solucionar el problema. Veamos el procedimiento…

PROCEDIMIENTO

El procedimiento explicado a continuación muestra la desde la configuración del cliente necesario en vIDM, hasta la utilización de las APIs en Postman para la restauración del password del usuario afectado.

Configurar vIDM para usar OAuth token

1. Una vez instalada la herramienta debemos configurar un token para la autenticación. Utilizando los siguientes pasos que han sido adaptados del siguiente blog.

2. Desde un navegador web haga Login en la URL del Tenant de vIDM en donde tiene el usuario afectado. Y luego vaya a la seccione Catalog y clic en Settings.

3. Clic en Remote App Access y después clic en Create Client.

4. Configure el Cliente con los siguientes datos:

– Access Type: Service Client Token.

– Client ID: Elija un nombre como por ejemplo PostmanClient.

5. Ahora haga clic en la flecha frente a Advanced para visualizar las opciones y clic en  Generate Shared Secret. (copie y pegue el Shared Secret generado en un bloc de notas para utilizarlo mas adelante).

Nota 1: Los valores del TTL del token de acceso le indicarán cuánto tiempo serán válidos sus Tokens tipo Bearer.

6. Y por ultimo clic en el botón ADD.

Configurar Postman para usar un token OAuth

1. Lo primero que debemos hacer por supuesto es descargar e instalar Postman, la descarga la pude realizar desde aquí.

2. Abra una nueva pestaña en Postman.

3. En la sección Authorization, seleccione TYPE como “OAuth 2.0”

4. Clic en el botón Get New Access Token y configure los siguientes datos:

– Token Name: elija un nombre. Ejemplo: vIDM Token

– Grant Type: Client Credentials

– Access Token URL: ingrese https://URL_del_Tenant/SAAS/auth/oauthtoken.

  Ejemplo:  https://irpaclyvm-vidm-it-mst.lab.local/SAAS/auth/oauthtoken

– Client ID: Ingrese el Client ID creado arriba (PostmanClient).

– Client Secret: Copie y pegue el shared secret que dejó disponible en el bloc de notas anteriormente.

– Scope: Admin.

– Client Authentication: Send as Basic Auth header.

5. Haga clic en Request Token.

6. Clic en Use Token.

7. Ahora podrá ver sus token creados en el menú desplegable de Available Tokens para su posterior uso.

Hasta aquí ya tenemos vIDM y Postman listos para usar las API call y solucionar nuestro problema con la contraseña del usuario configadmin.

Consultar detalles del Usuario

Debido a que necesitamos restaurar la contraseña del usuario configadmin. Lo primero que debemos hacer es obtener los detalles de ese usuario especifico haciendo uso de la siguiente API.

1. Abra una nueva pestana en Postman.

2. Seleccione el método  GET e ingrese la API para la URL del Tenant https://URLTENANT/SAAS/jersey/manager/api/scim/Users?filter=username%20eq%20%22MiUsuario%22.

Nota 2: Reemplace MiUsuario con el username de su ambiente. Para este ejemplo utilizaremos configadmin

Ejemplohttps://irpaclyvm-vidm-it-mst.lab.local/SAAS/jersey/manager/api/scim/Users?filter=username%20eq%20%configadmin%22

3. Click en el botón Send.

Esta API devolverá todos los atributos asociados para el usuario filtrado.

Nota 3: El resultado de este método debe mostrar Status: 200 OK.

4. De esta salida nos interesa el “Id” del usuario afectado (en este caso configadmin). Por lo que será necesario copiarlo para la modificación de su contraseña .

Modificación del Usuario

Utilizando el “Id” copiado anteriormente utilizaremos la siguiente API para modificar el valor de la contraseña del usuario afectado (configadmin).

1. Abra una nueva pestana en Postman.

2. Seleccione el método  PATCH e ingrese la API para la URL del Tenant https://URLTENANT/SAAS/jersey/manager/api/scim/Users/{ID}

Nota 4: Reemplace la URL del Tenant y el ID del usuario afectado.

Ejemplo: https://irpaclyvm-vidm-it-mst.lab.local/SAAS/jersey/manager/api/scim/Users/12cd6205-6b20-4d00-96b8-b3481155f87e

3. Como puede apreciar en la documentación de las referencias API para vIDM. Para esta API es requerido el ID y el Body. Por lo que tendremos que hacer clic en la pestaña Body, seleccionar raw y escribir los siguiente:

{

    “password”: “VMware1!”

}

Nota 5: Reemplace el password por el deseado.

4. Clic en el botón Send.

El resultado de este método debe mostrar Status: 204 No Content.

5. Ahora debería poder utilizar su contraseña actualizada. Abra una ventana de un navegador web con la URL del Tenant y haga login con el usuario y el nuevo password.

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

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

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

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

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

PROCEDIMIENTO

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

CertUtil -hashfile "Ubicacion_y_nombre_del_archivo" MD5

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

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

e05748cea32d60566f0738a5b811cfdc

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

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

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

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

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

  • MD2
  • MD4
  • MD5
  • SHA1
  • SHA256
  • SHA384
  • SHA512

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

Creciendo almacenamiento de vRealize Lifecycle Manager (vLCM)

¿Quien no ha tenido problemas con el espacio de vRealize Lifecycle Manager (vLCM) cuando estamos realizando una actualización o una instalación de una solución VMware? Pues bien, este post se centrará en este problema común que genera un error en el Request al intentar descargar los Binarios directamente desde My VMware o al intentar hacer el Mapping Local de los mismos.

Si analizamos los destalles del request en la sección Home -> Requests del servicio Lifecycle Operations podremos observar que el detalle del error básicamente contiene lo siguiente:

“com.vmware.vrealize.lcm.common.exception.userinput.myvmware.MyVmwareProductDownloadException: Error occurred while downloading product binaries from MyVMware account : nasawest@vmware.com. Please check the logs for more details        at com.vmware.vrealize.lcm.drivers.myvmware.helper.MyVmwareDownloadRestClient.downloadFile(MyVmwareDownloadRestClient.java:714)        at com.vmware.vrealize.lcm.drivers.myvmware.helper.MyVmwareDownloadUtil.getDownloadUrlsAndDownloadProductBinaryFiles(MyVmwareDownloadUtil.java:295)        at com.vmware.vrealize.lcm.drivers.myvmware.helper.MyVmwareDownloadUtil.downloadProductBinaries(MyVmwareDownloadUtil.java:168)        at com.vmware.vrealize.lcm.plugin.core.myvmware.tasks.MyVmwareDownloadTask.execute(MyVmwareDownloadTask.java:203)        at com.vmware.vrealize.lcm.automata.core.TaskThread.run(TaskThread.java:45)        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)        at java.base/java.lang.Thread.run(Unknown Source)Caused by: java.io.IOException: Error occurred when uploading file to a content repo. It could be due to disk space not available.        at com.vmware.vrealize.lcm.drivers.sourcemapping.helper.SourceMappingUtil.mountISOandUpload(SourceMappingUtil.java:1056)        at com.vmware.vrealize.lcm.drivers.myvmware.helper.MyVmwareDownloadRestClient.downloadFile(MyVmwareDownloadRestClient.java:659)        … 7 more”

Indicándonos una línea muy importante “It could be due to disk space not available” en donde nos esta diciendo que posiblemente no hay espacio disponible para la descarga de los binarios. Para verificar esto haremos lo siguiente:

Iniciamos sesión SSH hacia el Appliance de vLCM con usuario root y la clave configurada durante la instalación.

Ejecutamos el comando df -h

Efectivamente podemos evidenciar que el disco con la ruta /data se encuentra al 72% de utilización y debido a que en este caso de laboratorio el disco es de apenas 20GB, es necesario crecer el disco para poder descargar los BINARIOS.

¿Como lo hacemos entonces para crecer el disco?

No te preocupes… En la interfaz grafica (UI) de vLCM vamos Lifecycle Operation y despues a la sección Home -> Settings -> System Details.

Nota 1: Desde aquí también obtendremos un resumen del almacenamiento usado.

Para Extender el disco simplemente debemos hacer clic en el botón EXTEND STORAGE y diligenciar los datos solicitados para el vCenter Server que esta administrando el Appliance de vLCM. Para este ejemplo creceremos el disco en apenas 10 GB. (Ver Nota 3 al final sino tienes una credencial configurada para vCenter Server).

Clic en el botón EXTEND para continuar.

Clic en el enlace Click here para verificar los detalles del Request y monitorear su actividad.

Una vez terminado el proceso de expansión podrá ver de nuevo en Home -> Settings -> System Details que ya aparecerá el nuevo espacio. Ahora contamos con un total de 30 GB y un 48% usado.

En este punto podemos intentar de nuevo el proceso para descargar los BINARIOS desde Home -> Settings -> Binary Mapping, y el Request debería funcionar sin problemas.

El request para la descarga tardará un par de minutos así que sea paciente.

Una ves completado el Binario estará disponible en Home -> Settings -> Binary Mapping.

Nota 2: La configuración de los Binarios lo remataremos en otro post para no hacer este tan largo.

Nota 3: En vLCM todas la contraseñas son referenciadas desde el Locker. De manera que sino cuenta con una credencial creada para vCenter Server, vaya primero al Locker de vLCM y configure una.

Importando VMs a vRealize Automation 8.x (Onboarding)

Como podemos recordar de nuestro antecesor vRealize Automation 7.x, el proceso mediante el cual se importaban máquinas virtuales al inventario para que pudieran ser “administradas” desde el Portal de vRA, empleaba la funcionalidad Bulk Imports (ver mas). Sin embargo, esta funcionalidad no esta disponible en la nueva y mejorada versión de vRealize Automation 8.x. Por lo que surge la pregunta ¿Cómo hacemos entonces para importar las máquinas de vCenter Server?

Pues bien, vRealize Automation 8.x ha incluido dentro de sus funcionalidades un proceso de importación similar pero conocido como Onboarding el cual básicamente funciona creando Onboarding Plans o Planes de Incorporación en español.

Antes de pasar a la explicación, es importante anotar que el proceso de Onboarding NO facultará a una VM importada para adoptar todas las acciones de día 2 disponibles en vRA. Este proceso se realiza generalmente con el fin de garantizar la administración de las maquinas desde la plataforma de vRealize Automation de tal manera que el usuario final pueda realizar acciones básicas como tomar snapshots, reiniciar, apagar, encender, lanzar consola, etc. Sin requerir el acceso al vCenter Server.

Como es costumbre veamos un poco de teoría…

Onboarding Plans (o planes de incorporación) son usados para identificar VMs que han sido recolectadas desde una Cloud Account pero que aun no son administradas por un Proyecto (Project) de vRealize Automation Cloud Assembly.

Cuando se agrega una Cloud Account que contiene maquinas virtuales que fueron desplegadas fuera de vRealize Automation Assembly, las maquinas no son administradas por Cloud Assembly hasta que se realiza el proceso de Onboarding.

El Proceso incluye básicamente los siguientes pasos:

  1. Crear un Plan.
  2. Poblar el plan con las maquinas.
  3. Ejecutar el plan para importar las VMs.

Durante la creación del plan podemos definir si queremos asociar un Blueprint (Cloud Template) al despliegue y si queremos que las VMs sean importadas un único despliegue para todas las VMs o varios despliegues. Mas adelante aclararemos un poco mejor este tema!

Adicionalmente, podemos hacer el Onboarding de una o muchas maquinas dentro del mismo plan, las cuales pueden ser elegidas de forma manual o utilizando un reglas de filtrado basadas en un criterio como Name, Status, IP y tags.

Como datos adicionales se puede realizar el Onboarding de hasta 3500 máquinas no administradas en un solo Onboarding Plan por hora, o realizar el Onboarding de hasta 17.000 máquinas no administradas simultáneamente en varios Onboarding Plans por hora.

Por ultimo, las máquinas que están disponibles para el Onboarding se muestran en la sección Resources > Machines como Discovered en la columna Origen. Después de realizar el proceso de Onboarding aparecerán en la columna Origen como Deployed.

PRERREQUISITOS

  • Verifique que cuenta con el rol de usuario requerido (Cloud Assembly Administrator).
  • Cree y prepare un Project (Proyecto) y puéblelo con una o mas Cloud Accounts, o utilice uno Project existente.
  • Verifique en la sección Resources > Machines que tiene maquinas en estado Discovered.

PROCEDIMIENTO

Inicie sesión en vRealize Automation 8.x con un usuario que tenga el rol de Cloud Assembly Administrator.

Verifique que las VMs que desea importar a vRA aparezcan en Infrastructure | Resource | Machines como Discovered en la columna Origin.

Una vez identificadas las VMs que queremos importar. Debemos entonces preparar el ambiente para la importación.

Todo Project, tiene asociada una Cloud Zone por lo que debemos tener una disponible. Como sabemos una Cloud Zone tendrá definido los recursos de computo que utilizará un Project (Proyecto). El proceso de Onboarding utilizará esa configuración de proyecto para importar las máquinas.

Sino tiene una Cloud Zone creada puede crearla haciendo clic en Infrastructure | Configure | Cloud Zones y luego NEW CLOUD ZONES.

Seleccione un Cloud Account disponible, defina un nombre y una descripción.

Clic en Compute para filtrar los recursos de computo que serán asignados a la Cloud Zone

Como sabemos los Projects (proyectos) manienen la relación entre usuarios y los recursos de computo sobre los cuales ellos pueden desplegar cargas de trabajo. Sino tiene un Project existente debe crear uno como sigue.

En la sección Infrastructure | Configure | Projects, clic en NEW PROJECT.

Defina un nombre y una descripción.

Asigne un usuario o grupo de usuarios con el role de Administrador y Miembro.

En Provisioning definimos la Cloud Zone creada en pasos anteriores.

Una vez tenemos los prerrequisitos listos, podemos ir a la sección Infrastructure | Onboarding para hacer clic en NEW ONBOARDING PLAN.

Defina un nombre para el Plan de Onboarding, seleccione la Cloud Account y Project creados anteriormente.

Clic en CREATE.

En este punto tendremos dos opciones: La primera permite crear una regla para seleccionar las maquinas manualmente, mientras la segunda permite seleccionar automáticamente las VMs basadas en un criterio. A continuación explicaremos el procedimiento para cada una.

OPCION 1. SELECCIONAR LAS VMs MANUALMENTE

Dentro de la configuración del Onboarding Plan hacer Clic en la pestaña Machine y luego Clic en ADD MACHINE, para seleccionar las maquina que queremos importar de manera manual.

Para este ejemplo utilizaremos las VMs Centos01 y Centos02 creadas directamente en el vCenter server y que por lo tanto son candidatas a ser importadas.

Clic en OK, y nos preguntara el tipo de Deployment (Despliegue) que será asociado a las maquinas importadas. Podremos asignar un despliegue separado para cada VM, un Despliegue para todas las VMs seleccionadas (solo si seleccionamos más de una VM), agregar las VMs a un plan de despliegue o agregar las VMs a un Despliegue existente.

Cada una de ellas es bastante explicita por lo que no nos detendremos a explicar cada una y continuaremos utilizando para este caso la opción Create one plan deployment that contain all the mahines para incluir todas las VMs seleccionadas en un único despliegue y facilitar la administración del mismo.

Al hacer clic en CREATE obtendremos un resumen como el siguiente.

Ahora seleccionamos la pestaña Deployments y verificamos que todas las maquinas se encuentre dentro de un mismo Despliegue como lo indicamos anteriormente.

Como podemos observar el nombre del despliegue por defecto comienza con la palabra Deployment- seguido de un identificador de despliegue de vRA.

Si seleccionamos el Deployment se habilitara la opción RENAME para renombrar el Despliegue y asignar un nombre personalizado.

Al hacer clic en SAVE tendremos el nombre del Despliegue actualizado como se muestra en la siguiente imagen.

Adicionalmente si seleccionamos de nuevo el despliegue podremos observar que además de RENAME tambien se habilitan las opciones BLUEPRINT y REMOVE.

REMOVE evidentemente removerá el despliegue y tendremos que seleccionar nuevamente las maquinas a importar. No obstante si analizamos la opción BLUEPRINT, tendremos la opción de asignar un Blueprint (muy básico) al despliegue mediante la opción Create Blueprint in Cloud Assembly format, o no crear ningún Blueprint mediante la opción None (use runtime snapshot).

Si decidimos utilizar la opción de crear un Blueprint, debemos tener presente que la vista del Blueprint es solo un preview del código asociado y solo se puede editar hasta después del proceso de Onboarding.

Como podemos observar en el código YAML la propiedad imageRef tiene el valor “no_image_available“, por lo que deberá ser modificado a su valor correspondiente una vez terminado el Onboarding.

Nota:

Cuando el plan de Onboarding usa una máquina vSphere, debe editar el Blueprint después que el proceso de Onboarding haya completado. El proceso de Onboarding no puede enlazar la fuente vSphere Machine y su vSphere Template y el Blueprint resultante contendrá una entrada en el código como imageRef: “no image available”.

El Blueprint no puedra ser usado para un futuro despliegue hasta que especifique el nombre de Template correcto en el campo imageRef.

OPCIONAL 2. CREAR UNA REGLA PARA SELECCIONAR AUTOMATICAMENTE LAS VMS

Por otra parte, sino queremos utilizar la seleccion automática entonces debemos hacer Clic en la pestaña Rules y luego ADD RULE para agregar la reglas que definirán las VMs involucradas en el Onboarding Plan.

Defina un nombre para la regla y utilice el filtro para importar las máquinas basado en un criterio. Para el ejemplo haremos clic en Name para filtrar por nombre de VM.

Ahora escribimos en el filtro el nombre por el cual vamos a filtrar las VMs. En el ejemplo importaremos las máquinas con nombre centos. Y Clic en SAVE.

Como resultado obtendrá una vista similar a la siguiente.

Clic en Machines para verificar que las VMs filtradas corresponden a las deseadas. En caso de requerir la exclusión de alguna máquina de la lista podrá seleccionarla y utilizar las opciones EXCLUDE o REMOVE.

Clic en la pestana Deployments para definir el tipo de despliegue. Por defecto cuando utilizamos reglas, el Onboarding Plan deja despliegues separados para cada una de las máquinas y con un nombre de despliegue definido por vRA.

Como podemos ver en la siguiente imagen, por defecto cada máquina agregada tendrá un despligue.

Si seleccionamos uno de los Despliegues se habilitará la opción RENAME para renombrarlo y asignar un nombre personalizado. Clic en RENAME si deseamos cambiarlo.

Defina el nombre personalizado del Despliegue y luego clic en SAVE

Si tenemos varias VMs en despliegues independientes tendríamos que renombrar cada uno de ellos si deseamos personalizarlo.

Por otra parte si queremos agrupar el despliegue para varias VMs utilizando las reglas de filtrado, entonces requeriremos el uso de los Tags de vSphere del tal manera que al seleccionar las máquinas basadas en un criterio de selección (Rule), tengan un tag asociado como se muestra en el siguiente ejemplo, en donde la regla tiene el filtro Name:BG*.

En la siguiente imagen podemos observar que para el ejemplo las máquinas filtradas tienen un tag de vsphere en la columna Tags.

Nota

Si utilizamos la opción de selección automática mediante criterios de búsqueda, necesitaremos definir en la pestaña Summary del Onboarding Plan, el valor asociado al Deployment tag key y de esta forma definir en el plan, que agruparemos las maquinas del despliegue basado en su tag key.

Bueno, hasta aquí todo en orden!… Pero lo importante es que independientemente del método utilizado para seleccionar las máquinas a importar, una vez creado el Plan solo debemos ejecutarlo haciendo Clic en RUN.

El tiempo de ejecución dependerá de la cantidad de máquinas en el plan. Para el caso del ejemplo no tardó mas de 5 segundos.

Una vez ejecutado el plan, el estado de las VMs ha cambiado a Onboarded

Y en la pestaña Summary podremos ver un resumen de la ultima ejecución. Recordemos que estos planes han sido diseñados para poder ser reutilizados, por lo que solo será cuestión de cambiar las reglas (Rules) o las Maquinas (Machines) y ejecutarlo nuevamente en caso de ser necesario.

Para verificar que las VMs ahora hacer parte de vRA debemos ir a Infrastructure | Resources | Machines y podemos observar que las VMs incluidas en el Onboarding Plan ahora se muestran en la columna Origin como Deployed.

Al hacer clic sobre la Pestaña Deployments del Cloud Assembly veremos un despliegue con el nombre definido por nosotros y que contiene además las VMs seleccionadas.

Como nota adicional, si durante la configuracion de Deployment seleccionamos la opción Create Blueprint in Cloud Assembly format, como comentamos anteriormente, un nuevo Blueprint se creará automáticamente al ejecutar el Plan.

Al editarlo podemos observar que únicamente contendrá los componentes asociados a las virtual machine seleccionadas en el plan.

Como se mencionó anteriormente el valor asociado a imageref debe ser cambiado una vez el proceso de Onboarding haya terminado, con el fin que el Blueprint pueda ser utilizado. Aunque a mi parecer, es mejor utilizar la opción de no crear el Blueprint ya que el generado es muy básico.

Por otra parte, si utilizamos la opción None (use runtime snapshot) durante la configuración de Deployment  no se creará ningún Blueprint durante el proceso de Onboarding.

Hasta aquí el proceso de Onboarding esta completo! ¿Pero qué pasa con las acciones del días 2? Pues bien, será necesario crear una o varias políticas en el Service Broker, de tal manera que los usuarios miembros del Project (proyecto) en el cual importamos las VMs tengan restringidas las acciones sobre las máquinas importadas.

Esto debido a que al no ser una máquina virtual concebida originalmente por vRA, no podrá realizar algunas acciones como resize, update, redeploy, etc.

Recordemos que el proceso de Onboarding generalmente se realiza para habilitar en el usuario final acciones básicas como tomar snapshots, reiniciar, apagar, encender, lanzar consola, etc. Que permiten al usuario administrar la maquina desde el portal de vRealize Automation.

Como podremos observar después del Onboarding, el despliegue permitirá al usuario todas las acciones asociadas al Deployment, dentro de las cuales tenemos la opción de eliminar el despliegue; lo cual podría eliminar las VMs importadas. No queremos que al usuario se le ocurra probar esa acción en una VM importada ¿verdad?

De igual manera por default las VMs dentro del despliegue tienen todas las acciones permitidas y muchas veces solo queremos permitirles algunas necesarias para su operación.

Para solucionar esto entonces, necesitaremos definir una política de día 2, para lo cual necesitaremos ingresar a vRealize Automation con un role Service Broker Administrator y hacer clic en Content & Policies | Policies | Definitions y luego clic en NEW POLICY.

Seleccionaremos la opción Day 2 Actions Policy.

Y en la configuración de la política definiremos lo siguiente:

  • Nombre de la política.
  • Descripción (opcional).
  • El alcance de la política (a que proyectos va a ser aplicada).
  • Si será únicamente para un Despliegue especifico también podremos definirlo mediante el campo Deployment criteria.
  • Tipo de cumplimiento (Soft).
  • Role de los usuarios a quienes estará aplicada (Member).
  • Las acciones permitidas.

Las acciones permitidas pueden ser fácilmente filtradas utilizando la caja de texto en el cual podremos escribir vsphere.machine para listar todas las acciones permitidas a una máquina vSphere y de esta manera poder seleccionarlas.

Nota: Al no ser un despliegue nativo de vRA, no agregaremos en la lista ninguna accion para deployment.

Una vez configurada la política de día 2 obtendremos una vista como la siguiente.

Ahora solo queda verificar con un usuario Miembro del Service Broker y del Proyecto en el cual se importaron las VMs, que las acciones permitidas sean las correctas.

Iniciamos sesión con un usuario del miembro del Service Broker y del proyecto

Clic en Service Broker.

 Verificamos que no aparezcan Actions disponibles para el Deployment.

Y únicamente las acciones (Connect to Remote Console, Power Off, Power On y Reboot) configuradas en la política 2Day-Actions-Imported para Machine vSphere, estarán disponibles.

Exportar reglas del Firewall Distribuido de NSX-T con vRNI

Muchas veces bien sea desde el lado de implementación o desde la operación, nos encontramos con el problema de no poder exportar las reglas del Firewall Distribuido de NSX-T en las versiones 3.0 y anteriores. Esta característica ha sido recientemente adicionada a la versión 3.1 (ver aquí), de manera que si tenemos una version anterior nos vemos obligados a recurrir a APIs para poder extraer la configuración de estas políticas y reglas.

Por suerte, por lo general cuando hablamos de Micro-Segmentación casi siempre tenemos a la mano la herramienta vRealize Network Insight con lo cual esta tarea se resume a una consulta y a un export.

PROCEDIMIENTO

En la caja de búsqueda de vRNI realice la siguiente consulta: NSX-T Firewall rule

En el filtro NSX Manager, seleccione el NSX Manager de interés. Si solo tiene un NSX Manager conectado a vRNI omita el paso.

clip_image001

Haga clic en More Option y después clic en Export as CSV.

clip_image002

Clic en Clear All para eliminar todas las propiedades y poder ajustar las que son de nuestro interés.

clip_image003

Clic en ADD PROPERTIES y agregue las siguientes propiedades:

Nota: Puede utilizar el buscador para encontrar las propiedades rapidamente.

  • Section Name
  • Rule ID
  • Configure Source
  • Configure Destination
  • Service
  • Port Range Display
  • Applied to
  • Action
  • Direction
clip_image004

Activamos el check Save changes to: Create a new template, para crea una plantilla con las nueve (9) propiedades seleccionadas.

Por ultimo, en el campo Name asignamos un nombre a la plantilla y hacemos clic en EXPORT.

Seleccionamos el destino y nombre para el archivo .csv y clic en Save.

clip_image005

La próxima vez que desee exportar nuevamente las reglas únicamente tendrá que seleccionar en Property Template la plantilla guardada y automáticamente se cargaran las propiedades asociadas.

clip_image006

Una vez hemos exportado la información simplemente lo importamos en Excel para poder visualizarla como filas y columnas

clip_image007
clip_image008
clip_image009

(Opcional) Una vez la tenemos en este formato, recomiendo crear una tabla dinámica para organizar mejor la información de forma similar a como la vemos en el Firewall Distribuido.

Para esto, active el Diseño de tabla dinámica clásica antes de seleccionar la información de las columnas.

clip_image010

Organice las filas en el siguiente orden y seleccione la opción No mostrar subtotales en el diseño de la tabla dinámica

  • Section Name
  • Rule ID
  • Configure Source
  • Configure Destination
  • Service
  • Port Range Display
  • Applied to
  • Action
  • Direction
clip_image011

Por ultimo, utilice la función buscar y remplazar para eliminar la palabra “default.” que antepone cada security group en la información exportada. De esta manera podrá visualizar mejor la información presentada.

clip_image012

Actualizando vRealize Network Insight 5.x (Online Update)

Antes de comenzar a actualizar la solución es recomendable considerar los siguientes puntos:

  • Después de la actualización, vRealize Network Insight tarda entre 12 y 24 horas en procesar los datos que estaban en proceso durante la operación de actualización y reflejarlos en la interfaz de usuario.
  • vRealize Network Insight no admite rollback ni downgrade del producto por lo que se debe realizar una copia de seguridad antes de continuar con la actualización. Para obtener más información sobre el proceso de backup y restauración ver aquí.
  • En un entorno de clúster, debe realizar la operación de actualización solo en el nodo Platform 1.
  • Después de actualizar a vRealize Network Insight 6.x, algunos de los ID de reglas de firewall pueden cambiar a los nuevos ID devueltos por la API de VMware Cloud on AWS 1.9. Si existe alguna regla de firewall de VMware Cloud on AWS 1.8 adjunta a los flujos:
    • Las reglas de firewall de VMware Cloud on AWS 1.9 correctas o respectivas se adjuntarían inmediatamente después de la actualización para todos los flujos activos.
    • Las reglas de firewall se referirían a reglas inexistentes para los flujos cuyo período de inactividad es mayor a 24 horas antes de actualizar la versión 1.8 a 1.9.
  • La solución debería tener acceso a internet para la descarga de los paquetes necesarios de manera automática. Este acceso a internet puede ser directo o a través de un web proxy.
  • La opción Online Update deberá estar habilitada en Settings | Infrastructure and Support | Overview and Update y deberá existir un paquete disponible para instalar.
  • Asegúrese de tener soporte activo para la solución vRealize Network Insight antes de actualizar.
  • Si va a realizar un Upgrade (cambio a una nueva versión) entonces deberá realizar el upgrade también de la licencia en my.vmware.com.

PROCEDIMIENTO

1. Genere un Snapshot para cada una de la maquinas virtuales que conforman la solución (nodos Platform y Proxies) o asegúrese de tener un backup de cada una de ellas en caso de que algo salga mal.

2. Inicie sesión en vRealize Network Insight como administrador y vaya a Settings | Infrastructure and Support | Overview and Update para revisar la existencia de actualizaciones disponibles.

image

3. Verifique el estado de salud de la infraestructura sea Good.

image

4. Haga clic en el enlace View details frente a la nueva versión de paquete que aparece disponible.

image

5. Revise el numero de compilación de la nueva versión y lea atentamente la información de la ventana emergente. (Opcional) haga clic en View release note para conocer mas acerca de la nueva versión.

image

6. Haga clic en CONTINUE para iniciar el proceso de actualización y espere pacientemente a que todos los pasos finalicen con éxito.

image

7. Cuando aparezca el botón DONE en la parte inferior, sabrá que el proceso de actualización ha terminado. Y podrá hacer clic sobre el para cerrar la ventana emergente e ir a la ventana de inicio de sesión.

image

8. Inicie sesión en la solución vRealize Network Insight como administrador y revise las notas What is New de bienvenida, para familiarizarse con las bondades de la nueva versión. Cierre la ventana emergente haciendo clic en la X.

image

9. Una vez cierre la ventana anterior, aparecerá una notificación para ingresar la licencia asociada a la nueva versión.

Nota: Si únicamente se hace un Update dentro de la misma versión no tendrá que hacer este paso.

image

10. Haga clic en PROCEED para ir automáticamente a la sección License and Usage e ingrese la nueva llave que previamente debió haber actualizado desde el portal de my.vmware.com.

image

11. Verifique que el estado de salud para cada uno de los componentes de la infraestructura continúe en Good, en la sección Settings | Infrastructure and Support | Overview and Updates.

image

12. Por ultimo pero no menos importante, verifique que las fuentes de datos continúen recolectando datos.

image

Identificar el líder en un cluster de NSX-T Manager 3.x

Antes de explicar el sencillo procedimiento para identificar el líder en un clúster, recordemos que un clúster esta formado por un grupo de tres nodos NSX Manager para alta disponibilidad y escalabilidad y que cada NSX Manager appliance tiene incluido los roles de Policy, Manager y Controller.

Podemos construir un clúster de NSX-T Manager de las siguientes dos maneras.

NSX Management Cluster con Dirección IP Virtual

El NSX Management cluster garantiza la alta disponibilidad y es configurado de la siguiente forma:

  • Todos los manager deben estar en la misma subnet.
  • Un nodo Manager es elegido como líder.
  • La IP Virtual del Cluster es unida al manager líder.
  • El trafico NO es balanceado a través de los Managers mientras usa VIP.
  • La IP Virtual del cluster es usada para el trafico destinado a los nodos NSX Manager.
  • El trafico destinado a cualquier Nodo de Transporte usa la IP de management del nodo.
  • Una única dirección IP virtual es usada por los clientes de acceso API y GUI.
image

Cuando se envía una solicitud de usuario a la dirección IP virtual, el manager activo (el líder que tiene la dirección IP virtual adjunta) responde a la solicitud. Si el líder falla los dos managers restantes eligen un nuevo líder y este responderá a las solicitudes enviadas a esa dirección IP virtual.

Las solicitudes de equilibrio de carga y el tráfico no se equilibran entre los administradores mientras se usa VIP.

Si el nodo líder que posee VIP falla, se elige un nuevo líder que envía una solicitud GARP para tomar posesión de la VIP y entonces el nuevo nodo líder recibe todas las nuevas solicitudes de API y UI de los usuarios.

NSX Management Cluster con Load Balancer

Para este caso, un balanceador de carga es el encargado de proveer alta disponibilidad al cluster:

  • Todos los nodos son activos.
  • GUI y API son disponibles en todos los managers.
  • El trafico a la IP Virtual es balanceado a múltiples nodos manager.
  • Los nodos manager pueden estar en diferente subnet.
image

Una vez explicado lo anterior, podría surgir la pregunta -¿Para que querría saber quien es el líder? – pues bien, cuando tenemos un problema con la solución se hace indispensable saber cual de los nodos esta recibiendo las solicitudes de manera que podamos acceder a el a través de la linea de comandos para realizar el debido troubleshooting.

También es útil para la fase de pruebas post implementación (VMware verification workbook) en donde debemos testear la alta disponibilidad y garantizar el correcto funcionamiento del cluster.

PROCEDIMIENTO

1. Inicie sesión SSH hacia la IP Virtual del Cluster con el usuario admin y el password definido en la instalación . Sino tiene habilitado el servicio SSH puede hacer login desde la Consola de la VM en el vCenter.

2. Ejecute el comando get cluster status verbose y observaremos que para cada función del manager tenemos un líder seleccionado.

image

3. Ahora solo debemos buscar debajo de cada función del manager, el líder asociado para cada uno de los servicios de la misma.

En la siguiente grafica se muestra como líder del servicio api para la función HTTPS, al miembro con UUID terminado en 3d60144055b5 que corresponde al FQDN srvctrvmnsxp02.bivcloud.local.

image

Nota: Algunas funciones tendrán mas de un servicio, por lo que tendrán un líder asociado para cada uno.

image

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.

Implementando vRealize Network Insight (vRNI) 5.2

Si bien éste no será un post en el que revelaremos las grandes ventajas y funcionalidades de vRealize Network Insight, si diremos que es una de las herramientas más potentes que existen para lograr una visión 360° de nuestro Centro de Datos, debido a que nos permite recolectar información de lo que pasa con el flujo de información en el mundo virtual, físico e incluso a través de nuestros ambientes multicloud. Para conocer un poco acerca de los beneficios claves de la solución ver aquí.

Sus principales Casos de Uso

  • Planificación de Microsegmentación para los clientes que no conocen el flujo de información en sus aplicaciones.
  • Visibilidad 360° no solo del ambiente virtual sino también de la capa física.
  • Implementación de mejores practicas para NSX en la infraestructura.

Dicho lo anterior, nos concentraremos en la implementación de la solución para un ambiente virtual y para esto debemos tener presente cada uno de los componentes que hacen parte de la solución.

image

PROCEDIMIENTO

Clic en el siguiente video para visualizar el procedimiento de instalación y configuración de vRealize Network Insight 5.2.