Servidores dedicados Proxmox VE

Un servidor dedicado Proxmox es una máquina física de un solo inquilino que ejecuta Proxmox VE —la plataforma de virtualización de código abierto basada en Debian— directamente sobre el hardware. En lugar de alquilar una porción del hipervisor de otra persona, obtienes la máquina entera: una interfaz web y una API REST para levantar máquinas virtuales KVM y contenedores LXC, root completo sobre el host, y cada núcleo y cada gigabyte de RAM ECC para asignarlos como estimes oportuno.

La razón más poderosa para ejecutarlo aquí es la economía y la propiedad. Proxmox VE se publica bajo la GNU AGPLv3 y es gratuito para ejecutar en producción, sin licencia de hipervisor por socket ni por núcleo: una suscripción de pago compra el canal de actualizaciones enterprise y el soporte, no las funcionalidades. Despliégalo como imagen lista sobre hardware EPYC con ECC en menos de un minuto, y todo el host de virtualización es tuyo: sin factura por núcleo al estilo VMware, y sin un hipervisor compartido entre tú y el metal.

¿Nuevo en hipervisores? Lee nuestra guía de hipervisores bare metal.

Qué es realmente Proxmox VE

Proxmox VE es una plataforma de virtualización completa, no solo otra distribución de Linux. Superpone una pila de gestión sobre Debian —la versión actual, Proxmox VE 9.2, está construida sobre Debian 13 «Trixie»— y te ofrece dos tecnologías de virtualización bajo un mismo techo: el hipervisor KVM para máquinas virtuales completas y LXC para contenedores de sistema. Gobiernas ambas desde una única interfaz web en el puerto 8006, o desde una API REST y las herramientas de línea de comandos pvesh / qm / pct si prefieres automatizar.

Como toda la plataforma es de código abierto, todo está en el host y nada se retiene tras un nivel de licencia. Clustering integrado, migración en vivo, almacenamiento definido por software con ZFS y Ceph, un firewall integrado y un framework de copias de seguridad vienen todos en la descarga gratuita. En una máquina de Serverside tienes root completo sobre ese host, así que la versión que ejecutas, los repositorios que habilitas y la cadencia de actualización son enteramente decisión tuya: el appliance es tuyo para operarlo, no una porción gestionada a la que alquilas el acceso.

Repositorios con suscripción y sin suscripción

Esta es la parte que hace tropezar a los operadores de Proxmox primerizos, y conviene tenerla clara. Proxmox VE viene con el repositorio APT Enterprise habilitado, que requiere una clave de suscripción de pago para descargar de él. Sin clave, las actualizaciones de apt fallan contra ese repositorio, así que lo primero que hace la mayoría en una máquina recién instalada es cambiar al repositorio gratuito sin suscripción. En Proxmox VE 9 ambos se definen en el moderno formato deb822 .sources bajo /etc/apt/sources.list.d/, y deshabilitas el que no estás usando en lugar de borrarlo.

Los dos repositorios difieren en pruebas y soporte, no en funcionalidades. La propia recomendación de Proxmox es que el repositorio sin suscripción «puede usarse para pruebas y uso no productivo» y «no se recomienda en servidores de producción», porque sus paquetes no están validados tan a fondo como el canal enterprise. Una suscripción se factura por socket de CPU ocupado y por año —un socket cuenta una sola vez independientemente del número de núcleos— y desbloquea el repositorio enterprise estable más tickets de soporte con un SLA. No desbloquea ninguna funcionalidad: cada capacidad ya está en la descarga gratuita.

Elijas el repositorio que elijas, un host sin una suscripción activa muestra el conocido diálogo «No valid subscription» al iniciar sesión en la interfaz web. Es una molestia, no una limitación: la plataforma es plenamente funcional en cualquiera de los dos casos. Como en una máquina de Serverside tienes root, tú decides si comprar una suscripción para el canal enterprise y el soporte, o ejecutar el repositorio sin suscripción y gestionar tú mismo las actualizaciones.

VMs y contenedores LXC: cuándo usar cada uno

Proxmox te da dos formas de repartir un host, y elegir bien es la mayor parte del oficio. Una máquina virtual KVM es virtualización de hardware completa: arranca su propio kernel, ejecuta cualquier sistema operativo —Windows, los BSD, cualquier Linux— y está fuertemente aislada de sus vecinos y del host. Ese aislamiento y esa independencia del SO son la razón por la que las VMs son la opción correcta para todo aquello en lo que no confías del todo, todo lo que no sea Linux, y todo lo que quieras migrar en vivo entre nodos del clúster sin tiempo de inactividad.

Un contenedor LXC es un contenedor de sistema: comparte el kernel del host y ejecuta un userland de Linux sobre él. Eso lo hace mucho más ligero que una VM: arranca en una fracción de segundo, apenas acarrea sobrecarga de memoria y te permite empaquetar muchas más cargas de trabajo en el mismo hardware. La contrapartida es que debe ser Linux y el aislamiento es más débil que el de una VM completa, ya que cada contenedor se apoya en el único kernel compartido.

En la práctica, la mayoría de los hosts Proxmox ejecutan una mezcla: LXC para el conjunto denso de servicios Linux donde importa la eficiencia —proxies inversos, herramientas internas, apps autoalojadas— y VMs KVM para invitados Windows, cualquier cosa que requiera un kernel distinto, y cargas de trabajo que necesitan un aislamiento firme o migración en vivo. Una máquina de 32 núcleos y 512 GB tiene margen de sobra para ejecutar ambos patrones a la vez.

Almacenamiento: ZFS, Ceph y LVM-thin sobre bare metal

Proxmox VE admite varios backends de almacenamiento, y ejecutarlo sobre bare metal es lo que te permite elegir el adecuado en lugar de heredar el que imponga un host en la nube. En un solo nodo, los dos valores por defecto que te encuentras son local —un almacén de directorio para imágenes ISO, plantillas de contenedor y copias de seguridad— y local-lvm, un pool LVM-thin que aloja los discos de las VMs y los volúmenes raíz de los contenedores. Si en su lugar instalas sobre ZFS, ese almacén de bloques pasa a ser local-zfs.

ZFS es la opción popular en un solo nodo porque aporta snapshots instantáneos, replicación a nivel de bloque entre nodos, integridad de datos con checksums y compresión a tu almacenamiento de VMs. El coste es la RAM: ZFS quiere en torno a 2 GB de memoria base más aproximadamente 1 GB de caché ARC por terabyte de pool. Las instalaciones recientes de Proxmox limitan el ARC al 10 % de la RAM instalada por defecto, pero esa regla general es la razón por la que los hosts de virtualización quieren memoria en abundancia, que es exactamente por lo que nuestras configuraciones de ejemplo encabezan con 384 GB y 512 GB de DDR5.

Ceph está en el otro extremo de la escala: una capa de almacenamiento distribuida y con autorreparación que agrupa los discos de todo un clúster para que cualquier nodo pueda ejecutar cualquier VM, integrada directamente en la interfaz web de Proxmox. Es genuinamente hiperconvergente y genuinamente exigente: Proxmox recomienda al menos tres nodos y una red dedicada de 10 Gbps o más para el tráfico de Ceph, subiendo a 25 Gbps y más allá para pools respaldados por NVMe. Ahí es donde tener el bare metal en propiedad da sus frutos: NVMe real en el host y un uplink privado rápido entre tus servidores son lo que hace que el almacenamiento replicado y en clúster rinda, en lugar de un disco virtualizado sobre un backend compartido.

Clustering, quórum y HA

Varios hosts Proxmox pueden unirse en un único clúster, gestionado como uno solo. Por debajo, corosync se encarga de la mensajería entre nodos y pmxcfs —el sistema de archivos de clúster de Proxmox— mantiene /etc/pve sincronizado en todos ellos, de modo que cada nodo ve las mismas VMs, el mismo almacenamiento y la misma configuración. A partir de ahí obtienes migración en vivo y, con almacenamiento compartido o replicado, alta disponibilidad que reinicia los invitados en otro lugar cuando falla un nodo.

La trampa que aprende todo operador de clúster es el quórum. Un clúster solo actúa cuando una mayoría de nodos puede votar, por eso se recomienda un número impar de nodos y por eso tres es el mínimo práctico para una HA fiable. Un clúster de dos nodos no puede mantener el quórum por sí solo si cae un nodo: la solución es un QDevice, un árbitro externo ligero que aporta un voto de desempate para que un clúster de dos nodos (o de número par) sobreviva a un fallo único.

Aquí es donde ser dueño de la red importa tanto como ser dueño del hardware. Corosync es sensible a la latencia y la replicación de Ceph es ávida de ancho de banda, y ninguno de los dos debe ir en tu interfaz pública. Puedes poner una red privada virtual entre tus servidores de Serverside para que la mensajería del clúster, la replicación del almacenamiento y el tráfico de migración en vivo circulen todos por un enlace privado, manteniendo el plano de gestión y replicación completamente fuera de la internet pública mientras el uplink rápido soporta la carga.

Desplegar Proxmox VE en Serverside

Proxmox VE es una imagen de despliegue de primera clase en nuestro catálogo de SO, así que un hipervisor recién instalado se despliega sobre bare metal y es accesible en su interfaz web en menos de un minuto: sin ISO que montar, sin instalador por el que hacer clic antes de poder crear una VM. A partir de ahí el host es enteramente tuyo: root completo significa que eliges qué repositorio ejecutar, cuándo actualizar, si comprar una suscripción y cómo distribuir tu clúster, sin nada bloqueado por nuestra parte.

Si prefieres construir el host tú mismo, puedes. Una configuración iPXE personalizada te permite arrancar por red tu propia build de Proxmox o una versión fijada sobre el metal, y el montaje de ISO plug-and-play con acceso a la consola KVM está siempre ahí como alternativa: monta el instalador de Proxmox, obsérvalo arrancar desde la consola y elige tu propia distribución de ZFS. En cualquier caso, el borde de la red se sitúa por delante del hipervisor: la mitigación DDoS inline y siempre activa en nuestra red de más de 2 Tbit/s filtra los ataques antes de que alcancen tu plano de gestión en el puerto 8006, y las reglas de firewall en autoservicio te permiten restringir quién puede llegar a él.

Arranca tu propia build de Proxmox con iPXE personalizado

No estás limitado a nuestra imagen de serie. Las configuraciones iPXE personalizadas te permiten encadenar el arranque de una build o un instalador de Proxmox que tú controlas directamente sobre el hardware, de modo que el host arranque exactamente como lo especificaste en lugar de a partir de una plantilla que no elegiste.

Esa es la vía para los equipos que fijan una combinación concreta de Proxmox y kernel en toda una flota, o que integran los pasos posinstalación —selección de repositorio, distribución del almacenamiento, unión al clúster— en una única definición de arranque reproducible. Te entregamos el metal y nos mantenemos fuera de la cadena de arranque.