Tras un periodo de silencio que se alargó más de dos años, oVirt vuelve a aparecer en el radar de los administradores de sistemas con oVirt 4.5.7, una versión que busca algo muy concreto: mantener viva una plataforma clásica de gestión de virtualización basada en KVM en un momento en el que muchas organizaciones están reordenando su estrategia (y sus dependencias) en infraestructura.
La edición 4.5.7 se anunció como “generalmente disponible” el 13 de enero de 2026, y llega con un mensaje implícito: el proyecto, ahora empujado en gran parte por la comunidad, quiere seguir siendo una opción viable en entornos empresariales que han apostado por KVM y un plano de control centralizado.
Qué trae oVirt 4.5.7 y por qué importa
Aunque a primera vista “otra release más” podría parecer poco relevante, esta actualización toca tres puntos que suelen ser decisivos en producción:
1) Soporte para plataformas actuales (hosts y guests)
oVirt 4.5.7 amplía compatibilidad y empaquetado para entornos modernos. El anuncio menciona disponibilidad para CentOS Stream 9 y 10, además de RHEL 9/10 y derivados, y destaca específicamente soporte para CentOS 10 y AlmaLinux 10.
Este tipo de soporte no es un detalle menor: en virtualización, “estar al día” con el host OS condiciona drivers, kernel, compatibilidad de CPU, cadena de herramientas y, en general, la capacidad de mantener un ciclo de vida razonable.
2) Corrección de una vulnerabilidad (CVE-2024-7259)
La release incluye la corrección de CVE-2024-7259.
En la base de datos de NVD (NIST) esta vulnerabilidad se asocia a oVirt Engine y se indica que afecta a versiones anteriores a 4.5.7 (entre otros detalles técnicos y de alcance).
Si oVirt está en producción, este punto por sí solo suele justificar planificar una ventana de mantenimiento.
3) Modernización del stack Java y mejoras operativas
El proyecto indica que todo el código Java se construye ahora con Java 21, manteniendo compatibilidad con Java 11.
Además, se incluyen mejoras muy “de trinchera”, como una reconexión más rápida del host tras reinicio (en vez de un comportamiento estático de 10 minutos), ajustes en el arranque de VMs (reserva de puertos PCIe), mejoras de UI/administración y cambios en niveles de clúster, entre otros.
Compatibilidad de CPU: mantener el paso en servidores modernos
Uno de los mensajes más claros de esta versión es que oVirt intenta seguir siendo relevante en hardware actual. En el anuncio se listan nuevas familias de CPU soportadas, incluyendo:
- AMD EPYC: Milan, Rome y Genoa
- Intel: Sapphire Rapids
- IBM: POWER10
Para organizaciones con renovación de servidores (o para quienes compran infraestructura en ciclos de 3–5 años), esto es crítico: sin compatibilidad real, la plataforma se queda congelada por definición.
Nota importante: el caso de oVirt Node NG
El propio anuncio hace una recomendación llamativa: a quienes usan oVirt Node NG se les insta a migrar a otra forma de uso “por estabilidad y seguridad”, debido a cómo está estructurado ese producto.
En la práctica, es una señal para administradores: conviene revisar el método de despliegue/operación y evitar depender de componentes que el proyecto considere problemáticos.
Comparativa: oVirt frente a alternativas habituales
oVirt sigue siendo una opción sólida cuando se busca un manager KVM “clásico” con arquitectura conocida, pero el mercado (y el open source) se ha fragmentado mucho. Para entender el encaje, aquí va una comparativa orientativa.
Tabla rápida de posicionamiento (visión práctica)
| Plataforma | Enfoque | Puntos fuertes | Puntos a vigilar | Encaje típico |
|---|---|---|---|---|
| oVirt | Gestión centralizada de virtualización KVM | Madurez histórica, modelo “enterprise KVM manager”, stack conocido | Ecosistema menos “de moda”; depende de cómo evolucione la comunidad | Entornos KVM que quieren un plano de control clásico y estable |
| Proxmox VE | KVM + contenedores (LXC) con gestión integrada | Curva de adopción rápida, comunidad enorme, clustering práctico | Cambios de operación/migración si vienes de un modelo oVirt/RHV | Pymes/empresas que priorizan agilidad, coste y operación simple |
| OpenNebula | Cloud privada (IaaS) sobre hipervisores | Orientación a multi-tenant y cloud privada | Requiere más “cloud mindset” que “virtualización tradicional” | Proveedores/IT que quieren portal y gobierno tipo cloud |
| OpenStack (con KVM) | Cloud a gran escala, altamente modular | Muy potente en multi-tenant, red/almacenamiento complejos | Complejidad operativa alta, “no es para todo” | Grandes despliegues y organizaciones con equipo cloud dedicado |
| Harvester (HCI sobre Kubernetes) | HCI y VMs gestionadas en un enfoque cloud-native | Integración con ecosistema Kubernetes | Depende del modelo operativo K8s; no siempre encaja | Equipos que ya operan Kubernetes y quieren unificar el plano |
| VMware vSphere (propietario) | Virtualización enterprise “clásica” | Madurez, ecosistema enorme | Coste/licenciamiento, dependencia de vendor | Organizaciones que priorizan continuidad y estándar histórico |
| Nutanix AHV (propietario) | HCI con hipervisor propio | Operación integrada y experiencia HCI | Coste y dependencia de plataforma | Empresas que adoptan HCI como estándar |
Cómo decidir sin caer en “religión” tecnológica
- Si la prioridad es seguir con un modelo KVM gestionado de forma central y tienes experiencia histórica con oVirt/RHV, oVirt sigue siendo coherente, especialmente con una release que actualiza compatibilidad y seguridad.
- Si lo que se busca es rapidez de despliegue y operación diaria simplificada, muchas organizaciones se están yendo a Proxmox VE (especialmente en escenarios de consolidación, pymes y edge).
- Si lo que necesitas es cloud privada con multi-tenant “de verdad”, ahí el debate suele girar entre OpenNebula y OpenStack, con la complejidad como factor decisivo.
Conclusión: una release pequeña en marketing, grande en señales
oVirt 4.5.7 no vende fuegos artificiales: su valor está en lo que implica para producción real. Una vuelta tras más de dos años, soporte de plataformas modernas, fix de una CVE concreta y mejoras operativas que importan cuando hay reinicios, mantenimiento y SLAs.
Para quienes mantienen clusters KVM con un enfoque tradicional, es una actualización que merece atención. Y para quienes están replanteando su roadmap, también sirve como termómetro: oVirt sigue vivo, pero el “cómo” (y el ritmo) dependerá de comunidad, adopción y casos de uso.
