Support matrix for VMware discovery
This article summarizes prerequisites and support requirements for using the Azure Migrate: Discovery and assessment tool to discover and assess servers in a VMware environment for migration to Azure.
To assess servers, first, create an Azure Migrate project. The Azure Migrate: Discovery and assessment tool is automatically added to the project. Then, deploy the Azure Migrate appliance. The appliance continuously discovers on-premises servers and sends configuration and performance metadata to Azure. When discovery is completed, gather the discovered servers into groups and run assessments per group.
As you plan your migration of VMware servers to Azure, review the migration support matrix.
|Project limits||You can create multiple Azure Migrate projects in an Azure subscription.
You can discover and assess up to 50,000 servers in a VMware environment in a single project. A project can include physical servers and servers from a Hyper-V environment, up to the assessment limits.
|Discovery||The Azure Migrate appliance can discover up to 10,000 servers running across multiple vCenter Servers.
The appliance supports adding multiple vCenter Servers. You can add up to 10 vCenter Servers per appliance.
|Assessment||You can add up to 35,000 servers in a single group.
You can assess up to 35,000 servers in a single assessment.
Learn more about assessments.
|vCenter Server||Servers that you want to discover and assess must be managed by vCenter Server version 7.0, 6.7, 6.5, 6.0, or 5.5.
Discovering servers by providing ESXi host details in the appliance currently isn't supported.
IPv6 addresses aren't supported for vCenter Server (for discovery and assessment of servers) and ESXi hosts (for replication of servers).
|Permissions||The Azure Migrate: Discovery and assessment tool requires a vCenter Server read-only account.
If you want to use the tool for software inventory, agentless dependency analysis, web apps and SQL discovery, the account must have privileges for guest operations on VMware VMs.
|Operating systems||All Windows and Linux operating systems can be assessed for migration.|
|Storage||Disks attached to SCSI, IDE, and SATA-based controllers are supported.|
Azure Migrate appliance requirements
Azure Migrate uses the Azure Migrate appliance for discovery and assessment. You can deploy the appliance as a server in your VMware environment using a VMware Open Virtualization Appliance (OVA) template that's imported into vCenter Server or by using a PowerShell script. Learn more about appliance requirements for VMware.
Here are more requirements for the appliance:
- In Azure Government, you must deploy the appliance by using a script.
- The appliance must be able to access specific URLs in public clouds and government clouds.
Port access requirements
|Azure Migrate Appliance||Inbound connections on TCP port 3389 to allow remote desktop connections to the appliance.
Inbound connections on port 44368 to remotely access the appliance management app by using the URL
Outbound connections on port 443 (HTTPS) to send discovery and performance metadata to Azure Migrate.
|vCenter Server||Inbound connections on TCP port 443 to allow the appliance to collect configuration and performance metadata for assessments.
The appliance connects to vCenter on port 443 by default. If vCenter Server listens on a different port, you can modify the port when you set up discovery.
|ESXi hosts||For discovery of software inventory or agentless dependency analysis, the appliance connects to ESXi hosts on TCP port 443 to discover software inventory and dependencies on the servers.|
Software inventory requirements
In addition to discovering servers, Azure Migrate: Discovery and assessment can perform software inventory on servers. Software inventory provides the list of applications, roles and features running on Windows and Linux servers, discovered using Azure Migrate. It allows you to identify and plan a migration path tailored for your on-premises workloads.
|Supported servers||You can perform software inventory on up to 10,000 servers running across vCenter Server(s) added to each Azure Migrate appliance.|
|Operating systems||Servers running all Windows and Linux versions are supported.|
|Server requirements||For software inventory, VMware Tools must be installed and running on your servers. The VMware Tools version must be version 10.2.1 or later.
Windows servers must have PowerShell version 2.0 or later installed.
WMI must be enabled and available on Windows servers to gather the details of the roles and features installed on the servers.
|vCenter Server account||To interact with the servers for software inventory, the vCenter Server read-only account that's used for assessment must have privileges for guest operations on VMware VMs.|
|Server access||You can add multiple domain and non-domain (Windows/Linux) credentials in the appliance configuration manager for software inventory.
You must have a guest user account for Windows servers and a standard user account (non-
|Port access||The Azure Migrate appliance must be able to connect to TCP port 443 on ESXi hosts running servers on which you want to perform software inventory. The server running vCenter Server returns an ESXi host connection to download the file that contains the details of the software inventory.|
|Discovery||Software inventory is performed from vCenter Server by using VMware Tools installed on the servers.
The appliance gathers the information about the software inventory from the server running vCenter Server through vSphere APIs.
Software inventory is agentless. No agent is installed on the server, and the appliance doesn't connect directly to the servers.
SQL Server instance and database discovery requirements
Software inventory identifies SQL Server instances. Using this information, the appliance attempts to connect to the respective SQL Server instances through the Windows authentication or SQL Server authentication credentials in the appliance configuration manager. The appliance can connect to only those SQL Server instances to which it has network line of sight, whereas software inventory by itself may not need network line of sight.
After the appliance is connected, it gathers configuration and performance data for SQL Server instances and databases. The appliance updates the SQL Server configuration data once every 24 hours and captures the Performance data every 30 seconds.
|Supported servers||Supported only for servers running SQL Server in your VMware, Microsoft Hyper-V, and Physical/Bare metal environments as well as IaaS Servers of other public clouds such as AWS, GCP, etc. You can discover up to 300 SQL Server instances or 6,000 SQL databases, whichever is less.|
|Windows servers||Windows Server 2008 and later are supported.|
|Linux servers||Currently not supported.|
|Authentication mechanism||Both Windows and SQL Server authentication are supported. You can provide credentials of both authentication types in the appliance configuration manager.|
|SQL Server access||Azure Migrate requires a Windows user account that is a member of the sysadmin server role.|
|SQL Server versions||SQL Server 2008 and later are supported.|
|SQL Server editions||Enterprise, Standard, Developer, and Express editions are supported.|
|Supported SQL configuration||Discovery of standalone, highly available, and disaster protected SQL deployments is supported. Discovery of HADR SQL deployments powered by Always On Failover Cluster Instances and Always On Availability Groups is also supported.|
|Supported SQL services||Only SQL Server Database Engine is supported.
Discovery of SQL Server Reporting Services (SSRS), SQL Server Integration Services (SSIS), and SQL Server Analysis Services (SSAS) isn't supported.
By default, Azure Migrate uses the most secure way of connecting to SQL instances i.e. Azure Migrate encrypts communication between the Azure Migrate appliance and the source SQL Server instances by setting the TrustServerCertificate property to
true. Additionally, the transport layer uses SSL to encrypt the channel and bypass the certificate chain to validate trust. Hence, the appliance server must be set up to trust the certificate's root authority.
However, you can modify the connection settings, by selecting Edit SQL Server connection properties on the appliance.Learn more to understand what to choose.
Web apps discovery requirements
Software inventory identifies web server role existing on discovered servers. If a server has a web server installed, Azure Migrate discovers web apps on the server. The user can add both domain and non-domain credentials on the appliance. Ensure that the account used has local admin privileges on source servers. Azure Migrate automatically maps credentials to the respective servers, so one doesn’t have to map them manually. Most importantly, these credentials are never sent to Microsoft and remain on the appliance running in the source environment. After the appliance is connected, it gathers configuration data for ASP.NET web apps(IIS web server) and Java web apps(Tomcat servers). Web apps configuration data is updated once every 24 hours.
|Support||ASP.NET web apps||Java web apps|
|Stack||VMware, Hyper-V, and Physical servers||VMware, Hyper-V, and Physical servers|
|Windows servers||Windows Server 2008 R2 and later are supported.||Not supported.|
|Linux servers||Not supported.||Ubuntu Linux 16.04/18.04/20.04, Debian 7/8, CentOS 6/7, Red Hat Enterprise Linux 5/6/7.|
|Web server versions||IIS 7.5 and later.||Tomcat 8 or later.|
|Required privileges||local admin||root or sudo user|
Data is always encrypted at rest and during transit.
Dependency analysis requirements (agentless)
Dependency analysis helps you analyze the dependencies between the discovered servers, which can be easily visualized with a map view in Azure Migrate project and used to group related servers for migration to Azure. The following table summarizes the requirements for setting up agentless dependency analysis:
|Supported servers||You can enable agentless dependency analysis on up to 1000 servers (across multiple vCenter Servers), discovered per appliance.|
|Windows servers||Windows Server 2019
Windows Server 2016
Windows Server 2012 R2
Windows Server 2012
Windows Server 2008 R2 (64-bit)
Microsoft Windows Server 2008 (32-bit)
|Linux servers||Red Hat Enterprise Linux 5.1, 5.3, 5.11, 6.x, 7.x, 8.x
Cent OS 5.1, 5.9, 5.11, 6.x, 7.x, 8.x
Ubuntu 12.04, 14.04, 16.04, 18.04, 20.04
OracleLinux 6.1, 6.7, 6.8, 6.9, 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 7.9, 8, 8.1, 8.3, 8.5
SUSE Linux 10, 11 SP4, 12 SP1, 12 SP2, 12 SP3, 12 SP4, 15 SP2, 15 SP3
Debian 7, 8, 9, 10, 11
|Server requirements||VMware Tools (10.2.1 and later) must be installed and running on servers you want to analyze.
Servers must have PowerShell version 2.0 or later installed.
WMI should be enabled and available on Windows servers.
|vCenter Server account||The read-only account used by Azure Migrate for assessment must have privileges for guest operations on VMware VMs.|
|Windows server acesss||A user account (local or domain) with administrator permissions on servers.|
|Linux server access||Sudo user account with permissions to execute ls and netstat commands. If you're providing a sudo user account, ensure that you have enabled NOPASSWD for the account to run the required commands without prompting for a password every time a sudo command is invoked.
Alternatively, you can create a user account that has the CAP_DAC_READ_SEARCH and CAP_SYS_PTRACE permissions on /bin/netstat and /bin/ls files, set using the following commands:
|Port access||The Azure Migrate appliance must be able to connect to TCP port 443 on ESXi hosts running the servers that have dependencies you want to discover. The server running vCenter Server returns an ESXi host connection to download the file containing the dependency data.|
|Discovery method||Dependency information between servers is gathered by using VMware Tools installed on the server running vCenter Server.
The appliance gathers the information from the server by using vSphere APIs.
No agent is installed on the server, and the appliance doesn’t connect directly to servers.
Dependency analysis requirements (agent-based)
Dependency analysis helps you identify dependencies between on-premises servers that you want to assess and migrate to Azure. The following table summarizes the requirements for setting up agent-based dependency analysis:
|Before deployment||You should have a project in place, with the Azure Migrate: Discovery and assessment tool added to the project.
Deploy dependency visualization after setting up an Azure Migrate appliance to discover your on-premises servers.
Learn how to create a project for the first time.
Learn how to add a discovery and assessment tool to an existing project.
Learn how to set up the Azure Migrate appliance for assessment of Hyper-V, VMware, or physical servers.
|Supported servers||Supported for all servers in your on-premises environment.|
|Log Analytics||Azure Migrate uses the Service Map solution in Azure Monitor logs for dependency visualization.
You associate a new or existing Log Analytics workspace with a project. You can't modify the workspace for a project after the workspace is added.
The workspace must be in the same subscription as the project.
The workspace must be located in the East US, Southeast Asia, or West Europe regions. Workspaces in other regions can't be associated with a project.
The workspace must be in a region in which Service Map is supported.
In Log Analytics, the workspace that's associated with Azure Migrate is tagged with the project key and project name.
|Required agents||On each server that you want to analyze, install the following agents:
- Microsoft Monitoring Agent (MMA)
- Dependency agent
If on-premises servers aren't connected to the internet, download and install the Log Analytics gateway on them.
Learn more about installing the Dependency agent and the MMA.
|Log Analytics workspace||The workspace must be in the same subscription as the project.
Azure Migrate supports workspaces that are located in the East US, Southeast Asia, and West Europe regions.
The workspace must be in a region in which Service Map is supported.
The workspace for a project can't be modified after the workspace is added.
|Cost||The Service Map solution doesn't incur any charges for the first 180 days (from the day you associate the Log Analytics workspace with the project).
After 180 days, standard Log Analytics charges apply.
Using any solution other than Service Map in the associated Log Analytics workspace incurs standard charges for Log Analytics.
When the project is deleted, the workspace isn't automatically deleted. After deleting the project, Service Map usage isn't free, and each node will be charged per the paid tier of Log Analytics workspace.
If you have projects that you created before Azure Migrate general availability (February 28, 2018), you might have incurred additional Service Map charges. To ensure that you're charged only after 180 days, we recommend that you create a new project. Workspaces that were created before GA are still chargeable.
|Management||When you register agents to the workspace, use the ID and key provided by the project.
You can use the Log Analytics workspace outside Azure Migrate.
If you delete the associated project, the workspace isn't deleted automatically. Delete it manually.
Don't delete the workspace created by Azure Migrate, unless you delete the project. If you do, the dependency visualization functionality doesn't work as expected.
|Internet connectivity||If servers aren't connected to the internet, install the Log Analytics gateway on the servers.|
|Azure Government||Agent-based dependency analysis isn't supported.|
- Review assessment best practices.
- Learn how to prepare for a VMware assessment.
Submit and view feedback for