| title | description | ms.date | ms.topic | ms.service | ms.author | author | ms.custom |
|---|---|---|---|---|---|---|---|
Common questions about VMware disaster recovery with Azure Site Recovery |
Get answers to common questions about disaster recovery of on-premises VMware VMs to Azure by using Azure Site Recovery. |
07/10/2024 |
faq |
azure-site-recovery |
ankitadutta |
ankitaduttaMSFT |
engagement-fy23 |
This article answers common questions that might come up when you deploy disaster recovery of on-premises VMware virtual machines (VMs) to Azure.
Note
You can now move your existing replicated items to modernized VMware disaster recovery experience. Learn more.
How do I use the classic experience in the Recovery Services vault rather than the modernized experience?
Moving to the classic experience in a newly created Recovery Services isn't possible as it will be deprecated in March 2026. All new Recovery Services vaults will be using the modernized experience.
All VMware VMs or Physical servers that are being replicated using the classic experience can be migrated to the modernized experience. Check the details here and follow the tutorial.
Learn about the components involved in disaster recovery of VMware VMs.
Yes. In addition to using Site Recovery to set up full disaster recovery for VMware VMs, you can also use Site Recovery to migrate on-premises VMware VMs to Azure. In this scenario, you replicate on-premises VMware VMs to Azure Storage. Then, you fail over from on-premises to Azure. After failover, your apps and workloads are available and running on Azure VMs. The process is like setting up full disaster recovery, except that in a migration you can't fail back from Azure.
If you're a subscription administrator, you have the replication permissions you need. If you're not an administrator, you need permissions to take these actions:
- Create an Azure VM in the resource group and virtual network you that you specify when you configure Site Recovery.
- Write to the selected storage account or managed disk based on your configuration.
Learn more about required permissions.
You can replicate any app or workload running on a VMware VM that meets the replication requirements.
- Site Recovery supports application-aware replication, so that apps can be failed over and failed back to an intelligent state.
- Site Recovery integrates with Microsoft applications such as SharePoint, Exchange, Dynamics, SQL Server, and Active Directory. It also works closely with leading vendors, including Oracle, SAP, IBM, and Red Hat.
Learn more about workload protection.
Yes, Microsoft Software Assurance customers can use Azure Hybrid Benefit to save on licensing costs for Windows Server machines that are migrated to Azure, or to use Azure for disaster recovery.
Site Recovery needs access to VMware servers to:
- Set up a VMware VM running the Site Recovery configuration server.
- Automatically discover VMs for replication.
- To replicate, a VMware VM must have the Site Recovery Mobility service installed and running. You can deploy the tool manually, or you can specify that Site Recovery do a push installation of the service when you enable replication for a VM.
- During replication, VMs communicate with Site Recovery as follows:
- VMs communicate with the configuration server on HTTPS port 443 for replication management.
- VMs send replication data to the process server on HTTPS port 9443. (This setting can be modified.)
- If you enable multi-VM consistency, VMs communicate with each other over port 20004.
No, Site Recovery doesn't intercept replicated data and doesn't have any information about what's running on your VMs. Replication data is exchanged between VMware hypervisors and Azure Storage. Site Recovery has no ability to intercept that data. Only the metadata needed to orchestrate replication and failover is sent to the Site Recovery service.
Site Recovery is certified for ISO 27001:2013 and 27018, HIPAA, and DPA. It's in the process of SOC2 and FedRAMP JAB assessments.
Use the pricing calculator to estimate costs while using Site Recovery.
For a detailed estimate of costs, run the deployment planner tool for VMware and use the cost estimation report.
Managed disks are charged slightly differently from storage accounts. Learn more about managed-disk pricing.
You'll typically see an increase in the transactions cost incurred on GPv2 storage accounts since Azure Site Recovery is transactions heavy. Read more to estimate the change.
Yes, you can purchase reserved Azure virtual machines in the disaster recovery region, and Site Recovery failover operations use them. No additional configuration is needed.
The installers are in the %ProgramData%\ASR\home\svsystems\pushinstallsvc\repository folder on the configuration server.
On each VM that you want to replicate, install the service by one of several methods:
- Push installation
- Manual installation from the UI or PowerShell
- Deployment by using a deployment tool such as Configuration Manager
Site Recovery replicates on-premises VMware VMs and physical servers to managed disks in Azure.
- The Site Recovery process server writes replication logs to a cache storage account in the target region.
- These logs are used to create recovery points on Azure-managed disks that have prefix of asrseeddisk.
- When failover occurs, the recovery point you select is used to create a new target managed disk. This managed disk is attached to the VM in Azure.
- VMs that were previously replicated to a storage account (before March 2019) aren't affected.
No. Beginning in March 2019, in the Azure portal, you can replicate only to Azure managed disks.
Replication of new VMs to a storage account is available only by using PowerShell (Az.RecoveryServices module version 1.4.5) or the REST API (version 2018-01-10 or 2016-08-10). Learn how to set up replication using the PowerShell commands.
Learn how Site Recovery simplifies disaster recovery with managed disks.
Yes, you can easily change the type of managed disk for ongoing replications. Before changing the type, ensure that no shared access signature URL is generated on the managed disk:
- Go to the Managed Disk resource on the Azure portal and check whether you have a shared access signature URL banner on the Overview blade.
- If the banner is present, select it to cancel the ongoing export.
- Change the type of the disk within the next few minutes. If you change the managed-disk type, wait for fresh recovery points to be generated by Azure Site Recovery.
- Use the new recovery points for any test failover or failover in the future.
No. Switching from managed to unmanaged isn't supported.
Learn more about support requirements for VMware VMs and physical servers.
Replication is continuous when replicating VMware VMs to Azure.
Extended or chained replication isn't supported. Request this feature in the feedback forum.
This capability has been recently to Site Recovery services. Update your Site Recovery infrastructure (configuration servers, scale-out process servers) and mobility agent to versions 9.36 or higher to get accurate details. Learn more on how to track the progress here.
Offline replication isn't supported. Request this feature in the feedback forum.
For every source disk, data is replicated to a managed disk in Azure. This disk has the prefix of asrseeddisk. It stores the copy of the source disk and all the recovery point snapshots.
Yes, you can exclude disks.
Does upgrading kernel firmware on a server protected by Azure Site Recovery for disaster recovery have any impact?
No, it won't have any impact on the ongoing replication because the server is already protected through Azure Site Recovery.
Dynamic disks can be replicated. The operating system disk must be a basic disk.
If I use replication groups for multi-VM consistency, can I add a new VM to an existing replication group?
Yes, you can add new VMs to an existing replication group when you enable replication for them. However:
- You can't add a VM to an existing replication group after replication has begun.
- You can't create a replication group for existing VMs.
For VMware replication to Azure, you can modify disk size of source VMs. If you want to add new disks, you must add the disk and reenable protection for the VM.
Refer to our guidance to migrate machines to a new vCenter
Can I replicate to a cache or target storage account that has a virtual network (with Azure Firewalls) configured on it?
No, Site Recovery doesn't support replication to Azure Storage on virtual networks.
Site Recovery generates crash-consistent recovery points every 5 minutes.
Switching Recovery Services vaults, when the replication is already ongoing, isn't supported. To do so, replication needs to be disabled and enabled again. Additionally, the mobility service agent, installed on the source machine, will need to be unconfigured so that it can be configured to a new vault. Use the below commands to perform the unregistration -
For Windows machines -
C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\UnifiedAgentConfigurator.exe /Unconfigure true
For Linux machines -
/usr/local/ASR/Vx/bin/UnifiedAgentConfigurator.sh -q -U true -c CSPrime
My version of the Mobility services agent or configuration server is old, and my upgrade failed. What do I do?
Site Recovery follows the N-4 support model. Learn more about how to upgrade from old versions.
Learn about new updates, and get rollup information.
A reboot is recommended but not mandatory for each upgrade. Learn more.
The configuration server runs the on-premises Site Recovery components, including:
- The configuration server itself. The server coordinates communications between on-premises components and Azure, and manages data replication.
- The process server, which acts as a replication gateway. This server:
- Receives replication data.
- Optimizes the data with caching, compression, and encryption.
- Sends the data to Azure Storage. The process server also does a push install of the Mobility Service on VMs and performs automatic discovery of on-premises VMware VMs.
- The master target server, which handles replication data during failback from Azure.
Learn more about the configuration server components and processes.
You need a single, highly available, on-premises VMware VM for the configuration server. For physical server disaster recovery, install the configuration server on a physical machine.
Review the prerequisites.
We recommend that you create the configuration server VM by using the latest version of the Open Virtualization Format (OVF) template. If you can't use the template (for example, if you don't have access to the VMware server), download the setup file from the portal and set up the configuration server.
No. To replicate to more than one region, you need a configuration server in each region.
Although it's possible, the Azure VM running the configuration server would need to communicate with your on-premises VMware infrastructure and VMs. This communication adds latency and impacts ongoing replication.
Learn how to update the configuration server.
- You can find the latest update information on the Azure updates page.
- You can download the latest version from the portal. Or, you can download the latest version of the configuration server directly from the Microsoft Download Center.
- If your version is more than four versions older than the current version, see the support statement for upgrade guidance.
We recommend taking regular scheduled backups of the configuration server.
- For successful failback, the VM being failed back must exist in the configuration server database.
- The configuration server must be running and in a connected state.
- Learn more about common configuration server management tasks.
Yes. Download MySQL and place it in the C:\Temp\ASRSetup folder. Then, install it manually. When you set up the configuration server VM and accept the terms, MySQL is listed as Already installed in Download and install.
Yes. Download the MySQL installer and place it in the C:\Temp\ASRSetup folder. When you set up the configuration server VM, accept the terms and select Download and install. The portal uses the installer that you added to install MySQL.
No. Use the VM only for the configuration server.
No. Set up a fresh configuration server to avoid registration issues.
No. After a vault is associated with the configuration server, it can't be changed. Learn about registering a configuration server with a different vault.
Can I use the same configuration server for disaster recovery of both VMware VMs and physical servers?
Yes, but note that physical machine can be failed back only to a VMware VM.
Learn how to download the passphrase.
In the Recovery Services vault, select Configuration Servers in Site Recovery Infrastructure > Manage. Then, in Servers, select Download registration key to download the vault credentials file.
Yes, a single configuration server can protect VMs across multiple vCenters. There isn't limit on how many vCenter instances can be added to the configuration server, however the limits for how many VMs a single configuration server can protect do apply.
Yes, Azure Site Recovery can protect VMs across different clusters.
By configuring more than one process server, the design provides flexibility to move protected machines from an unhealthy process server to working process server. Movement of a machine from one process server to another must be initiated explicitly/manually via the defined steps here: moving VMs between process servers.
We strongly recommend creating a process server in Azure for failback purposes, to avoid data transfer latencies. Additionally, in case you separated the source VMs network with the Azure facing network in the configuration server, it's essential to use the process server created in Azure for failback.
Yes, you can keep the IP address on failover. Ensure that you specify the target IP address in the Compute and Network settings for the VM before failover. Also, shut down machines at the time of failover to avoid IP address conflicts during failback.
Yes, you can change the type or size of the VM at any time before failover. In the portal, use the Compute and Network settings for the replicated VM.
For VMware to Azure, the oldest recovery point you can use is 15 days.
Crash-consistent recovery points are generated in every five minutes. App-consistent snapshots are generated based on the input frequency entered by you. Beyond two hours, pruning of recovery points may happen based on the retention period that you input. Following are the scenarios:
| Retention Period input | Pruning mechanism |
|---|---|
| 0 day | No recovery point saved. You can failover only to the latest point |
| 1 day | One recovery point saved per hour beyond the last two hours |
| 2 - 7 days | One recovery point saved per two hours beyond the last two hours |
| 8 - 15 days | One recovery point saved per two hours beyond last two hours for 7 days. Post that, one recovery point saved per four hours. App-consistent snapshots will also be pruned based on duration mentioned above even if you input lesser app-consistent snapshot frequency. |
Yes. For example, if you increase retention from 1 day to three days, Site Recovery saves recovery points for an extra two days. The added time incurs storage changes. Earlier, it was saving recovery points per hour for one day. Now, it's saving recovery points per two hours for three days. Refer pruning of recovery points. So more 12 recovery points are saved. As an example only, if a single recovery point had delta changes of 10 GB, with a per-GB cost of $0.16 per month, then additional charges would be $1.60 × 12 per month.
After failover, you can access Azure VMs over a secure internet connection, over a site-to-site VPN, or over Azure ExpressRoute. To connect, you must prepare several things. Learn more.
Azure is designed for resilience. Site Recovery is engineered for failover to a secondary Azure datacenter, as required by the Azure service-level agreement (SLA). When failover occurs, we make sure your metadata and vaults remain in the same geographic region that you chose for your vault.
Failover isn't automatic. You start a failover by making a single selection in the portal, or you can use PowerShell to trigger a failover.
Yes. If you failed over to Azure, you can fail back to a different location if the original one isn't available. Learn more.
When you fail back from Azure, data from Azure is copied back to your on-premises VM, and private access is required.
No. Azure Site Recovery cannot use On-demand capacity reservation unless it's Azure to Azure scenario.
The application license is based on UUID of VMware virtual machine. Is the UUID of a VMware virtual machine changed when it is failed over to Azure?
Yes, the UUID of the Azure virtual machine is different from the on-premises VMware virtual machine. However, most application vendors support transferring the license to a new UUID. If the application supports it, the customer can work with the vendor to transfer the license to the VM with the new UUID.
Yes. You can automate Site Recovery workflows by using the REST API, PowerShell, or the Azure SDK. Learn more.
Yes. Learn more.