Part 1: Azure Migrate: Configure Agentless Migration & Assessment VMware VMs to Microsoft Azure V2
Part 2: Azure Migrate: Configure Hyper-V Agentless Migration & Assessment VMs to Microsoft Azure V2
Introduction
Lifting and shifting workloads to the cloud is not that hard given that certain requirements and prerequisites are taken into consideration during planning and assessment of such migration. The hard part of any cloud migration is mapping on-premises workloads to the appropriate cloud services that being IaaS, SaaS, PaaS, XaaS, and … taking into consideration performance, usability, availability, sizing, pricing, and so on.
The new Azure Migrate service allows for agentless assessment and migration of Microsoft Hyper-V virtual machines to Microsoft Azure IaaS. This practically means lifting and shifting VMs to be hosted on Azure as Infrastructure as a Service machines. To successfully pull this off, there needs to be appropriate planning specifically around network, authentication, storage, and workload types.
Before lifting and shifting workloads to Microsoft Azure, consider first how networking will work. Are you going to replicate the same networking subnets on your on-premises physical network to Microsoft Azure and thus make sure that all migrated workloads will have the same IP scheme or is part of your migration to abide by a new cloud networking construct and if so, was the possibility of changing the IP addresses of migrated virtual machines verified without impact to installed applications.
Another consideration is the availability of domain controllers on the cloud available to serve migrated virtual machines already domain joined without effecting workloads functionality. Normally new domain controllers are build on the cloud connected through an S2S or P2S VPN with on-premises DC for replication ( can be permanent or scheduled ). A new forest can be built for the cloud as well or if going to use Azure AD Domain Services ( no migration supported from on-premises DC ) thus the possibility of joining VMs to new domain without applications being effected need to be verified and taken into consideration.
More so, make sure that based on the conducted assessment through Azure Migration Service the type of proposed VM type (Size) is correctly assigned to avoid any performance issues, increased pricing and/or reduced availability. Microsoft Azure has different type of VM instances and sizes under different pricing/availability schemes that need to be considered and tested.
Last but not least, connectivity is a very big part of migrating workloads to the public cloud because user connectivity needs to be highly considered. Users connect to workloads using an L2 network hosted normally in the same site are now going to traverse multiple networks to reach their business applications. Is VPN going to be used or direct public access to every workloads or ExpressRoute, this needs to be highly considered taking into consideration latency and bandwidth requirements for migrated workloads.
That been said, the approach of lifting and shifting workloads to the cloud is the easy path and it is my believe that it should not be taken often. The migration to the cloud should form an opportunity for a complete re-architecture of any IT environment which would lead to mapping on-premises VM workloads to different types of cloud services such as AD to Azure AD Domain Service , web applications to Azure Web Apps, ADC/LB to Azure application gateways, SQL to Managed or hosted SQL service , and so on … The new architecture leverages cloud services as per a true workload and services assessment that would eventually lead to reduced cost, enhanced performance, and better availability.
The purpose of this post is to show how easy it is technically to migrate workloads from any on-premises Microsoft Hyper-V environment to Microsoft Azure using the new Azure Migrate Service. Remember the hard part of the lift and shift is determining the previously discussed prerequisites and requirements of the same. The new Azure Migrate service labeled v2 has two parts, first being Assessment and second being Migration both of which are supported natively or through 3rd party ISVs (paid). Microsoft documentation covers both functionality options extensively so make sure to check it out at https://docs.microsoft.com/en-us/azure/migrate/migrate-services-overview .
Requirements
To review the full list of requirements for using the Azure Migrate service with Hyper-V, make sure to visit the https://docs.microsoft.com/en-us/azure/migrate/migrate-support-matrix-hyper-v . Here are some points I faced during couple of engagements.
-
The geography of the migration service is limited but this is only for storing metadata received from assessment such as VM name, sizing, … The actual migration of any VM will be to a location you specify later on that can be different from the migration service chosen geography location.
-
I was able to assess and migrate virtual machines hosted on Hyper-V 2019 and having a Server 2019 OS although it seems to be stated that it is not supported.
-
Hyper-V servers managed by SCVMM are not supported for migration but might actually work just don’t rely on Microsoft support incase any issue arises.
-
The Unified Azure Migration Service appliance for Hyper-V can be domain joined and any internal policy applied as long as its requirements are met. The appliance will default to 8 vCPU and 16GB Memory but can be changed according to the number of VMs to be assessed and migrated. It can be deploy one the same Hyper-V server or different Hyper-V server/cluster.
-
Hyper-V hosts need to have the following access to Azure.
Configuration
Step 1: Create an Azure Migrate Service project.
Because I had another project previously created for a VMware environment, navigate to Servers and click on the upper right change beside Migrate Project then click on “Click Here”.
Choose the resource group that the migration project will be created in and then choose the geography that the Azure Migrate metadata will be stored in. Choose Azure Migrate Appliance for both assessments and migration.
After the project is created, click on Discover in order to download the Azure Migrate appliance for Hyper-V.
Step 2: Import the download appliance into Hyper-V and configure the appliance to connect to your Azure migration project.
Right click on the Hyper-V server and click on Import Virtual Machine or just use the right toolbar for the same. Don’t worry about resources error when importing the appliance since it defaults to 8 vCPU and my nested lab doesn’t have enough resources, as I only have one virtual machine to migrate which is named SQL.
Feel free to add the virtual appliance to your domain and apply any other setting such as AV or otherwise as long its prerequisites is still met. Open the shortcut on desktop to configure the appliance settings.
Choose the name of the created Azure Migrate project.
Add the Hyper-V host and/or cluster that VMs will be migrated from to Microsoft Azure and click on Validate.
It will take a minimum of 15 minutes for servers to be populated inside the Azure Migrate project. It is recommended that one waits at least one week before creating an assessment to get the right VM data.
Step 3: Create an assessment for the VMs planned to be migrated including agents for discovery of dependencies.
Here we create an assessment of virtual machines that can be grouped by different criteria. Here I assess a single VM named “SQL” , first I want the assessment data to be accurate based on which region I will migrate this workload later so price and available type of VM will be accurate ( note here that UAE North region is new so it didn’t show in the Azure Migrate assessment properties but is available during migration ). Refresh the migration service so that the created assessment appears in the dialog.
Complex workloads have lots of dependencies that are required to be migrated and operational before any migrated application may function properly such as application servers connected to DB servers. In order to discover these dependencies, an OMS workspace must be created on Azure and two agents configured on the assessed VMs. Give it 15 minutes for data to populate after both agents are installed.
Step 4: Now that VMs have been assessed and the cost/type of VM to be assigned when migrated is agreed upon and confirmed. Time to move to the actual migration of the virtual machine. First we Discover VMs for migration.
Download the replication provider agent to be installed on all hyper-v servers that VMs will be migrated from on top of download the vault key which be used during configuration of the agent on Hyper-V servers.
Time to replicate the machines discovered on the added Hyper-V servers. First make sure that you have a storage accounts available to host the migrated VMs disks, of course premium is always recommended.Two options are available, either use the assessment recommendations for the size/type of the migrated VMs or specify the same manually.
Testing the replicated VM allows us to fully test the workload to ensure that the migrated application is functioning properly before committing the migration of the VM to the live production environment. Cleanup the migration test when completed.
Now to do the actual live migration. The source VM on the hyper-V server will be stopped and a final sync will be conducted so that no data is lost during the cutover. Another option is available to keep the VM on-premises up but during the cutover definitely a small set of data would be lost ( the change during the cutover ).
After the migrated workload is turned, tested, and validated, the VM can be removed from the migration project ( no effect on the migrated VM or on-premises VM ).
Conclusion
Lifting and shifting workloads from Hyper-V to Azure is now technically very easy to do but the challenge lies in making sure the dependencies are taken care of and all discussed architectural decisions are taken and acted upon before the migration of any production workloads.