Support matrix for Hyper-V assessment
This article summarizes prerequisites and support requirements when you discover and assess on-premises servers running in a Hyper-V environment for migration to Azure, using the Azure Migrate: Discovery and assessment tool. If you want to migrate servers running on Hyper-V to Azure, review the migration support matrix.
To set up discovery and assessment of servers running on Hyper-V, you create a project, and add the Azure Migrate: Discovery and assessment tool to the project. After the tool is added, you deploy the Azure Migrate appliance. The appliance continuously discovers on-premises servers and sends server metadata and performance data to Azure. After discovery is complete, you gather discovered servers into groups, and run an assessment for a group.
Limitations
| Support | Details |
|---|---|
| Assessment limits | You can discover and assess up to 35,000 servers in a single project. |
| Project limits | You can create multiple projects in an Azure subscription. In addition to servers on Hyper-V, a project can include servers on VMware and physical servers, up to the assessment limits for each. |
| Discovery | The Azure Migrate appliance can discover up to 5000 servers running on Hyper-V. The appliance can connect to up to 300 Hyper-V hosts. |
| 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 for a group. |
Learn more about assessments.
Hyper-V host requirements
| Support | Details |
|---|---|
| Hyper-V host | The Hyper-V host can be standalone or deployed in a cluster. The Hyper-V host can run Windows Server 2019, Windows Server 2016, or Windows Server 2012 R2. Server core installations of these operating systems are also supported. You can't assess servers located on Hyper-V hosts running Windows Server 2012. |
| Permissions | You need Administrator permissions on the Hyper-V host. If you don't want to assign Administrator permissions, create a local or domain user account, and add the user account to these groups- Remote Management Users, Hyper-V Administrators, and Performance Monitor Users. |
| PowerShell remoting | PowerShell remoting must be enabled on each Hyper-V host. |
| Hyper-V Replica | If you use Hyper-V Replica (or you have multiple servers with the same server identifiers), and you discover both the original and replicated servers using Azure Migrate, the assessment generated by Azure Migrate might not be accurate. |
Server requirements
| Support | Details |
|---|---|
| Operating system | All operating systems can be assessed for migration. |
| Integration Services | Hyper-V Integration Services must be running on servers that you assess, in order to capture operating system information. |
| Storage | Local Disk, DAS, JBOD, Storage Spaces, CSV, SMB. These Hyper-V Host storages on which VHD/VHDX are stored are supported. IDE and SCSI virtual controllers are supported |
Azure Migrate appliance requirements
Azure Migrate uses the Azure Migrate appliance for discovery and assessment. You can deploy the appliance using a compressed Hyper-V VHD that you download from the portal or using a PowerShell script.
- Learn about appliance requirements for Hyper-V.
- Learn about URLs that the appliance needs to access in public and government clouds.
- In Azure Government, you must deploy the appliance using the script.
Port access
The following table summarizes port requirements for assessment.
| Device | Connection |
|---|---|
| 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 using the URL: https://<appliance-ip-or-name>:44368Outbound connections on ports 443 (HTTPS), to send discovery and performance metadata to Azure Migrate. |
| Hyper-V host/cluster | Inbound connection on WinRM port 5985 (HTTP) to pull metadata and performance data for servers on Hyper-V, using a Common Information Model (CIM) session. |
| Servers | For Windows server, need access on port 5985 (HTTP) and for Linux servers, need access on port 22 (TCP) to perform software inventory and agentless dependency analysis |
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 helps you to identify and plan a migration path tailored for your on-premises workloads.
| Support | Details |
|---|---|
| Supported servers | You can perform software inventory on up to 5,000 servers running across Hyper-V host(s)/cluster(s) added to each Azure Migrate appliance. |
| Operating systems | All Windows and Linux versions with Hyper-V integration services enabled. |
| Server requirements | Windows servers must have PowerShell remoting enabled and 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. Linux servers must have SSH connectivity enabled and ensure that the following commands can be executed on the Linux servers to pull the application data: list, tail, awk, grep, locate, head, sed, ps, print, sort, uniq. Based on OS type and the type of package manager being used, here are some additional commands: rpm/snap/dpkg, yum/apt-cache, mssql-server. |
| 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- sudo access) for all Linux servers. |
| Port access | For Windows server, need access on port 5985 (HTTP) and for Linux servers, need access on port 22(TCP). |
| Discovery | Software inventory is performed by directly connecting to the servers using the server credentials added on the appliance. The appliance gathers the information about the software inventory from Windows servers using PowerShell remoting and from Linux servers using SSH connection. Software inventory is agentless. No agent is installed on the servers. |
SQL Server instance and database discovery requirements
Software inventory identifies SQL Server instances. Using this information, the appliance attempts to connect to respective SQL Server instances through the Windows authentication or SQL Server authentication credentials that are provided in the appliance configuration manager. 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. SQL Server configuration data is updated once every 24 hours. Performance data is captured every 30 seconds.
| Support | Details |
|---|---|
| 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. |
Note
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 is found to have 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 |
Note
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 can be used to group related servers for migration to Azure. The following table summarizes the requirements for setting up agentless dependency analysis:
| Support | Details |
|---|---|
| Supported servers | You can enable agentless dependency analysis on up to 1000 servers (across multiple Hyper-V hosts/clusters), discovered per appliance. |
| Operating systems | All Windows and Linux versions with Hyper-V integration services enabled. |
| Server requirements | Windows servers must have PowerShell remoting enabled and PowerShell version 2.0 or later installed. Linux servers must have SSH connectivity enabled and ensure that the following commands can be executed on the Linux servers: touch, chmod, cat, ps, grep, echo, sha256sum, awk, netstat, ls, sudo, dpkg, rpm, sed, getcap, which, date. |
| Windows server access | 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 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: sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/ls |
| Port access | For Windows server, need access on port 5985 (HTTP) and for Linux servers, need access on port 22(TCP). |
| Discovery method | Agentless dependency analysis is performed by directly connecting to the servers using the server credentials added on the appliance. The appliance gathers the dependency information from Windows servers using PowerShell remoting and from Linux servers using SSH connection. No agent is installed on the servers to pull dependency data. |
Agent-based dependency analysis requirements
Dependency analysis helps you to identify dependencies between on-premises servers that you want to assess and migrate to Azure. The table summarizes the requirements for setting up agent-based dependency analysis. Hyper-V currently only supports agent-based dependency visualization.
| Requirement | Details |
|---|---|
| Before deployment | You should have a project in place, with the Azure Migrate: Discovery and assessment tool added to the project. You 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 Azure Migrate: Discovery and assessment tool to an existing project. Learn how to set up the appliance for discovery and assessment of servers on Hyper-V. |
| Azure Government | Dependency visualization isn't available in Azure Government. |
| 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. The workspace for a project can't be modified after it's added. The workspace must be in the same subscription as the project. The workspace must reside 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 associated with Azure Migrate is tagged with the Migration Project key, and the project name. |
| Required agents | On each server you want to analyze, install the following agents: The Microsoft Monitoring agent (MMA). The Dependency agent. If on-premises servers aren't connected to the internet, you need to download and install Log Analytics gateway on them. Learn more about installing the Dependency agent and MMA. |
| Log Analytics workspace | The workspace must be in the same subscription as the project. Azure Migrate supports workspaces residing 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 it's added. |
| Costs | The Service Map solution doesn't incur any charges for the first 180 days (from the day that you associate the Log Analytics workspace with the project)/ After 180 days, standard Log Analytics charges will apply. Using any solution other than Service Map in the associated Log Analytics workspace will incur standard charges for Log Analytics. When the project is deleted, the workspace isn't deleted along with it. After deleting the project, Service Map usage isn't free, and each node will be charged as per the paid tier of Log Analytics workspace/ If you have projects that you created before Azure Migrate general availability (GA- 28 February 2018), you might have incurred additional Service Map charges. To ensure payment after 180 days only, we recommend that you create a new project, since existing workspaces before GA are still chargeable. |
| Management | When you register agents to the workspace, you 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 won't work as expected. |
| Internet connectivity | If servers aren't connected to the internet, you need to install the Log Analytics gateway on them. |
| Azure Government | Agent-based dependency analysis isn't supported. |
Next steps
Feedback
Submit and view feedback for