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
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Enter the credentials for the vCenter server and name the Azure Migrate appliance which will be reflected in the Azure portal
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.
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.
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.
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.
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.
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.
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
What are the AV Exclusions? Have searched high and low and couldn’t find any documentation on this.
I would exclude the Azure Migrate folder in Program Files .