GUIDE · OPENSTACK TO COMMUNITY OPENSTACK, 2023.1 ANTELOPE TO 2026.2 HIBISCUS
OpenStack to OpenStack migration: move VMs to a new cloud, side by side
Seamless Migrate moves VMs from RHOSP 17.1, community OpenStack or Kolla-Ansible into a new community OpenStack cloud of any release series from 2023.1 Antelope to 2026.2 Hibiscus, one wave at a time, with the same warm, cold and storage handover strategies as a move to RHOSO 18.0.
- Source
- RHOSP 17.1, community OpenStack or Kolla-Ansible, Queens (2018) or later
- Destination
- Community OpenStack 2023.1 Antelope to 2026.2 Hibiscus, or RHOSO 18.0
- Presets
- OpenStack Community, Kolla-Ansible, RHOSO 18.0
- Strategies
- Cold, warm and storage handover
- 200 GiB VM
- 11m 20s warm, 20m 53s cold, 4m 20s handover
- License
- Open source, Apache 2.0
A new cloud beside the old one
Operators of their own OpenStack face the same choice as Red Hat's customers: upgrade in place, release after release, or build the next cloud beside the current one and move the workloads. A new Kolla-Ansible, OpenStack-Ansible or other upstream deployment on new hardware, a new storage backend or a redesigned network is often the safer road across many releases, and it is the only road when the old cloud cannot be upgraded at all.
Seamless Migrate is built for that road. The destination can be any community release series from 2023.1 Antelope to 2026.2 Hibiscus, registered with the OpenStack Community or Kolla-Ansible preset, and it runs on the same code path as RHOSO 18.0: both sides speak the OpenStack APIs, so KVM guests move to KVM with their volumes, NICs and boot properties, and the guest needs no conversion. The source can be an old community cloud, a Kolla-Ansible edge site or Red Hat OpenStack Platform 17.1.
Which OpenStack clouds can be a destination
The support window follows the upstream life cycle on releases.openstack.org, read on 16 October 2026. Tier 1 is what upstream maintains; a series moves down a tier when upstream stops maintaining it, and a new series joins within one Seamless minor release of its GA.
| Tier | Release series | Upstream phase | What a Seamless release does |
|---|---|---|---|
| Validated | RHOSO 18.0 | Red Hat's life cycle | The full lab matrix, every release |
| Tier 1 | 2026.2 Hibiscus, 2026.1 Gazpacho, 2025.2 Flamingo, 2025.1 Epoxy | Maintained upstream | The destination lab matrix before each final release |
| Tier 2 | 2024.1 Caracal, 2023.1 Antelope | Unmaintained upstream, SLURP | A compatibility smoke run |
| Tier 3 | 2024.2 Dalmatian, 2023.2 Bobcat | End of life upstream | Capability checks only, with a warning |
| Outside | Zed and older; newer than 2026.2 | Below the floor, or not validated yet | Capability checks only, with a warning |
Behaviour follows capabilities, never the series name. What a destination needs, checked before anything moves:
- Keystone v3 with project-scoped tokens; application credentials work too.
- Compute API 2.60 or later, Block Storage v3 and Glance v2.
- Neutron ports with fixed IPs, MAC addresses and port security.
- For a storage handover: Cinder manage, the admin role and a backend of the same driver family as the source, on the same Ceph cluster or NetApp ONTAP SVM.
- A conversion host image the roles support: the RHEL family (RHEL 9 with its subscription; CentOS Stream 9 and 10, Rocky Linux 9 and AlmaLinux 9 with EPEL) or Ubuntu 24.04 LTS and later.
A vendor build of a community series counts as the series it ships; none is certified. The full policy is in the design document, section 21.
Roles and policy defaults on the destination
Community clouds enforce the secure-RBAC policy defaults since 2023.2 Bobcat: the personas are reader, member, manager and admin, plus service for service-to-service calls. The destination credential needs:
- member for cold and warm migrations into its own project.
- admin to pre-stage flavors, for a storage handover and for an external network that is not shared.
- service or admin for a port with a fixed IP or MAC address on another project's network. The older
advsvcrole counts only on a cloud that turned the new defaults off.
Pre-flight validation raises NET_PORT_NOT_PERMITTED with the least role that fits, before the source VM stops, judged by the destination's policy profile, secure-RBAC or legacy, as the provider check reports it (a series from 2023.2 on means secure-RBAC unless you declare otherwise). The manager role is never required.
Three ways to move each VM
warmWarm
Snapshot passes copy the disks while the VM keeps serving traffic. After the first pass only changed chunks cross the wire, each pass ending with a verified digest; at cutover only the final delta remains.
- Downtime:
- the final delta and a scan of the largest disk
- Needs:
- conversion hosts in both clouds, no multi-attach volumes
storage_handoverStorage handover
When both clouds share a Ceph cluster or a NetApp ONTAP SVM, Cinder unmanages each volume at the source and manages it at the destination. Nothing is copied.
- Downtime:
- metadata operations, a few minutes whatever the size
- Needs:
- admin on both clouds, every volume type mapped to a destination backend on the same pool
coldCold
The VM stops and os-migrate copies its used data between the conversion hosts over SSH before it boots on the destination.
- Downtime:
- the whole copy of the used data
- Needs:
- conversion hosts in both clouds
Cold copies run on the os-migrate Ansible collection, which stays the data mover underneath every OpenStack strategy. Seamless estimates every eligible strategy for each VM and picks the least downtime; you can override the choice per VM.
How long each VM is down
| VM (one volume, 60 % used) | Warm | Storage handover | Cold |
|---|---|---|---|
| 50 GiB | 6m 12s | 4m 20s | 8m 36s |
| 200 GiB | 11m 20s | 4m 20s | 20m 53s |
| 500 GiB | 21m 34s | 4m 20s | 45m 28s |
| 1 TiB | 39m 27s | 4m 20s | 1h 28m |
OpenStack sources. Estimated downtime from the stop to the verified boot, with the planning model's defaults: 125 MiB/s link, 2 MiB/s of guest writes. The control plane recalibrates both after the first delta pass.
Try your own VM in the downtime calculator.
Networking and TLS on a community cloud
Networking is ML2/OVN or ML2/OVS, as the operator chose. Seamless recreates networks, subnets, routers and security groups on the destination, maps every NIC to a destination network and keeps the fixed IPs; no OVS- or OVN-specific binding is copied. A source MTU larger than the destination network's raises NET_MTU_SHRINK before anything moves, as on RHOSO 18.0.
TLS is the operator's choice on a community cloud, so verification stays on by default, with a CA bundle per provider for a private CA, and the provider check names any endpoint that still speaks plain HTTP.
The network cut-over, a Technology Preview validated in simulation, works on a community destination as on RHOSO 18.0: on a plan that opts in, floating IPs keep their address when both clouds share the external network, a DNS record follows a changed address through Designate or RFC 2136, and hooks an admin registers run at fixed points of each migration. The pre-flight warns when the source uses Neutron's DNS integration and the destination lacks its extension or zone, and the verification waits until each moved address answers.
How the migration runs
- 01
Connect both clouds
Add the source with its preset, and the new cloud with the OpenStack Community or Kolla-Ansible preset as the destination, declaring its release series if you know it. Credentials are write-only. One click checks each connection: Keystone, Nova, Cinder, Neutron and Glance, the roles, the Compute API version, TLS and the storage backends, and for the destination its release series, support tier and policy profile.
- 02
Stage the destination
Pre-stage the flavors, images and projects the VMs need, and a conversion host from a supported image in each cloud; an existing host works too, through its SSH key. Networks, subnets, routers and security groups are recreated by the migration.
- 03
Discover, map and plan
Select VMs from the inventory, map networks, flavors, volume types and projects, and let the planner order waves by risk with a small pilot first.
- 04
Validate
Pre-flight findings come with their fix: quota, MTU, guest OS, the roles each port needs on the destination, a capability a strategy needs that the destination lacks (a blocker) and a series outside the support tiers (a warning). Every VM gets a downtime estimate for each eligible strategy and an automatic choice you can override.
- 05
Copy while the VMs run
Warm VMs pre-copy in snapshot passes and wait, kept fresh by keep-warm syncs, for their change window.
- 06
Cut over, verify, finalize
A second approver, the change window and a free cutover slot gate every cutover. The VM stops, the final delta syncs and it boots on the destination; a failed check rolls it back on its own. Finalize needs an approver and the VM's name typed in full.
FAQ
OpenStack to OpenStack, answered.
What community cloud operators ask before they move tenants to a new release.
Which OpenStack releases can be a destination?
Every community release series from 2023.1 Antelope to 2026.2 Hibiscus, by support tier, and RHOSO 18.0. The floor is 2023.1 Antelope, the oldest SLURP series not at its end of life upstream; a newer series joins Tier 1 within one Seamless minor release of its GA, once the lab matrix passes on it. An older or newer cloud still runs when it has every capability a strategy needs, with a warning that no release validated it.
Do I need Red Hat OpenStack at all?
No. The source can be community OpenStack or Kolla-Ansible and the destination a community cloud too; RHOSO 18.0 is one destination among them. Seamless Migrate is an independent open source project under the Apache License 2.0 and needs no Red Hat subscription.
Which deployment tools does Seamless Migrate support?
The dashboard has presets for OpenStack Community and Kolla-Ansible as destinations, beside RHOSO 18.0. A cloud deployed with OpenStack-Ansible, DevStack or another tool registers with the OpenStack Community preset: what matters is the release series its APIs expose, not the tool. A vendor build of a community series counts as the series it ships; none is certified.
Is a community destination validated like RHOSO 18.0?
RHOSO 18.0 is the reference destination; release lab validation is pending; a community destination runs on the same code path, and the provider check already reports its release series, support tier and policy profile, with a missing capability blocking the plan before anything moves. What remains is the lab, which has not run yet: the destination lab matrix on every upstream-maintained series (2025.1 Epoxy, 2025.2 Flamingo, 2026.1 Gazpacho and 2026.2 Hibiscus) and a compatibility smoke run on 2023.1 Antelope and 2024.1 Caracal. They run against the release candidate, and a final release needs them.
Which roles does the destination credential need?
Under the secure-RBAC defaults, upstream's since 2023.2: member for cold and warm migrations into its own project; admin to pre-stage flavors, for a storage handover and for an external network that isn't shared; service or admin for a port with a fixed IP or MAC address on another project's network, where advsvc counts only on a cloud that turned the new defaults off. The manager role is never required.
How much downtime does an OpenStack to OpenStack migration need?
For a VM with one 200 GiB volume, 120 GiB used and 2 MiB/s of guest writes over 125 MiB/s, the planning model estimates 11m 20s for a warm migration, 20m 53s for a cold copy and 4m 20s for a storage handover on shared Ceph or NetApp ONTAP.
Can I migrate from Zed, Yoga or an older release?
As a source, yes: any release with Keystone v3, Nova API 2.60 or later, Cinder v3 and Neutron v2, that is OpenStack Queens (2018) and later. As a destination the floor is 2023.1 Antelope; an older cloud gets the capability checks only and a warning that no release validated it.
GET STARTED
Big possibilities.
First, a small pilot.
The demo runs every phase, from pre-copy to cutover, verification and rollback, against simulated clouds on your laptop. No OpenStack needed to try it.
Docker on a Linux server, or Colima on a Mac
$ git clone https://github.com/imransetiadi/seamless-vms-migrationgit clone https://github.com/imransetiadi/seamless-vms-migration$ cd seamless-vms-migrationcd seamless-vms-migration# macOS only: not needed on Linux$ make seamless-colima-upmake seamless-colima-up # macOS only: not needed on Linux$ scripts/compose-init.shscripts/compose-init.sh# simulated clouds, every phase$ make seamless-demomake seamless-demo # simulated clouds, every phaseOpen the local demo (opens in a new tab)Sign in at /login with the admin token compose-init.sh printed. Podman works too: SEAMLESS_ENGINE=podman.