Proxmox: la opción ‘Ballooning’ que crea presión de memoria artificial

Todo está “bien” hasta que deja de estarlo: la VM tiene mucha RAM configurada, la CPU está ociosa, el disco es rápido y, sin embargo, la latencia se arrastra. Tu base de datos empieza a comportarse como si funcionara en una memoria USB. El invitado reporta presión de memoria, el swap crece, las cachés desaparecen y tus gráficos parecen un electrocardiograma.

Entonces lo notas: ballooning está activado. Alguien pensó que era una “eficiencia gratis”. Lo que en realidad compraste fue escasez sintética: presión de memoria fabricada por el hipervisor que el sistema invitado no puede razonar, solo a la que puede reaccionar.

Ballooning en una frase (y por qué deberías sospechar)

El ballooning de memoria permite al host recuperar RAM de una VM en ejecución forzando al invitado a “usar” memoria internamente, provocando que el invitado recupere sus propias páginas.

Eso suena civilizado —como pedir prestada una silla en una fiesta. En la práctica, el host está arrancando los cojines del sofá mientras todavía estás sentado, y el invitado no tiene forma de saber si los cojines eran caché “gratis” o conjunto de trabajo crítico.

Regla con opinión: si ejecutas algo stateful o sensible a la latencia (bases de datos, búsqueda, brokers, runners de CI con cachés calientes, ZFS dentro de invitados, servidores de archivos Windows), el ballooning suele ser un impuesto innecesario. Compra RAM. O reduce intencionalmente las VMs. No dejes que el hipervisor haga dietas sorpresa durante la carga de trabajo.

Algunos datos y contexto histórico (6–10 puntos rápidos)

• El ballooning es anterior al auge de la nube. VMware popularizó el ballooning en los primeros días de ESX como herramienta práctica para overcommit de memoria cuando la RAM era cara y la consolidación era el argumento de venta.
• El ballooning en KVM suele implementarse mediante virtio-balloon. El invitado ejecuta un controlador que asigna páginas y las “fija” para que el host pueda recuperar su memoria subyacente.
• El ballooning apunta a memoria “no utilizada”… según la definición del invitado. Pero lo que el invitado llama “no utilizado” incluye caché de archivos que puede ser extremadamente valiosa para el rendimiento.
• Linux mejoró sus heurísticas de reclaim con el tiempo, pero sigue adivinando. Reclaim, swapping y la caída de cachés dependen de la carga de trabajo y de la política del kernel, no de tus SLO.
• Windows también soporta ballooning, pero la visibilidad es diferente. El comportamiento del controlador y los contadores de rendimiento no siempre coinciden con lo que el hipervisor cree haber recuperado.
• Ballooning no es lo mismo que memory hotplug. Hotplug cambia la vista del invitado sobre la memoria “instalada”; el ballooning mantiene la memoria instalada y crea presión dentro de ella.
• Transparent Huge Pages puede amplificar el desastre. Si el invitado usa THP intensamente, el reclaim puede fragmentar la memoria, aumentar el trabajo de compactación y generar picos de CPU durante la presión.
• Los hipervisores también tienen una herramienta más brutal: el swapping. Si el host overcommit supera lo que el ballooning puede recuperar, el host puede hacer swap de páginas del invitado —a menudo peor que el swap interno porque el invitado no lo puede optimizar.
• Proxmox facilita activar ballooning, lo cual es conveniente y peligroso. Es una casilla que parece ahorro hasta que pagas en latencia tail.

Qué hace realmente el ballooning dentro de Proxmox + KVM

Proxmox VE es una capa de gestión sobre KVM/QEMU. Cuando configuras la memoria de una VM, en la práctica hay dos números que importan:

• Memory (max): lo que QEMU puede dar a la VM (y lo que el invitado cree que tiene instalado).
• Balloon (min/target): hasta qué punto Proxmox tiene permitido reducir la VM bajo presión o por política.

Con ballooning activado, QEMU usa el dispositivo virtio-balloon. El controlador del invitado se infla asignando páginas de memoria y reportándolas al host como “no necesito estas”. Entonces el host puede reutilizar la RAM física subyacente para otras VMs o para sí mismo.

Hay dos consecuencias prácticas clave:

1. El invitado sigue creyendo que tiene la misma cantidad de RAM instalada. El SO no recibe un aviso cortés de “ahora tienes 12 GB en lugar de 16 GB”. Simplemente ve presión de memoria y reacciona.
2. El hipervisor está tomando una decisión de rendimiento con información incompleta. No puede ver qué páginas del invitado están “calientes” desde la perspectiva de la aplicación; solo ve páginas. Así que crea presión y deja que el invitado entre en pánico responsablemente.

El ballooning puede estar bien para VMs de propósito general poco usadas—piensa en servidores utilitarios que pasan la mayor parte del día inactivos. Es una apuesta para cualquier cosa con cachés o conjuntos de trabajo en estado estacionario. Que es la mayoría de cargas de producción.

Hay una vieja idea de operaciones (parafraseando) de Gene Kranz: la disciplina y el comportamiento responsable vencen a la improvisación cuando los sistemas se ponen raros. El ballooning es improvisación disfrazada de política.

Cómo la presión de memoria “falsa” se convierte en dolor real

Seamos claros: la presión de memoria es “falsa” solo en su origen. El dolor es completamente real.

1) El invitado libera primero la caché de páginas (y lo notas después)

Linux reclamará con gusto la caché de archivos bajo presión. Eso es normal y a menudo correcto. Pero si tu rendimiento depende de la calidez de la caché—bases de datos leyendo índices, nodos de búsqueda escaneando segmentos, CI descargando dependencias—el ballooning provoca churn de caché que parece una regresión aleatoria del rendimiento del disco.

Lo que hace esto desagradable: puede que no veas saturación del disco. Verás latencia. Más IOPS, lecturas más pequeñas, más trabajo de metadatos. ZFS en el host también se pone más ocupado porque el invitado pide datos que antes mantenía calientes.

2) Luego el invitado empieza a hacer swap (y culpas la capa equivocada)

Una vez que las cachés se van, el reclaim alcanza páginas anónimas: heap, stacks, memoria JVM, buffers de base de datos. Si el invitado tiene swap activado (normalmente lo tiene), el kernel hace swap. La latencia de tu aplicación se dispara y empiezas a culpar al array de almacenamiento, la red o “ese vecino ruidoso”. A veces el vecino ruidoso es la política de tu propio hipervisor.

Chiste #1: El ballooning es como el “hot desking” para la RAM—genial hasta que vuelves del almuerzo y tu silla está haciendo swap.

3) La presión en el host lleva al host a hacer swap (lo cual es peor)

Si el host está sobreasignado y el ballooning no puede recuperar suficiente memoria con rapidez, el host puede empezar a hacer swap. El swap a nivel de host es brutal porque el invitado no sabe qué páginas suyas fueron expulsadas. El invitado cree que la memoria sigue residente; se sigue encontrando con fallos mayores ocultos en la capa del hipervisor. La resolución de problemas se vuelve un juego de sombras.

4) El timing del reclaim del hipervisor no coincide con el timing de tu carga

El ballooning no está sincronizado con los patrones de carga. Puede inflarse justo antes de que empiece tu trabajo por lotes, justo cuando sube la cola o durante fases de compactación intensiva. No tienes voto. Tu aplicación descubre la nueva realidad página por página de fallos.

5) Puede convertir el overprovision “seguro” en sobrecarga caótica

Hay un caso de uso legítimo para el overcommit: en una flota grande, no todas las VMs alcanzan picos al mismo tiempo. Pero el ballooning te permite llevar el sistema a una región donde un pico correlacionado (día de despliegue, trabajos mensuales, failover por incidente) crea contención repentina. Esa contención no se comparte de forma justa. Se comparte según los objetivos de balloon y quién se aprieta primero.

Quién debería usar ballooning (rara vez) y quién no (la mayoría de ustedes)

El ballooning puede ser aceptable cuando:

• Las VMs están mayoritariamente inactivas y son sin estado (jump boxes, herramientas internas de bajo tráfico).
• Tienes una gestión de capacidad fuerte y aburrida y el ballooning es solo una red de seguridad.
• El SO invitado y las aplicaciones toleran el reclaim sin SLOs de latencia tail.
• Tienes holgura de RAM en el host y usas el ballooning principalmente para reducir desperdicio, no para habilitar consolidación agresiva.

El ballooning suele ser mala idea cuando:

• Ejecutas bases de datos (PostgreSQL, MySQL, MSSQL), búsqueda (Elasticsearch/OpenSearch), brokers de mensajes (Kafka/RabbitMQ), caches (Redis) o servicios con mucha JVM.
• Dependes de la caché del sistema de archivos como característica de rendimiento (la mayoría de servicios Linux lo hacen, quieras admitirlo o no).
• Ejecutas ZFS en el host y ya dependes de RAM para ARC. Ahora estás balanceando dos capas de caché hambrientas.
• Necesitas rendimiento predecible más que “alta utilización”.

Mi recomendación por defecto: desactiva el ballooning para VMs críticas, asigna memoria intencionalmente, mantiene holgura en el host y trata el overcommit como una sustancia controlada.

Guía rápida de diagnóstico

Si el rendimiento se está desplomando y sospechas del ballooning, no te vuelvas loco. Triagia en este orden:

Primero: ¿está el host realmente bajo presión de memoria?

• Revisa la memoria libre del host, uso de swap y si kswapd está activo.
• Si el host está haciendo swap, arregla eso antes de culpar a los invitados.

Segundo: ¿los invitados están reclamando/haciendo swap porque el ballooning los redujo?

• Revisa el estado del balloon por VM y la brecha entre la memoria máxima y la memoria actual ballooned.
• Dentro del invitado, revisa fallos mayores, swap in/out y actividad de reclaim.

Tercero: ¿la latencia de almacenamiento es síntoma del colapso de caché?

• Revisa patrones de aciertos de caché del invitado de forma indirecta: aumento de read IOPS, IO de metadatos, lecturas aleatorias y latencia elevada sin saturación de throughput.
• En hosts con ZFS, revisa el comportamiento del ARC y eventos de presión de memoria.

Cuarto: decide la acción inmediata menos riesgosa

• Si el ballooning está apretando una VM crítica: sube su objetivo de balloon (o desactiva ballooning) y asegúrate de que el host tenga holgura.
• Si el host está sobrecargado: migra carga, añade RAM, reduce asignaciones o apaga VMs no críticas.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estos son los chequeos que realmente ejecuto en hosts Proxmox y dentro de invitados. Cada tarea incluye: comando, qué significa la salida y la decisión que tomas.

Task 1: Check host memory + swap at a glance

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            62Gi        41Gi       1.8Gi       1.2Gi        20Gi        18Gi
Swap:           16Gi       6.5Gi       9.5Gi

Meaning: “available” es lo que importa para la comodidad del host Linux. El uso de swap en el host ya es no trivial.

Decision: Si el swap del host está creciendo durante el incidente, trátalo como P0. Reduce carga o aumenta RAM antes de ajustar invitados.

Task 2: Identify whether the host is actively reclaiming

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0 6815744 1887340  9120 16720256  12  210   320   410  980 2100 12  6 77  5  0
 1  1 6817780 1750020  9152 16611020   0  540   410   920 1020 2400 10  7 73 10  0
 3  0 6820100 1628800  9152 16500100   0  820   390   800 1100 2600 14  9 67 10  0
 2  0 6821100 1522100  9152 16388900   0  600   420   700 1050 2500 13  8 69 10  0
 1  0 6822100 1489000  9152 16299000   0  480   380   650 1000 2300 11  7 72 10  0

Meaning: so (swap out) está activo y wa (IO wait) está subiendo. Eso indica que el host está empujando páginas fuera.

Decision: Detén la hemorragia: migra una VM, para cargas no críticas o añade memoria. El ballooning no te salvará si ya cruzaste la línea.

Task 3: See top memory consumers on the host

cr0x@server:~$ ps -eo pid,comm,rss,vsz --sort=-rss | head
  PID COMMAND           RSS    VSZ
 4121 qemu-system-x86 8234500 17000000
 3988 qemu-system-x86 8012200 16500000
 4550 qemu-system-x86 6123000 13000000
 1872 pveproxy         320000  550000
 1601 pvestatd         210000  420000
 1023 zfs              180000  300000
  950 pvedaemon        120000  300000
  811 systemd-journal   95000  160000
  621 corosync          82000  210000

Meaning: Los procesos QEMU dominan. Eso es esperado; ahora necesitas saber si están ballooned o fijados.

Decision: Pasa de “existe presión en el host” a “qué VMs la están provocando y están siendo exprimidas”.

Task 4: List Proxmox VMs and identify candidates

cr0x@server:~$ qm list
      VMID NAME                 STATUS     MEM(MB)    BOOTDISK(GB) PID
       101 db-prod-1            running    16384      200.00       4121
       102 api-prod-1           running     8192       60.00       3988
       103 ci-runner-1          running     4096       80.00       4550
       120 jumpbox-1            running     2048       20.00       4801

Meaning: Ahora tienes VMIDs para consultar. La columna “MEM(MB)” es la máxima configurada, no necesariamente el uso actual por ballooning.

Decision: Inspecciona primero las que tienen necesidades de rendimiento ajustadas (db-prod-1).

Task 5: Check whether ballooning is configured for a VM

cr0x@server:~$ qm config 101 | egrep -i 'memory|balloon'
balloon: 8192
memory: 16384

Meaning: Esta VM puede ser empujada hasta 8 GB desde un máximo de 16 GB. Eso no es una red de seguridad; es otra personalidad.

Decision: Para servicios críticos, establece balloon: 0 (desactivar) o súbelo cerca del máximo si realmente necesitas un reclaim mínimo.

Task 6: Inspect runtime balloon stats from the host

cr0x@server:~$ qm monitor 101 --cmd 'info balloon'
balloon: actual=8704

Meaning: La VM está actualmente ballooned a ~8.5 GB. Si la carga espera comportamiento de 16 GB, has encontrado al villano.

Decision: Si necesitas alivio inmediato: aumenta el objetivo de balloon o desactiva ballooning y confirma holgura en el host.

Task 7: Confirm the virtio balloon device exists (guest)

cr0x@server:~$ lsmod | grep balloon
virtio_balloon         24576  0

Meaning: El invitado es capaz de ballooning. Si está cargado, obedecerá las solicitudes de balloon del host.

Decision: Para ciertos appliances o cargas sensibles, puedes eliminarlo/ponerlo en blacklist—pero es preferible arreglarlo en la configuración de Proxmox para evitar sorpresas luego.

Task 8: Check guest memory pressure indicators

cr0x@server:~$ cat /proc/pressure/memory
some avg10=42.31 avg60=28.10 avg300=12.90 total=987654321
full avg10=8.22 avg60=4.10 avg300=1.20 total=12345678

Meaning: PSI muestra que el sistema con frecuencia se queda bloqueado en reclaim de memoria (some) y a veces completamente bloqueado (full), lo cual mata la latencia.

Decision: Si PSI está elevado durante el incidente y el ballooning está activo, trata el ballooning como causa probable—no solo correlación.

Task 9: Check guest swapping and reclaim behavior quickly

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  2 1843200  12000  20000  340000   80  220   900   700 1200 2500 18  9 50 23  0
 2  1 1845500   9000  19000  320000   20  480  1200   900 1300 2700 20 10 44 26  0
 1  1 1849000   8000  17000  300000    0  520  1100  1000 1250 2600 17  8 48 27  0
 2  1 1852000   7000  16000  280000    0  600  1000  1100 1400 2900 22 11 40 27  0
 1  1 1856000   6000  15000  260000    0  430   950   980 1320 2800 19  9 45 27  0

Meaning: so es persistente. El invitado está activamente haciendo swap. La caché también se está reduciendo.

Decision: Detén la tormenta de swap: dale a la VM RAM real (desactiva ballooning o aumenta la memoria) y luego considera ajustar swappiness solo después de que la estabilidad vuelva.

Task 10: Check major faults (guest) to detect paging pain

cr0x@server:~$ grep -E 'pgmajfault|pgfault' /proc/vmstat
pgfault 348778901
pgmajfault 129988

Meaning: Los fallos mayores requieren IO. Una tasa creciente de pgmajfault durante el incidente es consistente con swapping o fallos de caché.

Decision: Si los fallos mayores suben cuando el balloon se reduce, esto no es “lentitud de la aplicación”. Es inanición de memoria.

Task 11: Check the host’s ZFS ARC pressure (if using ZFS)

cr0x@server:~$ arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:01:01   512    88     14    40   45    20   23    28   32   22.1G  24.0G
12:01:02   680   210     30   140   67    30   14    40   19   18.4G  24.0G
12:01:03   700   260     37   190   73    35   13    35   13   16.2G  24.0G

Meaning: El tamaño del ARC (arcsz) está disminuyendo mientras miss% sube. La presión de memoria del host está forzando la expulsión del ARC, incrementando IO de backend.

Decision: Si tanto el ARC del host está colapsando como los invitados están ballooned, tienes un desastre de caché en dos capas. Añade RAM o reduce la presión de las VMs; no “tunes” la física.

Task 12: Check per-QEMU memory from the host to spot weirdness

cr0x@server:~$ pmap -x 4121 | tail -n 5
total kB         17123456  8901232  120000  8200000

Meaning: RSS es alto; el ballooning no siempre se refleja inmediatamente como menor RSS debido a cómo se contabiliza y reutiliza la memoria.

Decision: Usa estadísticas de balloon y los indicadores de presión del host, no solo RSS, para razonar sobre el reclaim. RSS solo puede engañarte.

Task 13: Check kernel logs for OOM or reclaim warnings (host or guest)

cr0x@server:~$ journalctl -k -S -30min | egrep -i 'oom|out of memory|kswapd|memory pressure' | tail
Feb 04 12:00:12 server kernel: Memory cgroup out of memory: Killed process 2881 (java) total-vm:8123456kB, anon-rss:3456789kB, file-rss:12345kB, shmem-rss:0kB

Meaning: El invitado o el host pueden estar matando procesos si la presión es severa. El ballooning puede contribuir reduciendo la memoria efectiva.

Decision: Si ves OOM kills, deja de optimizar y empieza a asignar. Arregla el presupuesto de memoria primero.

Task 14: Disable ballooning for a VM (controlled change)

cr0x@server:~$ qm set 101 --balloon 0
update VM 101: -balloon 0

Meaning: Ballooning desactivado. La VM ahora debería mantener su memoria configurada sin reclaim del hipervisor.

Decision: Haz esto solo si el host tiene suficiente RAM. Si el host ya está apretado, puedes simplemente mover el dolor a otro lado (swap del host).

Task 15: Raise minimum balloon target instead of disabling (compromise)

cr0x@server:~$ qm set 102 --balloon 7168
update VM 102: -balloon 7168

Meaning: La VM 102 puede ser exprimida, pero no por debajo de 7 GB. Esto es un guardarraíl controlado de “no la dejes morir de hambre”.

Decision: Usa esto para servicios de criticidad media donde algo de reclaim es aceptable, pero las tormentas de swap no lo son.

Task 16: Validate host overcommit posture quickly

cr0x@server:~$ pvesh get /nodes/server/qemu --output-format yaml | egrep 'vmid|name|memory|balloon' -n | head -n 30
1:vmid: 101
2:name: db-prod-1
3:memory: 16384
4:balloon: 0
5:vmid: 102
6:name: api-prod-1
7:memory: 8192
8:balloon: 7168
9:vmid: 103
10:name: ci-runner-1
11:memory: 4096
12:balloon: 2048

Meaning: Puedes ver rápidamente quién puede ser exprimido y en qué medida.

Decision: Alinea la política de ballooning con los niveles de servicio. Si una VM crítica tiene un rango de balloon enorme, arréglalo ahora, no durante el próximo incidente.

Tres microhistorias corporativas desde el campo

Mini-historia 1: El incidente causado por una suposición errónea

Una compañía SaaS mediana migró un conjunto de servicios internos desde hardware antiguo a un cluster Proxmox limpio. Hicieron lo correcto: energía redundante, SSDs decentes, NICs duales y backups que realmente restauraban. Luego hicieron una cosa mal: asumieron que “ballooning significa que la VM devuelve memoria verdaderamente no utilizada”.

Su VM PostgreSQL se configuró con 32 GB máximo y 16 GB de balloon. En papel, suficiente. En realidad, la carga dependía de la caché de páginas de Linux y de buffers compartidos de PostgreSQL ajustados para la memoria mayor. Durante horas laborales, el clúster se puso algo ocupado, Proxmox infló el balloon y el invitado empezó a reclamar con fuerza.

Los síntomas fueron sutiles al principio: picos ocasionales de consultas, tiempos de checkpoint más largos, más jitter de IO. El equipo persiguió la latencia de almacenamiento e incluso cambió versiones de firmware de NVMe. Mientras tanto, el invitado crecía silenciosamente en uso de swap en segundo plano porque había sido entrenado para creer que “poseía” 32 GB incluso mientras el balloon lo mantenía reducido.

El outage llegó en un deploy martes cuando el tráfico y las migraciones de fondo se solaparon. La latencia tail cruzó el umbral de alerta y lo superó con creces. El autoescalado no ayudó porque escaló réplicas de aplicación, no la VM de la base de datos. La base no estaba limitada por CPU; se estaba ahogando en fallos mayores.

La solución fue aburrida e inmediata: desactivar ballooning para la VM de la base de datos, dimensionar la memoria a lo que el host realmente podía permitirse y mantener holgura en el host. El rendimiento se estabilizó en minutos. La línea más dolorosa del postmortem fue también la más honesta: “Tratamos la caché como gratuita.” La caché nunca es gratis; la pagas en RAM o la pagas en latencia.

Mini-historia 2: La optimización que salió mal

Un gran departamento de TI tenía un mandato: aumentar la densidad de virtualización. El cluster Proxmox ejecutaba docenas de VMs Windows y Linux, muchas de ellas “baja prioridad”. Alguien sugirió activar ballooning en todas partes con mínimos agresivos. La idea era recuperar memoria inactiva y meter más VMs en cada nodo.

Funcionó—al principio. Los gráficos de memoria del host se veían bien. La utilización subió. El informe semanal tenía números que hicieron asentir a la gerencia. Entonces llegó la ventana de parches mensual, y lo “baja prioridad” dejó de ser baja prioridad. Todos parchearon, reiniciaron, compilaron, escanearon y registraron al mismo tiempo.

El ballooning se infló en toda la flota. Los invitados Windows empezaron a paginar. Los invitados Linux perdieron cachés y entraron en reclaim. El controlador de dominio—configurado como “no crítico” porque no era orientado a cliente—también se vio exprimido. La latencia de autenticación subió. De repente muchos servicios no podían iniciar sesión, lo que provocó reintentos, lo que aumentó la carga, lo que empeoró el reclaim. Bucle de retroalimentación clásico, ahora con burocracia extra.

Operaciones hizo la danza habitual: culpar al SAN, culpar a la red, culpar al parche. Pero el verdadero fallo fue de política: habían construido un sistema que dependía de que las cargas nunca se correlacionaran. Las empresas son fábricas de correlación. Ventanas de parches, trabajos de fin de trimestre y escaneos de vulnerabilidades están sincronizados por diseño.

Revirtieron el ballooning en VMs de infraestructura, pusieron mínimos sensatos para el resto y crearon un presupuesto de capacidad que asumiera picos correlacionados. La densidad bajó un poco. Los incidentes bajaron mucho. La única “optimización” que quedó fue la correcta: compra suficiente RAM para las cargas que realmente ejecutas.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Un equipo fintech más pequeño ejecutaba Proxmox para una mezcla de servicios: API, un broker de mensajes, un par de bases de datos y observabilidad. Tenían una regla poco glamorosa: no ballooning en servicios tier-0, y un requisito estricto de 25–30% de holgura de memoria en el host.

No fue popular en compras. La RAM no es barata, y la holgura “no usada” parece desperdicio en una hoja de cálculo. Pero el equipo se mantuvo firme y documentó esto como requisito de fiabilidad, no como preferencia.

Un día, un desarrollador activó accidentalmente un job por lotes descontrolado en una VM analítica no crítica. La CPU subió, el uso de memoria subió y la VM empezó a comer caché de páginas como palomitas. En un host apretado, eso podría haber forzado ballooning en otros o empujado al host a swap.

En cambio, nada más flinchó. La VM ruidosa se volvió más lenta, como debía. La base de datos se mantuvo estable. El broker de mensajes conservó su latencia tail. Throttlearon el job y siguieron con su día.

Así es la buena infraestructura: el radio de impacto es predecible. No es emocionante. No crea historias de héroes. Evita esas historias en silencio.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: la VM “tiene RAM” pero aún hace swap

Causa raíz: El ballooning redujo la memoria efectiva de la VM; el invitado sigue viendo la RAM instalada pero enfrenta presión de reclaim internamente.

Solución: Desactiva el ballooning (qm set <vmid> --balloon 0) para esa VM o sube el objetivo mínimo de balloon cerca del máximo. Verifica que el host tenga holgura.

2) Síntoma: picos de latencia aleatorios, especialmente después de periodos de baja actividad

Causa raíz: Colapso de caché. El ballooning reclamó memoria usada como caché del sistema de archivos; la carga se vuelve sensible a la latencia de IO hasta que la caché se recalienta.

Solución: No hagas balloon a cargas dependientes de caché. Dimensiona la memoria adecuadamente. Si es necesario, aísla esas VMs en nodos con más RAM y menos inquilinos.

3) Síntoma: la espera de IO del host sube, pero los discos no están “al máximo”

Causa raíz: Swapping o tormentas de page-in generan mucho IO aleatorio pequeño con alta latencia, no necesariamente alto throughput.

Solución: Confirma con vmstat y fallos mayores del invitado. Elimina la presión de swap del host; reduce el overcommit; deja de balloonear VMs críticas.

4) Síntoma: ARC de ZFS se reduce y la tasa de aciertos cae durante periodos “ocupados”

Causa raíz: Presión de memoria en el host—a menudo por overcommit más dinámicas de ballooning—fuerza la expulsión del ARC, agravando los fallos de caché del invitado.

Solución: Incrementa la holgura de RAM del host. Considera ajustar zfs_arc_max solo después de arreglar el overcommit; limitar el ARC para “ahorrar memoria” a menudo solo traslada el dolor al IO.

5) Síntoma: desactivaste ballooning pero las cosas empeoraron

Causa raíz: El host ya estaba sobreasignado; el ballooning estaba enmascarando un déficit de capacidad. Desactivarlo llevó al host a swap u OOM.

Solución: Trátalo como problema de capacidad: migra VMs, reduce la memoria configurada, añade RAM o reparte cargas entre nodos. Ballooning no sustituye la planificación de capacidad.

6) Síntoma: “Solo los runners de CI están lentos”

Causa raíz: Los runners de CI dependen de cachés (cachés de paquetes, capas Docker). El ballooning los interrumpe; los tiempos de build se vuelven impredecibles.

Solución: Da a los runners de CI RAM fija o mueve el caching a un almacenamiento externo diseñado para ello. Si debes exprimir runners, hazlo intencionalmente con menor memoria máxima, no con ballooning dinámico.

7) Síntoma: invitados Windows se sienten lentos pero las métricas no muestran alarma

Causa raíz: Ballooning más la gestión de memoria de Windows puede ocultar el “por qué” real detrás de contadores de alto nivel; percibes primero lag para el usuario.

Solución: Correlaciona con estadísticas de balloon del host (qm monitor ... info balloon) y la presión de memoria del host. Si el host está exprimiendo la VM, deja de hacerlo.

8) Síntoma: OOM kills frecuentes dentro de una carga containerizada en una VM

Causa raíz: El ballooning reduce la memoria disponible de la VM; dentro de ella, los cgroups aplican límites; la carga golpea su OOM de cgroup más rápido.

Solución: Alinea presupuestos: la memoria de la VM debe cubrir la holgura de los contenedores. Desactiva ballooning o fija un mínimo alto. Luego revisa límites de contenedores.

Chiste #2: El ballooning es la única dieta donde la balanza miente primero y tu base de datos llora después.

Listas de verificación / plan paso a paso

Checklist A: Decide si ballooning pertenece a tu entorno

1. Haz inventario de tipos de carga: bases de datos, búsqueda, brokers, caches, CI, servidores de archivos, “miscelánea”.
2. Marca servicios tier-0 y tier-1: todo lo que tenga SLOs de latencia estrictos o de lo que dependan otros sistemas (DNS, auth, bases de datos).
3. Para tier-0/tier-1: pon ballooning en off (balloon: 0) a menos que tengas una razón muy fuerte.
4. Para tier-2/tier-3: si habilitas ballooning, fija un mínimo conservador (no 50% a menos que quieras 50% de rendimiento).
5. Establece una política de host: mantén holgura de memoria (me gusta 25–30% para cargas mixtas; más si haces mucho caching ZFS).
6. Documenta excepciones con dueños y triggers de rollback.

Checklist B: Remediación segura en producción cuando sospeches ballooning

1. Confirma que el host no está swapando intensamente (free -h, vmstat).
2. Confirma que la VM está ballooned por debajo de su máximo (qm config + qm monitor ... info balloon).
3. Revisa PSI del invitado y actividad de swap (/proc/pressure/memory, vmstat).
4. Si la VM es tier-0: sube el objetivo de balloon inmediatamente (o desactiva) y observa la memoria del host.
5. Si el host está al límite: migra una VM fuera del nodo primero, luego desactiva ballooning.
6. Tras la estabilización: ajusta la memoria máxima a un número veraz y mantén ballooning apagado para ese servicio.

Checklist C: Construye un modelo de memoria sensato para nodos Proxmox

1. Empieza por la RAM física.
2. Resta una reserva fija para el host (OS + servicios Proxmox + margen de seguridad).
3. Resta la reserva para caché de almacenamiento (expectativas de ZFS ARC, metadata, buffers de IO).
4. Presupuesta la RAM restante a las VMs como asignaciones fijas para tier-0/1.
5. Sólo entonces considera ballooning para VMs de baja criticidad, y limita cuánto se puede recuperar.
6. Planifica eventos correlacionados: ventanas de parches, jobs por lotes, failover, modo incidente.

Preguntas frecuentes

1) ¿El ballooning de Proxmox es “malo” o solo se usa mal?

Es una herramienta fácil de usar mal. En producción, a menudo se convierte en un sustituto de la planificación de capacidad. Usado con prudencia para VMs de baja criticidad puede estar bien. Usado ampliamente, fabrica latencia.

2) ¿Cuál es la diferencia entre ballooning y memory hotplug?

Hotplug cambia la vista del invitado sobre la RAM instalada (gana o pierde dispositivos de memoria). El ballooning mantiene la RAM instalada constante y crea presión interna forzando reclaim.

3) ¿Por qué el ballooning causa swap dentro del invitado?

Porque el invitado intenta satisfacer asignaciones de memoria bajo presión. Primero elimina cachés, luego reclama páginas anónimas; si eso no basta, hace swap—especialmente si el host sigue empujando el balloon más abajo.

4) Si el ballooning recupera memoria “no utilizada”, ¿por qué baja el rendimiento?

Porque “no utilizada” incluye caché. La caché puede no estar activamente asignada por aplicaciones, pero evita IO y mantiene la latencia predecible. Recuperarla es como tirar tus herramientas porque no las estás sosteniendo en ese segundo.

5) ¿Debería desactivar el swap dentro de los invitados para evitar el dolor del ballooning?

No como primer paso. Desactivar swap puede transformar la presión de memoria en OOM kills, que suelen ser peores. Arregla la causa (ballooning/overcommit). Luego decide la política de swap por carga.

6) ¿Puede el ballooning ayudar a prevenir OOM en el host?

Sí, a veces. Es una forma de recuperar memoria antes de que el host llegue al límite. Pero si dependes rutinariamente de ello, estás operando demasiado cerca del borde. La solución correcta es holgura.

7) ¿Por qué veo swap en el host aunque el ballooning esté activado?

Porque el ballooning tiene límites (objetivos mínimos, velocidad de reclaim, comportamiento del invitado). Si el host está sobreasignado o varias VMs hacen pico a la vez, el ballooning no puede recuperar suficiente rápido y el host hace swap de todos modos.

8) ¿A qué debo poner el mínimo del balloon si mantengo ballooning activo?

Empieza alto. Para servicios que te importan, pon el mínimo cerca del máximo—piensa “puede recuperar un poco de holgura inactiva”, no “puede reducir a la mitad la VM”. Para VMs de cajón de sastre, puedes ser más agresivo, pero prueba bajo carga.

9) ¿El ballooning interactúa mal con ZFS en el host?

Pue-de. ZFS adora la RAM para ARC. Si sobreasignas VMs y luego las ballooneas mientras el host también presiona el ARC, puedes acabar con doble colapso de caché: los invitados pierden caché, el host pierde ARC y los discos sufren.

10) ¿Cómo sé que el ballooning es el cuello de botella y no la CPU o el almacenamiento?

Correlaciona: el balloon actual se reduce, PSI y swap del invitado suben, los fallos mayores aumentan y el rendimiento se desploma sin saturación proporcional de CPU. Ese patrón es muy característico.

Conclusión: próximos pasos prácticos

El ballooning no es malvado. Es simplemente extremadamente dispuesto a convertir tu carga de producción en un experimento de gestión de memoria sin pedir permiso.

Haz lo siguiente:

1. Elige tus VMs tier-0 y desactiva el ballooning en ellas hoy.
2. Verifica la holgura del host: si estás rutinariamente cerca del límite, arregla la capacidad antes de ajustar configuraciones.
3. Usa el ballooning solo como política controlada para VMs de baja criticidad, con mínimos conservadores.
4. Instrumenta la presión de memoria: actividad de swap en el host, PSI del invitado y balloon actual vs máximo. Hazlo visible para que la “lentitud misteriosa” sea un gráfico, no un debate.
5. Escribe la regla: rendimiento predecible vence a la consolidación ingeniosa. Tu canal de incidentes futuro te lo agradecerá.