Two customers can recover into the same AHV cluster, both keep a server at 10.20.0.20, and remain isolated. The problem starts when a branch, an administrator, or a dependency outside those isolated networks needs to reach the right server. Somewhere, a router has to distinguish the two customers. A firewall has to permit the session, and the reply has to return through the expected path.
A successful VM restore proves little about those connections. The production firewall might be offline. DNS might still point to the failed site. The recovered application might start normally while its authentication server, payment interface, or database remains unreachable. For a service provider, these are onboarding and service design decisions that need to be settled before a customer declares a disaster.
I would build a Nutanix recovery service around an explicit network design for each tenant: where the customer connects, which routing context carries the traffic, where the default gateway lives during recovery, which dependencies survive, and who can change each part. The examples below describe a proposed service that still needs laboratory and deployment validation.
Give each control plane a defined job
The earlier SP Central 1.0 article explains tenancy, domains, projects, and delegated operations. The relevant point here is that the tenant's resource scope and the tenant's packet path are different things. Nutanix's Projects engineering explanation describes a domain as a Prism Central instance and places tenant resources within projects. That relationship tells an operator which resources a tenant can administer; the network configuration determines where their traffic goes.
Nutanix's tenant model includes native recovery capabilities. Its NCI 7.6 disaster recovery notes describe tenant management of recovery points, backup, and restore within projects. The compatible SP Central and infrastructure release set still needs confirmation. Those native capabilities do not establish a Veeam integration, an AHV workflow for every Cloud Connect operation, or automatic changes to a customer's WAN, DNS, and firewall.
| Component | Role in this proposed service | What needs separate ownership |
|---|---|---|
| SP Central and Nutanix Central | Tenant access, domain placement, and the delegated service experience | The service's supported recovery actions and authority to declare a disaster |
| Prism Central and AHV/AOS | Project and infrastructure configuration; execution and storage of recovered workloads | Capacity reservations, platform recovery, and correct placement by the chosen recovery tool |
| Flow and provider network infrastructure | VPCs, subnets, routing, translation, and the selected security controls | External routing contexts, customer handoffs, firewall rules, and return paths |
| Protection and recovery software | Recovery points, data movement, VM recovery, and its documented completion workflow | Application sequencing, customer access, and return to the original production site |
Flow Virtual Networking and Flow Network Security deserve separate entries in the design. The former provides the virtual networking constructs; the latter provides stateful distributed firewall capabilities. The current NCI licensing table puts overlay networking in Pro, while microsegmentation and advanced orchestration have different edition or add-on requirements. DR sites are separately licensed. I would have the provider agreement identify the actual SP Central, networking, security, and DR entitlements rather than accept a single line saying "Flow included."
Separate management and recovery infrastructure is a reasonable starting direction. A sketch with three management nodes and three recovery nodes is still a sketch. It says nothing yet about management VM sizing, failure reserve, simultaneous tenant declarations, repository performance, or how much capacity remains during migration out of Instant Recovery.
Choose the recovery path before designing around it
For the Veeam discussion, the verified release pair is Veeam Backup & Replication 13.1.2, build 13.1.2.57, and Veeam Plug-in for Nutanix AHV 10.1, build 13.10.1.4. Veeam records the plug-in pairing in its AHV build history. The final Nutanix build set still has to satisfy both Nutanix interoperability and Veeam's AHV platform requirements. These versions identify the documentation used here. The combined configuration requires separate qualification.
For a provider-operated AHV recovery offering, I would first qualify a provider-managed VBR recovery environment using an ordinary supported repository and registered AHV recovery infrastructure. The qualification must prove repository ownership, credentials, backup access, tenant placement, and recovery permissions. A working restore with unrestricted platform credentials would leave the tenant service design largely untested.
Cloud Connect requires more care because several different operations can sound like the same service:
| Workflow | Documented scope | Consequence for provider AHV recovery |
|---|---|---|
| AHV backup copied to a cloud repository | VBR-managed backup copy is available; a direct AHV VM backup job cannot target Cloud Connect | Provider possession of a backup does not identify the supported recovery initiator or target |
| Tenant-side Instant Recovery to AHV | The Cloud Connect guide describes recovery to an AHV cluster in the tenant's virtual infrastructure | The tenant's recovery control plane and required AHV connections must survive the outage |
| Provider-side Instant Recovery from tenant backups | The documented targets are VMware vSphere and Microsoft Hyper-V | This workflow cannot be sold as provider-initiated AHV Instant Recovery |
These distinctions come from the AHV limitations, the tenant AHV recovery procedure, and the separate provider recovery procedure. Combining their feature names does not create another supported workflow. A tenant-controlled backup server hosted away from production may address control-plane survivability, but it does not prove safe access to shared provider AHV infrastructure through SP Central.
Existing Zerto infrastructure is not evidence of a supported AHV-to-AHV path. I could not establish that pairing from the accessible current primary documentation, so Zerto is outside the selected recovery path until the exact release, endpoints, and failback workflow are confirmed against the vendor interoperability matrix. Likewise, Veeam Universal CDP's documented target infrastructure uses vCenter and a VMware I/O filter; broad source support does not supply an AHV destination.
Licensing follows the actual deployment model. Veeam's service-provider licensing guidance distinguishes the provider Cloud Connect server from provider-managed tenant backup servers. Confirm that model while choosing the recovery path, including who controls encrypted backup access. An existing license or a portal entitlement does not expand a product's supported restore targets.
Connect the customer from somewhere that survives
A site-to-site VPN between the customer's datacenter and the provider is useful while both ends are alive. If the disaster removes the customer's firewall, internet circuit, or power, that tunnel cannot also be the only way users reach recovery. Start the design with the locations that will still exist: surviving branches, remote staff, a secondary customer site, and the provider's administrative access.
Transport and recovery addressing are separate choices. An IPsec tunnel can carry a newly numbered recovery subnet or a preserved production prefix. A private circuit can carry an unsafe shared routing table just as easily as a properly isolated tenant handoff. SD-WAN can steer surviving branches toward the provider, but its controllers, identity dependencies, and edge devices need their own failure analysis.
| Connection | Prerequisites and ownership | What to prove during site loss |
|---|---|---|
| Site-to-site IPsec | Agreed peer configuration, reachable endpoints, tenant-specific policy, and ownership of routes on both sides | A surviving branch or alternate endpoint can connect without traversing the failed datacenter |
| Private WAN | Carrier handoff, tenant routing context, prefix filters, diversity, and customer/provider change ownership | The circuit's effective path and routing do not depend on the lost site; required encryption is provided separately |
| SD-WAN | An operated overlay with provider connectivity, route policy, segmentation, and supported edge capacity | Branches select the recovery path when the datacenter is unavailable, including underlay failover |
| Emergency user access | A prebuilt remote-access VPN, application access service, or other approved entry point with surviving authentication | Users can authenticate and reach only their permitted tenant applications from an independent connection |
Flow Virtual Networking also offers gateway options, including site-to-site VPN, as described in the Nutanix Cloud Bible's networking chapter. That chapter is explicitly based on PC 7.5 and AOS 7.5. Whether a Flow gateway or a provider firewall terminates the customer connection should follow the exact supported release, peer interoperability, tenant permissions, high availability, and the provider's operational model. SP Central should not be assumed to configure the remote customer device.
For an initial service, I would favor routed connectivity through a provider-operated tenant edge, with prebuilt policy and an independent user access option. Native Flow VPN can be a qualified alternative. I would avoid making emergency routing depend on someone constructing a new tunnel during an incident, finding a certificate on a lost server, or obtaining MFA from an unavailable identity service.
Test useful traffic over the connection. A small ping can succeed while a larger application exchange stalls after encapsulation. Cisco's MTU and IPsec guidance explains why tunnel overhead, fragmentation, and path MTU discovery need attention. Use the actual transport and firewall design to determine MTU and TCP MSS behavior. I would determine the values for each tenant connection.
Keep tenant context all the way to the return route
Flow VPCs give customers separate logical networks on shared infrastructure. Two customers can therefore use the same private subnet inside different VPCs. The external design must preserve that separation through its routing and security devices. Exporting two identical prefixes into one ordinary routing table loses the customer context needed to select a destination.
Consider Tenant A and Tenant B, each recovering 10.20.0.0/24. In this illustrative design, those duplicate addresses stay private inside separate VPCs with NAT external connectivity. Clients reach unique external addresses through the provider's tenant routing and security controls; the selected translation maps each address to the correct private VM. Tenant A might publish 10.20.0.20 as 172.22.10.20 while Tenant B publishes its own 10.20.0.20 as 172.22.20.20. All addresses in this example are private and illustrative.
Do not replace that design with duplicate externally routable prefixes merely because the provider has separate VRFs. The pc.2024.1 FVN guide prohibits overlapping externally routable prefixes across VPCs in its documented no-NAT model. Any alternative using preserved routed prefixes needs qualification against the exact FVN and Prism Central scope, as well as the external routing design. A VRF cannot override a product configuration restriction.
NAT and firewall enforcement solve different problems. Outbound source NAT does not by itself publish an application for inbound users. A floating IP or firewall destination-NAT rule can provide a reachable address, but access still needs security policy and a valid return path. Record which device owns each translation, which address DNS returns, and where the session state lives. If the request enters through one stateful firewall and the reply exits through another without the necessary shared state, the application can fail even though each subnet has a route.
Project permissions are another control. A tenant may be unable to see another customer's VMs while a routing mistake still permits packets to reach them. Conversely, correct packet isolation does not prove the restored VM belongs to the correct tenant project. Test object ownership and network enforcement separately, including restore-created categories and the policy actually applied to the VM.
Keep provider administration, AHV/CVM infrastructure, storage traffic, and recovery data services outside broad tenant access. Expose only the endpoints and permissions needed for the selected operation. A tenant who can administer an application should not inherit access to the systems that administer every customer.
Address overlap can also affect recovery infrastructure outside the guest VPCs. Veeam's AHV limitations require a direct IP connection from the AHV server to the backup server and exclude NAT gateways on that connection. If customer infrastructure prefixes overlap, putting a single central backup server behind a collection of NAT rules is not a supported answer to that requirement. Qualify nonoverlapping infrastructure connectivity or separate recovery management contexts; tenant application NAT and recovery infrastructure reachability need different designs.
Decide what preserving the address actually means
Re-IP is often the easiest option to route because the recovery subnet is distinct from production. It can require changes to application bindings, allowlists, monitoring targets, and possibly certificates or licensing tied to an address. DNS updates help clients find the new endpoint, but they do not repair an application configuration containing an old literal IP. I would select re-IP only after checking the supported guest configuration method and the application's dependencies.
Preserving the VM address does not necessarily require Layer 2 extension. For a full-subnet recovery, an isolated provider subnet can use the original addressing while routing is moved toward recovery. That proposal depends on fencing the original workload, establishing a reachable provider-side gateway, controlling route withdrawal and advertisement, and preserving a valid return path. It becomes harder when part of the same subnet must remain active at production: hosts can try to reach a peer locally rather than send traffic toward the recovery router.
NAT publication is another choice. A recovered server can keep its private address while clients use a different reachable address. Applications that embed IPs, initiate callbacks, or depend on source identity need explicit tests. Use one documented translation boundary where practical; multiple unmanaged layers of NAT make packet captures, firewall logs, and failback harder to reconcile.
Layer 2 extension can preserve adjacency for selected workloads, but it carries the original subnet's failure dependencies across sites. Nutanix's mobility networking explanation describes gateway placement and asymmetric firewall paths during subnet extension. If the extended VM still relies on a default gateway at the dead production site, keeping its IP has not restored off-subnet access. The extension endpoints, gateway behavior, MTU, and split-site failure case need qualification as one design.
Do not equate a compatible IPsec peer with support for every Layer 2 extension workflow. The older, explicitly versioned Flow Virtual Networking guide for pc.2024.1 distinguishes third-party Layer 3 VPN connectivity from its Nutanix-to-Nutanix VPN subnet extension. That is a warning to check the exact current workflow, not a recommendation to deploy the old release.
For a new provider service, I would start with routed tenant networks and qualify re-IP or a fenced full-subnet route move per application. I would offer Layer 2 extension only when the application requires it and its gateway and failure behavior have been demonstrated. Temporary testing networks should remain isolated from production route advertisement, even when they contain the same addresses.
Boot into a usable application network
Before startup, establish the target tenant project, subnet, gateway, security policy, and the deliberate state of the VM's network connection. A restored NIC attached to a valid AHV subnet is not sufficient evidence of correct tenant ownership or policy. The Veeam recovery wizard offers network selection and a disconnected option, but that does not prove automatic mapping into an SP Central project or every Flow topology.
Recovery data traffic needs its own firewall matrix. Veeam's AHV connectivity and ports identifies worker, Prism, repository, and mount-server connections, including CVM access to the mount server during Instant Recovery. A customer application VPN does not replace those connections. Prove them with the source site unavailable and with the same service accounts, network rules, and repository arrangement intended for recovery.
Veeam's AHV Instant Recovery description explains that the VM initially reads from the published backup while changes are recorded in cluster-local redo logs. The repository and mount path remain in the running application's storage path until migration completes. Size and test live reads, new writes, and migration together, including concurrent recoveries. A fast first boot is not a useful capacity result if the repository stalls when users start working.
Then follow an actual user transaction. Resolve the application name using the client's intended DNS service, authenticate, reach the front end, open the database connection, and complete a representative operation. Check connections in both directions, including callbacks to systems outside recovery. A successful login to a VM console bypasses much of this path.
Identity needs the same attention. Microsoft's domain controller discovery guidance describes how DNS service records and client subnet information affect discovery. A recovered application can have a valid IP yet select an unavailable domain controller or be unable to reach its DNS resolver. Define the recovery order and access for DNS, AD, time, certificates, and any tenant identity provider, using the appropriate recovery procedures for those services.
Inventory hybrid dependencies individually. A branch database may survive while its route still points through headquarters. A SaaS application may reject the provider's outbound public IP. A license server may be missing, or a callback endpoint may still resolve to production. Record the dependency, owner, required traffic, outage behavior, and the recovery decision. If a required service cannot be recovered or reached, document the reduced application capability before offering an RTO.
Delegate operations that have been proved
I would begin with provider-controlled recovery execution and a defined customer declaration and acceptance process. The customer identifies the authorized recovery point and business priorities, approves the cutover, and validates the application. The provider operates the shared infrastructure and performs the network and recovery actions assigned to it. Customer-managed DNS, WAN, or security changes still need named owners and a reachable incident contact.
| Operation | Reasonable initial owner | Condition for tenant delegation |
|---|---|---|
| Declare recovery and approve application availability | Customer, coordinated with provider | Authorized identity and an approval path that survives the outage |
| Operate assigned VMs and inspect their status | Tenant within documented project permissions | Restored ownership, visibility, and permissions verified with the tenant role |
| Initiate a particular recovery workflow | Provider initially; native tenant actions where documented | Exact product, initiator, licensing, and tenant scope tested end to end |
| Change shared edge routing, external networks, or infrastructure access | Provider | Delegation only within bounded controls that cannot affect other tenants |
| Change application DNS, customer routes, and external allowlists | Named customer or provider owner | The runbook records authority, credentials, dependencies, and reversal |
An API can make these steps repeatable after the underlying actions are supported and understood. It cannot supply missing permissions or turn an unsupported source-to-target path into a supported one. A self-service button should invoke a tested sequence with audit records, duplicate-request handling, failure reporting, and a safe place to stop. Tenant-managed recovery points are not proof that the entire application cutover can be delegated.
Provider access also needs to survive a tenant identity failure. Maintain a controlled administrative recovery path with appropriate authentication, audit, and limited access. Test it without relying on the customer VPN or customer directory. Otherwise the provider can have healthy recovery infrastructure and still be unable to operate it when the incident starts.
Design the return while choosing the failover network
Veeam's action named Migrate to production completes Instant Recovery by moving VM data into the selected destination storage. If that storage is at the provider, the customer application is still running at the provider. Returning it to the customer's site requires a separate, supported data movement and application cutover procedure.
The recovery copy becomes the active writer once users resume work. Before failback, determine how those changes return, how long synchronization will take over the available connection, and when writes must pause for final consistency. Retain a clear rollback point. Starting the original VM from an older disk and changing DNS back can discard the work performed during recovery or create two independent writers.
Re-IP requires reversing application configuration as well as DNS. Preserved-address recovery requires withdrawing the provider route and restoring the intended production route and gateway without leaving duplicate active instances. NAT publication requires updating or retiring the published mapping, plus any outbound allowlists. Layer 2 extension requires a controlled removal of the extension and a check that the remaining gateway and firewall paths are correct.
DNS changes also have a transition period. Check effective client and resolver caching, active application sessions, and which endpoint remains writable while clients move. Coordinate public DNS, internal DNS, load balancers, firewall rules, routes, and application startup with the same cutover owner. Do not remove the recovery path merely because one workstation has resolved the new address.
Acceptance tests I would require before selling it
The acceptance record should capture the exact versions, recovery point, initiator, tenant role, network mapping, traffic evidence, timings, and application result. Keep observed results separate from the intended design. I would require at least the following tests before assigning a service commitment:
- Whole-site loss. Remove the customer's production site from the test path. Recovery initiation, backup access, provider administration, DNS, identity, and user entry must work from their surviving locations. Record any step that still waits on production.
- Overlapping tenants. Recover two synthetic tenants with the same private subnet. Prove each authorized client reaches its own application and receives the reply. Attempt cross-tenant traffic and access to provider management from both sides; expected denials need evidence too.
- Placement and policy. Use the real recovery tool and intended account to restore into the correct project and network. Check tenant visibility, categories, effective security policy, and a negative attempt to select another tenant's resources. Repeat after a relevant product upgrade.
- Application recovery. Complete representative transactions from a surviving branch and the emergency access path. Include DNS, AD or the relevant identity service, outbound allowlists, callbacks, and dependencies that remain outside the recovery site.
- Degraded connectivity. Fail an edge or tunnel and impose representative loss or reduced bandwidth. Test large application transfers as well as small probes, then record reconvergence, session impact, and the supported operating limit.
- Concurrent recovery and migration. Start the contracted simultaneous recovery set while measuring repository reads, AHV write growth, network use, and application response. Complete Instant Recovery migration without losing the required service behavior. Reserve capacity from that result, not from tenant portal quotas.
- Failback and rollback. Synchronize new data, execute the approved write pause and network cutover, and verify transactions at production. Prove route, DNS, firewall, NAT, and monitoring restoration. Exercise the agreed rollback decision before deleting recovery resources.
I would use those results to define which application sets the service can recover, through which connectivity options, and with what measured limits. Customers with untested dependencies or unsupported recovery paths would need additional qualification before receiving the same commitment. The usable service is the specific combination of recovery data, tenant network, surviving access, and operating procedure that passed those tests.
Source Notes
Sources were checked on November 3, 2026. Product behavior above is drawn from the linked primary documentation; design choices and acceptance tests are the author's recommendations. No deployment, failover, performance result, or failback test is claimed.
Veeam claims use the 13.1.2.57 documentation and the AHV 10.1 build record. Nutanix tenant recovery statements use the NCI 7.6 engineering notes. Networking mechanisms use the explicitly scoped PC 7.5/AOS 7.5 technical reference and, where identified, the older pc.2024.1 manual. The exact SP Central 1.0 deployment interoperability set and provider contract entitlements remain qualification items; this article does not publish an approved bill of materials. The accompanying feature and responsibility matrix records those limits, including the unverified Zerto AHV pairing and shared-provider integration details.