Configurar Binarios en vLCM – Actualizando vRA Parte 3

Continuando con esta serie de posts acerca del proceso de actualización de vRealize Automation 8.x, vamos en esta oportunidad a revisar como configurar los binarios del componente de vRealize Suite Lifecycle Manager.

Como ya conocemos vRealize Suite Lifecycle Manager (vLCM) es una solución que permite controlar el ciclo de vida de los productos vRealize, haciendo mas fácil las tareas de instalación y actualización. Sin embargo, para que esto sea posible es importante conocer que vLCM requiere los conocidos Binarios, que básicamente son los bundles que contienen los archivos de instalación o de actualización de cada solución.

Por suerte, en Lifecycle Manager existe la posibilidad de agregar los Binarios de cada uno de los productos VMware de diferentes formas:

– Local: Permite asignar los archivos binarios descargados localmente a vRealize Suite Lifecycle Manager.

– NFS: Permite asignar a un producto binario descargado desde un repositorio NFS.

– My VMware Download: Permite asignar un producto binario descargado desde el portal My VMware.

En este post estaremos hablando de los dos métodos más utilizados, My VMware Download y Local.

PRERREQUISITOS

Verifique que vLCM tenga suficiente espacio antes de continuar con la descarga de los Binarios. Para esto vaya al servicio de Lifecycle Operations ->Settings -> System Details.

Una vez validado que tenemos suficiente espacio para alojar los Binarios, podemos continuar utilizando alguno de los siguientes métodos. Sino tiene espacio suficiente lo invito a leer el siguiente blog Creciendo almacenamiento de vRealize Lifecycle Manager (vLCM).

OPCIÓN 1. Agregar binarios desde My VMware Download

Para usar un producto binario descargado directamente desde My VMware, verifique que se haya registrado en My VMware, que haya registrado los servicios de My VMware con vRealize Suite Lifecycle Manager y por supuesto, que el Appliance de vLCM tenga salida hacia internet.

Para esto necesitaremos ir al servicio Lifecycle Operations y después a la sección Home -> Settings -> My VMware

Clic en ADD MY VMWARE ACCOUNT  para configurar una cuenta de usuario que cuente con permisos para descargar desde el portal de My VMware.

Nota 1

Para verificar que nuestra cuenta asociada tiene los permisos para realizar la descarga podemos simplemente ir a VMware Downloads, hacer login con el usuario y contraseña e intentar bajar cualquier producto.

Si obtenemos un mensaje como el siguiente y el botón DOWNLOAD NOW no se encuentra disponible, entonces nuestra cuenta NO tiene permisos para descargar y mostrará un error al intentar descargar el Binario.

Por esta razón, recomiendo antes de configurar la cuenta de My VMware en vLCM, verificar que podamos descargar medios. Una cuenta con permisos de descarga debe verse de la siguiente forma, con el botón DOWNLOAD NOW habilitado.

Este sencillo procedimiento nos permitirá validar que la cuenta que se va a configurar en vLCM es apta para descargar los BINARIES de vRealize Lifecycle Manager.

Continuando con la configuración de la cuenta My VMware en vLCM debemos hacer clic en VALIDATE.

Y luego clic en ADD.

En este punto podremos iniciar la configuración de los Binarios en Home -> Settings -> Binary Mapping

Clic en ADD BINARIES y seleccionar My VMware

Clic en el botón DISCOVERY. Para listar todo los Binarios de los productos disponibles y compatibles con la versión de vLCM que tenga en el ambiente.

Para este caso seleccionaremos el paquete de Upgrade de vRealize Automation 8.3 y VMware Identity Manager 3.3.4. Y después clic en ADD.

En este punto se lanzará una tarea de Request y comenzará la descarga. Tenga en cuenta que esta tarea puede demorar un par de minutos.

Nota 2

Si la cuenta configurada no tiene permisos para descargar desde el portal My VMware, en el Request obtendremos el siguiente error:

"Error Code: LCMMYVMWARE60010"
"Failed to get user entitlement accounts from https://my.vmware.com. Please try again after some time"
"Error occurred while downloading product binaries from MyVMware account..."

Generalmente esto ocurre porque la cuenta configurada no tiene permisos para realizar descargas de medios y por esta razón falla.

OPCIÓN 2. Agregar binarios desde repositorio Local

Para mapear un producto binario utilizando el método Local, deberá descargar el bundle de forma manual desde el portal de My VMware.

Para esto vaya al portal de My VMware Downloads e inicie sesión con una cuenta que tenga permisos para descargar.

Clic en View Download Components frente a VMware vRealize Suite.

Y vaya al enlace GO TO DOWNLOAD de cualquiera de los productos que necesita descargar.

Ejemplos

Para el binarios de VMware Identity Manager 3.3.4 debemos seleccionar el identity-manager-3.3.4.0-17498518-updaterepo-lcm.tar.gz y clic en DOWNLOAD NOW.

Para el binarios de vRealize Automation 8.3 debemos seleccionar el Prelude_VA-8.3.0.15014-17551690-updaterepo.iso y clic en DOWNLOAD NOW.

Para el binarios de vRealize Automation 8.3 debemos seleccionar el Prelude_VA-8.3.0.15014-17551690-updaterepo.iso y clic en DOWNLOAD NOW.

Nota 3

Como puede observar el archivo necesario para actualización contendrá un nombre asociado a Update y contendrá un archivo nombrado como XX-XXXXXXXX-updaterepo.

Una vez descargado los bundle podemos ahora mapearlos a vLCM sin necesidad que vLCM tenga acceso a Internet.

Para este ejemplo estaremos utilizado el Binario asociado a vRealize Log Insight 8.3 debido a que ya descargamos los asociados a vRA y vIDM utilizando el modo My VMware Download descrito arriba.

Ahora utilizando la herramienta WinSCP, debemos subir los Binarios al Appliance de vLCM en la ruta /data.

Después en vLCM debemos ir al servicio Lifecycle Operations y hacer clic en Home -> Settings -> Binary Mapping

Clic en ADD BINARIES y seleccionar la opción Local. Después clic en DISCOVER para visualizar el contenido de la carpeta /data.

Seleccionar el Binario asociado a vRealize Log Insight que subimos por WinSCP anteriormente y clic en ADD.

Clic en el enlace Click here para monitorear el request. Al terminar debería mostrar Completed en la columna Request Status.

Por ultimo, podemos verificar en Home -> Settings -> Binary Mapping que el Binario mapeado aparezca ahora disponible.

Referencias

https://docs.vmware.com/en/VMware-vRealize-Suite-Lifecycle-Manager/8.3/com.vmware.vrsuite.lcm.8.3.doc/GUID-2C93EB0A-055C-4897-A764-77FC73EFE992.html

Actualizar vRealize Suite Lifecycle Manager (vLCM) 8.x – Actualizando vRA Parte 2

Continuando con esta seria de posts acerca del proceso de actualización de la solución vRealize Automation 8.x y una vez garantizado el backup en frio explicado en la Parte 1, podemos continuar con la actualización del primer componente de la solución vRA que es vRealize Suite Lifecycle Manager (vLCM).

PRERREQUISITOS

  • Verifique que cumpla con los requisitos del sistema. Consulte Requisitos del sistema.
  • Tome un Snapshot del dispositivo virtual vRealize Suite Lifecycle Manager . Si encuentra algún problema durante la actualización, puede volver a esta instantánea. (Si esta siguiendo esta serie de post omita este paso, porque ya lo hicimos en la Parte 1)
  • Verifique que no haya tareas críticas en curso en vRealize Suite Lifecycle Manager. El proceso de actualización detiene e inicia los servicios de vRealize Suite Lifecycle Manager y reinicia el dispositivo virtual vRealize Suite Lifecycle Manager, lo que podría dañar las tareas en curso.
  • Si está actualizando vRealize Suite Lifecycle Manager a través de una URL de repositorio o un CD-ROM, asegúrese de descargar el binario de actualización de vRealize Suite Lifecycle Manager desde el portal My VMware con anticipación. El nombre del archivo debe ser -VMware-vLCM-Appliance-8.XXXX-XXXXXXXX-updaterepo.iso.

PROCEDIMIENTO

Para comprobar las actualización de vLCM tenemos tres opciones de repositorios. En este post estaremos hablando del Check online  y la opción CD-ROM.

ACTUALIZACION ONLINE

En el panel de servicios de vLCM, haga clic en Lifecycle Operations y luego clic en Settings.

Clic en System Upgrade.

Seleccione el tipo de repositorio para las actualizaciones de vRealize Suite Lifecycle Manager (Check Online) y después clic en CHECK FOR UPGRADE. Y si tiene salida a internet, después de unos minutos debería poder visualizar cual es la ultima versión disponible.

Ahora solo debe hacer clic en el botón UPGRADE.

Este proceso tomará un par de minutos. Si el proceso ve alguna pantallas con el mensajes Waiting for services to start, no se preocupe, es normal.

ACTUALIZACION OFFLINE

En la actualización offline, primero necesitaremos descargar el medio de instalación desde el portal de My VMware.

Nota: Una vez descargado el medio de instalación es importante verificar la integridad del mismo. Para esto lo invito a leer el siguiente post Verificar integridad de medios de instalación VMware (checksum), no tardará mas de 5 minutos.

Lo siguiente que debemos hacer es cargar la ISO a Content Library (si existe) o a un Datastore.

Desde la interface de vCenter Server, debemos mapear la ISO al dispositivo CD/DVD de la maquina virtual de vLCM haciendo Edit Settings a la maquina.

Nota: Si cargó la ISO a un datastore seleccione en CD/DVD drive Datastore ISO file, si la cargó a un Content Library entonces seleccione la opción Content Library ISO File, y seleccione la ISO que contiene la actualización de vLCM.

Volvemos a la interface gráfica de vLCM y en el panel de servicios, haga clic en Lifecycle Operations y luego clic en Settings.

Clic en System Upgrade.

Seleccione el tipo de repositorio para las actualizaciones de vRealize Suite Lifecycle Manager (CD-ROM) y después clic en CHECK FOR UPGRADE. En este caso va a revisar la actualización contra la ISO que hemos mapeado anteriormente y después de unos segundos debería poder visualizar cual es la última versión disponible.

Ahora solo debe hacer clic en el botón UPGRADE.

Este proceso tomara un par de minutos. Si en el proceso ve alguna pantallas con el mensajes Waiting for services to start, no se preocupe, es normal.

Una vez terminada la actualización por cualquiera de los métodos explicado anteriormente, inicie sesión en vRealize Suite Lifecycle Manager UI y compruebe el estado de la actualización haciendo clic en Settings -> System Upgrade.

Cuando se completa la actualización exitosamente, vRealize Suite Lifecycle Manager muestra el mensaje “vRealize Suite Lifecycle Manager successfully Upgrade”.

También puede verificar la versión actual haciendo clic sobre el nombre de usuario admin@local -> About, en la esquina superior derecha.

Para continuar viendo esta serie de blogs explicando el proceso de actualización de la solución de vRA lo invito a leer la Parte 3.

Referencias

https://docs.vmware.com/en/VMware-vRealize-Suite-Lifecycle-Manager/8.3/com.vmware.vrsuite.lcm.8.3.doc/GUID-DD8074D5-E1C9-4900-B324-8D9744C314B4.html

Backup para vRealize Automation 8.x – Actualizando vRA Parte 1

Esta serie de posts que consta de cinco partes, 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.

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 (vLCM, vIDM, vRA); para lo cual necesitaremos apagar toda la solución.

Para esto lo haremos como se indica a continuación:

0. Forzar sincronización de vIDM y vRA y verificar todas las contraseñas de administración de la solución para vLCM, vIDM y vRA.
1. Verificar que todos los servicio están funcionando correctamente
2. Detener servicios del cluster de vRA por consola
3. Apagar Appliances de vRA desde vLCM
4. Apagar Appliances de vIDM desde vLCM
5. Apagar vLCM desde el vCenter
6. Tomar backup
7. Tomar Snapshot (Recomendado)
8. Encender vLCM desde el vCenter
9. Encender vIDM desde vLCM
10. Encender Appliances de vRA
11. Iniciar servicios de vRA por consola

0. Antes de comenzar ser recomienda forzar una sincronización tanto de vRA como de vIDM desde vLCM. Para esto vamos a 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 IRD-VRA.

Después haga clic en TRIGGER INVENTORY SYNC.

El resultado de este request debe ser Completed.

Lo mismo haremos para vIDM. Para esto vamos a Home -> Environment -> “Environment que contenga la solución de vIDM” 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 … 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 una de los passwords documentados para la solución, de tal manera que puedan ser utilizado durante el troubleshooting si algo sale mal. Esta tarea consiste en iniciar sesión en las consolas gráficas con los usuario administradores (admin, configadmin, etc.), 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 servicios 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 vLCM 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 IRD-VRA. El nodo primario estará marcado como Primary.

En la sesión ssh ya establecida ejecute el siguiente comando para verificar que todo este arriba y no existan problemas antes de apagar.

kubectl get pods --all-namespaces

kubectl -n prelude get pods

2. Detener servicios del cluster de vRA por consola.

Ejecute los siguientes comando en la sesión SSH del Primary Node de vRA

/opt/scripts/svc-stop.sh

sleep 120

/opt/scripts/deploy.sh --onlyClean

Se recomienda copiarlos y pegarlos primero en un Bloc de Notas para evitar que algún caracter especial sea ingresado

y después si copiarlos y pegarlos en la consola ssh del nodo primario de vRA.

Nota: Si por alguna razón obtiene el siguiente error en el primer comando. “Error: context deadnline exceed” intente lanzar el mismo comando desde otro nodo del cluster vRA.

Si el problema continua intente ejecutar el script de la siguiente forma.

Naveguen entonces hasta la ubicación del script y ejecute los siguientes comando

root@vra-01a [ ~ ]# cd /opt/scripts/

root@ivra01a [ /opt/scripts ]# ls -la

Verifique que el script svc-stop.sh exista en ese nodo.

Después ejecute el script desde la ubicación actual, de la siguiente forma

root@ivra01a [ /opt/scripts ]# ./svc-stop.sh

Una vez ha ejecutado los tres comando con éxito, hasta el script /opt/scripts/deploy.sh –onlyClean. Ejecute de nuevo el siguiente comando (solo para verificar) y no deberíamos tener recursos activos.

kubectl -n prelude get pods

En este punto ya podemos apagar los appliances de vRA desde vLCM.

3. En vLCM desde el servicio Lifecycle Operations vamos a la sección Home -> Environments -> “Environment que contenga la solución de vRA”.

Clic en el icono con tres punto al lado derecho del titulo vRealize Automation  … clic en Power OFF.

y luego SUBMIT para confirmar.

El request debería mostrarse como Completed.

Nota: Si tiene la versión 8.1 de vLCM en su ambiente, esta opción no estará disponible. Así que deberá apagar los appliances desde vCenter.

4. En vLCM 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 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 vLCM desde el vCenter.

6. En este punto podemos lanzar el Job de backup con la solución que tengamos disponible (en este caso Veeam Backup), para respaldar los siguientes appliances:

  • vRA
  • vIDM
  • vLCM

7.  Nunca sobra un Snapshot (Recomendado) de los siguientes appliances:

  • vRA
  • vIDM
  • vLCM

8. En este punto procedemos a encender de nuevo el Appliance de vLCM desde el vCenter

9. Continuar con el encendido de vIDM desde vLCM

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

Nota: Si tiene la versión 8.1 de vLCM o inferior en su ambiente, esta opción no estará disponible. Así que deberá encender los appliances desde vCenter.

10. Encender Appliances de vRA desde vLCM

En vLCM desde el servicio Lifecycle Operations vamos a la sección Home -> Environments -> “Environment que contenga la solución de vRA” (en este caso IRD-VRA).

Clic en el icono con tres punto 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: Si tiene la versión 8.1 de vLCM o inferior en su ambiente, esta opción no estará disponible. Así que deberá encender los appliances desde vCenter. Espere aprox. 5 min a que los appliances inicien completamente.

11. Por ultimo, debemos iniciar los servicios de vRA por consola (Si tenemos un cluster de vRA ver Nota 1 para identificar Primary Node).

Inicie sesión ssh al Primary Node de vRA y ejecutar los siguientes comandos.

kubectl get pods --all-namespaces

kubectl -n prelude get pods

Nota: Como puede observar en esta versión de vRA 8.1, no se inició los servicios de manera automática por lo que tendremos que iniciarlos ejecutando el siguiente comando. Sin embargo, es probable que en versiones mas recientes vRA suba los servicios automáticamente en donde el comando anterior (kubectl -n prelude get pods), debería mostrar todo los pods creados. Sino es el caso ejecute el siguiente comando.

/opt/scripts/deploy.sh

Nota: El script de inicio tardara aproximadamente 20 min. De manera que sea paciente.

Una vez termine la ejecución del script, podrá observar en la consola que el despliegue ha terminado de manera exitosa, con el siguiente mensaje: Prelude has been deployed sucessfully.

Solo por verificar vuelva a ejecutar el siguiente comando:

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 la Parte 2.

Referencias

https://docs.vmware.com/en/vRealize-Automation/8.3/Administering/GUID-99D06124-13F8-489A-B43C-EAEC3F4FE582.html

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.