ha = basic, que reparte contando máquinas, y el rebalanceo automático viene desactivado.En casi todas las reuniones a las que llegamos, la conversación sobre si Proxmox «está listo» se hace con una lista de carencias sacada de una comparativa de hace tres años. Una parte de esa lista caducó hace meses. Otra parte sigue exactamente igual de vigente, y encima no suele estar en la lista.
Separar las dos es la mitad del trabajo de decidir, y casi nadie lo hace antes de sentarse a mirar el precio de la renovación.
Conviene además quitarse el marco épico. Tres años después de la compra, el movimiento real de clientes de VMware fue bastante más pequeño que el ruido: la mayoría de empresas ni huyó ni se quedó tan tranquila, renegoció y siguió. Esto no va de bandos. Va de si en tu caso concreto salen los números y los riesgos.
Nosotros trabajamos con las dos plataformas y no vendemos licencias de ninguna, que es justo por lo que podemos escribir esto.
Era cierto. Dejó de serlo el 21 de mayo de 2026, con Proxmox VE 9.2. El planificador de recursos del clúster incorpora un modo dinámico que tiene en cuenta el uso real de CPU y memoria de nodos e invitados en cada decisión de colocación, y el balanceador integrado puede migrar máquinas automáticamente para reducir el desequilibrio entre nodos, respetando las reglas de alta disponibilidad definidas.
Ahora la letra pequeña, que está en la misma frase del anuncio y casi nadie lee entera: el balanceador mueve invitados gestionados por la pila de HA. Las máquinas que tengas simplemente arrancadas en un nodo, sin declarar como recurso de alta disponibilidad, se quedan donde están por muy desequilibrado que esté el clúster. Es coherente y está documentado. Sencillamente no es lo que la gente entiende al leer el titular.
Veeam da soporte a Proxmox VE desde 2024, y la versión 13.1, publicada el 29 de julio de 2026, añade trabajos de replicación nativos para la plataforma: entre anfitriones, entre centros de datos y entre tipos de almacenamiento distintos.
Y otra vez la letra pequeña, esta vez en los problemas conocidos de esa misma versión: un trabajo de replicación puede fallar si la máquina de origen tiene discos cuyo tamaño no es múltiplo del tamaño de bloque del almacenamiento de destino. También hay un detalle con el mapeo de almacenamiento por máquina, que no se aplica a la colocación del dispositivo TPM.
Traducido: funciona, y tiene aristas. Las aristas se planifican antes, no se descubren el fin de semana del corte.
Hay una función de vSphere de la que casi nadie habla en las comparativas y que echamos de menos de verdad: el admission control.
La documentación de Broadcom lo explica sin ambigüedad. Con la política de slots, vSphere calcula un tamaño de slot —una representación lógica de CPU y memoria—, deduce cuántas máquinas caben si fallan los anfitriones que hayas configurado, y compara la capacidad de conmutación disponible con la configurada. Si la disponible es menor, impide la operación. No avisa: la impide. vSphere te prohíbe arrancar la máquina que rompería tu propia N-1.
La documentación de alta disponibilidad de Proxmox VE no describe ningún mecanismo equivalente. Hay reglas de afinidad de nodo y de recurso, hay prioridades, hay fencing con watchdog. No hay nada que reserve capacidad ni que te frene cuando te la comes. De hecho, la propia documentación te pasa la pelota con todas las letras: al explicar qué pasa cuando cae un nodo, dice que el gestor reparte los servicios entre los que quedan y recomienda diseñar el clúster para soportar ese peor caso.
Es una instrucción para ti, no una función del producto.
Puedes llenar el clúster hasta el borde y todo funcionará perfectamente hasta el día en que se caiga un nodo y descubras que lo que había dentro no cabe en los que quedan. Ese día no es una caída: es un fallo convertido en avería por una decisión de diseño que nadie tomó. Como ya contamos al hablar de alta disponibilidad en Proxmox, la HA no evita la caída, la acorta; y sin capacidad libre reservada, ni siquiera la acorta.
La cuenta es de primaria y aun así casi nunca está hecha:
| Nodos del clúster | Uso máximo por nodo para sobrevivir a una caída | Margen que pierdes |
|---|---|---|
| 3 | 66 % | Un tercio del clúster, parado |
| 4 | 75 % | Un cuarto |
| 5 | 80 % | Un quinto |
| 6 | 83 % | Un sexto |
| 8 | 87 % | Un octavo |
Cuanto más pequeño es el clúster, más caro sale el seguro. Un clúster de tres nodos que pase del 66 % de memoria asignada por nodo ya no es N-1, aunque en el panel se vea todo verde. Y si quieres aguantar dos caídas simultáneas —o una caída durante una ventana de mantenimiento, que es el caso realista—, la fórmula pasa a (N-2)/N y en tres nodos te quedas en el 33 %.
Esto se resuelve, claro. Con una hoja de cálculo, una revisión trimestral y una regla escrita de cuánta RAM se deja libre por nodo. Pero pasa de ser una barrera de la plataforma a ser una disciplina de la casa, y las disciplinas de la casa se relajan en agosto.
La diferencia relevante entre las dos plataformas no es una lista de funciones. Es que vSphere llegaba con muchas decisiones ya tomadas —por el fabricante, por el integrador, por quien lo montó hace ocho años— y Proxmox espera que las tomes tú. Cuando nadie las toma, quedan tomadas igual: en el valor por defecto.
Y los valores por defecto están publicados, a la vista de cualquiera, en la página de manual de datacenter.cfg:
Opción del bloque crs | Por defecto | Qué significa |
|---|---|---|
ha | basic | Solo se cuenta el número de servicios. Ni CPU ni memoria |
ha-auto-rebalance | 0 | El balanceo automático está desactivado |
ha-rebalance-on-start | 0 | Al arrancar un servicio parado no se busca el mejor nodo |
ha-auto-rebalance-threshold | 30 | Desequilibrio, en %, que dispara el balanceo si se activa |
ha-auto-rebalance-hold-duration | 3 | Rondas que debe mantenerse el desequilibrio antes de mover |
ha-auto-rebalance-margin | 10 | Mejora mínima, en %, para que merezca la pena migrar |
ha-auto-rebalance-method | bruteforce | Método de puntuación (bruteforce o topsis) |
Lee la primera fila otra vez. De fábrica, el planificador reparte contando máquinas: la base de datos que se come el nodo entero y la maquinita del servidor de licencias valen exactamente lo mismo. Para eso están los modos static —que mira la configuración de CPU y memoria— y dynamic —que mira además el uso real—, pero hay que ponerlos.
Nada de esto es un defecto. Son valores conservadores, y para un clúster recién montado son los correctos: un balanceador que empieza a mover máquinas solo el primer día es peor que uno quieto. El problema no es el valor, es la creencia. Si alguien vendió la migración diciendo «ya tiene DRS» y nadie tocó el fichero, el clúster está repartiendo por número de máquinas y no se sabrá hasta que un nodo vaya ahogado con el de al lado medio vacío.
Ninguno es un problema de Proxmox. Uno es del calendario, dos son de tus proveedores y el resto son de casa.
Es el caso más frecuente y el más caro. Llega la oferta de renovación, el número escuece, quedan seis semanas y alguien decide que se migra antes de que expire.
Migrar con la fecha impuesta desde fuera significa renunciar a lo único que hace segura una migración: poder pararla. Nosotros trabajamos con vuelta atrás preparada y con una ventana en la que el origen sigue encendido y arrancable, y esa ventana caduca sola, por contrato y por datos. Si la renovación se come la ventana, la recomendación honesta es renovar el periodo más corto que te dejen y migrar sin cuchillo en el cuello. Sale más barato pagar unos meses de más que hacer un corte a ciegas.
El ERP, el sistema de gestión sectorial, el software del laboratorio, la aplicación que valida las facturas. Muchos fabricantes publican una lista de hipervisores sobre los que dan soporte, y esa lista no se negocia por foro ni por benchmark: se pregunta por escrito, con el número de contrato delante, y se guarda la respuesta.
Si tu proveedor crítico contesta que fuera de su lista atiende en modo best effort, eso es una decisión de riesgo que corresponde a dirección, no a sistemas. Y no la arregla que Proxmox rinda igual o mejor, porque el problema no era técnico.
Súmale a cada nodo la memoria realmente asignada a las máquinas encendidas —la de hoy, no la del último inventario—, quita el nodo más cargado y comprueba si eso cabe en los que quedan dejando margen para el propio sistema.
En vSphere no hacía falta hacerla porque la hacía el admission control. En Proxmox la haces tú o no se hace. Cuando sale que no cabe hay tres salidas honestas: comprar un nodo más, apagar algo, o escribir en el plan que ante la caída de ese nodo concreto hay servicios que no arrancan, y decir cuáles. Las tres valen. Fingir que la pregunta no existe, no. Migrar un clúster sobreaprovisionado a una plataforma que no te va a frenar es quitar el airbag y comprar un coche más nuevo.
Una sola sala. Copias que nunca se han restaurado de verdad. Un tiempo objetivo de recuperación que nadie ha cronometrado.
Cambiar de hipervisor no arregla nada de eso, y se come el presupuesto y las horas de la persona que podría estar arreglándolo. Si tu exposición real está ahí, el orden correcto es primero poner número al RTO y al RPO y probar una restauración con cronómetro, y después hablamos de plataforma. Es peor consejo comercial y mejor consejo a secas.
Proxmox VE es Debian por debajo, y eso es una ventaja enorme el día que hay que mirar un log y una desventaja el día que nadie sabe cuál mirar.
Y no perdona el olvido del ciclo de vida. Un dato que viene al pelo: Proxmox VE 8 llega a su fin de soporte este mes de agosto de 2026, y el gestor de paquetes no te va a avisar solo. Si en la empresa no hay nadie que vaya a leer eso, ni contratado quien lo haga, la migración se convierte en una plataforma nueva sin dueño. Eso es peor punto de partida que un vSphere caro pero cuidado.
Este caso no estaba en las comparativas de hace tres años y hoy es de los más frecuentes. Si tu instalación se apoya en NSX para la microsegmentación, en vSAN como almacenamiento, en SRM para el plan de recuperación, en Horizon para los escritorios o en herramientas de terceros que hablan con la API de vCenter, no estás migrando un hipervisor: estás sustituyendo cinco productos a la vez.
Proxmox tiene respuestas para casi todo eso —SDN con EVPN, Ceph, replicación, la API propia—, pero son respuestas distintas, con otros nombres y otra operativa. Migrar el hipervisor y esas cinco piezas en el mismo proyecto multiplica el riesgo. Lo sensato es ordenarlas: primero desacoplar lo que se pueda, y el hipervisor al final.
Si los servidores están al final de su vida útil o el contrato de soporte del fabricante vence en unos meses, migrar ahora es hacer el trabajo dos veces: una para llevarlo a Proxmox sobre el hierro viejo y otra para moverlo al nuevo.
Y hay un matiz que se paga caro cuando se ignora: la lista de hardware compatible no es la misma. Controladoras RAID que en vSphere iban con su driver del fabricante, tarjetas de red con firmware específico o cabinas certificadas para una versión concreta de ESXi pueden comportarse distinto en Debian. Si la renovación de hardware ya está en el plan, esa es la ventana natural para cambiar de plataforma: se monta el clúster nuevo al lado y se migra encima, que además es la forma más segura de hacerlo.
Si estás en mitad del proceso de un ENS, una ISO 27001 o una adecuación a NIS2, cambiar la plataforma de virtualización en ese momento significa rehacer el alcance, los diagramas, los procedimientos y las evidencias, y explicárselo al auditor con la plataforma a medio migrar.
No es imposible: es caro y es innecesario. Se hace después del certificado, con el cambio documentado como lo que es, un cambio mayor planificado. Y de paso la migración se convierte en la excusa perfecta para actualizar unos procedimientos que probablemente describan un sistema que ya no existe.
Dicho todo lo anterior, hay muchas empresas para las que la respuesta es que sí, y suele ser bastante clara. Empecemos por donde empieza la conversación de verdad.
Lo que ha cambiado con Broadcom no es solo que el número sea mayor. Es la forma del coste: desaparecieron las licencias perpetuas, todo pasó a suscripción, la unidad de cobro es el core y hay mínimos por CPU física, así que un servidor con procesadores modestos paga por cores que no tiene ocupados. Ahí es donde muchas renovaciones se multiplican sin que la infraestructura haya crecido ni un vatio.
Proxmox cobra de otra manera, y esa diferencia es la que hay que llevar a la reunión:
| VMware (VVF / VCF) | Proxmox VE | |
|---|---|---|
| Modelo | Suscripción obligatoria | Suscripción opcional: el software funciona sin ella |
| Unidad | Por core, con mínimo por CPU | Por socket ocupado |
| Perpetua | Ya no existe | No aplica |
| Precio de lista | Depende del contrato y de la negociación | 120 / 370 / 550 / 1.100 € por socket y año |
| Requisito de clúster | Según edición | Mismo nivel en todos los nodos |
| Qué se paga | El derecho a usar el software | Repositorio empresarial y soporte |
Los cuatro niveles de Proxmox son Community, Basic, Standard y Premium, y se diferencian en el soporte: Community da acceso al repositorio empresarial pero sin soporte del fabricante; Basic incluye tres incidencias al año con respuesta en un día laborable; Standard, diez incidencias con respuesta en cuatro horas; Premium, incidencias ilimitadas con respuesta en dos horas.
Para hacerse una idea: un clúster de tres nodos con dos sockets cada uno son seis suscripciones. En Standard, 3.300 € al año, con soporte del fabricante incluido y sin límite de cores, de RAM ni de máquinas. Pon al lado tu factura de renovación —tu número real, el del contrato, no un precio de lista— y la conversación se termina sola en la mayoría de los casos.
Dos avisos para que la comparación sea honesta, que es de lo que va este blog:
Uno. El ahorro en licencias no es el ahorro del proyecto. Hay horas de migración, formación, pruebas y un periodo de convivencia con las dos plataformas encendidas. Esa cuenta entera, con el punto en el que se cruzan las dos curvas, la hicimos en el coste real de migrar de VMware a Proxmox, y es la que hay que llevar a dirección.
Dos. Que la suscripción sea opcional no significa que sea opcional en producción. El repositorio sin suscripción existe y funciona, pero para una plataforma que sostiene el negocio, pagar el nivel que corresponda es parte del coste, no un extra. Presupuestar Proxmox a cero euros es la forma más rápida de que la comparación se vuelva en tu contra dentro de un año.
Cuando la cuenta a tres años sale con las horas de proyecto dentro y no solo con el precio de las licencias. Cuando hay una ventana en la que se puede parar sin drama. Cuando el software crítico está confirmado por escrito. Cuando alguien —de casa o de fuera— se queda con la plataforma después de la foto de fin de proyecto. Y cuando se hace por capas: un grupo de máquinas poco críticas primero, semanas de convivencia entre las dos plataformas y el origen encendido hasta que ya nadie se acuerde de él. El procedimiento completo lo tenemos escrito en la guía de migración de VMware a Proxmox.
| Señales de «todavía no» | Señales de «adelante» |
|---|---|
| La fecha la marca la renovación | Hay margen para parar y volver atrás |
| El ERP no confirma soporte por escrito | Los fabricantes críticos responden que sí |
| Nadie ha calculado la N-1 | La capacidad está calculada y sobra margen |
| Las copias no se han restaurado nunca | El RTO está cronometrado y las copias se prueban |
| Sin equipo ni contrato de mantenimiento | Hay dueño de la plataforma después del proyecto |
| Dependencia dura de NSX, vSAN, SRM o Horizon | El hipervisor es lo único que hay que cambiar |
| El hardware se renueva en unos meses | La renovación de hardware es justo la ventana |
| Auditoría o certificación en curso | El certificado ya está o toca renovarlo después |
Si tienes tres o más marcas en la izquierda, el proyecto no es migrar: es quitar esas marcas primero.
La pregunta no es si Proxmox está listo. En 2026, para la mayoría de las cargas que nos encontramos, lo está: el planificador dinámico llegó en mayo, la replicación de Veeam en julio, y lo que queda por resolver está documentado y se puede planificar.
La pregunta es si tu casa está lista, y eso se responde con cuatro cosas: la cuenta a tres años con las horas dentro, la capacidad calculada para cuando falte un nodo, el compromiso por escrito de los fabricantes que sostienen tu facturación y una persona con nombre que se quede con la plataforma cuando acabe el proyecto.
Cuando esas cuatro están, migrar suele ser una decisión excelente y el ahorro es real. Cuando falta alguna, lo barato sale caro con una precisión matemática.
Si estás en mitad de esa decisión y quieres que alguien mire tus números y tu inventario sin venderte licencias de nada, cuéntanos qué tienes. A veces la respuesta es que migres, a veces que esperes seis meses, y alguna vez que el problema está en otro sitio. Puedes comparar las dos plataformas con calma en nuestra comparativa.
Desde Proxmox VE 9.2, del 21 de mayo de 2026, el planificador de recursos del clúster funciona en modo dinámico y el balanceador integrado puede migrar máquinas automáticamente para reducir el desequilibrio. Con dos matices: solo mueve invitados gestionados por la pila de HA, y el rebalanceo automático viene desactivado de fábrica.
Sí. Veeam da soporte a Proxmox VE desde 2024 y en la versión 13.1, de julio de 2026, añadió trabajos de replicación nativos. Conviene leer los problemas conocidos de esa versión, en especial el de los discos cuyo tamaño no es múltiplo del bloque del almacenamiento de destino.
Lo más relevante en el día a día es el control de admisión: vSphere impide arrancar una máquina si eso rompe la capacidad de conmutación configurada, y Proxmox no tiene un mecanismo equivalente. La consecuencia es que la reserva de capacidad para sobrevivir a la caída de un nodo pasa a ser una disciplina del equipo.
El software es libre y funciona sin suscripción. Las suscripciones se pagan por socket ocupado y por año, con cuatro niveles publicados —Community, Basic, Standard y Premium, de 120 a 1.100 euros—, y todos los nodos de un clúster deben tener el mismo nivel. Para producción, presupuestar el nivel que corresponda es parte del coste del proyecto.
Como mínimo, la de un nodo entero: con N nodos, el uso sostenible por nodo es (N-1)/N, es decir, un 66 % en un clúster de tres y un 75 % en uno de cuatro. Si quieres aguantar una caída durante una ventana de mantenimiento, la cuenta se hace con (N-2)/N.
Normalmente no. Migrar con la fecha impuesta desde fuera obliga a renunciar a la vuelta atrás, que es lo que hace segura una migración. Suele salir más barato renovar el periodo más corto posible y migrar con margen que hacer un corte a ciegas.
datacenter.cfg(5) — opciones del bloque crs y sus valores por defecto.La lectura sobre la ausencia de un mecanismo de reserva de capacidad en Proxmox es nuestra: su documentación describe reglas de afinidad, prioridades y fencing, y no describe nada equivalente al control de admisión. Los ocho casos, el orden en que los ponemos y la opinión sobre los valores por defecto también son nuestros, no de las fuentes.
No solo se migra desde VMware. Muchas organizaciones quieren salir de Hyper-V —por coste de Windows, por consolidar en una plataforma abierta o por soberanía— y el camino tiene sus particularidades. Explicamos las diferencias entre Hyper-V y Proxmox, cómo se convierten los discos VHDX, por qué los drivers VirtIO son imprescindibles y qué comprobar en las VMs Windows y Linux antes y después del salto.
Una VM Windows puede arrancar bien tras migrar de VMware a Proxmox VE y aun así conservar una instalación dañada de VMware Tools que no se deja desinstalar. Explicamos el procedimiento seguro —primero desinstalación normal, luego limpieza forzada opcional— e incluimos un script de PowerShell prudente, con registro, simulación con -WhatIf y copia de claves del Registro.
Tras el giro de licencias de Broadcom, miles de empresas buscan salida. Cómo planificar la migración, qué herramientas de P2V/V2V usar y los errores que arruinan un proyecto.