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!

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

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

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

Novedades Clave de vSphere 8.0 U3: Mejoras y Funcionalidades

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

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 U1: Mejoras y Funcionalidades

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

Muy bien como lo explicamos en el post anterior Novedades Clave de vSphere 8.0 GA: Mejoras y Funcionalidades En esta oportunidad hablaremos solo de las características que fueron incluidas en vSphere 8.0 U1 y. Recordemos que el objetivo final de esta serie de post de novedades de vSphere es tener una visión general de la evolución del producto hasta la fecha. Y estar preparados para la actualización de vSphere 9.0 que ya fue liberada.

CONTENIDO

Administración Eficientemente
Mejoras en Seguridad
- Identidad y Autenticación
Potenciar Cargas de Trabajo
Conclusión
Recursos

Novedades de vSphere 8 Update 1

Continuando con nuestro camino de adopción de la solución vSphere, componente principal de VMware Cloud Foundation, en este artículo recordaremos las nuevas funciones y mejoras que vSphere 8 Update 1 trajo consigo el 18 de Abril de 2023, mejorando la eficiencia operativa, elevando la seguridad y potenciando las cargas de trabajo.

Podemos categorizar las mejoras de vSphere en tres temas principales:

Administración Eficientemente: Hacer que sea más fácil para los clientes operar sus infraestructuras de TI de la manera más eficiente posible.
Seguridad: Cada función se convierte en una característica de seguridad, lo que permite a los equipos de TI centrarse en ser seguros en lugar de solo asegurar.
Potenciar Cargas de Trabajo: Introducir soporte para nuevas tecnologías de hardware, como GPUs y DPUs.

Administración Eficientemente

vSphere Configuration Profile

Comenzamos con los vSphere Configuration Profile, que facilitan la gestión de la configuración del clúster. Esta nueva función permite a los administradores establecer configuraciones deseadas a nivel de clúster en formato JSON, verificar la conformidad de los hosts y remediar cualquier incumplimiento.

Si bien esta funcionalidad fue introducida en vSphere 8.0 GA como Tech Preview, en vSphere 8 Update 1 comenzó a ser completamente soportada. Permitiendo la configuración de vSphere Distributed Switch que no estaba disponible en la version anterior.

vSphere Lifecycle Manager (vLCM)

Además, se mejoró el vSphere Lifecycle Manager (vLCM) para admitir hosts standalone. Esto incluyó la capacidad de definir imágenes personalizadas y gestionar hosts en ubicaciones remotas con conectividad limitada. Desde esta versión todo lo que se espera de vLCM esta disponible para hosts Standalone.

Flexibilidad en Cargas de Trabajo de GPU

Con vSphere 8 Update 1, ahora se pueden asignar diferentes perfiles de GPU a diferentes cargas de trabajo en la misma máquina. Esto permite a los administradores maximizar la utilización de recursos de GPU.

Mejoras en vSphere con Tanzu

Se han realizado mejoras significativas en la integración de Tanzu Supervisor Services, permitiendo su uso con vSphere Distributed Switch, lo que facilita su implementación y gestión.

Como parte de las mejoras incorporadas al entonces vSphere with Tanzu, se añadieron nuevas funcionalidad al vSphere Virtual Machine Service (VM Service), incluido en la versión vSphere 7 Update 2a , y que básicamente permite implementar y gestionar Virtual Machines mediante las API estándar de Kubernetes, al mismo tiempo que permite al administrador de TI controlar el consumo de recursos y la disponibilidad del servicio. Si quiere saber un poco más de VM Service lo invito a leer este corto articulo Introducing the vSphere Virtual Machine Service escrito por Glen Simon.

Como parte de esas mejoras al VM service el equipo de DevOps ahora puede traer tu propia imagen, lo que permite a los usuarios crear imágenes que se pueden almacenar en una biblioteca de contenido.

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

Por si esto fuera poco, vSphere 8 Update 1 introdujo un workflow en el vSphere Client para desplegar y registrar el Skyline Health Diagnostics y de esta manera registrarlo facilmente con vCenter.

Mejoras en Seguridad

La seguridad es una prioridad constante. En vSphere 8 Update 1, se ha abordado la compatibilidad entre ESXi Quick Boot (introducido en vSphere 6.7) y TPM 2.0, permitiendo un reinicio rápido sin comprometer la seguridad.

También se ha mejorado el soporte para vTPM, permitiendo que las máquinas virtuales protegidas con vTPM sean totalmente tolerantes a fallos, es decir que podamos protegerlas con Fault Tolerance.

Identidad y Autenticación

Se introdujo soporte para el proveedor de identidad Okta, lo que permite una gestión más moderna de identidades y autenticación multifactor. Esto se alinea con las mejores prácticas de seguridad actuales. Lo mejor es que no se require el uso de ADFS, nos permite introducir 2FA/MFA y además nos permite tener un Single Sing-On consistente dentro de la organización.

Potenciar Cargas de Trabajo

Hemos realizado importantes mejoras en VM DirectPath I/O, permitiendo la adición y eliminación en caliente de dispositivos NVMe, usando APIs, lo que reduce el tiempo de inactividad de la carga de trabajo.

Además, se extendió el soporte para la tecnología NVIDIA NVSwitch, que permite una comunicación de alta velocidad entre múltiples GPUs, llegando hasta 900 GB/s, lo que es crucial para aplicaciones de inteligencia artificial y computación de alto rendimiento. En esta versión (vSphere 8.0 U1) podíamos conectar hasta 8 GPUs en un Switch NVIDIA usando el protocolo NVLink

Conclusión

Estas mejoras en vSphere 8 Update 1 no solo mejoraron la eficiencia operativa y la seguridad, sino que también permitieron a los clientes aprovechar al máximo sus cargas de trabajo. Para más información y recursos adicionales, visita el Centro de Recursos de VMware.

¡Gracias por tu atención y espero que encuentres útiles estas nuevas características que fueron lanzadas hace un tiempo pero que probablemente no sabías, no recordabas o nunca habías escuchado hablar de ellas!
No vemos en el vSphere 8 Update 2 y Update 3 para completar este path de adopción de la tecnología vSphere.

Recursos

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

Novedades Clave de vSphere 8.0 GA: Mejoras y Funcionalidades

en 26 agosto, 202531 agosto, 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?

Si bien esta información salió hace algunos años, en el campo me he dado cuenta que muchos de nuestros cliente siguen usando vSphere en sus versiones 8.x sin saber que funcionalidades se han incluido.

Ya esta disponible VCF 9.0 y con el nuevas funcionalidades para vSphere 9.0, pero antes de llegar allá enfoquémonos en lo que la mayoria de nuestros clientes tienen actualmente y en cómo podemos ayudarlos a sacarle el mayor provecho a su infraestructura.
Así que con el fin de mejorar la adopción de VMware Cloud Foundation en nuestros clientes, partners y comunidad en general, he decidido crear una serie de blogs, donde resumiremos las mejoras incorporadas en cada uno los lanzamientos de las productos que componen la solución de VCF.

Novedades de vSphere 8.x

CONTENIDO

vSphere Distributed Service Engine
Mejoras en vSphere con Tanzu
- Autenticación Federada con Pinniped
Gestión del Ciclo de Vida
Inteligencia Artificial y Aprendizaje Automático
Mejoras en el Sistema Operativo Invitado y Cargas de Trabajo
- Notificaciones de vMotion
Gestión de Recursos y Sostenibilidad
Seguridad y Cumplimiento
Conclusión
Recursos

Ahora, teniendo en cuenta que vSphere es el Core, comenzaremos por aquí. En este blog, exploraremos de forma muy resumida las características más destacadas y las mejoras que vSphere 8.0 GA trajo a la mesa hace un par de años (2022/10/11).

Para no hacer este blog tan largo, explicaremos solo lo correspondiente a vSphere 8.0 GA y en las siguiente entradas, hablaremos de las características que se han venido incorporando con el lanzamiento de cada uno de los updates. Esto con el objetivo de tener al final una visión general de la evolución del producto hasta la fecha. ¡Así que vamos a sumergirnos en el contenido!

vSphere Distributed Service Engine

Comencemos hablando sobre el vSphere Distributed Services Engine, que nació como Proyecto Monterey. Este motor ha evolucionado y se lanzó con vSphere 8.0 GA, permitiendo mover funcionalidades desde el host hacia una Data Processing Unit (DPU) o unidad de procesamiento de Datos. Su principal objetivo es desbloquear el poder de las Data Processing Unit (DPU) para el procesamiento de datos acelerado por hardware, lo que ofrece una mejora en el rendimiento de la infraestructura. Ahora, usar estas DPU en tus cargas de trabajo es más sencillo que nunca.

Pero, ¿qué es una DPU? Es un dispositivo similar a un dispositivo PCIe como una NIC o una GPU, que reside en la capa de hardware. Contiene cierta capacidad de cómputo, almacenamiento, memoria y tiene interfaces de red, por lo que se le conoce también como SmartNIC porque Incluye un procesador ARM, 16-32GB RAM, high speed ethernet de 10GB a 100 GB, interfaz de Management de 1GB, y Sensores. Lo interesante aquí es que hasta el lanzamiento de vSphere 8.0 GA, nuestros servicios de red, almacenamiento y gestión de hosts funcionaban únicamente en una instancia de ESXi x86, virtualizando la capa de cómputo. Con vSphere 8.0 GA, se agregó una instancia adicional de ESXi directamente en la DPU, lo que permite descargar servicios de ESXi hacia este dispositivo, comenzando con algunos servicios de red y seguridad de NSX, aumentando así el rendimiento de la plataforma. Se espera que en futuros releases, se amplíe el soporte para la descarga de más funcionalidad hacia el dispositivo DPU. Clic en el siguiente enlace obtener más información acerca de ESXi Installation on DPU

Nota: Hasta esta versión vSphere 8.0 GA, solo estaban soportados de tipos de DPU, NVIDIA y Pensando. Pero como veremos en los siguientes post asociados a los Updates de vSphere 8.0, nuevos modelos y partners se han unido a la fiesta!

Esto libera parte del poder de cómputo x86 y lo devuelve a nuestras aplicaciones y cargas de trabajo. Para aprovechar el vSphere Distributed Services Engine, necesitas utilizar un Switch Distribuido de vSphere versión 8 y NSX. Esto te permitirá seleccionar la compatibilidad de descarga de red y elegir la DPU adecuada en tu entorno.

Mejoras en vSphere con Tanzu

Pasemos ahora a las mejoras en vSphere con Tanzu. Introducido en vSphere 7, vSphere con Tanzu trajo consigo Tanzu Kubernetes Grid (TKG) y varias versiones. Con vSphere 8, se consolidaron estas diferentes versiones en un único runtime de Kubernetes unificado, que se utiliza para desplegar Kubernetes en clústeres de vSphere, nubes públicas y privadas.

Una nueva característica en vSphere 8.0 GA es el concepto de vSphere Zones. Esto se utiliza para aislar cargas de trabajo a través de clústeres de vSphere y permite que se extiendan o abarquen múltiples clústeres para maximizar la disponibilidad y el consumo de recursos, evitando a su vez que tengamos un único punto de falla a nivel del vSphere Cluster que soporta la solución de vSphere with Tazu.

Por otro lado, incorporamos el concepto de ClusterClass en VMware vSphere with Tanzu, que no es más que una forma declarativa de, especificar la configuración y gestionar el ciclo de vida de clústeres de Kubernetes a través de un cluster de gestión de Kubernetes que, para vSphere with Tanzu, es conocido como Supervisor Cluster. Utilizando esta nueva funcionalidad podemos incluso decidir los paquetes de infraestructura que se deben instalar al crear el clúster. El ClusterClass puede incluir especificaciones asociadas a proveedores de red, almacenamiento y nube, así como el mecanismo de autenticación y la recopilación de métricas. De esta manera podemos definirlo una vez y aplicarlo múltiples veces.

Nota: Las imágenes de Photon OS y Ubuntu ahora se pueden personalizar y guardar de nuevo en la Content Library para su uso en clústeres de Kubernetes de Tanzu. También se integró la autenticación de Pinniped tanto en el Supervisor Cluster como en los clústeres TKG para la gestión de identidades federadas.

Autenticación Federada con Pinniped

En vSphere 7, toda la autenticación se realizaba a través de la integración con vCenter SSO. En vSphere 8.0 GA, tienes una alternativa: la integración con Pinniped. Esta integración permite que el Supervisor Cluster y los clústeres de Kubernetes de Tanzu accedan directamente a un proveedor de identidad OIDC(OpenID Connect), sin depender de vCenter SSO. Los pods de Pinniped se despliegan automáticamente en el Supervisor Cluster y en los clústeres de Tanzu para admitir esta funcionalidad.

Gestión del Ciclo de Vida

Ahora veamos la gestión del ciclo de vida. vSphere Lifecycle Manager (vLCM) ha mejorado, permitiendo la remediación paralela de hosts, lo que reduce el tiempo total de operación. Recordemos que al remediar un host ESXi que contiene una DPU, también hay un evento de remediación la instancia de ESXi que existe en el dispositivo DPU. La buena noticia es que vSphere Lifecycle Manager Images es consciente de eso, por lo que no tienes nada de que preocuparte a nivel de la gestion del ciclo de vida de dicha instancia de ESXi.

Tambien se introdujo el soporte de staging en vSphere Lifecycle manager Images y la remediación paralela, lo que mejora el tiempo total de remediación al realizar operaciones de ciclo de vida en tus clústeres de vSphere.

Nota: Es importante mencionar que la gestión de actualizaciones de baselines está obsoleta en vSphere 8.0, lo que significa que debes comenzar a migrar a un enfoque declarativo basado en Images (vSphere Lifecycle Manager Images).

Por otro lado, a nivel del vCenter Server, redujimos los problemas que habían durante el proceso de recuperación. En esta versión el vCenter concilia el estado del clúster, después de una restauración a partir de una copia de seguridad, contra un nuevo componente llamado Distributed Key-Value Store que se aloja en los hosts ESXi de un clúster, y almacena el estado y la configuración del clúster, y ahora es considerado por el vCenter como la fuente de información veraz para el estado y la configuración de los clústers de vSphere. De esta manera los cambios realizados después de la ejecución del backup del vCenter, no seperderán ni generarán errores en caso de una restauraciónn sino queserán conciliados con el Distributed Key-Value Store para que el vCenter pueda actualizar su base de datos utilizando dicha información.

Ademas, en esta version se introdujo una nueva vista previa técnica de los vSphere Configuration Profiles, que será nuestra próxima generación de gestión de configuración de clústeres, podriamos decir que es la evolución de los Host Profiles.

Nota: En la version vSphere 8.0 GA, la gestión de Images desde vSphere Lifecycle Manager para un host standalone se podia realizar a través de las API unicamente. Sin embargo, es importante mencionar vSphere Lifecycle Manager Baselines, también conocida como Update Manager, está en proceso de obsolecencia en vSphere 8.x.

Inteligencia Artificial y Aprendizaje Automático

En cuanto a la inteligencia artificial y el aprendizaje automático, estas áreas están creciendo rápidamente y requieren hardware acelerado, típicamente en forma de GPUs. vSphere ofrece ahora la posibilidad de soportar Device Groups, que es una configuración realizada en la capa del hardware, que permite definir dispositivos PCI comunes GPUs y NICs que hacen parte de un mismo PCIe Switch. Esto simplifica la asignación de dispositivos a máquinas virtuales, ya que los dispositivos se presentan como una unidad única a nivel de la capa de virtualización.

Nota: Uno de nuestros primeros partners en apoyar los Device Groups es NVIDIA, que lanzó un controlador compatible para esta funcionalidad. Esto permite a DRS y vSphere HA trabajar con Device Groups para la colocación de máquinas virtuales y la recuperación ante fallos.

En versiones anteriores, las máquinas virtuales que consumían dispositivos de hardware físico mediante DirectPath IO o Dynamic DirectPath IO tenían una movilidad limitada.
En vSphere 8.0 GA, se ha resuelto este problema con Enhanced DirectPath I/O (Device Virtualization Extension) el cual se basa en Dynamic DirectPath IO e introduce un nuevo marco y API para que los proveedores creen dispositivos virtuales respaldados por hardware para permitir una mayor compatibilidad con funciones de virtualización, como la migración mediante vSphere vMotion, la suspensión y reanudación de una máquina virtual y la compatibilidad con instantáneas de disco y memoria. Ahora la mobilidad esta parmitida gracias a un drive instalado tanto en el Guest OS como en el hipervisor.

Mejoras en el Sistema Operativo Invitado y Cargas de Trabajo

En esta sección, exploraremos algunas mejoras en el sistema operativo invitado y las cargas de trabajo. Cada nueva versión de vSphere introduce una nueva versión de hardware virtual, y en esta ocasión, hemos llegado a la versión 20. Esto permite aumentos en los máximos de cómputo y desbloquea muchas características nuevas.

Una de las nuevas políticas es la provisión de TPM virtual, diseñada para ayudar a implementar cargas de trabajo de Windows 11 a gran escala. En vSphere 8.0 GA, los dispositivos vTPM se pueden reemplazar automáticamente durante las operaciones de clonación o implementación. Esto permite seguir las prácticas recomendadas de que cada máquina virtual contenga un dispositivo TPM único.

Además, estamos simplificando la configuración de vNUMA y aumentando los máximos de cómputo, permitiendo hasta ocho dispositivos vGPU por máquina virtual.

Notificaciones de vMotion

También estamos introduciendo las notificaciones de vMotion, que permiten que las máquinas virtuales sean conscientes de los eventos de vMotion, lo que es crucial para aplicaciones sensibles a la latencia. Esto permite que las aplicaciones realicen trabajos previos de preparación a la migración, como detener servicios o hacer failover de manera controlada.

Nota: Las aplicaciones se debe ser reescritas para que admitan las notificaciones de vMotion. O se puede escribir una aplicación asociada como intermediaria entre las notificaciones de vMotion y la aplicación principal.

Gestión de Recursos y Sostenibilidad

En el ámbito de la gestión de recursos, se mejora el rendimiento de DRS mediante un mejor aprovechamiento de las estadísticas de memoria que fueron introducidas en vSphere 7U3. vSphere Memory Monitoring and Remediation (vMMR) ayuda a cubrir la necesidad de monitoreo al proporcionar estadísticas de ejecución tanto a nivel de VM (ancho de banda) como de Host (ancho de banda, tasas de errores). vMMR también proporciona alertas predeterminadas y la capacidad de configurar alertas personalizadas basadas en las cargas de trabajo que se ejecutan en las VM.

En vSphere 8, el rendimiento de DRS se mejora significativamente aprovechando las estadísticas de memoria, lo que da como resultado decisiones de ubicación óptimas para las máquinas virtuales sin afectar el rendimiento ni el consumo de recursos.

También se introdujo métricas verdes para monitorear las emisiones de energía y carbono de la infraestructura de vSphere y las cargas de trabajo, ayudando a las organizaciones a visualizar su huella de carbono.

Nota: Usage es una metrica de potencia real medida en función del uso activo de la CPU y la memoria de las máquinas virtuales. Se deriva de los medidores de potencia conectados a los hosts (IPMI, interfaz de administración de plataforma inteligente).

Nota: Static Power es una metrica potencia inactiva modelada de la máquina virtual, como si la máquina virtual fuera un host físico hipotético configurado con la misma cantidad de CPU y memoria que la máquina virtual.

Seguridad y Cumplimiento

Finalmente, en términos de seguridad, vSphere 8.0 GA es más seguro por defecto. Se eliminó la opción de usar TLS 1.0 y 1.1, dejando solo TLS 1.2 como opción. También se implementó restricciones para evitar que binarios no confiables se ejecuten en ESXi, lo que significa que solo se pueden ejecutar paquetes firmados.

Además, se introduce un tiempo de espera automático para SSH, que se deshabilitará automáticamente si no se utiliza, ayudando a mitigar posibles vectores de ataque.

Conclusión

Esto ha sido un resumen técnico de las novedades en vSphere 8.0 GA. Hay mucho más que explorar y descubrir así que te invito a seguir nuestro blog, y participar en este bonito camino de adopción de nuestras tecnologías VMware By Broadcom.

Recuerda que estamos haciendo un repaso de las funcionalidades que han sido liberadas en cada uno de los updates de vSphere. Posteriormente haremos lo mismo con vSAN, NSX, VCF, y los productos que componen la Aria Suite.

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.

Solucionar Error HTTP 500 en vCenter Server

en 13 noviembre, 202316 octubre, 2024 por Diego Felipe Tunubalá Medinaen vCenter Server, vSphereDeja un comentario

Creo que muchos a administradores en su día a día han experimentado el error HTTP Status 500 – Internal Server Error al intentar hacer login en la UI del vCenter Server. Se que su primer instinto será reiniciar múltiples veces sin un resultado satisfactorio.

En este caso lo primero que debemos hacer es verificar es el estado del certificado configurado en el vCenter, si vemos que nuestro certificado ya expiró como en nuestro caso (Valid from 12/4/2020 to 12/5/2022), no se preocupe, tenemos un procedimiento para regenerarlo y recuperar la gestión del vCenter.

PROCEDIMIENTO

1. Iniciar sesión SSH al vCenter y ejecutar el comando shell

2. Ejecutar el siguiente comando /usr/lib/vmware-vmca/bin/certificate-manager para lanzar el Certificate Management Tools de vCenter Server

3. Digitar la opción 8 y responder confirmar presionando la letra y

4. A continuación podemos dejar los valores por defector del template de vSphere o customizar el template con nuestro valores. Para este caso utilizaremos los valores por default debido a que necesitamos regenerar los certificados default.

Nota: Si decidimos utilizar los valores por defecto podemos presionar la teclar enter varias veces para aceptar los valores por default hasta llegar a las opciones Hostname y VMCA donde debemos especificar el FQDN de nuestro vCenter Server y nuestro Platform Services Controller (PSC). Para versiones superiores a vCenter Server 6.7 donde la única arquitectura soportada es PSC Embedded este valor es el mismo para estos dos inputs.

5. Al final de los inputs presionamos nuevamente la tecla y para confirmar la operación y podemos ir a tomarnos un cafe mientras los certificados son regenerados. Esto puede tardar aproximadamente 20 min.

6. Al final del proceso debemos obtener el mensaje Reset Status : 100% Completed (Reset completed successfully)

7. Por último, solo nos queda verificar que la fecha de nuestros certificado ha cambiado por una fecha valida y que nuestro vCenter ya esta arriba nuevamente.

ATENCIÓN!!!

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

Verificar integridad de medios de instalación VMware (checksum)

en 23 abril, 202113 noviembre, 2023 por Diego Felipe Tunubalá Medinaen Tools, vSphereDeja un comentario

Como ya sabemos, una suma de verificación o checksum, es el resultado de ejecutar una función hash criptográfica dentro de un archivo, que tiene como propósito principal detectar cambios en una secuencia de datos para proteger su integridad. La particularidad de esto es que un pequeño cambio en el archivo provoca una salida totalmente distinta.

Dicho esto, checksum nos permite verificar la integridad del medio de instalación y estar seguros que el contenido del mismo no ha sido alterado y es tal y como lo indica su fabricante.

Lo importante a tener en cuenta en este post es que el objetivo no es garantizar una procedencia confiable del medio de instalación, sino verificar la integridad del archivo descargado.

Dejando un lado la teoría vamos a lo que nos interesa…

PROCEDIMIENTO

Utilizando la línea de comando de Windows (CMD) y la herramienta CertUtil incluida en las versiones mas recientes del sistema operativo. Ejecute el siguiente comando.

CertUtil -hashfile "Ubicacion_y_nombre_del_archivo" MD5

Nota 1: Para no tener que escribir el nombre del archivo, podemos simplemente seleccionarlo y arrastrarlo dentro de la consola de CMD de Windows y de esta manera incluirá la ubicación completa del mismo.

El resultado del comando nos devuelve un número de verificación similar al siguiente. Selecciónelo y cópielo para el siguiente paso (el de su Command Prompt).

e05748cea32d60566f0738a5b811cfdc

Para verificar que el archivo no ha sufrido ninguna modificación durante la descarga o posterior a ella, vaya a la página de descargas de VMware, donde descargó el medio de instalación, utilice la función Buscar… (ctrl+f o command+f) y dentro del campo de búsqueda pegue el numero que devolvió la salida del comando anterior.

De esta manera podemos buscar rápidamente si el numero que nos devolvió la herramienta CertUtil corresponde con el numero de verificación (MD5SUM) publicado por el fabricante.

Nota 2: Sino puede ver los detalles del medio de instalación en pagina de descargas. Haga clic en el enlace Read more para visualizar la información publicada por VMware.

Si el numero es encontrado como en la imagen anterior, el medio de instalación es apto para ser usado. Sino es así, vuelva a descargar el medio de instalación porque seguramente esta corrupto.

Nota 3: Puede utilizar la herramienta CertUtil para la suma de verificación de otros algoritmos hash cambiando el parámetro MD5 en el comando por cualquiera de los siguientes. VMware en su página de descargas publica la información para MD5SUM, SHA1SUM y SHA256SUM.

MD2
MD4
MD5
SHA1
SHA256
SHA384
SHA512

Por ultimo y como recomendación, realice este procedimiento para evitar algunos dolores de cabeza y perder tiempo tratando de solucionar problemas que probablemente vienen del medio de instalación y no del proceso de instalación o actualización.

Limpiando particiones en discos para configuración de vSAN

en 8 julio, 202016 julio, 2022 por Diego Felipe Tunubalá Medinaen VSAN, vSphereDeja un comentario

En esta oportunidad explicaremos como abordar una situación en la cual al intentar crear el cluster vSAN de forma manual a través del asistente de configuración, no tenemos disponibles algunos discos que deberían aparecer para la creación de los Disk Groups. En ese momento nos preguntaremos ¿Por qué no aparecen todos los discos disponibles?, pues bien lo más probable es que el o los discos que no aparecen listados para ser Claimed por vSAN no están vacíos y deban ser formateados para poderlos liberar.

Es aquí donde nos podríamos encontrar con un error común que puede convertirse en un dolor de cabeza sino conocemos su causa raíz. El error básicamente se produce al intentar ejecutar la acción Erase Partitions en la configuración del host en el apartado Configure->Storage->Storage Devices, como se muestra en la siguiente imagen.

Al hacer clic sobre la opción anterior nos mostrará un resumen de las particiones con las que cuenta este disco y razón por la cual no esta disponible para el asistente de configuración de VSAN.

Al hacer click sobre el botón OK, en la mayoría de los casos, las particiones serán eliminadas y el disco quedará disponible para vSAN. Una forma rápida de verificarlo es que al hacer nuevamente clic sobre Erase Partition, no debería listar ninguna partición y el asistente de configuración de vSAN debería ahora listar el o los discos.

¿Y SI FALLA?…

Es ahora cuando aparece el problema ¿Que hacemos si esta tarea falla y nos muestra el siguiente error: “Cannot change the host configuration”? Primero que todo ¡calma, calma!, no tenemos que ir a ninguna línea de comandos a intentar limpiar estas particiones, la solución es mucho más sencilla que eso.

Nota 1: Para las versiones de ESXi anteriores a 7,0, scratch partition es un espacio temporal que se configura automáticamente durante la instalación o el primer arranque de un host ESXi. El instalador de ESXi crea una partición FAT16 de 4GB en el dispositivo de destino durante la instalación si hay suficiente espacio y si el dispositivo se considera local. Esta partición no es creada cuando el hipervisor se instala en tarjetas SD o unidades flash USB.

Nota 2: Si no existe espacio temporal persistente disponible en el disco local o la partición no es creada (en el caso de SD, Flash USB), ESXi almacenará estos datos temporales en la memoria RAM. Esto puede ser problemático en situaciones con poca memoria, pero no es fundamental para el funcionamiento de ESXi.

Explicado lo anterior, el problema pudo haberse producido si ese disco o discos, en algún momento fueron formateados como Datastore (VMFS), y esto hace que el hipervisor configure ese datastore como su mejor candidato para ubicar el Scratch Partition (Partición creada para almacenar la salida de vm-support necesaria para el soporte de VMware).

Por esta razón, la solución a este problema se basa en cambiar la configuración asociada a la opción avanzada del hipervisor ScratchConfig.ConfiguredScratchLocation, que probablemente estará apuntando al datastore local que en algún momento se configuró en dicho disco.

SOLUCIÓN

1. Si ya tiene vCenter instalado navegue en el inventario hasta el Host –> Configure –> Advanced System Settings. Clic en Edit… y en el filtro escriba ScratchConfig.ConfiguredScratchLocation.

2. Sino tiene instalado un vCenter aún, inicie sesión en el Host Client del host en cuestión (en cualquier navegador web https://IP_FQDN_Host ) y navegue hasta Manage->System-> Advanced Settings y en el buscador escriba ScratchConfig.ConfiguredScratchLocation o simplemente Scratch.

3. Independientemente de si se realizó el paso anterior desde el vCenter o desde el Host Client, podrá ver que en el campo value aparecerá la ruta hacia un datastore, lo único que debemos hacer es editar este valor y colocar /tmp, para redireccionarlo a la memoria RAM (no recomendado) o especificar la ruta de un almacenamiento persistente diferente.

Nota 3: Al editar el valor de ScratchConfig.ConfiguredScratchLocation será /tmp, mientras el valor de ScratchConfig.CurrentScratchLocation permanecerá sin cambios. Esto se debe a que es necesario realizar un reinicio del host para que los mismo sean aplicados.

4. Una vez realizado el reinicio, inicie sesión nuevamente en el Host Client y navegue hasta Manage->System-> Advanced Settings. En el buscador escriba ScratchConfig.ConfiguredScratchLocation o simplemente Scratch.

En la columna value podrá observar que el valor tanto para ScratchConfig.ConfiguredScratchLocation como para ScratchConfig.CurrentScratchLocation es /tmp.