Actualizar vRealize Automation (vRA) 8.x

Continuando con esta serie de posts, hemos llegado por fin a la actualización de los appliances de vRealize Automation. De nuevo tendremos una serie de prerrequisitos que verificar, pero si ha seguido esta serie de publicaciones no debería tener ningún problema.

Antes de comenzar es importante aclarar que si esta realizando una actualización de la solución vRealize Automation 8.x, debería seguir esta serie de posts en el siguiente orden.

1  Crear Backup para la solución de vRealize Automation

2. Actualizar vRealize Suite Lifecycle Manager (vRSLCM) 8.x

3. Configurar Binarios en vRealize Suite Lifecycle Manager (vRSLCM)

4. Actualizar VMware Identity Manager

5. Actualizar vRealize Automation 8.x

PRERREQUISITOS

  • Asegúrese de haber actualizado las versiones anteriores de vRealize Suite Lifecycle Manager a la última. Para obtener más información sobre la actualización de su vRealize suite Lifecycle Manager.
  • Asegúrese de haber actualizado la versión anterior de VMware Identity Manager a 3.3.2 o posterior. Para obtener más información sobre la actualización de VMware Identity Manager.
  • Verifique que ya haya instalado vRealize Automation 8.0, 8.0.1, 8.1, 8.2 u 8.3.
  • Realice el mapeo de los binarios de vRealize Automation desde el recurso el repositorio local, My VMware o NFS. 
  • Aumente la CPU, la memoria y el almacenamiento según los requisitos del sistema de vRealize Automation 8.4. Para obtener más información, consulte Requisitos de hardware en vRealize Automation 8.4 Reference Architecture.

PROCEDIMIENTO

1. En la interface de vLCM -> Lifecycle Operations, haga clic en Manage Environments.

2. Navegue hasta la instancia en donde se encuentra vRealize Automation. Para este caso es vRA LAB.

3. Haga clic en VIEW DETAILS y haga clic en el botón TRIGGER INVENTORY SYNC antes de actualizar.

4. Y después en SUMBIT para forzar la sincronización del inventario.

Nota 1: A veces, puede haber una desviación o un cambio en el entorno fuera de Lifecycle Manager y para que Lifecycle Manager conozca el estado actual del sistema, el inventario debe estar actualizado.

El resultado del Request debería ser Completed.

5. Una vez hecha la sincronización del inventario, vuelva a la instancia de vRA y haga clic en UPGRADE.

6. Clic en el botón PROCEED.

7. Seleccione el tipo de vRealize Suite LCM Repository, solo si ha asignado el mapa binario ISO, o puede seleccionar Repository URL con una URL de repositorio de actualización privada.

Para este caso seleccionaremos la opción vRealize Suite LCM Repository y luego haga clic en NEXT.

Nota 2: De manera opcional puede hacer clic en el botón VIEW COMPATIBILITY MATRIX para verificar la compatibilidad de la nueva versión con las soluciones existentes. Se requiere acceso a internet en la IP de vRA para esta acción.

8. En la sección de Snapshot hace click en NEXT

9. Haga clic en RUN PRECHECK.

10. Lea los comentario y marque el check «I took care of the manual steps above and am ready to proceed» para habilitar el botón RUN PRECHECK.

10. Clic en RUN PRECHECK una vez mas y espere a que termine la validación.

Nota 3: El Pre-Check valida los siguientes criterios:

  • Si las versiones de origen de vRealize Automation son 8.0.0 u 8.0.1, asegúrese de seguir los pasos que se indican en el artículo 78325 de KB antes de actualizar para restaurar las cuentas raíz caducadas.
  • SSH habilitado: verifica que SSH para el usuario root esté habilitado.
  • Verificación de versión: verifica si la versión de destino seleccionada para la actualización es compatible con la versión actual de vRealize Automation .
  • Espacio en disco en la partición de registro raíz, datos y servicios: verifica si la cantidad necesaria de espacio libre en disco está disponible en la partición de registro raíz, datos y servicios.
  • Comprobación de CPU y memoria: verifica si la cantidad necesaria, por ejemplo, 12 recursos de CPU y 42 GB de memoria disponibles en cada nodo de vRealize Automation antes de la actualización.
  • Verificación de existencia de propiedades de vCenter: verifica si los detalles de vCenter están presentes como parte de cada nodo en el inventario de Lifecycle Manager. Dado que se toma una instantánea durante el proceso de actualización, es importante tener los detalles correctos de vCenter dentro del inventario de Lifecycle Manager.
  • Verificación de recuperación de ID de referencia de objeto administrado de máquinas virtuales de vRealize Automation : verifica si el ID de referencia de objeto administrado de la máquina virtual se puede recuperar de los detalles disponibles en el inventario de Lifecycle Manager. Esto es necesario a medida que realiza operaciones relacionadas con snapshots en las máquinas virtuales, encontrando la máquina virtual usando las mismas.

11. Haga clic en NEXT

12. Después clic en SUBMIT y espere a que el proceso de actualización termine. Sea paciente, este proceso puede tardar mas de dos hora.

Nota 4: Si durante el proceso de actualización obtiene el siguiente error en el request. Lo invito a leer el post Solucionando error: vRA First boot check on failed on host.

Si el proceso de actualización ha terminado de manera satisfactoria el resultado del Request debería ser Completed.

13. En la interface de vLCM -> Lifecycle Operations, haga clic en Manage Environments y navegue hasta la instancia en donde se encuentra vRealize Automation. Para este caso es vRA LAB. Verifique la versión del producto al lado del nombre vRealize Automation. Para este caso es 8.6.0.

14. Inicie sesión en la URL del Tenant en vRA y verifique el correcto funcionamiento de la solución.

Nota 5: En este punto puede comenzar su proceso de validación de toda su plataforma y una vez considere que todo esta funcionando correctamente proceda a eliminar los snapshots para cada una de la maquinas virtuales involucradas en el proceso de actualización de vRealize Automation 8.x.

Referencias

https://docs.vmware.com/en/VMware-vRealize-Suite-Lifecycle-Manager/8.6/com.vmware.vrsuite.lcm.8.6.doc/GUID-62A2C4A9-98BF-44A5-9C23-950016A615EA.html

ATENCIÓN!!!

TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.

Solucionando error: vRA First boot check on failed on host

En esta oportunidad estaremos revisando la solución al error LCMVRAVACONFIG590060, que podría llegar a ocurrir durante el proceso de actualización de la solución vRealize Automation (vRA) 8.x. Cabe anotar que este error se produjo después de que vRealize Lifecycle Manager (vRSLCM) había marcado el pre check como exitoso. Pero bueno, cosas extrañas pueden ocurrir.

El detalle del error básicamente contienen lo siguiente:

com.vmware.vrealize.lcm.common.exception.EngineException: vRA First boot check on failed on host : vra01.lab.local. Run command 'vracli status first-boot' to find first boot status        at com.vmware.vrealize.lcm.plugin.core.vra80.task.VraVaPreUpgradeTask.execute(VraVaPreUpgradeTask.java:111)        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)

La solución a este problema es bastante sencilla y únicamente requiere seguir el procedimiento a continuación.

PROCEDIMIENTO

1. Inicie sesión ssh en el nodo que reporta el error en vLCM y ejecute el siguiente comando

vracli status first-boot

Si la salida del comando anterior es Error: Cannot connect to Tiller, continúe con los siguientes pasos.

2. Descargue el archivo 2672731-add-tiller-proxy.tar desde los adjuntos del KB81815.

3. Tome un snapshot al nodo de vRA reportado por vLCM (en este caso el nodo vra01)

4. Inicie sesión en el nodo de vRA que reporta vLCM con la herramienta WINSCP y cargue el archivo descargado "2672731-add-tiller-proxy.tar.gz" en la ruta "/root".

5. Vuelva a la sesión SSH del nodo de vRA (en este caso nodo vra-01) y ejecute el siguiente comando

tar -xvf 2672731-add-tiller-proxy.tar.gz && chmod a+x 2672731-add-tiller-proxy.sh && ./2672731-add-tiller-proxy.sh && rm 2672731-add-tiller-proxy.*

6. Inicie sesión SSH en cada uno de los demás nodos de vRA y ejecute el siguiente comando para verificar que se puede acceder a helm desde todos los nodos de vRA

helm ls

Nodo vRA 01

Nodo vRA 02

Nodo vRA 03

7. Vuelva a la interfaz de vRSLCM, en el request fallido haga clic en RETRY y después en SUBMIT.

8. Al final el proceso de actualización de vRA debería ser exitoso y el resultado del Request debería ser Completed.

Referencia

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

ATENCIÓN!!!

TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO TEMPORAL, UTILIZADO PARA FINES DE ESTUDIO.

Instalar Cloud-Init en Templates usadas por vRealize Automation 8.x

Después de haber leído unos cuantos artículos y haber realizado algunas pruebas de cara a cumplir con los requerimientos del cliente, he decidido crear este post debido a que el tema es un poco confuso. Pero en este blog trataremos de compilar la información de las referencias adjuntas y explicar todo lo que necesita saber acerca de Cloud-Init y su funcionamiento a través de los Cloud Templates (blueprints) de Cloud Assembly.

Como es costumbre comencemos con un poco de teoría…

Cloud-Init es la inicialización automatizada de OpenStack de una nueva instancia, la cual es una tarea que debe dividirse entre la infraestructura de la nube y el sistema operativo invitado. OpenStack ™ proporciona los metadatos necesarios a través de HTTP o ConfigDrive y Cloud-Init se encarga de configurar la instancia en Linux.

Sin embargo, ¿qué pasaría si necesitara hacer lo mismo, pero en un sistema operativo Windows®?

Cloudbase-Init™ es el equivalente de Windows del proyecto Cloud-Init utilizado en la mayoría de las imágenes de OpenStack Linux. Cuando se implementa como un servicio en Windows, Cloudbase-Init se encarga de todas las acciones de inicialización del invitado: expansión del volumen del disco, creación de usuarios, generación de contraseñas, ejecución de scripts personalizados de PowerShell, CMD y Bash, plantillas de Heat, configuración de comunicación remota de PowerShell y mucho más.

Aunque había opciones limitadas para la inicialización de invitados hasta hace poco, ahora puede estar seguro. Cloudbase-Init es el equivalente en Windows de Cloud-Init: un proyecto de código abierto que trae todas las funciones manejadas en Linux, a Windows.

Para hacer uso de Cloud-Init en los Cloud Templates (blueprints) de Cloud Assembly podemos agregar una sección cloudConfig al código del blueprint, en la que podemos agregar comandos de inicialización de máquina que se ejecutan en el momento de la implementación.

cloudConfig: cloudConfig es el código YAML usado en los blueprints de VMware que envía instrucciones a Cloud-Init través de la unidad de CD-ROM en la plantilla de la máquina virtual.

Que pueden hacer los comandos de cloudConfig?

Ejecutar comandos de inicialización para automatizar la aplicación de configuraciones en el momento de la creación de la instancia, por lo que podemos personalizar usuarios, permisos, instalaciones o cualquier otra operación basada en comandos. Ejemplos incluyen:

  • Establecer un nombre de host (hostname).
  • Generación y configuración de claves privadas SSH.
  • Instalar paquetes de software.

Dónde se pueden agregar los comandos de cloudConfig?

Puede agregar una sección cloudConfig al código de Cloud Template (blueprint) como se muestra en el siguiente código. Básicamente como una propiedad del componente máquina virtual.

Pero también puede agregarse en la configuración de Image Mapping. Cuando se configura la infraestructura, específicamente al crear Image Mappings tenemos la opción de agregar comandos cloud-init en el botón EDIT bajo la opción Cloud Configuration.

De esta manera, todos los blueprints que hacen referencia a la imagen de origen (Image Mapping) obtienen la misma inicialización.

Es posible que tenga un Image Mapping y blueprint donde ambos contienen comandos de inicialización. En este caso, en el momento del despliegue, los comandos se fusionan y Cloud Assembly ejecuta los comandos consolidados.

Por otra parte, cuando el mismo comando aparece en ambos lugares (en el blueprint y en el Image Mapping) pero incluye diferentes parámetros, solo se ejecuta el comando definido en el Image Mapping debido a que estos comandos tienen prioridad sobre los comandos del Cloud Template (blueprint).

Haga clic en el enlace para obtener más información sobre Image Mappings en vRealize Automation Cloud.

Ejemplos de comandos de cloudConfig

La siguiente sección de ejemplo cloudConfig se toma del código del blueprint del WordPress casos de uso para el servidor MySQL basado en Linux.

Cómo se forman los comandos de cloudConfig?

Lo primero que debemos tener presentes es que Linux cloud-init y Windows Cloudbase-init no comparten la misma sintaxis. Una sección cloudConfig para un sistema operativo no funcionará en una imagen de máquina de otro sistema operativo.

  • Linux: Los comandos de inicialización siguen el estándar open cloud-init.
  • Windows: Los comandos de inicialización utilizan Cloudbase-init.

Cómo inicializar automáticamente una máquina en un Cloud Template (blueprint) de vRealize Automation Cloud Assembly?

Puede aplicar la inicialización de la máquina en vRealize Automation Cloud Assembly ejecutando comandos directamente o, si se implementa en Cloud Zones basadas en vSphere, puede hacerlo a través de los Customization Specification de vSphere. (Ver mas).

  • Comandos: Una sección cloudConfig en el código de su Cloud Template (blueprint) contiene los comandos que desea ejecutar.
  • Customization Specification (Especificaciones de personalización): Una propiedad en el código del Cloud Template (blueprint) hace referencia a un Customization Specification de vSphere por su nombre (el nombre del custom Spec).

PREPARACION DE TEMPLATES

Ahora que ya conocemos que es Cloud-Init, Cloudbase-Init, cloudConfig y como funcionan; veamos como es el importante proceso de preparación de la plantillas en vSphere tanto para Windows como para Linux. Ver mas (Opcional).

Preparación de Templates Windows

1. Descargue el instalador del agente (version estable) desde el sitio oficial de descarga de Cloudbase.

2. Prepare la maquina con todo lo que necesita a nivel de sistema operativo para tener una plantilla funcional (actualizaciones, configuración de discos, instalación de agente de monitoreo, antivirus, etc).

3. Copie el instalador dentro de la VM que será la plantilla para los despliegues desde vRealize Automation.

4. Ejecute el instalador y haga clic en Next.

5. Acepte los términos de la licencia y luego clic en Next.

6. Tome nota de la ruta de instalación por Default, la va a necesitar mas adelante. Después clic en Next.

7. Cambie el Username default de Admin a Administrator y marque la opción Run Cloudbase-init service as LocalSystem. Luego clic en Next.

Nota 1: Si el usuario de administrador local no es Administrator recomiendo renombrarlo en el sistema operativo. De lo contrario en el campo Username indique el usuario de administrador local que tenga en su ambiente.

8. Clic en Install para inicial la instalación.

9. Cuando termine la instalación NO haga clic en Finish. Por el contrario vaya a la ruta donde instalo el programa dependiendo a su version de sistema operativo. (en este caso C:\Program Files\Cloudbase Solutions\Cloudbase-Init\conf). Y verifique que existen los archivos cloudbase-init.conf y cloudbase-init-unattend.conf dentro de la carpeta.

10. Utilice cualquier herramienta para editar como administrador el archivo cloudbase-init-unattend.conf y cambie el valor de metadata_services por el siguiente:

metadata_services=cloudbaseinit.metadata.services.ovfservice.OvfService

11. Guarde los cambios y después cierre el archivo cloudbase-init-unattend.conf.

12. Utilice cualquier herramienta para editar como administrador el archivo cloudbase-init.conf que se encuentra en la misma carpeta. En este caso fijaremos los valores de first_logon_behaviour, metadata_services y plugins. Para esto agregue las siguiente lineas al final del archivo.

first_logon_behaviour=always

metadata_services=cloudbaseinit.metadata.services.ovfservice.OvfService

plugins=cloudbaseinit.plugins.windows.createuser.CreateUserPlugin,cloudbaseinit.plugins.windows.setuserpassword.SetUserPasswordPlugin,cloudbaseinit.plugins.common.sshpublickeys.SetUserSSHPublicKeysPlugin,cloudbaseinit.plugins.common.userdata.UserDataPlugin

Nota 2: Configure el valor first_logo_behavior de acuerdo a sus necesidades. En este caso puntual no requerimos que el password de administrador sea cambiado después del despliegue de las VMs. first_logo_behavior puede tener los valores clear_text_injected_only, no, always. Para mayor información ver aquí o aquí.

13. Guarde los cambios y después cierre el archivo cloudbase-init.conf.

14. Vuelva a la vista del asistente de instalación y haga clic en Finish sin marcar ninguna opción y luego apague la VM.

Nota 3: VMware ha visto casos en los que la ejecución de Sysprep impide que funcionen los despliegues de las imagenes.

Durante el deploy, vRealize Automation Cloud Assembly aplica una especificación de personalización (Customization Specification) generada dinámicamente, que desconecta la interfaz de red. El estado de Sysprep pendiente en la imagen puede hacer que falle el Customization Specification de vSphere y dejar el despliegue desconectado.

Por esta razón, si va a utilizar Customization Specification de vSphere deje las opciones de Sysprep desactivadas al crear la imagen (recomendado). Por el contrario si va realizar el Sysprep desde cloudbase-init entonces marque las dos opciones antes de finalizar la instalación.

15. (Opcional Recomendado) Apague la maquina virtual, haga clic con el botón derecho en editar la configuración, cambie la unidad de CD/DVD 1 a Client Device con el Device Mode en Passthrough CD-ROM. Ver más aquí.

16. Convierta la maquina virtual en Template en el inventario de vCenter Server.

17. En este punto ya podrá configurar el Image Mapping en Cloud Assembly para usar esta plantilla (sino sabe como hacerlo vea How to add image mapping in vRealize Automation to access common operating systems).

Nota 4: La siguiente tabla explica un poco las entradas realizadas durante la instalación

Ejemplo de utilización en Cloud Template (blueprint) con imagen Windows

Para verificar el funcionamiento de los comandos cloudbase-init enviados a través del cloudConfig desde el Cloud Template, recomiendo crear un Cloud Template (bueprint) básico que cree un archivo test.txt en la raíz de disco C:/. Para probar otros comandos puede ver el ejemplo que se encuentra acá o ver muchos mas ejemplos en la pagina oficial de cloud-init aquí.

Realice un despliegue de este blueprint de prueba y debería haberse creado dos archivos test.txt y test1.txt en la raíz del disco C:/. Como puede notar en el blueprint (Cloud Template) el archivo test.txt fue creado desde cloud cloudConfig desde donde se le indicó su contenido, mientras el archivo test1.txt fue creado como producto de la ejecución de comandos "echo" dentro de la maquina virtual.

Nota 5: Si todo va bien hasta aquí, puede comenzar a diseñar sus Cloud Templates (blueprints) mas complejos. Utilice siempre la propiedad customizationSpec: [nombre del Customization Specification file de vSphere] si desea realizar el Sysprep desde vSphere. Por otra parte sino tiene un Custom Spec creado en su ambiente, no se preocupe, cree uno siguiendo las instrucciones de acá.

Actualización 30/11/2021

He detectado que con la instalación recomendada por VMware y la documentación oficial de cloudbase-init, genera comportamientos erráticos cuando utilizamos customization specification file de vSphere para customizar la VM. Por suerte un Blogger nos ha dado la solución (ver mas aquí), que básicamente consiste en cambiar el inicio del servicio cloudbase-init en la VM template, de Automatic a Automatic (Delayed Start) con el fin que el servicio se inicie después que el servicio de VMtools se haya iniciado. De esta manera, garantizamos que la personalización realizada por el Customization Specification file configurado en vSphere ya haya terminado y haya reiniciado la VM. 

Una manera que me gusta usar para detectar si cloudbase-init y cloudConfig están haciendo bien su trabajo, es colocar en la lista de comandos runcmd, algún comando que nos devuelva la hora en un archivo de texto.

Así, cuando se realicen nuestros despliegues desde vRA podremos verificar al interior de la VM la hora exacta en la cual se ejecutaron los comandos. Es importante hacer una revisión aquí, que los comandos se hayan ejecutado a una hora de inicio después del evento Customization of VM XXXX succededed.

En el ejemplo, hemos creado un Cloud Template (Blueprint) que crea un script test.ps1 que genera un archivo de salida output.txt. Estos archivos se crean al mismo tiempo, sin embargo dentro del script existe un sleep de 10 min y después actualiza el contenido del archivo output.txt. Aquí podemos comprobar que los archivos se crearon a la 08:53 PM, aproximadamente 2 min después de que terminó el evento de vSphere que indica que la customization finalizó satisfactoriamente (08:51:43 PM).

Ahora vemos que los archivos output se actualizaron por ultima vez 10 min después (09:04 PM) lo que indica que el script se ejecuto completamente, de acuerdo a lo programado.

Preparación de Template RedHat/Centos/Ubuntu

Al desplegar maquinas basadas en Linux desde vRealize Automation, que incluyen comandos cloud-init, se recomienda personalizar la imagen para evitar conflictos entre cloud-init y custom specification. Esto debido a que pueden existir diseños que no funcionen correctamente y podrían producir algunos de los siguientes resultados no deseados. (tomado de vSphere static IP address assignment in Cloud Assembly cloud templates):

  • El código de cloud-init no contiene comandos de asignación de red y la propiedad customizeGuestOs es false.
    Ni los Comandos de inicialización (cloud-init) ni el Customization Spec están presentes para configurar los ajustes de red.
  • El código de cloud-init no contiene comandos de asignación de red y la propiedad ovfProperties está establecida.
    Los comandos de inicialización (cloud-init) no están presentes, pero ovfProperties bloquea el Customization Spec.
  • El código de cloud-init contiene comandos de asignación de red y la propiedad customizeGuestOs falta o está configurada como true.
    La aplicación de Customization Spec (vSphere) entra en conflicto con los comandos de inicialización (cloud-init).

Por suerte, alguien ya se tomó el trabajo de crear unos scripts para la preparación de maquinas RedHat, CentOs y Ubuntu que nos ayudan a evitar esos comportamientos inesperados cuando combinamos Custom Spec y cloud-init.

De esta manera la preparación de los templates con cloud-init para este tipo de sistemas operativos se resume en la ejecución del script correspondiente.

1. Descargue los scripts de preparación del siguiente repositorio externo.

Nota 6: Hay dos archivos para cada una de las distribuciones de Linux, los que tienen un myblog al final del nombre del archivo usan un enfoque de cron job que se explica en este blog y el que no lo tiene, usa un servicio runonce personalizado que creamos en lugar de usar un cron job. Ambos funcionan, pero al final estos son dos enfoques diferentes, puede usar el que prefiera. Personalmente recomiendo utilizar el que usa el servicio runonce (sin «myblog» al final del nombre del archivo).

2. Cargue el script a la ruta /tmp del servidor Linux que utilizará como Template para vRealize Automation.

Si utiliza una herramienta como WinSCP. Suba el archivo utilizando la opción de texto plano, para evitar que se cambie el formato del mismo.

3. Verifique el formato del archivo desde una ventana de Terminal dentro del OS. Para esto ejecute uno de los siguientes comando según corresponda con el sistema operativo invitado.

vi /tmp/build-centos-rhel-vra8-template.sh

ó

vi /tmp/build-ubuntu-vra8-template.sh

4. Escriba :set ff? y enter para verificar el formato del archivo cargado.

Si la salida del comando anterior es fileformat=dos entonces deberá ejecutar el siguiente comando para convertirlo a formato UNIX, de lo contrario no podrá ejecutar el script.

5. Escriba ahora :set ff=unix y enter para cambiar el formato del archivo.

6. Guarde los cambio ejecutando :wq

7.  Tómese un tiempo para inspeccionar el script y cambiar el usuario cloudadmin por administrator o root (dependiendo de su configuración).

8.  Comente la ultima línea para evitar que la maquina se apague de manera automática y guarde los cambios. Esta línea la ejecutaremos de forma manual cuando termine la ejecución del script.

9. Cambie los permisos del archivo ejecutando uno de los siguiente comandos (dependiendo de su OS).

chmod +x  /tmp/build-centos-rhel-vra8-template.sh 

ó

chmod +x /tmp/build-ubuntu-vra8-template.sh

10. Importante: Verifique que el servidor tenga salida a internet y alcance los repositorio de actualización.

11. Pruebe el comando yum install -y cloud-init, si funciona correctamente entonces podemos ejecutamos el script con el siguiente comando dependiendo de OS.

 ./tmp/build-centos-rhel-vra8-template.sh 

ó

./tmp/build-ubuntu-vra8-template.sh

Nota 7: Antes de apagar la VM verifique el estado de la VM con el comando cloud-init status, si la salida no es done, elimine el archivo /etc/cloud/cloud-init.disabled como se indica aquí, reinicie la VM y revise de nuevo que la salida del comando cloud-init status sea done.

12. Si la instalación finaliza correctamente, ejecute el apagado de la maquina con el siguiente comando.

shutdown -h now

13. (Opcional Recomendado). Haga clic con el botón derecho en editar la configuración, cambie la unidad de CD/DVD 1 a Client Device con el Device Mode en Passthrough CD-ROM.

14. Convierta la maquina virtual en Template en el inventario de vCenter Server.

15. En este punto ya podrá configurar el Image Mapping en Cloud Assembly para usar esta plantilla (sino sabe como hacerlo vea How to add image mapping in vRealize Automation to access common operating systems).

Ejemplo de utilización en Cloud Template (blueprint) con imagen RedHat/CentOS/Ubuntu

Para verificar el funcionamiento de los comandos cloud-init enviados a través del cloudConfig desde el Cloud Template, recomiendo crear un Cloud Template básico que cree un archivo test.txt en el repositorio /tmp/test.

Realice un despliegue de este blueprint de prueba y debería haberse creado un archivo Test.txt en el repositorio /tmp/test.

Nota 8: En las maquina Linux los comandos enviados desde cloudConfig pueden visualizarse en el archivo

/var/lib/cloud/instance/cloud-config.txt dentro del OS. Esto es útil cuando necesitamos hacer troubleshooting y necesitamos validar si los comandos están entrando a la maquina.

Al abrir el contenido del archivo podemos visualizar todos los comandos que hemos configurado en la sección cloudConfig del Cloud Template (blueprint) de vRealize Automation.

Actualización 03/12/2021

La versión de Ubuntu 20.4 ya tiene instalado el cloud-init por default pero sino simplemente instálelo de la siguiente forma.

Ejecute los siguientes comandos:

apt-get install cloud-init
cat /etc/cloud/ds-identify.cfg, la salida debería ser policy: enabled

systemctl enable cloud-init-local.service
systemctl start cloud-init-local.service

systemctl enable cloud-init.service
systemctl start cloud-init.service
systemctl enable cloud-config.service
systemctl start cloud-config.service
systemctl enable cloud-final.service
systemctl start cloud-final.service
cloud-init status
cloud-init clean

Si los comando se ejecutan correctamente, realice el apagado de la maquina con el siguiente comando. shutdown -h now

Por otra parte, si como mencionamos antes el cloud-init ya esta instalado en SO, tener en cuenta que por defecto el cloud-init viene «desconfigurado». De manera que para esta version (Ubuntu 20.04) es importante verificar que tengamos configurada la fuente de datos (Data Source) correcta.

Para configurarlo correctamente de debemos ejecutar el comando:

dpkg-reconfigure cloud-init

Preferiblemente marcar únicamente OVF que será el que utilizaremos para las plantillas de vRA. Sin embargo, en este caso vemos que existe una con el nombre VMware, entonces marcaremos las dos (OVF, VMware).

Nota 9: La fuente de datos OVF (Open Virtualization Format) proporciona una fuente de datos para leer datos desde un ISO de transporte OVF. 

Para verificar que el cambio a tomado efecto podemos ejecutar el comando

cat /etc/cloud/cloud.cfg.d/90_dpkg.cfg

Si por alguna razón todo lo anterior esta bien configurado pero aún no le funcionan los comandos de cloudConfig, no se preocupe en seguida tendrá la solución.

Vamos a hacer un procedimiento sencillo pero que me costó encontrar unas 8 horas. Y que probablemente sino lo hacemos no va a funcionar en esta versión de Ubuntu, debido a que por defecto, el instalador del SO deja deshabilitadas los Data Sources. (Agradecimientos a este foro por existir!)

Ejecute el siguiente comando y verifique si aparece la línea datasource_list [None], si es así. Eureka! Hemos encontrado el problema.

cat /etc/cloud/cloud.cfg.d/99-installer.cfg

Solo basta con editar esa línea y definir la fuente de datos [OVF], para esto podemos utilizar el siguiente comando

vi /etc/cloud/cloud.cfg.d/99-installer.cfg

Para guardar solo presione ESC, y despues :wq!

Después, para verificar que el cambio se ha aplicado podemos ejecutar de nuevo el comando

cat /etc/cloud/cloud.cfg.d/99-installer.cfg

Por último, ejecutaremos los comandos que ya conocemos antes de apagar la VM.

Ahora después de hacer un despliegue del Cloud Template (Blueprint) del ejemplo anterior (Ejemplo de utilización en Cloud Template (blueprint) con imagen RedHat/CentOS/Ubuntu) podremos ver que se ha creado la carpeta test y el archivo Test.txt dentro de la carpeta. Esto quiere decir que ya se están ejecutando los comandos cloudConfig enviados desde el Cloud Template de vRealize Automation.

Preparación de Template SUSE

Llegamos a la ultima plantilla que veremos en este blog, y es tal vez de la que menos información encontramos en la web. Bueno, que realmente funcione sin darnos tantos dolores de cabeza.

El procedimiento de preparación de se resume en los siguientes pasos.

1. Verifique que la maquina virtual que será plantilla para vRealize Automation tenga salida a internet para alcanzar los repositorios de descarga de SUSE.

2. Instalar dependencias recomendadas en el enlace de IBM.

Para instalar los paquetes en SUSE ejecute los siguientes comandos como root.

zypper install xfsprogs
zypper install python3-oauthlib
zypper install python3-Jinja2
zypper install python3-PyYAML
zypper install python3-distro
zypper install python3-jsonpatch
zypper install python3-jsonschema
zypper install python3-PrettyTable
zypper install python3-requests
zypper install python3-configobj

Nota 8: Si por alguna razón falla la instalación de los paquetes python3-jsonpatch y
python3-jsonschema entonces intente instalarlos manualmente con ayuda de la documentación oficial de SUSE.

Ejemplo para SUSE SLE 15.3 (tomado de la documentación oficial python-jsonpatch from devel:languages:python)

En el ejemplo anterior encontramos el repositorio para instalar python-jsonpatch y con el pudimos instalar python3-jsonpatch y python3-jsonschema. No se preocupe si su version de SUSE no es la misma, solo es cuestión de buscar rápidamente en la web el comando correcto para su version.

3. Una vez instalados todos lo paquetes listados anteriormente. Proceda a instalar el cloud-init como lo indica la documentación oficial de SUSE cloud-init from Cloud:Tools. De nuevo puede apoyarse de la web para buscar el comando correcto de acuerdo a su version de SUSE.

Ejemplo para SUSE 15:

4. Una vez terminada la instalación del componente cloud-init en el Template. Ejecute los siguientes comandos:

systemctl enable cloud-init-local.service
systemctl enable cloud-init.service
systemctl enable cloud-config.service
systemctl enable cloud-final.service
systemctl start cloud-init.service
systemctl start cloud-init-local.service
systemctl start cloud-config.service
systemctl start cloud-final.service
cloud-init status
cloud-init clean

5. Si los comando se ejecutan correctamente, realice el apagado de la maquina con el siguiente comando.

shutdown -h now

6. (Opcional Recomendado). Haga clic con el botón derecho en editar la configuración, cambie la unidad de CD/DVD 1 a Client Device con el Device Mode en Passthrough CD-ROM.

7. Convierta la maquina virtual en Template en el inventario de vCenter Server.

8. En este punto ya podrá configurar el Image Mapping en Cloud Assembly para usar esta plantilla (sino sabe como hacerlo vea How to add image mapping in vRealize Automation to access common operating systems).

Ejemplo de utilización en Cloud Template (blueprint) con imagen SUSE

De manera similar a como lo hemos hecho en los casos anteriores, para verificar el funcionamiento de los comandos cloud-init enviados a través del cloudConfig desde el Cloud Template, recomiendo crear un Cloud Template básico que cree un archivo test.txt en el repositorio /tmp/test.

Realice un despliegue de este blueprint de prueba y debería haberse creado un archivo test.txt en el repositorio /tmp/test.

De igual manera a como lo hicimos en el Template RedHat, en SUSE podemos verificar los comando que fueron enviados desde cloudConfig a la nueva instancia de maquina, en el archivo /var/lib/cloud/instance/cloud-config.txt

Nota 10: Puede hacer uso de los logs de cloud-init para hace troubleshooting de ser necesario.

Ejemplo: Visualizacion de Logs.

NOTAS ADICIONALES PARA TODOS LOS TEMPLATES

Nota 11: Para garantizar una interpretación correcta de los comandos, incluya siempre el carácter de barra vertical cloudConfig: | como se muestra.

Nota 12: Si una secuencia de comandos de cloud-init se comporta de manera inesperada, verifique la salida de la consola en /var/log/cloud-init-output.log cuando haga troubleshooting. Para obtener más información sobre cloud-init, puede consultar la documentación oficial de cloud-init .

Nota 13: Cuando despliegue en vSphere, proceda con cuidado si intenta combinar los comandos integrados de cloudConfig con la utilización de Customization Specification de vSphere. No son formalmente compatibles y pueden producir resultados inconsistentes o no deseados cuando se usan juntos. Sin embargo, puede utilizarlos juntos de forma segura siempre y cuando NO utilice comandos de inicialización para la red en cloudConfig ya que esta acción la realiza el Customization Specification de vSphere. Recomiendo leer el siguiente enlace y revisar los ejemplos allí descritos para entender cómo interactúan los comandos y los Custom Specification. Revise los ejemplos para Asignación de direcciones IP estáticas en Cloud Templates de Cloud Assembly .

Nota 14: Es posible examinar los comandos que son enviados a través de cloudConfig desde vRealize Automation. Para esto siga los siguientes pasos.

1. Abra el Deployment en vRealize Automation y después Clic en Topology.

2. En el panel del lado derecho expanda la sección > Cloud Config.

3. Revise los comando que fueron enviados a la instancia de maquina virtual durante el despliegue.

Nota 15: Puede configurar la propiedad remoteAccess en el código del Cloud Template (blueprint) para crear un usuario adicional (diferente al administrator o root) para el acceso después del despliegue de la maquina virtual. Por supuesto deberá utilizar la propiedad de cloudConfig para enviar comandos cloud-init (Linux) o cloudbase-init (Windows) y de esta manera otorgar los permisos necesarios dentro de la maquina virtual. Por defecto tendrá permisos de acceso remoto. (Para mayor información ver aquí).

Nota 14: Los blueprint a partir de la version de vRealize Automation 8.2 han sido renombrados como Cloud Templates.

OPCIONAL

Por ultimo y como paso adicional a la preparación de las plantillas de cualquier sistema operativo. Solo si evidencia algún conflicto entre Custom Spec y cloud-Init, aunque no debería; pero si es el caso siga las recomendaciones descritas en How to make a Cloud Assembly deployment wait for initialization, para hacer que la inicialización de la maquina desplegada por Cloud Assembly espere un tiempo antes de comenzar.

ATENCIÓN!!!

TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO TEMPORAL, UTILIZADO PARA FINES DE ESTUDIO.

Referencias

  1. Cloudbase-Init
  2. Cloud-Init
  3. Configuration commands in Cloud Assembly templates
  4. vSphere static IP address assignment in Cloud Assembly cloud templates
  5. How to perform Windows guest customization
  6. How to automatically initialize a machine in a vRealize Automation Cloud Assembly template
  7. Creating and Managing Customization Specifications
  8. How to create an initializable Windows image for vSphere
  9. Cloudbase-init Configuration options reference
  10. Windows guest initialization with Cloudbase-Init in vCenter
  11. Logging for cloud-init in redhat OS
  12. Add repository and install manually python-jsonpatch for SUSE SLE 15
  13. Preparing a vSphere VM to Receive a cloud-init Script (KB 76346)
  14. Installing and configuring cloud-init on SLES
  15. cloud-init from Cloud:Tools project
  16. python-jsonpatch from devel:languages:python project
  17. Prepare a SLES or openSUSE Leap virtual machine for Azure
  18. How to add image mapping in vRealize Automation to access common operating systems
  19. How to enable remote access in vRealize Automation Cloud Assembly templates
  20. Supply a username and password to vRealize Automation Cloud Assembly
  21. How to Use Remote Access Authentication in your Cloud Assembly Deployments
  22. Recomendation Passtrough Mode CD/DVD
  23. How to include Cloudbase-Init commands in a cloud template
  24. Delayed deployment in Cloud Assembly
  25. Installing and configuring cloud-init on Ubuntu 20.04
  26. Building a vRealize Automation Cloud Ready Ubuntu Template for vSphere
  27. Cloud-Init Boot Stages

Importando VMs a vRealize Automation 7.x

Una de las tareas que deberíamos incluir en nuestros planes de trabajo, luego de la instalación, configuración y prueba de nuestro ambiente Cloud Privado con vRealize Automation, es la importación de las VMs que ya existían en el ambiente virtual y que podrían comenzar a ser administradas desde el portal de VRA, con el fin de mantener unificada la interfaz de gestión de las VMs desde el lado del usuario. Esto ayudará a limitar el acceso de administradores al vCenter debido a que acciones como (reinicio, apagado, snaphots, reconfiguración, etc.) podrán ser realizadas por el usuario desde el portal del VRA.

¿CÓMO FUNCIONA?

Existe una funcionalidad llamada Bulk Imports, que permite importar, actualizar y migrar máquinas a vRealize Automation. Esta funcionalidad crea un archivo .CSV que contiene datos de la VM como reservation, storage path, blueprint, owner, y custom properties.

Bulk Imports admite las siguientes tareas administrativas:

  • Importar una o más máquinas virtuales no administradas para que puedan administrarse en el entorno de vRealize Automation .
  • Realizar un cambio global en una propiedad de máquina virtual, como una ruta de almacenamiento.
  • Migrar una máquina virtual de un entorno de vRealize Automation a otro.

Nota: Solo vCloud Director y vSphere son compatibles con Bulk Import. Establecer el filtro en otro tipo de endpoint no genera datos en el archivo CSV.

PRERREQUISITOS

  • Inicie sesión en vRealize Automation como fabric administrator y como business group manager.
  • Si está importando máquinas virtuales que usan direcciones IP estáticas, prepare un pool de direcciones configurado correctamente. Para obtener más información, consulte Crear un perfil de red.
  • Cree un Blueprint para la máquina virtual que planea importar. Este plan debe ser publicado y tener un owner válido para ser Entitled a ese propietario.

PROCEDIMIENTO

Clic en el siguiente video, o clic aquí para ver directamente en YouTube.

Configurar notificaciones en vRealize Automation 7.x con cuenta Gmail

¿Por qué utilizar una cuenta externa?

En la mayoría de las ocasiones, cuando tenemos un ambiente de Laboratorio, no tenemos los recursos disponibles en la infraestructura para crear nuestro propio servidor de correo, ya sea por capacidad de procesamiento, memoria, storage, licencias, experiencia en la configuración del mismo o simplemente no contamos con el tiempo suficiente para hacerlo.

Es por esta razón, que en este post explicaremos el procedimiento para emplear una cuenta de Gmail (100% gratis) como Email Server, Inbound (usada para responder a las notificaciones y completar tareas) y Outbound (usada para enviar notificaciones basadas en eventos del sistema), de la solución vRealize Automation 7.x y de esta manera poder notificar a los administradores acerca de lo que sucede en la infraestructura.

Nota 1: No se recomienda utilizar cuentas de correo externo para ambientes productivos.

PROCEDIMIENTO

Dicho lo anterior, veamos cada uno de los pasos involucrado en la configuración de las notificaciones para vRealize Automation, empleando una cuenta Gmail.

1. Cree una cuenta Gmail o utilice una cuenta de correo existente.

Para efectos de laboratorio he decido crear una cuenta nueva únicamente para este fin. Para crear una cuenta nueva haga clic aquí. Una vez creada, inicie sesión en su cuenta recientemente creada y siga las instrucciones del asistente de configuración de Gmail.

image

2.  Habilite en la cuenta el acceso IMAP (Internet Message Access Protocol)

El Protocolo de Acceso a Mensajes de Internet (IMAP), es un protocolo de aplicación que permite el acceder los mensajes almacenados en un servidor de Internet y permite tener acceso al correo electrónico desde cualquier equipo que tenga una conexión a Internet.

Por defecto, la cuenta Gmail esta configurada con IMAP deshabilitado por lo que será necesario habilitarlo como sigue:

a) En su computadora, abra Gmail.
b) En la esquina superior derecha, haga clic en Configuración Configuración.
c) Haga clic en Configuración.
d) Haga clic en la pestaña Reenvío y correo POP/IMAP.
e) En la sección «Acceso IMAP», haga clic en Habilitar IMAP.
f) Por ultimo, haga clic en Guardar cambios.

image

Nota 2: Tenga en cuenta que para configurar el cliente IMAP vamos necesitar mas adelante los siguientes datos propios de Gmail y de la cuenta asociada.

image

3. Active el acceso de apps menos seguras en la cuenta Gmail.

Si una app o un sitio no cumplen con los estándares de seguridad, es posible que Google bloquee a las personas que intenten acceder a su cuenta desde ellos. Las apps menos seguras pueden permitir que los hackers accedan a la cuenta con más facilidad. Es importante bloquear los accesos desde ellas con el fin de mantener su cuenta protegida.

Dicho lo anterior, la cuenta Gmail por defecto es configurada para denegar el acceso de app menos seguras. Sin embargo, para este fin, debe ser habilitado como sigue:

Nota 3: No realice este procedimiento en su cuenta de correo electrónico personal.

a) En su computadora, abra Gmail.
b) En la esquina superior derecha, haga clic en Google Appsimage.
c) Haga clic en Cuenta.
d) Haga clic en Seguridad y baje hasta la sección Acceso de Apps menos seguras.
e) Haga clic en Activar el acceso (no se recomienda).
f) Por ultimo, haga clic en el botón Permitir el acceso de apps menos seguras.

image
image

4. Configure Email Servers en vRealize Automation appliance

Una vez realizado lo anterior, podrá configurar los Email Servers Inbound y Outbound en vRealize Automation 7.x como sigue:

a) Inicie sesión en el Tenant deseado https://IPóHostname_vRA/vcac/org/nombre_tenant con un usuario  Tenant Administrator. (si es el default tenant entonces https://IPóHostname_vRA/vcac/ ).
b) Haga clic en la pestaña Administration.
c) Haga clic en la sección Notifications y luego clic en Email Servers.
d) Clic en New  (Add) y seleccione Email – Inbound.
e) Configure el servidor IMAP con los datos suministrados en la Nota 2 y los datos de la cuenta de correo electrónico creada en el paso 1.
f) Haga click en el botón TEST CONNECTION. Si la conexión es exitosa (image Connection tested successfully) haga clic en OK.

image

Nota 4: El test debería pasar, si no es así verifique la contraseña. Si la contraseña es correcta y recibe el mensaje image Invalid username or password, revise los pasos anteriores para la configuración de IMAP y Acceso de app menos seguras.

g) Clic en New  (Add) y seleccione Email – Outbound.
h) Configure el servidor SMTP con los datos suministrados en la Nota 2 y los datos de la cuenta de correo electrónico creada en el paso 1.
i) Haga click en el botón TEST CONNECTION. Si la conexión es exitosa (image Connection tested successfully) haga clic en OK.

image

Nota 5: El test debería pasar, si no es así verifique la contraseña. Si la contraseña es correcta y recibe el mensaje image Invalid username or password, revise los pasos anteriores para la configuración Acceso de app menos seguras. Adicionalmente, si no ha permitido el Acceso de app menos seguras, recibirá un correo con una advertencia de inicio de sesión.

image

Por ultimo, al finalizar la configuración de Email Servers, la vista deberá lucir de la siguiente forma.

image

5.  Seleccione los escenarios de notificación

En la pestaña Administration | Notifications | Scenarios, seleccione de la lista, la fuente de notificación que desea Activar o Suspender mediante los botones imageo image.

clip_image001

6. Configure una dirección de correo electrónico a los usuarios

vRealize Automation enviará las notificaciones a las cuentas de correo electrónico configurada para cada uno de los usuarios. De esta manera si se han configurado usuarios de dominio, esta configuración deberá realizarse en el Active Directory.

image

Para visualizar el cambio realizado en el AD desde vRealize Automation será necesario forzar una sincronización, para esto debemos realizar los siguientes pasos:

a) Inicie sesión en el Tenant deseado https://IPóHostname_vRA/vcac/org/nombre_tenant con un usuario  Tenant Administrator. (si es el default tenant entonces https://IPóHostname_vRA/vcac/ ).
b) Haga clic en Administration | Directories.
c) Seleccione el Active Directory y clic en Sync Now.

Si por el contrario, esta usando únicamente usuarios locales (no recomendado), defina una cuenta de correo electrónico para los usuarios locales del Tenant, iniciando sesión como System Administrator (Administrator) en https://IPóHostname_vRA/vcac/ .

a) Vaya a la Sección Tenants.
b) Seleccione el nombre del Tenant y clic en editar.
c) Seleccione la pestaña Local Users.
d) Seleccione el usuario local y defina una cuenta de correo electrónico.

image

7. (Opcional) Cree o edite un Custom Group

Los Custom Group proporcionan un control más granular sobre el acceso dentro de vRealize Automation, que los Business Groups que corresponden a una línea de negocio, departamento u otra unidad organizativa; debido a que los Custom Groups permite centralizar la asignación de roles dentro del Tenant.

Para efectos de laboratorio, se ha creado un Custom group LAB-vRA-Admins para agrupar todos los usuarios de dominio con permiso de administrador, y se le han otorgado todos los roles (esto es valido para entorno de laboratorio), para un ambiente productivo deberá segregarse cada uno de los roles. Cree un Custom Group siguiendo los pasos descritos aquí.

clip_image001[5]

En los miembros asignados al Custom Group se encuentra el usuario de dominio Diego Tunubalá (diego.tunubala@lab.local) que como observamos muestra el email diego.tunubala@xxxx.com configurado en el Active Directory.

image

8. (Opcional) Cree o edite un Business Group

Los Business Groups se utilizan para asociar un conjunto de servicios y recursos a un conjunto de usuarios. Estos grupos a menudo corresponden a una línea de negocio, departamento u otra unidad organizativa. Puede crear un Business Group para poder configurar reservas y autorizar a los usuarios a aprovisionar elementos del catálogo de servicios para los miembros del grupo empresarial. Cree un Custom Business Group siguiendo los pasos descritos aquí.

En nuestro ambiente de laboratorio se ha creado el Business Group LAB-BS-Group01 cuyos miembros son el Custom Group LAB-vRA-Admins, con el Role Manager asignado, y el grupo de dominio gvarusers@lab.local con el role de usuario.

clip_image001[7]

Con el fin de verificar las notificaciones tanto del lado del administrador como del lado del usuario, adicionaremos el usuario pruebavra@lab.local al group de dominio gvarusers@lab.local en el Active Directory.

Nota 6: Al usuario pruebavra@lab.local le fue configurado una cuenta de correo electrónico del mismo modo a lo explicado en el paso 6, pero con una cuenta de correo diferente.

9. Verificar la llegada de notificaciones

La verificación de las notificaciones es una tarea muy sencilla, ya que basta con iniciar sesión en el Tenant con un usuario autorizado y realizar la solicitud de un ítem del catalogo. Para este prueba utilizaremos el usuario pruebavra@lab.local y realizaremos una solicitud de despliegue.

image

Debido a que la solicitud de ítems del catalogo tiene configurada un Approval Policy, la solicitud quedará a la espera de la respuesta del usuario Aprobador configurado en el Tenant (para este caso de laboratorio, es el mismo Tenant Administrator) y será enviada una notificación.

image

En este punto podemos pasar a verificar los mensajes enviados en la cuenta de Gmail configurada y observaremos que desde la cuenta se ha enviado un mail tanto al usuario Administrador del Tenant como al usuario solicitante.

image

En la cuenta de correo asociada al Administrador del Tenant diego.tunubala (mismo usuario aprobador), llegará un correo con dos acciones disponibles Approve y Reject. Que permitirán Aceptar o rechazar el despliegue y enviar un comentario al usuario.

image

Mientras tanto en la cuenta de correo asociada al usuario de prueba pruebavra llegará una notificación indicando que la solicitud ha sido presentada.

image

10. Aprobar solicitud a través de email.

Debido a que el usuario de dominio diego.tunubala@lab.local tienen configurado el role de Aprobador, al hacer clic en el enlace Approve, nos dará la opción de enviar un mensaje adjunto a la aprobación que será enviada a vRealize Automation de manera inmediata sin necesidad de entrar al portal de vRA. Lo mismo sucede si elegimos la opción Reject.

image

Una vez aprobada la solicitud, el usuario será notificado mediante un correo con el status Approved.

image

Después de la aprobación de la solicitud el flujo de despliegue continuará, finalizando nuevamente con una notificación vía correo electrónico al usuario, esta vez con la información de la VM o servicio solicitado desde el catálogo.

image
image