En el post anterior explicamos como realizar este mismo procedimiento con Gmail y ahora es el turno de explicarlo con Outlook que de igual forma debido a las mejoras en seguridad aplicadas por Microsoft se hace necesario utilizar ahora la funcionalidad llamada Contraseñas de Aplicaciones que como su nombre lo indica es una contraseña que generamos para permitir el acceso desde nuestro aplicativos a nuestra cuenta Outlook.
Dicho lo anterior, en esta oportunidad vamos a explicar entonces cómo podemos utilizar una cuenta de Outlook como SMTP Server de la solución VMware Aria Automation (antes vRealize Automation) para habilitar las notificaciones del servicio de Service Broker.
PROCEDIMIENTO
Ingresar a la cuenta Outlook que utilizaremos para ser configurada como SMTP server de Aria Automation. Sino tiene una puede crearla desde la pagina oficial de Outlook
Una vez dentro de la cuenta vamos a la parte superior derecha en donde aparece el nombre de usuario de la cuenta, hacemos click y después click en My Profile*
Después debemos hacer click en Security para posteriormente hacer click sobre el link Get Started, que se encuentra dentro de la sección Advanced security options
Si la cuenta es nueva, Microsoft nos solicita configurar una opción de seguridad para ayudarnos a proteger nuestra cuenta y para esto tenemos dos opciones An alternate email address o A phone number. En este caso he seleccionado la primera y he agregado una cuenta de gmail. Ahora hacemos click en Next
Ingresamos el código que nos debió haber llegado a nuestra cuenta de correo o teléfono especificada y después click en Next
A continuación debemos ingresar el password de la cuenta debido a que estamos accediendo a información sensible y después click en Sign In
Debemos ahora verificar nuestra identidad en la cuanta de correo que agregamos en el paso anterior haciendo clic en el nombre de la cuenta
Ingresamos la cuenta de correo completa que se muestra enmascarada para verificar que es nuestra cuenta y que conocemos los datos. Recordar que este caso configuramos una cuenta alterna de gmail, razón por la cual esta validación la vamos a hacer desde la cuenta de gmail. Estos pasos de verificación puede ser diferentes si seleccionamos A phone number en el paso anterior. Click en Send code para recibir el código en la cuenta de email especificada.
Ingresamos el código de verificación que nos llegó y click en Verify
En este punto podemos hacer click en el link No gracias para no configurar una App que nos permita ingresar sin password.
Ahora, un paso muy importante para poder utilizar las Contraseñas de aplicación es que debemos activar la Verificación en 2 Pasos haciendo click en Turn On que se encuentra bajo la sección Additional security
Leemos detenidamente en que consiste la verificación en 2 pasos y click en Next
Debemos ahora definir una opción para verificar nuestra identidad, en este caso al igual que lo como lo hicimos en Gmail seleccionaremos A phone number e ingresamos el numero de teléfono
Ingresamos el código que nos debió haber llegado a nuestro teléfono y después click en Next
15. Si el código es correcto deberíamos ver que la Verificación en 2 pasos ha sido activada y un código has sido generado para efectos de recuperación. Guarde este código en un lugar seguro y no lo comparta. Click en Next
16. En Set up your smart phone with an app password click en Next
En Some other apps and devices need an app password too click en Finish
Ahora podemos ver que la verificación en 2 pasos ha sido activada para esta cuenta
En la pestaña donde estamos debemos hacer el down para ubicar la sección App passwords (Contraseñas de Aplicaciones) y hacemos click en el link Create a new app password
Ingresamos la contraseña de la cuenta outlook para poder ingresar a esta opción
A continuación una Contraseña de Aplicaciones se ha creado y este será el password que debemos utilizar para la integración con Aria Automation o cualquier solución de VMware. Click en Done para terminar
Vamos ahora a realizar la configuración en el servicio de Service Broker de Aria Automation, para esto hacemos login en la solución y en el menu principal hacemos click en **Service Broker
Después vamos a Content & Policies -> Notifications -> Email Server. Llenamos los datos como sigue y después click TEST CONNECTION. Si la conexión ha sido exitosa, entonces click en CREATE
Los datos importantes aquí son los siguientes:
Server Name: smtp-mail.outlook.com Sender Name: Alias para el emisor de la notificación Sender Address: vmware.test.lab01@outlook.com (a diferencia de la configuración con Gmail esta si debe ser una cuenta válida) User Name: vmware.test.lab01@outlook.com (cuenta de email creada) Password:jhsdcpumigurzfgg (La contraseña de aplicaciones creada en el paso anterior) Connection Security: STARTLS Server port: 587 Trust certificates presented by the host: Yes
Nota: La ruta para llegar hasta Notifications -> Email Server podría ser diferente dependiendo de la version.
Nota: Al hacer click sobre el botón TEST CONNECTION deberíamos ver un banner color verde con el mensaje Email server configuration validated successfully
Como resultado del TEST CONNECTION recibiremos ademas un correo electrónico en la cuenta email configurada para el usuario con el cual estamos haciendo el TEST CONNECTION. Es decir, en este caso estamos logueados en Aria Automation con el usuario configadmin que es un usuario local de Workspace One Access, el cual tiene en su atributo email la cuenta de correo electrónico creada anteriormente.
(Opcional) Para validar o cambiar la cuenta de correo electrónico configurada en un usuario local de Workspace One Access debemos hacer login en la solución con un usuario administrador y después navegar hasta Administration Console
Una vez dentro, podemos navegar hasta la pestaña User & Groups para ver la información de cada uno de los usuarios
Nota: Aquí podemos ver algunos usuarios que son locales (System Domain) y algunos que son de dominio (corp.local). Para los usuarios locales podemos editar el email simplemente haciendo click sobre el usuario y cambiando el valor del campo email.
Nota: En este caso hemos utilizado la cuenta de correo que hemos creado en Outlook, pero podría ser cualquiera.
Por otro lado, para los usuario que son sincronizaos desde el dominio, este campo debe ser editado directamente el Active Directory
Una vez realizados los pasos anteriores, podemos aprovechar las notificaciones que envía Aria Automation Service Broker a los usuario para cada uno de los escenarios indicados en la documentación oficial Send email notifications to Automation Service Broker users
TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.
¡IMPORTANTE! He migrado blog del dominio nachoaprendevirtualizacion.com a nachoaprendeit.com. Si te ha servido este artículo deja tu buen Like y compártelo con tus colegas, estas aciones me ayudarán a optimizar los motores de búsqueda para llegar a más personas.
En un post anterior habíamos explicado como realizar este mismo procedimiento. Sin embargo, con las mejoras en seguridad aplicadas por Gmail la opción para permitir Aplicaciones Menos Seguras ya no esta disponible. En consecuencia Gmail ha habilitado una opción para utilizar el SMTP utilizando ahora una funcionalidad llamada Contraseñas de Aplicaciones que como su nombre lo indica es una contraseña que generamos para permitir el acceso desde nuestro aplicativos a nuestra cuenta Gmail.
Dicho lo anterior, en esta oportunidad vamos a explicar entonces cómo podemos utilizar una cuenta de Gmail como SMTP Server de la solución VMware Aria Automation (antes vRealize Automation 8.x) para habilitar las notificaciones del servicio Service Broker.
PROCEDIMIENTO
Ingresar a la cuenta Gmail que utilizaremos para ser configurada como SMTP server de Aria Automation. Sino tiene una puede crearla desde la pagina oficial de Gmail
Una vez dentro de la cuenta vamos a la parte superior derecha en donde aparece el nombre de usuario de la cuenta, hacemos click y después click en Administrar tu Cuenta de Google
Una vez dentro, debemos hacer click en Seguridad para posteriormente hacer click sobre el símbolo > frente a Verificación en 2 pasos, que se encuentra dentro de la sección Cómo acceder a Google
Leemos detenidamente en que consiste la Verificacion en 2 pasos y hacemos click en el botón Comenzar
Definimos un numero de teléfono para la verificación y escogemos la opción que deseemos para recibir los códigos. En este caso dejare la default Mensaje de texto y click en Siguiente
Ingresamos el código que nos debió haber llegado a nuestro celular y después click en Siguiente
Si el código es correcto deberíamos tener el siguiente mensaje y hacemos click en el botón Activar
Una vez activada la Verificacion en 2 pasos debe verse de la siguiente manera.
Hacemos nuevamente click sobre el símbolo > frente a Verificacion en 2 pasos e ingresamos la contraseña de la cuenta Gmail para poder ingresar a esta opción
10. Una vez autenticados vamos a hacer scroll down hasta encontrase la sección Contraseñas de aplicaciones y hacemos click sobre el símbolo > para proceder a configurar la contraseña de aplicación que usaremos en VMware Aria Automation durante la configuración del SMTP server
Nota: Actualmente vemos que aparece Ninguna bajo Contraseñas de aplicaciones
Dentro de Contraseñas de Aplicaciones lo único que tenemos que hacer es crear un nombre para nuestra aplicación (App Name) y después click en Crear. Para este caso hemos definido el nombre VMware Aria Automation
La Contraseña de Aplicación se mostrara en pantalla y debemos copiarla guardarla en un lugar seguro antes de finalizar haciendo click en el botón Listo
Nota: La contraseña generada en este caso es rxgm yubk ktop vxhk y debe ser guardada respetando los espacio que ésta incluye.
Vemos que ahora aparece listada nuestra nueva aplicación creada y podemos volver a atrás si lo deseamos. Hasta aquí es todo lo que teníamos que hacer en la cuenta de Gmail.
Vamos ahora a realizar la configuración en el servicio de Service Broker de Aria Automation, para esto hacemos login en la solución y en el menu principal hacemos click en **Service Broker
Después vamos a Content & Policies -> Notifications -> Email Server. Llenamos los datos como sigue y después click TEST CONNECTION. Si la conexión ha sido exitosa, entonces click en CREATE
Los datos importantes aquí son los siguientes:
Server Name: smtp.gmail.com Sender Name: Alias para el emisor de la notificación Sender Address: Es la cuenta de email utilizada para enviar las notificaciones. No necesariamente debe ser una cuenta real User Name: email.test.lab01@gmail.com (cuenta de email creada) Password:rxgm yubk ktop vxhk (La contraseña de aplicaciones creada en el paso anterior respetando los espacios) Connection Security: SSL/TLS (puede ser también STARTLS, por el contrario la opción None no funcionará) Server port: Aparece automáticamente dependiendo del protocolo de comunicación seleccionado en Connection Security Trust certificates presented by the host: Yes
Nota: La ruta para llegar hasta Notifications -> Email Server podría ser diferente dependiendo de la version.
Nota: Al hacer click sobre el botón TEST CONNECTION deberíamos ver un banner color verde con el mensaje Email server configuration validated successfully
Como resultado del TEST CONNECTION recibiremos ademas un correo electrónico en la cuenta email configurada para el usuario con el cual estamos haciendo el TEST CONNECTION. Es decir, en este caso estamos logueados en Aria Automation con el usuario configadmin que es un usuario local de Workspace One Access, el cual tiene en su atributo email la cuenta de correo electrónico creada anteriormente.
(Opcional) Para validar o cambiar la cuenta de correo electrónico configurada en un usuario local de Workspace One Access debemos hacer login en la solución con un usuario administrador y despues navegar hasta Administration Console
Una vez dentro, podemos navegar hasta la pestaña User & Groups para ver la información de cada uno de los usuarios
Nota: Aquí podemos ver algunos usuarios que son locales (System Domain) y algunos que son de dominio (corp.local). Para los usuarios locales podemos editar el email simplemente haciendo click sobre el usuario y cambiando el valor del campo email.
Nota: En este caso hemos utilizado la cuenta de correo que hemos creado en Gmail, pero podría ser cualquiera.
Por otro lado, para los usuario que son sincronizaos desde el dominio, este campo debe ser editado directamente el Active Directory
Una vez realizados los pasos anteriores, podemos aprovechar las notificaciones que envía Aria Automation Service Broker a los usuario para cada uno de los escenarios indicados en la documentación oficial Send email notifications to Automation Service Broker users
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.
¡IMPORTANTE! He migrado blog del dominio nachoaprendevirtualizacion.com a nachoaprendeit.com. Si te ha servido este artículo deja tu buen Like y compártelo con tus colegas, estas aciones me ayudarán a optimizar los motores de búsqueda para llegar a más personas.
Una de las operaciones de día 2 que mas terror nos daba hace unos años o posiblemente con la que mas sufríamos, fue el reemplazo de certificados para las soluciones VMware. Los que tuvimos que luchar esa batalla, recordaremos lo tedioso que era tener que reemplazar cada uno de los certificados de una solución de forma manual y encontrarse errores diferentes conforme avanzábamos.
Por suerte, esto ha cambiado y ahora Aria Suite Lifecycle (antes vRealize Suite Lifecycle Manager) nos ofrece una forma fácil, rápida y segura de reemplazar los certificados, por lo menos de los productos asociados a la Aria Suite (antes vRealize Suite) y por supuesto que sean gestionados desde Aria Suite Lifecycle.
En el procedimiento a continuación estaremos explicando cómo reemplazar los certificado autofirmados por certificados customizados, es decir certificados firmados por una entidad certificadora del cliente o CA Enterprise. El cambio de un certificado de un autofirmado por otro igualmente autofirmado, es similar al proceso explicado en este post y simplemente costa de los siguientes dos pasos por lo que no representa mayor tiene mayor dificultad.
Crear un certificado en el servicio de locker de vRealize Suite lifecycle Manager
Reemplazar el certificado viejo por el nuevo
Reemplazo de Certificado autofirmado por certificados customizados
Lo primero que debemos tener presente es que el reemplazo de certificados autofirmados por certificados customizados, incluye la participación del equipo de seguridad del cliente, quien será el encargado de proveernos los certificados validos para nuestros productos.
Una manera fácil de hacer esto es solicitar al cliente el/los certificados en extensión .pem y de esta manera evitamos tener que generar un Certificate Signing Request (CSR), que si bien podemos generarlos desde vRealize Suite Lifecycle Manager, pues lo único que haría es agregarnos un paso mas en el proceso. Por esta razón, recomiendo solicitar al cliente crear directamente los certificados en su herramienta y exportarlo en el formato indicado y con el Key sin cifrar.
Una vez nos han enviado el/los certificados podemos continuar con los siguientes pasos:
1. Verificar que los certificados los entreguen en .pem y que estén bien generados. Para esto podemos abrir el archivo .pem con un editor de texto y verificar que tenga la siguiente estructura.
2. Algunas veces nos envían el certificado con el key cifrado, entonces debemos pedir que nos envíen el Key sin clave. Y Rearmar el .pem en otro archivo pero esta vez utilizando el Key sin cifrar.
Recordemos que la sección asociada al Key debería contener los siguiente:
—–BEGIN RSA PRIVATE KEY—–
—–END RSA PRIVATE KEY—–
3. Una vez hemos verificado la estructura del certificado podemos ir al servicio de Locker de Aria Suite Lifecycle e importarlos en -> Certificates -> Import. En este paso solo debemos hacer click en BROWSER FILE y buscar el archivo .pem que construimos en el paso anterior. Automáticamente los campos Private Key y Certificate Chain serán poblados. Finalizamos el proceso haciedo click en el boton IMPORT
4. Una vez importados se mostraran los detalles del certificado de manera que podremos verificar que los Subject Alternative Name de cada certificado contenga los FQDN de todos los nodos de cada solución incluyendo el FQDN del VIP del balanceador que le corresponda, de ser necesario.
5. Si vamos a reemplazar el certificado de una solucion que se encuentra detrás de un balanceador como por ejemplos VMware Identity Manager (vIDM), ahora llamado Workspace One Access (WS1), debemos primero reemplazar el certificado en el balanceador siguiendo la guía de cada fabricante.
6. Una vez realizado el cambio de certificados en el balanceador, debemos realizar la action Re-trust Load Balancer en el servicio Lifecycle Operations-> Environments -> Para este ejemplo globalenvironment (ambiente asociado a vIDM o WS1).
7. Para efectuar el reemplazo de certificados lo único que debemos hacer es ir al servicio de Lifecycle Operations-> Environments -> click en VIEW DETAILS del ambiente en cuestión (para este caso globalenvironment) -> Click en los tres puntos (…) para listar mas opciones -> Replace Certificate
8. A continuación nos muestra un resumen del certificado actual
9. Hacemos click en NEXT para seleccionar el nuevo certificado (importado) desde la lista desplegable
10. Si el certificado es de una solución como vIDM del cual dependen otros productos, nos mostrará que durante el proceso de cambio de certificados hará un Re-Trust sobre los productos listados allí. Click en NEXT para continuar.
11. A continuación podremos seleccionar si queremos que Aria Suite Lifecycle cree por nosotros un snapshot en la VMs involucradas . Se recomienda esta acción a no ser que ya hayamos tomado un snapshot directamente desde el vCenter. Luego Click en NEXT
12. Para validar que el certificado que vamos a aplicar es correcto, debemos ejecutar un PRECHECK haciendo click en el botón RUN PRECHECK
13. Después de finalizar el PRECHECK podemos ver que nos solicita una acción de aceptar y nos indica que el remplazo de los certificados sobre los balanceadores debe hacerse manual como lo comentamos anteriormente. Procedemos entonces a hacer click en ACEPTAR y después en FINISH
Nota 1: Si por alguna razon, reemplaza el certificado de una solucion de Aria Suite (vRealize Suite) sin haber cambiado el certificado del balanceador recibirá una notificación en el Aria Suite Lifecycle (vRealize Suite Lifecycle Manager) indicándole que debe reemplazar el certificado en el balanceador (Importar el certificado nuevo en NSX-T, NSX-v, F5, o el balanceador que corresponda) siguiendo la guia del fabricante, como comentamos anteriormente.
Nota 2: De igual forma, si se cambia el certificado del balanceador despues de cambiar el certificado de vIDM entonces recibirá una unas notificaciones en Aria Suite Lifecycle indicándole que debe realizar una acción de re-trust en cada una de las soluciones que se encuentren detras de ese balanceador. Comenzando de nuevo por Workspace One Access (WS1A).
Nota 3: Sino hacemos esto vamos a recibir un Bad Gateway al intentar a hacer login en WS1A. Para evitar esto, recomendamos reemplazar el certificado del balanceador en primer lugar como lo hemos mencionado anteriormente
14. Si realizamos el reemplazo del certificado en el balanceador, en primera instancia como lo hemos recomendado, la URL de acceso al WS1 (VIP)después del reemplazo de los certificados del globalenvironment, debería mostrar el sitio como seguro y con los detalles del certificado que hemos importado.
15. Como hemos realizado un cambio que esta por fuera del control de Aria Suite Lifecycle (vRealize Suite Lifecycle Manager) debemos realizar la acción de Re-trust Load Balancer, desde la solucion de Workspace One Access / VMware Identity Manager (globalenvironment) y para esto vamos a Environment -> global environment -> click en los tres puntos (…) para mas opciones y luego click en Re-trust Load Balancer
16. (Opcional) Cuando termine vamos a cada unos de los productos que estaba integrados con vIDM o WS1A, como por ejemplo Aria Operations (antes vRealize Operations Manager), Aria Automation (antes vRealize Automation), Aria Operations for Logs (vRealize Log Insight), etc. En algunas ocasiones podríamos necesitar hacer click Re-Trust with Identity Manager en cada una de las soluciones de Aria Suite (vRealize Suite), aunque este proceso por lo general se hace automático durante el reemplazo de certificados de Workspace One Access (WS1A).
17. El reemplazo de certificados de todas las soluciones de la Aria Suite tienen el mismo procedimiento que hemos mencionado para el Workspace One Access (globalenvironement), razon por la cual no haremos este post mas largo.
Nota 4: Para las soluciones que no están detrás de un balanceador, es claro que podemos hacer directamente el reemplazo de certificados siguiendo los pasos 7-13.
Por ultimo, vamos a realizar el reemplazo de certificados de la solucion Aria Suite Lifecycle (vRealize Suite Lifecycle Manager). El reemplazo de esta solucion no tiene un orden especifico y se puede realizar en primero o ultimo lugar. Vemos entonces los siguientes pasos.
Remplazo de certificados de Aria Suite Lifecycle (vRealize Suite Lifecycle Manager)
1. En el servicio de Locker vamos a crear o importar un certificado para esta solucion. Como ya explicamos como importar un certificado, en este caso generaremos uno nuevo desde la opción -> Certificates -> Add Certificate. Recordar que si lo generamos desde el servicio de Locker, sera entonces un certificado autofirmado o Self-Signed.
2. En Lifecycle Operations click en –> Settings -> Change Certificate
3. Click en el boton REPLACE CERTIFICATE
4. Revisamos los detalles del certificado actual y hacemos click en NEXT
5. Seleccionamos el nuevo certificado, que importamos o generamos en el servicio de Locker y click en NEXT
6. Click en RUN PRECHECK para verificar que todo este bien con el certificado y si todo esta ok, click en FINISH
Nota: Después de un par de minutos, en el servicio de Lifecycle Operations deberíamos ver el Request asociado a este reemplazo de certificados como Completed.
Y podemos validar que el Subject del certificado ahora contienes los datos que configuramos en el nuevo certificado.
Nota 5: (Opcional) Si ha realizado reemplazo de certificados para WS1A antes de cambiar los de Aria Suite Lifecycle entonces realize una acción de RE-REGISTER dentro del servicio de Lifecycle Operations -> Settings -> Authentication Provider. Debería haberse realizado de manera automática, pero si tiene algún problema con la autenticación de usuarios de dominio en la solucion Aria Suite Lifecycle, este paso solucionara el inconveniente.
Si alguna vez te has encontrado con el error que muestro a continuación, no te preocupes!, muy seguramente tu subscripción ha expirado, esto en el caso que no tengas una licencia perpetua por supuesto.
"It appears that your subscription has expired.Your workloads are still available. Contact yourAccount Manager or Customer Success Manager torenew so that you can log in and keep working".
Por otro lado, sino es tu caso pero aún quieres saber como reemplazar la licencia asignada a tu solución de Aria Automation (antes vRealize Automation), continual leyendo el blog.
PROCEDIMIENTO
1. Lo primero, será entonces iniciar sesión en la solución Aria Suite Lifecycle
2. En el servicio Locker > Licenses, verificamos que efectivamente tengamos nuestra licencia en estado Expired. De igual forma, como lo comenté anteriormente, si solo quieres saber como reemplazar la licencia, puedes continuar leyendo los siguientes pasos
3. Sino hemos agregado una licencia de Aria Suite (vRealize Suite) que es la que contiene la solución de Aria Automation (vRealize Automation) debemos hacer click en el botón ADD LICENSE MANUALLY e ingresar un nombre para la Licencia (License Alias) y el License Key. Después Click en VALIDATE y posteriormente ADD
4. Una vez adicionada la licencia de vRealize Suite, debemos ir al servicio de Lifecycle Operations
5. Navegar hasta Environments -> Click en VIEW DETAILS del environment donde tenemos el Aria Automation (vRA), en este caso el ambiente que tiene la solución de Aria Automation es el llamado VRA-LAB
6. Click en los tres punto de la derecha (…) y luego Add License
7. Seleccionamos la nueva licencia en este caso vExpert 2023
8. Seleccionamos la licencia que vamos a retirar, que en este caso la que está en estado expired y click en el botón FINISH
9. El resultado del Request generado debería ser Succesfull
10. Volvemos al ambiente de vRA y verificamos que ahora la licencia ha sido aplicada
11. Por ultimo podemos vovler al servicio de Locker a eliminar las licencias expiradas para mantener nuestro ambiente limpio
12. Una vez reemplazada la licencia podemos ver que nuestra solucion de vRA esta de nuevo operativa
Nota: El procedimiento aplicado en este blog puede ser utilizado para reemplazar la licencia de cualquier solucion de la Aria Suite (Antes vRealize Suite), esto es, Aria Operations (vRealize Operations Manager), Aria Operations for Logs (vRealize Log Insight), Aria Operations for Networks (vRealize Network Insight), etc.
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.
En este blog explicaremos paso a paso cómo crear una notificación por correo electrónico para las VMs desplegadas desde vRA 8.x. Esto debido a que lamentablemente a la fecha de escritura de este blog, no existe esta funcionalidad de manera nativa y el servicio de Service broker esta limitado únicamente a enviar notificaciones para los escenarios indicados en el siguiente enlace de la documentación oficial Send email notifications to Service Broker users.
Agradecimientos a @Sam Perrin, quien ha dado la pauta para esta solución en este blog.
En este caso para suplir esa necesidad de notificación, utilizaremos la funcionalidad de vRealize Orchestrator (vRO) para extender las funcionalidades de vRealize Automation (vRA).
Comenzaremos creando una plantilla muy básica de HTML en cualquier editor de texto, y la guardaremos con el nombre VM-Details y la extensión .html. Esta plantilla será utilizada posteriormente por vRO para presentar los datos de la VM en el contenido del email.
Dejo a continuación el código de la plantilla para que evite la fatiga y pueda simplemente copiar/pegar.
<html>
<body>
<p>=============================================</p>
<p>Please find your VM details below;</p>
<ul>
<li>VM Name = {{vmName}}</li>
<li>IP Address = {{ipAddress}}</li>
<li>Memory = {{memory}}</li>
<li>CPU = {{cpu}}</li>
<li>Guest OS = {{guestOs}}</li>
</ul>
<p>=============================================</p>
</body>
</html>
Posteriormente vamos a iniciar sesión el nuestra solución de vRA y seleccionaremos el servicio de Orchestrator
Ahora dentro de vRO, en el panel de navegación izquierdo debemos ir a la sección Assets -> Resources.
Y bajo la carpeta Resources debemos crear una Carpeta llamada Email-Templates.
Nota 1: Utilice la vista de árbol (Tree View) para crear la carpeta justo debajo de Resources.
Nota 2: Para configurar la vista en modo árbol podemos hacer click en icono enmarcado en la imagen anterior.
Seleccionamos la nueva carpeta creada (Email-Template) y dentro de esta carpeta haremos click en el botón +IMPORT para importar el archivo .html que hemos creado
Una vez hecho lo anterior podemos volver ahora al panel izquierdo de vRO y navegar hasta Library -> Workflows para proceder a crear el nuevo workflow que hará la magia.
Click en +NEW WORLFLOW, definir un nombre en este caso lo llamaremos «Notifications with VM deployed from vRA».
En la pestaña de Schema, dentro del nuevo workflow, agregamos al canvas los siguientes schema elements, Scriptable Task y Workflow element, en el orden indicado a continuación.
Scriptable task
Workflow element
Scriptable task
Workflow element
Comenzaremos editando el primer Scriptable task de izquierda a derecha. Para esto simplemente seleccionamos el schema element dentro del canvas y aparecerá un panel al lado derecho para configurar los parámetros de este elemento.
En la pestana General, bajo la sección Details, podemos cambiar el nombre del Schema element cambiando el texto que esta frente al campo Name. En este caso lo reemplazamos por «Get Resource Name» (sin comillas) y en el campo Description agregamos el siguiente texto «This Scriptable task get the Parameter «resourceName» coming from Compute Post Provisioning event topic in vRA» (sin las comillas).
Ahora debemos expandir la sección de Inputs/Outputs y frente al campo Imputs debemos hacer click en el signo (+) y luego click en Create New para crear un nuevo Input con el nombre inputProperties del tipo Properties.
Luego click en CREATE
De igual forma, pero frente al campo Outputs vamos hacemos click en el signo (+) y luego click en Create New para crear una nueva Variable con el nombre vmResourceName del tipo String.
Y click en CREATE
Debe quedar de la siguiente forma
Ahora en la pestana scripting debemos incluir el siguiente código. Para mayor facilidad simplemente copie/pegue
Pasaremos ahora a editar el siguiente schema element llamado Workflow element. De nuevo al seleccionarlo aparecerá un panel al lado derecho. En la sección Workflow vamos a utilizar uno de los workflows que trae incorporado vRO y que nos servirá para obtener el nombre de la VM. Entonces escribimos en el campo de texto «get virtual machines by name» y seleccionamos de la lista el workflow existente que contiene ese nombre.
Nota 1: Una vez seleccionamos el workflow, podemos notar que el campo name en la sección Details se ha renombrado y ahora este schema element ha tomado el nombre del workflows que hemos seleccionado.
En la sección Workflows de este elemento configuraremos los inputs/outputs que el workflow invocado (Get virtual machines by name) requiere.
Ahora frente al input hacemos click en el campo de texto criteria escribiremos el nombre de la variable creada anteriormente vmResourceName y la seleccionaremos de la lista desplegable.
Seguidamente, frente al output vms hacemos click en el campo de texto y luego click en Create New para crear una nueva Variable con el nombre vmObject del tipo VC:VirtualMachine.
Nota 2: Observe que esta variable será un Array
Estos cambios deberían lucir de la siguiente manera.
Pasaremos al tercer schema element de izquierda a derecha para editarlo. Click en Scriptable task para seleccionarlo.
Lo primero que vamos a hacer, como ya lo sabemos, es editar el Name bajo la sección Details, y lo renombraremos como «Get VM Properties» (sin comillas).
En el campo Description colocaremos lo siguiente «This simple task gets vm properties from vmObjet coming from Get virtual machines by name Workflow».
Ahora debemos expandir la sección de Inputs/Outputs y frente al campo Imputs debemos hacer click en el signo (+) y en el campo de texto escribiremos el nombre de la variable creada anteriormente vmObject y la seleccionaremos de la lista desplegable.
De igual forma, pero frente al campo Outputs debemos hacer click en el signo (+) y luego click en Create New para crear una nueva Output con el nombre emailContent del tipo String.
Y click en CREATE
Repetiremos la acción del paso anterior para crear una salida (output) adicional, click en el signo (+) y luego click en Create New pero creando esta vez será una nueva Variable con el nombre contentEmail del tipo String.
Debe quedar de la siguiente forma
Lo siguiente que debemos hacer, es hacer clic en la pestaña Scripting de este schema element, y agregar el siguiente código. Para evitar la fatiga de nuevo, simplemente copiar/pegar.
/*
- Input: vm [VC:VirtualMachine]
- Output: emailContent [string]
*/
var vm = vmObject[0];
var vmName = vm.name;
var ipAddress = vm.ipAddress;
var memory = vm.memory;
var cpu = vm.cpu;
var guestOs = vm.guestOS;
var htmlTemplate = fetchEmailTemplate("VM-Details.html");
var fieldKeyValues = new Properties();
fieldKeyValues.put("{{vmName}}",vmName);
fieldKeyValues.put("{{ipAddress}}",ipAddress);
fieldKeyValues.put("{{guestOs}}",guestOs);
fieldKeyValues.put("{{cpu}}",cpu);
fieldKeyValues.put("{{memory}}",memory);
for each (field in fieldKeyValues.keys) {
htmlTemplate = updateContent(field,fieldKeyValues.get(field),htmlTemplate);
}
System.debug("==== Email Content ==== \n" + htmlTemplate);
emailContent = htmlTemplate;
contentEmail = emailContent;
function fetchEmailTemplate(elementName) {
var categoryPath = "Email-Templates";
var category = Server.getResourceElementCategoryWithPath(categoryPath);
for each (var resourceElement in category.resourceElements) {
if (resourceElement.name.toLowerCase() === elementName.toLowerCase()) {
var mime = resourceElement.getContentAsMimeAttachment()
return mime.content;
}
}
}
function updateContent(key,value,content) {
content = content.replace(key,value);
return content;
}
En la pestana Scripting de este Schema element, debería verse de la siguiente forma.
Pasamos ahora a editar el ultimo elemento de nuestro workflow. Como ya sabemos simplemente lo seleccionamos y en esta ocasión nuevamente utilizaremos uno de los workflows preconstruidos que trae incorporado vRO.
Entonces bajo la sección Workflow de este schema element, en el campo de texto escribiremos «Send notification (TLSv1.2)» (sin las comillas) y lo seleccionaremos de la lista.
Nota 3: De nuevo, puede notar que al seleccionar el workflow el nombre de este schema element se actualiza con el nombre del workflow que estamos invocando.
Ahora utilizando el procedimiento de crear nueva variables que ya conocemos, debemos crear variables para cada una de los inputs requeridos por este workflow (Send notification (TLSv1.2)).
Configuremos entonces cada una de las entradas del workflow como sigue. Podrá ver al fondo del screenshot como se van poblando cada una de las inputs.
En input content en el campo de texto vamos a escribir el nombre de la variable contentEmail y la seleccionamos de la lista
Por último, para el input useStartTls input crearemos una variable con el value en True.
Después de la creación de cada una de las variables para cada uno de los inputs de este workflow, debería quedar así
Nota 5: Como pudo notar el contenido del email que será enviado por correo, esta definido en el input content el cual obtiene su valor de la variable contentEmail creada en el Scriptable task anterior llamado Get VM Properties.
Al final nuestro workflow personalizado debería quedar con las siguientes Variables.
Y deberíamos tener los siguiente inputs/outputs
Ahora solo queda crear una Extensibility subscription en vRA para que el workflow se lance en el evento Compute Post Provisioning. Para ver mas información acerca de extensibility subscription vea el siguiente enlace Create an extensibility subscription.
Nota 6: Una subscription habilita el uso de acciones o workflows a través de un event topic seleccionado.
Vamos entonces al servicio de Cloud Assembly -> Extensibility -> Subscription y click en +NEW SUBSCRIPTION.
Diligenciamos los datos como se muestra a continuación
Nota 7: Como recomendación y best practice, es importante que se habilite siempre la opción Filter events in topic en la condición de la Subscription, para que se ejecute solo con los blueprints específicos que nosotros definamos. En este caso hemos utilizado el filtro event.data.blueprintId.
Realizamos un despliegue desde el Catalogo de Service Broker y esperamos que termine el despliegue.
Al final del despliegue debería llegarnos una notificación por cada VM desplegada desde vRA
Por ultimo, si queremos revisar la ejecución del Workflow podemos ir al vRealize Orchestrator vRO -> Activity -> Workflow Runs
Y hacer click en cualquiera de los que aparecen listados, en este caso haremos click en el que se ejecutó por ultima vez para verificar el valor de cada una de las Variables.
Con esto terminamos esta entrada, que seguramente nos ayudara a llenar este vacío existente en vRA. Espero sea de gran utilizada.
Esta serie de posts ha sido desarrollada con el fin de dar claridad al proceso involucrado cuando realizamos una actualización de la solución vRealize Automation 8.x, debido a que al enfrentarnos por primera vez, podría ser un poco confuso.
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
Como recomendación o best practice antes de la actualización de cualquier componente de la solución de vRA, necesitaremos garantizar un backup en frio, por esta razón, lo haremos para de todos sus componentes. Esto es, vRealize Suite Lifecycle Manager (vRSLCM), VMware Identity Manager (vIDM) ahora llamado Workspace One Access (WSA), y vRealize Automation (vRA).
Para esto necesitaremos apagar toda la solución pero antes recomiendo seguir las siguientes actividades:
Forzar sincronización de vIDM y vRA y verificar todas las contraseñas de administración de la solución para vRSLCM, vIDM y vRA.
Verificar que todos los servicio están funcionando correctamente
Detener servicios del cluster de vRA por consola (si no existe la opción de Power off desde vRSLCM)
Apagar solución de vRA desde vRSLCM
Apagar solución de vIDM (ahora llamado WSA), desde vRSLCM
Apagar vRSLCM desde el vCenter
Tomar backup de todos los appliances
Tomar Snapshot (Recomendado)
Encender vRSLCM desde el vCenter
Encender solución de vIDM (ahora llamado WSA) desde vRSLCM
Encender solución de vRA desde vRSLCM
Verificar servicios de vRA por consola
PROCEDIMIENTO
Antes de comenzar ser recomienda forzar una sincronización tanto de vRA como de vIDM desde vRSLCM. Para esto vamos al servicio Lifecycle Operations después Home -> Environment -> «Environment que contenga la solución de vRA» y luego clic en VIEW DETAILS.
Después haga clic en TRIGGER INVENTORY SYNC.
El resultado de este request debe ser Completed.
Lo mismo haremos para vIDM. Para esto vamos al servicio Lifecycle Operations de vRSLCM, después Home -> Environment -> globalenvironment y luego clic en VIEW DETAILS. Para este caso el Environment que contiene la solución de vIDM es globalenvironment.
Clic en el icono con los tres puntos (…) al lado derecho de VMware Identity Manager y después haga clic en TRIGGER INVENTORY SYNC.
El resultado de este request debe ser Completed.
IMPORTANTE! Adicionalmente, deberemos testear cada uno de los password documentados para la solución, de tal manera que puedan ser utilizados durante el procedimiento de troubleshooting si algo sale mal.
Esta tarea consiste en iniciar sesión en las consolas graficas con los usuario administradores (admin, configadmin, etc.) e iniciar sesión ssh a cada uno de los appliances con cada uno de los usuarios administradores documentados (root, sshuser, etc.).
Una vez completados los preliminares, podemos comenzar…
1. Verificar que todos los servicio están funcionando correctamente. Si existe algún problema resuélvalo antes de continuar.
Inicie sesión SSH al Primary Node de vRealize Automation y ejecute los siguientes comandos para verificar el estado de los servicios
Nota 1: En un ambiente de vRA en cluster verifique el nodo primario (Primary Node) desde el servicio Lifecycle Operations de vRSLCM haciendo clic Home -> Environment -> «Environment que contenga la solución de vRA» y luego clic en VIEW DETAILS. Para este caso el Environment que contiene la solución de vRA es vRA LAB. El nodo primario estará marcado como Primary.
Nota 2: En este caso de laboratorio solo tenemos un nodo y por lo tanto «vra01» es el Primary.
En la sesión ssh ya establecida ejecute los siguientes comandos para verificar que todo este arriba y no existan problemas antes de apagar.
kubectl get pods --all-namespaces
kubectl -n prelude get pods
2. Si todo esta perfecto con los comandos anteriores, procedemos a apagar solución vRealize Automation desde vRealize Suite Lifecycle Manager. Para esto vamos al servicio Lifecycle Operations de vRSLCM, después Home -> Environment -> «Environment que contenga la solución de vRA» y luego clic en los tres puntos (…) al lado del nombre vRealize Automation y click en Power OFF.
y luego SUBMIT para confirmar.
El request debería mostrarse como Completed.
Nota 3: Si tiene la versión 8.1 o anterior de vRSLCM en su ambiente, esta opción (Power OFF desde vRSLCM) no estará disponible. Así que deberá apagar los appliances desde vCenter manualmente, después de ejecutar el siguiente procedimiento para bajar los servicios de vRA de manera controlada (Starting and stopping vRealize Automation).
4. Continuamos ahora con el apagado de la solución VMware Identity Manager, ahora llamado Workspace One Access (WSA), igualmente usando vRSLCM desde el servicio Lifecycle Operations vamos a la sección Home -> Environments -> «Environment que contenga la solución de VMware Identity Manager» (en este caso globalenvironment).
Clic en el icono con tres puntos (…) al lado derecho del titulo VMware Identity Manager y luego clic en Power OFF.
y luego SUBMIT para confirmar. El resultado del Request debería ser Completed.
Esta acción debería haber apagado los appliances del vIDM de manera controlada. Sin embargo, no esta de mas verificar.
5. Por ultimo procederemos a apagar el Appliance de vRSLCM desde el vCenter, siguiendo el procedimiento tradicional para apagar una VM.
6. En este punto podemos lanzar el Job de backup con la solución que tengamos disponible (Veeam Backup, CommVault, etc), para respaldar los siguientes appliances de las siguientes soluciones:
vRA
vIDM
vRSLCM
7. Nunca sobra un Snapshot (Recomendado) igualmente de los siguientes appliances de las soluciones:
vRA
vIDM
vLCM
8. En este punto procedemos a encender de nuevo las soluciones comenzando por el Appliance de vRSLCM desde el vCenter
9. Una vez ha subido el vRealize Suite Lifecycle manager (vRSLCM), podemos continuar con el encendido de vIDM (ahora llamado WSA) desde vLCM
En vRSLCM desde el servicio Lifecycle Operations vamos a la sección Home -> Environments -> «Environment que contenga la solución de VMware Identity Manager» (en este caso globalenvironment).
Clic en el icono con tres punto al lado derecho del titulo VMware Identity Manager (…) clic en Power ON y después en SUBMIT.
El resultado del Request debería ser Completed.
10. Continuamos encendiendo la solución de vRA desde vRSLCM
En vRSLCM desde el servicio Lifecycle Operations vamos a la sección Home -> Environments -> «Environment que contenga la solución de vRA» (en este caso vRA LAB).
Clic en el icono con tres puntos (…) al lado derecho del titulo vRealize Automation, clic en Power ON y después en SUBMIT.
El resultado del Request debería ser Completed.
Nota 4: Si tiene la versión 8.1 de vRSLCM o inferior en su ambiente, esta opción no estará disponible. Así que deberá encender los appliances desde vCenter. Espere aprox. 25 min a que los appliances inicien completamente.
11. (Opcional) Verifica por consola que los pods de vRA hayan iniciado correctamente (Si tenemos un cluster de vRA ver Nota 1 para identificar Primary Node).
kubectl -n prelude get pods
Por ultimo, solo nos queda ingresar a la URL del Tenant en vRA y verificar que todo se encuentre operando normalmente.
Para continuar viendo esta serie de blogs explicando el proceso de actualización de la solución de vRA lo invito a leer las demás entradas asociadas con la actualización de vRA.
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
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.
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.
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.
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
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.
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).
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:
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.
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.
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.
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=unixy 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.
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
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.
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.
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:
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.
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.
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.
Nacho Aprende IT 