Matriz de suporte para avaliação do Hyper-V

Artigo
02/16/2024

Atenção

Este artigo faz referência ao CentOS, uma distribuição Linux que está perto do fim da vida útil. Por favor, considere o seu uso e planeje de acordo.

Este artigo resume os pré-requisitos e os requisitos de suporte quando você descobre e avalia servidores locais em execução em um ambiente Hyper-V para migração para o Azure usando a ferramenta Azure Migrate: Discovery and assessment . Se você quiser migrar servidores em execução no Hyper-V para o Azure, consulte a matriz de suporte à migração.

Para configurar a descoberta e a avaliação de servidores em execução no Hyper-V, crie um projeto e adicione a ferramenta Azure Migrate: Discovery and assessment ao projeto. Depois que a ferramenta for adicionada, você implantará o dispositivo Azure Migrate. O dispositivo descobre continuamente servidores locais e envia metadados do servidor e dados de desempenho para o Azure. Após a conclusão da descoberta, você reúne os servidores descobertos em grupos e executa uma avaliação para um grupo.

Limitações

Suporte	Detalhes
Limites de avaliação	Você pode descobrir e avaliar até 35.000 servidores em um único projeto.
Limites de projeto	Pode criar vários projetos numa subscrição do Azure. Além de servidores no Hyper-V, um projeto pode incluir servidores no VMware e servidores físicos, até os limites de avaliação para cada um.
Deteção	O dispositivo Azure Migrate pode descobrir até 5.000 servidores em execução no Hyper-V. O dispositivo pode se conectar a até 300 hosts Hyper-V.
Avaliação	Pode adicionar até 35 000 servidores num único grupo. Você pode avaliar até 35.000 servidores em uma única avaliação para um grupo.

Saiba mais sobre avaliações.

Requisitos do anfitrião Hyper-V

Suporte	Detalhes
Anfitrião Hyper-V	O host Hyper-V pode ser autônomo ou implantado em um cluster. O host Hyper-V pode executar o Windows Server 2022, Windows Server 2019, Windows Server 2016 ou Windows Server 2012 R2. As instalações Server Core desses sistemas operacionais também são suportadas. Não é possível avaliar servidores localizados em hosts Hyper-V que executam o Windows Server 2012.
Permissões	Você precisa de permissões de administrador no host Hyper-V. Se você não quiser atribuir permissões de Administrador, crie uma conta de usuário local ou de domínio e adicione a conta de usuário a estes grupos: Usuários de Gerenciamento Remoto, Administradores do Hyper-V e Usuários do Monitor de Desempenho.
Comunicação remota do PowerShell	A comunicação remota do PowerShell deve ser habilitada em cada host Hyper-V.
Réplica do Hyper-V	Se você usar a Réplica do Hyper-V (ou tiver vários servidores com os mesmos identificadores de servidor) e descobrir os servidores originais e replicados usando o Azure Migrate and Modernize, a avaliação gerada pelo Azure Migrate and Modernize pode não ser precisa.

Requisitos de servidor

Suporte	Detalhes
Sistema operativo	Todos os sistemas operacionais podem ser avaliados para migração.
Serviços de Integração	O Hyper-V Integration Services deve estar em execução em servidores avaliados por você para capturar informações do sistema operacional.
Armazenamento	Disco local, DAS, JBOD, Espaços de Armazenamento, CSV e SMB. Esses armazenamentos de host Hyper-V nos quais VHD/VHDX são armazenados são suportados. Controladores virtuais IDE e SCSI são suportados.

Requisitos de aplicação do Azure Migrate

O Azure Migrate and Modernize usa o dispositivo Azure Migrate para descoberta e avaliação. Você pode implantar o dispositivo usando um VHD Hyper-V compactado baixado do portal ou usando um script do PowerShell. Para mais informações:

Saiba mais sobre os requisitos do dispositivo para o Hyper-V.
Saiba mais sobre os URLs que o dispositivo precisa acessar em nuvens públicas e governamentais .
Use o script para implantar o dispositivo no Azure Government.

Acesso à porta

A tabela a seguir resume os requisitos de porta para avaliação.

Dispositivo	Ligação
Aplicação	Ligações de entrada na porta TCP 3389 para permitir ligações de ambiente de trabalho remoto ao dispositivo. Conexões de entrada na porta 44368 para acessar remotamente o aplicativo de gerenciamento do dispositivo usando a URL: `https://<appliance-ip-or-name>:44368` Conexões de saída nas portas 443 (HTTPS) para enviar metadados de descoberta e desempenho para o Azure Migrate and Modernize.
Host/cluster Hyper-V	Conexão de entrada na porta WinRM 5985 (HTTP) para extrair metadados e dados de desempenho para servidores no Hyper-V usando uma sessão CIM (Common Information Model).
Servidores	Os servidores Windows precisam de acesso na porta 5985 (HTTP). Os servidores Linux precisam de acesso na porta 22 (TCP) para realizar inventário de software e análise de dependência sem agente.

Requisitos de inventário de software

Além de descobrir servidores, o Azure Migrate: Discovery and assessment pode executar o inventário de software em servidores. O inventário de software fornece a lista de aplicativos, funções e recursos em execução em servidores Windows e Linux que são descobertos usando o Azure Migrate and Modernize. Ele ajuda você a identificar e planejar um caminho de migração adaptado para suas cargas de trabalho locais.

Suporte	Detalhes
Servidores suportados	Você pode executar o inventário de software em até 5.000 servidores em execução em hosts/clusters Hyper-V adicionados a cada dispositivo Azure Migrate.
Sistemas operativos	Todas as versões do Windows e Linux com os serviços de integração do Hyper-V habilitados.
Requisitos de servidor	Os servidores Windows devem ter a comunicação remota do PowerShell habilitada e o PowerShell versão 2.0 ou posterior instalado. O WMI deve estar habilitado e disponível nos servidores Windows para reunir os detalhes das funções e recursos instalados nos servidores. Os servidores Linux devem ter a conectividade Secure Shell (SSH) habilitada e garantir que os seguintes comandos possam ser executados nos servidores Linux para extrair os dados do aplicativo: list, tail, awk, grep, locate, head, sed, ps, print, sort, uniq. Com base no tipo de sistema operacional e no tipo de gerenciador de pacotes que está sendo usado, aqui estão mais alguns comandos: rpm/snap/dpkg, yum/apt-cache, mssql-server.
Acesso ao servidor	Você pode adicionar várias credenciais de domínio e não domínio (Windows/Linux) no gerenciador de configuração do dispositivo para inventário de software. Você deve ter uma conta de usuário convidado para servidores Windows e uma conta de usuário padrão (acesso não-sudo) para todos os servidores Linux.
Acesso à porta	Os servidores Windows precisam de acesso na porta 5985 (HTTP). Os servidores Linux precisam de acesso na porta 22 (TCP). Se você usar credenciais de domínio, o dispositivo Azure Migrate deverá ser capaz de se conectar às seguintes portas TCP e UDP: TCP 135 – Ponto de extremidade RPC TCP 389 – LDAP TCP 636 – LDAP SSL TCP 445 – SMB TCP/UDP 88 – Autenticação Kerberos TCP/UDP 464 – Operações de alteração Kerberos
Deteção	O inventário de software é realizado conectando-se diretamente aos servidores usando as credenciais do servidor adicionadas no dispositivo. O appliance reúne as informações sobre o inventário de software de servidores Windows usando a comunicação remota do PowerShell e de servidores Linux usando a conexão SSH. O inventário de software é sem agente. Nenhum agente está instalado nos servidores.

Requisitos de descoberta de instância e banco de dados do SQL Server

O inventário de software identifica instâncias do SQL Server. O appliance usa essas informações e tenta se conectar às respetivas instâncias do SQL Server por meio das credenciais de autenticação do Windows ou do SQL Server fornecidas no gerenciador de configuração do dispositivo. O dispositivo pode se conectar somente às instâncias do SQL Server às quais ele tem linha de visão de rede. O inventário de software por si só pode não precisar de linha de visão de rede.

Depois que o dispositivo é conectado, ele coleta dados de configuração e desempenho para instâncias e bancos de dados do SQL Server. Os dados de configuração do SQL Server são atualizados uma vez a cada 24 horas. Os dados de desempenho são capturados a cada 30 segundos.

Suporte	Detalhes
Servidores suportados	Suportado apenas para servidores que executam o SQL Server no VMware, Microsoft Hyper-V e ambientes físicos/bare-metal e servidores IaaS (infraestrutura como serviço) de outras nuvens públicas, como os Serviços Web do Azure e o Google Cloud Platform. Você pode descobrir até 750 instâncias do SQL Server ou 15.000 bancos de dados SQL, o que for menor, a partir de um único dispositivo. Recomendamos que você verifique se um dispositivo tem escopo para descobrir menos de 600 servidores executando SQL para evitar problemas de dimensionamento.
Servidores Windows	Windows Server 2008 e posterior são suportados.
Servidores Linux	Não é atualmente suportado.
Mecanismo de autenticação	Há suporte para autenticação do Windows e do SQL Server. Você pode fornecer credenciais de ambos os tipos de autenticação no gerenciador de configuração do dispositivo.
Acesso do SQL Server	Para descobrir instâncias e bancos de dados do SQL Server, a conta do Windows ou do SQL Server deve ser membro da função de servidor sysadmin ou ter essas permissões para cada instância do SQL Server.
Versões do SQL Server	SQL Server 2008 e posterior são suportados.
Edições do SQL Server	As edições Enterprise, Standard, Developer e Express são suportadas.
Configuração SQL suportada	Há suporte para a descoberta de implantações SQL autônomas, altamente disponíveis e protegidas contra desastres. Também há suporte para a descoberta de implantações SQL de alta disponibilidade e recuperação de desastres com tecnologia de instâncias de cluster de failover Always On e grupos de disponibilidade Always On.
Serviços SQL suportados	Somente o Mecanismo de Banco de Dados do SQL Server é suportado. Não há suporte para a descoberta do SQL Server Reporting Services, SQL Server Integration Services e SQL Server Analysis Services.

Nota

Por padrão, o Azure Migrate and Modernize usa a maneira mais segura de se conectar a instâncias SQL. Ou seja, o Azure Migrate and Modernize criptografa a comunicação entre o dispositivo Azure Migrate e as instâncias do SQL Server de origem definindo a TrustServerCertificate propriedade como true. Além disso, a camada de transporte usa Secure Socket Layer para criptografar o canal e ignorar a cadeia de certificados para validar a confiança. Por esse motivo, o servidor do dispositivo deve ser configurado para confiar na autoridade raiz do certificado.

No entanto, você pode modificar as configurações de conexão selecionando Editar propriedades de conexão do SQL Server no dispositivo. Saiba mais para entender o que escolher.

Use os scripts de exemplo a seguir para criar um login e provisioná-lo com as permissões necessárias.

Autenticação do Windows

-- Create a login to run the assessment
use master;
DECLARE @SID NVARCHAR(MAX) = N'';
CREATE LOGIN [MYDOMAIN\MYACCOUNT] FROM WINDOWS;
SELECT @SID = N'0x'+CONVERT(NVARCHAR, sid, 2) FROM sys.syslogins where name = 'MYDOMAIN\MYACCOUNT'
IF (ISNULL(@SID,'') != '')
  PRINT N'Created login [MYDOMAIN\MYACCOUNT] with SID = ' + @SID
ELSE
  PRINT N'Login creation failed'
GO    

-- Create a user in every database other than tempdb, model, and secondary AG databases (with connection_type = ALL) and provide minimal read-only permissions.
USE master;
EXECUTE sp_MSforeachdb '
  USE [?];
  IF (''?'' NOT IN (''tempdb'',''model''))
  BEGIN
    DECLARE @is_secondary_replica BIT = 0;
    IF CAST(PARSENAME(CAST(SERVERPROPERTY(''ProductVersion'') AS VARCHAR), 4) AS INT) >= 11
    BEGIN
      DECLARE @innersql NVARCHAR(MAX);
      SET @innersql = N''
        SELECT @is_secondary_replica = IIF(
          EXISTS (
              SELECT 1
              FROM sys.availability_replicas a
              INNER JOIN sys.dm_hadr_database_replica_states b
              ON a.replica_id = b.replica_id
              WHERE b.is_local = 1
              AND b.is_primary_replica = 0
              AND a.secondary_role_allow_connections = 2
              AND b.database_id = DB_ID()
          ), 1, 0
        );
      '';
      EXEC sp_executesql @innersql, N''@is_secondary_replica BIT OUTPUT'', @is_secondary_replica OUTPUT;
    END
    IF (@is_secondary_replica = 0)
    BEGIN
      CREATE USER [MYDOMAIN\MYACCOUNT] FOR LOGIN [MYDOMAIN\MYACCOUNT];
      GRANT SELECT ON sys.sql_expression_dependencies TO [MYDOMAIN\MYACCOUNT];
      GRANT VIEW DATABASE STATE TO [MYDOMAIN\MYACCOUNT];
    END
  END'
GO

-- Provide server level read-only permissions
use master;
GRANT SELECT ON sys.sql_expression_dependencies TO [MYDOMAIN\MYACCOUNT];
GRANT EXECUTE ON OBJECT::sys.xp_regenumkeys TO [MYDOMAIN\MYACCOUNT];
GRANT EXECUTE ON OBJECT::sys.xp_instance_regread TO [MYDOMAIN\MYACCOUNT];
GRANT VIEW DATABASE STATE TO [MYDOMAIN\MYACCOUNT];
GRANT VIEW SERVER STATE TO [MYDOMAIN\MYACCOUNT];
GRANT VIEW ANY DEFINITION TO [MYDOMAIN\MYACCOUNT];
GO

-- Provide msdb specific permissions
use msdb;
GRANT EXECUTE ON [msdb].[dbo].[agent_datetime] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysjobsteps] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[syssubsystems] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysjobhistory] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[syscategories] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysjobs] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysmaintplan_plans] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[syscollector_collection_sets] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysmail_profile] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysmail_profileaccount] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysmail_account] TO [MYDOMAIN\MYACCOUNT];
GO

-- Clean up
--use master;
-- EXECUTE sp_MSforeachdb 'USE [?]; DROP USER [MYDOMAIN\MYACCOUNT]'
-- DROP LOGIN [MYDOMAIN\MYACCOUNT];
--GO

Autenticação do SQL Server

--- Create a login to run the assessment
use master;
-- NOTE: SQL instances that host replicas of Always On availability groups must use the same SID for the SQL login.
 -- After the account is created in one of the members, copy the SID output from the script and include this value
 -- when executing against the remaining replicas.
 -- When the SID needs to be specified, add the value to the @SID variable definition below.
DECLARE @SID NVARCHAR(MAX) = N'';
IF (@SID = N'')
BEGIN
 CREATE LOGIN [evaluator]
     WITH PASSWORD = '<provide a strong password>'
END
ELSE
BEGIN
 DECLARE @SQLString NVARCHAR(500) = 'CREATE LOGIN [evaluator]
   WITH PASSWORD = ''<provide a strong password>''
   , SID = ' + @SID
 EXEC SP_EXECUTESQL @SQLString
END
SELECT @SID = N'0x'+CONVERT(NVARCHAR(100), sid, 2) FROM sys.syslogins where name = 'evaluator'
IF (ISNULL(@SID,'') != '')
 PRINT N'Created login [evaluator] with SID = '''+ @SID +'''. If this instance hosts any Always On Availability Group replica, use this SID value when executing the script against the instances hosting the other replicas'
ELSE
 PRINT N'Login creation failed'
GO

-- Create a user in every database other than tempdb, model, and secondary AG databases (with connection_type = ALL) and provide minimal read-only permissions.
USE master;
EXECUTE sp_MSforeachdb '
 USE [?];
 IF (''?'' NOT IN (''tempdb'',''model''))
 BEGIN
   DECLARE @is_secondary_replica BIT = 0;
   IF CAST(PARSENAME(CAST(SERVERPROPERTY(''ProductVersion'') AS VARCHAR), 4) AS INT) >= 11
   BEGIN
     DECLARE @innersql NVARCHAR(MAX);
     SET @innersql = N''
       SELECT @is_secondary_replica = IIF(
         EXISTS (
           SELECT 1
           FROM sys.availability_replicas a
           INNER JOIN sys.dm_hadr_database_replica_states b
             ON a.replica_id = b.replica_id
           WHERE b.is_local = 1
             AND b.is_primary_replica = 0
             AND a.secondary_role_allow_connections = 2
             AND b.database_id = DB_ID()
         ), 1, 0
       );
     '';
     EXEC sp_executesql @innersql, N''@is_secondary_replica BIT OUTPUT'', @is_secondary_replica OUTPUT;
   END

   IF (@is_secondary_replica = 0)
   BEGIN
       CREATE USER [evaluator] FOR LOGIN [evaluator];
       GRANT SELECT ON sys.sql_expression_dependencies TO [evaluator];
       GRANT VIEW DATABASE STATE TO [evaluator];
   END
 END'
GO

-- Provide server level read-only permissions
USE master;
GRANT SELECT ON sys.sql_expression_dependencies TO [evaluator];
GRANT EXECUTE ON OBJECT::sys.xp_regenumkeys TO [evaluator];
GRANT EXECUTE ON OBJECT::sys.xp_instance_regread TO [evaluator];
GRANT VIEW DATABASE STATE TO [evaluator];
GRANT VIEW SERVER STATE TO [evaluator];
GRANT VIEW ANY DEFINITION TO [evaluator];
GO

-- Provide msdb specific permissions
USE msdb;
GRANT EXECUTE ON [msdb].[dbo].[agent_datetime] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysjobsteps] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[syssubsystems] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysjobhistory] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[syscategories] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysjobs] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysmaintplan_plans] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[syscollector_collection_sets] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysmail_profile] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysmail_profileaccount] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysmail_account] TO [evaluator];
GO

-- Clean up
--use master;
-- EXECUTE sp_MSforeachdb 'USE [?]; BEGIN TRY DROP USER [evaluator] END TRY BEGIN CATCH PRINT ERROR_MESSAGE() END CATCH;'
-- BEGIN TRY DROP LOGIN [evaluator] END TRY BEGIN CATCH PRINT ERROR_MESSAGE() END CATCH;
--GO

Requisitos de descoberta de aplicativos Web

O inventário de software identifica a função de servidor Web que existe nos servidores descobertos. Se um servidor tiver um servidor Web instalado, o Azure Migrate and Modernize descobrirá aplicativos Web no servidor.

Você pode adicionar credenciais de domínio e de não domínio no dispositivo. Verifique se a conta usada tem privilégios de administrador local nos servidores de origem. O Azure Migrate and Modernize mapeia automaticamente as credenciais para os respetivos servidores, para que não seja necessário mapeá-las manualmente. Essas credenciais nunca são enviadas à Microsoft e permanecem no dispositivo em execução no ambiente de origem.

Depois que o dispositivo é conectado, ele coleta dados de configuração para aplicativos Web ASP.NET (servidor Web IIS) e aplicativos Web Java (servidores Tomcat). Os dados de configuração de aplicativos Web são atualizados uma vez a cada 24 horas.

Suporte	Aplicações Web do ASP.NET	Aplicações Web Java
Pilha	VMware, Hyper-V e servidores físicos.	VMware, Hyper-V e servidores físicos.
Servidores Windows	Windows Server 2008 R2 e posterior são suportados.	Não suportado.
Servidores Linux	Não suportado.	Ubuntu Linux 16.04/18.04/20.04, Debian 7/8, CentOS 6/7 e Red Hat Enterprise Linux 5/6/7.
Versões do servidor Web	IIS 7.5 e posterior.	Tomcat 8 ou posterior.
Privilégios necessários	Administrador local.	Usuário root ou sudo.

Nota

Os dados são sempre encriptados em repouso e durante o trânsito.

Requisitos de análise de dependência (sem agente)

A análise de dependência ajuda a analisar as dependências entre os servidores descobertos. Você pode visualizar facilmente dependências com um modo de exibição de mapa em um projeto do Azure Migrate. Você pode usar dependências para agrupar servidores relacionados para migração para o Azure. A tabela a seguir resume os requisitos para configurar a análise de dependência sem agente.

Suporte	Detalhes
Servidores suportados	Você pode habilitar a análise de dependência sem agente em até 1.000 servidores (em vários hosts/clusters Hyper-V) descobertos por dispositivo.
Sistemas operativos	Todas as versões do Windows e Linux com os serviços de integração do Hyper-V habilitados.
Requisitos de servidor	Os servidores Windows devem ter a comunicação remota do PowerShell habilitada e o PowerShell versão 2.0 ou posterior instalado. Os servidores Linux devem ter conectividade SSH habilitada e garantir que os seguintes comandos possam ser executados nos servidores Linux: touch, chmod, cat, ps, grep, echo, sha256sum, awk, netstat, ls, sudo, dpkg, rpm, sed, getcap, which, date.
Acesso ao servidor Windows	Uma conta de usuário (local ou domínio) com permissões de administrador em servidores.
Acesso ao servidor Linux	Uma conta de usuário sudo com permissões para executar comandos ls e netstat. Se você estiver fornecendo uma conta de usuário sudo, certifique-se de habilitar o NOPASSWD para que a conta execute os comandos necessários sem solicitar uma senha toda vez que um comando sudo for invocado. Como alternativa, você pode criar uma conta de usuário que tenha as permissões CAP_DAC_READ_SEARCH e CAP_SYS_PTRACE nos arquivos /bin/netstat e /bin/ls, definidas usando os seguintes comandos: `sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/ls sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/netstat`
Acesso à porta	Os servidores Windows precisam de acesso na porta 5985 (HTTP). Os servidores Linux precisam de acesso na porta 22 (TCP).
Método de descoberta	A análise de dependência sem agente é realizada conectando-se diretamente aos servidores usando as credenciais do servidor adicionadas no dispositivo. O dispositivo reúne as informações de dependência dos servidores Windows usando a comunicação remota do PowerShell e dos servidores Linux usando a conexão SSH. Nenhum agente é instalado nos servidores para extrair dados de dependência.

Requisitos de análise de dependência baseada em agente

A análise de dependência ajuda você a identificar dependências entre servidores locais que você deseja avaliar e migrar para o Azure. A tabela resume os requisitos para configurar a análise de dependência baseada em agente. Atualmente, o Hyper-V oferece suporte apenas à visualização de dependência baseada em agente.

Requisito	Detalhes
Antes da implantação	Você deve ter um projeto em vigor com a ferramenta Azure Migrate: Discovery and assessment adicionada ao projeto. Você implanta a visualização de dependência depois de configurar um dispositivo Azure Migrate para descobrir seus servidores locais. Saiba como criar um projeto pela primeira vez. Saiba como adicionar a ferramenta Azure Migrate: Discovery and assessment a um projeto existente. Saiba como configurar o dispositivo para descoberta e avaliação de servidores no Hyper-V.
Azure Government	A visualização de dependência não está disponível no Azure Government.
Log Analytics	O Azure Migrate and Modernize usa a solução de Mapa de Serviço nos logs do Azure Monitor para visualização de dependência. Você associa um espaço de trabalho novo ou existente do Log Analytics a um projeto. Não é possível modificar o espaço de trabalho de um projeto depois de adicioná-lo. O espaço de trabalho deve estar na mesma assinatura que o projeto. O espaço de trabalho deve residir nas regiões Leste dos EUA, Sudeste Asiático ou Europa Ocidental. Espaços de trabalho em outras regiões não podem ser associados a um projeto. O espaço de trabalho deve estar em uma região na qual o Mapa de Serviços é suportado. Você pode monitorar VMs do Azure em qualquer região. As VMs em si não estão limitadas às regiões suportadas pelo espaço de trabalho do Log Analytics. No Log Analytics, o espaço de trabalho associado ao Azure Migrate and Modernize é marcado com a chave do Projeto de Migração e o nome do projeto.
Agentes necessários	Em cada servidor que você deseja analisar, instale os seguintes agentes: Agente de monitoramento da Microsoft (MMA) Agente de dependência Se os servidores locais não estiverem conectados à Internet, você precisará baixar e instalar o gateway do Log Analytics neles. Saiba mais sobre como instalar o agente de dependência e o MMA.
Área de trabalho do Log Analytics	O espaço de trabalho deve estar na mesma assinatura que o projeto. O Azure Migrate and Modernize suporta espaços de trabalho residentes nas regiões Leste dos EUA, Sudeste Asiático e Europa Ocidental. O espaço de trabalho deve estar em uma região na qual o Mapa de Serviços é suportado. Você pode monitorar VMs do Azure em qualquer região. As VMs em si não estão limitadas às regiões suportadas pelo espaço de trabalho do Log Analytics. Não é possível modificar o espaço de trabalho de um projeto depois de adicioná-lo.
Custos	A solução de Mapa de Serviços não incorre em quaisquer encargos durante os primeiros 180 dias. A contagem começa a partir do dia em que você associa o espaço de trabalho do Log Analytics ao projeto. Após 180 dias, aplicam-se os custos padrão do Log Analytics. O uso de qualquer solução diferente do Mapa de Serviços no espaço de trabalho associado do Log Analytics incorre em cobranças padrão para o Log Analytics. Quando o projeto é excluído, o espaço de trabalho não é excluído junto com ele. Depois de excluir o projeto, o uso do Mapa de Serviço não é gratuito. Cada nó é cobrado de acordo com a camada paga do espaço de trabalho do Log Analytics. Se você tiver projetos criados antes da disponibilidade geral do Azure Migrate (GA em 28 de fevereiro de 2018), poderá incorrer em outras cobranças do Mapa de Serviço. Para garantir o pagamento apenas após 180 dias, recomendamos que crie um novo projeto. Os espaços de trabalho criados antes do GA ainda são cobrados.
Gestão	Ao registrar agentes no espaço de trabalho, você usa a ID e a chave fornecidas pelo projeto. Você pode usar o espaço de trabalho do Log Analytics fora do Azure Migrar e Modernizar. Se você excluir o projeto associado, o espaço de trabalho não será excluído automaticamente. Exclua-o manualmente. Não exclua o espaço de trabalho criado pelo Azure Migrate and Modernize, a menos que exclua o projeto. Se você fizer isso, a funcionalidade de visualização de dependência não funcionará conforme o esperado.
Ligação à Internet	Se os servidores não estiverem conectados à Internet, você precisará instalar o gateway do Log Analytics neles.
Azure Government	Não há suporte para análise de dependência baseada em agente.

Próximos passos

Prepare-se para a avaliação de servidores em execução no Hyper-V.