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

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). Y verifique que existen los archivos cloudbase-init.conf y cloudbase-init-unattend.conf dentro de la carpeta \conf.

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

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.

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.

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:/.

Realice un despliegue de este blueprint de prueba y debería haberse creado un archivo test.txt en la raíz del disco C:/.

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.

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

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

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, realize 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 8: 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 9: Para garantizar una interpretación correcta de los comandos, incluya siempre el carácter de barra vertical cloudConfig: | como se muestra.

Nota 10: 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 11: 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 12: 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 13: 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.

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

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 (vLCM) 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 : irpaclyvm-vra-it-01.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 vra-01)

4. Inicie sesión en el nodo de vRA que reporta vLCM con la herramienta WINSCP y cargue el archivo del paso anterior “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

Ejemplo: Nodo vRA 01

Ejemplo: Nodo vRA 02

Ejemplo: Nodo vRA 03

Nota: Helm es un administrador de paquetes para Kubernetes y se utiliza para empaquetar, configurar e implementar aplicaciones y servicios en clústeres de Kubernetes.

7. Vuelva a la interfaz de vLCM, 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 mostrarse como Completed.

Referencia

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

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.

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 en un único despliegue para todas las VMs o en 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.

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.