sábado, 24 de octubre de 2026
Infra crew

Infraestructura TI con contexto

Virtualización

¿Qué es vNUMA?

·2 fuentes

Por InfraCrew Editorial · Criterios editoriales y correcciones

vNUMA expone al sistema invitado una topología de memoria virtual relacionada con los nodos del host. Revisamos rendimiento, tamaño y matices de hot-add.

Vista cenital de una placa de servidor con dos sockets de procesador y bancos de memoria próximos a cada uno, distribución física que ayuda a explicar la topología de memoria expuesta por vNUMA. InfraCrew aparece discretamente en el borde de la bandeja.

vNUMA es la topología NUMA virtual que un hipervisor presenta a una máquina virtual. Ayuda al sistema operativo invitado a entender cómo se distribuyen sus procesadores y memoria virtuales en relación con los nodos de acceso a memoria del host. Esa información puede influir en la latencia de memoria y en la planificación de cargas grandes.

La «v» señala que esta vista pertenece a la máquina virtual. No es un mapa literal de los módulos DIMM instalados en el servidor. El hipervisor decide cómo exponer la topología virtual de acuerdo con el hardware, los recursos asignados y sus reglas; la configuración visible puede diferir de un host a otro.

Por qué importa la proximidad entre CPU y memoria

En un sistema NUMA, acceder a memoria asociada al mismo nodo suele tener características distintas de acceder a memoria conectada a otro nodo. Una VM con varios vCPU y mucha memoria puede beneficiarse de que el hipervisor y el sistema invitado conozcan una distribución que se acerque a la del hardware. La afinidad y la localidad pueden afectar al rendimiento, aunque el resultado también depende de la carga y de cómo se ejecute.

Sin embargo, exponer más nodos virtuales no acelera automáticamente una aplicación. Si el sistema invitado o la aplicación distribuyen mal sus hilos y memoria, el detalle adicional puede no ayudar. La topología es una señal para la planificación, no una optimización mágica. Hay que compararla con métricas y patrones de acceso reales.

El ajuste de tamaño de la VM también importa. Asignar más procesadores virtuales de los que necesita puede hacer que abarque dominios físicos innecesarios. Una máquina virtual sobredimensionada puede empeorar la localidad que se buscaba mejorar. Conviene empezar por medir CPU lista, latencia de memoria y utilización bajo la carga representativa.

-InfraCrew dice: Añadir CPU virtual por si acaso también añade decisiones al hipervisor. «Por si acaso» escala deprisa.-

Lo que ve el invitado depende de la plataforma

Cada hipervisor expone y administra vNUMA según su implementación y versión. En VMware vSphere, por ejemplo, la generación de topología virtual depende del tamaño configurado y otros parámetros. No se debe copiar un umbral de vCPU de una guía antigua como regla universal: cambian versiones, compatibilidad del hardware virtual y condiciones de la VM.

También hay diferencias con la conexión en caliente de recursos. En vSphere 8.0 y versiones de hardware virtual compatibles, Broadcom documenta una opción para conservar o exponer topología vNUMA al añadir CPU en caliente. La función requiere condiciones concretas y compatibilidad del sistema invitado; activar CPU Hot Add no garantiza ese comportamiento en cualquier VM.

La memoria en caliente plantea un matiz distinto: la documentación de Broadcom indica que habilitar Memory Hot Add puede llevar a presentar un único nodo UMA en determinados escenarios, lo que afecta a vNUMA. CPU Hot Add y Memory Hot Add no deben tratarse como un interruptor idéntico. Antes de modificarlos, revisa los requisitos de versión, licencia y sistema operativo invitado documentados para el entorno.

-InfraCrew dice: «Añadirlo en caliente» suena sencillo hasta que la topología también entra en la conversación.-

Cómo investigar una VM lenta

Primero identifica el hipervisor, la versión, la compatibilidad de hardware virtual y los recursos asignados. Después observa métricas tanto en el host como en la VM. Una captura puntual del número de nodos no explica por sí sola el rendimiento. Conviene correlacionar el momento del problema con uso de CPU, espera, memoria y comportamiento de la aplicación.

Contrasta la topología que detecta el sistema operativo invitado con la configuración y recomendaciones del fabricante de la aplicación. Las bases de datos y cargas paralelas pueden tener pautas propias. El conocimiento del invitado debe alinearse con lo que la carga puede aprovechar. Cambiar la topología sin validar la aplicación puede desplazar el cuello de botella, no resolverlo.

Ajustar con una prueba y una vuelta atrás

Registra la configuración inicial y define qué resultado demostraría una mejora: menor latencia, menos espera, rendimiento más estable o mayor capacidad útil. Cambia un factor cada vez en una ventana controlada. Comparar antes y después con la misma carga evita atribuir al ajuste una variación casual.

Comprueba asimismo reinicios, migraciones y operaciones de mantenimiento previstas. La función de hot-add puede ser útil operativamente, pero mantener una topología efectiva también importa para ciertas cargas. La elección debe responder a la prioridad del servicio, y las limitaciones del invitado deben formar parte de la decisión.

Si la prueba empeora resultados o muestra una topología inesperada, vuelve a la configuración registrada y consulta la matriz de compatibilidad del fabricante. vNUMA se diagnostica con contexto de plataforma y mediciones, no con una receta universal de núcleos por nodo.

-InfraCrew dice: Una vista NUMA bonita en el invitado no sustituye al gráfico de latencia que nadie abrió.-

Diccionario de la Crew

NUMA — Arquitectura de acceso a memoria en la que el coste puede depender de la proximidad entre CPU y memoria.

CPU Hot Add — Capacidad de añadir CPU virtual a una máquina en ejecución, sujeta a requisitos de hipervisor y sistema invitado.

Fuentes consultadas

También te puede interesar

Dos armarios de servidores en un laboratorio de migración y un portadiscos sobre un carro técnico con etiqueta Infracrew.Virtualización

Nutanix Move 6.3.3 elimina la carga de VDDK en migraciones de ESXi a AHV

DirectPath conecta un snapshot de disco al appliance Move como dispositivo de bloque local y copia los datos hacia AHV sin subir una librería VDDK. La versión 6.3.3 es una edición especial para despliegues nuevos, con requisitos de permisos, compatibilidad y limitaciones que conviene revisar antes de planificar un cutover.

·2 fuentes