OpenStack Gazpacho: the release that makes the VMware exit real and your private cloud ready for what's next.

What SLURP releases are and why Gazpacho is the one that matters

OpenStack publishes two releases per year. Since 2022, alternating releases are marked as SLURP (Skip Level Upgrade Release Process): they allow operators to upgrade once a year, jumping directly from one SLURP to the next without touching the intermediate version.

Here's the current landscape:

The official Gazpacho cycle schedule details all milestones, feature freeze dates, and responsible teams. The official release page collects the highlights selected by the community.

The practical consequence: if your environment runs Epoxy (2025.1), you can jump straight to Gazpacho without touching Flamingo. That halves your mandatory upgrades and simplifies maintenance window planning in production.

And if you're on Flamingo, it's a standard one-step upgrade.

With the upgrade calendar clear, let's look at what actually justifies moving — beyond just closing a support window.

Parallel live migrations in Nova: the game changer

If we had to pick a single feature from Gazpacho to explain why this release matters to enterprises, it would be this: Nova now supports parallel live migrations.

Until now, live migration of instances processed memory transfers sequentially: one connection after another. Gazpacho introduces multiple simultaneous connections, significantly accelerating workload transfers between hosts or availability zones.

Why does this matter so much? Because migration speed is, in practice, the factor that determines how long a maintenance window lasts. For an organisation with hundreds of VMs — or one evaluating a move from VMware — the difference between serial and parallel migration is the difference between a single maintenance night and an entire weekend.

And that's not all that changes in Nova

Parallel migrations are the headline, but Nova brings three more changes that stack on the same principle: less operational friction.

Live migration with vTPM

Another feature that pairs with parallel migrations: Nova now allows live migration of instances using vTPM (virtual Trusted Platform Module) without shutting them down. Workloads with disk encryption or secure boot requirements — common in regulated environments — can now be moved between nodes without service interruption. Previously, migrating a VM with vTPM required a full shutdown-move-restart cycle. That's over.

Default IOThread per QEMU instance

A subtler change with real impact: Nova now activates a default IOThread per QEMU instance, offloading disk I/O processing from vCPUs. In high-density environments — many VMs per host — this translates to more consistent storage performance under load, without touching any configuration.

Full OpenAPI coverage in Nova

Nova achieves complete OpenAPI schema coverage: every API endpoint now has a machine-readable specification. For teams automating with Terraform, Ansible, or custom tooling, this means validating requests before sending them and reducing errors in infrastructure-as-code deployments.

Nova handles the VMs. But VMs need to live somewhere. And if that somewhere is physical hardware that hasn't gone through OpenStack before — which is exactly the situation in most VMware migrations — Ironic enters the picture.

Ironic: intelligent automation that cuts manual work

Ironic is OpenStack's service for provisioning physical servers — bare metal — as if they were virtual machines. In Gazpacho, Ironic receives a package of improvements that together represent a step change in day-to-day operations:

• Autodetect deploy interface. Ironic automatically determines the right deployment method for each server, eliminating manual selection. It doesn't sound dramatic, but in a datacentre with heterogeneous hardware (different generations, different vendors) it saves hours of per-node configuration.
• Automatic protocol detection (NFS/CIFS) for Redfish. Virtual media boot configuration is simplified: Ironic determines the correct protocol without operator intervention.
• Trait-based port scheduling. Network assignment is automated based on real infrastructure attributes — NIC type, speed, capabilities — instead of depending on manual mappings.
• Noop deploy interface. Perhaps the most interesting for migration projects: it allows you to register and monitor servers that are already deployed and running, without needing to reprovision them. The typical use case: onboarding existing hardware into OpenStack's inventory during a gradual migration from VMware or another platform.

Cyborg driver guide

Cyborg, OpenStack's accelerator service, publishes for the first time a unified driver configuration guide covering all supported types: FPGA, GPU, NIC, QAT, SSD, and PCI passthrough. For organisations incorporating AI accelerators or HPC workloads into their private cloud, having tested, unified documentation significantly lowers the barrier to entry.

VMs migrated with Nova, existing hardware onboarded with Ironic. Now for the part that always ends up more complex than expected: the network.

What changed inside: OVN, Manila, OpenBao

Networking: native BGP and OVN improvements in Neutron

The Neutron OVN controller gains features that have been long requested in enterprise environments:

• Native BGP support for advertising routes directly from the network controller, without external tooling.
• North-South routing for external ports, simplifying connectivity with physical networks.
• Allowed address pairs with virtual MACs, enabling multi-tenant scenarios and hybrid connectivity architectures.

Historically, these were scenarios where OpenStack required workarounds or third-party tools. Gazpacho solves them natively.

Storage: QoS in Manila and asynchronous volume attachments

Manila introduces QoS types and specifications that allow applying per-workload performance policies to shared storage. If you have a storage pool for databases and another for cold files, you can now set limits and priorities at the platform level, not just at the hardware level. Cinder advances asynchronous volume attachments, improving responsiveness in high-density environments.

Security: PKI with OpenBao

Integration with OpenBao — an open fork of HashiCorp Vault — for PKI certificate management in OpenStack-Ansible allows aligning OpenStack's certificate infrastructure with existing enterprise security tooling. Especially relevant in regulated environments where certificate lifecycle management is audited and where administration already uses Vault as a standard.

Watcher: cross-zone migration strategies

Watcher, the resource optimisation service, improves its workload redistribution strategies across zones with enhanced testing. For operators managing multi-site clouds or differentiated availability zones, this improves the reliability of automated redistributions during maintenance or failures.

All of the above — migrations, automation, networking — are visible features you can justify in a budget conversation. But there's work Gazpacho does silently, more important in the long run than any single feature: cleaning house.

Eventlet: the beginning of the end for legacy concurrency

One of the most important background stories in OpenStack over the past three years is the progressive elimination of Eventlet, a cooperative concurrency library adopted in the project's early days when Python 2 lacked a native alternative. Python 3 does have one: asyncio. But migrating a project the size of OpenStack from one concurrency model to another is a monumental effort.

In Flamingo (2025.2), four services completed the migration: Ironic, Mistral, Barbican, and Heat. In Gazpacho, Nova makes significant progress towards native threading, with measurable performance and stability improvements. Neutron also advances. And nine more projects are in active migration.

Why should an organisation that doesn't contribute code to OpenStack care? Because Eventlet is a known source of subtle bugs, debugging difficulties, and incompatibilities with modern Python libraries. Its removal makes OpenStack more stable, more maintainable, and more predictable in production over the long term. It's the kind of invisible improvement that doesn't appear in demos but makes a real difference at 3 AM when something fails and needs diagnosing.

Gazpacho as a VMware replacement: why the timing matters

We're back to where we started. We said 2026 is not a normal year for infrastructure — that Broadcom has forced organisations to rethink their virtualisation stack. The question those organisations ask is no longer "is OpenStack technically capable?" That was settled a long time ago. The question is: "does it have answers to my specific problems?" With Gazpacho, that answer has improved substantially.

Since Broadcom restructured the VMware licensing model — significant price increases, end of perpetual licences, shift to subscription bundles — the concerns we hear most often from customers are always the same. Gazpacho has a direct answer for each one, and each answer connects back to what we've just covered:

On top of this, OpenStack now exceeds 55 million cores in production worldwide. It's not a niche project or a future promise: it's infrastructure running in production at Walmart, CERN, NTT, Deutsche Telekom, and thousands of smaller organisations that don't publish their numbers. The project has been running for 15 years and the contributor base is growing, not shrinking.

How this fits your infrastructure

Release model, parallel live migrations, intelligent bare metal, networking without workarounds, legacy debt winding down, favourable market context. Everything converges on the same practical question: what do you do now? The answer depends on where you are.

There are three common situations, and the right diagnosis differs for each:

• You have OpenStack in production and need to plan the upgrade to Gazpacho. If you're on Epoxy, the direct SLURP-to-SLURP upgrade is your path. If you're on Flamingo, it's a standard one-step jump. In both cases, the recommendation is to validate in a test environment, especially if you use features that have changed between versions (migrations, OVN, Ironic).
• You have VMware and the renewal cost has you looking at alternatives. The question here is one of design: which workloads move first, what OpenStack architecture fits (on what hardware, with what storage — Ceph is the natural choice), and how to migrate data without stopping the service.
• You're starting a new project — private cloud, data platform, AI infrastructure — and OpenStack is on the table. Gazpacho is the right version to start with, using Ceph for storage and, if you need containers, Kubernetes integrated via Magnum.

In all three cases, the sensible order is the same: a short technical conversation to understand the situation, an architecture proposal with clear options and trade-offs, and a validation lab before touching production. What changes with Gazpacho is not the process — it's that there are more mature pieces to work with.

Further reading

• Virtualisation and private cloud with SIXE — design, deployment, and operation of private clouds
• Certified training — official courses in open infrastructure technologies
• 24/7 urgent support — for environments where a 3 AM problem is a real problem
• OpenStack 2026.1 official documentation — the full reference for Gazpacho