Etiqueta: vvf

Mejores Prácticas para Implementar IDPS con VMware vDefend

en por Diego Felipe Tunubalá Medinaen NSX, VCF/VVFDeja un comentario

Si andan metidos en el mundo de la seguridad con VMware vDefend (lo que muchos seguimos llamando con cariño NSX Security), sabrán que implementar un IDPS Distribuido (D-IDPS) no es solo hacer «Next, Next, Finish». Es una bestia potente que vive en el hipervisor, y si no se configura con cabeza, podemos degradar el rendimiento de nuestros hosts ESXi.

Recientemente me puse a analizar documentación sobre este tema y aquí les traigo el resumen «masticadito» con las Best Practices que necesitan saber para desplegar esto en producción sin morir en el intento.

Así que si tienes que asegurar el tráfico East-West, toma nota.

CONTENIDO

  1. Antes de comenzar
  2. Casos de Uso: ¿Para qué activamos esto?
  3. Arquitectura: ¿Qué pasa realmente con el paquete?
  4. Sizing: Las «Reglas de Oro» de Recursos por Host
  5. Estrategias de Despliegue
  6. Optimización del IDPS
  7. Day 2: Operaciones y Troubleshooting
  8. Day 2: Firmas y Ciclo de Vida
  9. Testear el funcionamiento del IDPS
  10. Conclusión

1. Antes de comenzar

Antes de tocar cualquier configuración, necesitas visibilidad. No vueles a ciegas. Para obtener el máximo beneficio de la solución, se recomienda entender detalladamente las siguientes métricas para cada clúster antes de habilitar el IDPS.

Métricas de Infraestructura y Red:

  • CPU Usage per host: Vital, recuerda que necesitas cores libres.
  • Memory Usage per host: Crítico por la reserva de RAM.
  • Packets per second (PPS): La métrica reina (el límite ronda los 150K).
  • Total Connections & CPS: Volumen y tasa de conexiones .
  • Throughput & Packet Sizes: Ancho de banda y tamaño de paquete.
  • Logging Rates: Fundamental para no saturar tu SIEM si estas exportando hacia allá.

Datos Clave para el Despliegue: Adicionalmente, ten clara esta data antes de desplegar :

  • ¿Qué VMs y Sistemas Operativos vamos a proteger?
  • ¿Qué Grupos usaremos en el campo «Apply To»?
  • ¿Qué protocolos/aplicaciones están en uso?

Recurso Gratuito: Utiliza el dashboard «IDPS Planner» para Aria Operations. Te da estos datos masticados.

Pasted image 20260121195120.png

O utilizando las métricas de Aria Operations for Networks

Pasted image 20260121195042.png

2. Casos de Uso: ¿Para qué activamos esto?

Esta tecnología aporta valor real frente a un IDS perimetral. No lo actives «porque sí», actívalo para resolver esto:

  • Visibilidad East-West (La Joya de la Corona): Los IDS tradicionales están en el borde. Una vez que el atacante entra, se mueve lateralmente ciego a tus controles . vDefend está pegado a la carga de trabajo, dándote visibilidad exacta de amenazas internas.
  • Virtual Patching (El Salvador de Legacy): Todos tenemos ese servidor con Windows 2008 o una App legacy que no se puede parchear hoy. El IDPS actúa como un «parche virtual»: detecta y bloquea el exploit de la vulnerabilidad conocida antes de que toque el SO, dándote tiempo para planificar.
  • Cumplimiento Normativo (Compliance): Normativas como PCI DSS o HIPAA exigen explícitamente controles de intrusión. vDefend te permite cumplir esto granularmente sin rediseñar la red física.
  • Seguridad para VDI: Los escritorios virtuales son entornos «sucios» por definición. Aplicar IDPS aquí protege al resto del Data Center de lo que tus usuarios puedan traer.

3. Arquitectura: ¿Qué pasa realmente con el paquete?

Para entender el impacto, hay que entender el flujo. El problema de los IDS tradicionales y firewalls físicos es el «hair-pinning»: tienes que sacar el tráfico del host, llevarlo al appliance físico para inspeccionarlo y devolverlo. Eso es ineficiente y complejo de diseñar.

vDefend cambia el juego colocando el control de seguridad directamente en la vNIC de cada máquina virtual.
Pasted image 20260121190457.png

El flujo interno («Under the hood»): El tráfico no se procesa mágicamente. Sigue este camino dentro del host ESXi:

  1. DFW Primero: El paquete pasa primero por el filtro del Distributed Firewall (vmware-sfw) en el kernel.
  2. Punt al IDPS: Si el tráfico coincide con una política definida para inspección (una «Inspect Policy»), se marca para ser analizado.
  3. Memoria Compartida: El paquete se copia a una región de memoria compartida (Shared Memory Region) a través del canal dvFilter.
  4. User Space Engine: El motor de IDPS (que corre en espacio de usuario, no en kernel) recoge el paquete de ese anillo de memoria, lo analiza con sus worker threads y emite un veredicto.

Nota: Este intercambio entre Kernel y User Space es crítico. Si el motor no vacía el buffer lo suficientemente rápido, los paquetes se descartan silenciosamente.

Pasted image 20260121192727.png

4. Sizing: Las «Reglas de Oro» de Recursos por Host

Muchos ignoran hasta que tienen problemas. Para que ese motor en User Space funcione, necesitamos reservar recursos físicos del host ESXi. Según la documentación vDefend Distributed IDPS Performance Recommendations, estos son los límites y requisitos que debes respetar:

RecursoRequisitoNotas
CPUHasta 5 CoresSe recomiendan hasta 5 cores adicionales libres por host para los worker y receiver threads.
Memoria2 GB de RAMDato crítico: A partir de la versión 4.1, se reservan 2 GB de memoria del host.
Cuidado con el overcommitment en tus clústeres.
Red~150K PPSEl límite de throughput por host es de aproximadamente 150,000 Paquetes Por Segundo.

¿Qué pasa si supero el limite? (Bypass vs. Drop)

Si saturas el host (CPU o Red), el sistema entra en modo «Oversubscription». Aquí es vital tener versiones modernas:

  • vDefend 4.2.0 + ESXi 8.0u3: Soporta Bypass (dejar pasar tráfico) por CPU, Memoria y Red. Esto evita cortes de servicio ante picos de tráfico.
  • Versiones anteriores (3.2.x): No tenían capacidad de bypass y podían causar drops.
Pasted image 20260121214544.png

Nota: El sistema puede aplicar este Bypass de forma Global o puedes hacer un override Por Regla.
Nota: No hay granularidad en la causa. Si se satura cualquier recurso (CPU, RAM o Red), la acción seleccionada se ejecuta independientemente de qué recurso esté al límite . Configúralo con sabiduría según tu postura de seguridad.

5. Estrategias de Despliegue

Dependiendo de tus métricas analizadas en el primer paso, tienes dos caminos claros:

a). La Estrategia «No Recomendada pero Útil» (<150K PPS)

Si tus métricas muestran que todos tus hosts están cómodamente por debajo de 150K PPS y sobran CPU/RAM, podrías optar por una política general ANY ANY.

Pasted image 20260121193516.png

De esta manera tenemos un despliegue rápido para proteger toda la infraestructura (PROD, DEV, QA) organizada por Grupos o Unidades de Negocio, detectando ataques conocidos en tiempo récord. Sin embargo, probablemente vamos a levantar muchos falsos positivos y vamos a desperdiciar el recurso IDPS.

b). La Estrategia Quirúrgica (Hosts Saturados o Críticos)

Si tienes mucho tráfico, aplica ingeniería de precisión usando perfiles personalizados:
Perfiles por S.O.: No uses el mismo perfil para todo. Crea un perfil de firmas específico para Windows, otro para Linux o incluso para aplicaciones específicas (ej. Apache, SQL).
De esta manera reducimos la carga de inspección y eliminamos falsos positivos irrelevantes (ej. no buscar vulnerabilidades de Linux en un servidor Windows).

6. Optimización del IDPS

Para no quemar CPU a lo tonto, sigue estos principios al definir tu política:

  • El Mandamiento Supremo: «Apply To»: Nunca dejes esto en «Distributed Firewall». Usa siempre Grupos. Limita el scope para que el motor solo se instancie en las vNICs de las VMs miembro del grupo.
  • Direccionalidad Inteligente: El IDPS puede inspeccionar IN, OUT o ambos. A veces, inspeccionar ambos es un desperdicio si el tráfico ya pasó por el motor.
    Define bien si inspeccionas la entrada o la salida para ahorrar recursos según el flujo de la aplicación.
  • Excluye Backups y Tráfico Pesado: El tráfico de alto volumen como SMB o Backups suele superar los límites de PPS y aporta poco valor de inspección.
  • Tuning de Protocolo (IPv6): Si tus servidores solo hablan IPv4, configura la regla en el FW Distribuido o Gateway Firewall para que el protocolo sea explícitamente IPv4. Si dejas IPv6 habilitado (que muchos SO traen por defecto), estarás enviando tráfico basura al motor.
  • Usa Tags y Grupos: Olvídate de las IPs estáticas. Usa Tags (Scope: Zone, Tag: DMZ) para que las reglas se apliquen dinámicamente a las cargas de trabajo correctas.

7. Day 2: Operaciones y Troubleshooting

Una vez implementado, hay que operarlo. Aquí mis recomendaciones para el «Día 2».

Gestión de Perfiles (Profiles) No actives todas las firmas a lo loco.

  1. Empieza filtrando solo por severidad «Critical» y «High».
    Pasted image 20260121214421.png
  2. Empieza siempre en modo Detect Only (solo alerta). Pasa a Detect & Prevent (bloqueo) solo después de validar que no hay falsos positivos.
    Pasted image 20260121215312.png
  3. TIP: Cuando pases a Detect & Prevent mode, debes asegurarte de cambiar ademas el comportamiento de la acción, de firmas involucradas en el evento, de Alert a Reject o Drop. Algunas firmas vienen configuradas con su acción por default en Alert, de manera que aunque cambies a Detect & Prevent no bloquearás tráfico a menos que cambies el comportamiento de la acción.
    Pasted image 20260121215502.png
  4. Comenzar con un perfil de cobertura amplia y una amplia aplicación.
    • Por ejemplo, CVE: > 7.0.
    • Por ejemplo, Attack-Target: Client-Endpoint, Server and Client for EUC.
  5. Opcionalmente, con el tiempo, incluir solo las firmas relevantes en un perfil y aplicarlo a cargas de trabajo específicas.
    • Attack target: servidor DNS, servidor AD, servidor web.
    • Affected product
  6. Recuerda que tienes un límite de perfiles disponibles dependiendo de las version de NSX. NSX 4.2.3 Configuration Limits

Log Forwarding: Si envías logs a un SIEM (como Splunk), asegúrate de configurar el Syslog sobre TCP.
Si usas UDP, el paquete se limita a 400 Bytes. Un log de IDPS suele ser más largo, así que se cortará y perderás la mitad de la información del ataque.

Comando de Pánico para Troubleshooting ¿Sospechas que estás tirando paquetes por falta de CPU o Memoria? Entra por SSH al host ESXi y lanza este comando:

vsipioctl getdpiinfo -s

Fíjate en el contador packets_freed_in_error. Si es mayor que 0 (ej. >500-1000), estás teniendo problemas de pérdida de paquetes por saturación del buffer o falta de CPU.

8. Day 2: Firmas y Ciclo de Vida

El IDPS no es «Dispara y olvida». Debes garantizar que la base de datos de firmas este actualizada.

Actualizaciones de firmas del vDefend Threat Intelligence Service (vTIS): Las firmas son el corazón del sistema. Las versiones recientes de NSX buscan actualizaciones automáticamente cada cuatro horas. Si la firma está en tu perfil, la actualización aplica inmediatamente.

9. Testear el funcionamiento del IDPS

Una vez hemos creados los perfiles y aplicadas las reglas de IDPS, podemos esperar a la ocurrencia de eventos maliciosos o usar metodologias de Testeo similares a EICAR test para A/V.

Estos test generaran alertas. Sin embargo, ningún contenido malicioso es descargado al cliente que solicita el payload, pero si generan los eventos en el IDPS que nos permiten verificar el funcionamiento de la solución.

Pasted image 20260121215041.png

Conclusión

Operacionalizar vDefend IDPS no se trata solo de encender un switch; requiere planificación. Conocer sus aplicaciones y flujos de tráfico es el 90% del éxito. Si siguen estas prácticas, especialmente el cuidado con los límites de PPS y el diseño de políticas específicas, podrán asegurar sus cargas de trabajo críticas sin sacrificar el rendimiento.

¡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.

Generalidades del Upgrade a VCF 9.x

en por Diego Felipe Tunubalá Medinaen VCF/VVFDeja un comentario

¡Hola a todos! Después de mucho movimiento en la comunidad y tras analizar las últimas novedades de Broadcom, hoy vamos a tratar un tema que sé que a muchos de ustedes les quita el sueño: el salto a VMware Cloud Foundation (VCF) 9.0.

Recientemente se llevó a cabo un webinar muy completo donde se despejaron las dudas más críticas sobre la transición desde la versión VCF 5.2. Hemos tratado de resumir todo esa Webinar trayendo los puntos clave, al mejor estilo de NachoAprende. Sin embargo, si quieres profundizar te dejo el link del webinar al final.

Pasted image 20260105151005.png
  1. El nuevo centro de mando: SDDC Manager se integra
  2. vSAN OSA: No entren en pánico
  3. La secuencia de actualización crítica
  4. Componentes obligatorios: VCF Operations y Fleet Management
  5. El reto de la Identidad: Adiós a vIDM
  6. Diseño consolidado y límites de Host
  7. Manejo de binarios y depósitos
  8. Rollback: No hay «botón de pánico» mágico
  9. Información Adicional
  10. Recursos

El nuevo centro de mando: SDDC Manager se integra

Aunque el motor de parches asíncronos sigue siendo el mismo que conocimos en la versión 5.2, la gran novedad es la consolidación de interfaces. Ahora, la interfaz de SDDC Manager vive dentro de la consola de VCF Operations, específicamente en la sección de Fleet Management. Esto busca que no tengamos que saltar entre diferentes portales para gestionar la flota de componentes.

Pasted image 20260105192528.png

vSAN OSA: No entren en pánico

Muchos me han preguntado si el hardware actual servirá si no pueden saltar a ESA. La respuesta es un rotundo sí: vSAN OSA no está depreciado ni va a desaparecer en VCF 9.0. Es la mejor opción para seguir aprovechando la inversión en hardware actual de forma eficiente. Eso sí, verifiquen la matriz de compatibilidad de firmware para la versión 9.0 antes de empezar.

La secuencia de actualización crítica

En VCF, el orden de los factores sí altera el producto. Para no romper nada, debemos seguir este flujo secuencial:

  1. VCF Operations (antes Aria Operations).
  2. SDDC Manager (el workflow de actualización del propio manager).
  3. VMware NSX.
  4. VMware vCenter.
  5. Hosts ESXi.
Pasted image 20260105155133.png

Componentes obligatorios: VCF Operations y Fleet Management

Si actualmente no usan Aria Suite, ¡atención! Durante el upgrade a VCF 9.0, el sistema desplegará automáticamente VCF Operations y VCF Operations Fleet Management (antiguo Aria Lifecycle). En la versión 9.0, estos componentes ya no son opcionales, son parte core de la plataforma.

Pasted image 20260105193936.png

El reto de la Identidad: Adiós a vIDM

Este es un punto donde deben tener mucho cuidado: no existe un camino de actualización directa desde VMware Identity Manager (vIDM) hacia el nuevo VCF Identity Broker (VIDB). Si utilizan VCF Automation, deben realizar un despliegue «greenfield» (desde cero) del VIDB. Tomen esto en cuenta para sus planes de actualización.

Diseño consolidado y límites de Host

Para quienes están diseñando nuevos entornos consolidados en VCF 9.0, la recomendación es de un mínimo de cuatro hosts para despliegue greenfield en Alta disponibilidad o tres host para un despliegue Simple. Ver Single-Rack Cluster Model Sizing Considerations
Sin embargo, si están convergiendo una infraestructura existente con vSAN, el mínimo absoluto son tres hosts, aunque cuatro es lo ideal para mantener la redundancia. En cuanto a los límites máximos, se mantienen los de vSphere: 96 hosts por clúster y hasta 2,500 hosts por vCenter.

Pasted image 20260105194751.png
Pasted image 20260105194809.png

Manejo de binarios y depósitos

La ubicación de los binarios depende de su punto de partida:

• Si no tienen Aria: Deben descargar y desplegar las VMs de VCF Operations y Fleet Management primero, y luego bajar los binarios al «depot» dentro de Fleet Management.
• Si están convergiendo de vSphere a VCF: El VCF Installer se encarga de desplegar lo que falte, por lo que los binarios deben estar en el instalador.

Pasted image 20260105154334.png

Rollback: No hay «botón de pánico» mágico

Lamentablemente, no existe un botón de «deshacer» que revierta todo el stack de VCF a la vez si algo falla. Mi recomendación es que traten cada paso como un checkpoint independiente. Hagan un backup de cada componente (SDDC Manager, NSX, vCenter) justo antes de su turno en la secuencia. Si algo falla, pueden revertir ese componente específico para investigar o contactar a soporte antes de que expire su ventana.

¡OJO! Si su infraestructura depende de VMware Cloud Director (VCD), deténganse: actualmente no es compatible con VCF 9.0 y no hay rutas de migración oficiales por ahora.

Como siempre digo, la planificación es el 90% del éxito en estos upgrades de infraestructura. Si sienten que el proceso les supera, los servicios profesionales de VMware By Broadcom están ahí para ayudar en transiciones complejas.

Información Adicional

Pasted image 20260105153247.png
Pasted image 20260105153700.png

Recursos: Webinar Completo

¡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.

Si ya realizaron si upgrade a VCF 9.0 comenta ¿Qué les parece este salto a la versión 9.0? para los que no ¿Ya están preparando sus laboratorios? ¡Los leo en los comentarios!

TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.

Solucionando error «Downloading content from content repo failed» en Aria Suite Lifecycle Manager 8.18.x

en por Diego Felipe Tunubalá Medinaen Aria Suite / vRealize Suite, vRealize Suite Lifecycle Manager/Aria Suite LifecycleDeja un comentario

En esta oportunidad vamos a resolver rapidamente un problema con el que me encontré en la version de Aria Suite Lifecycle Manager 8.18, al intentar agregar las licencias para la instalación de los productos de Aria.

De manera que si estas intentando agregar la licencia de Aria Suite en el Aria Suite lifecycle Manager y nos da el siguiente error

Downloading content from content repo failed.
Pasted image 20250909102309.png

Y en la descripción del Request dice lo siguiente:

Error Code: LCMLICENSINGCONFIG11007
Downloading content from content repo failed.
Downloading content from content repo failed due to com.vmware.vrealize.lcm.plugin.core.licensing.common.exception.LicensingException: Downloading content from content repo failed. With /tmp/dlfRepo.zip
Pasted image 20250909102424.png

Probablemente vamos a poder solucionarlo como se indica en Downloading content from content repo failed.» Error when you try to Add License Manually from Aria Suite Lifecycle Locker y resumimos acá de la siguiente manera.

Procedimiento

Vamos Lifecycle Operations > Settings > System Details y hacer click en el check del FIPS Mode Compliance

Pasted image 20250909102655.png

Pasted image 20250909102735.png
Pasted image 20250909103055.png

Ahora intentamos agregar de nuevo la licencia desde el servicio de Locker

Pasted image 20250909103018.png

y verémos que ahora la validación funciona y podemos agregar nuestra licencia sin problemas

Pasted image 20250909103505.png
Pasted image 20250909103405.png
Pasted image 20250909103621.png

Conclusion

Esto es todo amigos, de esta manera salimos de este pequeño bache en nuestro proceso de implementación de los productos de aria suite y podemos continuar las tareas de despliegue que tengamos programadas.

¡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.

Resumen de los What’s New vSphere 8.0 U1, U2 y U3

en por Diego Felipe Tunubalá Medinaen ESXi, vCenter Server, VCF/VVF, VSAN, vSphere, vSphere ReplicationDeja un comentario

¡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.

Novedades de vSphere 8.x – What’s New vSphere 8.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.

Novedades Clave de vSphere 8.0 U3: Mejoras y Funcionalidades

en por Diego Felipe Tunubalá Medinaen ESXi, vCenter Server, VCF/VVF, VSAN, vSphere, vSphere ReplicationDeja un comentario

¡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.

CONTENIDO

  1. Release Timeline y Deprecaciones
  2. vSphere Supervisor
  3. Lifecycle Management
  4. Hardware Support
  5. Availability & Resilience
  6. Workloads y eficiencia
  7. Seguridad y Cumplimiento
  8. Storage
  9. Conclusión
  10. Recursos

Release Timeline y Deprecaciones

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.
Pasted image 20250822183731.png

  • 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.

      Pasted image 20250822183809.png

  • 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.

    Pasted image 20250822183853.png

  • 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.

    Pasted image 20250822183955.png

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.
    • Imagen única para Dual DPU.
    • Personalización avanzada de imágenes (remover addons, drivers, VMware Tools, Host Client).
Pasted image 20250822184155.png

Hardware Support

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.
Pasted image 20250822184246.png
Pasted image 20250822184313.png

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.

    Pasted image 20250822184347.png

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.
Pasted image 20250822184427.png

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.

      Pasted image 20250822184602.png


      Pasted image 20250822184612.png

  • Fault Tolerance para Metro Clusters (vSAN y no-vSAN): permite ubicar primario y secundario en sitios distintos.

Pasted image 20250822184629.png

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.
Pasted image 20250822184733.png

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.
Pasted image 20250822184836.png

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.

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.

Novedades Clave de vSphere 8.0 U2: Mejoras y Funcionalidades

en por Diego Felipe Tunubalá Medinaen ESXi, vCenter Server, VCF/VVF, VSAN, vSphere, vSphere ReplicationDeja un comentario

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.

CONTENIDO

1. Eficiencia Operacional Mejorada

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.

Pasted image 20250226103238.png

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.

Pasted image 20250226105032.png

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.

Pasted image 20250226105044.png

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.

Pasted image 20250226105805.png

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.

Pasted image 20250226110011.png

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.

Pasted image 20250226113423.png

Soporte Mejorado para Sistemas Operativos Invitados

En esta versión tenemos la posibilidad de personalizar OUs en Active Directory al unir un sistema Windows.

Pasted image 20250226113532.png

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.

Pasted image 20250226113628.png

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.

Pasted image 20250226113928.png

  • 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.

Pasted image 20250226114322.png
  • 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.
Pasted image 20250226114429.png

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.

Pasted image 20250226115154.png
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.

Pasted image 20250226115259.png

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.

Novedades Clave de vSphere 8.0 U1: Mejoras y Funcionalidades

en por Diego Felipe Tunubalá Medinaen ESXi, vCenter Server, VCF/VVF, VSAN, vSphere, vSphere ReplicationDeja un comentario

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.

CONTENIDO

  1. Administración Eficientemente
  2. Mejoras en Seguridad
  3. Potenciar Cargas de Trabajo
  4. Conclusión
  5. Recursos

Novedades de vSphere 8 Update 1

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.

Pasted image 20250225174917.png
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.

Pasted image 20250225174820.png

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.

Pasted image 20250225191327.png

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.

Pasted image 20250225191421.png

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.

Pasted image 20250225175902.png
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.

Pasted image 20250225181539.png

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.

Pasted image 20250225191508.png

Adicionalmente, los desarrolladores pueden ahora lanzar la consola de las VMs utilizando el comando kubectl sin necesidad de tener acceso al vCenter Server.

Pasted image 20250225183558.png

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.

Pasted image 20250225185554.png

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.

Pasted image 20250225190239.png
Pasted image 20250225190313.png

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.

Pasted image 20250225191211.png

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.

Pasted image 20250225191143.png

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.

Pasted image 20250225191635.png

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

Pasted image 20250225192051.png

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.

Novedades Clave de vSphere 8.0 GA: Mejoras y Funcionalidades

en por Diego Felipe Tunubalá Medinaen ESXi, vCenter Server, VCF/VVF, VSAN, vSphere, vSphere ReplicationDeja un comentario

¡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.

Novedades de vSphere 8.x

CONTENIDO


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.

Pasted image 20250207141942.png

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!

Pasted image 20250207141902.png

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.

Pasted image 20250207142111.png

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.

Pasted image 20250207181935.png

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.

Pasted image 20250207142702.png

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.

Pasted image 20250207143743.png

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.

Pasted image 20250207144000.png

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.

Pasted image 20250207145655.png

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.

Pasted image 20250207162837.png

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.
Pasted image 20250207150119.png
Pasted image 20250207163109.png

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.

Pasted image 20250207183543.png

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.
Pasted image 20250207184427.png

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.

Pasted image 20250207185114.png

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.

Pasted image 20250207185302.png

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.

Pasted image 20250207185410.png

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.

Pasted image 20250207185451.png

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.

Pasted image 20250207185731.png

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.

Pasted image 20250207190231.png

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.

Pasted image 20250207190506.png

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.

Migrando objetos del Manager al Policy en NSX

en por Diego Felipe Tunubalá Medinaen NSX, VCF/VVFDeja un comentario

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.

CONTENIDO

Escenario

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.

Pasted image 20250707101236.png

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.

Pasted image 20250707101303.png

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.

Pasted image 20250707101318.png

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!

  1. 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.
    Pasted image 20250707102628.png

  2. 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.
    Pasted image 20250707111236.png

  3. 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

    Pasted image 20250707103059.png

  4. 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.
    Pasted image 20250707103214.png

  5. Click en START OBJECT PROMOTION para comenzar con el proceso promoción y visualizar cuales objetos vas a ser movidos.
    Pasted image 20250707103305.png

  6. Clic en CONTINUE para iniciar la migración
    Pasted image 20250707103315.png

  7. Esto tomará solo unos pocos segundos y podremos ver que la migración ha terminado satisfactoriamente.
    Pasted image 20250707103419.png

  8. Para ver el detalle o resumen de lo que se hizo, podemos hacer clic en el link que aparece frente a Recent Activity
    Pasted image 20250707103441.png


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.

Pasted image 20250707103454.png

Después de la migración, los objetos creados en el Manager Mode van a tener icono del Policy

Pasted image 20250707103535.png

Y en el Policy Mode ya debemos ver los Segmentos disponibles que antes solo se veían en el Manager Mode

Pasted image 20250707103738.png

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.

Pasted image 20250707112545.png

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

Pasted image 20250707104126.png

Las opciones disponibles son las siguientes:

Activar o desactivar visibilidadDescripción
Visible para todos los usuariosSi hay objetos del modo Manager presentes, los botones de modo son visibles para todos los usuarios.
Visible para usuarios con el rol de administrador empresarialSi hay objetos del modo Manager presentes, los botones de modo son visibles para los usuarios con el role Enterprise Admin.
Oculto para todos los usuariosIncluso 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 predeterminadoSe 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

Pasted image 20250707104227.png
Pasted image 20250707104148.png

De esta manera ya no aparecerá la opción de seleccionar entre Policy o Manager cuando entramos al la UI del NSX

Pasted image 20250707104339.png

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.

Updating Kubernetes Cluster (K8s) for NAPP Deployment

en por Diego Felipe Tunubalá Medinaen NSX, VCF/VVFDeja un comentario

CONTENT

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.

  • VMware NSX® Intelligence™
  • VMware NSX® Network Detection and Response™
  • VMware NSX® Malware Prevention
  • VMware NSX® Metrics

For more information, we can consult the official documentation NSX Application Platform Overview.

NAPP Deployment

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.

Pasted image 20241008201848.png

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.

Pasted image 20241008204215.png

Compatibility Analysis

According to the interoperability matrix, we should meet the following minimum versions of TKR.

Pasted image 20241009201638.png
Pasted image 20241009201659.png

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.

Without further ado, let’s go to the Lab!

Solution

The first thing we will do is follow the documentation Update a TKG Cluster by Editing the TKR Version, but don’t worry, here we will explain it step by step.

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.

  1. 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.
    Pasted image 20241008205643.png
  2. 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
    Pasted image 20241008205737.png
    kubectl vsphere login --insecure-skip-tls-verify --server [IP_SupervisorCluster] --vsphere-username administrator@vsphere.local
    Pasted image 20241008210229.png 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]
    Pasted image 20241008210416.png

  3. We will validate the compatible versions of TKR available in the content library linked to that namespace, using the following command
    kubectl get tkr
    Pasted image 20241008210538.png
    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.
    Pasted image 20241008210919.png

  4. 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
    Pasted image 20241008211501.png
    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.

    Pasted image 20241008211758.png

  5. 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.

    Pasted image 20241008214718.png

    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.


    Pasted image 20241008214744.png 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.


    Pasted image 20241008222258.png 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.

    Pasted image 20241008222327.png

  6. 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
    Pasted image 20241008222057.png
  7. We list the Tanzu Kubernetes releases
    kubectl get tanzukubernetesreleases
    Pasted image 20241008222410.png
  8. We execute the following command to edit the manifest of the Guest Cluster
    kubectl edit tanzukubernetescluster/CLUSTER-NAME
    Pasted image 20241008222735.png
    Here we will edit only the lines of references for the controlplane and nodePools that appear within the topology object
    Pasted image 20241008223241.png
  9. Verify that the output of the kubectl command indicates that the manifest edit was successful
    Pasted image 20241008223302.png
  10. Verify with the following command that the Guest Cluster is updating
    kubectl get tanzukubernetescluster
    Pasted image 20241008223750.png
    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.
  11. Once updated, it should look as follows
    Pasted image 20241008224344.png
  12. 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.
  13. At the end, we should see the distribution version as follows
    Pasted image 20241009141240.png

Important Notes

Note 1: We can monitor the process from napp-ns-default > Monitor

Pasted image 20241008224450.png

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.

Pasted image 20241008225555.png

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.

Pasted image 20241008234330.png

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.

Pasted image 20241009103042.png

Note 3: We should expect the NSX Application Platform solution to appear stable from the NSX console. This may take a few minutes.

Pasted image 20241009111506.png
Pasted image 20241009111527.png

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.

Pasted image 20241009111711.png
Pasted image 20241009111916.png

We can use the command napp-k get pods -A.

Pasted image 20241010183303.png

Reference screenshots for additional updates (jumps).

Jump to v1.25.13---vmware.1-fips.1-tkg.1

Pasted image 20241008230058.png
Pasted image 20241008230130.png
Pasted image 20241008232632.png

Jump to `v1.26.12—vmware.2-fips.1-tkg.2

Pasted image 20241008232740.png
Pasted image 20241008234210.png
Pasted image 20241009105148.png

Jump to `v1.27.10—vmware.1-fips.1-tkg.1

Pasted image 20241009105012.png

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.

Pasted image 20241009112714.png

To resolve this alert, simply follow the next KB NAPP pane in NSX UI shows message "Server version and client version 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.