Tuning de performance para Workloads sensibles a la latencia Latency-Sensitive) en vSphere 8

en 4 junio, 20264 junio, 2026 por Diego Felipe Tunubalá Medinaen ESXi, VCF/VVF, vSphereDeja un comentario

Si administras infraestructura vSphere y tienes workloads que simplemente no pueden darse el lujo de esperar — sistemas de trading financiero, plataformas de streaming en tiempo real, o control industrial — este artículo es para ti.

VMware by Broadcom publicó en enero 2025 una guía técnica completa sobre cómo optimizar vSphere 8 para este tipo de cargas. El problema es que ese documento asume que ya sabes mucho. Aquí te traigo lo más útil y accionable, explicado de verdad, sin más preámbulo.

CONTENIDO

¿De qué hablamos cuando decimos latency-sensitive?
Baseline Requirements — antes de tocar cualquier cosa
Host Considerations — empezando desde el BIOS
VM Considerations — el sizing importa más de lo que crees
Latency Sensitivity por VM — el setting que muchos ignoran
- Cómo activarla (3 pasos obligatorios)
- Parámetros avanzados adicionales
Networking — VMXNET3 y más allá
Comandos de operación útiles
Conclusion

¿De qué hablamos cuando decimos latency-sensitive?

Antes de entrar en configuraciones, hay que entender qué problema estamos resolviendo, porque si aplicas todo esto a las VMs equivocadas, solo vas a complicarte la vida.

Latencia, en este contexto, es el tiempo que tarda una aplicación en recibir un dato, procesarlo y responder. Para la mayoría de las aplicaciones empresariales, unos milisegundos de más no importan. Pero hay aplicaciones donde ese retardo sí importa — y mucho.

Hablamos de cosas como:

Una plataforma que procesa órdenes de bolsa en tiempo real, donde microsegundos de diferencia pueden costar dinero.
Un sistema de control de manufactura que necesita responder a una señal del piso de producción sin demora.
Una plataforma de broadcast de video en vivo donde cualquier jitter (variación en el tiempo de entrega de paquetes) se ve como glitch en la pantalla del usuario final.

Estas aplicaciones necesitan acceso constante y predecible al procesador y a la red. El problema es que vSphere, por defecto, está configurado para hacer algo muy diferente: consolidar workloads y ser eficiente. Eso significa compartir recursos, hacer balanceo dinámico, y priorizar el uso eficiente de CPU sobre el acceso inmediato a ella. Para workloads normales eso es perfecto. Para estos, es exactamente lo que no queremos.

Lo que vamos a hacer en este artículo es ajustar vSphere para que, en lugar de compartir y balancear, garantice y dedique. Y eso empieza mucho antes de tocar una VM — empieza en el BIOS del servidor físico.

⚠️ ¡OJO! Broadcom es muy explícito en esto: testea todo en non-production primero. Muchos de estos settings aumentan el consumo de CPU y pueden impactar negativamente otros workloads en el mismo host si no se aplican con criterio.

Baseline Requirements — antes de tocar cualquier cosa

Antes de ajustar un solo parámetro, confirma que tu ambiente cumple con lo mínimo recomendado. Aplicar tuning de performance sobre versiones viejas de software o hardware desactualizado es tirar tiempo — las optimizaciones que vamos a ver dependen de capacidades que solo existen en versiones recientes.

Componente	Requerimiento mínimo	¿Por qué importa?
vSphere	8.0 U3 (o mínimo 7.0 U3)	Las mejoras de scheduling y vTopology automática llegaron en estas versiones
Virtual Hardware	Versión 21 o superior	Las versiones viejas pueden bloquear instrucciones del procesador que necesitamos
VM Tools	12.4.5 o superior	Afecta la comunicación entre el guest OS y el hypervisor
Procesadores	Generación actual con BIOS/microcode vigente	Los procesadores modernos tienen capacidades de scheduling que los viejos no

Dicho eso, ahora sí vamos al corazón del tuning del servidor fisico.

Host Considerations — empezando desde el BIOS

Mucha gente piensa que el tuning de performance en vSphere empieza en el vCenter. En realidad empieza mucho antes — en el BIOS del servidor físico. Y esto es algo que se pasa por alto constantemente.

Aquí está la situación: los procesadores modernos son inteligentes. Demasiado inteligentes para lo que necesitamos. Están diseñados para ahorrar energía cuando no hay carga, bajando su frecuencia de operación. Cuando llega trabajo, suben la frecuencia de nuevo. Esto es excelente para eficiencia energética, pero es un desastre para latencia, porque ese proceso de subir y bajar frecuencia toma tiempo — y ese tiempo es latencia impredecible para tu aplicación.

Lo que vamos a hacer en el BIOS es decirle al procesador: «olvídate de ahorrar energía, quiero que operes siempre a máxima capacidad y de forma predecible».

Configuración de BIOS recomendada

Setting	Valor recomendado	¿Qué hace y por qué lo tocamos?
Power Management	High Performance	Le dice al servidor que priorice rendimiento sobre ahorro de energía. Sin esto, el CPU puede estar a velocidad reducida justo cuando tu aplicación lo necesita.
Hyper-Threading	Enabled	Permite que cada core físico ejecute dos hilos simultáneamente. Más capacidad de procesamiento paralelo para los worlds del hypervisor.
Turbo Boost	Enabled	Permite al CPU subir temporalmente su frecuencia por encima del valor base cuando hay demanda. Lo dejamos activo porque da más rendimiento pico.
Energy Efficient Turbo	Disabled	Es una versión «inteligente» del Turbo Boost que decide cuándo activarse basándose en el consumo de energía. Lo desactivamos porque queremos un comportamiento predecible, no uno que varía según métricas de energía.
P States	Disabled	Los P-States son los distintos niveles de frecuencia y voltaje a los que puede operar el CPU. Desactivarlos fuerza al procesador a correr siempre al mismo nivel, eliminando las variaciones de latencia que ocurren cuando cambia de estado.
C States	Disabled	Los C-States son estados de «sueño» del procesador — cuando no hay trabajo, el CPU se «apaga» parcialmente para ahorrar energía. Despertar desde un C-State toma tiempo. Lo desactivamos para que el CPU nunca entre en modo de bajo consumo.
C1E Enhanced Mode	Disabled	Es una variante mejorada del C-State más básico (C1). Mismo principio: si está activo, el CPU puede entrar en modo de ahorro aunque sea brevemente, generando latencia inesperada.
QPI/UPI Power Management	Disabled	QPI/UPI es el bus de alta velocidad que conecta múltiples procesadores entre sí (en servidores dual-socket). Si tiene power management activo, esa conexión entre CPUs puede operar a velocidad reducida. Para latencia, la queremos siempre a máxima velocidad.
Node Interleaving	Disabled	Cuando está activo, el servidor distribuye la memoria automáticamente entre los nodos NUMA (más sobre NUMA adelante). Parece buena idea, pero en realidad le quita al sistema operativo la capacidad de hacer una gestión inteligente de la memoria. Lo desactivamos para que el OS y el hypervisor controlen dónde va cada dato.

📝 Nota Todos estos settings en conjunto mantienen el Turbo Boost activo (más velocidad cuando se necesita) pero eliminan cualquier comportamiento dinámico de ahorro de energía que pueda causar variaciones impredecibles. Siempre consulta la documentación del fabricante de tu servidor — los nombres exactos de estos settings pueden variar entre Dell, HPE, Lenovo, etc.

EVC — otro factor que poca gente considera

EVC (Enhanced vMotion Compatibility) es una función de vSphere que «normaliza» las instrucciones del procesador que ven las VMs, para que puedan moverse con vMotion entre hosts con CPUs de diferentes generaciones. Suena bien, ¿verdad? El problema es que para lograrlo, oculta instrucciones del procesador que podrían beneficiar el rendimiento de tu aplicación.

Para workloads latency-sensitive, usa el baseline de EVC más reciente compatible con tus CPUs, o simplemente desactívalo. Si todos tus hosts tienen la misma generación de CPU, no necesitas EVC de todas formas. Más detalles en KB 313545.

vMotion y DRS — úsalos con cabeza

vMotion migra una VM de un host a otro «en vivo», sin apagarla. Durante ese proceso, hay un momento en que la VM se pausa brevemente — hasta 1 segundo según la documentación oficial. Para aplicaciones normales, un segundo no se nota. Para una aplicación que procesa transacciones financieras o controla maquinaria industrial, 1 segundo puede ser catastrófico.

DRS (Distributed Resource Scheduler) usa vMotion automáticamente para balancear la carga entre hosts. Si DRS está en modo automático, puede mover tus VMs críticas en cualquier momento sin que tú lo decidas.

La recomendación es simple: planifica cuándo y cómo se hacen estos movimientos. No los dejes en automático para workloads latency-sensitive. Úsalos solo en ventanas de mantenimiento planificadas.

Muy bien, con el hardware ajustado, el siguiente paso es optimizar las VMs que van a correr sobre él.

VM Considerations — el sizing importa más de lo que crees

Ya ajustamos el BIOS. Ahora viene la parte donde muchos administradores cometen errores — el tamaño y la configuración de las VMs. La tentación natural es «poner muchos recursos para que no le falte nada». Para latencia, esa lógica es exactamente al revés.

Rightsize VMs — más no siempre es mejor

Primero, un concepto que vas a ver mucho en esta sección: NUMA (Non-Uniform Memory Access). Los servidores modernos tienen múltiples procesadores físicos (sockets), y cada uno tiene su propio «bnaco de memoria» directamente conectada. Acceder a la memoria propia de un CPU es rápido. Acceder a la memoria del otro CPU, cruzando el bus QPI/UPI que mencionamos antes, es más lento — puede ser hasta 2x más lento.

Ese «cruzar al otro CPU para buscar datos» es lo que queremos evitar a toda costa en workloads latency-sensitive.

Por esta razon, recomendamos tres reglas concretas:

1. No hagas la VM más grande que un NUMA node físico. Si tu servidor tiene dos sockets con 32 cores cada uno, y haces una VM de 48 vCPUs, vSphere va a tener que distribuirla entre los dos NUMA nodes. Eso significa que parte de los accesos de memoria van a ser remotos — lentos. Mantén las VMs dentro de un solo NUMA node.

2. Haz la VM tan pequeña como sea suficiente para su función. Una VM más pequeña es más fácil de ubicar completamente dentro de un NUMA node, y genera menos competencia por recursos del sistema. No le pongas 32 vCPUs si la aplicación usa 8. Puedes siempre agregar recursos después si los necesita.

3. Reserva 4–8 cores físicos para el host — y no los asignes a VMs. El ESXi no solo ejecuta VMs. Tiene sus propios procesos que trabajan en nombre de las VMs: recibir paquetes de red, procesarlos antes de entregarlos a la VM, manejar interrupciones de hardware, etc. Estos procesos compiten por CPU con todo lo demás. La única forma de protegerlos es no llenar el host al 100% de capacidad — deja esos cores libres para el hypervisor.

⚠️ ¡OJO! Si buscas el parámetro sched.cpu.latencySensitivity.sysContexts en la documentación, no lo vas a encontrar. Fue removido en vSphere 7.0 y ya no existe. No lo configures.

Virtual Hardware Version — no la dejes en la versión vieja

Cuando creas una VM, vSphere le asigna una versión de hardware virtual. Esa versión define qué capacidades tiene disponibles la VM — incluyendo a qué instrucciones del procesador puede acceder. Una VM con Virtual Hardware 13 corriendo en un host con vSphere 8 está, literalmente, usando una versión vieja de todo aunque el host sea moderno.

Usa Virtual Hardware versión 21 con vSphere 8.0 U3. Si tienes VMs viejas que migraste, actualiza la versión del hardware virtual.

vTopology — que la VM «vea» el hardware como realmente es

vTopology es la forma en que vSphere presenta la topología del procesador físico a la VM. En términos simples: ¿la VM cree que tiene 8 cores en 1 socket, o 2 cores en 4 sockets? ¿Sabe que existen múltiples NUMA nodes?

Esto importa porque el sistema operativo guest (Windows, Linux) y las aplicaciones que corren dentro de la VM toman decisiones de scheduling basadas en esa topología. Si la VM tiene una vista distorsionada del hardware, el guest OS va a tomar malas decisiones sobre dónde ejecutar threads y dónde almacenar datos — aumentando la latencia.

Antes de vSphere 8, la configuración por defecto era 1 core por socket, lo cual era casi siempre incorrecto. vSphere 8 aplica automáticamente la vTopology correcta la primera vez que enciendes una VM nueva. El problema es que las VMs que migraste desde versiones anteriores no se ajustan automáticamente — esas las tienes que revisar y corregir manualmente o actualizarles el Virtual Hardware a una versión 20 o superior que ya hace la tarea por ti.

Disable Hot-Add — este feature y la latencia no se llevan bien

vCPU Hot-Add es la capacidad de agregar vCPUs a una VM sin apagarla. Suena útil. El problema es que para implementarlo, vSphere tiene que deshabilitar vNUMA en esa VM.

vNUMA es lo que le permite a la VM «ver» los múltiples NUMA nodes del servidor físico, para que el guest OS pueda hacer una gestión inteligente de la memoria. Sin vNUMA, la VM ve el servidor como si tuviera memoria uniforme en todos lados — lo que se llama topología UMA — y pierde la capacidad de optimizar accesos de memoria.

En resumen: habilitar Hot-Add para «tener flexibilidad» le quita a la VM la capacidad de gestionar bien su memoria, y eso incrementa la latencia. Para workloads latency-sensitive, mantén Hot-Add deshabilitado.

Con las VMs bien configuradas, el siguiente paso es activar el setting más poderoso de todos — y el que más gente pasa por alto.

Latency Sensitivity por VM — el setting que muchos ignoran

Esta es, probablemente, la configuración individual más impactante de todo este artículo. Y la mayoría de los administradores no saben que existe.

Latency Sensitivity es un setting que se activa por VM individualmente. Cuando lo pones en «High», vSphere cambia fundamentalmente cómo maneja esa VM. Son tres cambios críticos:

1. La VM obtiene acceso exclusivo a los cores físicos. Normalmente, vSphere comparte los cores físicos entre múltiples VMs y sus propios procesos. Con Latency Sensitivity en High, cada vCPU de esa VM «toma posesión» de un core físico. Ningún otro proceso, ninguna otra VM, puede correr en ese core mientras la VM lo esté usando. ¿El resultado? El ready time (el tiempo que una VM espera para que le den turno de CPU) cae prácticamente a cero.

2. El vCPU bypasea el scheduler del VMkernel. El scheduler es el componente del hypervisor que decide quién usa el CPU y cuándo. Pasarlo siempre tiene un costo en tiempo — pequeño, pero constante. Con acceso exclusivo a los cores, vSphere puede saltarse ese paso y dejar que el vCPU opere directamente, sin intermediarios. Esto acelera significativamente las operaciones de halt y wake-up del vCPU — que son muy frecuentes en aplicaciones de alta velocidad.

3. VMXNET3 se auto-optimiza. Cuando esta función está activa y la VM usa adaptadores de red VMXNET3, vSphere deshabilita automáticamente el interrupt coalescing (la práctica de agrupar múltiples interrupciones de red en una sola para ahorrar CPU) y el LRO (Large Receive Offload, que agrupa paquetes recibidos). Ambas técnicas ahorran CPU pero introducen pequeños retrasos. Para latencia, preferimos pagar el costo en CPU y obtener la respuesta inmediata.

Cómo activarla (3 pasos obligatorios)

Los tres pasos son obligatorios — no opcionales. Si no haces el 1 y el 2, el paso 3 no funciona correctamente.

Paso 1 — CPU Reservation: Edit Settings → Virtual Hardware → CPU → Reservation

Aquí tienes que reservar CPU en MHz para la VM. La fórmula es simple: frecuencia base del procesador × número de vCPUs. Por ejemplo, si tu CPU corre a 2.4 GHz y la VM tiene 8 vCPUs: 2,400 MHz × 8 = 19,200 MHz de reserva.

Esto garantiza que el host siempre tenga esos recursos disponibles para la VM — no puede dárselos a nadie más.

Paso 2 — Memory Reservation: Edit Settings → Virtual Hardware → Memory → Reservation → Reserve all guest memory (All locked)

Toda la memoria de la VM queda «bloqueada» en RAM física. Ninguna página de memoria puede ser movida a disco (swap). Para latencia, el acceso a disco en lugar de RAM es inaceptable.

Paso 3 — Latency Sensitivity: Edit Settings → VM Options → Advanced → Latency Sensitivity → High

⚠️ CAUTION Esta configuración tiene un costo real y muy concreto: los cores físicos asignados exclusivamente a esta VM no pueden ser usados por ninguna otra VM mientras están asignados. Si tienes un host con 32 cores y una VM con 8 vCPUs en modo Latency Sensitivity High, esos 8 cores quedan reservados solo para ella. Evalúa el impacto en la densidad del host antes de activarla.

Parámetros avanzados adicionales

Una vez activada la Latency Sensitivity, agrega estos tres parámetros en Edit Settings → VM Options → Advanced → Configuration Parameters → Edit Configuration → Add Configuration Parameters:

			
sched.cpu.affinity.exclusiveNoStats = TRUE
monitor.forceEnableMPTI = TRUE
timeTracker.lowLatency = TRUE

Estos complementan la configuración de Latency Sensitivity con ajustes más finos de cómo el hypervisor maneja el tiempo y el scheduling de esa VM específica.

Con las VMs configuradas, queda una capa más que afinar. Si señor, la Red.

Networking — VMXNET3 y más allá

La red es el otro gran factor de latencia. Los datos tienen que llegar a la VM lo más rápido posible, con el menor procesamiento intermedio. Aquí hay varias capas que podemos optimizar.

VMXNET3 — el punto de partida

VMXNET3 es el adaptador de red paravirtualizado de VMware. «Paravirtualizado» significa que fue diseñado específicamente para correr dentro de una VM sobre vSphere — no es una emulación de hardware real. Eso lo hace significativamente más eficiente que otros adaptadores virtuales.

Siempre usa VMXNET3 como el adaptador de red en tus VMs latency-sensitive. Si tienes VMs con adaptadores E1000 o E1000E, cámbialos.

Balance Tx y Rx — para alto throughput bidireccional

Si tu VM necesita enviar y recibir datos al mismo tiempo a alta velocidad (piensa en un sistema que procesa streams de entrada mientras genera respuestas de salida), agrega estos parámetros directamente en el archivo VMX de la VM:

			
ethernetX.pnicFeatures = 4
ethernetX.ctxPerDev = 3

(Reemplaza ethernetX con el nombre del adaptador correspondiente, por ejemplo ethernet0)

Esto activa paralelismo en la capa de networking de vSphere — básicamente, permite que múltiples threads procesen el tráfico de red simultáneamente en lugar de hacerlo en serie. El resultado es un balance más equitativo entre el ancho de banda de transmisión y recepción. Requiere que RSS (Receive Side Scaling) esté habilitado en la NIC física del host.

SR-IOV y DirectPath I/O — cuando VMXNET3 no alcanza

Para workloads extremos — más de 50,000 paquetes por segundo — VMXNET3 puede quedarse corto. En esos casos, considera estas dos tecnologías que permiten a la VM acceder directamente al hardware de red, eliminando capas de virtualización:

Tecnología	Cómo funciona	Cuándo usarla
DirectPath I/O	La VM accede directamente a 1 NIC física. No hay capa virtual de por medio.	Cuando 1 VM necesita todo el rendimiento de 1 NIC física
SR-IOV	La NIC física se divide en múltiples «NICs virtuales» (VFs) que cada VM accede directamente	Cuando varias VMs necesitan acceso casi-directo a hardware compartiendo 1 NIC física

⚠️ ¡OJO! SR-IOV y DirectPath I/O tienen un costo importante: no soportan vMotion, memory overcommitment ni network I/O control. Una VM con DirectPath I/O no se puede mover en vivo a otro host. Piénsalo bien antes de usarlos — son para casos donde el rendimiento es más crítico que la flexibilidad de gestión.

SmartNICs / DPUs — el siguiente nivel

vSphere 8 soporta DPUs (Data Processing Units), también conocidas como SmartNICs. Son tarjetas de red con su propio procesador dedicado que pueden tomar workloads del networking stack que normalmente correría en los CPUs del host.

Con el modo VMXNET3 UPTv2, el tráfico de red de la VM puede ir directamente a la DPU y su interfaz de red, sin pasar por los CPUs del host — reduciendo latencia y liberando cores para la aplicación. Y a diferencia de DirectPath I/O, esto sí mantiene compatibilidad con DRS, HA y otras funciones de vSphere 8.

Comandos de operación útiles

Ya con todo configurado, necesitas herramientas para monitorear que todo esté funcionando como esperas. Aquí los comandos más útiles del día a día.

Ver estadísticas de la NIC física

Útil para confirmar que la NIC está operando correctamente y ver contadores de errores o drops:

esxcli network nic stats get -n vmnicX

(Reemplaza vmnicX con el nombre de tu NIC, por ejemplo vmnic0)

Ver y ajustar ring buffers

Los ring buffers son áreas de memoria donde la NIC almacena paquetes antes de que el CPU los procese. Si son muy pequeños y llegan muchos paquetes rápido, se llenan y los paquetes se descartan. Para streams UDP en particular, esto es crítico.

			
# Ver cuál es el máximo que soporta la NIC
esxcli network nic ring preset get -n vmnicN
# Ver el tamaño actual configurado
esxcli network nic ring current get -n vmnicN
# Aumentar los ring buffers (rx = receive, tx = transmit)
esxcli network nic ring current set -n vmnicX -r 2048 -t 1024

		

Compara el preset máximo con el valor actual. Si el actual es mucho menor al máximo, aumentarlo puede reducir drops de paquetes.

Monitoreo con net-stats

net-stats -A -t WwqQi -i 2

Agrega | grep para filtrar por lo que te interesa. Los contadores clave son rxeps y txeps — si ves que suben, tienes drops de paquetes. El campo de thread utilization te ayuda a identificar contención en el scheduling de red.

Deshabilitar queue pairing

En workloads donde se transmite mucho más de lo que se recibe (como streaming de video saliente), una función llamada queue pairing puede generar un cuello de botella: el thread que procesa la recepción también tiene que procesar las confirmaciones de transmisión, y si hay muchas transmisiones, puede atrasarse y agotar el buffer de la vNIC.

esxcli system settings advanced set -o /Net/NetNetqRxQueueFeatPairEnable -i 0

⚠️ CAUTION Este cambio requiere reboot del ESXi host para aplicarse. Además, al separar el procesamiento en un thread adicional, incrementa el consumo de CPU del host. Evalúa si el beneficio justifica el costo en tu caso específico antes de aplicarlo en producción.

Conclusion

Lo que cubrimos aquí son los ajustes de mayor impacto y más aplicables para la mayoría de los entornos. El white paper oficial de Performance Tuning for Latency-Sensitive Workloads va más allá y cubre escenarios más específicos que dejamos fuera a propósito para no complicar el artículo:

Afinización manual del thread de transmisión (Tx) de la VM a un core físico específico
Asociación de VMs a NUMA nodes específicos para alinearlas con la NIC física
Tuning de Photon OS con kernel linux-rt (basado en PREEMPT_RT) para cargas de tiempo real dentro del guest
Enhanced Datapath para workloads NFV
Lista completa de comandos esxcli network con referencia de parámetros

📝 Disclaimer Este artículo es un resumen práctico del Performance Technical White Paper oficial de VMware by Broadcom (enero 2025). No cubre todos los escenarios ni reemplaza la documentación oficial. Siempre valida los cambios en un ambiente de non-production antes de aplicarlos en producción.

⚠️ ¡IMPORTANTE!

He migrado el blog del dominio nachoaprendevirtualizacion.com a nachoaprendeit.com. Si te ha servido este artículo, deja tu buen 👍 Like y compártelo con tus colegas. Estas acciones me ayudarán a optimizar los motores de búsqueda para llegar a más personas y a motivarme a seguir compartiendo este tipo de artículos.

Secure Boot Certificates para VMs: Lo que Debes Saber antes de junio 2026

en 29 mayo, 202617 junio, 2026 por Diego Felipe Tunubalá Medinaen ESXi, VCF/VVF, vSphereDeja un comentario

Si administras entornos VMware con Secure Boot habilitado, hay una fecha que debes tener en el radar: junio de 2026. Microsoft está renovando su cadena de certificados Secure Boot y como administradores de infraestructura hay pasos que ejecutar para asegurarse de que las VMs queden preparadas.

Este tema ha generado bastante ruido en la comunidad con titulares del estilo «tus VMs van a dejar de bootear en junio» que más que informar, alarman. Sin embargo, es importante aclarar que la expiración de un certificado y su revocación son eventos distintos — sus VMs no van a dejar de bootear de un día para otro. Lo que sí se pierde sin actualizar es la capacidad de recibir futuras actualizaciones de seguridad de Secure Boot, y eso merece atención planificada, no urgencia de pánico.

La buena noticia es que Broadcom ya liberó ESXi 8.0 P09 con la solución automática. Para la mayoría de los entornos, la remediación es tan simple como parchear el host y reiniciar las VMs. En este artículo vamos a ver qué está pasando, cómo identificar las VMs afectadas, y cómo ejecutar la remediación paso a paso según el escenario.

Este contenido está basado en la documentación oficial de Broadcom y Microsoft:

⚠️ ¡IMPORTANTE!
Este artículo es una guía informativa basada en la documentación oficial publicada por Broadcom y Microsoft a la fecha de publicación. Su objetivo es ayudarles a entender el problema y tener una referencia clara del proceso de remediación. Dicho esto, cada ambiente es diferente — versiones de ESXi, configuraciones de vTPM, cifrado de disco, hardware virtual — y es responsabilidad de cada administrador validar los pasos contra la documentación oficial vigente antes de ejecutar cualquier cambio en producción. Los KBs referenciados se actualizan periódicamente; siempre verifiquen la versión más reciente.

Contenido

Contenido
¿Qué está pasando?
La cadena de confianza de Secure Boot
Síntomas
Las dos causas raíz
¿Cuál es el impacto real hoy?
Productos y versiones afectadas
Tabla de certificados por versión de ESXi
Matriz de remediación
SOLUCIÓN A — ESXi 8.0 P09 (Silent PK Update)
SOLUCIÓN B — Actualización Manual vUEFI
SOLUCIÓN C — VMX Configuration para Linux con vTPM
VMs Windows con vTPM — Sin solución aún
Scripts adjuntos al KB 423893
Resumen

¿Qué está pasando?

Microsoft está renovando su cadena de certificados de Secure Boot. Los certificados que vienen usando desde 2011 están próximos a expirar — el KEK CA 2011 vence en junio 2026 — y necesitan ser reemplazados por los nuevos certificados 2023 en todas las VMs que tienen Secure Boot habilitado.

Hasta ahí todo suena normal. El problema específico en entornos VMware es que la mayoría de las VMs existentes tienen el Platform Key (PK) configurado como NULL (VMW.NULLPK) por diseño en versiones anteriores de ESXi. Y ese PK null es el que bloquea todo — porque sin un PK válido, la plataforma no puede autorizar ninguna actualización en la cadena de Secure Boot.

Dicho de otra forma: Windows quiere actualizar los certificados, intenta hacerlo, pero el firmware de la VM le cierra la puerta desde la raíz.

La cadena de confianza de Secure Boot

Antes de entrar a la remediación, vale la pena entender bien la cadena. Y es que si no entienden cómo funciona, no van a entender por qué el PK null es tan crítico.

Secure Boot funciona como una cadena de confianza jerárquica. Si un eslabón falla, todo lo que está debajo también falla:

			
PK  (Platform Key)           ← RAÍZ. Si es NULL, nada más funciona.
 └── KEK (Key Exchange Key)  ← Autoriza cambios a DB y DBX
      ├── DB  (Allowed)      ← Define qué puede bootear
      └── DBX (Revoked)      ← Define qué está bloqueado

Con el PK null, la plataforma no puede autorizar ningún cambio al KEK. Sin KEK actualizado, no se pueden actualizar DB ni DBX. Y sin esas actualizaciones, Windows no puede instalar los nuevos certificados 2023 — por eso el scheduled task de Windows falla silenciosamente y el Event ID 1801 sigue apareciendo.

Síntomas

Estos son los síntomas que pueden estar viendo en sus ambientes:

Event ID 1801 en Windows Event Viewer — certificados disponibles pero no aplicados al firmware
Event ID 1769 — error invalid access to memory location al intentar actualizar KEK 2023
Falta Microsoft Corporation KEK 2K CA 2023 en la base KEK de la VM
Falla al instalar DB, DBX o certificados Option ROM actualizados
El update funciona en algunas VMs pero falla en otras con diferente versión de ESXi o HW Version
Secure Boot sigue funcionando pero futuras revocaciones DBX no se pueden aplicar

Las dos causas raíz

Hay dos causas documentadas en los KBs oficiales. Son relacionadas pero distintas — y entender la diferencia importa a la hora de elegir la remediación.

Causa 1 — KEK expirado o faltante

Microsoft Corporation KEK CA 2011 expira en junio 2026. Sin KEK válido no se pueden autorizar actualizaciones de DB ni revocaciones DBX. Windows reporta Event ID 1801 durante el intento de remediación.

Causa 2 — Platform Key NULL (la causa más profunda)

En VMs creadas en ESXi anteriores a 9.0, el PK se inicializa como VMW.NULLPK por diseño. Con el PK null la plataforma no puede autorizar ningún cambio al KEK, bloqueando toda la cadena desde la raíz. Esta es la causa que VMware resuelve con el parche de ESXi 8.0 P09.

KB 423919 — «The Platform Key (PK) on virtual machines has an invalid signature, which causes updates to the Key Exchange Key (KEK) database to fail. As a result, the automated Secure Boot update process fails and reports error events or logs.»

¿Cuál es el impacto real hoy?

Acá es donde muchos se alarman más de la cuenta. Vamos por partes:

Situación	Impacto
Certs 2011 expirados pero no revocados	VMs siguen booteando normalmente ✅
Secure Boot no verifica expiración durante boot	El boot no se interrumpe por expiración ✅
Sin KEK 2023 en firmware	Nuevos payloads DB/DBX firmados solo con KEK 2023 fallan ❌
PK NULL	Cualquier intento de actualizar KEK siempre falla ❌
Microsoft revoca los certs 2011	Boot se rompe — sin fecha confirmada aún ⚠️

Las VMs siguen booteando después de la expiración. Secure Boot no verifica la fecha de expiración de los certificados durante el proceso de boot — el impacto al boot ocurre solo si Microsoft revoca activamente los certificados vencidos, y a la fecha de este artículo no hay una fecha confirmada para eso.

No hay emergencia inmediata de boot, pero sí hay una ventana de tiempo para remediar antes de que Microsoft tome esa decisión.

Productos y versiones afectadas

Producto	Versiones
VMware ESXi	7.x, 8.x, 9.x
VCF	4.x, 5.x, 9.x
TCP	3.x, 4.x, 5.x
TCI	2.x, 3.x

VMs con HW Version 12 o anterior no soportan Secure Boot — no aplica este problema. VMs en HW Version 13 con Secure Boot habilitado requieren upgrade a HW Version 14+ antes de proceder con la actualización del PK.

Tabla de certificados por versión de ESXi

Esta tabla es fundamental para entender qué certificados tiene cada VM según en qué versión de ESXi fue creada. El estado del PK es lo que más importa revisar:

ESXi + HW Version en creación de VM	PK	KEK	DB
ESXi 9.x O ESXi 8.0 P09+ con HW 14+	Windows OEM Devices PK (Sep 2038)	KEK 2K CA 2023 (Mar 2038) + KEK CA 2011 (Jun 2026)	Windows UEFI CA 2023 + Microsoft UEFI CA 2023 + certs 2011
ESXi 8.0 U2/U3 hasta 8.0 P08 con HW 14+	VMW.NULLPK ❌	KEK 2K CA 2023 + KEK CA 2011	Windows UEFI CA 2023 + Microsoft UEFI CA 2023 + certs 2011
ESXi anteriores con HW 14+ O HW 13 en cualquier ESXi	VMW.NULLPK ❌	*Solo KEK CA 2011 (Jun 2026)* ❌**	Solo certs 2011 ❌
HW Version 12 o anterior	N/A — Secure Boot no soportado

Como ven, el VMW.NULLPK aparece en prácticamente todas las VMs creadas antes de ESXi 9.0 o ESXi 8.0 P09 (Parche liberado recientemente). Es el denominador común del problema.

Matriz de remediación

Con el contexto claro, acá está la matriz que define qué hacer en cada escenario según la configuración de la VM. El escenario más común en producción es el #2 — Secure Boot habilitado y sin vTPM — y es exactamente el que resuelve el parche de ESXi 8.0 P09:

#	Secure Boot	vTPM	ESXi 7.x / 8.0 ≤ P08	ESXi 8.0 P09	ESXi 9.x
1	Disabled	Disabled	Sin acción	Silent PK Update (opcional/proactivo)	Sin acción
2	Enabled	Disabled	Manual vUEFI	✅ Silent PK Update — solo reiniciar	Manual vUEFI
3	Enabled	Enabled	Manual vUEFI	Manual VMX (solo Linux); Windows: esperar parche	Manual VMX (solo Linux); Windows: esperar 9.1.x
4	Disabled	Enabled	Sin acción	Sin acción	Sin acción
Vamos a ver cada solución en detalle.

SOLUCIÓN A — ESXi 8.0 P09 (Silent PK Update)

Esta es la solución principal y la más simple para los escenarios 1 y 2. ESXi 8.0 P09 ya fue liberado e incluye la capacidad de Silent PK Update. Asi que la formas mas facil solucionar el problema es parchando los hosts a esta version liberada el dia 27 de Mayo de 2026.

¿Qué hace el parche exactamente?

Durante el reboot de una VM con vTPM deshabilitado, ESXi detecta que el PK es VMW.NULLPK y lo reemplaza automáticamente por Windows OEM Devices PK — sin intervención adicional del administrador, sin tocar el Guest OS, sin scripts dentro de la VM.

Ahora bien, una vez que el PK es válido, ¿quién actualiza el KEK y el DB? Acá es donde entra Microsoft. Según el KB 5062713, Windows tiene un scheduled task que corre cada 12 horas y aplica los certificados automáticamente en este orden secuencial — cada paso debe completar antes de pasar al siguiente:

Aplica Windows UEFI CA 2023 → DB
Si el dispositivo tiene Microsoft Corporation UEFI CA 2011 en el DB, aplica Microsoft Option ROM UEFI CA 2023 y Microsoft UEFI CA 2023 → DB
Agrega Microsoft Corporation KEK 2K CA 2023 → KEK
Actualiza el Windows Boot Manager al firmado con Windows UEFI CA 2023 (este último paso requiere un restart adicional — se completa en el próximo reboot natural del sistema)

El cliente no necesita intervenir en KEK ni DB. Es completamente automático una vez que ESXi corrige el PK. VMware arregla el PK, Microsoft arregla el resto.

El KB de Microsoft lo aclara perfectamente para entornos virtualizados:

MS KB 5062713 — «For Windows running long term in a VM, the updates can be applied through Windows like any other devices, if the virtualized firmware supports Secure Boot updates.»

La frase clave es «if the virtualized firmware supports Secure Boot updates» — que es exactamente lo que estaba bloqueado con el VMW.NULLPK y lo que ESXi 8.0 P09 corrige.

Con esto claro, vamos a los pasos.

Paso 1 — Identificar las VMs afectadas

Lo primero es saber con qué VMs estamos trabajando. Tienen dos opciones:

Opción A — vSphere Client (UI)

Navegar al cluster o host → pestaña VMs → clic derecho en encabezado de columna → Show/Hide Columns → activar «Secure Boot». Esto agrega una columna con el estado para todas las VMs del inventario de forma inmediata.

Opción B — PowerCLI

			
# 1. Conectar a vCenter
Connect-VIServer -Name <vc_fqdn / ip_address> -User <username>
# 2. Listar VMs con Secure Boot habilitado
Get-VM | Where-Object {
    $_.ExtensionData.Config.BootOptions.EfiSecureBootEnabled -eq $true
} | Select Name
# 3. Listar VMs con vTPM habilitado
Get-VM | Where-Object {
    $_.ExtensionData.Config.Hardware.Device | Where-Object {
        $_.GetType().Name -eq "VirtualTPM"
    }
}

		

El KB 423893 adjunta el script SecureBootExportVMList.ps1 que exporta un CSV completo con columnas: VMName, PowerStatus, VMHardwareVersion, SecureBoot, vTPM. Es lo recomendado para entornos con muchas VMs porque les da todo el contexto necesario en un solo archivo.

Paso 2 — Verificar que el PK es NULL (dentro del Guest OS)

Antes de reiniciar masivamente, vale la pena confirmar que las VMs efectivamente tienen el PK inválido. Esto se hace desde adentro del Guest OS.

En Linux

			
mokutil --pk
# Resultado en BLANCO → PK es NULL, necesita actualización
# Resultado con contenido → PK ya es válido, no requiere acción

En Windows (PowerShell como Administrador)

			
$pk = Get-SecureBootUEFI -Name PK
$bytes = $pk.Bytes
$cert = $bytes[44..($bytes.Length-1)]
[IO.File]::WriteAllBytes("PK.der", $cert)
certutil -dump PK.der

		

El PK es inválido si aparece alguno de estos dos resultados:

			
# Resultado 1 — PK completamente NULL:
Cannot index into a null array.
At line:1 char:1
+ $cert[44..($bytes.Length-1)]
    + CategoryInfo : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : NullArray
# Resultado 2 — PK inválido (solo 45 bytes):
PS C:\> certutil -dump PK.der
00 .
CertUtil: -dump command completed successfully.
PS C:\> $bytes.Length
45

		

Paso 3 — Reiniciar las VMs

Con el host en ESXi 8.0 P09 confirmado y las VMs identificadas con vTPM deshabilitado, el único paso que queda es reiniciarlas. Nada más. El parche hace el resto durante el reboot.

VM individual

Get-VM <VM Name> | Restart-VMGuest -Confirm:$false

Cluster completo

Get-Cluster <my-cluster> | Get-VM | Restart-VMGuest -Confirm:$false

📝 Script incluido en el KB

El KB 423893 adjunta el script RestartMultipleVMs.ps1 que acepta un archivo .txt con los nombres de las VMs a reiniciar, se conecta al vCenter, ejecuta el reboot en cada una y exporta el resultado en CSV con columnas: VMName, PowerStatus, GuestOSRebootStatus.

Ejemplo de salida del script:

VMName	PowerStatus	GuestOSRebootStatus
VirtualMachine-1	PoweredOn	Initiated Guest Reboot
VirtualMachine-2	PoweredOn	Initiated Guest Reboot
VirtualMachine-3	Unknown	Error – VM doesn’t exist or error initiating reboot

Paso 4 — Verificar que todo quedó correcto

Una vez reiniciadas las VMs, hay dos cosas que verificar: que el PK fue corregido por ESXi, y que el scheduled task de Microsoft ya aplicó el KEK y DB 2023.

Para el PK, repetir la verificación del Paso 2 dentro del Guest OS. El resultado ya no debe ser en blanco (Linux) ni mostrar NullArray o "00" (Windows).

Para confirmar que el scheduled task de Microsoft aplicó KEK y DB 2023 — recuerden que corre cada 12 horas, así que puede tomar un tiempo:

Windows

			
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
# TRUE  = aplicado correctamente ✅
# FALSE = aún pendiente, esperar hasta 12 horas

Linux

			
mokutil --db
# o
sudo efi-readvar -v db
# Buscar en el output: "Windows UEFI CA 2023", "Microsoft UEFI CA 2023"

Monitoreo via Event Viewer en Windows

El propio Windows les dice cuándo terminó. Busquen estos Event IDs:

Event ID	Tipo	Significado
1801	Error	Certificados disponibles pero aún no aplicados al firmware
1808	Informational	Certificados nuevos aplicados correctamente ✅

Cuando vean el Event ID 1808, el proceso completó exitosamente y pueden cerrar este ticket.

SOLUCIÓN B — Actualización Manual vUEFI

Si no pueden actualizar el host a ESXi 8.0 P09, esta es la alternativa. Aplica para:

Hosts en ESXi 7.x — sin parche automatizado disponible porque ya está fuera de General Support
Hosts en ESXi 8.0 P08 o anterior que no pueden moverse a P09 aún
Hosts en ESXi 9.x con VMs en escenario 2 (Secure Boot Enabled + vTPM Disabled)

El proceso es más manual pero está completamente documentado en el KB 423919. La idea es agregarle temporalmente un disco FAT32 a la VM con el certificado correcto, bootear al vUEFI y desde ahí enrollar el nuevo PK.

⚠️ Antes de empezar — CAUTION del KB 423919

Si la VM tiene vTPM y disk encryption (BitLocker en Windows o LUKS en Linux) sellado a TPM PCR registers, no se salten estos pasos preparatorios: crear snapshot de la VM, guardar el recovery key, o deshabilitar temporalmente el cifrado sellado al TPM. Hacerlo sin esta preparación puede dejar el sistema en BitLocker recovery y sin poder bootear.

PRE-PASO — Preparar el disco FAT32 con el certificado PK

Se necesita un disco temporal FAT32 con el archivo WindowsOEMDevicesPK.der para que la VM lo lea desde la interfaz vUEFI. Esto hay que hacerlo antes de apagar la VM.

En Linux (Ubuntu/Debian)

			
# 1. Agregar disco virtual de 128 MB a la VM desde el vCenter e identificarlo
lsblk
# Asumimos que aparece como /dev/sdb
# 2. Formatear como FAT32
sudo mkfs.vfat -F 32 -n KEYUPDATE /dev/sdb
# 3. Crear punto de montaje y montar
sudo mkdir -p /mnt/keys
sudo mount /dev/sdb /mnt/keys
# 4. Verificar que quedó montado
mount | grep keys
# 5. Descargar el certificado PK desde Microsoft:
# https://github.com/microsoft/secureboot_objects/blob/main/PreSignedObjects/PK/Certificate/WindowsOEMDevicesPK.der
# 6. Copiar al disco y desmontar
sudo cp WindowsOEMDevicesPK.der /mnt/keys
sudo umount /mnt/keys

		

En Windows

			
1. Agregar disco virtual de 128 MB a la VM.
2. Formatear como FAT32:
   - GUI: Win + R → diskmgmt.msc → formatear el nuevo disco como FAT32
   - CMD: format /FS:FAT32 X:  (reemplazar X: con la letra del disco)
3. Descargar el certificado PK desde Microsoft:
   https://github.com/microsoft/secureboot_objects/blob/main/PreSignedObjects/PK/Certificate/WindowsOEMDevicesPK.der
4. Copiar WindowsOEMDevicesPK.der al volumen FAT32 de 128 MB.

		

Proceso — Actualización del PK via vUEFI

Con el disco FAT32 listo y adjunto a la VM, seguimos estos pasos:

			
1. Apagar la VM.
2. Tomar snapshot de la VM.
3. Confirmar que el disco FAT32 preparado está adjunto a la VM.
4. Habilitar Secure Boot variable update sin autenticación.
   Seleccionar la VM en vSphere Client → navegar a:
   - vCenter 7.x: Edit Settings → VM Options → Advanced → Edit Configuration
   - vCenter 8.x/9.x: Edit Settings → Advanced Parameters
   Agregar:
     Nombre: uefi.allowAuthBypass
     Valor:  TRUE
5. Forzar entrada al Setup Mode:
   Edit Settings → VM Options → Boot Options
   Habilitar "Force EFI Setup"
6. Encender la VM.
   Arrancará directamente en la interfaz vUEFI en lugar del OS.
7. Navegar en la interfaz vUEFI y enrollar el PK:
   Enter Setup
    └── Secure Boot Configuration
         └── PK Options
              └── Enroll PK
                   ├── Seleccionar WindowsOEMDevicesPK.der desde el disco FAT32
                   ├── Review
                   └── Commit Changes and Exit
8. Remover el parámetro VMX agregado en el paso 4:
   Eliminar uefi.allowAuthBypass = TRUE desde Advanced Parameters.
9. Remover el disco FAT32 de la VM.
10. Reiniciar la VM — ahora bootea normalmente con el PK corregido.
11. Verificar que el PK fue actualizado correctamente:
    - Linux:   mokutil --pk  (debe retornar contenido, ya no en blanco)
    - Windows: ejecutar nuevamente el bloque PowerShell del Paso 2
               (debe mostrar un certificado válido, no "00" ni NullArray)

		

Una vez el PK es válido, el scheduled task de Microsoft descrito en la Solución A aplica el KEK y DB 2023 automáticamente en las siguientes 12 horas — el flujo de verificación es exactamente el mismo.

Actualización Manual del KEK

Para escenarios donde el scheduled task de Microsoft no puede correr — principalmente VMs Linux o entornos sin Windows Update activo — el KEK también puede actualizarse manualmente usando el mismo mecanismo del disco FAT32.

			
1. Descargar el certificado KEK 2023 desde Microsoft:
https://go.microsoft.com/fwlink/?linkid=2239775
2. Convertir a formato DER
openssl x509 -inform der -in KEK.cer -outform der -out KEK-2023.der
3. Copiar KEK-2023.der al disco FAT32
4. Bootear la VM al EFI Setup nuevamente
   (repetir pasos 4, 5 y 6 del proceso anterior)
5. Navegar en vUEFI y enrollar el KEK:
   Secure Boot Configuration
    └── KEK Options
         └── Enroll KEK
              ├── Seleccionar KEK-2023.der
              └── Commit Changes and Exit

		

Troubleshooting — Error al aplicar el certificado PK

Por si pasa algún problema, la documentación oficial nos dice. Si al intentar enrollar el PK aparece este error:

Only DER encoded certificate file (*.cer/der/crt) is supported

Probablemente el archivo se corrompió durante la descarga. Descargarlo nuevamente. Como alternativa, descargar la versión PEM y convertirla manualmente:

			
# Descargar versión PEM desde:
# https://go.microsoft.com/fwlink/?linkid=2255361
# Convertir a DER
openssl x509 -inform der -in PK.cer -outform der -out PK.der

SOLUCIÓN C — VMX Configuration para Linux con vTPM

Esta solución aplica para el Escenario 3 en ESXi 8.0 P09: VMs Linux con Secure Boot habilitado y vTPM habilitado. Es un punto medio entre la automatización del parche y el proceso manual completo del vUEFI.

⚠️ Antes de empezar — CAUTION del KB 423893

Si hay LUKS sellado a TPM PCR registers, seguir los pasos preparatorios: crear snapshot, guardar recovery key, o deshabilitar el cifrado sellado al TPM antes de proceder.

🚨 Solo para Linux

Este método aplica únicamente para VMs Linux con vTPM habilitado. Para Windows con vTPM, Broadcom recomienda esperar la solución automatizada — más detalle en la siguiente sección.

			
# 1. Suspender aplicaciones TPM dentro del Guest OS
#    (seguir documentación específica del OS o aplicación)
# 2. Apagar la VM
# 3. Conectar a vCenter
Connect-VIServer -Name <vc_fqdn / ip_address> -User <username>
# 4a. Agregar parámetro advanced — VM individual
Get-VM <VM Name> | New-AdvancedSetting `
    -Name 'uefi.secureBoot.PK.resetOnce' `
    -Value "TRUE" `
    -Confirm:$false
# 4b. O para todas las VMs de un Cluster (deben estar apagadas)
Get-Cluster <my-cluster> | Get-VM | New-AdvancedSetting `
    -Name 'uefi.secureBoot.PK.resetOnce' `
    -Value "TRUE" `
    -Confirm:$false
# 5. Encender la VM
# 6. Re-habilitar aplicaciones TPM dentro del Guest OS

		

📝 Script incluido en el KB

El KB 423893 adjunta el script AddResetOnceVMAdvancedParam.ps1 que acepta una lista de VMs en archivo .txt, agrega el parámetro solo en VMs que estén apagadas y tengan vTPM habilitado, y exporta el resultado en CSV. Importante: el script muestra una advertencia explícita sobre el riesgo de BitLocker/LUKS y solicita confirmación y/n antes de proceder — no se salten esa advertencia.

Ejemplo de salida del script:

VMName	PowerStatus	AdvancedConfigStatus
VirtualMachine-1	PoweredOn	Error – VM Not in PoweredOff State
VirtualMachine-2	PoweredOff	Added ResetOnce Advanced Config
VirtualMachine-3	PoweredOn	vTPM is Not Enabled on this VM, hence didn’t add Advanced Config
VirtualMachine-4	PoweredOn	Error – VM doesn’t exist

VMs Windows con vTPM — Sin solución aún

Este es el escenario donde hay que tener paciencia. El KB 423893 es muy explícito: Broadcom recomienda esperar la solución automatizada para VMs Windows con vTPM habilitado.

¿Por qué no hacer el update manual igual? Porque actualizar el PK desde fuera del Guest OS en una VM Windows con vTPM activo altera las variables de Secure Boot y las mediciones del vTPM sin que el OS tenga conocimiento — y eso puede dejar el sistema en BitLocker recovery, requiriendo la recovery key para poder volver a bootear. No es un riesgo que valga la pena tomar cuando la solución automatizada está en camino.

La solución planificada se llama Capsule PK Update y está pendiente de liberación en:

Próximo patch de ESXi 8.x
Próximo patch de ESXi 9.1.x

El KB 423893 se actualizará cuando estos patches estén disponibles.

Scripts adjuntos al KB 423893

Los tres scripts están disponibles para descarga directamente en el KB 423893. Vale la pena tenerlos a la mano antes de arrancar cualquier remediación:

Script	Para qué sirve
`SecureBootExportVMList.ps1`	Exporta inventario de VMs con estado Secure Boot y vTPM a CSV — primer paso recomendado
`RestartMultipleVMs.ps1`	Reinicia múltiples VMs desde lista en `.txt` y exporta resultado en CSV
`AddResetOnceVMAdvancedParam.ps1`	Agrega `uefi.secureBoot.PK.resetOnce=TRUE` en VMs Linux apagadas con vTPM, exporta resultado en CSV

Conclusion

La transición de certificados Secure Boot de Microsoft es un proceso de ciclo de vida normal que la industria maneja periódicamente. Lo que hace este caso particular es que requiere coordinación entre el firmware virtual de VMware y el mecanismo de actualización del guest OS de Microsoft — y esa coordinación tiene matices dependiendo de la versión de ESXi y la configuración de la VM.
VMware by Broadcom está liderando la solución con múltiples mecanismos de automatización en camino. Mientras tanto, los mecanismo de remediacion Automatico y workaround manual está bien documentados.

El resumen de lo que hay que hacer:

			
¿El host está en ESXi 8.0 P09 o superior?
│
├── SÍ → ¿La VM tiene vTPM habilitado?
│         │
│         ├── NO  → ✅ Reiniciar la VM
│         │         ESXi corrige el PK automáticamente durante el reboot.
│         │         Microsoft Scheduled Task aplica KEK + DB 2023
│         │         en las siguientes 12 horas. Sin intervención adicional.
│         │
│         ├── SÍ (Linux)   → Solución C — VMX Configuration
│         │
│         └── SÍ (Windows) → ⏳ Esperar Capsule Update
│                             (riesgo de BitLocker recovery si se hace manual)
│
└── NO → ESXi 7.x o 8.0 ≤ P08
          └── Solución B — Actualización Manual vUEFI (KB 423919)
              Nota: vSphere 7 está fuera de General Support —
              no habrá parches automatizados para esa versión.

		

⚠️ ¡IMPORTANTE!

Cómo Configurar un Container Registry Local en vSphere Kubernetes Service (VKS)

en 21 mayo, 202622 mayo, 2026 por Diego Felipe Tunubalá Medinaen Tanzu/VKSDeja un comentario

Contenido

Login al Harbor local
Configurar un cliente Docker con el certificado de registro Harbor
Descarga de Imágenes
Tagear Imágenes
Subir imagen al Container Registry Privado (Harbor)
Referenciar Imagen desde Registry Local

¿Tu clúster de Kubernetes no tiene salida a internet y te está bloqueando los despliegues?
Es más común de lo que parece… y lo peor: muchas veces ya tienes la solución dentro de tu propia plataforma.

En entornos empresariales es habitual encontrar restricciones de red que impiden el acceso a repositorios públicos, lo que complica la descarga de imágenes necesarias para desplegar aplicaciones contenedorizadas en Kubernetes (K8s).

Aquí es donde entra una solución simple, segura y muchas veces subutilizada: un Container Registry local como Harbor, integrado a través de los Supervisor Services de vSphere Supervisor.

En este contenido te voy a mostrar cómo descargar imágenes desde fuentes externas, cargarlas en tu registry local y dejarlas listas para ser consumidas por tus despliegues en Kubernetes.

Asumiendo que ya tienes un Harbor habilitado en la infraestructura, vamos a seguir los siguientes pasos para poder descargar las imágenes de repositorios publicos y subirlas a nuestro repositorio privado o Container Registry basado en Harbor.

Para esto debemos hacer Login al Harbor desde el navegador web https://fqdn-harbor-local

Para almacenar nuestra imágenes es necesario crear un Proyecto, para esto vamos a crearlo haciendo clic en New Project, este puede ser definido como Public o Private. El nombre de este proyecto será opencart

En Harbor existen dos tipos de proyectos:

Público : Cualquier usuario puede descargar imágenes de este proyecto. Esta es una forma práctica de compartir repositorios con otros.
Privado : Solo los usuarios que son miembros del proyecto pueden descargar imágenes.

Dentro de este proyecto alojarémos las imágenes a tráves del comando push desde un cliente Docker.

Configurar un cliente Docker con el certificado de registro Harbor

Para trabajar con imágenes de contenedor en un registro con Docker, es necesario agregar el certificado de Registry al cliente de Docker. Este certificado se utiliza para autenticar Docker durante el inicio de sesión en el Registry.

Nota: Para esto vamos usar la siguiente documentacion oficial Configurar un cliente Docker con el certificado de registro Harbor que por supuesto explicaremos paso a paso.

Nota: Los siguientes pasos asumen que estas usando una VM Linux (Ubuntu) con el Docker daemon instalado. Sino ha instalado el Docker Engine (daemon) sobre una VM Ubuntu, vaya un momento a Install Docker Engine on Ubuntu y siga los pasos.

Una vez instalado el Docker Engine (Deamon) debemos verificar que esté instalado y que puedas extraer imágenes del concentrador Docker, ejecuta el siguiente comando:

docker run hello-world

Resultado esperado:

			
Hello from Docker!
This message shows that your installation appears to be working correctly.

Nota: Estos comandos se verificaron utilizando Ubuntu 20.04 y Docker 19.03.

Configure su cliente Docker para interactuar con un container regsitry, como Harbor Registry o Docker Hub. Este ejemplo asume que está usando Harbor del Servicio de Supervisor.

Inicie sesión en Harbor Registry.
Seleccionar > Administration > Configuration > Registry Root Certificate.
Hacer clic Download para descargar el certificado de Harbor Registry llamado ca.crt.

Nota: Si es necesario, cambie el nombre del certificado a ca.crt.
Copiar de forma segura el archivo ca.crt a su cliente host Docker.
En el host Docker, cree una ruta de directorio para el registro privado utilizando la dirección IP de Harbor.
/etc/docker/certs.d/IP-address-or-FQDN-of-harbor/
Por ejemplo:
mkdir /etc/docker/certs.d/10.179.145.77
Mueva el ca.crt a este directorio.

Por ejemplo:

mv ca.crt /etc/docker/certs.d/10.179.145.77/ca.crt
Reinicie el Docker deamon.

sudo systemctl restart docker.service
Inicie sesión en el Harbor Registry integrado usando su cliente Docker.
docker login ip-fqdn-harbor
Ejemplo:
docker harbor-01a.site-a.vcf.lab
Deberías ver el siguiente mensaje:

WARNING! Your password will be stored unencrypted in /home/ubuntu/.docker/config.json. Configure a credential helper to remove this warning. See https://docs.docker.com/engine/reference/commandline/login/#credentials-store Login Succeeded

Descarga de Imágenes

El siguiente paso es descargar las imágenes desde el repositorio publico a la VM, preferiblemente basada en Linux, donde instalamos el docket client, para ejecutar los siguientes comando:

Para ver las imagenes que estan descargadas en la libreria del Docker Client local podemos usar los siguientes comando:

docker image ls
docker images

El signidicado de algunas de las columnas que puede devolver el comando anterior es el siguiente:

IMAGE: El tag completo de la imagen (lo que acabamos de explicar: registry/proyecto/nombre:versión)
ID: El identificador único de la imagen en tu máquina local, Docker lo genera automáticamente. Es un hash, pero aquí solo muestra los primeros 12 caracteres (el hash completo es mucho más largo)
DISK USAGE: Cuánto espacio está ocupando esa imagen en tu disco duro local
CONTENT SIZE: El tamaño real del contenido de la imagen sin contar metadatos ni capas compartidas. Nota que ambas tienen 0B, lo cual puede indicar que el comando fue ejecutado con una versión de Docker que no calcula ese campo, o que están siendo referenciadas de otra forma
REPOSITORY: El nombre del repositorio de la imagen (por ejemplo, gitea/gitea y una imagen de Broadcom)
TAG: La etiqueta o versión de la imagen (latest, 4.0.1-1-debian-11-r66)
IMAGE ID: Identificador único de la imagen
CREATED: Cuándo fue creada la imagen (3 weeks ago, 2 years ago)
SIZE: El tamaño que ocupa la imagen en disco (180MB, 487MB)

Para descargar la imagen desde los respositorios de Docker Hub podemos usar el siguiente comando
docker pull [image:version]
Ejemplo: docker pull busybox:latest

o podemos seguir los ejemplos que estan en la siguiente nota para bajar la imagenes de otros respositorios.

Nota: Imagenes de algunos repostorios podrian requerir un usuario y contraseña para poderse descargar

Nota: Algunas imágenes podrían no estar disponible en Docker Hub por lo que se hace necesario descargarlas desde otros repositorio como bitnami, registry.k8s, gcr.io, public.ecr.aws, etc

			
Probar imágenes 100% públicas
docker pull bitnami/wordpress:latest
docker pull bitnami/mysql:8.0
# O usar el registry oficial de Kubernetes
docker pull registry.k8s.io/pause:3.2

		

Podemos probar diferentes Registries Publicos que funcionan bastante bien

			
# Estos deberían funcionar SIN usuario:
docker pull gcr.io/google-containers/pause:3.2
docker pull ghcr.io/bitnami/wordpress:latest     # GitHub Container Registry
docker pull public.ecr.aws/bitnami/wordpress:latest  # AWS Public Registry

NOTA: Importante tener presente que NO NECESITAS CREDENCIALES para la mayoria de registries públicos.

Tagear Imágenes

Ahora debemos colocarle un tag siguiendo el formato que nos indica el mismo Harbor dentro del proyecto en el enlace PUSH COMMAND. Esto es necesario porque Docker no sabe a dónde subir una imagen a menos que el nombre de la imagen comience con la dirección del servidor (harbor-01a.site-a.vcf.lab).

Tag una Imagen para el proyecto Opencart

Para tagear una imagen antes de subirla debemos ajustar el siguiente comando:

docker tag SOURCE_IMAGE[:TAG] fqdn-habor/project/REPOSITORY[:TAG]

A continuacion, la explicacion de que hace este comando.

Lado izquierdo → la imagen que ya tienes local, o incluso puede ser que este en el repositorio publico:

SOURCE_IMAGE = el nombre de tu imagen local o en el repositorio publico
[:TAG] = la versión de esa imagen local. Aunque se llama TAG no es el tag que le vamos a colocar es solo la version de la imagen, podríamos decir que es el tag de la version.

Lado derecho → el destino completo en Harbor, y esto todo junto es lo que Docker llama «el tag»:

fqdn-harbor = dominio de tu Harbor
project = proyecto dentro de Harbor
REPOSITORY = nombre que tendrá en Harbor
[:TAG] = la versión. De nuevo es el tag pero solo de la version.

Entonces, el tag que le estás poniendo es todo el lado derecho completo: fqdn-harbor/project/REPOSITORY[:TAG]. Eso es lo que Docker entiende por tag — no solo el :TAG del final.

Ejemplo:
docker tag busybox:latest harbor-01a.site-a.vcf.lab/busybox/busybox:latest

Nota: Este comando no duplica la imagen, solo le crea un alias o apodo. Le dice a Docker que la imagen que descargaste originalmente (como busybox:latest) ahora también debe ser reconocida con el nombre largo de tu servidor Harbor.

Subir imagen al Container Registry Privado (Harbor)

Ahora lo que hacemos es tomar las imágenes que ya etiquetaste y las transferimos por la red desde tu computadora o desde el repositorio publico hasta el servidor Harbor. Para esto se hace necesario hacer el push para publicar la imagen en harbor

Push una imagen en este proyecto
docker push fqdn-habor/project/REPOSITORY[:TAG]

Este es el comando que hace el trabajo pesado: la carga (upload). Una vez que termine, cualquier otra persona (o tu clúster de Tanzu) podrá descargar la imagen directamente desde Harbor sin necesidad de internet.

Ejemplo: docker push harbor-01a.site-a.vcf.lab/busybox/busybox:latest

Esta acción sube la imagen a Harbor, específicamente a nuestro proyecto y la deja disponible para que podamos usarla después en nuestros archivos YAML.

Nota (Opcional): Otra forma es crear un puntero o Alias local para que desde el repositorio original se haga push directamente al Harbor. De esta forma evitamos bajar la imagen con el pull. Creamos unicamente el apuntador y hacemos el push directamente desde el repositorio publico hacia el harbor.

docker tag SOURCE_IMAGE_ONLINE_REPO[:TAG] fqdn-habor/project/REPOSITORY[:TAG]

Ejemplo:
docker tag vcf-automation-docker-dev-local.usw5.packages.broadcom.com/bitnami/opencart:4.0.1-1-debian-11-r66 harbor-01a.site-a.vcf.lab/opencart/opencart:4.0.1-1-debian-11-r66

docker push fqdn-habor/project/REPOSITORY[:TAG]

Ejemplo:
docker push harbor-01a.site-a.vcf.lab/opencart/opencart:4.0.1-1-debian-11-r66

Referenciar Imagen desde Registry Local

Y eso es todo, lo que haríamos despues cuando estemos instalando la aplicación en nuetro cluster de Kubernetes, es simplemente referenciar el path de la imagen que subimos, que ahora vive en nuestro Image Registry local (Harbor), en el archivo YAML que instala la aplicación.

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

Mejores Prácticas para Implementar IDPS con VMware vDefend

en 22 enero, 202621 mayo, 2026 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

Antes de comenzar
Casos de Uso: ¿Para qué activamos esto?
Arquitectura: ¿Qué pasa realmente con el paquete?
Sizing: Las «Reglas de Oro» de Recursos por Host
Estrategias de Despliegue
Optimización del IDPS
Day 2: Operaciones y Troubleshooting
Day 2: Firmas y Ciclo de Vida
Testear el funcionamiento del IDPS
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.

O utilizando las métricas de Aria Operations for Networks

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.

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

DFW Primero: El paquete pasa primero por el filtro del Distributed Firewall (vmware-sfw) en el kernel.
Punt al IDPS: Si el tráfico coincide con una política definida para inspección (una «Inspect Policy»), se marca para ser analizado.
Memoria Compartida: El paquete se copia a una región de memoria compartida (Shared Memory Region) a través del canal dvFilter.
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.

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:

Recurso	Requisito	Notas
CPU	Hasta 5 Cores	Se recomiendan hasta 5 cores adicionales libres por host para los worker y receiver threads.
Memoria	2 GB de RAM	Dato 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 PPS	El 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.

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.

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.

Empieza filtrando solo por severidad «Critical» y «High».
Empieza siempre en modo Detect Only (solo alerta). Pasa a Detect & Prevent (bloqueo) solo después de validar que no hay falsos positivos.
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.
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.
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
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.

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.

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 6 enero, 2026 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.

El nuevo centro de mando: SDDC Manager se integra
vSAN OSA: No entren en pánico
La secuencia de actualización crítica
Componentes obligatorios: VCF Operations y Fleet Management
El reto de la Identidad: Adiós a vIDM
Diseño consolidado y límites de Host
Manejo de binarios y depósitos
Rollback: No hay «botón de pánico» mágico
Información Adicional
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.

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:

VCF Operations (antes Aria Operations).
SDDC Manager (el workflow de actualización del propio manager).
VMware NSX.
VMware vCenter.
Hosts ESXi.

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.

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.

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.

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

Recursos: Webinar Completo

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 16 septiembre, 202519 septiembre, 2025 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.

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

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

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

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

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.

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 11 septiembre, 202511 septiembre, 2025 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

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

Cómo conectarse a los nodos del TKG/VKS Cluster via SSH

en 9 septiembre, 202516 septiembre, 2025 por Diego Felipe Tunubalá Medinaen Tanzu/VKS, VCF/VVFDeja un comentario

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.

CONTENIDO

Prerrequisitos
- Create a Linux Jump Host VM
- Identificar la Workload Network
Procedimiento para iniciar sesión SSH a los nodos TKG
Conclusion

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

Sin mas preámbulo, te explico la forma correcta de hacerlo, basado en la documentación oficial SSH to TKG Service Cluster Nodes as the System User Using a Password aunque podemos también encontrar los pasos resumidos en el siguiente VMware KB Accessing vSphere with Tanzu workload clusters using SSH

Prerrequisito

Create a Linux Jump Host VM

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

kubectl vsphere login --server=https://<SUPERVISOR_IP> [--vsphere-username <VSPHERE_USERNAME>]

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,

En Linux use base64 –decode (o base64 -d);
En MacOS, use base64 –decode (o base64 -D);
En Windows, use an online tool.

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.

ssh vmware-system-user@TKG-CLUSTER-NODE-IP-ADDRESS

Para utilizar Private Key (nodos Windows), utilice el siguiente comando.

ssh -i filename vmware-system-user@TKG-CLUSTER-NODE-IP-ADDRESS

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

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 4 septiembre, 202531 agosto, 2025 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

Release Timeline y Deprecaciones
- Obsolecencias destacadas
- Remociones
vSphere Supervisor
Lifecycle Management
Hardware Support
Availability & Resilience
Workloads y eficiencia
Seguridad y Cumplimiento
Storage
Conclusión
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.

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

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.

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.

Recursos

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 1 septiembre, 202531 agosto, 2025 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
- Mayor Resiliencia en el Patching de vCenter
2. Seguridad y Administración de Certificados Mejorada
- Cambios de Certificados Sin Interrupciones
- Refuerzo en Seguridad Contra Ransomware
3. Gestión de Clústeres y Almacenamiento Más Flexible
- Mejoras en la Gestión de vSAN
- Soporte Mejorado para Sistemas Operativos Invitados
4. Optimización para Workloads con GPU y AI
- Expansión del Ecosistema de DPU y GPU
- Novedades en Virtual Hardware
5. Innovación para DevOps y Kubernetes
- Mejoras en VMware vSphere with Tanzu
Conclusión
Recursos

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.

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.