Este post se centrará en un problema común que hemos experimentado con vRSLCM y es que el Request falla al intentar descargar los Binarios desde My VMware o al intentar hacer el Mapping Local de los mismos.
Si analizamos los detalles del request en la sección Home -> Requests del servicio Lifecycle Operations podremos observar que detalle del error básicamente contiene lo siguiente:
com.vmware.vrealize.lcm.common.exception.userinput.myvmware.MyVmwareProductDownloadException: Error occurred while downloading product binaries from MyVMware account : user@lab.local. Please check the logs for more details at com.vmware.vrealize.lcm.drivers.myvmware.helper.MyVmwareDownloadRestClient.downloadFile(MyVmwareDownloadRestClient.java:714) at com.vmware.vrealize.lcm.drivers.myvmware.helper.MyVmwareDownloadUtil.getDownloadUrlsAndDownloadProductBinaryFiles(MyVmwareDownloadUtil.java:295) at com.vmware.vrealize.lcm.drivers.myvmware.helper.MyVmwareDownloadUtil.downloadProductBinaries(MyVmwareDownloadUtil.java:168) at com.vmware.vrealize.lcm.plugin.core.myvmware.tasks.MyVmwareDownloadTask.execute(MyVmwareDownloadTask.java:203) at com.vmware.vrealize.lcm.automata.core.TaskThread.run(TaskThread.java:45) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.base/java.lang.Thread.run(Unknown Source)Caused by: java.io.IOException: Error occurred when uploading file to a content repo. It could be due to disk space not available. at com.vmware.vrealize.lcm.drivers.sourcemapping.helper.SourceMappingUtil.mountISOandUpload(SourceMappingUtil.java:1056) at com.vmware.vrealize.lcm.drivers.myvmware.helper.MyVmwareDownloadRestClient.downloadFile(MyVmwareDownloadRestClient.java:659) ... 7 more
Indicándonos una lĂnea muy importante «It could be due to disk space not available» en donde nos esta diciendo que posiblemente no hay espacio disponible para la descarga de los binarios. Para verificar esto haremos lo siguiente:
Iniciamos sesiĂłn SSH hacia el Appliance de vLCM con usuario root y la clave configurada durante la instalaciĂłn.
Ejecutamos el comando df -h
Efectivamente podemos evidenciar que el disco con la ruta /data se encuentra al 72% de utilizaciĂłn y debido a que en este caso de laboratorio el disco es de apenas 20GB, es necesario crecer el disco para poder descargar los BINARIES.
Como lo hacemos entonces para crecer el disco?
No te preocupes… En la interfaz grafica (UI) de vLCM vamos a la sección Home -> Settings -> System Details.
Para Extender el disco simplemente debemos hacer clic en el botĂłn EXTEND STORAGE y diligenciar los datos solicitados para el vCenter Server que esta administrando el Appliance de vLCM. Para este ejemplo creceremos el disco en apenas 10 GB. (Ver Nota 2 al final sino tienes una credencial configurada para vCenter Server).
Clic en el botĂłn EXTEND para continuar.
Clic en el enlace Click here para verificar los detalles del Request y monitorear su actividad.
Una vez terminado el proceso de expansión podrá ver de nuevo en Home -> Settings -> System Details que ya aparecerá el nuevo espacio. Ahora contamos con un total de 30 GB y un 48% usado.
En este punto podemos intentar de nuevo el proceso para descargar los BINARIOS desde Home -> Settings -> Binary Mapping, y el Request deberĂa funcionar sin problemas.
El request tardará un par de minutos asà que se paciente
Una ves completado el Binario estará disponible en Home -> Settings -> Binary Mapping
Nota 1: La configuraciĂłn de los Binarios lo remataremos en otro blog para no hacerlo tan largo.
Nota 2: En vRSLCM todas la contraseñas son referenciadas desde el Locker. De manera sino cuenta con una credencial creada para vCenter Server, vaya primero al Locker de vLCM y configure una.
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.
Como ya conocemos vRealize Lifecycle Manager (vRSLCM) 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 vRSLCM 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 vRealize Suite 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.
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.
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.
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 vRSLCM, 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.
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 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.
La actualización del componente vRealize Suite Lifecycle Manager (vRSLCM) es quizá el paso mas importante durante la actualización de cualquiera de nuestras soluciones de la vRealize Suite, ya que de este dependerán las versiones a las que podremos actualizar de acuerdo con la matriz de interoperatividad dispuesta por VMware.
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.
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.
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.
Cuando se completa la actualización exitosamente, vRealize Suite Lifecycle Manager muestra el mensaje «vRealize Suite Lifecycle Manager successfully Upgrade».
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
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.
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.
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?
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.
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:
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.
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.
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á.
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.
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.
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
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.
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: 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.
Como ya sabemos, una suma de verificación o checksum, es el resultado de ejecutar una función hash criptográfica dentro de un archivo, que tiene como propósito principal detectar cambios en una secuencia de datos para proteger su integridad. La particularidad de esto es que un pequeño cambio en el archivo provoca una salida totalmente distinta.
Dicho esto, checksum nos permite verificar la integridad del medio de instalaciĂłn y estar seguros que el contenido del mismo no ha sido alterado y es tal y como lo indica su fabricante.
Lo importante a tener en cuenta en este post es que el objetivo no es garantizar una procedencia confiable del medio de instalaciĂłn, sino verificar la integridad del archivo descargado.
Dejando un lado la teorĂa vamos a lo que nos interesa…
PROCEDIMIENTO
Utilizando la lĂnea de comando de Windows (CMD) y la herramienta CertUtil incluida en las versiones mas recientes del sistema operativo. Ejecute el siguiente comando.
Nota 1: Para no tener que escribir el nombre del archivo, podemos simplemente seleccionarlo y arrastrarlo dentro de la consola de CMD de Windows y de esta manera incluirá la ubicación completa del mismo.
El resultado del comando nos devuelve un nĂşmero de verificaciĂłn similar al siguiente. SelecciĂłnelo y cĂłpielo para el siguiente paso (el de su Command Prompt).
e05748cea32d60566f0738a5b811cfdc
Para verificar que el archivo no ha sufrido ninguna modificación durante la descarga o posterior a ella, vaya a la página de descargas de VMware, donde descargó el medio de instalación, utilice la función Buscar… (ctrl+f o command+f) y dentro del campo de búsqueda pegue el numero que devolvió la salida del comando anterior.
De esta manera podemos buscar rápidamente si el numero que nos devolvió la herramienta CertUtil corresponde con el numero de verificación (MD5SUM) publicado por el fabricante.
Nota 2: Sino puede ver los detalles del medio de instalaciĂłn en pagina de descargas. Haga clic en el enlace Read more para visualizar la informaciĂłn publicada por VMware.
Si el numero es encontrado como en la imagen anterior, el medio de instalaciĂłn es apto para ser usado. Sino es asĂ, vuelva a descargar el medio de instalaciĂłn porque seguramente esta corrupto.
Nota 3: Puede utilizar la herramienta CertUtil para la suma de verificación de otros algoritmos hash cambiando el parámetro MD5 en el comando por cualquiera de los siguientes. VMware en su página de descargas publica la información para MD5SUM, SHA1SUM y SHA256SUM.
MD2
MD4
MD5
SHA1
SHA256
SHA384
SHA512
Por ultimo y como recomendaciĂłn, realice este procedimiento para evitar algunos dolores de cabeza y perder tiempo tratando de solucionar problemas que probablemente vienen del medio de instalaciĂłn y no del proceso de instalaciĂłn o actualizaciĂłn.
Muchas veces bien sea desde el lado de implementaciĂłn o desde la operaciĂłn, nos encontramos con el problema de no poder exportar las reglas del Firewall Distribuido de NSX-T en las versiones 3.0 y anteriores. Esta caracterĂstica ha sido recientemente adicionada a la versiĂłn 3.1 (ver aquĂ), de manera que si tenemos una version anterior nos vemos obligados a recurrir a APIs para poder extraer la configuraciĂłn de estas polĂticas y reglas.
Por suerte, por lo general cuando hablamos de Micro-SegmentaciĂłn casi siempre tenemos a la mano la herramienta vRealize Network Insight con lo cual esta tarea se resume a una consulta y a un export.
PROCEDIMIENTO
En la caja de bĂşsqueda de vRNI realice la siguiente consulta: NSX-T Firewall rule
Clic en ADD PROPERTIES y agregue las siguientes propiedades:
Nota: Puede utilizar el buscador para encontrar las propiedades rapidamente.
Section Name
Rule ID
Configure Source
Configure Destination
Service
Port Range Display
Applied to
Action
Direction
Activamos el check Save changes to:Create a new template, para crea una plantilla con las nueve (9) propiedades seleccionadas.
Por ultimo, en el campo de texto Create a new template asignamos un nombre a la plantilla (en este caso hemos definido Export DF Rules Template)y hacemos clic en EXPORT.
Seleccionamos el destino y nombre para el archivo .csv y clic en Save.
La próxima vez que desee exportar nuevamente las reglas únicamente tendrá que seleccionar en Property Template la plantilla guardada y automáticamente se cargaran las propiedades asociadas.
Una vez hemos exportado la informaciĂłn simplemente lo importamos en Excel para poder visualizarla como filas y columnas.
(Opcional) Una vez la tenemos en este formato, recomiendo crear una tabla dinámica para organizar mejor la información de forma similar a como la vemos en el Firewall Distribuido.
Para esto, active el Diseño de tabla dinámica clásica antes de seleccionar la información de las columnas.
Organice las filas en el siguiente orden y seleccione la opción No mostrar subtotales en el diseño de la tabla dinámica
Section Name
Rule ID
Configure Source
Configure Destination
Service
Port Range Display
Applied to
Action
Direction
Por ultimo, utilice la función buscar y remplazar para eliminar la palabra «default.» que antepone cada security group en la información exportada. De esta manera podrá visualizar mejor la información presentada.
vRealize Network Insight no admite rollback ni downgrade del producto por lo que se debe realizar una copia de seguridad antes de continuar con la actualizaciĂłn. Para obtener más informaciĂłn sobre el proceso de backup y restauraciĂłn ver aquĂ.
En un entorno de clĂşster, debe realizar la operaciĂłn de actualizaciĂłn solo en el nodo Platform 1.
Las reglas de firewall se referirĂan a reglas inexistentes para los flujos cuyo perĂodo de inactividad es mayor a 24 horas antes de actualizar la versiĂłn 1.8 a 1.9.
La opción Online Update deberá estar habilitada en Settings | Infrastructure and Support | Overview and Update y deberá existir un paquete disponible para instalar.
AsegĂşrese de tener soporte activo para la soluciĂłn vRealize Network Insight antes de actualizar.
1. Genere un Snapshot para cada una de la maquinas virtuales que conforman la soluciĂłn (nodos Platform y Proxies) o asegĂşrese de tener un backup de cada una de ellas en caso de que algo salga mal.
2. Inicie sesiĂłn en vRealize Network Insight como administrador y vaya a Settings | Infrastructure and Support | Overview and Update para revisar la existencia de actualizaciones disponibles.
3. Verifique el estado de salud de la infraestructura sea Good.
4. Haga clic en el enlace View details frente a la nueva versiĂłn de paquete que aparece disponible.
5. Revise el numero de compilaciĂłn de la nueva versiĂłn y lea atentamente la informaciĂłn de la ventana emergente. (Opcional) haga clic en View release note para conocer mas acerca de la nueva versiĂłn.
7. Cuando aparezca el botón DONE en la parte inferior, sabrá que el proceso de actualización ha terminado. Y podrá hacer clic sobre el para cerrar la ventana emergente e ir a la ventana de inicio de sesión.
8. Inicie sesiĂłn en la soluciĂłn vRealize Network Insight como administrador y revise las notas What is New de bienvenida, para familiarizarse con las bondades de la nueva versiĂłn. Cierre la ventana emergente haciendo clic en la X.
9. Una vez cierre la ventana anterior, aparecerá una notificación para ingresar la licencia asociada a la nueva versión.
Nota: Si únicamente se hace un Update dentro de la misma versión no tendrá que hacer este paso.
10. Haga clic en PROCEED para ir automáticamente a la sección License and Usage e ingrese la nueva llave que previamente debió haber actualizado desde el portal de my.vmware.com.
11. Verifique que el estado de salud para cada uno de los componentes de la infraestructura continĂşe en Good, en la secciĂłn Settings | Infrastructure and Support | Overview and Updates.
12. Por ultimo pero no menos importante, verifique que las fuentes de datos continĂşen recolectando datos.
Antes de explicar el sencillo procedimiento para identificar el lĂder en un clĂşster, recordemos que un clĂşster esta formado por un grupo de tres nodos NSX Manager para alta disponibilidad y escalabilidad y que cada NSX Manager appliance tiene incluido los roles de Policy, Manager y Controller.
Podemos construir un clĂşster de NSX-T Manager de las siguientes dos maneras.
NSX Management Cluster con DirecciĂłn IP Virtual
El NSX Management cluster garantiza la alta disponibilidad y es configurado de la siguiente forma:
Todos los manager deben estar en la misma subnet.
Un nodo Manager es elegido como lĂder.
La IP Virtual del Cluster es unida al manager lĂder.
La IP Virtual del cluster es usada para el trafico destinado a los nodos NSX Manager.
El trafico destinado a cualquier Nodo de Transporte usa la IP de management del nodo.
Una Ăşnica direcciĂłn IP virtual es usada por los clientes de acceso API y GUI.
Cuando se envĂa una solicitud de usuario a la direcciĂłn IP virtual, el manager activo (el lĂder que tiene la direcciĂłn IP virtual adjunta) responde a la solicitud. Si el lĂder falla los dos managers restantes eligen un nuevo lĂder y este responderá a las solicitudes enviadas a esa direcciĂłn IP virtual.
Las solicitudes de equilibrio de carga y el tráfico no se equilibran entre los administradores mientras se usa VIP.
Si el nodo lĂder que posee VIP falla, se elige un nuevo lĂder que envĂa una solicitud GARP para tomar posesiĂłn de la VIP y entonces el nuevo nodo lĂder recibe todas las nuevas solicitudes de API y UI de los usuarios.
NSX Management Cluster con Load Balancer
Para este caso, un balanceador de carga es el encargado de proveer alta disponibilidad al cluster:
Todos los nodos son activos.
GUI y API son disponibles en todos los managers.
El trafico a la IP Virtual es balanceado a mĂşltiples nodos manager.
Los nodos manager pueden estar en diferente subnet.
1. Inicie sesiĂłn SSH hacia la IP Virtual del Cluster con el usuario admin y el password definido en la instalaciĂłn . Sino tiene habilitado el servicio SSH puede hacer login desde la Consola de la VM en el vCenter.
2. Ejecute el comando get cluster status verbose y observaremos que para cada funciĂłn del manager tenemos un lĂder seleccionado.
3. Ahora solo debemos buscar debajo de cada funciĂłn del manager, el lĂder asociado para cada uno de los servicios de la misma.
En la siguiente grafica se muestra como lĂder del servicio api para la funciĂłn HTTPS, al miembro con UUID terminado en 3d60144055b5 que corresponde al FQDN nsxp02.lab.local.
Nota: Algunas funciones tendrán mas de un servicio, por lo que tendrán un lĂder asociado para cada uno.
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.
Es aquĂ donde nos podrĂamos encontrar con un error comĂşn que puede convertirse en un dolor de cabeza sino conocemos su causa raĂz. El error básicamente se produce al intentar ejecutar la acciĂłn Erase Partitions en la configuraciĂłn del host en el apartado Configure->Storage->Storage Devices, como se muestra en la siguiente imagen.
Al hacer clic sobre la opción anterior nos mostrará un resumen de las particiones con las que cuenta este disco y razón por la cual no esta disponible para el asistente de configuración de VSAN.
Al hacer click sobre el botĂłn OK, en la mayorĂa de los casos, las particiones serán eliminadas y el disco quedará disponible para vSAN. Una forma rápida de verificarlo es que al hacer nuevamente clic sobre Erase Partition, no deberĂa listar ninguna particiĂłn y el asistente de configuraciĂłn de vSAN deberĂa ahora listar el o los discos.
¿Y SI FALLA?…
Es ahora cuando aparece el problema ÂżQue hacemos si esta tarea falla y nos muestra el siguiente error: “Cannot change the host configuration”? Primero que todo ¡calma, calma!, no tenemos que ir a ninguna lĂnea de comandos a intentar limpiar estas particiones, la soluciĂłn es mucho más sencilla que eso.
Nota 1: Para las versiones de ESXi anteriores a 7,0, scratch partition es un espacio temporal que se configura automáticamente durante la instalación o el primer arranque de un host ESXi. El instalador de ESXi crea una partición FAT16 de 4GB en el dispositivo de destino durante la instalación si hay suficiente espacio y si el dispositivo se considera local. Esta partición no es creada cuando el hipervisor se instala en tarjetas SD o unidades flash USB.
Nota 2: Si no existe espacio temporal persistente disponible en el disco local o la partición no es creada (en el caso de SD, Flash USB), ESXi almacenará estos datos temporales en la memoria RAM. Esto puede ser problemático en situaciones con poca memoria, pero no es fundamental para el funcionamiento de ESXi.
Explicado lo anterior, el problema pudo haberse producido si ese disco o discos, en algĂşn momento fueron formateados como Datastore (VMFS), y esto hace que el hipervisor configure ese datastore como su mejor candidato para ubicar el Scratch Partition (ParticiĂłn creada para almacenar la salida de vm-support necesaria para el soporte de VMware).
Por esta razón, la solución a este problema se basa en cambiar la configuración asociada a la opción avanzada del hipervisor ScratchConfig.ConfiguredScratchLocation, que probablemente estará apuntando al datastore local que en algún momento se configuró en dicho disco.
SOLUCIĂ“N
1. Si ya tiene vCenter instalado navegue en el inventario hasta el Host –> Configure –> Advanced System Settings. Clic en Edit… y en el filtro escriba ScratchConfig.ConfiguredScratchLocation.
2. Sino tiene instalado un vCenter aĂşn, inicie sesiĂłn en el Host Client del host en cuestiĂłn (en cualquier navegador web https://IP_FQDN_Host ) y navegue hasta Manage->System-> Advanced Settings y en el buscador escriba ScratchConfig.ConfiguredScratchLocation o simplemente Scratch.
3. Independientemente de si se realizó el paso anterior desde el vCenter o desde el Host Client, podrá ver que en el campo value aparecerá la ruta hacia un datastore, lo único que debemos hacer es editar este valor y colocar /tmp, para redireccionarlo a la memoria RAM (no recomendado) o especificar la ruta de un almacenamiento persistente diferente.
Nota 3: Al editar el valor de ScratchConfig.ConfiguredScratchLocation será /tmp, mientras el valor de ScratchConfig.CurrentScratchLocation permanecerá sin cambios. Esto se debe a que es necesario realizar un reinicio del host para que los mismo sean aplicados.
4. Una vez realizado el reinicio, inicie sesiĂłn nuevamente en el Host Client y navegue hasta Manage->System-> Advanced Settings. En el buscador escriba ScratchConfig.ConfiguredScratchLocation o simplemente Scratch.
En la columna value podrá observar que el valor tanto para ScratchConfig.ConfiguredScratchLocation como para ScratchConfig.CurrentScratchLocation es /tmp.
5. Por ultimo, intente nuevamente la acciĂłn Erase Partition.
Nacho Aprende IT 