VMware Live Recovery Is Now VCF Protection and Recovery: What Changed in VCF 9.1?

TL;DR

VMware Live Recovery has been renamed and integrated into VMware Cloud Foundation as VCF Protection and Recovery. The name describes a broader protection model, but it does not represent one universal backup product.

The practical model has several layers:

• vSAN Protection and Recovery provides local VM snapshot protection and operational recovery.
• Remote replication moves protected VM data to a separate recovery environment.
• Site Recovery Manager adds disaster recovery orchestration, recovery plans, testing, planned migration, failover, reprotection, and failback.
• VCF Automation can expose governed protection and disaster recovery functions to projects and tenants.
• Advanced Cyber Compliance adds isolated cyber recovery, clean-room workflows, malware validation, and security integrations.
• VCF Fleet Disaster Recovery addresses recovery of VCF management services and platform components rather than ordinary application workloads.

The most important design lesson is that these capabilities have different failure domains, dependencies, licenses, workflows, and operational owners. Calling all of them “Protection and Recovery” does not make them interchangeable.

Introduction

VMware disaster recovery terminology has changed several times over the last few releases.

Teams may still have Site Recovery Manager appliances, VMware Live Site Recovery documentation, VMware Live Recovery licensing, vSphere Replication services, vSAN Data Protection policies, and newer VCF Protection and Recovery interfaces in the same environment.

That creates more than a naming problem.

When every capability is described as protection or recovery, architects can accidentally combine several very different requirements:

• Reversing a failed operating system patch.
• Recovering a deleted virtual machine.
• Restarting an application at another site.
• Moving workloads during planned maintenance.
• Proving that a restore point is free of ransomware.
• Allowing a tenant administrator to initiate protection.
• Recovering the VCF management plane after losing a site.

Those scenarios do not require the same architecture.

VCF 9.1 brings these capabilities closer together through a common product family, a converged appliance model, vSAN integration, VCF Automation integration, and a broader platform-recovery story. The operating model, however, still depends on understanding where one protection layer ends and another begins.

This article builds that mental model.

The Core Mental Model: Protection and Recovery Is a Stack

The phrase VCF Protection and Recovery should be interpreted as a capability stack rather than as a single backup engine.

Each layer solves a different problem.

The first three layers form a familiar workload-protection progression:

1. Preserve a previous state locally.
2. maintain another copy in a separate location.
3. orchestrate how the workload is restarted.

VCF Automation changes who can consume those capabilities. Cyber recovery changes how restore points are trusted and validated. VCF Fleet Disaster Recovery changes what is being recovered, shifting the target from application workloads to the private-cloud management system itself.

The architecture becomes easier to understand once those dimensions are separated.

What Was Renamed in VCF 9.1

The primary change is that VMware Live Recovery has been renamed and integrated into VMware Cloud Foundation as VCF Protection and Recovery.

Related naming changes also matter.

This is why the phrase Site Recovery Manager 9.1 can be misleading.

SRM remains recognizable terminology for disaster recovery orchestration, and Broadcom documentation still uses Site Recovery Manager when describing recovery plans and licensing. The current 9.1 deployment artifact and documentation family, however, are VCF Protection and Recovery.

An accurate design document should record both the deployed terminology and the current platform terminology.

For example:

Legacy deployment:
VMware Live Site Recovery 9.0.x
Separate SRM and vSphere Replication services

Current product-family name:
VCF Protection and Recovery

VCF 9.1 target:
Unified Protection and Recovery appliance
Site Recovery Manager orchestration capability
Integrated replication and vSAN protection services

Do not mechanically replace every reference to SRM or vSphere Replication. Those names still describe real functions. Instead, stop using VMware Live Recovery as though it were one indivisible product.

Scope and Assumptions

This mental model assumes the following:

• The target release is VMware Cloud Foundation 9.1.
• Local snapshot protection uses vSAN Protection and Recovery on supported vSAN Express Storage Architecture environments.
• Remote protection uses a separate target environment with its own vCenter Server.
• Remote vSAN protection targets supported vSAN storage at the recovery location.
• Disaster recovery and cyber recovery entitlements are validated against the organization’s current Broadcom agreement.
• Application-level backup, database-native recovery, and third-party data protection may still be required.
• Recovery objectives are established by the business and application owners, not inferred from product defaults.
• Management-plane recovery is designed separately from normal workload recovery.

The article does not assume that every environment uses vSAN exclusively. VCF 9.1 can replicate protected workloads from supported vSAN, VMFS, and NFS source datastores to a supported vSAN recovery target.

It also does not assume that a local snapshot satisfies backup, regulatory retention, or cyber-recovery requirements.

Local Protection Is Operational Recovery

The first layer is vSAN Protection and Recovery, previously called vSAN Data Protection.

It uses native vSAN ESA snapshot capabilities to protect virtual machines locally. Administrators create protection groups, associate virtual machines with those groups, define snapshot schedules, and configure retention behavior.

VCF 9.1 adds several useful operational improvements:

• Hierarchical retention schedules using hourly, daily, weekly, and monthly retention tiers.
• Protection-group membership based on vSphere tags.
• Support for immutable snapshots when the protection policy requires them.
• Up to 200 protected snapshots per virtual machine when using the applicable vSAN Protection and Recovery interfaces.
• Restore, revert, and clone workflows for protected virtual machines.
• Recovery of virtual machines that have been removed from vCenter inventory.
• Consistent snapshot-recovery operations for supported VM Service virtual machines.

These capabilities are included with the relevant base VCF entitlement.

What Local Protection Is Good At

Local snapshots are appropriate for fast operational recovery scenarios such as:

• Reversing an unsuccessful operating system upgrade.
• Restoring a virtual machine after an accidental deletion.
• Recovering from a configuration change.
• Creating a temporary clone for testing or investigation.
• Returning a workload to a recent crash-consistent state.
• Maintaining short-term and tiered recovery points close to production.

Because the snapshots are integrated with the vSAN data path, they can provide efficient recovery without the traditional consolidation behavior associated with older redo-log snapshot designs.

What Local Protection Does Not Solve

Local snapshots remain within the local storage and administrative environment.

They do not automatically provide:

• Protection from the loss of the entire site.
• An independent copy on different storage media.
• An application-consistent recovery point.
• Multi-VM application consistency simply because several VMs share a protection group.
• Disaster recovery network mappings.
• Automated application boot sequencing.
• Clean-room malware analysis.
• Recovery of the VCF management plane.
• A complete three-copy, two-media, one-offsite protection strategy.

Snapshots created for a protection group are scheduled as a best-effort operation. They should not be treated as a distributed application-consistency mechanism.

Local protection is therefore best understood as operational recovery close to the workload.

It may augment a traditional backup platform, but it does not automatically replace one.

Remote Replication Changes the Failure Domain

The second layer is remote protection.

VCF 9.1 expands vSAN Protection and Recovery beyond the earlier vSAN-to-vSAN-only source model. Protected VMs can originate from supported:

• vSAN datastores.
• VMFS datastores.
• NFS datastores.

The target is a supported vSAN ESA recovery environment.

This enables fan-in designs in which multiple source clusters or storage platforms replicate protected workloads to a centralized recovery site.

This is a meaningful change for organizations that have mixed storage estates.

A recovery architecture no longer has to wait for every protected workload to be migrated to vSAN at the source. Existing VMFS and NFS workloads can participate in a VCF-oriented recovery design while the target is standardized on vSAN.

Replication Is Not Yet a Recovery Plan

Remote replication creates another usable copy of the workload data.

That changes the failure domain, but it does not answer several critical questions:

• Which VMs start first?
• Which networks should they use?
• Which IP addresses or DNS records must change?
• Which dependencies must be available before an application starts?
• What happens if only part of the application recovers?
• How is the workload tested without affecting production?
• How is protection reversed after failover?
• How does the organization return to the original site?

Those questions belong to the orchestration layer.

Remote replication without tested orchestration is protected data, not a complete disaster recovery capability.

Recovery Plans Provide Site Orchestration

Site Recovery Manager remains the orchestration function for conventional disaster recovery.

It groups protected workloads into recovery plans and coordinates the actions required to bring those workloads online at another site.

Depending on the design, a recovery plan can address:

• Protection-group selection.
• Recovery priority.
• Virtual machine start order.
• Network mappings.
• Resource mappings.
• Storage relationships.
• Recovery-plan testing.
• Planned migration.
• Disaster recovery.
• Reprotection.
• Failback.
• Manual validation points and operational procedures.

A recovery plan should represent an application or service-recovery sequence, not simply a collection of virtual machines owned by the same department.

Planned Migration and Disaster Recovery Are Different Modes

A planned migration assumes that both sites and the relevant management services are available.

The process can coordinate an orderly transition:

1. Synchronize the latest workload changes.
2. shut down or quiesce protected workloads at the source.
3. complete the final replication operation.
4. start the workloads at the destination.
5. validate service availability.
6. reprotect in the reverse direction when appropriate.

The objective is controlled movement with minimal or no unplanned data loss.

Disaster recovery assumes that normal coordination with the source may no longer be possible.

The source site may be:

• Unavailable.
• Partially available.
• Inaccessible.
• Operationally unsafe.
• Suffering from a storage, power, network, or facility failure.

The recovery process may have to use the most recent recoverable replica rather than a final synchronized state.

The same recovery plan may support both modes, but the decision authority and risk posture should be different.

A maintenance change should not require the same emergency approval path as a declared site disaster. Conversely, an incident commander should not be blocked by a workflow designed only for normal business-hours migration.

Disaster Recovery and Cyber Recovery Solve Different Problems

Conventional disaster recovery generally assumes that the replicated workload is trustworthy.

The source site may be offline, but the most recent viable replica is normally the preferred recovery point.

Cyber recovery cannot make that assumption.

During ransomware or destructive intrusion, the latest replica may contain:

• Encrypted files.
• Malicious persistence.
• Compromised credentials.
• Fileless malware.
• Unauthorized configuration changes.
• Dormant payloads.
• Corrupted application data.

The recovery objective changes from restart the application elsewhere to identify a trustworthy recovery point and prove that it can safely return to service.

VMware Advanced Cyber Compliance adds the cyber-recovery capabilities required for that process.

The Cyber-Recovery Workflow

VCF 9.1 supports customer-owned, on-premises isolated recovery environments through the Advanced Cyber Compliance service.

A representative workflow is:

The clean room is not just another recovery cluster.

It requires:

• Strong network isolation.
• Restricted administrative access.
• Separate identity and credential planning.
• Endpoint detection and response integration.
• Controlled ingress and egress.
• Restore-point investigation.
• Evidence collection.
• Security approval before production reconnection.
• Procedures for staging, recovery, reprotection, and return.

VCF 9.1 integrates EDR validation into the workflow and supports security integrations such as CrowdStrike Falcon alongside VMware capabilities.

The Operational Difference

Cyber recovery takes longer because it is solving an additional problem: determining what can be trusted.

That delay should be reflected in recovery-time planning. A conventional DR test does not establish a credible cyber-recovery time objective.

VCF Automation Adds a Consumption Layer

VCF Automation does not replace replication or recovery orchestration.

It adds the project, tenant, role, and self-service layer through which protection capabilities can be consumed.

VCF 9.1 introduces foundational multi-tenant disaster recovery support for supported VM Service workloads and VCF-to-VCF protection scenarios. The Protection and Recovery integration also allows authorized project roles to perform supported protection and replication operations.

This creates a useful separation of responsibilities.

Provider and Platform Responsibilities

The platform or service-provider team should retain responsibility for:

• Recovery-site architecture.
• Site pairing.
• Replication infrastructure.
• Recovery capacity.
• Storage design.
• Network reachability.
• Entitlement management.
• Service policies.
• Protection-class definitions.
• Recovery testing.
• Escalation and incident authority.

Project and Tenant Responsibilities

Authorized project users may be allowed to:

• Request a protected VM.
• Apply an approved protection class.
• Initiate supported replication operations.
• View protection status.
• Perform permitted recovery actions.
• Supply application-specific recovery information.
• Validate the recovered application.

The tenant should not need unrestricted administrative access to Site Recovery Manager or the recovery-site infrastructure.

VCF Automation provides an abstraction boundary:

Self-service should not mean uncontrolled recovery.

The service still needs:

• Capacity quotas.
• Protection tiers.
• Maximum retention policies.
• Role separation.
• Recovery approval rules.
• Cost allocation.
• Audit records.
• Tenant network mappings.
• Defined support boundaries.
• A process for recovering shared dependencies.

A tenant may own an application, but the platform team still owns the recovery service.

Workload Recovery Is Not VCF Management-Plane Recovery

A private cloud can successfully recover application VMs and still be operationally impaired if its management services are unavailable.

VCF management-plane recovery can include dependencies and components such as:

• VCF Management Services.
• SDDC Manager.
• vCenter Server.
• NSX management components.
• VCF Operations.
• Fleet-management services.
• VCF Automation.
• Identity Broker services.
• Certificate and password-management dependencies.
• License services.
• DNS and time services.
• Recovery automation and backup repositories.

The exact list depends on the deployed VCF topology and which services are hosted at the failed site.

Broadcom provides a separate VCF Fleet Disaster Recovery implementation and task library for recovering fleet components in another location. That workflow combines protection, backup restoration, component deployment, configuration repair, certificate handling, identity updates, validation, and reprotection.

This is not the same as placing every management VM into one ordinary application recovery plan.

Why the Management Plane Needs Its Own Runbook

Management services have circular dependencies.

For example:

• Recovery orchestration may depend on vCenter Server.
• vCenter recovery may depend on DNS and identity.
• VCF Automation recovery may depend on management services and certificates.
• Fleet services may need backup data restored into newly deployed components.
• License and identity services may have to be available before normal administration resumes.
• Network management may be required to make the recovery systems reachable.
• Recovery interfaces may be unavailable if they are hosted only at the failed site.

The management-plane recovery design therefore needs:

• A documented bootstrap sequence.
• Emergency administrative credentials.
• Offline copies of the runbook.
• Independent access to backups.
• Recovery-site DNS and IP planning.
• Certificate-replacement procedures.
• Identity and authorization recovery.
• A known-good recovery workstation or jump host.
• Clear boundaries between restored components and redeployed components.
• Validation of fleet and instance associations.
• A tested process for reprotection after recovery.

The key distinction is simple:

Workload recovery restores the services running on the private cloud. Management-plane recovery restores the systems required to operate the private cloud.

Both are necessary, but they should not be designed as one undifferentiated recovery plan.

Base VCF Capabilities and Advanced Dependencies

The Protection and Recovery name can make entitlement boundaries look less important than they are.

They remain important.

The reliable planning rule is:

• VCF alone: local operational protection.
• VCF plus SRM: local protection, remote replication, and disaster recovery orchestration.
• VCF plus Advanced Cyber Compliance: local protection, disaster recovery orchestration, and comprehensive cyber recovery.
• VCF Fleet Disaster Recovery: a platform-recovery architecture and runbook that may use several of the above capabilities but is not reduced to one license checkbox.

Commercial terms can change. Validate the applicable entitlement, metric, and support scope before finalizing the design.

Which Teams Own Each Layer

A successful design assigns ownership by capability rather than by product console.

These responsibilities can be combined in a smaller organization, but they should not be left undefined.

A common failure pattern is to make the virtualization team responsible for every recovery outcome because the workloads are virtual machines. The virtualization team may operate the recovery tools, but it cannot independently determine business priority, application integrity, security trust, or incident authority.

Use the Failure Scenario to Choose the Layer

The starting question should be what failed or became untrustworthy, not which protection product do we own.

Scenario: Failed Application Patch

A server patch causes the application to fail.

The source cluster and site are healthy. The application owner only needs a recent VM state.

Best-fit layer: Local snapshot recovery.

Remote site failover would introduce unnecessary network, identity, and operational complexity.

Scenario: Data Center Power Failure

The primary site is unavailable, but the replicated workload is trusted.

Best-fit layer: Site disaster recovery through a tested recovery plan.

The recovery plan should start shared services and application tiers in their validated order.

Scenario: Planned Facility Maintenance

Both sites are operational, and the organization wants to move services before shutting down infrastructure.

Best-fit layer: Planned migration.

The workflow should complete a final synchronization and orderly source shutdown before starting the destination workloads.

Scenario: Ransomware Investigation

The latest local snapshots and remote replicas may contain malicious changes.

Best-fit layer: Cyber recovery in an isolated recovery environment.

Selecting the newest restore point without malware validation could reproduce the compromise at the recovery site.

Scenario: Platform Tenant Requires DR

An internal development organization or service-provider tenant needs protected VM Service workloads but should not administer the recovery platform.

Best-fit layer: VCF Automation-backed protection with centrally managed policies and recovery infrastructure.

Scenario: Loss of VCF Management Services

Application clusters may still exist, but VCF Operations, Automation, fleet services, or other management components are unavailable.

Best-fit layer: VCF Fleet Disaster Recovery.

Application recovery plans alone will not reconstruct the private-cloud control plane.

Decision Criteria for a VCF 9.1 Protection Design

Before selecting protection services, answer the following questions.

What Failure Domain Must the Design Survive?

Distinguish among:

• Virtual machine failure.
• Application failure.
• Datastore failure.
• Cluster failure.
• vCenter failure.
• Management-domain failure.
• Site failure.
• Administrative compromise.
• Cyber compromise.
• Regional or organizational dependency failure.

A local snapshot can address the first two scenarios but cannot independently solve the others.

What Recovery Point Is Required?

Define separate targets for:

• Operational rollback.
• Site disaster recovery.
• Cyber recovery.
• Long-term retention.
• Management-plane recovery.

A one-hour local snapshot policy does not prove a one-hour cyber-recovery point. The most recent clean recovery point could be days older than the most recent snapshot.

Does the Application Need Consistency Beyond Crash-Consistent VMs?

Identify:

• Database-native backup requirements.
• Application quiescing.
• Multi-tier write ordering.
• Transaction-log recovery.
• External storage dependencies.
• Message queues.
• Identity providers.
• External APIs.
• Load balancers and DNS.

A protected VM is not automatically a recoverable business service.

Can the Recovery Copy Be Administered Independently?

Evaluate whether the target has separate:

• vCenter management.
• Administrative identities.
• Network controls.
• credentials.
• storage.
• monitoring.
• backup access.
• security tooling.

The more dependencies shared with production, the more likely a common failure or compromise can affect both sites.

Who Is Authorized to Start Recovery?

Define authority for:

• Local restore.
• Recovery-plan test.
• Planned migration.
• Disaster declaration.
• Forced recovery.
• Cyber restore-point approval.
• Tenant-initiated recovery.
• Management-plane failover.
• Reprotection and failback.

The person who can operate the interface may not be the person authorized to accept the business risk.

How Will Recovery Be Proven?

Each layer needs its own evidence:

• Snapshot restoration evidence.
• Replication RPO evidence.
• Recovery-plan test results.
• Application validation.
• Cyber scan and investigation results.
• Tenant action logs.
• Management-plane bootstrap tests.
• Reprotection status.
• Failback validation.

A successful power-on event is not sufficient proof of application or platform recovery.

Operational Practices That Matter More Than the Rename

The VCF 9.1 naming change is useful only if the operating model is updated with it.

Maintain a Protection-Service Catalog

Define clear service tiers such as:

Each tier should document its RPO, RTO, retention, ownership, dependencies, test frequency, entitlement, and cost.

Keep Backup and Snapshot Strategies Explicitly Connected

Do not remove an existing backup service merely because local snapshots are now easier to manage.

Document which system provides:

• Local operational rollback.
• Offsite copies.
• Different storage media.
• Long-term retention.
• Application-consistent recovery.
• File-level restore.
• Regulatory preservation.
• Cyber-vault or clean-room recovery.
• Management-component backups.

Some workloads may be adequately served by native protection. Others will require layered protection.

The decision should be based on recovery requirements, not the number of products the organization wants to eliminate.

Test Each Recovery Mode Separately

At minimum, test:

• Local snapshot restoration.
• Recovery-plan test execution.
• Planned migration.
• Unplanned site recovery.
• Reprotection.
• Failback.
• Cyber restore-point validation.
• Tenant-initiated workflows.
• VCF management-plane recovery.

A successful recovery-plan test does not prove cyber recovery, and a successful application failover does not prove VCF fleet recovery.

Monitor the Recovery Service, Not Just Replication

Operational dashboards should expose:

• Snapshot-policy compliance.
• Capacity consumption.
• Immutable snapshot status.
• Replication health.
• Achieved RPO.
• Stale or unprotected VMs.
• Protection-group membership.
• Recovery-plan test age.
• Last successful reprotection.
• Recovery-site capacity.
• Appliance and service health.
• Certificate expiry.
• Tenant actions.
• Clean-room readiness.
• Management backup status.

A green replication indicator can coexist with an unusable recovery plan.

Treat VCF 9.1 as an Appliance-Architecture Transition

VCF 9.1 deprecates the separate new deployment model for standalone SRM and vSphere Replication appliances in favor of the unified Protection and Recovery appliance.

Existing 9.0.x environments should not assume that upgrading vCenter Server and replacing product names in documentation completes the transition.

The upgrade plan should validate:

• The installed SRM or VMware Live Site Recovery version.
• The installed vSphere Replication version.
• Convergence prerequisites.
• Supported migration paths.
• Existing site pairings.
• Protection groups and recovery plans.
• Certificates.
• Service registrations.
• Licensing.
• Interoperability with the target vCenter release.
• Rollback and recovery options.

For very small deployments, a fresh Protection and Recovery appliance deployment may be practical. Environments with established protection groups and recovery plans require a more deliberate convergence and migration plan.

Keep Historical Names in the CMDB

Record at least:

This helps operators correlate design documents with support articles, logs, license keys, upgrade tools, user interfaces, and older runbooks.

Conclusion

VMware Live Recovery becoming VCF Protection and Recovery is more than a product rename, but it is not evidence that every recovery function has become one product.

VCF 9.1 presents a layered protection architecture.

Local vSAN snapshots support fast operational recovery. Remote replication creates a separate copy and changes the failure domain. Site Recovery Manager converts protected workloads into tested recovery plans. VCF Automation exposes governed services to projects and tenants. Advanced Cyber Compliance introduces isolated validation and cyber-recovery workflows. VCF Fleet Disaster Recovery addresses the separate problem of rebuilding the systems that operate the private cloud.

The architecture should therefore start with the failure scenario, recovery objective, trust model, and operating owner.

Do not ask whether a workload is “covered by Protection and Recovery.”

Ask:

• Which protection layer covers it?
• Which failure domain does that layer survive?
• Who can initiate recovery?
• Which dependencies must already exist?
• How is the result validated?
• Which entitlement enables the workflow?
• What happens when the management plane itself is unavailable?

That shared language is the real value of the VCF 9.1 protection model.

It allows application, infrastructure, storage, automation, security, continuity, and VCF platform teams to discuss recovery without pretending that a snapshot, a replica, a recovery plan, a clean room, and a management-plane rebuild are the same thing.

External References

• Broadcom TechDocs: Protection and Recovery 9.1 Release Notes
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/protection-and-recovery/9-1/release-notes/protection-and-recovery-91-release-notes.html
• Broadcom TechDocs: Protection and Recovery 9.1
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/protection-and-recovery/9-1.html
• Broadcom TechDocs: Using Protection and Recovery with VCF Automation
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/protection-and-recovery/9-1/multi-tenant-disaster-recovery-for-vcf-automation.html
• Broadcom TechDocs: VCF Fleet Disaster Recovery
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/fleet-management/vcf-fleet-disaster-recovery.html
• Broadcom Knowledge Base: VCF Protection and Recovery 9.1: Transition from Standalone SRM and VR 9.0.2
  Canonical URL: https://knowledge.broadcom.com/external/article/444864/vcf-protection-and-recovery-91-transitio.html
• VMware: vSAN FAQs
  Canonical URL: https://www.vmware.com/docs/vmw-vsan-faqs
• VMware: VMware Advanced Cyber Compliance Frequently Asked Questions
  Canonical URL: https://www.vmware.com/docs/291
• VMware Cloud Foundation Blog: VMware vSAN Protection and Recovery Enhancements for VCF 9.1
  Canonical URL: https://blogs.vmware.com/cloud-foundation/2026/05/14/vmware-vsan-protection-and-recovery-enhancements-for-vcf-9-1/
• VMware Cloud Foundation Blog: Continuous Compliance, Integrated Cyber Recovery and Enhanced Platform Security for VCF 9.1
  Canonical URL: https://blogs.vmware.com/cloud-foundation/2026/05/05/continuous-compliance-integrated-cyber-recovery-and-enhanced-platform-security-for-vcf-9-1/

The post VMware Live Recovery Is Now VCF Protection and Recovery: What Changed in VCF 9.1? appeared first on Digital Thought Disruption.