Azure Site Recovery - VMWare to Azure best practises

This blogpost contains a couple of tips that will make migrating from VMWare to Azure with Azure Site Recovery a lot easier.

by | Jul 6, 2017 | Azure, Azure Site Recovery

Introduction

The last few weeks I was working on a big VMWare to Azure migration. In this migration I am migrating more than 100 VMs to Azure with Azure Site Recovery. In this blogpost I will give you some tips and solutions for issues I have encountered. Please note that this blogpost is not an end to end manual of migrating VMWare to Azure; it is a collection of tips.

Preparation

Tip 1: Make sure you are only planning to migrate compatible VMs
When migrating from VMWare to Azure, your preparation phase is really important. In this phase you identify VMs that are not compatible with Azure Site Recovery. To check if your VMs and VMWare setup is compatible; check the following links:

  • Supported VMWare versions: https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-support-matrix-to-azure#support-for-datacenter-management-servers
  • Requirements VMs (virtual hardware): https://docs.microsoft.com/nl-nl/azure/site-recovery/site-recovery-support-matrix-to-azure#failed-over-azure-vm-requirements
  • Requirements OS: https://docs.microsoft.com/nl-nl/azure/site-recovery/site-recovery-support-matrix-to-azure#failed-over-azure-vm-requirements

Most of errors in ASR occur when VMs are not compatible with ASR, so make sure your VMs are compatible.

Tip 2: Make sure you are not hitting any of the subscription limits
It is important to make sure that the quotas on your subscription and location are set correctly. If quotas are not set correctly; your migration will fail. By default Microsoft has set a couple of limits for Azure Subscriptions. Most quota limits can be raised by submitting a support ticket in the Azure Portal. Please check the following link for the quota’s and limits in Azure subscriptions: https://docs.microsoft.com/en-us/azure/azure-subscription-service-limits

Tip 3: Make sure all configured endpoints in your VMs are pointing to DNS aliases
When you are migrating multiple VMs to Azure, there is a big chance that those VMs are connecting to each other. For example; a webserver that hosts a web application that connects to a database server. Always make sure that the connection strings that are used for connections between VMs make use of a DNS alias. During the failover to Azure, VMs will get new IP addresses. If connection strings are setup with ip addresses in it; the connection between VMs will not work after the failover.  After a failover, your VMs will register their new IP address in the DNS server, and DNS aliases will work.

Setting up the Configuration Server

Tip 4: Chose the right architecture for the configuration server
When migrating from VMWare to Azure you need to have one or more configuration servers. Before setting up the configuration server, make sure you choose the right architecture for the configuration server.

  • Architecture Configuration Servers: https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-multi-tenant-support-vmware-using-csp#multi-tenant-environments

Tip 5: Stick to the manual when building the configuration server(s)
Also make sure to setup the configuration server in the right way. Microsoft has a very clear manual on setting up this configuration server. Follow the manual very carefully; if you do not follow every step in exact the way it is described; the configuration server will most likely not work.

  • Setting up the configuration server: https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-vmware-to-azure-manage-configuration-server

Enabling protection

 

Tip 6: Register additional service accounts for migration
When enabling protection in a mutli-domain environment, make sure you have setup a service account for the second domain on your configuration server. You can add additional service accounts in the management console of the configuration server. A shortcut to the management console of the configuration server is placed on the desktop of the user that has installed the configuration server. Also add additional accounts for the workgroup VMs that you are planning to migrate.

Tip 7: Limit the bandwidth for ASR when running other productional workloads on the same internet connection
I saw that ASR can use a lot of bandwidth. It easily uses 800Mbps. When you have productional applications running on the same internet connection; make sure to limit ASR. You can do this in the configuration server console, or by setting up quantity of service in your router/switch.

Creating Recovery Plans

Tip 8: Create Recovery Plans
Recovery plans are used to group machines and do a failover for those machines as set. When you are planning to do a large migration; group machines together that are related with each other. For example: make sure you’re whole SCOM environment is in a recovery plan. Also make sure that the order of VMs to failover is set correctly. In case of the SCOM example: make sure that de SQL database is migrated before the management servers are migrated.

Tip 9: You can add additional VMs to an existing recovery plan
What I found is that I often need to add an additional VM to a recovery plan. In fist case I could not find where to add additional machines to plan. You can do this by doing a right click on the failover group (first click the edit button on your recovery plan).

(Test) Failover

Tip 10: Create a temporary isolated VNET for test migrations
Before I do a test failover, I create a separate (isolated) VNET that is not connected with any other networks. In this network I can do the test failover without interfering with the production environment. During the testfailover I select this network as target network. When you are using multiple subnets in your production VNET, it is recommended to create subnets with the same name in your test VNET. When you do a test failover, ASR will look for subnets with the same name as configured for the protected item in your test VNET. doing this allows you to test your VMs with subnetting.

Tip 11: An intermediate step is sometimes required. Make sure you don’t hit quota limits of your subscription during this step
In some cases an intermediate step is required. During this step ASR is setting up a temporary VM. The OS disk of your protected VM will be attached to this VM and some operations (to make the VM compatible with Azure) are executed. Make sure that quotas on your Azure subscription are set wide enough for this temporary VMs. By default ASR uses the standard A-series VMs for the temporary VMs; if those are not available, an other series is dynamically selected. When the quota is hit in this intermediate step; you will encounter the following error:

Failover failed with ‘CoreCountSubscriptionQuotaReached’ Azure error message: ‘CreateVmRoleTaskV2 StartAction caught exception. FMErrorCode: UserErrorCoreCountSubscriptionQuotaReached, Message: OperationNotAllowed: Operation results in exceeding quota limits of Core. Maximum allowed: 10, Current in use: 10, Additional requested: 2.’.

A solution to solve this error is:

  • Raise quota’s on the subscription by submitting a support ticket to Microsoft. You will find an option in the Azure portal to do this.
  • The intermediate step is required in the following cases: https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-test-failover-to-azure#time-taken-for-failover – Make sure you’re VM is setup in a way that the intermedia step is not required.
Share This