Azure Migrate: Configure Agentless Migration & Assessment VMware VMs to Microsoft Azure V2

azuremigratevmware

Introduction

Cloud technology, in all its models and iterations, has dominated the IT world and will continue to do so for years and years to come being the most sought after IT service of the coming decade. Despite Amazon AWS still sitting on the throne of public cloud computing IaaS service, Microsoft seems to have gained significant ground in the past two years and is expected to beat AWS in the coming years becoming the dominant public cloud computing vendor.

IaaS, being the fastest-growing sector of public cloud computing, is all about hosting services on the cloud by means of either deploying new workloads or migrate existing on-premises workloads to the cloud. The reasons that most customers decide to migrate on-premises workloads rather than build new ones on the cloud are too many to list but think about cost, downtime, effort, skills, operations, and technical expertise to list a few. I have seen that 99% of customers wanting to move to the cloud quickly would always want to migrate by lifting and shifting all of their existing workloads as is and then take their time in planning on directing their DevOps efforts into building microservices and other cloud native design considerations.

This means that migrating on-premises workloads that being virtual machines and/or physical machines to the public cloud to be hosted as an IaaS service is a big part of any organization’s public cloud strategy. Public cloud computing vendors need to have a solid migration product/service/methodology in place that supports existing on-premises virtualization technologies in order to assess, migrate, validate, and optimize workloads lifted and shifted to the cloud in an easy and operable manner. Think of enterprises that have thousands of virtual machines with thousands of inter-dependencies between apps, web, database, network, security, and so on …

Azure Migrate v1

image

Microsoft Azure has had Migration services for some time now that assessed on-premises workloads and provided migration guidance in terms of suitability, sizing, and cost estimates for every workload. The service named Azure Migrate  was built to cover the biggest market of potential cloud customers that want to lift-and-shift their workloads without disrupting their services as of now by just hosting their machines on the cloud using an IaaS model.

image

The Azure Migrate service had two major limitation, it did not have native migration services so it could not, on its own, actually replicate and migrate virtual machines to Azure. The workaround was to use Azure Site Recovery which is a service originally built for BCDR between Azure to /from on-premises workloads, Azure to/from Azure workloads, and on-premises to/from on-premises workloads. The replication feature of ASR could be used to migrate workloads to Azure but required setting up difference service on Azure and different server on-premises and operating two dashboards. The second limitation was that Azure Migrate only supported VMware environments so Hyper-V and physical machines were out of the equation which represented a challenge for many customers that had to rely/pay 3rd party tools to do the same.

image

Azure Migrate v2

In an effort to streamline IaaS adoption and migration, Microsoft is currently previewing (Technical Preview) a new version of the Azure Migrate service that can do the following from a single console using a single product:

  • Improved VMware assessment and native migration (replication) with supporting large scale environments with more than 30K+ virtual machines.
  • New Hyper-V assessment only capabilities providing workload suitability, sizing recommendations, and cost estimates.
  • Native agentless VMware migration functionality to Microsoft Azure.
  • Unified console for assessment and migration that supports Azure Migrate, Azure ASR, and ISV tools.
  • Native Cloudamize ISV integration with Azure migrate unified portal for additional assessment capabilities.

Simply put, the new Azure Migrate service can now assess VMware or Hyper-V environments from a single unified console using a single deployed on-premises machine specific to VMware or Hyper-V. For VMware environments, this same Azure Migrate machine, can now also replicate VMware VMs to Microsoft Azure without the need for ASR and using an agentless approach. For Hyper-V environments, ASR will still need to be used as of now since I am sure they are working on  supporting the same in the near future.

Azure Migrate uses snapshots and change block tracking (CBT) to replicate and migrate VMware VMs to Microsoft Azure thus an agent is not required and everything is done through the integration of the Azure Migrate VM and VMware vCenter through vSphere management SDK. A single Azure Migrate appliance can discover and assess up to 10K+ VMs and you can setup multiple appliances to scale up the number of VMs to be discovered and assessed. VMware migration part of the appliance supports replicating and migrating 50 VMs at a time so multiple batches of 50 VMs can be scheduled for migration to cover all the environment.

Private Preview

The new Azure Migrate service is currently in technical preview so the above information might change over time until the product is GA. To enable the service, navigate to the following private preview page and fill in the required information. Make sure  you have your Azure subscription ID and be ready to wait for couple of days until it is approved. Also make sure that any Azure account used for creating and managing the service is part of Owner or Contributor +User access administrator for the resource group that you will deploy the service in.

SNAG-0012

image

image

The Microsoft Azure Migrate team has done a wonderful job documenting the steps required to assess and migrate for both VMware and Hyper-V environments. These documents will be shared with you once the preview access is approved and it will have all the prerequisites and requirements to run the service on Azure and on-premises so I will not be listing them here as the document says NDA. All the required network port and communication details are listed in the respective documents in great detail.

This configuration post will detail the Azure Migrate preview setup for a VMware environment in which a single VM is going to be assessed and then migrated to Azure using the Azure Migrate appliance. You need to have a vCenter in place with an administrative account and the Migrate appliance will require internal communication with vCenter and external communication with Azure all of which are detailed in the Microsoft provided documents (you can check the current Azure Migrate documentation which has all the ports).

Configuration:

Create an Azure Migrate project by adding a migration tool. Note that you will not see the Azure Migrate screen if the preview is not approved and a special URL will be provided by Microsoft for the same.

SNAG-0011

SNAG-0015

SNAG-0016

Currently the Azure Migrate service lives in the US with limited geographical locations but that is only the backend service, you can still assess and migrate to your own resource location group in any different location.

SNAG-0017

Microsoft Azure Migrate integrates with 3rd party ISV tools for the assessment part which for now supports Cloudamize and others to follow but remember this would be a paid service although the advantage would be support to physical machines and agentless dependencies checks on top of much more detailed assessments and optimizations reports. Same applies to the replication part below, ISVs will be added to support physical and Hyper-v migration from within the Azure Migrate service portal.

SNAG-0018

SNAG-0019

After the migration project has been created under tools, we are presented with the following dashboard to configure assessment and migration from the unified portal. Click on discover under the assessment tools tab to start the process of adding the appliance to the on-premises VMware environment. After the OVA is downloaded, import into vCenter.

SNAG-0020

image

SNAG-0022

SNAG-0023

SNAG-0024

SNAG-0025

SNAG-0026

SNAG-0027

SNAG-0029

SNAG-0030

SNAG-0031

SNAG-0033

The appliance is just a Windows Server 2016 VM which can be joined to domain, set a static IP, secured with AV (exclusions required), and should be fully updated. This can be treated as any VM as long as the FW and AV requirements are fulfilled.

SNAG-0034

SNAG-0035

SNAG-0036

SNAG-0037

SNAG-0038

To configure the appliance, a shortcut is provided on the desktop named AzureMigrate WebPortal which opened automatically upon login. A proxy can be setup if direct internet access is not possible but do bare in mind that replication traffic is huge so better to NAT this server with direct internet to Azure.

SNAG-0040

SNAG-0041

SNAG-0042

SNAG-0043

SNAG-0044

SNAG-0046

SNAG-0047

SNAG-0048

SNAG-0049

SNAG-0050

SNAG-0051

Login to Azure with an account that has Owner or Contributor +User access administrator for the resource group that you will deploy the service in.

SNAG-0053

Enter the credentials for the vCenter server and name the Azure Migrate appliance which will be reflected in the Azure portal

SNAG-0055

SNAG-0057

SNAG-0058

That is it from the appliance side, we are done. Now we need to wait at least 15 minutes before data start to show inside the Azure Migrate assessment service. For production environments, I would recommend running an assessment for at least a month. Refresh the Assessments tools page and the discovered servers should pop up then click on that number.

image

SNAG-0061

Now is the time to create an assessment of the environment. Groups are created to combine machines that need to be assessed. Clicking on assessment properties “View all”  allows us to change the zone and sizing options of VMs that will reflect in the assessment report in terms of cost.

image

SNAG-0063

SNAG-0064

SNAG-0065

SNAG-0066

SNAG-0067

SNAG-0069

image

SNAG-0071

SNAG-0072

SNAG-0073

SNAG-0074

SNAG-0075

SNAG-0076

SNAG-0077

In order to get VMs dependencies which is a very important part of any migration assessment, an OMS workspace needs to be created and two agents need to be installed on every assessed VM. Make sure you choose a unique name for the OMS because although it might not warn you but if the name is used, it will fail. The OMS also has limited geographical locations but again this is only where the data is hosted and analyzed but does not effect the actual migration location for your VMs.

SNAG-0078

SNAG-0079

SNAG-0080

SNAG-0081

SNAG-0082

SNAG-0083

SNAG-0084

SNAG-0085

SNAG-0087

SNAG-0088

SNAG-0089

SNAG-0091

SNAG-0092

Now that we have an assessment with dependencies finalized, we can start the migration process for this group which has only one VM for testing. Click on the replicate tab under Migration tools. We will use the Azure Migration appliance for the same so no independent ASR required. We will also utilize the created assessment to automatically create the recommended size and settings of the VM. As with ASR, UEFI boot is not supported but guess what it works just fine yet note that Microsoft will not support you if the VM does not boot.

image

SNAG-0096

SNAG-0097

SNAG-0099

SNAG-0101

SNAG-0103

SNAG-0104

SNAG-0105

SNAG-0107

SNAG-0109

image

SNAG-0115

SNAG-0117

SNAG-0118

SNAG-0122

When the replication starts, a snapshot is taken from the VM and after the replication has finished, the snapshot is deleted. Azure Migrate appliance will periodically take snapshots of the VM and replicate the changes only through CBT. When it is time to migrate, the VM is shutdown, a snapshot is created, a final change replication is done, and then the snapshot is deleted after which the VM is migrated with latest data. Now we will test the replicated VM to make sure it will boot fine and all settings are okay then we can proceed to the actual migration. After testing is done, a clean up test migration removes the test machine and continues VM replication.

SNAG-0120

SNAG-0121

SNAG-0124

SNAG-0125

SNAG-0126

SNAG-0127

SNAG-0128

SNAG-0129

SNAG-0131

SNAG-0132

SNAG-0133

You can choose not to shutdown the VM which is not recommended for many reasons but if you choose to do so then the data written after the final sync will not be replicated to the cloud VM.

SNAG-0134

SNAG-0138

SNAG-0139

SNAG-0140

SNAG-0141

SNAG-0142

SNAG-0144

Needless to say that when migrating production workloads, there are lots of considerations and preparations that are out of scope of this post. Think about network readiness, DNS readiness, AD readiness, security readiness and much more factors come into play when lifting-and-shifting workloads to the cloud.

Conclusion

Microsoft has definitely taken a step in the right direction with the new Azure Migration service and the integration of ISV’s all from within a unified console is going to make migration a much simpler process to organizations. Interestingly I found no issues in the private preview after extensively testing it which is always good news.

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 *