¡Bienvenidos a esta serie post con visión técnica de lo nuevo que ha venido incorporando vSphere en los últimos años!
¿POR QUÉ AHORA?
Estando de cara al cliente en mi dia a dia me he dado cuenta que muchos clientes siguen utilizando vSphere en sus versiones 8.x sin conocer las nuevas funcionalidades, y operandolo como si nunca hubiera existido un update que mejora el rendimiento, la seguridad o la gestión del entorno virtual.
Por esta razon, estoy convencido que es crucial que nuestros clientes estén informados sobre estas capacidades para optimizar su infraestructura. Y aunque ya está disponible VCF 9.0 y vSphere 9.0, es importante conocer en las versiones actuales que la mayoria de nuestros clientes tienen, para facilitar la transición a nuevas versiones y garantizar que la infraestructura esté alineada con las mejores prácticas.
Con el fin de fomentar la adopción de VMware Cloud Foundation, he creado una serie de blogs que resumen las mejoras o What’s New de vSphere 8.x, abordando características como la escalabilidad, la integración con la nube, la resiliencia y herramientas de administración que simplifican la labor del administrador de sistemas.
Sin mas preámbulo les dejo los links a cada una de ellas. Les aseguro que no les tomará mas de 20 minutos comocer todo lo que vSphere nos trajo antes de la version 9.x.
¡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, y a motivarme a seguir compartiendo este tipo de artículos.
TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.
En esta oportunidad vamos a responder a una pregunta muy frecuente de nuestros clientes. Y es ¿Como inicio sesión SSH a los nodos del cluster de Tanzu Kubernetes Grid (TKG), recientemente renombrado a vSphere Kubernetes Service (VKS)?. Pues bien, vSphere with Tanzu ahora vSphere IaaS Control Plane, esta diseñado para que no haya necesidad de tener que ingresar a estos nodos. Sin embargo, algunos clientes son curiosos y quieren acceder a darle una mirada a estos nodos.
Lo primero que debemos decir es que hay varia forma de hacerlo incluyendo una en donde nos conectamos a traves del vCenter a las Control Plane del Supervisor Cluster y desde ahi saltamos a las control VM de los TKG. Sin embargo, esta opción no parece ser la mejor para los clientes que no quiere compartir un acceso ssh al vCenter solo para poder acceder a la VMs del cluster de K8s que hemos llamado acá TKG (Tanzu Kubernetes Grid) recientemente renombrado como VKS (vSphere Kubernetes Services).
Este prerrequisito es muy facil de cumplir y basicamente vamos a necesitar una VM basada en Linux. Sino tenemos una, podemos seguir la documentación oficial Create a Linux Jump Host VM para desplegar un Photon OS.
Pero si como en mi caso ya tienen una, pueden usar esa. Lo único que debemos hacer es agregarle una segunda interface, que tenga acceso a la red de Workload Network > Namespace Network del Supervisor Cluster.
Así que agrégale una segunda interface a tu VM existente o nueva y déjala hasta ahi. Mas adelante veremos cuál IP, Subnet o NSX Segment configurarle.
Identificar la Workload Network
Antes de continuar, es importante entender que los objetos de Kubernetes crean objetos en NSX • Un Kubernetes namespace crea un logical segment. • Un vSphere Pod crea un logical port conectado al logical segment. • Kubernetes crea un correspondiente virtual server en NSX para su servicio load balancer.
Para saber cual es la red de Workload Network, vamos a ver la configuración de Supervisor Cluster en Workload Management > Supervisors > [Supervisor-Name] > Network > Workload Network
Nota: Aqui vemos que la Namespace Network es la 10.244.0.0/20 y es subneteada con /28 para cada Namespace (vSphere Namespace) que se crea en el Supervisor Cluster.
Ahora bien, en el NSX que soporta el despliegue de Supervisor Cluster, solo si su solucion de Supervisor fue desplegada usando NSX, vamos a ver que por cada Namespace en el Supervisor Cluster se crea un T1 Gateway y que estos tienen un sufijo que contiene el nombre de los cluster TKGs ha creado.
Y en la columna Linked Segments tenemos un numero que nos indica a cuantos segmentos NSX esta conectado. Por lo general hay mínimo dos segmentos asociados, seg-domain-xxx y un vnet-domain-yyy. Puede haber mas si el Namespace tiene mas de un cluster vSphere Pods por dentro. En este caso solo tengo un Cluster de TKG desplegado en ese vSphere Namespace. Para mas información acerca de objectos creados en NSX por favor visitar NSX Networking Objects for VKS Clusters.
Lo importante a entender aquí, es que las VM de Control y Worker de los cluster TKG esta conectados al segmento vnet-domain-yyy de esos T1 Gateways. Por lo que nuestra tarea es agregar un IP de ese Segmento a la VM Jump que teníamos disponible o que tuvimos que crear.
De lo anterior, podemos hacer el siguiente análisis. Si el segmento vnet-domain-yyy tiene configurado el gateway 10.244.0.145, la VM de control del TKG la 10.244.0.146 y la de Worker del TKG la 10.244.0.147 y ya sabemos que nuestra solución Supervisor Cluster hace subnet /28 para cada vSphere Namespace. Quiere decir aun tenemos 11 IPs de la subnet disponibles para poder asignársela a la interface de nuestra VM Jump. Solo para aclarar, recordemos que /28 no da 16 IPs disponibles y 14 IPs usables, pero aca ya tenemos 3 IPs utilizadas.
Nota: Esto puede cambiar si tiene mas componentes dentro del su vSphere Namespace, o mas nodos en sus cluster de TKG.
En este caso, como mencionamos anteriormente, ya tenia una VM linux en el ambiente, de manera que solamente le voy a conectar una segunda interface. Si usted no tiene una siga la documentación para descarga el ISO o el OVA y desplegar el Photon OS y cuando este listo continue con este paso.
Nota: Recordemos que las IPs que ha tomado las Control VM y Worker nodes de TKG son del Segmento vnet-domain-xxxxxx-Namespace-Name-yyy. Por esta razon debemos conectar ese Segmento NSX a nuestra VM en la segunda interface.
Configure la máquina virtual con una dirección IP desde Red de Workload > Red del Namespace.
# sudo ip addr add 10.244.0.158/28 dev ens35
# ip addr show ens35
Nota: Se recomienda utilizar para esto la ultima IP disponible de esa subnet /28 o una de las ultimas para evitar overlapping si agregamos mas recursos a ese vSphere Namespace.
Una vez configurada la IP vamos a verificar que podemos hacer ping al gateway
Nota: En este punto ya estamos listos para iniciar sesión a nuestros TKG clusters.
Procedimiento para iniciar sesión SSH a los nodos TKG
En este punto ya deberíamos poder hacer SSH a la VM. Sin embargo. Primero debemos obtener la contraseña de esas VMs, siguiendo SSH to TKG Service Cluster Nodes as the System User Using a Password, pero como siempre acá lo vamos a resumir. Entonces lo primero es hacer login al supervisor cluster
Cambiar el contexto (vSphere Namespace) donde esta aprovisionado el clúster TKG.
kubectl config get-contexts
kubectl config use-context [vSPHERE_NAMESPACE_NAME]
Ejemplo: En este caso queremos hacer login a un TKG que esta en el vSphere Namespace `terraform-cli`
Ahora listamos las VMs para saber cuales conforman el cluster TKG
kubectl get virtualmachines
(Opcional) podemos ejecutar el siguiente comando para ver la IP de las VMs desde kubectl o podriamos verla directamente en el inventario de vSphere
kubectl describe virtualmachine VM_NAME
Acá vamos a poder ver la IP configurada
Aunque podemos verla también desde el vSphere Client
Ahora vamos a visualizar los secrets que esta configurados en este vSphere Namespace con el siguiente comando
kubectl get secrets
De la salida anterior nos interesa obtener el Password SSH de las VM de Control y Worker del TKG cluster y para eso vamos a utilizar el siguiente comando
kubectl get secrets TKG-CLUSTER-NAME-ssh-password -o yaml
Nota: El comando anterior nos devuelve el password de ssh
Nota (solo Windows nodes): Si su TKG usa nodos Windows. Dado que los nodos Windows no permiten un mecanismo SSH basado en contraseña, utilice la Private Key para acceder por SSH a los nodos de Control y Worker. Para eso utilice el siguiente comando.
kubectl get secrets TKG-CLUSTER-NAME-ssh -o jsonpath='{.data.ssh-privatekey}
Ahora debemos decodifica el Password SSH o Private Key segun sea el caso de nuestros nodos, Linux o Windows
Descifrar el Password SSH (Nodos basados en Linux): El secreto está codificado en Base64. Para decodificarlo,
Debido a que nuestro jump es Ubuntu usaremos la opcion base64 --decode
echo <ssh-passwordkey> | base64 --decode
Nota: Por alguna razon, el password decodificado no se mostro en una linea nueva, pero es esa. Si queremos comprobarlo podemos copiar el password y pegarlos en el online tool.
Descodificar la Private Key (Nodos basados en Windows) Utilice el mismo mecanismo que utilizó para decodificar el Password SSH. Guarde la Private Key SSH decodificada en un archivo y configure los permisos chmod 400 FILE_NAME.
Si hemos seguido las pasos hasta el momento, ya deberíamos poder iniciar sesión SSH a nuestros nodos del TGK desde nuestra Jump VM, ya sea con la Password SSH o Private Key decodificados, según corresponda (nodos linux o Windows).
Iniciamos entonces SSH a cualquiera de los nodos del clúster TKG con el usuario del sistema vmware.
Para utilizar Password SSH (nodos Linux), use este comando.
Nota: filename Es el archivo donde almacenaste la Private Key SSH para los nodos Windows.
Conclusion
Con este procedimiento habrá logrado iniciar sesión en los nodos de Control o Worker de su TKG cluster, utilizando el Password o Private Key que decodificó.
¡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, y a motivarme a seguir compartiendo este tipo de artículos.
TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.
¡Bienvenidos a un ultimo capítulo de esta serie de posts donde exploramos la evolución de vSphere 8.x! En esta ocasión hablaremos de vSphere 8.0 Update 3, liberado el 25 de junio de 2024, una de las actualizaciones más completas de la serie 8.x.
El objetivo sigue siendo el mismo: dar a nuestros clientes, partners y comunidad una visión clara de las mejoras que VMware ha ido incorporando en cada release. Y es que, aunque ya estamos viendo llegar VMware Cloud Foundation 9, la mayoría de las organizaciones hoy en día siguen ejecutando cargas críticas sobre vSphere 8.x.
Así que acompáñame a revisar, de manera resumida y técnica, las novedades más importantes que trajo este update.
Antes de hablar de lo nuevo, es importante revisar lo que se va. Cada versión de vSphere deja atrás tecnologías que ya no cumplen con los estándares modernos de seguridad y eficiencia. Veamos qué funciones han sido marcadas como obsoletas o eliminadas en vSphere 8.0 U3.
IMPORTANTE: La vida útil de vSphere 7 termina el 2 de octubre de 2025, así que este es un momento clave para planear la migración.
Obsolecencias destacadas
Update Manager baselines y APIs.
Autenticación integrada con Windows, RSA SecureID directo y Smart Card directo.
Boot en SD/USB y BIOS heredado (migrar a UEFI + Secure Boot).
NPIV en Fibre Channel, soporte CIM/SLP, Trust Authority, SDRS y SIOC para IO Latency.
TPM 1.2, CPUs y dispositivos I/O en fin de vida.
Soporte para Guest OS antiguos (incluyendo MacOS en KB 88698).
Remociones
Cliente local de vSphere.
Adaptadores Software FCoE y RoCE v1.
Binarios de 32 bits.
Cifrados inseguros como SHA1.
Nota: si aún dependes de estas tecnologías, es hora de actualizar.
Comencemos ahora si con lo interesante de este release que probablemente es el que mas mejoras ha incluido en la version vSphere 8.x
vSphere Supervisor
Kubernetes sigue siendo protagonista en la evolución de vSphere. En esta versión, VMware da un paso importante para separar el ciclo de vida de Kubernetes del de vCenter, lo que trae más flexibilidad y rapidez. Vamos a ver cómo esto impacta a los clústeres y qué mejoras llegan para los administradores.
Kubernetes desacoplado de vCenter: ahora el servicio VKS tiene lanzamientos asíncronos alineados con versiones upstream que le nos permite actualizar el cluster de Kubernetes independientemente de los upgrades del vCenter o Supervisor.
Autoscaling nativo para clústeres Kubernetes (minima versión soportada v1.25):
Escala nodos cuando aumenta la demanda.
Escala hacia abajo cuando hay recursos sobreutilizados.
Soporte para vSAN Stretched Cluster permite desplegar clústeres de Kubernetes sobre una infraestructura vSAN distribuida en dos sitios geográficos distintos. Gracias a esto, si un sitio completo falla, el otro puede seguir operando, garantizando alta disponibilidad y resiliencia para las cargas de trabajo de Kubernetes.
Rotación automática de certificados del Supervisor sin intervención manual (solo alerta si falla). En vSphere 8.0 U3 elimina la necesidad de intervención manual cuando un certificado está por expirar. El sistema se encarga de renovar los certificados de forma automática antes de su vencimiento.en vSphere 8.0 U3 elimina la necesidad de intervención manual cuando un certificado está por expirar. El sistema se encarga de renovar los certificados de forma automática antes de su vencimiento.
Backup & Restore de VMs en namespaces vía VADP, con recreación automática de objetos del Supervisor.
En vSphere 8.0 U3 se habilita la integración del VM Service con Advanced Data Protection (VADP) para realizar backup y restore de máquinas virtuales dentro de namespaces.
VM Class expandida: más opciones de hardware administradas desde el vCenter UI.
En lugar de definir cada ajuste manualmente, los usuarios pueden referirse a una VM Class como plantilla completa, mientras que los administradores mantienen un control granular sobre qué configuraciones de hardware estarán disponibles para los usuarios de autoservicio.
Local Consumption Interface (LCI): Ofrece una interfaz gráfica que simplifica el consumo de servicios básicos, permitiendo desplegar VMs y clústeres de Kubernetes con generación automática de YAML y soporte para configuraciones como balanceadores de carga y volúmenes persistentes, reduciendo la complejidad y acelerando las operaciones.
Lifecycle Management
Mantener la infraestructura actualizada sin interrumpir el negocio es clave. En vSphere 8.0 U3 encontramos avances en la forma de actualizar, configurar y parchar nuestro entorno, con menos caídas y más control. Revisemos estas mejoras en la gestión del ciclo de vida.
vCenter Reduced Downtime Update: migración con switchover automático u opcional manual, minimizando la caída del servicio.
vSphere Configuration Profiles: gestión declarativa de configuración a nivel de clúster, con soporte de baselines.
vSphere Lifecycle Manager (vLCM):
Live Patch: aplicar parches sin evacuar VMs.
Staging, remediación paralela y soporte para hosts standalone.
El hardware evoluciona y vSphere también. En este update vemos soporte optimizado para DPUs, GPUs y CPUs de última generación, con mejoras que apuntan directamente a workloads de IA, cómputo intensivo y memoria acelerada. Descubramos qué trae de nuevo este soporte.
Dual DPU Support
Modo HA: active/standby con failover transparente.
Modo Capacidad: 2 DPUs independientes, duplicando capacidad de offload.
CPUs y memoria
Soporte optimizado para Intel Xeon y AMD EPYC con aceleradores integrados (QAT, AMX, AVX-512).
Scheduler mejorado para CPUs de muchos núcleos.
NVMe para memoria (Tech Preview): más cargas in-memory con menor TCO.
GPUs
Perfiles flexibles de vGPU con mezcla de workloads gráficos y de cómputo.
Cluster-level GPU Monitoring: visibilidad centralizada de consumo.
Mejoras en movilidad de VMs con vGPU, con control de stun time en vMotion.
Availability & Resilience
La alta disponibilidad no es opcional en entornos críticos. Con esta actualización, vSphere introduce mejoras para mantener los clústeres resilientes y con menor footprint, asegurando continuidad incluso en escenarios distribuidos. Veamos los cambios más relevantes.
vSphere Cluster Service embebido en ESXi:
Solo 2 VMs por clúster.
Sin footprint en almacenamiento.
Fault Tolerance para Metro Clusters (vSAN y no-vSAN): permite ubicar primario y secundario en sitios distintos.
Workloads y eficiencia
No todo es más potencia: también se trata de eficiencia. vSphere 8.0 U3 incorpora funciones que permiten ahorrar energía y optimizar despliegues de máquinas virtuales sin perder flexibilidad. Aquí te cuento cómo impacta esto en las cargas de trabajo diarias.
CPU C-State Virtualization: permite a las cargas invocar modos de ahorro profundo de energía en CPUs.
OVF/OVA con personalización de hardware al desplegar desde Content Library.
Self-Service Resolution: reactivar operaciones de VM deshabilitadas sin tocar la BD de vCenter.
Seguridad y Cumplimiento
La seguridad sigue siendo prioridad en cada release. En vSphere 8.0 U3 se amplían las opciones de identidad, se simplifica la gestión de cifrados y se refuerzan las guías de endurecimiento (Hardening) con automatización. Exploremos qué significa esto para proteger mejor nuestros entornos.
PingFederate como nuevo IdP soportado.
TLS & Cipher Suite Profiles: configuración rápida de suites modernas vía API/PowerCLI.
Security Configuration Guides actualizados, ahora incluyen vSAN y scripts para auditoría/remediación.
Storage
El almacenamiento es el corazón de cualquier plataforma virtualizada. En vSphere 8.0 U3, VMware introduce soporte extendido para vVols, NVMe y NFSv4.1, además de optimizaciones que reducen tiempos y mejoran el rendimiento. Vamos a desglosar estas novedades.
vVols Stretched Cluster (soporte inicial con SCSI y Uniform).
UNMAP en vVols con NVMe (manual y automático).
UI mejorada para registro y troubleshooting de Storage Providers.
WSFC sobre vVols con NVMeoF con shared disks (sin RDMs).
Clustered VMDK con NVMe-TCP (se suma a NVMe-FC de U2).
NVMeoF mejorado: soporte de reservas y copy optimization.
FPIN (Fabric Performance Impact Notification): alertas de congestión en FC.
Reducción drástica en tiempos para inflar discos Thin ➝ EZT en VMFS.
NFSv4.1 con nConnect: mayor throughput usando múltiples conexiones.
CNS/CSI: soporte para hasta 250 file shares y migración de PVs entre datastores no compartidos.
Conclusión
vSphere 8.0 U3 no es solo una actualización más: es, hasta ahora, la versión que más mejoras y cambios ha incorporado en la serie 8.x, abarcando desde seguridad, almacenamiento y eficiencia operativa, hasta soporte de hardware de nueva generación para IA, GPUs y DPUs.
Esta actualización marca un punto de quiebre porque nos prepara directamente para la adopción de VMware Cloud Foundation 9, asegurando que las organizaciones que actualicen a vSphere 8.0 U3 tengan la base más sólida, segura y moderna para dar el salto al ya liberado vSphere 9.0.
Con estas capacidades, VMware demuestra que vSphere sigue siendo el pilar confiable para workloads tradicionales y nativos de nube, al mismo tiempo que prepara el camino hacia el futuro de la infraestructura empresarial.
¡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, y a motivarme a seguir compartiendo este tipo de artículos.
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 hemos aprendido hasta ahora. VMware continuó innovando con el lanzamiento de vSphere 8.0 Update 2, una actualización que mejora la eficiencia operativa, la resiliencia y la flexibilidad de la plataforma. Esta versión introduce nuevas funcionalidades para reducir el tiempo de inactividad en actualizaciones, mejorar la administración de certificados, fortalecer la seguridad y optimizar la gestión de cargas de trabajo.
A continuación, detallamos las principales mejoras de esta actualización liberada el 21 de septiembre de 2023.
Actualizaciones de vCenter con Menos Tiempo de Inactividad
Una de las principales novedades es el vCenter Reduced Downtime Update, que minimiza la interrupción del servicio al actualizar vCenter. Ahora, se despliega un nuevo appliance de vCenter mientras el actual sigue en funcionamiento. El tiempo de inactividad solo ocurre en la fase final, cuando los servicios del vCenter antiguo se detienen y se activan en el nuevo, reduciendo la interrupción a menos de 5 minutos.
Esto mejora la continuidad operativa, minimiza el impacto en los usuarios y facilita el proceso de rollback en caso de ser necesario. Esto sin duda nos permite tener actividades de Actualización y parchado más eficientes.
Mayor Resiliencia en el Patching de vCenter
Los parchados del vCenter ahora incluyen snapshots automáticos de la particion LVM (Logical Volume Manager) antes de aplicar parches, lo que facilita la recuperación en caso de fallas. Es importante aclarar que no es un snapshot a nivel de VM.
Además, el proceso permite pausas y reversiones si es necesario. En el evento de una falla en el parchado, podemos hacer rollback a las última versión de backup del LVM.
Nota: Esto no reemplaza los mecanismos de backup por imagen o por archivo que deberíamos tener en nuestro ambiente para proteger la Virtual Machine de vCenter Server.
2. Seguridad y Administración de Certificados Mejorada
Cambios de Certificados Sin Interrupciones
vSphere 8.0 U2 introduce la capacidad de renovar o reemplazar certificados del vCenter sin reiniciar los servicios. Esto reduce la necesidad de programar ventanas de mantenimiento y minimiza riesgos operativos.
Refuerzo en Seguridad Contra Ransomware
Se han mejorado las configuraciones predeterminadas para proteger el entorno desde el primer momento. Además, se han actualizado las guías de seguridad y se han agregado scripts de PowerCLI para auditorías y correcciones automatizadas.
3. Gestión de Clústeres y Almacenamiento Más Flexible
Mejoras en la Gestión de vSAN
Ahora, vSphere Lifecycle Manager (vLCM) puede administrar la imagen de los nodos witness de vSAN de manera independiente, lo que proporciona más control y flexibilidad en la administración del almacenamiento.
Soporte Mejorado para Sistemas Operativos Invitados
En esta versión tenemos la posibilidad de personalizar OUs en Active Directory al unir un sistema Windows.
Por otro lado, los mensajes de error en el panel de Task son más descriptivos cuando los archivos están bloqueados, incluyendo detalles del host que mantiene el bloqueo. Y es que a quien no le ha pasado que encuentran las VMs apagadas y no las pueden encender? Bueno pues ahora el mensaje de error nos permite identificar cuál host tiene bloqueado los archivos.
4. Optimización para Workloads con GPU y AI
Expansión del Ecosistema de DPU y GPU
VMware continúa trabajando en incrementar su ecosistema de Partner para proporcionar a sus clientes compatibilidad con múltiples fabricantes de dispositivos DPUs y GPUs. Recordemos que en versiones anteriores solo estaba soportado NVIDIA y AMD Pensando.
Desde esta versión de vSphere (vSphere 8.0 U2), ahora podemos soportar hasta 16 vGPUs en una sola máquina virtual, así como hasta 32 dispositivos de transferencia directa. Esto permite que vSphere admita los modelos y cargas de trabajo de IA/ML más grandes y complejos que necesitan toda esa aceleración de hardware.
También podemos ahora configurar el tiempo máximo de aturdimiento «stun» para vMotion en cargas de trabajo con GPU.
Por último, se ha mejorado la colocación y balanceo de cargas de trabajo de GPU para optimizar el uso de recursos.
Novedades en Virtual Hardware
Pasemos ahora a las mejoras en el Virtual Hardware. Y aprovecho para resaltar la importancia de realizar el proceso de actualización de VMtools y Virtual Hardware una vez completado el proceso de actualización de vCenter y ESXi. Debido a que esto suele ser una actividad que es pasada por alto por los administradores, impidiendo que la actualizacion de la infraestructura sea completa y se accedan a las mejoras a nivel de las VMs.
Soporte para hasta 32 dispositivos de passthrough por VM.
Compatibilidad mejorada con NVMe 1.3 y 256 discos vNVMe por VM.
Sensibilidad a alta latencia con Hyperthreading activado.
5. Innovación para DevOps y Kubernetes
Mejoras en VMware vSphere with Tanzu
Exportación e importación de configuraciones de Supervisor Clusters para una rápida replicación de entornos.
Servicio de VM mejorado, permitiendo la provisión de VMs Windows y Linux junto con contenedores. Los usuarios de DevOps pueden usar kubectl para implementar y personalizar máquinas virtuales de Windows en sus namespaces. Los datos de personalización de invitados de Windows, que utilizan el formato estándar SysPrep, se encapsulan como un secret y se incluyen en la especificación de implementación de la máquina virtual.
Self-Service VM Images, donde los desarrolladores pueden gestionar imágenes de VM mediante kubectl. Teniendo la posibilidad no solo de leer el contenido de la Content Library sino además publicar contenido dentro de la misma.
Conclusión
vSphere 8.0 U2 es una actualización clave que mejora la eficiencia, seguridad y flexibilidad de la plataforma. Con un enfoque en minimizar el tiempo de inactividad, reforzar la seguridad y mejorar la experiencia de administración, esta versión sigue posicionándose como la mejor opción para entornos empresariales modernos.
Si deseas conocer más detalles, consulta la documentación oficial de VMware o experimenta estas mejoras en tu infraestructura.
Recursos
¡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, y a motivarme a seguir compartiendo este tipo de artículos.
TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.
Muy bien como lo explicamos en el post anterior Novedades Clave de vSphere 8.0 GA: Mejoras y Funcionalidades En esta oportunidad hablaremos solo de las características que fueron incluidas en vSphere 8.0 U1 y. Recordemos que el objetivo final de esta serie de post de novedades de vSphere es tener una visión general de la evolución del producto hasta la fecha. Y estar preparados para la actualización de vSphere 9.0 que ya fue liberada.
Continuando con nuestro camino de adopción de la solución vSphere, componente principal de VMware Cloud Foundation, en este artículo recordaremos las nuevas funciones y mejoras que vSphere 8 Update 1 trajo consigo el 18 de Abril de 2023, mejorando la eficiencia operativa, elevando la seguridad y potenciando las cargas de trabajo.
Podemos categorizar las mejoras de vSphere en tres temas principales:
Administración Eficientemente: Hacer que sea más fácil para los clientes operar sus infraestructuras de TI de la manera más eficiente posible.
Seguridad: Cada función se convierte en una característica de seguridad, lo que permite a los equipos de TI centrarse en ser seguros en lugar de solo asegurar.
Potenciar Cargas de Trabajo: Introducir soporte para nuevas tecnologías de hardware, como GPUs y DPUs.
Administración Eficientemente
vSphere Configuration Profile
Comenzamos con los vSphere Configuration Profile, que facilitan la gestión de la configuración del clúster. Esta nueva función permite a los administradores establecer configuraciones deseadas a nivel de clúster en formato JSON, verificar la conformidad de los hosts y remediar cualquier incumplimiento.
Si bien esta funcionalidad fue introducida en vSphere 8.0 GA como Tech Preview, en vSphere 8 Update 1 comenzó a ser completamente soportada. Permitiendo la configuración de vSphere Distributed Switch que no estaba disponible en la version anterior.
vSphere Lifecycle Manager (vLCM)
Además, se mejoró el vSphere Lifecycle Manager (vLCM) para admitir hosts standalone. Esto incluyó la capacidad de definir imágenes personalizadas y gestionar hosts en ubicaciones remotas con conectividad limitada. Desde esta versión todo lo que se espera de vLCM esta disponible para hosts Standalone.
Flexibilidad en Cargas de Trabajo de GPU
Con vSphere 8 Update 1, ahora se pueden asignar diferentes perfiles de GPU a diferentes cargas de trabajo en la misma máquina. Esto permite a los administradores maximizar la utilización de recursos de GPU.
Mejoras en vSphere con Tanzu
Se han realizado mejoras significativas en la integración de Tanzu Supervisor Services, permitiendo su uso con vSphere Distributed Switch, lo que facilita su implementación y gestión.
Como parte de las mejoras incorporadas al entonces vSphere with Tanzu, se añadieron nuevas funcionalidad al vSphere Virtual Machine Service (VM Service), incluido en la versión vSphere 7 Update 2a , y que básicamente permite implementar y gestionar Virtual Machines mediante las API estándar de Kubernetes, al mismo tiempo que permite al administrador de TI controlar el consumo de recursos y la disponibilidad del servicio. Si quiere saber un poco más de VM Service lo invito a leer este corto articulo Introducing the vSphere Virtual Machine Service escrito por Glen Simon.
Como parte de esas mejoras al VM service el equipo de DevOps ahora puede traer tu propia imagen, lo que permite a los usuarios crear imágenes que se pueden almacenar en una biblioteca de contenido.
Adicionalmente, los desarrolladores pueden ahora lanzar la consola de las VMs utilizando el comando kubectl sin necesidad de tener acceso al vCenter Server.
Por si esto fuera poco, vSphere 8 Update 1 introdujo un workflow en el vSphere Client para desplegar y registrar el Skyline Health Diagnostics y de esta manera registrarlo facilmente con vCenter.
Mejoras en Seguridad
La seguridad es una prioridad constante. En vSphere 8 Update 1, se ha abordado la compatibilidad entre ESXi Quick Boot (introducido en vSphere 6.7) y TPM 2.0, permitiendo un reinicio rápido sin comprometer la seguridad.
También se ha mejorado el soporte para vTPM, permitiendo que las máquinas virtuales protegidas con vTPM sean totalmente tolerantes a fallos, es decir que podamos protegerlas con Fault Tolerance.
Identidad y Autenticación
Se introdujo soporte para el proveedor de identidad Okta, lo que permite una gestión más moderna de identidades y autenticación multifactor. Esto se alinea con las mejores prácticas de seguridad actuales. Lo mejor es que no se require el uso de ADFS, nos permite introducir 2FA/MFA y además nos permite tener un Single Sing-On consistente dentro de la organización.
Potenciar Cargas de Trabajo
Hemos realizado importantes mejoras en VM DirectPath I/O, permitiendo la adición y eliminación en caliente de dispositivos NVMe, usando APIs, lo que reduce el tiempo de inactividad de la carga de trabajo.
Además, se extendió el soporte para la tecnología NVIDIA NVSwitch, que permite una comunicación de alta velocidad entre múltiples GPUs, llegando hasta 900 GB/s, lo que es crucial para aplicaciones de inteligencia artificial y computación de alto rendimiento. En esta versión (vSphere 8.0 U1) podíamos conectar hasta 8 GPUs en un Switch NVIDIA usando el protocolo NVLink
Conclusión
Estas mejoras en vSphere 8 Update 1 no solo mejoraron la eficiencia operativa y la seguridad, sino que también permitieron a los clientes aprovechar al máximo sus cargas de trabajo. Para más información y recursos adicionales, visita el Centro de Recursos de VMware.
¡Gracias por tu atención y espero que encuentres útiles estas nuevas características que fueron lanzadas hace un tiempo pero que probablemente no sabías, no recordabas o nunca habías escuchado hablar de ellas! No vemos en el vSphere 8 Update 2 y Update 3 para completar este path de adopción de la tecnología vSphere.
Recursos
¡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, y a motivarme a seguir compartiendo este tipo de artículos.
TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.
¡Bienvenidos a esta serie post con visión técnica de lo nuevo que ha venido incorporando vSphere en los últimos años!
¿POR QUÉ AHORA?
Si bien esta información salió hace algunos años, en el campo me he dado cuenta que muchos de nuestros cliente siguen usando vSphere en sus versiones 8.x sin saber que funcionalidades se han incluido.
Ya esta disponible VCF 9.0 y con el nuevas funcionalidades para vSphere 9.0, pero antes de llegar allá enfoquémonos en lo que la mayoria de nuestros clientes tienen actualmente y en cómo podemos ayudarlos a sacarle el mayor provecho a su infraestructura. Así que con el fin de mejorar la adopción de VMware Cloud Foundation en nuestros clientes, partners y comunidad en general, he decidido crear una serie de blogs, donde resumiremos las mejoras incorporadas en cada uno los lanzamientos de las productos que componen la solución de VCF.
Ahora, teniendo en cuenta que vSphere es el Core, comenzaremos por aquí. En este blog, exploraremos de forma muy resumida las características más destacadas y las mejoras que vSphere 8.0 GA trajo a la mesa hace un par de años (2022/10/11).
Para no hacer este blog tan largo, explicaremos solo lo correspondiente a vSphere 8.0 GA y en las siguiente entradas, hablaremos de las características que se han venido incorporando con el lanzamiento de cada uno de los updates. Esto con el objetivo de tener al final una visión general de la evolución del producto hasta la fecha. ¡Así que vamos a sumergirnos en el contenido!
vSphere Distributed Service Engine
Comencemos hablando sobre el vSphere Distributed Services Engine, que nació como Proyecto Monterey. Este motor ha evolucionado y se lanzó con vSphere 8.0 GA, permitiendo mover funcionalidades desde el host hacia una Data Processing Unit (DPU) o unidad de procesamiento de Datos. Su principal objetivo es desbloquear el poder de las Data Processing Unit (DPU) para el procesamiento de datos acelerado por hardware, lo que ofrece una mejora en el rendimiento de la infraestructura. Ahora, usar estas DPU en tus cargas de trabajo es más sencillo que nunca.
Pero, ¿qué es una DPU? Es un dispositivo similar a un dispositivo PCIe como una NIC o una GPU, que reside en la capa de hardware. Contiene cierta capacidad de cómputo, almacenamiento, memoria y tiene interfaces de red, por lo que se le conoce también como SmartNIC porque Incluye un procesador ARM, 16-32GB RAM, high speed ethernet de 10GB a 100 GB, interfaz de Management de 1GB, y Sensores. Lo interesante aquí es que hasta el lanzamiento de vSphere 8.0 GA, nuestros servicios de red, almacenamiento y gestión de hosts funcionaban únicamente en una instancia de ESXi x86, virtualizando la capa de cómputo. Con vSphere 8.0 GA, se agregó una instancia adicional de ESXi directamente en la DPU, lo que permite descargar servicios de ESXi hacia este dispositivo, comenzando con algunos servicios de red y seguridad de NSX, aumentando así el rendimiento de la plataforma. Se espera que en futuros releases, se amplíe el soporte para la descarga de más funcionalidad hacia el dispositivo DPU. Clic en el siguiente enlace obtener más información acerca de ESXi Installation on DPU
Nota: Hasta esta versión vSphere 8.0 GA, solo estaban soportados de tipos de DPU, NVIDIA y Pensando. Pero como veremos en los siguientes post asociados a los Updates de vSphere 8.0, nuevos modelos y partners se han unido a la fiesta!
Esto libera parte del poder de cómputo x86 y lo devuelve a nuestras aplicaciones y cargas de trabajo. Para aprovechar el vSphere Distributed Services Engine, necesitas utilizar un Switch Distribuido de vSphere versión 8 y NSX. Esto te permitirá seleccionar la compatibilidad de descarga de red y elegir la DPU adecuada en tu entorno.
Mejoras en vSphere con Tanzu
Pasemos ahora a las mejoras en vSphere con Tanzu. Introducido en vSphere 7, vSphere con Tanzu trajo consigo Tanzu Kubernetes Grid (TKG) y varias versiones. Con vSphere 8, se consolidaron estas diferentes versiones en un único runtime de Kubernetes unificado, que se utiliza para desplegar Kubernetes en clústeres de vSphere, nubes públicas y privadas.
Una nueva característica en vSphere 8.0 GA es el concepto de vSphere Zones. Esto se utiliza para aislar cargas de trabajo a través de clústeres de vSphere y permite que se extiendan o abarquen múltiples clústeres para maximizar la disponibilidad y el consumo de recursos, evitando a su vez que tengamos un único punto de falla a nivel del vSphere Cluster que soporta la solución de vSphere with Tazu.
Por otro lado, incorporamos el concepto de ClusterClass en VMware vSphere with Tanzu, que no es más que una forma declarativa de, especificar la configuración y gestionar el ciclo de vida de clústeres de Kubernetes a través de un cluster de gestión de Kubernetes que, para vSphere with Tanzu, es conocido como Supervisor Cluster. Utilizando esta nueva funcionalidad podemos incluso decidir los paquetes de infraestructura que se deben instalar al crear el clúster. El ClusterClass puede incluir especificaciones asociadas a proveedores de red, almacenamiento y nube, así como el mecanismo de autenticación y la recopilación de métricas. De esta manera podemos definirlo una vez y aplicarlo múltiples veces.
Nota: Las imágenes de Photon OS y Ubuntu ahora se pueden personalizar y guardar de nuevo en la Content Library para su uso en clústeres de Kubernetes de Tanzu. También se integró la autenticación de Pinniped tanto en el Supervisor Cluster como en los clústeres TKG para la gestión de identidades federadas.
Autenticación Federada con Pinniped
En vSphere 7, toda la autenticación se realizaba a través de la integración con vCenter SSO. En vSphere 8.0 GA, tienes una alternativa: la integración con Pinniped. Esta integración permite que el Supervisor Cluster y los clústeres de Kubernetes de Tanzu accedan directamente a un proveedor de identidad OIDC(OpenID Connect), sin depender de vCenter SSO. Los pods de Pinniped se despliegan automáticamente en el Supervisor Cluster y en los clústeres de Tanzu para admitir esta funcionalidad.
Gestión del Ciclo de Vida
Ahora veamos la gestión del ciclo de vida. vSphere Lifecycle Manager (vLCM) ha mejorado, permitiendo la remediación paralela de hosts, lo que reduce el tiempo total de operación. Recordemos que al remediar un host ESXi que contiene una DPU, también hay un evento de remediación la instancia de ESXi que existe en el dispositivo DPU. La buena noticia es que vSphere Lifecycle Manager Images es consciente de eso, por lo que no tienes nada de que preocuparte a nivel de la gestion del ciclo de vida de dicha instancia de ESXi.
Tambien se introdujo el soporte de staging en vSphere Lifecycle manager Images y la remediación paralela, lo que mejora el tiempo total de remediación al realizar operaciones de ciclo de vida en tus clústeres de vSphere.
Nota: Es importante mencionar que la gestión de actualizaciones de baselines está obsoleta en vSphere 8.0, lo que significa que debes comenzar a migrar a un enfoque declarativo basado en Images (vSphere Lifecycle Manager Images).
Por otro lado, a nivel del vCenter Server, redujimos los problemas que habían durante el proceso de recuperación. En esta versión el vCenter concilia el estado del clúster, después de una restauración a partir de una copia de seguridad, contra un nuevo componente llamado Distributed Key-Value Store que se aloja en los hosts ESXi de un clúster, y almacena el estado y la configuración del clúster, y ahora es considerado por el vCenter como la fuente de información veraz para el estado y la configuración de los clústers de vSphere. De esta manera los cambios realizados después de la ejecución del backup del vCenter, no seperderán ni generarán errores en caso de una restauraciónn sino queserán conciliados con el Distributed Key-Value Store para que el vCenter pueda actualizar su base de datos utilizando dicha información.
Ademas, en esta version se introdujo una nueva vista previa técnica de los vSphere Configuration Profiles, que será nuestra próxima generación de gestión de configuración de clústeres, podriamos decir que es la evolución de los Host Profiles.
Nota: En la version vSphere 8.0 GA, la gestión de Images desde vSphere Lifecycle Manager para un host standalone se podia realizar a través de las API unicamente. Sin embargo, es importante mencionar vSphere Lifecycle Manager Baselines, también conocida como Update Manager, está en proceso de obsolecencia en vSphere 8.x.
Inteligencia Artificial y Aprendizaje Automático
En cuanto a la inteligencia artificial y el aprendizaje automático, estas áreas están creciendo rápidamente y requieren hardware acelerado, típicamente en forma de GPUs. vSphere ofrece ahora la posibilidad de soportar Device Groups, que es una configuración realizada en la capa del hardware, que permite definir dispositivos PCI comunes GPUs y NICs que hacen parte de un mismo PCIe Switch. Esto simplifica la asignación de dispositivos a máquinas virtuales, ya que los dispositivos se presentan como una unidad única a nivel de la capa de virtualización.
Nota: Uno de nuestros primeros partners en apoyar los Device Groups es NVIDIA, que lanzó un controlador compatible para esta funcionalidad. Esto permite a DRS y vSphere HA trabajar con Device Groups para la colocación de máquinas virtuales y la recuperación ante fallos.
En versiones anteriores, las máquinas virtuales que consumían dispositivos de hardware físico mediante DirectPath IO o Dynamic DirectPath IO tenían una movilidad limitada. En vSphere 8.0 GA, se ha resuelto este problema con Enhanced DirectPath I/O (Device Virtualization Extension) el cual se basa en Dynamic DirectPath IO e introduce un nuevo marco y API para que los proveedores creen dispositivos virtuales respaldados por hardware para permitir una mayor compatibilidad con funciones de virtualización, como la migración mediante vSphere vMotion, la suspensión y reanudación de una máquina virtual y la compatibilidad con instantáneas de disco y memoria. Ahora la mobilidad esta parmitida gracias a un drive instalado tanto en el Guest OS como en el hipervisor.
Mejoras en el Sistema Operativo Invitado y Cargas de Trabajo
En esta sección, exploraremos algunas mejoras en el sistema operativo invitado y las cargas de trabajo. Cada nueva versión de vSphere introduce una nueva versión de hardware virtual, y en esta ocasión, hemos llegado a la versión 20. Esto permite aumentos en los máximos de cómputo y desbloquea muchas características nuevas.
Una de las nuevas políticas es la provisión de TPM virtual, diseñada para ayudar a implementar cargas de trabajo de Windows 11 a gran escala. En vSphere 8.0 GA, los dispositivos vTPM se pueden reemplazar automáticamente durante las operaciones de clonación o implementación. Esto permite seguir las prácticas recomendadas de que cada máquina virtual contenga un dispositivo TPM único.
Además, estamos simplificando la configuración de vNUMA y aumentando los máximos de cómputo, permitiendo hasta ocho dispositivos vGPU por máquina virtual.
Notificaciones de vMotion
También estamos introduciendo las notificaciones de vMotion, que permiten que las máquinas virtuales sean conscientes de los eventos de vMotion, lo que es crucial para aplicaciones sensibles a la latencia. Esto permite que las aplicaciones realicen trabajos previos de preparación a la migración, como detener servicios o hacer failover de manera controlada.
Nota: Las aplicaciones se debe ser reescritas para que admitan las notificaciones de vMotion. O se puede escribir una aplicación asociada como intermediaria entre las notificaciones de vMotion y la aplicación principal.
Gestión de Recursos y Sostenibilidad
En el ámbito de la gestión de recursos, se mejora el rendimiento de DRS mediante un mejor aprovechamiento de las estadísticas de memoria que fueron introducidas en vSphere 7U3. vSphere Memory Monitoring and Remediation (vMMR) ayuda a cubrir la necesidad de monitoreo al proporcionar estadísticas de ejecución tanto a nivel de VM (ancho de banda) como de Host (ancho de banda, tasas de errores). vMMR también proporciona alertas predeterminadas y la capacidad de configurar alertas personalizadas basadas en las cargas de trabajo que se ejecutan en las VM.
En vSphere 8, el rendimiento de DRS se mejora significativamente aprovechando las estadísticas de memoria, lo que da como resultado decisiones de ubicación óptimas para las máquinas virtuales sin afectar el rendimiento ni el consumo de recursos.
También se introdujo métricas verdes para monitorear las emisiones de energía y carbono de la infraestructura de vSphere y las cargas de trabajo, ayudando a las organizaciones a visualizar su huella de carbono.
Nota: Usage es una metrica de potencia real medida en función del uso activo de la CPU y la memoria de las máquinas virtuales. Se deriva de los medidores de potencia conectados a los hosts (IPMI, interfaz de administración de plataforma inteligente).
Nota: Static Power es una metrica potencia inactiva modelada de la máquina virtual, como si la máquina virtual fuera un host físico hipotético configurado con la misma cantidad de CPU y memoria que la máquina virtual.
Seguridad y Cumplimiento
Finalmente, en términos de seguridad, vSphere 8.0 GA es más seguro por defecto. Se eliminó la opción de usar TLS 1.0 y 1.1, dejando solo TLS 1.2 como opción. También se implementó restricciones para evitar que binarios no confiables se ejecuten en ESXi, lo que significa que solo se pueden ejecutar paquetes firmados.
Además, se introduce un tiempo de espera automático para SSH, que se deshabilitará automáticamente si no se utiliza, ayudando a mitigar posibles vectores de ataque.
Conclusión
Esto ha sido un resumen técnico de las novedades en vSphere 8.0 GA. Hay mucho más que explorar y descubrir así que te invito a seguir nuestro blog, y participar en este bonito camino de adopción de nuestras tecnologías VMware By Broadcom.
Recuerda que estamos haciendo un repaso de las funcionalidades que han sido liberadas en cada uno de los updates de vSphere. Posteriormente haremos lo mismo con vSAN, NSX, VCF, y los productos que componen la Aria Suite.
¡Gracias por tu atención y espero que encuentres útiles estas nuevas características que fueron lanzadas hace un tiempo pero que probablemente no sabías, no recordabas o nunca habías escuchado hablar de ellas!
Recursos
¡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, y a motivarme a seguir compartiendo este tipo de artículos.
TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.
Con la introducción del modelo de Policy como API de NSX principal a partir de NSX 2.4 (publicado en febrero de 2019), NSX ofrece un modelo de API jerárquica declarativa que simplifica el consumo llamada Policy Mode. Sin embargo, aún me sigo encontrando clientes que tienen su NSX Manager configurado con el viejo Manager Mode.
En este artículo vamos a ver la opción que nos ofrece el mismo NSX Manager para mover la configuración heredada existente de la API de NSX Manager Mode (llamada API de MP) a NSX Policy Mode sin interrumpir la ruta de datos, ni eliminar o volver a crear los objetos existentes.
Con esta función, podemos promover los objetos creados en NSX Manager Mode a NSX Policy Mode y, a continuación, interactuar con los mismos objetos a través de la interfaz de usuario de NSX Policy o las API de NSX Policy. La lista de objetos soportados para ser promovidos se encuentra en Promote Manager Objects to Policy Objects.
Tenemos tres Logical Switches creados en la interface de Manager Mode que necesitamos promover al Policy Mode. Una característica de estos objetos es que no tienen el icono circular con dos linean en medio que caracteriza los objetos creados en Policy Mode.
Adicionalmente, estos objetos creados en Manager Mode no se pueden visualizar desde el Policy Mode, lo que puede traernos dificultades en algunas operaciones de día-2.
En vCenter tanto los objetos creados a tráves de Manager Mode o Policy Mode, se visualizan de forma similar, de manera que acá no vamos a ver ninguna diferencia.
Procedimiento para promover del Manager al Policy
Muy bien ahora vamos seguir la documentación oficial Promote Manager Objects to Policy Objects en donde se nos indica el procedimiento para esta promoción. Pero no te preocupes acá lo vamos a revisar paso a paso!
Validamos cual NSX Manager es el lider desde la interface de NSX. Teniendo en cuenta que un ambiente productivo van a existir tres NSX manager y el leader será el que tiene asignado la VIP del cluster de NSX Managers.
Nota: En mi laboratorio solo tengo un NSX Manager de manera que será ese mismo.
Importante asegurarnos de tomar un backup por archivos del NSX justo antes de ejecutar el procedimiento. Sino tiene backup configurado, deberá configurar un SFTP y apuntar el backup de NSX hacia ese servidor como se indica en la documentación oficial Configure Backups. De esta manera, en caso de que la promoción falle, podemos revertir el sistema a su estado original usando la copia de seguridad.
Iniciamos sesión SSH con el usuario admin en el nodo de NSX Manager que hemos identificado como lider en el paso anterior, para luego iniciar el servicio de migration-coordinator y verificar que se haya iniciado correctamente con los siguientes comandos
start service migration-coordinator get service migration-coordinator
Una vez iniciado el servicio vamos System > General Settings >Manager Objects Promotion y deberíamos ver el botón de START OBJECT PROMOTION.
Nota: Sino aparece esta opción es porque aún no se ha iniciado el servicio de Migration-Coordinator como se especificó en pasos anteriores.
Click en START OBJECT PROMOTION para comenzar con el proceso promoción y visualizar cuales objetos vas a ser movidos.
Clic en CONTINUE para iniciar la migración
Esto tomará solo unos pocos segundos y podremos ver que la migración ha terminado satisfactoriamente.
Para ver el detalle o resumen de lo que se hizo, podemos hacer clic en el link que aparece frente a Recent Activity
Resultado
Este procedimiento no es disruptivo y de hecho podemos ver que durante el cambio, las VMs conectadas a los Logical Switches del Manager Mode, ahora Segmentos del Policy Mode, No fueron afectadas.
Después de la migración, los objetos creados en el Manager Mode van a tener icono del Policy
Y en el Policy Mode ya debemos ver los Segmentos disponibles que antes solo se veían en el Manager Mode
Recomendación
Para evitar que se sigan creando objetos en el Manager Mode, se recomienda que desactivemos la vista de Manager Mode en la UI de NSX y para eso debemos seguir la documentación Configure the User Interface Settings, que de nuevo, explicarémos para que no tenga que ir a leerla.
Nota: Para los despliegues greenfield de NSX 4.x, los usuarios no verán esta opción debido a que el Default es Policy.
Para esto entonces solo debemos ir a System > General System Setting > User Interface y clic en edit frente a User Interface Mode Toggle
Las opciones disponibles son las siguientes:
Activar o desactivar visibilidad
Descripción
Visible para todos los usuarios
Si hay objetos del modo Manager presentes, los botones de modo son visibles para todos los usuarios.
Visible para usuarios con el rol de administrador empresarial
Si hay objetos del modo Manager presentes, los botones de modo son visibles para los usuarios con el role Enterprise Admin.
Oculto para todos los usuarios
Incluso si objetos del modo Manager estan presentes, los botones de modo permanecen ocultos para todos los usuarios. Esto solo muestra la interfaz de usuario del modo Policy, incluso si objetos del modo Manager estan presentes.
Modo predeterminado
Se puede configurar como Policy o Manager, si está disponible.
Mi recomendación es dejar la opcion Toggle Visible en Oculto para todos los usuarios o Hidden from All Users y en el Default Mode asegurarnos que este marcada la opción Policy
De esta manera ya no aparecerá la opción de seleccionar entre Policy o Manager cuando entramos al la UI del NSX
Y esto es todo amigos!, de esta manera vamos a poder migrar Objetos Manager a Objetos Policy de manera automática, facil y sin afectar el servicio.
¡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, y a motivarme a seguir compartiendo este tipo de artículos.
TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.
This post is aimed at those who need to update the version of the Kubernetes cluster that supports the NSX Application Platform (NAPP) solution. It must always be aligned with VMware’s interoperability matrix. The process we will describe below should also be followed when performing an upgrade of NSX (which uses NAPP), vCenter (with vSphere with Tanzu), or VCF (with Workload Management enabled) to avoid breaking the integration with the Kubernetes (K8s) clusters.
What is the NAPP
NSX Application Platform (NAPP) is a microservices-based platform that houses various NSX functions that collect, ingest, and correlate network traffic information. As data is generated, captured, and analyzed in your NSX environment, NSX Application Platform provides a platform that can dynamically scale based on the needs of your environment.
The platform can host the following NSX functions that collect and analyze data in your NSX-T environment.
For those who are unclear about what constitutes a NAPP (NSX Application Platform) deployment, we can provide an image that summarizes the deployment components. The main component supporting the NAPP solution is the vSphere with Tanzu solution.
I know that the previous image may cause fear. However, the engineering team at VMware By Broadcom has developed a tool called NAPPA (NSX Application Platform Automation Appliance) in order to facilitate the deployment of each of the components that make up the entire Kubernetes infrastructure required to support the NAPP (NSX Application Platform) solution.
This way, NAPPA executes flows automatically to configure vSphere with Tanzu, which is a solution that allows us to run K8s clusters directly on the hypervisor through the creation of vSphere Namespaces. Similarly, NAPPA, using the Supervisor Cluster deployed with vSphere with Tanzu, automatically creates a vSphere namespace, where a Tanzu Kubernetes Cluster is established, which we will refer to as the Guest Cluster from now on, and this is where the NSX Application Platform solution comes to life, along with all the pods associated with the services of Metric, VMware NSX® Intelligence™, VMware NSX® Network Detection and Response™, VMware NSX® Malware Prevention, and VMware NSX® Metrics.
To make the story shorter, we’ll leave it at that.
The issue: TKR version out of support
Now, the problem we are going to solve here is how to maintain this Guest Cluster after implementing it with the NAPPA. Because in many instances, depending on the version of NSX we had at the time of deploying the NAPP (NSX Application Platform), the version of that cluster may remain on an unsupported version which can cause issues as we update our vSphere and NSX environment.
For laboratory purposes, we have deployed the latest version of NAPP 4.2.0, and interestingly, the guest cluster has been implemented using the TKR version 1.23.8+vmware.3-tkg.1, which as of now is out of support. This behavior is a known issue for the NAPPA tool, and to avoid this behavior, I invite you to read the following post Deploying NAPP with supported TKR version.
Compatibility Analysis
According to the interoperability matrix, we should meet the following minimum versions of TKR.
As we can see in the interoperability matrix, TKR versions below 1.26.5 used by the NAPP guest cluster are currently out of support, and some of them may not be compatible with your NSX Intelligence or your vCenter Server.
Note: The procedure explained below should be performed when we upgrade NSX or vCenter Server, whether as a result of an update of VMware Cloud Foundation (VCF) or when we update these solutions independently, in order to keep the NAPP cluster compatible and within VMware by Broadcom support.
Note: We must keep in mind that the TKR version can only be upgraded incrementally, n + 1, meaning that if we have version 1.23, the first jump must be to 1.24 and so on, until reaching the required version.
Log in to the NAPPA via SSH, using the root user, so that we can connect to the cluster supervisor without needing to install any plugins on our VM, and we will execute the following command.
Run the following command to connect to the Supervisor cluster. If you don’t know the IP of the Supervisor Cluster, just go to vCenter Server > Menu > Workload Management > Namespaces > Supervisor Cluster kubectl vsphere login --insecure-skip-tls-verify --server [IP_SupervisorCluster] --vsphere-username administrator@vsphere.local Now we will choose the context that has our napp deployment, which should be napp-ns-default, and for this we use the following command kubectl config use-context [context_name]
We will validate the compatible versions of TKR available in the content library linked to that namespace, using the following command kubectl get tkr
Here we can see that NAPPA has published three images in the content library, including the image 1.27.6+vmware.1-fips.1-tkg.1, which is newer and compatible. However, at the time of deployment, the 1.23.8+vmware.3-tkg.1 was used, which is unfortunate because now we have to upgrade the Guest Cluster to reach that version or a higher compatible one according to the interoperability matrix.
Note: During deployment, NAPPA configures a content library called NSX Content Library in the vCenter, with those three images. However, we cannot jump from v1.23.x to v1.27.x as previously mentioned, so we will have to upload the images to that library.
To download and upload the missing images to the content library, we need to go to the following URL https://wp-content.vmware.com/v2/latest/lib.json or we could also create a new Content Library Subscribed with the following URL https://wp-content.vmware.com/v2/latest/lib.json and connect the namespace to that library.
In this case, we will use the first option, and our first jump will be to version v1.24.x
In the repository, we see two images, but we will select the one called ob-22036247-tkgs-ova-photon-3-v1.24.11---vmware.1-fips.1-tkg.1 that is of course compatible according to the interoperability matrix. So we click on it and then right-click on photon-ova.ovf to copy the link.
Now let’s go to the content library NSX Content Library > Actions > Import Library Item and select the URL option, where we will paste the copied link earlier.
Note: In the item name, I recommend using the same name as in the download portal for easy identification.
Click on IMPORT and wait for it to download.
Repeat the steps for the following images that will be the gradual jumps: ob-22757567-tkgs-ova-photon-3-v1.25.13---vmware.1-fips.1-tkg.1 ob-23319040-tkgs-ova-photon-3-v1.26.12---vmware.2-fips.1-tkg.2 ob-23049612-tkgs-ova-photon-3-v1.27.6---vmware.1-fips.1-tkg.1 ob-24026550-tkgs-ova-photon-5-v1.28.7---vmware.1-fips.1-tkg.1
The Content Library should look like the following. Remember that the images we have selected have been chosen considering the interoperability matrix between NSX intelligence and Tanzu Kubernetes Releases.
Now if we run the command kubectl get tkr again, the images we have uploaded should show true in the READY and COMPATIBLE columns.
Note: We should not apply any image that does not meet these conditions.
Now we run the following command to see the next available version of the Kubernetes cluster and the name of the Guest Cluster that we are going to intervene. kubectl get tanzukubernetescluster
We list the Tanzu Kubernetes releases kubectl get tanzukubernetesreleases
We execute the following command to edit the manifest of the Guest Cluster kubectl edit tanzukubernetescluster/CLUSTER-NAME
Here we will edit only the lines of references for the controlplane and nodePools that appear within the topology object
Verify that the output of the kubectl command indicates that the manifest edit was successful
Verify with the following command that the Guest Cluster is updating kubectl get tanzukubernetescluster Note: In the command output, we see that the READY column says False; we must wait for it to appear as True. Patience is key, this may take up to 30 minutes.
Once updated, it should look as follows
We repeat steps 8 to 11 until we reach the target version. For example, our next jump will be to version v1.25.13---vmware.1-fips.1-tkg.1 and so on. However, before doing so, read the following important notes.
At the end, we should see the distribution version as follows
Important Notes
Note 1: We can monitor the process from napp-ns-default > Monitor
In napp-ns-default > Compute, we must wait until the Phase column changes from Updating to Running. However, when Running appears, it does not indicate that it has finished. We can still see events and tasks running in the inventory.
Note 2: During each upgrade jump, we will see how additional nodes are created while the process occurs. The upgrade begins with the Control Plane nodes and then with the Worker nodes. It is important that before starting the next jump, we verify that there are no running tasks, and that the number of nodes in the inventory is correct; in my case, the LAB should only have one Control Plane node and one Worker Node. In the following screenshot, we see one additional node, indicating that it has not yet finished.
Once all activities are completed, we will check that the number of nodes for the Guest Cluster in the inventory is correct. However, we still need to wait for the NAPP solution to stabilize.
Note 3: We should expect the NSX Application Platform solution to appear stable from the NSX console. This may take a few minutes.
Note 4: If we use the Troubleshooting option of the NAPPA (NSX Application Platform Automation Appliance), we can see the moment when all the Pods are up.
We can use the command napp-k get pods -A.
Reference screenshots for additional updates (jumps).
Jump to v1.25.13---vmware.1-fips.1-tkg.1
Jump to `v1.26.12—vmware.2-fips.1-tkg.2
Jump to `v1.27.10—vmware.1-fips.1-tkg.1
Update Kubernetes Tools
Once we have completed the updates and are now on a compatible version according to the NSX Intelligence interoperability matrix, you are likely to see the following alert on the interface. If you are on a version higher than NSX 4.1.2.2, this alert will probably not appear.
Server version v1.27.10+vmware.1-fips.1 and client version v1.23.3 are incompatible. Please upload Kubernetes Tools to resolve.
And that’s all, folks! With this procedure, you will be able to maintain the Kubernetes (K8s) cluster deployed as part of the NSX Application Platform (NAPP) solution.
IMPORTANT! I have migrated the blog from the domain nachoaprendevirtualizacion.com to nachoaprendeit.com. If you found this article useful, please give it a like and share it with your colleagues. These actions will help me optimize search engines to reach more people.
ALL NAMES OF VMS USED IN THIS BLOG ARE INVENTED AND PERTAIN TO A PERSONAL LABORATORY ENVIRONMENT, USED FOR STUDY PURPOSES.
Este post está dirigido para quienes tienen la necesidad de actualizar la versión del clúster de Kubernetes que soporta la solución NSX Application Platform (NAPP). La cual debe estar siempre alineada con la matriz de interoperabilidad de VMware. El proceso que vamos a describir a continuación también debe ser realizado cuando vayamos a realizar una actualización de NSX (que utilice NAPP), vCenter (con vSphere with Tanzu) o VCF (con Workload Management habilitado) para evitar romper la integración con los clústeres de Kubernetes (K8s).
Que es el NAPP
NSX Application Platform (NAPP) es una plataforma basa en microservicios que aloja varias funciones de NSX que recopilan, incorporan y correlacionan información de tráfico de red. A medida que se generan, capturan y analizan los datos en su entorno NSX, NSX Application Platform proporciona una plataforma que puede escalar dinámicamente en función de las necesidades de su entorno.
La plataforma puede alojar las siguientes funciones de NSX que recopilan y analizan los datos en su entorno NSX-T.
Para quienes no tienen claro qué conforma un despliegue de NAPP (NSX Application Platform), podemos dejar una imagen que resume los componentes del despliegue. Donde el componente principal para soportar la solución de NAPP, es la solución de vSphere with Tanzu.
Sé que la imagen anterior puede causar terror. Sin embargo, el equipo de ingeniería de VMware By Broadcom ha desarrollado una herramienta llamada NAPPA (NSX Application Platform Automation Appliance) con el fin de facilitar la implementación de cada uno de los componentes que conforman toda la infraestructura de Kubernetes requerida para soportar la solución de NAPP (NSX Application Platform).
De esta manera NAPPA ejecuta flujos de manera automática para, configurar vSphere with Tanzu, que es una solución que nos permite la ejecución de clústeres de K8s directamente sobre el Hipervisor a través de la creación de vSphere Namespaces. De igual manera NAPPA, usando el Supervisor Clúster desplegado con vSphere with Tanzu, crea automáticamente un vSphere namespace, donde se crea un Tanzu Kubernetes Clúster, al cual llamaremos Guest Cluster de ahora en adelante, y es donde la solución de NSX Application Platform toma vida, así como también todos los pods asociados a los servicios de Metric, VMware NSX® Intelligence™, VMware NSX® Network Detection and Response™, VMware NSX® Malware Prevention y VMware NSX® Metrics.
Para no hacer más largo el cuento lo vamos a dejar hasta ahí.
El problema: Versión TKR fuera de soporte
Ahora bien, el problema que vamos a solucionar acá es cómo mantener este Guest Cluster después de haberlo implementado con el NAPPA. Debido a que en muchas ocasiones, dependiendo de la versión del NSX que teníamos al momento de desplegar el NAPP (NSX Application Platform), la versión de dicho cluster puede quedarse en una versión fuera de soporte que puede generar problemas a medida que vamos actualizando nuestro ambiente de vSphere y de NSX.
Para efectos de laboratorio, hemos desplegado la versión más reciente de NAPP 4.2.0 y curiosamente el guest cluster se ha implementado usando la versión de TKR 1.23.8+vmware.3-tkg.1, que a la fecha está fuera de soporte. Este comportamiento es un issue conocido, para la herramienta de NAPPA y para evitar este comportamiento te invito a leer el siguiente post Desplegar NAPP con version de TKR soportado
Análisis de Compatibilidad
De acuerdo con la matriz de interoperabilidad deberíamos cumplir con las siguientes versiones mínimas de TKR.
Como podemos apreciar en la matriz de interoperabilidad, las versiones de TKR por debajo de 1.26.5 usadas por el guest cluster de NAPP, están actualmente fuera de soporte e incluso algunas de ellas podrían no ser compatible con tu NSX Intelligence o con tu vCenter Server.
Nota: El procedimiento explicado a continuación debe realizarse cuando hagamos una actualización de NSX o vCenter Server ya sea como consecuencia de una actualización de VMware Cloud Foundation (VCF) o cuando actualizamos estas soluciones de manera independiente, con el fin de mantener el clúster de NAPP compatible y dentro del soporte de VMware by Broadcom.
Nota: Debemos tener presente que la versión de TKR solo se puede subir de manera gradual, n + 1, es decir que si tenemos la versión 1.23, el primer salto debe ser a la 1.24 y así sucesivamente hasta alcanzar la versión requerida.
Iniciar sesión en el NAPPA vía SSH, con el usuario root ya que desde ahi podremos conectarnos al supervisor cluster sin necesidad de instalar ningún plugin en nuestra VM y vamos a ejecutar el siguiente comando.
Ejecutar el siguiente comando para iniciar conexión al Supervisor cluster. Sino sabes cuál es la IP del Supervisor Cluster solo ve al vCenter Server > Menu > Workload Management > Namespaces > Supervisor Cluster kubectl vsphere login --insecure-skip-tls-verify --server [IP_SupervisorCluster] --vsphere-username administrator@vsphere.local) Ahora vamos a elegir el contexto que tiene nuestro despliegue de napp, que debería ser napp-ns-default y para ello usamos el siguiente comando kubectl config use-context [context_name]
Vamos a validar las versiones compatibles de TKR disponibles en la Libreria de contenido unida a dicho namespace, con el siguiente comando kubectl get tkr Acá podemos apreciar que el NAPPA ha publicado en la librería de contenido tres imágenes, entre ellas la imagen de 1.27.6+vmware.1-fips.1-tkg.1 que es superior y compatible. Pero en el momento del despliegue ha usado la 1.23.8+vmware.3-tkg.1, lo cual es una pena porque ahora nos toca subir el Guest Cluster hasta llegar a esa version o una superior compatible de acuerdo con la matriz de interoperabilidad.
Nota: Durante el despliegue, NAPPA configura una librería de contenidos llamada NSX Content Library en el vCenter, con esas tres imágenes. Sin embargo, no podemos hacer el salto desde la v1.23.x hacia la v1.27.x como ya lo mencionamos antes, así que tendremos que cargar las imágenes a dicha librería.
Para descargar y subir a la librería de contenidos las imágenes que nos faltan debemos ir a la siguiente URL https://wp-content.vmware.com/v2/latest/lib.json o también podríamos crear una nueva Content Library Subsribed con la siguiente URL https://wp-content.vmware.com/v2/latest/lib.json y conectar el namespace con esa librería.
En este caso vamos a usar la primera opción y nuestro primer salto será hacia la versión v1.24.x En el repositorio vemos dos imágenes pero vamos a seleccionar la que se llama ob-22036247-tkgs-ova-photon-3-v1.24.11---vmware.1-fips.1-tkg.1 y que por supuesto sea compatible, de acuerdo con la matriz de interoperabilidad.Así que hacemos clic en ella y luego sobre photon-ova.ovf clic derecho para copiar el link
Vamos ahora a la librería de contenidos NSX Content Library > Actions > Import Library Item y seleccionamos la opción URL, donde vamos a pegar el link copiado anteriormente. Nota: En el item name, recomiendo colocarle el mismo nombre que tiene en el portal de descarga para que sea fácil identificarla.
Clic en IMPORTAR y esperamos que se descargue Repetir los pasos para las siguientes imágenes que seran los saltos graduales:
La Content Library debería verse de la siguiente forma. Recordemos que las imágenes que hemos seleccionado han sido selecionadas teniendo en cuenta la matriz de interoperabilidad entre NSX intelligence y Tanzu Kubernetes Releases. Ahora si lanzamos nuevamente el comando kubectl get tkr, las imágenes que hemos cargado deberían mostrarse con true en la columna READY y COMPATIBLE. OJO! No deberíamos aplicar ninguna imagen que no cumpla con estas condiciones.
Ahora lanzamos el siguiente comando para ver la siguiende versión disponible del cluster de kubernetes y el nombre del Guest Cluster que vamos a intervenir. kubectl get tanzukubernetescluster
Listamos los Tanzu Kubernetes releases kubectl get tanzukubernetesreleases
Ejecutamos el siguiente comando para editar el manifest de Guest Cluster kubectl edit tanzukubernetescluster/CLUSTER-NAME Aqui vamos a editar unicamente las lineas de las referencias para el controlplane y nodePools que aparecen dentro del objeto topology
Verifique en la salida del comando kubectl indique que la edición del manifiesto se realizó correctamente
Verifique con el siguiente comando que el Guest Cluster se este actualizando kubectl get tanzukubernetescluster Nota: En la salida del comando vemos que la columna READY dice False debemos esperar a que aparezca True. La paciencia es la clave, esto puede tomar hasta 30 min.
Una vez actualizada debería verse de la siguiente forma
Repetimos los pasos 8 a 11 hasta llegar a la versión de destino. Por ejemplo nuestro siguiente salto sera ala version v1.25.13---vmware.1-fips.1-tkg.1 y asi susesicamente. Sin embargo, antes de hacerlo lee las siguientes notas importantes.
Al finalizar deberíamos ver la versión de distribución de la siguiente manera
Notas importantes
Nota 1: Podemos monitorear el proceso desde napp-ns-default > Monitor
O en napp-ns-default > Compute debemos esperar hasta que la columna Phase pase de Updating a Running. Sin embargo, cuando aparece Running no indica que ya ha terminado. Aún podemos ver eventos y tareas corriendo en el inventario.
Nota 2: Durante cada salto de actualización veremos como se crean nodos adicional mientras ocurre el proceso. La actualización comienza por los nodos del Control Plane y despues en los nodos Worker. Es importante que antes de iniciar con el siguiente salto, verifiquemos no se encuentren tareas en ejecución, que la cantidad de nodos en el inventarios sea la correcta, en mi caso del LAB debería tener únicamente un Control Plane node y un Worker Node. En el siguiente pantallazo vemos un nodo de más, es decir que aún no ha terminado.
Una vez terminan todas las actividades, vamos a ver que el numero de nodos para el Guest Cluster en el inventario es el correcto. Sin embargo, aún debemos esperar que la solucion del NAPP se estabilice.
Nota 3: Debemos esperar que la solución de NSX Application Platform se muestre estable desde la consola de NSX. Esto puede tardar algunos minutos.
Nota 4: Si utilizamos la opción de Troubleshooting del NAPPA (NSX Application Platform Automation Appliance), podemos ver el momento en el que todos los Pods estén arriba.
o podemos usar el comando napp-k get pods -A
Screenshots de referencia para los actualizaciones (saltos) adicionales.
Salto a v1.25.13---vmware.1-fips.1-tkg.1
Salto a v1.26.12---vmware.2-fips.1-tkg.2
Salto a v1.27.10---vmware.1-fips.1-tkg.1
Actualizar Kubernetes Tools
Una vez hemos terminado con las actualizaciones y nos encontremos ahora en una versión compatible de acuerdo con la matriz de interoperabilidad de NSX Intelligence. Es probable que vea la siguiente alerta en la interface. Si estas en una version superior a NSX 4.1.2.2 seguramente no te va a salir esta alerta.
Server version v1.27.10+vmware.1-fips.1 and client version v1.23.3 are incompatible. Please upload Kubernetes Tools to resolve.
¡Y eso es todo amigos! Con este procedimiento vas a poder darle mantenimiento al cluster de Kubernetes (K8s) desplegado como parte de la solución NSX Application Platform (NAPP).
¡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.
TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.
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.
Now we will choose the context that has our napp deployment, which should be 
Repeat the steps for the following images that will be the gradual jumps:
Now if we run the command 
Nacho Aprende IT 