La pregunta resulta lógica: si tanto OpenStack como Proxmox utilizan KVM, ¿por qué no instalar Proxmox en los servidores y desplegar OpenStack encima para gestionar toda la infraestructura? La respuesta radica en que ambos son plataformas de control que buscan gestionar recursos y automatizar operaciones, lo que puede generar conflictos en lugar de complementariedad. Integrarlos no garantiza automáticamente una nube privada más completa.
Resumen rápido de OpenStack y Proxmox en 30 segundos
- OpenStack soporta KVM mediante Nova y libvirt, pero no tiene un controlador específico para gestionar clústeres de Proxmox.
- Proxmox administra máquinas virtuales, redes, almacenamiento, alta disponibilidad, permisos y copias de seguridad en una plataforma integrada.
- Superponer dos controles sobre los mismos recursos puede derivar en configuraciones inconsistentes y operaciones contradictorias.
- Proxmox funciona bien como plataforma de virtualización completa; OpenStack es más adecuado para nubes IaaS multiusuario y autoservicio.
- Kubernetes puede desplegarse sobre cualquiera de los dos, por lo que no justificaría desplegar OpenStack solo por ello.
La documentación actual de Nova, el componente de computación de OpenStack, soporta KVM mediante libvirt y otros hipervisores como VMware vSphere, Virtuozzo, z/VM, o el aprovisionamiento físico con Ironic. Sin embargo, Proxmox no aparece como un hipervisor o controlador soportado oficialmente.
Esto no significa que no sea posible crear integraciones personalizadas, llamar a la API de Proxmox o construir un puente que traduzca órdenes. Pero esa integración no forma parte del modelo estándar de OpenStack y implicaría que una organización asuma el desarrollo, las pruebas, el mantenimiento y la resolución de fallos en una capa intermedia gestionada por ambos proyectos, sin una coordinación oficial.
KVM: un punto en común, pero no la arquitectura definitiva
KVM es la tecnología de virtualización incluida en Linux, que permite ejecutar máquinas virtuales usando las extensiones del procesador. Proxmox VE la combina con QEMU para ofrecer una virtualización completa de sistemas Windows y Linux. OpenStack la puede utilizar como motor de cómputo a través de Nova y libvirt.
La coincidencia termina ahí. Proxmox VE no es solo una interfaz web para KVM; es una plataforma integral que gestiona clústeres, alta disponibilidad, migraciones, almacenamiento, redes definidas por software, cortafuegos, permisos y recuperación. También soporta contenedores LXC desde el mismo entorno.
OpenStack construye su aprovisionamiento mediante servicios separados: Nova para cómputo, Neutron para redes, Cinder para almacenamiento en bloques, Glance para imágenes y Keystone para identidad. Además, se pueden agregar componentes para balanceo, orquestación, telemetría o gestión de clústeres de contenedores.
Cuando OpenStack crea una instancia, registra su identidad, asigna un host, conecta interfaces virtuales, adjunta volúmenes y mantiene el estado del recurso. Proxmox realiza acciones similares en su propio inventario, con sus definiciones de almacenamiento, red y alta disponibilidad.
Permitir que ambos gestionen las mismas máquinas genera dos fuentes de verdad distintas. Por ejemplo, OpenStack puede considerar que una instancia debe ejecutarse en un nodo mientras Proxmox intenta migrarla por alta disponibilidad. Un administrador puede cambiar un disco desde la interfaz de Proxmox sin que Cinder registre esa acción. Las redes configuradas en Neutron pueden no coincidir con las que establece Proxmox en sus puentes o VLAN.
Este tipo de conflictos no suele aparecer en los procesos iniciales, sino que emergen meses después, durante migraciones, recuperaciones, ampliaciones de disco o actualizaciones. Las configuraciones manuales y automatizadas, junto con múltiples administradores y cientos de máquinas, incrementan la divergencia.
Instalar componentes de Nova directamente en servidores ya gestionados por Proxmox tampoco soluciona la contradicción. En realidad, significa que OpenStack gestionaría los KVM y libvirt subyacentes mientras Proxmox mantiene sus propios archivos de configuración y base de datos en paralelo, en los mismos recursos físicos.
La opción más coherente es definir claramente el plano de control: si optamos por OpenStack, los nodos de cómputo deben integrarse siguiendo su arquitectura y controladores; si elegimos Proxmox, las máquinas deben gestionarse con su clúster, API y herramientas específicas.
Por supuesto, se puede usar ambos en paralelo en una organización. Se puede mantener un entorno Proxmox para cargas tradicionales y otro OpenStack para servicios internos de infraestructura como servicio (IaaS). La separación evita conflictos y permite asignar cargas de trabajo a cada modelo operativo.
Virtualización frente a nube privada: la decisión real
Muchos debates surgen al migrar desde VMware vSphere. La transición a menudo implica decidir si reemplazar la plataforma de virtualización o construir una nube privada. Proxmox satisface muchas funciones que antes ofrecía vSphere, incluyendo agrupación de servidores, VM y contenedores, alta disponibilidad, integración con Ceph, ZFS, almacenamiento compartido, migraciones y backups específicos.
Además, Proxmox DataCenter Manager permite gestionar múltiples clústeres y centros de datos, simplificando la administración centralizada de miles de cargas. Sin embargo, esta funcionalidad sigue basada en el modelo de Proxmox, sin ofrecer todos los servicios avanzados de una nube IaaS completa.
OpenStack, en cambio, atiende a un perfil diferente: proporciona a los usuarios finales recursos bajo demanda mediante API, con capacidades para aislar proyectos, establecer cuotas, crear redes dinámicas, gestionar catálogos de imágenes y adjuntar volúmenes sin intervención manual.
En una nube privada, la infraestructura se presenta como un servicio: los equipos de desarrollo solicitan recursos sin preocuparse por detalles de hardware o almacenamiento, y el sistema decide dónde desplegar según capacidad y políticas. Pero esto implica mantener múltiples servicios, bases de datos, colas de mensajería, redes, almacenamiento, además de un personal capacitado para gestión, automatización y resolución de fallos complejos.
Mientras Proxmox reduce esa carga con una gestión más sencilla, su API, permisos y automatización no convierten automáticamente a un clúster de virtualización en una nube IaaS completa. La cantidad de VM no es el único factor: entornos con menos de 2000 VMs pueden justificar OpenStack si demandan autogestión, redes aisladas y creaciones dinámicas de recursos. En entornos con cargas estables y administración centralizada, Proxmox puede ser suficiente.
La clave no es solo contar máquinas virtuales, sino entender quién las solicita, con qué frecuencia cambian y qué servicios necesitan los usuarios. Si los cambios se gestionan manualmente y con procedimientos controlados, Proxmox puede cubrir las necesidades. Pero si decenas de equipos requieren consumir recursos mediante API con aislamiento y cuotas, las capacidades de OpenStack justifican su complejidad.
La elección del hipervisor en sí también tiene matices. Aunque OpenStack soporta múltiples tecnologías y su documentación indica que puede programar cargas sobre diferentes hipervisores, en la práctica la mayoría de despliegues usan solo uno. Las diferencias en funciones, formatos y controladores hacen difícil tratarlos como intercambiables sin trabajo adicional.
Elegir OpenStack también implica una dependencia tecnológica hacia sus APIs, servicios, diseño de redes y almacenamiento. Esta dependencia, aunque preferible a la de un proveedor propietario, sigue existiendo y debe considerarse en la decisión.
Kubernetes: ¿obliga a desplegar OpenStack?
Kubernetes a menudo se presenta como una razón para usar OpenStack, aunque no son dependientes en modo automático. Kubernetes puede ejecutarse sobre máquinas virtuales creadas en Proxmox, vSphere o OpenStack, y no requiere necesariamente OpenStack para su operación.
Un clúster estable puede funcionar perfectamente sobre Proxmox usando plantillas, Terraform, Ansible u otras herramientas, y Kubernetes gestionará los contenedores. Para muchos entornos, esto es suficiente.
OpenStack aporta valor cuando Kubernetes necesita consumir recursos dinámicamente; por ejemplo, con Magnum para clústeres de contenedores, integration con Keystone, Neutron, Cinder y Octavia para balanceo. La decisión de usar OpenStack depende de si es necesario un aprovisionamiento y gestión avanzada de recursos a través de API, o si basta con máquinas virtuales estables gestionadas desde un entorno más simple.