OpenStack Gazpacho: la release que acelera la salida de VMware y prepara tu nube privada para lo que viene.

Qué es una release SLURP y por qué Gazpacho es la que importa

OpenStack publica dos versiones al año. Desde 2022, las releases alternas se marcan como SLURP (Skip Level Upgrade Release Process): permiten a los operadores actualizar una sola vez al año, saltando directamente de una SLURP a la siguiente sin pasar por la versión intermedia.

Esto es lo que hay encima de la mesa a fecha de este post:

El calendario oficial del ciclo Gazpacho detalla los milestones, fechas de feature freeze y los equipos responsables de cada componente. La página oficial de la release recoge las highlights seleccionadas por la comunidad.

La consecuencia práctica: si tu entorno ejecuta Epoxy (2025.1), puedes saltar directamente a Gazpacho sin tocar Flamingo. Eso reduce a la mitad las actualizaciones obligatorias y simplifica la planificación de ventanas de mantenimiento en producción.

Y si estás en Flamingo, el salto es de un solo paso — el estándar.

Con el calendario claro, veamos qué justifica actualizar — más allá de cerrar una ventana de soporte.

Migraciones en vivo paralelas en Nova: el cambio de juego

Si tuviéramos que elegir una sola novedad de Gazpacho para explicar por qué esta release importa a las empresas, sería esta: Nova ahora soporta migraciones en vivo paralelas.

Hasta ahora, la migración en vivo de instancias procesaba las transferencias de memoria de forma secuencial: una conexión tras otra. Gazpacho introduce múltiples conexiones simultáneas, lo que acelera significativamente el traslado de cargas de trabajo grandes entre hosts o zonas de disponibilidad.

¿Por qué importa tanto? Porque la velocidad de migración es, en la práctica, el factor que determina cuánto dura una ventana de mantenimiento. Para una empresa con cientos de máquinas virtuales — o que está evaluando mover cargas desde VMware — la diferencia entre migrar en serie y migrar en paralelo es la diferencia entre una noche de mantenimiento y un fin de semana entero.

Y eso no es todo lo que cambia en Nova

Las migraciones paralelas son la novedad más visible, pero Nova trae otros tres cambios que se acumulan sobre el mismo principio: menos fricción operativa.

Migración en vivo con vTPM

Otra novedad que acompaña a las migraciones paralelas: Nova permite ahora migrar instancias que utilizan vTPM (módulo de plataforma segura virtual) sin necesidad de apagarlas. Las cargas de trabajo con requisitos de cifrado de disco o arranque seguro — habituales en entornos regulados — ya pueden trasladarse entre nodos sin interrumpir el servicio. Hasta ahora, migrar una VM con vTPM requería apagar, mover, y volver a encender. Eso se ha acabado.

IOThread por defecto en QEMU

Un cambio más sutil pero con impacto real: Nova activa por defecto un IOThread por instancia de QEMU, descargando el procesamiento de E/S de disco de las vCPU. En entornos de alta densidad — muchas VMs por host — esto se traduce en un rendimiento de almacenamiento más consistente bajo carga, sin necesidad de tocar la configuración.

Cobertura completa de OpenAPI en Nova

Nova logra cobertura total de su esquema OpenAPI: cada endpoint del API tiene ahora una especificación legible por máquinas. Para equipos que automatizan con Terraform, Ansible o herramientas propias, esto significa validar peticiones antes de enviarlas al API y reducir errores en despliegues de infraestructura como código.

Bien. Nova controla las VMs. Pero las VMs tienen que vivir en algún sitio. Y si ese sitio es hardware físico que no ha pasado por OpenStack antes — que es exactamente la situación de la mayoría de migraciones desde VMware — entra en escena Ironic.

Ironic: automatización inteligente que reduce el trabajo manual

Ironic es el servicio de OpenStack para aprovisionar servidores físicos — bare metal — como si fueran máquinas virtuales. En Gazpacho, Ironic recibe un paquete de mejoras que, juntas, representan un salto en la operación del día a día:

• Autodetect deploy interface. Ironic detecta automáticamente el método de despliegue adecuado para cada servidor, eliminando la selección manual. No suena espectacular, pero en un datacenter con hardware heterogéneo (distintas generaciones, distintos fabricantes) quita horas de configuración por nodo.
• Detección automática de protocolo (NFS/CIFS) para Redfish. La configuración de arranque por virtual media se simplifica: Ironic determina el protocolo correcto sin intervención del operador.
• Planificación de puertos basada en traits. La asignación de red se automatiza según los atributos reales de la infraestructura — tipo de NIC, velocidad, capacidades — en lugar de depender de mapeos manuales.
• Interfaz de despliegue "noop". Quizá la más interesante para proyectos de migración: permite registrar y monitorizar servidores que ya están desplegados y funcionando sin necesidad de reaprovisionarlos. El caso de uso típico: incorporar hardware existente al inventario de OpenStack durante una migración gradual desde VMware o desde otra plataforma.

Guía de drivers en Cyborg

Cyborg, el servicio de aceleradores de OpenStack, publica por primera vez una guía de configuración de drivers que cubre todos los tipos soportados: FPGA, GPU, NIC, QAT, SSD y PCI passthrough. Para organizaciones que están incorporando aceleradores de IA o cargas HPC en su cloud privado, disponer de documentación unificada y probada reduce significativamente la barrera de entrada.

Tenemos las VMs migradas con Nova y el hardware registrado con Ironic. Ahora viene la parte que siempre acaba siendo más complicada de lo esperado: la red.

Lo que cambia por dentro: OVN, Manila, OpenBao

Redes: BGP nativo y mejoras OVN en Neutron

El controlador OVN de Neutron incorpora novedades que llevan tiempo pidiéndose en entornos enterprise:

• Soporte BGP nativo para anunciar rutas directamente desde el controlador de red, sin necesidad de herramientas externas.
• Enrutamiento Norte-Sur para puertos externos, simplificando la conectividad con redes físicas.
• Pares de direcciones permitidos con MACs virtuales, facilitando escenarios multitenant y arquitecturas de conectividad híbrida.

Históricamente, estos eran escenarios donde OpenStack requería soluciones alternativas o herramientas de terceros. Gazpacho los resuelve de forma nativa.

Almacenamiento: QoS en Manila y adjuntos asíncronos

Manila introduce tipos y especificaciones de QoS que permiten aplicar políticas de rendimiento por carga de trabajo al almacenamiento compartido. Si tienes un pool de almacenamiento para bases de datos y otro para ficheros fríos, ahora puedes establecer límites y prioridades a nivel de la plataforma, no solo a nivel del hardware. Cinder avanza en los adjuntos asíncronos de volúmenes, mejorando la respuesta en entornos de alta densidad.

Seguridad: PKI con OpenBao

La integración con OpenBao — fork abierto de HashiCorp Vault — para la gestión de certificados PKI en OpenStack-Ansible permite alinear la infraestructura de certificados de OpenStack con las herramientas de seguridad empresarial existentes. Especialmente relevante en entornos regulados donde la gestión del ciclo de vida de los certificados está auditada y donde la administración ya utiliza Vault como estándar.

Watcher: estrategias de migración cross-zone

Watcher, el servicio de optimización de recursos, mejora sus estrategias de redistribución de cargas entre zonas con un testing reforzado. Para operadores que gestionan clouds multi-site o con zonas de disponibilidad diferenciadas, esto mejora la fiabilidad de las redistribuciones automáticas durante mantenimientos o ante fallos.

Todo lo anterior — migraciones, automatización, redes — son features visibles que puedes vender internamente. Pero hay un trabajo que Gazpacho hace en silencio, más importante a largo plazo que cualquier feature nueva: limpiar la casa por dentro.

Eventlet: el principio del fin de una dependencia heredada

Una de las historias de fondo más importantes de OpenStack en los últimos tres años es la eliminación progresiva de Eventlet, una biblioteca de concurrencia cooperativa que se adoptó en los primeros días del proyecto, cuando Python 2 no tenía una alternativa nativa. Python 3 sí la tiene: asyncio. Pero migrar un proyecto del tamaño de OpenStack de un modelo de concurrencia a otro es un trabajo monumental.

En Flamingo (2025.2), cuatro servicios completaron la migración: Ironic, Mistral, Barbican y Heat. En Gazpacho, Nova avanza significativamente hacia el threading nativo, con mejoras de rendimiento y estabilidad medibles. Neutron también progresa. Y nueve proyectos más están en proceso activo de migración.

¿Por qué importa esto a una empresa que no contribuye código a OpenStack? Porque Eventlet es una fuente conocida de bugs sutiles, dificultades de depuración e incompatibilidades con bibliotecas modernas de Python. Su eliminación hace OpenStack más estable, más mantenible y más predecible en producción a largo plazo. Es el tipo de mejora invisible que no aparece en demos pero que se nota en las 3 de la mañana cuando algo falla y hay que diagnosticarlo.

Gazpacho como alternativa a VMware: por qué el timing importa

Volvemos al punto de partida del artículo. Dijimos que 2026 no es un año normal para la infraestructura — que Broadcom ha forzado a muchas organizaciones a replantearse su stack de virtualización. La pregunta que se hace ese tipo de organización no es "¿OpenStack es técnicamente capaz?". Eso quedó resuelto hace tiempo. La pregunta es: "¿tiene respuesta para mis problemas concretos?". Y con Gazpacho, la respuesta ha mejorado notablemente.

Desde que Broadcom reestructuró el modelo de licencias — subidas significativas, eliminación de licencias perpetuas, cambio a bundles — las preguntas de los clientes que nos llegan son siempre las mismas. Gazpacho tiene respuesta para cada una de ellas, y es una respuesta que conecta directamente con lo que acabamos de ver:

A esto se suma que OpenStack supera los 55 millones de cores en producción a nivel mundial. No es un proyecto de nicho ni una promesa de futuro: es infraestructura que opera en producción en Walmart, CERN, NTT, Deutsche Telekom, y miles de organizaciones más pequeñas que no publican sus números. El proyecto lleva 15 años funcionando y la base de contribuidores está creciendo, no encogiéndose. La release anterior, Flamingo (2025.2), ya había avanzado significativamente en seguridad y en la eliminación de Eventlet.

Cómo encaja esto en tu infraestructura

Modelo de releases, migraciones paralelas, bare metal inteligente, redes sin parches, deuda técnica en retirada, contexto de mercado favorable. Todo confluye en la misma pregunta práctica: ¿y tú, qué haces ahora? La respuesta depende de dónde estás.

Hay tres situaciones habituales, y el diagnóstico es distinto en cada una:

• Tienes OpenStack en producción y necesitas planificar el salto a Gazpacho. Si estás en Epoxy, el upgrade directo SLURP-a-SLURP es tu ruta. Si estás en Flamingo, es un salto estándar. En ambos casos, la recomendación es validar en entorno de pruebas, especialmente si usas features que han cambiado entre versiones (migraciones, OVN, Ironic).
• Tienes VMware y el coste de renovación te ha hecho mirar alternativas. Aquí la pregunta es de diseño: qué workloads se mueven primero, qué arquitectura OpenStack encaja (sobre qué hardware, con qué almacenamiento — Ceph es la opción natural), cómo se migran los datos sin parar el servicio.
• Arrancas un proyecto nuevo — cloud privado, plataforma de datos, infraestructura de IA — y OpenStack es una de las opciones. Gazpacho es la versión correcta para empezar, con Ceph como almacenamiento y, si necesitas contenedores, Kubernetes integrado a través de Magnum.

En los tres casos, el orden sensato es el mismo: conversación técnica corta para entender el caso, propuesta de arquitectura con opciones y trade-offs claros, y laboratorio de validación antes de tocar producción. Lo que cambia con Gazpacho no es el proceso — es que hay más piezas maduras con las que trabajar.

Para seguir leyendo

• Ceph Tentacle: el salto que cambia el almacenamiento open source en 2026 — el almacenamiento que mejor encaja bajo OpenStack
• Virtualización y cloud privada con SIXE — diseño, despliegue y operación de nubes privadas
• Formación certificada — cursos oficiales en tecnologías de infraestructura abierta
• Soporte urgente 24/7 — para entornos donde un problema a las 3 de la mañana es un problema de verdad