Proxmox VE se ha convertido en una de las alternativas más serias para las empresas que quieren recuperar el control sobre su infraestructura de virtualización. Su base open source, la integración con KVM y LXC, las capacidades de clustering, la alta disponibilidad, Ceph, ZFS y Proxmox Backup Server lo han colocado de lleno en el radar de CIOs, CTOs y equipos de sistemas que buscan una plataforma potente sin atarse a modelos de licenciamiento cerrados.
Pero Proxmox no debería entenderse solo como una forma de reducir costes frente a VMware. Esa lectura se queda corta. En producción, Proxmox es una plataforma de infraestructura crítica y exige la misma disciplina que cualquier entorno empresarial: red bien diseñada, almacenamiento adecuado, quórum, alta disponibilidad, backup, monitorización, pruebas de fallo y operación del día a día.
Cada vez vemos más este patrón en los proyectos de cloud privado. Muchas empresas no quieren simplemente “pasarse a Proxmox”. Quieren construir una plataforma estable, controlada y lista para crecer. Y para eso no basta con instalar Proxmox en varios servidores: la arquitectura de debajo tiene que estar bien diseñada.
Uno de los errores más comunes al abordar Proxmox es empezar por la interfaz de gestión o por la creación de máquinas virtuales. Es comprensible: Proxmox VE ofrece una experiencia de usuario muy directa y pone fácil desplegar VMs y contenedores en poco tiempo. Pero en un entorno real, la estabilidad no depende solo del hipervisor.
Depende de cómo se han diseñado los nodos, cómo se separan las redes, qué almacenamiento se usa, cómo se gestiona el quórum, qué pasa si un nodo cae, dónde se guardan los backups y cuánto margen hay para crecer sin rediseñar todo el entorno.
| Capa de diseño | Pregunta a resolver antes de producción |
|---|---|
| Cómputo | ¿Cuántos nodos hacen falta y cuánto margen queda ante un fallo? |
| Red | ¿Están separados gestión, migración, almacenamiento, backup y tráfico de cliente? |
| Almacenamiento | ¿Local, Ceph, NFS/iSCSI, almacenamiento en red o síncrono? |
| Alta disponibilidad | ¿Qué VMs deben reiniciarse automáticamente y dónde? |
| Quórum | ¿Puede el clúster tomar decisiones seguras durante un fallo? |
| Backup | ¿Dónde están las copias, cómo se verifican y cuánto tarda una restauración? |
| Operación | ¿Hay monitorización, alertas, documentación y procedimientos de mantenimiento? |
Esta diferencia es lo que separa un laboratorio funcional de una plataforma empresarial. En un laboratorio, basta con que las VMs arranquen. En producción, hay que preguntarse qué pasa cuando un host falla a las 3 de la mañana, cuando el almacenamiento se acerca al límite, cuando una migración coincide con un pico de tráfico o cuando una restauración se convierte en el único camino de recuperación.
En un cloud privado basado en Proxmox, los nodos de cómputo son una pieza central. No son solo servidores donde “caben” las máquinas virtuales: son la base sobre la que se reparten CPU, memoria, conectividad, disponibilidad y mantenimiento.
Diseñamos estos entornos sobre nodos dedicados, de modo que cada cliente disponga de recursos de cómputo exclusivos, sin vecinos ruidosos ni competencia directa por CPU y RAM con terceros. Esa separación es importante cuando la infraestructura sostiene ERPs, bases de datos, ecommerce, escritorios virtuales, plataformas SaaS, sistemas internos o aplicaciones de cara al cliente.
El valor de Proxmox sobre nodos dedicados no es solo rendimiento. Es también previsibilidad. El equipo técnico sabe qué hardware hay disponible, cuál es la capacidad real, cuánto se puede sobreasignar, qué margen queda ante un fallo y cuándo conviene añadir nuevos nodos.
| Decisión sobre nodos | Impacto operativo |
|---|---|
| Número mínimo de nodos | Determina HA, quórum y tolerancia a fallos |
| CPU y memoria por nodo | Condiciona la densidad de VMs y el overcommit |
| Redundancia | Permite mantenimiento sin tumbar todo el entorno |
| Homogeneidad del hardware | Simplifica migraciones, balanceo y operación |
| Margen disponible | Evita que un fallo deje el clúster sin capacidad suficiente |
| Pool de nodos de reserva | Reduce los tiempos de recuperación tras un fallo físico |
Un clúster de tres nodos puede ser suficiente para muchos entornos iniciales, pero no todos los clústeres de tres nodos son iguales. Si los tres trabajan al 90 % de capacidad, la alta disponibilidad será sobre todo teórica: si un nodo cae, los otros dos no tendrán capacidad real para absorber la carga. Por eso el dimensionamiento debe contemplar el fallo, no solo la operación normal del día a día.
La pregunta no debería ser “cuántas VMs caben”. La pregunta correcta es: “cuántas VMs pueden seguir funcionando si pierdo un nodo y necesito mantener el servicio”.
Proxmox puede mover máquinas virtuales entre nodos, gestionar alta disponibilidad y trabajar con distintos tipos de almacenamiento. Pero todas esas capacidades dependen de la red. Si la red está mal diseñada, el clúster acabará evidenciándolo en forma de latencia, migraciones lentas, backups que afectan a producción o problemas de comunicación entre nodos.
En un entorno profesional, conviene separar al menos lógicamente varios tipos de tráfico: gestión, Corosync, migración, almacenamiento, backup y tráfico de cliente. En proyectos más exigentes, esa separación debería ser también física o basada en redes dedicadas con ancho de banda garantizado.
| Tipo de tráfico | Riesgo si se mezcla sin control |
|---|---|
| Gestión | Exposición innecesaria y operación más difícil en incidentes |
| Corosync / clúster | Pérdida de estabilidad si hay latencia o pérdida de paquetes |
| Migración | Degradación de VMs si compite con tráfico de producción |
| Almacenamiento | Alta latencia en discos virtuales y bases de datos |
| Backup | Impacto en horas críticas si no se limita o programa |
| Cliente | Contención con el tráfico interno del clúster |
Corosync merece una mención especial. Es la base de la comunicación del clúster y del quórum. No debería convivir alegremente con tráfico pesado ni depender de enlaces inestables. Una red saturada puede no tumbar las VMs de inmediato, pero sí hacer que la gestión del clúster sea menos fiable justo cuando hacen falta decisiones rápidas.
La migración en vivo también depende de esta capa. En Proxmox funciona muy bien cuando el diseño la acompaña, pero una VM grande con mucha memoria y alta actividad de escritura puede tardar más de lo esperado si la red de migración no tiene capacidad suficiente. La conclusión es simple: la red no se diseña al final, se diseña antes de crear la primera VM de producción.
El almacenamiento suele ser la parte que más condiciona el comportamiento de un entorno Proxmox. Y también una de las más subestimadas. En producción no basta con mirar los terabytes disponibles: hay que mirar latencia, IOPS, ancho de banda, redundancia, snapshots, replicación, recuperación, crecimiento y mantenimiento.
Proxmox puede trabajar con muchas opciones: almacenamiento local, ZFS, Ceph, NFS, iSCSI, Fibre Channel, cabinas externas o almacenamiento en red. Cada opción tiene sentido en escenarios concretos, pero ninguna es universal.
| Opción de almacenamiento | Ventaja principal | Precaución |
|---|---|---|
| SSD/NVMe local | Muy buen rendimiento local | Menos flexibilidad para HA sin replicación |
| ZFS local | Snapshots, integridad y gestión avanzada | Requiere RAM, planificación y no llenar el pool |
| Ceph | Almacenamiento distribuido integrado | Exige nodos, discos y red bien dimensionados |
| NFS/iSCSI | Integración sencilla con cabina compartida | Depende de la cabina/red y del diseño de disponibilidad |
| Almacenamiento en red | Separa cómputo y datos | Requiere baja latencia y redundancia real |
| Almacenamiento síncrono | RPO muy bajo y continuidad avanzada | Mayores exigencias de arquitectura y coste |
Una arquitectura sólida puede apoyarse en almacenamiento en red y almacenamiento síncrono diseñados para desacoplar cómputo y datos. Esa separación permite escalar nodos de cómputo y almacenamiento de forma más independiente, simplifica ciertos escenarios de recuperación y reduce la dependencia de los discos locales de cada host.
Esto no significa que Ceph o ZFS no sean buenas opciones. Lo son, cuando encajan. Ceph puede ser muy potente en entornos con suficientes nodos, red rápida y operación especializada —lo explicamos a fondo en la guía de Ceph para Proxmox—. ZFS es una tecnología excelente para integridad, snapshots y rendimiento local. Pero en entornos empresariales donde el objetivo es una plataforma de cloud privado manejable y predecible, el almacenamiento en red puede aportar una base sólida para operación, crecimiento y continuidad.
Lo importante es no convertir el almacenamiento en una decisión improvisada. Muchos incidentes de virtualización empiezan como problemas de almacenamiento: pools demasiado llenos, latencia creciente, snapshots olvidados, backups saturando enlaces, cabinas sin margen o discos que no se comportan como se esperaba bajo carga.
La alta disponibilidad de Proxmox VE permite que las máquinas virtuales o contenedores se reinicien automáticamente en otro nodo cuando el nodo original falla. Es una funcionalidad muy valiosa y una de las razones por las que Proxmox puede usarse en entornos empresariales. Pero conviene entender bien sus límites.
HA no significa que una VM nunca se interrumpa. Si un nodo cae, la VM tiene que arrancar en otro. Eso implica un tiempo de recuperación. Para muchas cargas, es aceptable. Para otras, no. Una base de datos crítica, una aplicación transaccional o un sistema con usuarios conectados pueden necesitar además replicación a nivel de aplicación, balanceadores, clústeres internos o sus propios mecanismos de tolerancia a fallos.
| Concepto | Qué protege | Qué no sustituye |
|---|---|---|
| HA de Proxmox | Fallo de nodo y reinicio automático de VM | Alta disponibilidad a nivel aplicación |
| Migración en vivo | Movimiento planificado de VMs entre nodos | Recuperación ante fallo súbito de host |
| Backup | Recuperación de datos y sistemas | Continuidad inmediata |
| Replicación de aplicación | Continuidad de servicio a nivel software | Copia histórica |
| DR | Recuperación ante fallo de sede o desastre | Operación normal del clúster local |
La confusión entre HA, backup y disaster recovery es habitual. La alta disponibilidad ayuda a restaurar el servicio tras la caída de un nodo. El backup permite recuperar datos o sistemas a un punto anterior. El disaster recovery habilita la respuesta ante un fallo mayor, como la pérdida de un centro de datos, un problema grave de plataforma o un incidente de seguridad. Son capas distintas y deben coexistir.
En Proxmox, como en otros sistemas de clúster, el quórum es lo que permite tomar decisiones evitando situaciones peligrosas como el split-brain. Si el clúster no tiene quórum, puede bloquear ciertas operaciones para proteger la consistencia.
Por eso los clústeres de dos nodos hay que manejarlos con especial cuidado. Pueden tener sentido en escenarios concretos, pero suelen requerir un qdevice o un diseño muy bien probado. En entornos de producción, lo más común y recomendable es empezar con al menos tres nodos para ofrecer un quórum más fiable.
| Diseño de clúster | Lectura práctica |
|---|---|
| 1 nodo | Sin alta disponibilidad real |
| 2 nodos sin qdevice | Alto riesgo de perder quórum |
| 2 nodos con qdevice | Puede funcionar en escenarios controlados |
| 3 nodos | Base común para HA fiable |
| 4+ nodos | Mejor capacidad de crecimiento y mantenimiento |
El quórum no debería descubrirse durante un incidente. Hay que probarlo antes. Simular la caída de un nodo, la pérdida de red, reinicios controlados y mantenimientos ayuda a entender cómo se comporta el clúster y evita sorpresas en producción.
Los snapshots son útiles, pero no son backups. Esta frase se repite a menudo porque sigue siendo uno de los errores más comunes en virtualización. Un snapshot sirve para preservar el estado de una VM durante una ventana corta: una actualización, un cambio de configuración, una prueba controlada o un despliegue. Si se mantiene demasiado tiempo, puede crecer, consumir almacenamiento y afectar al rendimiento.
El backup debe diseñarse de otra forma. En entornos Proxmox, Proxmox Backup Server aporta copias incrementales, deduplicación, verificación, cifrado e integración natural con Proxmox VE. PBS puede combinarse con almacenamiento de objetos compatible con S3 o NFS para retención y archivo, además de capas de almacenamiento en red más rápidas cuando hace falta reducir los tiempos de restauración.
| Elemento | Uso correcto |
|---|---|
| Snapshot | Cambio temporal y ventana corta de mantenimiento |
| Backup local | Recuperación rápida, pero insuficiente como única copia |
| Proxmox Backup Server | Copias incrementales, deduplicadas y verificables |
| Almacenamiento de archivo | Retención y copia separada a largo plazo |
| Copia en otro centro de datos | Protección ante fallo grave de sede |
| Pruebas de restauración | Validación real de que el backup funciona |
Una política de backup profesional debe responder a preguntas concretas: cada cuánto se hacen las copias, cuánto tiempo se retienen, dónde se guardan, quién puede borrarlas, cómo se verifican, cuánto tarda una restauración y qué sistemas se recuperan primero. Para el diseño de esos plazos conviene fijar bien los objetivos de RTO y RPO y aplicar el principio de copias inmutables que explicamos en la regla 3-2-1 frente a ransomware.
Un backup que nunca se ha restaurado no es una garantía. Es una hipótesis.
Proxmox permite usar CPU y memoria de forma eficiente, pero el overcommit no es ilimitado. Asignar demasiadas vCPU o demasiada RAM sin medir el uso real acaba generando contención. El problema no siempre aparece al principio. Aparece cuando varias VMs consumen recursos al mismo tiempo, cuando corren los backups, cuando crece una base de datos o cuando un nodo cae y el resto del clúster debe absorber su carga.
| Recurso | Riesgo de un mal dimensionamiento | Buena práctica |
|---|---|---|
| vCPU | Contención y latencia de CPU | Medir uso real y evitar asignación excesiva |
| RAM | Swapping o falta de margen ante un fallo | Reservar capacidad para picos y HA |
| Disco | Latencia y espera de I/O | Medir IOPS, no solo capacidad |
| Red | Cuellos de botella en migración, backup y almacenamiento | Separar tráfico y dimensionar los enlaces |
| Backup | Impacto en producción | Ventanas, límites y monitorización |
| HA | Falta de capacidad cuando cae un nodo | Diseñar con margen N+1 o equivalente |
En un cloud privado, el dimensionamiento debe revisarse de forma continua. Las cargas cambian. Una VM que hoy consume poco puede volverse crítica mañana. Un entorno que empezó con diez VMs puede crecer hasta cien. La ventaja de una infraestructura bien diseñada es que permite añadir nodos, ampliar almacenamiento y ajustar recursos sin reconstruir toda la plataforma. Es justo lo que persiguen los clústeres con almacenamiento local bien planteados a escala media o grande.
Una plataforma Proxmox bien diseñada necesita operación. Monitorización de nodos, almacenamiento, red, backups, latencia, capacidad, errores SMART, uso de CPU, memoria, I/O wait, estado de HA y tareas programadas. Y alertas útiles, no ruido. Si todo alerta, nada alerta.
La operación incluye también procedimientos: cómo se actualiza un nodo, cómo se evacúan las VMs antes de un mantenimiento, cómo se prueba HA, cómo se revisan los backups, cómo se documentan los cambios, cómo se gestionan los accesos y cómo responde el equipo ante una degradación del almacenamiento.
Proxmox tiene una ventaja importante: es transparente. Permite inspeccionar muchas capas del sistema, trabaja con herramientas Linux conocidas y se puede automatizar mediante API y CLI. Pero esa transparencia requiere conocimiento. No elimina la necesidad de administración: la hace más visible. Por eso muchas empresas prefieren delegar esa capa en un servicio gestionado y centrarse en sus aplicaciones.
Para muchas empresas, el valor de Proxmox no está solo en el ahorro de licencias. Está en la posibilidad de construir un cloud privado abierto, flexible y controlado. Esa arquitectura puede apoyarse en nodos dedicados, redes privadas, almacenamiento en red, almacenamiento síncrono, backup, monitorización, soporte y opciones multi-datacenter.
Este enfoque ayuda a separar responsabilidades. La base física, la conectividad, el entorno de centro de datos, el hardware, la red, el almacenamiento y el soporte de infraestructura quedan cubiertos por el proveedor. El cliente puede centrarse en sistemas, aplicaciones, seguridad, datos y evolución de la plataforma.
| Necesidad de negocio | Enfoque con Proxmox gestionado |
|---|---|
| Control de la infraestructura | Nodos dedicados y entorno de uso exclusivo |
| Menor dependencia propietaria | Plataforma open source Proxmox VE |
| Continuidad | HA, almacenamiento en red, backup y opciones multi-DC |
| Crecimiento | Ampliación de nodos y almacenamiento bajo demanda |
| Migración desde VMware | Diseño del entorno destino, piloto y transición por fases |
| Recuperación | Proxmox Backup Server, archivo y pruebas de restauración |
| Operación | Monitorización, soporte y procedimientos técnicos |
La idea no es presentar Proxmox como una solución mágica. No lo es. Proxmox funciona muy bien cuando se diseña con disciplina. También puede dar problemas si se despliega como una instalación rápida sin arquitectura. Lo mismo ocurre con cualquier plataforma de virtualización en producción.
La diferencia está en reconocerlo desde el principio: Proxmox no es virtualización barata. Es infraestructura crítica cuando sostiene cargas críticas.
| Área | Recomendación rápida |
|---|---|
| Clúster | Diseña con al menos tres nodos cuando necesites HA fiable |
| Quórum | Prueba la pérdida de nodos y el comportamiento del clúster antes de producción |
| Red | Separa gestión, migración, almacenamiento, backup y tráfico de cliente |
| Almacenamiento | Elige según la carga: red, Ceph, ZFS, síncrono o una combinación |
| HA | Úsalo para el reinicio automático, no como sustituto de la HA de aplicación |
| Backup | Usa PBS, retención, verificación y restauraciones probadas |
| Capacidad | Alerta antes del límite, no cuando el pool ya está lleno |
| Dimensionamiento | Mide el consumo real y reserva margen ante fallos |
| Operación | Documenta cambios, actualiza por fases y monitoriza todo |
¿Es Proxmox una alternativa real a VMware para cloud privado? Sí, siempre que se diseñe como plataforma de producción. Proxmox VE puede ser una base sólida para cloud privado cuando se combina con clustering, almacenamiento adecuado, red segmentada, alta disponibilidad, backup y operación profesional. Lo comparamos en detalle en Proxmox vs VMware.
¿Hace falta almacenamiento compartido para usar HA en Proxmox? En muchos escenarios de HA, las VMs deben poder arrancar en otros nodos con acceso a sus discos, ya sea mediante almacenamiento compartido, almacenamiento distribuido o una replicación bien diseñada. La arquitectura exacta depende del caso de uso.
¿Es Ceph obligatorio en Proxmox? No. Ceph es una opción potente, especialmente para almacenamiento distribuido, pero no es obligatorio. Proxmox también puede trabajar con almacenamiento local, ZFS, NFS, iSCSI, Fibre Channel, almacenamiento en red o cabinas externas.
¿Los snapshots de Proxmox sirven como backup? No. Los snapshots son útiles para ventanas cortas de mantenimiento, pero no sustituyen una estrategia de backup. Para copias reales conviene usar Proxmox Backup Server u otra solución, con retención, verificación y pruebas de restauración.
¿Cómo se migra desde VMware a Proxmox? Con un diseño del entorno destino, un piloto y una transición por fases. Lo detallamos paso a paso en la guía de migración de VMware a Proxmox.
¿Estás planteando llevar Proxmox a producción o migrar desde VMware? Diseñamos y operamos cloud privado sobre Proxmox en hardware dedicado, con HA, almacenamiento en red, backup y monitorización incluidos. Hablemos de tu proyecto.
Proxmox VE 9.2 estrena versión oficial para ARM64 (AArch64), la primera fuera de x86-64 en la historia del producto. Misma base de código, mismos repositorios y mismo soporte, con NVIDIA Grace y NVIDIA Vera como plataformas certificadas de salida. Repasamos qué hardware cumple los requisitos, qué funciones se quedan en x86 y qué cambia (poco, de momento) para quien ya tiene un clúster en producción.
Haces backup de la VM cada noche y duermes tranquilo. Hasta que restauras y la base de datos arranca corrupta o pierde las últimas transacciones. Un snapshot de disco no es lo mismo que un backup consistente de una base de datos. Explicamos la diferencia entre backup consistente por caída, por sistema de ficheros y por aplicación, y cómo conseguir el bueno en Proxmox con el agente invitado, hooks y volcados nativos.
Una red IP enrutada abajo, los servicios de cada cliente encapsulados arriba y BGP distribuyendo dónde está cada MAC. Qué resuelve EVPN-VXLAN, cómo encajan underlay y overlay, qué detalles rompen un fabric (la MTU, siempre la MTU) y cuándo no compensa montarlo.