IntroductionThe 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.
PreparationTip 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
Setting up the Configuration ServerTip 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
- Setting up the configuration server: https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-vmware-to-azure-manage-configuration-server
Enabling protectionTip 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 PlansTip 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) FailoverTip 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.