| title | description | author | ms.service | ms.topic | ms.date | ms.author |
|---|---|---|---|---|---|---|
Azure Migrate - Frequently Asked Questions (FAQ) | Microsoft Docs |
Addresses frequently asked questions about Azure Migrate |
snehaamicrosoft |
azure-migrate |
conceptual |
09/21/2018 |
snehaa |
This article includes frequently asked questions about Azure Migrate. If you have any further queries after reading this article, post them on the Azure Migrate forum.
Yes, Azure Migrate currently only supports assessment of VMware workloads. Support for Hyper-V and physical servers will be enabled in future.
Yes, Azure Migrate requires vCenter Server to discover a VMware environment. It does not support discovery of ESXi hosts that are not managed by a vCenter Server.
Azure Migrate is an assessment service that helps you discover your on-premises workloads and plan your migration to Azure. Azure Site Recovery, along with being a disaster recovery solution, helps you migrate on-premises workloads to IaaS VMs in Azure.
Azure Migrate provides migration assessment specifically to assist with migration readiness and evaluation of on-premises workloads into Azure. Microsoft Assessment and Planning (MAP) Toolkit has other functionality. For example, migration planning for newer versions of Windows client and server operating systems, software usage tracking etc. For those scenarios, continue to use the MAP Toolkit.
Azure Migrate is a migration planning tool and Azure Site Recovery Deployment Planner is a disaster recovery (DR) planning tool.
Migration from VMware to Azure: If you intend to migrate your on-premises workloads to Azure, use Azure Migrate for migration planning. Azure Migrate assesses on-premises workloads and provides guidance, insights, and mechanisms to assist you in migrating to Azure. Once you are ready with your migration plan, you can use services such as Azure Site Recovery and Azure Database Migration Service to migrate the machines to Azure.
Migration from Hyper-V to Azure: Azure Migrate currently only supports assessment of VMware virtual machines for migration to Azure. Support for Hyper-V is on the roadmap for Azure Migrate. In the interim, you can use Site Recovery Deployment Planner. Once Hyper-V support is enabled in Azure Migrate, you can use Azure Migrate for planning migration of Hyper-V workloads.
Disaster Recovery from VMware/Hyper-V to Azure: If you intend to do disaster recovery (DR) on Azure using Azure Site Recovery (Site Recovery), use Site Recovery Deployment Planner for DR planning. Site Recovery Deployment Planner does a deep, ASR-specific assessment of your on-premises environment. It provides recommendations that are required by Site Recovery for successful DR operations such as replication, failover of your virtual machines.
Azure Migrate currently supports East US and West Central US as migration project locations. Even though you can only create migration projects in West Central US and East US, you can still assess your machines for multiple target locations. The project location is only used to store the discovered data.
The connection can be over the internet or use ExpressRoute with public peering.
Additional components (for example anti-virus) can be added into the OVA template as long as the communication and firewall rules required for the Azure Migrate appliance to work are left as is.
Azure Migrate supports two kinds of discovery, appliance-based discovery and agent-based discovery. The appliance-based discovery collects metadata about the on-premises VMs, the complete list of metadata collected by the appliance is listed below:
Configuration data of the VM
- VM display name (on vCenter)
- VM inventory path (host/cluster/folder in vCenter)
- IP address
- MAC address
- Operating system
- Number of cores, disks, NICs
- Memory size, Disk sizes
Performance data of the VM
- CPU usage
- Memory usage
- For each disk attached to the VM:
- Disk read throughput
- Disk writes throughput
- Disk read operations per sec
- Disk writes operations per sec
- For each network adapter attached to the VM:
- Network in
- Network out
The agent-based discovery is an option available on top of the appliance-based discovery and helps customers visualize dependencies of the on-prem VMs. The dependency agents collect details like, FQDN, OS, IP address, MAC address, processes running inside the VM and the incoming/outgoing TCP connections from the VM. The agent-based discovery is optional and you can choose to not install the agents if you do not want to visualize the dependencies of the VMs.
In the case of the one time discovery approach, in order to collect the performance data, the statistics level on the vCenter server would have to be set to 3. Setting it to this level would collect a large quantity of troubleshooting data, which would be stored in the vCenter Server database. It could thus result in some performance issues on the vCenter Server. There would be negligible impact on the ESXi host.
We have introduced continuous profiling of performance data(which is in preview). With continuous profiling, there is no longer a need to change the vCenter Server statistics level to run a performance-based assessment. The collector appliance will now profile the on-premises machines to measure the performance data of the virtual machines. This would have almost zero performance impact on the ESXi hosts as well as on the vCenter Server.
The data collected by the collector appliance is stored in the Azure location that you specify while creating the migration project. The data is securely stored in a Microsoft subscription and is deleted when the user deletes the Azure Migrate project.
For dependency visualization, if you install agents on the VMs, the data collected by the dependency agents is stored in the US in a Log Analytics workspace created in user’s subscription. This data is deleted when you delete the Log Analytics workspace in your subscription. Learn more.
Yes, the collected data is encrypted both at rest and while in transit. The metadata collected by the appliance is securely sent to the Azure Migrate service over internet via https. The collected metadata is stored in Cosmos DB and in Azure blob storage in a Microsoft subscription and is encrypted at rest.
The data collected by the dependency agents is also encrypted in transit (secure https channel) and is stored in a Log Analytics workspace in the user’s subscription. It is also encrypted at rest.
The collector appliance connects to the vCenter Server (port 443) using the credentials provided by the user in the appliance. It queries the vCenter Server using VMware PowerCLI to collect metadata about the VMs managed by vCenter Server. It collects both configuration data about VMs (cores, memory, disks, NIC etc.) as well as performance history of each VM for the last one month from vCenter Server. The collected metadata is then sent to the Azure Migrate service (over internet via https) for assessment. Learn more
Yes, a single collector appliance can be used to discover multiple vCenter Servers, but not concurrently. You need to run the discoveries one after another.
Currently there is no integration. The .OVA template in Site Recovery is used to set up a Site Recovery configuration server for VMware VM/physical server replication. The .OVA used by Azure Migrate is used to discover VMware VMs managed by a vCenter server, for the purposes of migration assessment.
If you change the settings on a VM you want to assess, trigger discover again using the collector appliance. In the appliance, use the Start collection again option to do this. After the collection is done, select the Recalculate option for the assessment in the portal, to get updated assessment results.
If you have an environment that is shared across tenants and you do not want to discover the VMs of one tenant in another tenant's subscription, you can use the Scope field in the collector appliance to scope the discovery. If the tenants are sharing hosts, create a credential that has read-only access to only the VMs belonging to the specific tenant and then use this credential in the collector appliance and specify the Scope as the host to do the discovery. Alternatively, you can also create folders in vCenter Server (let's say folder1 for tenant1 and folder2 for tenant2), under the shared host, move the VMs for tenant1 into folder1 and for tenant2 into folder2 and then scope the discoveries in the collector accordingly by specifying the appropriate folder.
You can discover 1500 virtual machines in a single migration project. If you have more machines in your on-premises environment, learn more about how you can discover a large environment in Azure Migrate.
Azure Migrate currently does not support cost estimation for Enterprise Agreement offer. The workaround is to specify Pay-As-You-Go as the offer and manually specifying the discount percentage (applicable to the subscription) in the 'Discount' field of the assessment properties.
Dependency visualization enables you to assess groups of VMs for migration with greater confidence by cross-checking machine dependencies before you run an assessment. Dependency visualization helps you to ensure that nothing is left behind, avoiding unexpected outages when you migrate to Azure. Azure Migrate leverages the Service Map solution in Log Analytics to enable dependency visualization.
No. Learn more about Azure Migrate pricing here.
To use dependency visualization, you need to download and install agents on each on-premises machine that you want to evaluate.
- Microsoft Monitoring agent(MMA) needs to be installed on each machine.
- The Dependency agent needs to be installed on each machine.
- In addition, if you have machines with no internet connectivity, you need to download and install Log Analytics gateway on them.
You don't need these agents on machines you want to assess unless you're using dependency visualization.
Yes, Azure Migrate now allows you to attach an existing workspace to the migration project and leverage it for dependency visualization. Learn more.
No, the dependency visualization cannot be exported. However, since Azure Migrate uses Service Map for dependency visualization, you can use the Service Map REST APIs to get the dependencies in a json format.
Here is a script that you can use for installation of dependency agent. For MMA, here is a script available on TechNet that you can leverage.
In addition to scripts, you can also leverage deployment tools like System Center Configuration Manager (SCCM), Intigua etc. to deploy the agents.
The list of Windows operating systems supported by MMA is here. The list of Linux operating systems supported by MMA is here.
The list of Windows operating systems supported by dependency agent is here. The list of Linux operating systems supported by dependency agent is here.
No, Azure Migrate lets you visualize dependencies for up to one hour duration. Azure Migrate allows you to go back to a particular date in the history for up to last one month, but the maximum duration for which you can visualize the dependencies is up to 1 hour. For example, you can use the time duration functionality in the dependency map, to view dependencies for yesterday, but can only view it for a one hour window.
You can visualize dependencies for groups that have up to 10 VMs, if you have a group with more than 10 VMs, we recommend you to split the group in to smaller groups and visualize the dependencies.
- Read the Azure Migrate overview
- Learn how you can discover and assess a VMware environment