NVMe haciendo de RAM: la memoria por niveles funciona si tienes la mitad ociosa

En la crónica del último VMware Explore hay una frase que explica el momento mejor que cualquier gráfico: la DRAM cuesta hoy a menudo varias veces más que el servidor donde va montada. La respuesta de VMware a eso se llama memoria por niveles: si una parte de la RAM lleva horas sin que nadie la toque, que baje a un NVMe local y deje sitio a lo que sí se usa. Está en producto, documentada, y dos sesiones sobre el tema llenaron salas de 500 personas. Lo que menos se ha citado de todo esto es una recomendación que el propio VMware publicó en su blog de Cloud Foundation el 6 de agosto: mantén la memoria activa por debajo del 50 % de la física. Leída al revés, esa recomendación es un diagnóstico.

Qué hace exactamente

La definición de Broadcom es de una sola línea: «Memory Tiering te permite añadir capacidad de memoria a un host ESX usando dispositivos NVMe instalados localmente en el host como memoria por niveles». El hipervisor vigila qué páginas de memoria están frías —nadie las ha leído ni escrito en un buen rato— y las baja al NVMe. Cuando alguien vuelve a pedirlas, suben. Para la máquina virtual todo esto es invisible: sigue viendo sus 64 GB.

La función salió como disponible con VMware Cloud Foundation 9.0 y este año, en la 9.1, VMware la ha retocado para que se porte mejor con bases de datos y le ha añadido paneles que enseñan cuánta actividad de escalonado hay y herramientas de gestión. La documentación de vSphere 9.0 pide vCenter y ESX 9.0 o superior, y la función viene desactivada de fábrica. Y hay hoja de ruta declarada: Dave Morera, arquitecto de marketing técnico de VMware, lo dijo en Explore con estas palabras: «tenemos una hoja de ruta de dos a tres años». Lo que hay puesto en esa hoja de ruta dice bastante sobre lo que falta hoy, y a eso volvemos más abajo.

Escalonar no es tener más memoria

Esto es criterio nuestro y conviene decirlo pronto, porque el titular invita a entenderlo mal. La memoria por niveles no crea memoria: cambia capacidad por latencia. Un acceso a DRAM y un acceso a un NVMe no están en la misma escala; entre uno y otro hay órdenes de magnitud, y esa distancia no la arregla ningún algoritmo. Lo que hace el algoritmo es apostar a que casi nunca vas a pagar ese peaje, porque casi siempre lo que pides está arriba.

La apuesta es razonable. En cualquier cluster con unas cuantas decenas de máquinas hay memoria que no hace nada: entornos de preproducción encendidos desde marzo, servidores de aplicación dimensionados «por si acaso», la máquina de un proyecto que se canceló y nadie apagó. Esa memoria está asignada, ocupa sitio y no la toca nadie. Es exactamente el material que el escalonado se lleva al NVMe sin que se note. Cuando la apuesta se rompe es cuando la máquina que se quedó abajo era la que a las nueve de la mañana se pone a trabajar de golpe.

El número que decide es tuyo, no de VMware

En un artículo del 6 de agosto sobre reservas de memoria, VMware suelta la recomendación operativa más útil de todo el material que hemos leído sobre esta función: mantener la memoria activa por debajo del 50 % de la memoria física total. Es una buena práctica publicada por el fabricante, y aquí viene nuestra lectura: esa frase describe a qué tipo de servidor le sirve esto. Si tu memoria activa está por encima de ese umbral, el escalonado no te va a salvar; te va a trasladar el problema a la latencia.

El problema es que casi nadie sabe cuál es su cifra. Cuando entramos en una infraestructura ajena y preguntamos cuánta memoria está de verdad en uso, la respuesta habitual es la de la pestaña de resumen, la memoria asignada, que mide otra cosa. Medirlo no tiene misterio y no hace falta comprar nada para hacerlo: se coge el histórico de memoria activa de varias semanas, incluidos los cierres de mes, y se compara con la física instalada. Ese cociente decide si esta función es una buena compra o un parche caro. Lo mismo defendíamos cuando escribimos sobre la subida del precio de la RAM: antes de firmar módulos hay que saber cuánta de la que ya tienes está trabajando.

Los requisitos son una lista de la compra

La documentación de Broadcom y la nota de Explore dejan una lista de condiciones que conviene leer seguida, porque por separado cada una parece menor:

• El NVMe tiene que ser local. Literal: «los dispositivos NVMe no pueden ser sobre fabric ni Ethernet. Deben estar instalados localmente». Adiós a resolverlo desde la cabina que ya tienes.
• Y no vale cualquier NVMe. Broadcom pide la especificación de caché de vSAN, uso mixto, 3 DWPD. En Explore se concretó todavía más: mínimo 100.000 escrituras por segundo y 7.300 TB de escrituras de por vida.
• Activar o desactivar exige el host en modo mantenimiento. Es decir: vaciar el servidor y moverlo todo. No es un interruptor que se prueba un martes por la tarde.
• Se pierden cosas por el camino. Con la memoria por niveles activada, la documentación dice que Quick Boot no está soportado en ese host y que suspender máquinas a memoria tampoco; el hot-plug y el «preparar para retirar» quedan fuera para los discos NVMe que hacen de nivel, no para el resto. Suspender a disco y los snapshots siguen funcionando. El servidor tampoco puede llevar Intel Optane ni memoria persistente NVDIMM-N.
• Hay techo. Por defecto el sistema limita la capacidad escalonada al tamaño de la DRAM, ratio 1:1, con un máximo de 4 TB por partición. La proporción por defecto y la que se recomienda de partida es esa 1:1; VMware permite subirla hasta 1:4, y cuando lo hace apunta a casos concretos como los escritorios virtuales, no como ajuste general.

Puesta en fila, la lista deja de parecer una función y empieza a parecer un presupuesto: unidades NVMe empresariales de alta resistencia en cada host, una ventana de mantenimiento por servidor y la suscripción al día. Las exigencias tienen su razón, porque a ese NVMe se le va a escribir mucho y muy seguido. Pero es la parte que no cabe en el titular. La respuesta a que el hierro se haya encarecido implica comprar más hierro, y de un tipo que tampoco se ha librado de la subida: las mismas previsiones de mercado que citamos en nuestro repaso al precio de la memoria daban a la NAND un +70-75 % intertrimestral en el segundo trimestre de 2026, del mismo tirón de demanda que la DRAM.

El 25 % del que no se sabe casi nada

La cifra que dio VMware en Explore es que la memoria por niveles soporta hoy alrededor del 75 % de las cargas. Se agradece que lo diga con un número. La pega es que nadie publica cuál es el 25 % restante. Lo único de ese grupo que tiene nombre propio está en la hoja de ruta: las monster VM —las máquinas de hasta 960 vCPU y 16 TB de memoria repartidas entre varios servidores físicos— están previstas para VCF 9.2, hacia mayo de 2027.

Y aquí conviene que seamos precisos, aunque el argumento quede menos redondo: una máquina de 16 TB repartida entre varios servidores es un caso extremo, y el ERP de una pyme o el motor de informes que se dispara en el cierre de mes casi con seguridad caen dentro del 75 % que ya está soportado. No vamos a insinuar lo contrario para que la crítica suene mejor. Lo que sí sostenemos, y es criterio nuestro, es que un porcentaje agregado no contesta la única pregunta que te importa: si la máquina concreta que te está apretando la memoria está dentro o fuera de ese 75 %. Esa lista no está publicada, así que la respuesta se saca probando en un host, no leyendo una ficha.

Y no, la reserva no te saca de ahí

El reflejo de cualquiera que lleve años en vSphere es: «vale, pues a la base de datos le pongo una reserva completa y me quedo tranquilo». No funciona así, y lo dice VMware en su propio artículo del 6 de agosto: «no fija la memoria en DRAM». Una reserva impide que el host reclame esa memoria por swap, ballooning o compresión, pero «esas páginas reservadas se pueden seguir sirviendo tanto desde DRAM como desde NVMe». La distinción que usan es buena: el número de la reserva es una promesa al planificador; la memoria fijada es un contrato con el hardware. No son lo mismo.

Sacar de verdad una máquina del escalonado se hace desactivándolo para ella, y eso tiene un efecto que en el mismo artículo se explica con un ejemplo: al desactivarla y reservarla entera, la proporción del resto del host se desplaza de 1:1 a 1:2. Traducido: la DRAM que le has garantizado a la máquina importante se la has quitado a sus vecinas, que ahora dependen el doble del NVMe. Es una decisión perfectamente legítima —hay cargas que la merecen—, pero es un reparto, no un regalo. Quien piense que puede blindar tres o cuatro máquinas críticas y dejar el resto igual, va a encontrarse el coste en el sitio donde no lo estaba mirando.

Cuándo sí sale a cuenta

Con todo lo anterior encima de la mesa, la función sigue resolviendo un problema real. Sale a cuenta, en nuestra opinión, cuando se cumplen tres cosas a la vez: tu memoria activa está claramente por debajo de la mitad de la física; el cluster tiene muchas máquinas medianas y tibias, no dos monstruos; y ya estás dentro de VCF con la versión que toca, de modo que el coste incremental es el de los discos y las ventanas de mantenimiento, no el de una plataforma nueva. En ese escenario, meter NVMe en cada host es bastante más barato que meter DRAM, y encaja con el consejo que damos desde hace meses: estirar el hierro que ya tienes antes que comprar en el peor momento del mercado.

Las dos cifras que más se van a repetir en las presentaciones son un 30 % menos de ciclos de CPU y un 40 % menos de coste de propiedad. Son afirmaciones del fabricante, recogidas en la crónica de Explore, y no las hemos medido nosotros. Ni las damos por falsas ni las repetimos como si fueran nuestras: si alguien las va a usar para justificar una compra, que pida el detalle de con qué carga y contra qué línea base se obtuvieron, porque un porcentaje de coste de propiedad sin escenario de partida no significa nada.

Lo que hacemos antes de tocar nada

Cuando llega la conversación de «no tenemos memoria», lo primero que miramos es la diferencia entre memoria asignada y memoria tocada, con histórico. Casi siempre aparece lo mismo: máquinas encendidas que nadie reclama, entornos que sobrevivieron a su proyecto, dimensionados que se copiaron de una plantilla. Apagar y ajustar no da para una presentación bonita, pero es gratis y no añade una pieza nueva que pueda fallar. Solo después tiene sentido hablar de ballooning, de deduplicación de páginas —con sus pegas, que las tiene: cuesta CPU— o, ahora, de escalonar a NVMe.

Y falta nombrar la palanca que más veces hemos visto mover la factura de verdad, que es de licencias y no técnica. Ya escribimos que el éxodo masivo de VMware no ha ocurrido y que buena parte del mercado ha renegociado en vez de irse, y también que hay casos en los que NO recomendamos migrar a Proxmox. No somos resellers de nadie: ni de VMware ni de Proxmox, y no vendemos licencias de ninguno. Lo que sí decimos, con la misma tranquilidad, es que si estás mirando esta función porque el hardware se ha encarecido, el calendario de tus licencias merece estar en la misma hoja de cálculo que los discos.

En everyWAN diseñamos y operamos infraestructura virtualizada en las dos plataformas desde hace años, hacemos migraciones de VMware a Proxmox cuando la cuenta sale, y decimos que no cuando no sale. Si lo que hace falta es alguien que mire tus números antes de que firmes nada, eso es consultoría y se cobra por horas, no por licencias.

Fuentes (verificadas el 2 de septiembre de 2026): la crónica de VMware Explore, la hoja de ruta, la cifra del 75 % de cargas soportadas, la definición y el calendario de las monster VM (hasta 960 vCPU y 16 TB repartidas entre varios servidores físicos, previstas para VCF 9.2 hacia mayo de 2027), los requisitos del NVMe (100.000 escrituras por segundo y 7.300 TB de escrituras de por vida), las cifras de 30 % menos de ciclos de CPU y 40 % menos de coste de propiedad, la cita de Dave Morera y el dato de las salas de 500 personas proceden de The Register, 1 de septiembre de 2026. La definición de la función, la ratio 1:1 por defecto con máximo de 4 TB, el requisito de NVMe local («no pueden ser sobre fabric ni Ethernet»), la especificación de caché de vSAN con 3 DWPD, el modo mantenimiento, la incompatibilidad con Intel Optane y NVDIMM-N y las limitaciones de Quick Boot, suspensión a memoria y hot-plug están en la documentación de Broadcom para vSphere (páginas de las versiones 9.0 y 9.1). La recomendación de mantener la memoria activa por debajo del 50 % de la física —que no está en la documentación de producto sino en el blog corporativo, y que allí aparece ligada al efecto de las reservas completas sobre el presupuesto de DRAM—, la frase «no fija la memoria en DRAM», la distinción entre promesa al planificador y contrato con el hardware y el ejemplo del desplazamiento de 1:1 a 1:2 son del artículo «Memory Tiering and VM Memory Reservation», 6 de agosto de 2026, del blog oficial de VMware Cloud Foundation. La disponibilidad inicial con VCF 9.0 está anunciada en el mismo blog. Criterio propio, no hecho reportado: que escalonar cambia capacidad por latencia y no crea memoria; la lectura del 50 % como diagnóstico de a qué host le sirve la función; que la lista de requisitos funciona como lista de la compra; que las máquinas con problema de memoria suelen ser las grandes, justo las que están en la hoja de ruta y no en el producto de hoy; y el orden de palancas que aplicamos (medir asignado frente a tocado, apagar y ajustar, y solo después escalonar). La ratio de hasta 1:4 y su encaje con casos como los escritorios virtuales provienen del anuncio de disponibilidad de VCF 9.0 y de la crónica de Explore, no de la página de documentación citada. La cifra de la NAND (+70-75 % intertrimestral en el segundo trimestre de 2026) es una previsión de TrendForce ya recogida y verificada en nuestro post sobre el precio de la memoria, que se enlaza en el cuerpo. Las cifras de rendimiento y coste de propiedad son afirmaciones del fabricante y no las hemos verificado con mediciones propias.