Your VMware SRM Replacement Was Hiding in Your Storage Array All Along

If you're one of the thousands of infrastructure teams re-evaluating your virtualization stack right now, you already know the drill: Broadcom's licensing changes made "wait and see" an expensive strategy, and OpenStack has moved from "the thing we run for the lab" to "the thing we're running production on." The compute and networking story for that migration is well trodden at this point. The disaster recovery story is not — and it's usually the last question asked in the room, right after someone says "so what happens when we lose a whole site?"

That question used to have an easy answer in a VMware shop: Site Recovery Manager. Recovery plans, protection groups, non-disruptive test failovers, self-service DR that application owners could run without paging the storage team. OpenStack, on its own, doesn't have an equivalent. And that gap is exactly what Trilio Site Recovery, running on Everpure FlashArray, is built to close.

The Gap in Native OpenStack DR

OpenStack is very good at availability inside a region. Nova spreads VMs across compute hosts, Cinder spreads volumes across backends, Neutron routes around failed links. None of that helps you when the entire site goes dark.

Cinder can replicate volumes at the backend level, and Everpure FlashArray does that replication well. But that capability sits below the OpenStack control plane, and it shows:

Trilio Site Recovery wraps FlashArray's replication in a tenant-facing control plane that answers all four of those problems — exactly the territory SRM used to own for VMware admins.

What "SRM-Like" Actually Looks Like Here

The core object is the Protection Group: a named set of Nova VMs that fail over together as a unit, with one primary site and one secondary site. Add a VM to a group and its Cinder volumes get enrolled together so every disk in the group snapshots at the same instant — a crash-consistent recovery point across the whole application tier, not a pile of individually-consistent volumes you have to reason about separately.

From there, the operational picture maps almost one-to-one onto what a VMware admin already expects from SRM:

• Planned failover — graceful shutdown, a final snapshot for zero data loss, promotion on the secondary, VMs recreated there.
• Unplanned failover — no graceful shutdown (the primary may be gone), promotes the most recent available recovery point.
• Test failover — clones a recovery point, boots isolated test-prefixed VMs on a separate network, leaves production completely untouched. This is the non-disruptive DR test every auditor asks for, and it works the same way SRM's test failover does.
• Failback — reverses replication direction, syncs what accumulated during the failover window, and returns workloads home.
• Boot order — an integer per VM that controls startup sequencing, so your database tier is ACTIVE before your app tier tries to connect. This is a direct analog to SRM's VM priority groups.
• Recovery point selection — every replicated snapshot is a selectable recovery point. During failover or test failover, you choose which point to recover to — not just the latest. If ransomware hit six hours ago, you target the snapshot before the attack.

Cross-site operations authenticate through Keystone Trusts — a scoped, revocable delegation rather than a shared credential or a stored password — so the engine can act on your behalf on the remote site without your team handing out standing access. Everything above is available through the REST API, the openstack dr CLI, and a Horizon dashboard panel, so it's genuinely self-service rather than "file a ticket with the storage team."

The Replication Engine Underneath: Get This Part Right

This is where a lot of vendor content (and, frankly, some AI-generated documentation making the rounds right now) gets sloppy, so it's worth being precise. The two modes have different guarantees:

Recovery point selection also deserves a mention because it's easy to undervalue until you need it: you're not forced to fail over to the latest copy. If ransomware hit six hours ago, you target the recovery point before the attack — during a real failover or during a test failover, so you can confirm a point-in-time copy is actually clean before you commit to it.

Why This Matters Beyond DR: The Sovereignty Angle

Disaster recovery architecture and digital sovereignty architecture are more entangled than most DR conversations acknowledge, and that's becoming a board-level topic in the EU well before it's a boardroom topic anywhere else. The EU's proposed Cloud and AI Development Act (CADA) is explicit that sovereignty scope isn't just about where your primary data sits — it extends to metadata and telemetry too. A DR architecture that quietly ships replication metadata, health telemetry, or control-plane state to infrastructure outside your control creates exposure you didn't sign up for, even if your production data itself never leaves the jurisdiction you intended.

Looking at how this Trilio-on-Everpure architecture actually behaves against the four questions that matter for sovereignty:

None of this makes the platform automatically "CADA-compliant" — that's a legal and organizational determination, not an architecture checkbox, and the regulation itself is still moving toward its targeted 2027 adoption window. But it does mean the underlying architecture gives you something to point to when a regulator, auditor, or customer asks how failover and replication metadata are handled, instead of asking you to take a vendor's word for it. That's the distinction worth sitting with: provable control versus asserted compliance, and it applies to DR architecture just as much as it applies to where your primary workloads run.

Where This Leaves VMware Teams Evaluating OpenStack

If disaster recovery has been the quiet blocker in your migration plan, it's worth revisiting what's already sitting in your storage layer. Everpure FlashArray plus Trilio Site Recovery isn't a like-for-like port of SRM — the abstractions are different, and ActiveCluster-level synchronous replication genuinely isn't here yet — but the tenant-facing self-service model, the crash-consistent protection groups, and the non-disruptive test failover cover the ground that actually matters for most DR runbooks. And for teams that also have a sovereignty conversation running in parallel with their migration, the architecture happens to answer both questions with the same set of controls.