10 errores en Proxmox que no quieres cometer (y qué hacer en su lugar)

Si alguna vez te has metido de lleno en el mundo de los homelabs, seguramente has oído hablar de Proxmox, la querida plataforma de virtualización de código abierto. Es potente, flexible y completamente gratuita. Pero esa libertad también trae una curva de aprendizaje que te muerde si no tienes cuidado.

Un usuario decidió ahorrarles ese dolor a los demás y publicó un minimanual con lecciones aprendidas a golpes en su propia experiencia. Su guía abierta en PDF recoge 10 errores habituales en Proxmox, y la reacción de la comunidad fue una mezcla de "gracias" y "a mí también me pasó". Van mucho más allá de los fallos de novato, porque hasta los usuarios con experiencia se han llevado la mano a la frente con algunos de ellos.

Aquí tienes un repaso más detallado de esas 10 trampas de Proxmox, con comentarios y contexto de la comunidad de Proxmox en general.

1. ZFS sin planificar bien la RAM

ZFS es increíble… hasta que se come tu sistema vivo. La vieja regla general es un gigabyte de RAM por cada terabyte de almacenamiento bruto. Ignórala y ZFS puede hundir tu rendimiento o, peor aún, tumbar el sistema por completo.

Un usuario comentó que la regla le generaba confusión y señaló incoherencias en las propias cuentas del autor. La conclusión se mantiene: si usas ZFS, tienes que planificar a conciencia cómo asignas la memoria. Y si tu sistema tiene menos de 16GB de RAM, quizá ZFS no sea la mejor opción.

Qué hacer en su lugar: calcula la proporción entre almacenamiento y RAM y piensa si añadir L2ARC o SLOG tiene más sentido que meter más memoria.

2. El mito de que "la ECC es obligatoria"

Ah, el eterno debate sobre la ECC. Hay quien dice que usar ZFS sin RAM ECC es buscarse la corrupción de datos, y hay quien lo llama alarmismo.

Un participante lo explicó mejor que nadie: la ECC no evita los bitflips; los registra y los corrige. Sin ECC puedes sufrir corrupción sin que el sistema te avise, pero no es algo seguro. Todo depende de cuánto valores tus datos y de lo a prueba de balas que quieras que sea tu sistema.

Qué hacer en su lugar: si tus datos importan de verdad, invierte en ECC. Si estás experimentando, las copias de seguridad y un diseño inteligente importan más que obsesionarse con el tipo de memoria.

3. Usar RAIDZ para el almacenamiento de las VMs

RAIDZ está pensado para archivos grandes y secuenciales, como bibliotecas multimedia o copias de seguridad. Las VMs son otra historia. Como RAIDZ escribe franjas repartidas por varios discos, la E/S aleatoria se convierte en un cuello de botella.

Los veteranos de Proxmox dicen que es un error habitual al principio. En montajes con muchas VMs, los espejos en franjas (espejos ZFS) ofrecen mucho mejor rendimiento y resiliencia.

Qué hacer en su lugar: usa espejos, o incluso espejos en franjas de ZFS (un montaje tipo RAID10), para tus VMs, y guarda RAIDZ para el almacenamiento en frío.

4. Descartar Local-LVM por inflexible

Muchos usuarios dan por hecho que Local-LVM es demasiado rígido para ser útil. En la práctica suele ser el método de almacenamiento más rápido de fábrica, y en despliegues pequeños funciona perfectamente. Sí, le faltan los snapshots y las funciones avanzadas que ofrece ZFS, pero es estable y sencillo.

Qué hacer en su lugar: empieza con Local-LVM si no necesitas florituras. Siempre puedes migrar más adelante, cuando crezcan tus necesidades.

5. La trampa del tipo de CPU "host"

Sobre el papel, usar las funciones exactas de la CPU del host en tu VM suena genial, porque esperarías el máximo rendimiento. La pega es que no podrás migrar esa VM a otra máquina si la CPU no es idéntica.

Un usuario mencionó problemas todavía mayores: con la CPU "host", las mitigaciones para Spectre y Meltdown podrían faltar a menos que se gestionen a mano.

Qué hacer en su lugar: elige un modelo de CPU genérico como x86-64-v2-AES para equilibrar rendimiento y compatibilidad. Usa "host" solo si estás completamente seguro de que la VM no tendrá que migrar.

6. Montar HA sin cumplir los requisitos

La alta disponibilidad (HA) de Proxmox no es enchufar y listo. Muchos usuarios la configuran con dos nodos y sin dispositivo de quórum, que es la receta perfecta para un split-brain.

Necesitas tres votos para tener quórum. Eso suele significar tres nodos físicos, o dos nodos más un QDevice. Si escatimas aquí, acabarás con VMs atascadas en el limbo o, peor aún, con dos nodos intentando ejecutar la misma VM.

Qué hacer en su lugar: usa tres nodos, o dos nodos más un QDevice, y asegúrate de que el fencing está bien configurado.

7. Una estrategia de copias de seguridad incompleta

El error es tratar las copias de seguridad como algo "que estaría bien tener", porque son innegociables. Un paso en falso y tu VM entera puede desaparecer.

La guía insiste en planificar dónde y cuándo haces las copias, además de cómo restauras. Un usuario añadió algo importante: prueba siempre tus copias, porque una copia que no se puede restaurar es un pisapapeles.

Qué hacer en su lugar: automatiza copias diarias o semanales, guárdalas en remoto (o al menos fuera del disco) y haz restauraciones de prueba de vez en cuando.

8. Ejecutar Docker directamente en Proxmox

Este provocó un coro de "¿por qué iba alguien a…?", y aun así es sorprendentemente habitual. Ejecutar Docker en el host de Proxmox mezcla contenedores e hipervisores, lo que es una pesadilla de estabilidad y de seguridad.

La recomendación es sencilla: aísla. O ejecutas Docker en un contenedor LXC o levantas una VM ligera solo para gestionar contenedores (hola, fans de Portainer o Rancher).

Qué hacer en su lugar: no ejecutes Docker en el nodo Proxmox pelado. Usa una VM o un LXC y mantén limpio tu hipervisor.

9. Sin monitoreo hasta que algo se rompe

Este es el "asesino silencioso". La mayoría de los usuarios se saltan el monitoreo hasta que algo explota, y para entonces puede que los registros ya no sirvan de nada.

La guía original toca el monitoreo básico, pero algunos miembros de la comunidad defienden montajes más avanzados: traps SNMP, alertas por correo, Prometheus + Grafana o, como mínimo, una solución basada en agentes.

Qué hacer en su lugar: monta el monitoreo el primer día. Hasta unas alertas básicas por correo son mejor que nada.

10. Desplegar servicios directamente en el hipervisor

No instalarías tus aplicaciones en el bloque del motor del coche, así que ¿por qué ibas a desplegar servicios en tu hipervisor?

Proxmox está pensado para ser ligero y centrado en lo suyo, y nunca se diseñó como una distro Linux de uso general. Añadir servicios aumenta tu superficie de ataque y hace más peligrosas las actualizaciones.

Qué hacer en su lugar: pon tus servicios en VMs o contenedores y deja en paz al hipervisor.

Menciones de honor de la comunidad

• Clonar VMs de Windows sin Sysprep.
• Borrar pools de almacenamiento de LXC que todavía están referenciados.
• No usar sincronización horaria, algo especialmente crítico para la autenticación TOTP.
• Fiarse de las fuentes de alimentación externas de los servidores Minisforum (¡cámbialas pronto!).

Reflexiones finales

Proxmox es como un lienzo en blanco: puedes construir algo increíble o meterte tú solo en un callejón sin salida. Evitar todos los errores no es realista, así que el truco está en aprender las lecciones correctas rápido. Y gracias a la transparencia de un usuario (y a lo que añadió después una comunidad apasionada), no tienes que aprenderlo todo por las malas.

Así que antes de tu próximo qm create o zfs pool create, respira, vuelve a leer esto y ahórrate el drama. Lo único peor que una VM corrupta es darte cuenta de que la has estropeado tú.