Proxmox VE vs VMware ESXi en 2026: la visión de quien opera servidores dedicados

La respuesta corta

Para un servidor dedicado de un solo inquilino o un clúster pequeño en 2026, Proxmox VE es la opción por defecto, y VMware ESXi solo se justifica si ya pagas la pila vSphere completa (y la usas). Es una afirmación más tajante de lo que se atreven la mayoría de comparativas, así que el resto del artículo la justifica: qué hizo el cambio de licencias de Broadcom, qué puede y qué no puede hacer el ESXi gratuito que ha vuelto, las diferencias de arquitectura que importan en bare metal, los fallos multinodo que duelen en producción y un cálculo de coste por nodo sin maquillaje.

Por qué fiarte de esta comparativa y no de cualquier otra: casi todo el contenido Proxmox vs ESXi está escrito para homelabs (pensando en un mini-PC) o por fabricantes de copias de seguridad (listas de funciones que terminan en «y aquí está nuestro producto»). Quien opera servidores dedicados tiene otras restricciones (la recuperación es solo por IPMI, el hardware es de un solo inquilino, no hay SAN y la red se configura en el host), y esas restricciones cambian la respuesta.

Qué ha cambiado: Broadcom y el ESXi que volvió

Dos cambios han reiniciado esta comparación, y necesitas tener presentes los dos.

El cambio de licencias. Desde que Broadcom compró VMware, las licencias perpetuas han desaparecido y todo es por suscripción, licenciado por núcleo físico, con un mínimo de 16 núcleos por CPU que se factura incluso en procesadores con menos núcleos. Las antiguas referencias a la carta se fundieron en dos paquetes: VMware vSphere Foundation (VVF) para el mid-market y el más amplio VMware Cloud Foundation (VCF) para una nube privada completa (VCF añade NSX, SDDC Manager y 4× la capacidad de vSAN incluida). En 2025 hubo además un muy comentado mínimo de 72 núcleos por pedido; su situación actual es confusa (algunos canales dicen que se retiró tras las críticas y otros siguen citándolo), así que tómalo como algo que preguntar a tu revendedor, no como una regla fija. Para un operador pequeño con CPU modernas de muchos núcleos, el efecto neto es que el modelo por núcleo más el suelo de la suscripción dispara el coste anual muy por encima de lo que antes costaba licenciar el mismo hardware.

El ESXi gratuito ha vuelto, pero lee los límites. Broadcom reintrodujo un ESXi gratuito con la versión 8.0 Update 3e en abril de 2025. Eso reabrió la pregunta de «¿vuelvo sin más al ESXi gratuito?», así que aquí van los límites documentados, sacados directamente de la KB de Broadcom:

• 8 vCPU por máquina virtual. No 8 en total, 8 por VM. Una sola VM de base de datos con 16 vCPU queda descartada.
• Hasta 2 CPU físicas (sockets) por host. Es un límite de sockets, no de VM.
• Las API de gestión son de solo lectura. Es el límite que más pesa: las herramientas de copia de seguridad de terceros (Veeam y compañía) dependen de API con escritura (VADP), así que no puedes hacer copias de seguridad de las VM de un ESXi gratuito con ellas. Tampoco hay vMotion, DRS ni HA.
• No se puede gestionar desde vCenter, y no tiene soporte ni SLA.

En conjunto, esto convierte al ESXi gratuito en un buen producto para un laboratorio o un host aislado, y en una base inadecuada para un servidor de producción gestionado y con copias de seguridad, sobre todo en una máquina moderna de doble socket con 32 núcleos o más por socket, donde el techo de 8 vCPU por VM y la falta de API de copias de seguridad se notan desde el primer día. A mediados de 2026 la build gratuita sigue siendo la 8.0U3e; vSphere 9 existe, pero no hay un ESXi 9 gratuito. Así que «el ESXi gratuito ha vuelto» es cierto y casi irrelevante para un servidor de producción.

Arquitectura: lo que importa en bare metal

Las tablas de función contra función pasan por alto lo que cambia cuando la máquina entera es tuya. Hay cuatro diferencias.

Modelo de hipervisor: KVM + LXC frente a un Type-1 puro. Proxmox VE ejecuta tanto máquinas virtuales KVM completas como contenedores de sistema LXC desde una sola interfaz; ESXi es un hipervisor Type-1 puro que solo ejecuta VM. En una única máquina densa esa diferencia se traduce en dinero: los contenedores LXC comparten el kernel del host, así que caben muchas más cargas solo Linux en el mismo hardware que como VM completas, y sigues pudiendo usar VM para lo que necesita su propio kernel o un límite de aislamiento estricto.

Almacenamiento: definido por software frente a la pila de VMware. Proxmox trae de serie ZFS (local, con snapshots, checksums y replicación), Ceph RBD (distribuido, hiperconvergente) y LVM-thin, además de directorio/NFS/iSCSI. VMware ofrece VMFS sobre almacenamiento en bloque y vSAN, y en los paquetes actuales la capacidad de vSAN se mide por núcleo dentro de la licencia. En un servidor dedicado con NVMe local y sin SAN, lo natural es ZFS en un solo nodo o Ceph repartido en unos pocos, y está incluido en lugar de licenciarse por terabyte.

Red: Linux en el host. La red de Proxmox usa por defecto bridges de Linux, con Open vSwitch y un framework SDN disponibles; la configuras en /etc/network/interfaces como en cualquier máquina Linux, que es justo lo que ya hace quien opera servidores dedicados. VMware usa vSwitches estándar o distribuidos, con NSX solo en el paquete VCF. Cuando tu vía de recuperación es una consola IPMI, que «sea red Linux normal» es una ventaja tangible.

API y automatización. Proxmox incluye una API REST completa en cada instalación (HTTPS en el 8006, pvesh, tokens de API), gratis. La superficie de automatización de vSphere está detrás de vCenter y de una licencia de pago y, lo que es decisivo, la API del ESXi gratuito es de solo lectura, así que la versión gratuita no tiene ninguna API de automatización ni de copias de seguridad utilizable. Si gestionas la infraestructura con Terraform o Ansible, Proxmox se automatiza desde el primer día sin coste.

La realidad operativa (lo que ninguna tabla de funciones cubre)

Aquí es donde la experiencia de quien opera en producción se separa de la reseña de un homelab. Proxmox es excelente, pero tiene aristas que solo aparecen a escala multinodo y bajo presión de memoria. Conocerlas de antemano marca la diferencia entre una infraestructura aburrida y una mala noche. Estas son las que más muerden, con su solución.

El ARC de ZFS se come en silencio la RAM de los invitados

El incidente clásico de Proxmox sobre ZFS: las VM empiezan a hacer swap o el OOM killer las mata en un host que «tiene RAM de sobra», porque la caché en memoria de ZFS (el ARC) ha crecido hasta llenarla. ZFS considera la RAM libre como terreno para la caché y, cuando hay contención, el ARC y las asignaciones de los invitados se pelean.

No es hipotético: los foros de Proxmox están llenos de casos. En un hilo representativo, un host de 64 GB con Proxmox 8.1.4 tenía el ARC cerca de los 32 GB; como lo resumió un habitual del foro, «ZFS ocupa 32GB, la VM 16.5GB, Proxmox ocupa 2GB, lo que suma un 80 %», y el OOM killer acabó matando la VM de Windows Server de 16 GB, que solo se recuperó con un reinicio por IPMI. En otro, un host de 32 GB tenía el ARC clavado en 15.5 GiB (99.7 %) y el OOM killer mataba una y otra vez un invitado Windows, aunque entre todas sus VM solo pedían ~8 GB. La misma causa en ambos casos: el ARC con el antiguo valor por defecto de ZFS, aproximadamente la mitad de la RAM del host.

Las versiones modernas de Proxmox lo mitigan: desde PVE 8.1 el instalador limita el ARC al 10 % de la RAM del host, con un máximo de 16 GiB, mientras que antes de la 8.1 se usaba el valor por defecto de ZFS, el 50 % (62.5 % en ZFS 2.3.0+). Pero los hosts instalados con versiones antiguas, actualizados in situ o montados a mano pueden seguir con ese valor antiguo. La solución es explícita: define zfs_arc_max (en bytes) en /etc/modprobe.d/zfs.conf y regenera el initramfs. Para limitar el ARC a 8 GiB:

# 8 GiB in bytes
echo "options zfs zfs_arc_max=8589934592" > /etc/modprobe.d/zfs.conf
update-initramfs -u -k all
reboot

Una trampa documentada: si el zfs_arc_max que eliges es igual o menor que zfs_arc_min, baja también zfs_arc_min o el cambio no se aplicará. La regla práctica documentada es de unos 2 GiB de base más ~1 GiB de ARC por TiB de pool, dejando el resto para los invitados, y la verdadera lección es comprobar arc_summary en cualquier host que heredes en lugar de suponer que el límite está puesto. En el caso de 64 GB, el operador se quedó con un límite de 24 GiB; en el de 32 GB, un límite de 4 GiB devolvió el host a un uso de memoria estable de ~70 %.

Un clúster de dos nodos necesita un QDevice para el quórum

Un clúster de dos nodos parece HA y no lo es. El clustering de Proxmox usa corosync, que necesita mayoría de votos para mantener el quórum; con dos nodos, perder uno deja al superviviente con uno de dos votos (sin mayoría), así que deja de tomar decisiones de clúster para evitar un split-brain. Los equipos lo descubren justo cuando menos pueden permitírselo: un nodo muere y el «clúster» se bloquea.

La solución es un clúster de tres nodos de verdad o un Corosync QDevice, un daemon externo ligero (puede ir en una VM pequeña o incluso en una Raspberry Pi aparte) que aporta un tercer voto de desempate. Decídelo antes de que el segundo nodo entre en producción, no después.

Ceph con muy pocos nodos o poca red

Ceph es magnífico y no perdona quedarse corto. La propia guía de Proxmox pide al menos 3 nodos (5 recomendados para producción) y una red dedicada de 10 Gbps como mínimo, 25 Gbps o más en cuanto usas NVMe. Si ejecutas Ceph en dos nodos, o sobre un enlace compartido de 1 Gbps, obtienes la decepción que cabe esperar: bloqueos durante la recuperación, picos de latencia y una reconstrucción que satura el mismo enlace que intentan usar tus VM. Si no tienes los nodos ni la red para Ceph, usa ZFS con replicación. Es la herramienta adecuada para dos o tres nodos.

Migración en caliente: expectativas realistas

La migración en caliente funciona bien en Proxmox, pero se suelen confundir dos cifras: el tiempo de corte (la breve pausa mientras se traspasan la última memoria modificada y el estado de la CPU) y el tiempo total de migración (lo que tarda toda la transferencia). Se comportan de forma distinta, y los foros de Proxmox están llenos de registros de tareas reales que lo muestran. Proxmox apunta a un tiempo de corte máximo por defecto de 100 ms, que sube automáticamente (200 ms, 400 ms, …) solo si el invitado ensucia la RAM más rápido de lo que el enlace puede vaciarla. Con almacenamiento compartido o rápido, el corte medido se queda entre decenas y pocos cientos de milisegundos casi sin importar el tamaño de la VM. Estos son valores reales que los operadores han pegado de sus propias migraciones:

De esos registros salen dos lecciones para el operador. Primero, el tiempo de corte es prácticamente independiente del tamaño de la RAM y de la velocidad del enlace en una migración que se comporta bien: lo que escala con RAM ÷ rendimiento es el tiempo total. Segundo, lo que más destroza el tiempo total no es la red, sino el túnel cifrado SSH: está limitado a un solo núcleo y suele dejar el rendimiento muy por debajo de la tarjeta de red. En un caso con una VM de 32 GB sobre un enlace Ceph de 40 Gbps, la migración segura por defecto tardó más de 20 minutos; cambiar a migration: insecure en la red de clúster de confianza la dejó en 30 segundos. Y sé preciso con la palabra «corte»: el valor registrado es la pausa stop/copy de QEMU, y el corte cero de verdad no existe; un corte de menos de un segundo con almacenamiento compartido es el objetivo realista, no cero. Nada de esto es un defecto de Proxmox; es el tipo de cosa que una reseña de homelab nunca saca a la luz y que quien opera una flota tiene en cuenta al planificar.

Coste: por nodo, no por puesto

Los enfoques de homelab y por puesto ocultan lo que le importa al operador: la factura recurrente por nodo físico. Los dos modelos tienen formas opuestas, y esa forma es lo que cuenta.

Proxmox es gratuito en producción bajo AGPLv3; la suscripción es opcional y se cobra por socket de CPU y año, solo por el repositorio enterprise estable y el soporte. Según la página de precios de Proxmox (julio de 2026, sin IVA, en EUR): Community 120 €, Basic 370 €, Standard 550 €, Premium 1100 €, por socket y año. En un nodo de doble socket eso va de 0 € (repositorio no-subscription) a 2200 €/año en el nivel más alto.

VMware es una suscripción por núcleo físico con el mínimo de 16 núcleos por CPU. Broadcom no publica una lista de precios pública, así que cada cifra es una estimación de terceros con fecha, pero el modelo basta para entenderlo. Un nodo de doble socket con 32 núcleos por socket son 64 núcleos licenciables, facturados cada año. La cifra mejor documentada es la de VCF: un VP de Broadcom describió una rebaja «de 700 $ por núcleo y año a 350 $» en el relanzamiento de junio de 2024, aunque esa «rebaja» es engañosa, ya que el VCF de 350 $ incluye ahora NSX, vSAN y Aria y es obligatorio para muchos clientes, así que para la mayoría el efecto neto fue una subida, no un ahorro. Para el paquete VVF de mid-market, los cálculos de revendedores de 2026 sitúan el rango de mercado entre 150 $ y 190 $ por núcleo y año, frente a la media de ~135 $ que aún se cita desde el relanzamiento.

Confírmalo con un presupuesto de revendedor: las cifras de abajo son estimaciones de terceros con fecha (julio de 2026), no precios publicados por Broadcom.

Las cifras de VMware son anuales y recurrentes; la columna de Proxmox es una cuota de soporte fija y opcional (o cero con el repositorio no-subscription). En una flota pequeña, la diferencia se acumula cada año.

En cuanto a copias de seguridad: Proxmox Backup Server es gratuito y de código abierto, con copias incrementales en el cliente y deduplicadas en el servidor para VM, contenedores y hosts físicos. Veeam es excelente y ahora admite Proxmox VE como plataforma de primera clase (añadido en Backup & Replication 12.2, en 2024), pero es una suscripción por carga de trabajo que se suma. Si la partida de copias de seguridad te importa, PBS inclina aún más las cuentas a favor de Proxmox.

Resumiendo: para una flota pequeña, el coste por nodo de Proxmox es una cuota de soporte fija y opcional (o cero), mientras que el de VMware es una suscripción obligatoria, recurrente y por núcleo que crece con tu número de núcleos. Con las CPU actuales de muchos núcleos, la diferencia es grande y se acumula cada año.

Cuándo ESXi sigue siendo la opción correcta

La credibilidad exige decir dónde gana el veterano, y en algunos casos gana:

• Ya ejecutas (y usas) la pila vSphere completa. Si DRS, vSAN, NSX y la automatización de vCenter sostienen tu operación y la memoria muscular de tu equipo es vSphere, arrancarlo todo para ahorrar en licencias puede costar más de lo que ahorra.
• Una certificación de proveedor o un appliance exige ESXi. Algunos programas empresariales y appliances virtuales solo están certificados o soportados en vSphere. Si un contrato de soporte depende de ello, eso lo decide.
• Hay un proceso empresarial auditado construido alrededor de vCenter. El control de cambios, el RBAC y las herramientas de cumplimiento conectadas a vCenter suponen un coste de cambio real. Las migraciones deben tenerlo en cuenta.
• Tienes una inversión en vSAN y un modelo operativo a su alrededor que no estás preparado para reconstruir sobre Ceph.

Ninguno de estos casos describe al cliente típico de un servidor dedicado ni a una flota de hosting pequeña, pero si alguno te describe a ti, la madurez de ESXi es real y sigue ahí.

Migrar de ESXi a Proxmox: la versión corta

Desde la versión 8.2, Proxmox VE incluye un asistente de importación para invitados VMware: añades el ESXi (o vCenter) como almacenamiento de origen de importación en Datacenter → Storage → Add → ESXi y luego traes las VM. Habla directamente con la API de ESXi, admite ESXi 6.5–8.0 y ofrece un modo «live import» que arranca la VM pronto y copia el resto en segundo plano. Conviene conocer primero dos salvedades de migraciones reales:

• No es rápido, y vSAN no está soportado. El importador pasa por la API de VMware, que limita la velocidad; usuarios del foro reportan rendimientos de apenas ~30 MB/s a través de vCenter, y algunos se saltan el asistente con las VM grandes y prefieren un Storage vMotion hacia NFS. Las VM que residen en vSAN no se pueden importar con el asistente en absoluto.
• Los invitados Windows necesitan preparación VirtIO o no arrancan. Si importas un disco de arranque de Windows directamente sobre un controlador VirtIO SCSI, da pantallazo azul con INACCESSIBLE_BOOT_DEVICE (código de parada 0x7B), porque Windows no tiene cargado ningún driver de almacenamiento VirtIO. La solución documentada es arrancar primero el invitado en SATA/IDE, instalar los drivers virtio-win y luego pasar el disco de arranque a VirtIO SCSI, o marcar la casilla «Prepare for VirtIO-SCSI» del asistente, y a ser posible instalar los drivers VirtIO mientras la VM sigue en ESXi.

Un paso a paso completo merece su propia guía; lo importante aquí es que la migración es un camino resuelto y documentado (el wiki oficial de migración de Proxmox lo recorre de principio a fin), no una reconstrucción desde cero.

El veredicto, con condiciones

• Elige Proxmox VE si operas un servidor dedicado de un solo inquilino o un clúster pequeño, quieres VM KVM y contenedores LXC en el mismo host, valoras el almacenamiento ZFS/Ceph y una API REST gratuita, y prefieres pagar una cuota de soporte fija y opcional por socket antes que una suscripción obligatoria por núcleo. Es la opción por defecto para el público al que va dirigido este artículo.
• Elige VMware vSphere de pago si ya estás comprometido con DRS/vSAN/NSX/vCenter y los usas activamente, dependes de una certificación concreta de un proveedor de software o tienes un proceso auditado construido alrededor de vCenter, y puedes asumir la suscripción por núcleo.
• Elige el ESXi gratuito solo si quieres un único host de laboratorio, sin gestión ni copias de seguridad, y puedes vivir con 8 vCPU por VM, dos sockets y ninguna API de copias de seguridad. Es un producto de homelab, no de servidor.

Si estás sopesando esta decisión, nuestra guía complementaria sobre qué es un hipervisor bare metal y cómo se comparan las cuatro plataformas principales cubre también XCP-ng y Hyper-V, y nuestra guía paso a paso para configurar Proxmox VE recorre la instalación desde un disco vacío. Si lo que planeas es salir de una nube pública de pago por uso y no de las licencias de VMware, nuestra guía de migración a la nube cubre el lift-and-shift y la modernización de bases de datos.

Preguntas frecuentes

¿Está Proxmox VE listo para producción?

Sí. Es AGPLv3 sin límites de funciones, de VM ni de nodos, lleva años publicando versiones a un ritmo previsible y es el destino más habitual de los equipos que abandonan VMware. La versión actual es Proxmox VE 9.2 (mayo de 2026), basada en Debian 13 «Trixie». Las salvedades son operativas, no de madurez: dimensiona el ARC de ZFS, no montes HA con dos nodos sin un QDevice y dale a Ceph los nodos y la red que necesita.

¿Puede Proxmox sustituir a vCenter?

Para la mayoría de operadores, sí: el plano de gestión de Proxmox (interfaz web más API REST) viene integrado en cada nodo y forma clústeres de forma nativa, así que no hay un appliance de gestión aparte que licenciar como ocurre con vCenter. Lo que no sustituye uno a uno es el conjunto de funciones DRS/NSX/vSAN de un despliegue vSphere completo; si son centrales en tu forma de operar, esa es la carencia que debes sopesar.

¿Va a volver el ESXi gratuito, o ya ha vuelto?

Ya ha vuelto. Broadcom reintrodujo el ESXi gratuito con la build 8.0 Update 3e en abril de 2025. Pero está limitado a 8 vCPU por VM y dos sockets físicos, no se puede gestionar desde vCenter y solo expone una API de solo lectura, así que las herramientas de copia de seguridad de terceros no pueden proteger sus VM. Sirve para un laboratorio, no para un servidor de producción con copias de seguridad. A mediados de 2026 no existe un ESXi 9 gratuito.

¿Cuántos nodos necesita como mínimo un clúster de Proxmox?

Puedes funcionar con un solo nodo indefinidamente. Para una alta disponibilidad fiable necesitas tres nodos, de modo que corosync tenga siempre mayoría de votos. Dos nodos pueden formar clúster, pero no mantienen el quórum cuando uno cae. Si solo tienes dos, añade un QDevice como desempate externo. Ceph en concreto pide tres nodos como mínimo y cinco para producción.

Desplegar Proxmox VE en Serverside.com

Proxmox necesita bare metal, y para eso está esto. Serverside.com despliega Proxmox VE 9.2 como imagen lista para usar sobre hardware de un solo inquilino en menos de un minuto; tienes root completo sobre toda la máquina, así que la elección del repositorio, la disposición del almacenamiento y la configuración del clúster son cosa tuya. El hardware encaja directamente: AMD EPYC de muchos núcleos con DDR5 ECC para hosts densos en VM y contenedores, y una red rápida, que importa para el trabajo intensivo en ancho de banda en el que Proxmox destaca: Ceph y la replicación ZFS entre nodos. La mitigación DDoS siempre activa de nuestra red ASN 55285 protege tanto el plano de gestión como tus invitados.

¿Listo para montar uno? Echa un vistazo a nuestros servidores dedicados Proxmox VE para desplegar la imagen lista para usar, o a toda la gama de servidores dedicados. Como Proxmox se basa en Debian, nuestras páginas de Debian y Ubuntu cubren el sistema operativo de base si prefieres montar el host tú mismo. ¿Empiezas desde cero? Comienza por nuestra guía de configuración de Proxmox VE.