Azure Migrate: Configure Hyper-V Agentless Migration & Assessment VMs to Microsoft Azure V2

image

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.

image

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.

image

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 .

image

image

image

image

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.

    image

  • 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.

    image
    image
    image

  • 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.

    image

  • 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.

    image

  • Hyper-V hosts need to have the following access to Azure.

    image

Configuration

Step 1: Create an Azure Migrate Service project.

SNAG-0020

SNAG-0021

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”.

image

image

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.

SNAG-0024

SNAG-0025

SNAG-0026

SNAG-0027

After the project is created, click on Discover in order to download the Azure Migrate appliance for Hyper-V.

image

SNAG-0029

SNAG-0030

Step 2: Import the download appliance into Hyper-V and configure the appliance to connect to your Azure migration project.

SNAG-0003

SNAG-0004

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.

SNAG-0005

SNAG-0006

SNAG-0007

SNAG-0008

SNAG-0009

SNAG-0010

SNAG-0011

SNAG-0014

SNAG-0015

SNAG-0016

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.

SNAG-0018

SNAG-0031

SNAG-0034

SNAG-0035

SNAG-0036

SNAG-0038

Choose the name of the created Azure Migrate project.

SNAG-0039

SNAG-0040

SNAG-0042

SNAG-0043

Add the Hyper-V host and/or cluster that VMs will be migrated from to Microsoft Azure and click on Validate.

SNAG-0044

SNAG-0045

SNAG-0047

SNAG-0048

SNAG-0049

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.

image

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.

image

SNAG-0053

SNAG-0054

SNAG-0055

SNAG-0056

SNAG-0057

SNAG-0058

image

SNAG-0062

SNAG-0063

SNAG-0064

SNAG-0065

SNAG-0066

SNAG-0067

SNAG-0068

image

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.

SNAG-0070

SNAG-0071

SNAG-0072

SNAG-0074

SNAG-0075

SNAG-0076

SNAG-0077

SNAG-0078

SNAG-0079

SNAG-0080

image

SNAG-0082

SNAG-0083

SNAG-0085

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.

SNAG-0086

SNAG-0087

SNAG-0088

SNAG-0089

SNAG-0090

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.

SNAG-0092

SNAG-0093

SNAG-0094

SNAG-0095

SNAG-0097

SNAG-0098

SNAG-0099

SNAG-0121

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.

SNAG-0122

SNAG-0123

SNAG-0124

SNAG-0125

SNAG-0126

SNAG-0127

SNAG-0128

SNAG-0129

SNAG-0131

SNAG-0132

SNAG-0133

SNAG-0135

SNAG-0136

SNAG-0138

SNAG-0139

SNAG-0140

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.

SNAG-0141

SNAG-0142

SNAG-0143

SNAG-0144

SNAG-0146

SNAG-0147

SNAG-0149

SNAG-0150

SNAG-0152

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 ).

SNAG-0153

SNAG-0154

SNAG-0156

SNAG-0157

SNAG-0158

SNAG-0159

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 ).

SNAG-0161

SNAG-0161

SNAG-0162

SNAG-0164

SNAG-0165

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.

May the Peace, Mercy, and Blessing of God Be Upon You

Leave a Reply

Your email address will not be published. Required fields are marked *