If you have deployed NSX Application Platform (NAPP) using the latest version of NAPPA (NSX Application Platform Automation Appliance) and upon completion of the deployment you notice that the Guest Cluster supporting the NAPP solution is on a TKR (Tanzu Kubernetes release) version of v1.23.8, this post is for you, and I will explain how to resolve it in under 3 minutes.
Well, if you’re here, it’s because you’ve already realized that even though you’re using the latest version of NAPPA, it is deploying the Guest Cluster in an unsupported version (v1.23.8).
The bad news is that it is a reported issue with the NAPPA tool (version 4.2), which, although it has three images of TKR incorporated and loads them into the content library, ends up choosing version v1.23.8 instead of v1.27.6, even though both were shown as COMPATIBLE.
Solutions
At this point, you have two options: update from TKR v.1.23.8 until you reach at least v1.26.5, although I would recommend going for v.1.27.6. I will be posting an article for that update soon, so don’t miss it!
The other option, which is smarter and requires less effort, is to remove the deployment using the CLEANUP function of NAPPA to redeploy it while keeping in mind some considerations that I will explain later.
If you decided to remove the deployment, go to NSX Application Platform Automation Appliance, proceed next to the wizard until you reach the end. This is where your deployment should have finished; start from the last stage of deployment > Deploy NAPP and click on CLEANUP.
Note: If you had already activated any NAPP service with NSX Intelligence, go to the NSX graphical interface and click on remove that service; otherwise, it will not let you delete the deployment. Once the service is removed, it should look like the following image.
After doing the same (CLEANUP) in the Deploy TKGs stage. This will remove the deployment of NAPP and vSphere With Tanzu from your environment to simply redeploy it.
WARNING! Do this only if you have deployed vSphere With Tanzu using the NAPPA and only for the purpose of the NAPP.
At this point, you have only made a couple of clicks to remove the deployment, which is why it is my preferred option.
Now you just need to update NSX to version 4.1.2.2 or higher and relaunch the NAPP. This update is very straightforward; moreover, it will help you to get rid of one or two vulnerabilities that you might have in the environment.
In my case, I upgraded from NSX version 4.1.2.1 to version 4.1.2.5.
Here you just need to restart the NAPPA assistant from the beginning; the good news is that all the data is already preloaded, you just have to re-enter a couple of passwords.
If all has gone well, you should now have the Guest Cluster deployed that supports the NSX Application Platform (NAPP) in the supported and compatible version (v1.27.6).
And that’s all, friends! With this, we confirm that when we have a version of NSX higher than 4.1.2.2, the guest cluster is deployed with version v1.27.6.
ALL VM NAMES USED IN THIS BLOG ARE FICTITIOUS AND RELATE TO A CUSTOM LAB ENVIRONMENT USED FOR STUDY PURPOSES.
IMPORTANT! I have migrated the blog from the domain nachoaprendevirtualizacion.com to nachoaprendeit.com. If you found this article helpful, please give it a Like and share it with your colleagues; these actions will help me optimize search engines to reach more people.
Si estas desplegado NSX Application Platform (NAPP) utilizando la ultima versión de NAPPA (NSX Application Platform Automation Appliance) y al finalizar el despliegue vez que el Guest Cluster que soporta la solución de NAPP esta en una versión de TKR (Tanzu Kubernetes release) v1.23.8. Este post es para ti, y te explico en menos de 3 minutos como solucionarlo.
Pues bien, si estas acá es porque ya te diste cuenta que aunque estas usando la última versión del NAPPA, te esta desplegando el Guest Cluster en una versión fuera de soporte (v1.23.8).
La mala noticia es que es un issue reportado de la herramienta NAPPA (versión 4.2), que aunque tiene incorporadas tres imágenes de TKR y las carga en la librería de contenido, termina eligiendo la versión v1.23.8 y no la v1.27.6, aunque las dos se mostraban como COMPATIBLE.
Soluciones
En este punto tienes dos opciones, hacer actualizaciones desde la TKR v.1.23.8 hasta llegar mínimo a la v1.26.5 aunque yo recomendaría mejor la v.1.27.6. Estaré publicando un post para esa actualización. Así que, ¡No te lo pierdas!
O la otra opción, más inteligente y con menos esfuerzo, es eliminar el despliegue usando la función de CLEANUP del NAPPA para volverlo a lanzar teniendo algunas consideraciones que te explico más adelante.
Si decidiste eliminar el despliegue, ve a NSX Application Platform Automation Appliance, next a el wizard hasta llegar al final, aquí fue donde debió haber terminado tu despliegue, comienza por la última etapa del despliegue > Deploy NAPP y clic en CLEANUP
Nota: Si ya habías activado algún servicio del NAPP con NSX Intelligence, ve a la interface gráfica de NSX y haz clic en eliminar a ese servicio, de lo contrario no te va dejar eliminar el despliegue. Una vez eliminado el servicio, debe lucir como en la siguiente imagen.
Después hacer lo mismo (CLEANUP) en la etapa Deploy TKGs. Esto eliminará el despliegue de NAPP y vSphere With Tanzu de tu ambiente para simplemente volver a lanzarlo.
¡OJO! Hacer esto solo si has desplegado el vSphere With Tanzu usando el NAPPA y solo para el propósito del NAPP.
En este punto solo has hecho un par de clics para eliminar el despliegue, por eso es mi opción preferida.
Ahora solo tienes que hacer un update de NSX a la version 4.1.2.2 o superior y volver a lanzar el NAPP. Esta actualización es muy sencilla, además te va a ayudar a librarte de una que otra vulnerabilidad que puedas tener en el ambiente.
En mi caso pasé de la versión de NSX 4.1.2.1 a la version 4.1.2.5
Aquí ya solo debes volver a lanzar el asistente del NAPPA desde el principio, la buena noticia es que todos los datos ya aparece precargados, solo tienes que reingresar un par de passwords.
Si todo ha salido bien, deberías tener ahora desplegado el Guest Cluster que soporta la solución de NSX Application Platform (NAPP) en la versión soportada y compatible (v1.27.6).
¡Y eso es todo amigos! Con esto comprobamos que, cuando tenemos una versión den NSX superior a 4.1.2.2. El guest cluster se despliega con la versión v1.27.6.
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 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.
Si después de un apagado forzado o una actualización tu Virtual Machine (VM) en VMware Fusion muestra el siguiente error, este post te muestra como salir de este problema rápidamente.
Cannot open the disk '/User/XXXX/Virtual Machines.localized/YYYY.vmwarevm/Disco Virtual.vmdk' or one of the snapshot disk it depends on.`
Module 'Disk' power on failed. failed to start the virtual machine
Procedimiento
Buscar la VM en la siguiente ruta que te indica el error. De forma predeterminada, los paquetes de máquinas virtuales se almacenan en Macintosh HD/Users/User_name/Documents/Virtual Machines. Según la versión de Fusion y la configuración de Mac OS, el nombre de esta última carpeta puede ser Virtual Machines.localized.
Nota: Las máquinas virtuales que se ejecutan desde particiones de Boot Camp se almacenan en Macintosh HD/Users/User_name/Library/Application Support/VMware Fusion/Virtual Machines/Boot Camp. Aquí solo se almacenan los archivos de configuración de máquinas virtuales de Fusion para la partición de Boot Camp; Fusion utiliza la partición de Boot Camp como disco virtual.
Una vez localizado el archivos de la VM, vamos a hacer clic derecho sobre el y despues Show Package Contents
La acción anterior nos llevará a un nuevo directorio donde debemos localizar las carpetas con el nombre .lck al final, en este caso tengo dos carpetas
Por último, solo debemos eliminar esas carpetas y volver a intentar el Power On de la máquina virtual en VMware Fusion
¡Y eso es todo amigos! Con este procedimiento vas a poder desbloquear una Máquina Virtual (VM) en VMware Fusion que por X o Y razón resultó bloqueada!
¡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.
Si tienes un ambiente de NSX 4.1.x o superior, has llegado un día a la oficina y te has encontrado con un montón de alertas de certificados expirados. ¡Este post es para ti!
Contexto
El entorno ejecuta NSX 4.1.0.2 o superior y se actualizó desde NSX-T 3.2.x.
Las alarmas de NSX indican que los certificados han expirado o están a punto de expirar.
Los certificados que vencen contienen «Corfu Client» en su nombre.
Causa
Hay dos factores principales que pueden contribuir a este comportamiento:
Los NSX Managers tienen muchos certificados para servicios internos. En NSX-T 3.2.x, los certificados de servicio de Cluster Boot Manager (CBM) tenían un período de validez incorrecto de 825 días en lugar de 100 años. Esto se corrigió a 100 años en NSX-T 3.2.3 y NSX 4.1.0. Sin embargo, en cualquier entorno que haya ejecutado anteriormente NSX-T 3.2.x (anterior a 3.2.3), los certificados internos de CBM Corfu vencerán después de 825 días, independientemente de si se actualiza o no a la versión corregida.
En NSX-T 3.2.x, los certificados de servidor internos podían vencer y no se activaba ninguna alarma. No se produjo ningún impacto funcional. A partir de NSX 4.1.0.2, las alarmas de NSX ahora controlan la validez de los certificados internos y se activan en el caso de certificados vencidos o que estén a punto de vencer.
Nota: En NSX 4.1.x, no hay impacto funcional cuando caduca un certificado interno. Sin embargo, las alarmas seguirán activándose y esto es lo que verás si estás frente esta situación, que podrás solucionar en menos de 5 min.
Solución
Siguiendo el KB NSX alarms indicating certificates have expired or are expiring nos dice que existe un script en Python que resuelve este problema como por arte de magia. Para ello solo necesitamos una VM con python instalado. La buena noticia es que el vCenter Server ya tiene los módulos que necesitamos para ejecutar estos scripts, así que no vamos a tener que desplegar nada, solo cargar el script al vCenter Server Appliance y lanzarlo desde ahí. Para mayor información por favor revisar el KB indicado anteriormente.
Cargar el archivo a la carpeta /tmp del vCenter Server Appliance utilizando WinSCP o cualquier cliente SFTP.
Como persona responsable asegúrate de tener el Backup de NSX reciente. En mi caso, tomaré un snapshot, ya que es un ambiente Nested.
Hacer login al vCenter Server con el usuario root y navegar hasta la carpeta /tmp. Una vez aquí simplemente ejecutamos el siguiente comando
python3 replace_certs_v1.7.py
Nota: Lo único que tenemos que hacer es responder a las preguntas que nos realiza el script.
Resultado
Una vez finaliza la ejecución del script, aproximadamente 30 minutos en el laboratorio, podemos ver que todas las alertas de certificados se han corregido.
Si revisamos el certificado de uno de los NSX Manager, podremos ver que su fecha ha sido actualizada.
También podemos verificar que ya no tenemos alertas de Certificados en la sección Settings > Certificates
¡Y eso es todo amigos! Ya puedes pasar el susto y volver tus tareas habituales…
Nota para las versiones NSX 4.1.2 o anteriores: debido a problemas de permisos de carpetas y archivos, es posible que el script no reemplace los certificados en la primera ejecución y los intentos posteriores sí los reemplacen. Asegúrese de ejecutar el script una segunda vez en caso de que no funcione la primera vez.
Nota para NSX 4.1.1 y versiones posteriores: el script no rota CBM_APIlos certificados (certificado de cliente API-Corfu), ya que estos están obsoletos en la versión 4.1.1. Consulte la resolución de KB#367857. Después de completar el script, es posible que algunos certificados sin usar permanezcan en la interfaz de usuario con la columna “ Dónde se usa ” establecida en 0. Estos certificados se pueden eliminar si lo desea.
Nota para VCenter 8.0 U3: este script puede fallar en vCenter 8.0 U3 debido a problemas de incompatibilidad. Puede fallar con el error: SshCommandExecutor: An error occurred: [digital envelope routines] unsupported Unable to SSH to '192.168.x.x'. Please fix it and rerun the script Solución: use una versión diferente de vCenter o utilice un dispositivo Linux diferente con los componentes necesarios para ejecutar el script.
¡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.
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.
Como todos sabemos, todos los productos y soluciones de VMware by Broadcom ahora se centran el marco de VMware Cloud Foundation (VCF) y VMware vSphere Foundation (VVF). Sin embargo, existe aún mucha confusión con respecto a cómo son cuantificadas las licencias requeridas para el ambiente teniendo en cuenta el modelo de subscripción de Broadcom.
1. Licenciamiento VCF/VVF por subscripción requerido para el ambiente
Lo primero que debemos tener presente es que el modelo de suscripción se basa en la cantidad total de cores físicos, de cada CPU en todos los hosts ESXi asociados con las instancias de VCF o vCenter Server que los clientes planean licenciar con VCF o VVF.
Sin embargo, existe una reglar que indica que los clientes deben adquirir una capacidad de licencia mínima de 16 cores por CPU.
Pero además de esto, la cantidad de licencias por subscripción requeridas debe ser la mayor entre el resultado de las siguientes dos operaciones:
1) Qta Licencias Subscripcion VCF/VVF: [Número de núcleos por CPU] × [Número de CPU por host ESXi] × [Número de hosts ESXi]
2) Qta Licencias Subscripcion VCF/VVF: [16 núcleos] x [número total de CPU por host ESXi]
Nota: Esto no significa que las licencias se vendan en paquetes de 16, sino que es más bien el mínimo de licencias por subscripción que un cliente puede comprar.
2. Licenciamiento para vSAN por subscripción requerido para el ambiente
Por otro lado, tenemos el caso del licenciamiento para vSAN, pero este es otro asunto un poco diferente, debido a que aquí el licenciamiento depende en primera instancia de si vamos a utilizar VCF o VVF.
Escenario vSAN con VCF
Comencemos por el escenario en el cual vamos a licenciar vSAN para VCF (VMware Cloud Foundation). Aquí el licenciamiento está definido en TiB (tebibyte), y en este caso la cantidad de licencias de vSAN se basa en el almacenamiento físico total RAW (TiB) reclamado por vSAN en todos los hosts ESXi en cada clúster de vSAN asociado con las instancias de vCenter Server o VCF que los clientes planean licenciar para vSAN.
Nota: Para los que no se acuerda, el Terabyte utiliza el sistema decimal y equivale a 1 billón de bytes, mientras el Tebibyte (TiB) utiliza el sistema binario y equivale a 1.099.511.627.776 bytes o lo que es lo mismo 1024 GiB (Gibibyte), que es como normalmente todos en TI lo asociamos. Es más un tecnicismo y cuestión de acostumbrarnos a colocar las siglas correctas.
Dicho esto, podríamos utilizar la siguiente expresión para definir la cantidad de licencias por subscripción necesarias para vSAN en un ambiente de VCF.
Qta licencias Subscripcion vSAN (en VCF) = [Número total de TiB reclamados por vSAN en cada host ESXi] x [número de hosts ESXi en cada clúster].
De esta manera, cada TiB que reclama vSAN requiere una única licencia. A diferencia del licenciamiento por subscripción de VCF, donde mínimo debíamos adquirir 16 licencias, para este caso de vSAN, NO existe un mínimo.
Algo importante a resaltar, es que el licenciamiento por subscripción de VCF provee el derecho a 1 TiB de vSAN por cada licencia de core de VCF adquirida. Esto quiere decir que si el número de TiB que necesita el ambiente es menor o igual al número de licencias de core de VCF, el cliente no debe adquirir licenciamiento de vSAN adicional. Por otro lado, si el número de TiB que necesita el ambiente es superior al número de licencias de core adquiridas, probablemente deba adquirir licenciamiento adicional para vSAN únicamente.
Resumiendo el párrafo anterior, podríamos expresarlo de la siguiente forma:
1) (Qta Licencias subscripcion VCF) <= Numero de TiB requereridas por el ambiente, entonces no requiere licencias adicional de vSAN
2) (Qta Licencias subscripcion VCF) > Numero de TiB requereridas por el ambiente, entonces se requiere licencias adicional para vSAN
Nota: Para ver todos los ejemplos disponibles, lo invito a revisar el link anterior.
Escenario vSAN con VVF
Por otro lado, tenemos el escenario en el cual vamos a licenciar vSAN para VVF (VMware vSphere Foundation) . Aquí el licenciamiento está definido en GiB (Gibibyte), y en este caso la cantidad de licencias de vSAN se basa en el almacenamiento físico total RAW (GiB) reclamado por vSAN en todos los hosts ESXi en cada clúster de vSAN asociado con las instancias de vCenter Server o VVF que los clientes planean licenciar para vSAN.
Cuando estamos licenciando para VVF, tenemos derecho hasta 100 GiB de vSAN de prueba, por cada licencia por subscripción de core adquirida. Es decir si adquirimos 16 licencias de core para VVF tendríamos derecho a 16 x 100 GiB = 1600 GiB = 1.5624 TiB.
Nota: Aunque acá la referencia es GiB, es mejor convertirlo a TiB para mayor facilidad.
De esta manera, si los clientes exceden la cantidad de capacidad de prueba de vSAN en el clúster de vSAN, deben licenciar la cantidad total de TiB reclamados en el clúster de vSAN comenzando desde 0.
Dicho esto, la expresión para calcular la capacidad máxima trial de vSAN para VVF sería la siguiente:
Capacidad vSAN trial (en VVF) = [Qta de licencias de núcleo de vSphere Foundation en cada host ESXi implementado en el clúster de vSAN] x [100 GiB] / 1024
Nota: De nuevo acá, dividimos por 1024 para convertir la capacidad a TiB y hacer una comparación más sencilla.
3. Herramienta para consolidar la información de la cantidad de licencias
Como entendemos que contar la cantidad de licencias en nuestro ambiente puede ser una tarea aburrida, VMware By Broadcom ha puesto a disposición una herramienta (script) para identificar la cantidad de licencias por Core (con un mínimo de 16 cores por CPU física) y licencias TiB que se requieren para licenciar correctamente los siguientes productos VMware: VMware Cloud Foundation (VCF), VMware vSphere Foundation (VVF) y VMware vSAN.
Nota: VMware Cloud Foundation y VMware vSphere Foundation requieren licencias por core para todos los cores físicos en cada CPU que ejecute el software. OJO! En caso de que los usuarios deshabiliten los núcleos de CPU físicos en la configuración del BIOS o por otros medios, el script puede producir resultados inexactos. Por lo tanto, todos los núcleos físicos deben estar activados en cada CPU del host al ejecutar el script.
Los requerimientos para ejecutar el script son los siguientes:
VMware PowerCLI 10.x o superior instalado.
En la VM donde se instaló el PowerCLI, abrir una consola de PowerShell y ejecutar el siguiente comando Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypas
Nota: Sin nunca has instalado PowerCLI, ¡No has sido un verdadero guerrero, bienvenido al campo de batalla! Es broma, no te preocupes solo revisa el artículo Install PowerCLI si tu VM tiene salida a internet o si no tienes salida a internet entonces usa el siguiente artículo Install PowerCLI Offline. Aunque para evitarte la fatiga, te dejo abajo la instalación para cuando tenemos salida a internet en la VM.
Instalación de PowerCLI
Verificar la versión de PowerShell que tenemos instalada y verificar la Compatibility Matrix de PowerCLI. Sino tenemos la versión correcta de PowerShell indicado en los prerrequisitos de la matriz de compatibilidad (para la versión PowerCLI 13.3), vamos a tener que instalar la nueva versión siguiendo la documentación de Microsoft Installing PowerShell on Windows
En mi caso tenía la versión 5.0.1 y la documentación dice que necesitaba mínimo la 5.1.0. Sin embargo, instalamos de una vez la última versión disponible. En este caso utilicé la opción por MSI que menciona en Installing PowerShell on Windowsporque creo es la más sencilla.
Una vez actualizado nuestro PowerShell, ahora sí, instalamos el PowerCLI usando el comando Install-Module VMware.PowerCLI
Nota: Si les da algún error solo use el comando con los parámetros Install-Module VMware.PowerCLI -Force -skipPublisherCheck
Usar la herramienta (script)
Una vez instalado el PowerCLI seguir los siguientes pasos para ejecutar el script
Desde la consola del PowerShell navegar hasta donde tenemos el archivo descargado del KB indicado anteriormente.
Conectarse a vCenter Server con el siguiente comando Connect-VIServer -Server IP_FQDN_vCenter_Server
Nota: Si el comando anterior les da el error cannot be loaded. The file xxxx.psm1 is not digitally signed. You cannot run this script on the current system. For more information abut running scripts and setting execution policy, see about_Execution_Policies at htt;s//microsoft.... Solo ejecute el siguiente comando Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass y vuelva a intentar el import.
Ejecute la función Get-FoundationCoreAndTiBUsage y especifique el tipo de implementación para traer los resultados. De manera predeterminada, el script iterará por todos los clústeres de vSphere. Get-FoundationCoreAndTiBUsage -DeploymentType VCF Get-FoundationCoreAndTiBUsage -DeploymentType VVF
Desconectarse del vCenter Server: Disconnect-VIServer -Server IP_FQDN_vCenter_Server
A continuación se muestra un par ejemplos adicionales después de ejecutar la herramienta en PowerCLI.
Ejemplo de VCF con vSAN
Ejemplo de VVF con vSAN
¡Y eso es todo amigos! Con esta sencilla herramienta podremos verificar la cantidad de licencias VCF/VVF y vSAN que necesitamos en el ambiente.
¡IMPORTANTE! He migrado el 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 acciones me ayudarán a optimizar los motores de búsqueda para llegar a más personas.
Creo que muchos a administradores en su día a día han experimentado el error HTTP Status 500 – Internal Server Error al intentar hacer login en la UI del vCenter Server. Se que su primer instinto será reiniciar múltiples veces sin un resultado satisfactorio.
En este caso lo primero que debemos hacer es verificar es el estado del certificado configurado en el vCenter, si vemos que nuestro certificado ya expiró como en nuestro caso (Valid from 12/4/2020 to 12/5/2022), no se preocupe, tenemos un procedimiento para regenerarlo y recuperar la gestión del vCenter.
PROCEDIMIENTO
1. Iniciar sesión SSH al vCenter y ejecutar el comando shell
2. Ejecutar el siguiente comando /usr/lib/vmware-vmca/bin/certificate-manager para lanzar el Certificate Management Tools de vCenter Server
3. Digitar la opción 8 y responder confirmar presionando la letra y
4. A continuación podemos dejar los valores por defector del template de vSphere o customizar el template con nuestro valores. Para este caso utilizaremos los valores por default debido a que necesitamos regenerar los certificados default.
Nota: Si decidimos utilizar los valores por defecto podemos presionar la teclar enter varias veces para aceptar los valores por default hasta llegar a las opciones Hostname y VMCA donde debemos especificar el FQDN de nuestro vCenter Server y nuestro Platform Services Controller (PSC). Para versiones superiores a vCenter Server 6.7 donde la única arquitectura soportada es PSC Embedded este valor es el mismo para estos dos inputs.
5. Al final de los inputs presionamos nuevamente la tecla y para confirmar la operación y podemos ir a tomarnos un cafe mientras los certificados son regenerados. Esto puede tardar aproximadamente 20 min.
6. Al final del proceso debemos obtener el mensaje Reset Status : 100% Completed (Reset completed successfully)
7. Por último, solo nos queda verificar que la fecha de nuestros certificado ha cambiado por una fecha valida y que nuestro vCenter ya esta arriba nuevamente.
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.
Como su nombre lo indica este post se enfoca en la solución de un problema de vencimiento de certificados para la consola de administración (EMC Unisphere) de nuestro VNX5200 . Sin embargo no hay de que preocuparse, ¡El mensaje de error asusta más que el problema en sí!.
Al intentar ingresar a la consola de administración del EMC Unisphere aparece el siguiente error: «The System can not be managed for the following reasons. Certificate has invalid date» y simplemente no permite continuar con el inicio de sesión.
El problema básicamente radica en que el certificado ha expirado y no permite el inicio de sesión de ninguna manera.
SOLUCIÓN
La solución se centra en forzar la generación de un nuevo certificado a través de una interfaz de línea de comandos.
1. Descargue la herramienta EMC Navisphere CLI desde aquí. Iniciando sesión con una cuenta de usuario registrada para poder realizar la descarga.
2. Instale EMC Navisphere CLI en su ordenador siguiendo cada uno de los pasos del asistente.
Nota 1: Tenga presente la ruta de instalación de la herramienta (la usaremos más adelante). La ruta por default es C:\Program Files (x86)\EMC\Navisphere CLI.
Nota 2: En el Paso 3. Deje la validación del certificado en Low para que no verifique el certificado. (Solo para este caso, porque esta vencido).
3. Una vez finalizada la instalación. Abra una línea de comandos en Command Prompt (CMD) y navegue hasta la ubicación de instalación de la herramienta Navisphere CLI utilizando el siguiente comando:
cd C:\Program Files (x86)\EMC\Navisphere CLI
4. Ejecute ahora la herramienta NaviSECCLI.exe utilizando la siguiente línea de comandos:
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 