Matriz de compatibilidad para la detección de VMware

En este artículo se resumen los requisitos previos y los requisitos de soporte técnico para usar la herramienta Azure Migrate: Discovery and assessment para detectar y evaluar servidores en un entorno de VMware para la migración a Azure.

Nota:

Esta documentación de escenario de migración de VMware de un extremo a otro está actualmente en versión preliminar. Para más información sobre el uso de Azure Migrate, consulte la Documentación del producto de Azure Migrate.

Para evaluar los servidores, primero cree un proyecto de Azure Migrate. La herramienta Azure Migrate: Discovery and assessment se agrega automáticamente al proyecto. A continuación, implemente el dispositivo de Azure Migrate. El dispositivo detecta los servidores locales de forma continuada y envía los metadatos de configuración y rendimiento a Azure. Después de finalizar la detección, recopile los servidores detectados en grupos y ejecute evaluaciones por grupo.

A medida que planee la migración de los servidores de VMware a Azure, consulte la matriz de compatibilidad de migración.

Requisitos de VMware

VMware	Detalles
vCenter Server	Los servidores que desea detectar y evaluar deben administrarse mediante vCenter Server versión 8.0, 7.0, 6.7, 6.5, 6.0 o 5.5. Actualmente no se admite la detección de servidores proporcionando detalles del host ESXi en el dispositivo. Las direcciones IPv6 no se admiten para vCenter Server (para la detección y evaluación de servidores) y los hosts ESXi (para la replicación de servidores).
Permisos	La herramienta Azure Migrate: Discovery and assessment requiere una cuenta de solo lectura de vCenter Server. Si desea usar la herramienta para el inventario de software, el análisis de dependencias sin agente, aplicaciones web y la detección de SQL, la cuenta debe tener privilegios para las operaciones de invitado en máquinas virtuales (VM) de VMware.

Requisitos del servidor

VMware	Detalles
Sistemas operativos	Todos los sistemas operativos Windows y Linux se pueden evaluar para la migración.
Storage	Se admiten los discos conectados a controladores basados en SCSI, IDE y SATA.

Requisitos del dispositivo de Azure Migrate

Azure Migrate and Modernize usa el dispositivo de Azure Migrate para la detección y la evaluación. Puede implementar el dispositivo como servidor en el entorno de VMware mediante una plantilla de VMware Open Virtualization Appliance importada en vCenter Server. También puede usar un script de PowerShell. Obtenga más información sobre los requisitos del dispositivo para VMware.

A continuación, se detallan más requisitos para el dispositivo:

• En Azure Government, debe implementar el dispositivo mediante un script.
• El dispositivo debe poder acceder a direcciones URL específicas en nubes públicas y nubes gubernamentales.

Requisitos de acceso a puertos

Dispositivo	Conexión
Dispositivo con Azure Migrate	Conexiones entrantes en el puerto TCP 3389 para permitir las conexiones del Escritorio remoto al dispositivo. Conexiones entrantes en el puerto 44368 para tener acceso de forma remota a la aplicación de administración del dispositivo mediante la dirección URL https://<appliance-ip-or-name>:44368. Conexiones salientes en el puerto 443 (HTTPS) para enviar metadatos de detección y rendimiento a Azure Migrate and Modernize.
vCenter Server	Conexiones entrantes en el puerto TCP 443 para permitir que el dispositivo recopile los metadatos de configuración y rendimiento de las evaluaciones. De forma predeterminada, el dispositivo se conecta a vCenter en el puerto 443. Si vCenter Server escucha en un puerto diferente, puede modificar el puerto al configurar la detección.
Hosts de ESXi	Para una detección del inventario de software o un análisis de dependencias sin agente, el dispositivo se conecta a los hosts ESXi en el puerto TCP 443 para detectar el inventario de software y las dependencias en los servidores.

Requisitos de inventario de software

Además de detectar servidores, "Azure Migrate: detección y evaluación" puede realizar el inventario de software en servidores. El inventario de software proporciona la lista de aplicaciones, roles y características que se ejecutan en servidores de Windows y de Linux, detectados mediante Azure Migrate and Modernize. Le permite identificar y planear una ruta de migración adaptada a sus cargas de trabajo locales.

Soporte técnico	Detalles
Servidores admitidos	Puede realizar un inventario de software en hasta 10 000 servidores, si se ejecutan en servidores vCenter Server y están agregados a cada dispositivo de Azure Migrate.
Sistemas operativos	Se admiten los servidores que ejecutan todas las versiones de Windows y Linux.
Requisitos del servidor	Para el inventario de software, las herramientas de VMware deben estar instaladas y en ejecución en los servidores. La versión de las herramientas de VMware debe ser la versión 10.2.1 o posterior. Los servidores de Windows deben tener instalada la versión 2.0 de PowerShell u otra posterior. Instrumental de administración de Windows (WMI) debe estar habilitado y disponible en los servidores de Windows para recopilar los detalles de los roles y características instalados en los servidores.
Cuenta de vCenter Server	Para interactuar con los servidores para el inventario de software, la cuenta de solo lectura de vCenter Server que se usa para la evaluación debe tener privilegios para las operaciones de invitado en máquinas virtuales de VMware.
Acceso al servidor	Puede agregar varias credenciales de dominio y que no sean de dominio (Windows o Linux) en el administrador de configuración del dispositivo para el inventario de software. Debe tener una cuenta de usuario invitado para las instancias de Windows Server y una cuenta de usuario estándar (sin acceso sudo) para todos los servidores Linux.
Acceso a puertos	El dispositivo de Azure Migrate debe poder conectarse al puerto TCP 443 en los hosts ESXi que ejecutan los servidores en los que quiere realizar el inventario de software. El servidor que ejecuta vCenter Server devuelve una conexión de host ESXi para descargar el archivo que contiene los detalles del inventario de software. Si usa credenciales de dominio, el dispositivo de Azure Migrate debe poder conectarse a los siguientes puertos TCP y UDP: TCP 135: punto de conexión RPC TCP 389: LDAP TCP 636: SSL LDAP TCP 445: SMB TCP/UDP 88: autenticación Kerberos TCP/UDP 464: operaciones de cambio de Kerberos
Detección	El inventario de software se realiza desde vCenter Server con las herramientas de VMware instaladas en los servidores. El dispositivo recopila la información sobre el inventario de software del servidor que ejecuta vCenter Server mediante las API de vSphere. El inventario de software no tiene agente. No hay ningún agente instalado en el servidor y el dispositivo no se conecta directamente a los servidores.

Requisitos para la detección de bases de datos e instancias de SQL Server

El inventario de software identifica las instancias de SQL Server. Con esta información, el dispositivo intenta conectarse a las instancias de SQL Server respectivas mediante la autenticación de Windows o las credenciales de autenticación de SQL Server en el administrador de configuración del dispositivo. El dispositivo solo puede conectarse a las instancias de SQL Server a las que tiene línea de visión de red. Es posible que el inventario de software por sí mismo no necesite línea de visión de red.

Una vez conectado el dispositivo, este recopila datos de configuración y rendimiento de las instancias y de las bases de datos de SQL Server. El dispositivo actualiza los datos de configuración de SQL Server una vez cada 24 horas y captura los datos de rendimiento cada 30 segundos.

Soporte técnico	Detalles
Servidores admitidos	Solo se admite para servidores que ejecutan SQL Server en VMware, Microsoft Hyper-V y entornos físicos o sin sistema operativo y servidores de infraestructura como servicio (IaaS) de otras nubes públicas, como Amazon Web Services (AWS) y Google Cloud Platform (GCP). Puede detectar hasta 750 instancias de SQL Server o 15 000 bases de datos SQL, lo que sea menor, desde un único dispositivo. Se recomienda asegurarse de que un dispositivo tenga como ámbito descubrir menos de 600 servidores que ejecutan SQL para evitar problemas de escalado.
Servidores Windows	Se admiten Windows Server 2008 y versiones posteriores.
Servidores Linux	No se admite actualmente.
Mecanismo de autenticación	Se admiten tanto la autenticación de Windows como la de SQL Server. Puede proporcionar las credenciales de ambos tipos de autenticación en el administrador de configuración del dispositivo.
Acceso de SQL Server	Para detectar bases de datos e instancias de SQL Server, la cuenta de Windows o SQL Server deberá ser miembro del rol de servidor sysadmin o tener estos permisos para cada instancia de SQL Server.
Versiones de SQL Server	Se admiten SQL Server 2008 y versiones posteriores.
Ediciones deSQL Server	Se admiten las ediciones Enterprise, Standard, Developer y Express.
Configuración de SQL compatible	Se admite la detección de implementaciones de SQL independientes, de alta disponibilidad y protegidas por desastres. También se admite la detección de implementaciones de SQL de recuperación ante desastres de alta disponibilidad con tecnología de instancias de clúster de conmutación por error Always On y grupos de disponibilidad Always On.
Servicios SQL compatibles	Solo se admite el motor de base de datos de SQL Server. No se admite la detección de SQL Server Reporting Services, SQL Server Integration Services y SQL Server Analysis Services.

Nota:

De forma predeterminada, Azure Migrate and Modernize usan la forma más segura de conectarse a instancias de SQL. Es decir, Azure Migrate and Modernize cifra la comunicación entre el dispositivo de Azure Migrate y las instancias de SQL Server de origen al establecer la propiedad TrustServerCertificate en true. Además, la capa de transporte usa Secure Socket Layer para cifrar el canal y omitir la cadena de certificados para validar la confianza. Por este motivo, el servidor del dispositivo se debe configurar para confiar en la entidad de certificación raíz del certificado.

Sin embargo, puede modificar la configuración de conexión; para ello, seleccione Editar las propiedades de conexión de SQL Server en el dispositivo. Descubra más para saber lo que elegir.

Configuración del inicio de sesión personalizado para la detección de SQL Server

Use los siguientes scripts de ejemplo para crear un inicio de sesión y aprovisionarlo con los permisos necesarios.

Autenticación de 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 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

Los inicios de sesión de autenticación

--- 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 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 detección de aplicaciones web

El inventario de software identifica el rol de servidor web existente en los servidores detectados. Si un servidor tiene instalado un servidor web, Azure Migrate and Modernize detecta aplicaciones web en el servidor.

Puede agregar credenciales de dominio y que no sean de dominio al dispositivo. Asegúrese de que la cuenta usada tenga privilegios de administrador local en los servidores de origen. Azure Migrate and Modernize asigna automáticamente las credenciales a los servidores respectivos para que no tenga que hacerlo manualmente. Lo más importante es que estas credenciales nunca se envían a Microsoft y permanecen en el dispositivo que se ejecuta en el entorno de origen.

Una vez conectado el dispositivo, recopila datos de configuración para las aplicaciones web de ASP.NET (servidor web de IIS) y las aplicaciones web de Java (servidores Tomcat). Los datos de configuración de las aplicaciones web se actualizan una vez cada 24 horas.

Soporte técnico	Aplicaciones web ASP.NET	Aplicaciones web de Java
Pila	Servidores físicos, Hyper-V y VMware.	Servidores físicos, Hyper-V y VMware.
Servidores Windows	Se admiten Windows Server 2008 R2 y versiones posteriores.	No admitida.
Servidores Linux	No admitida.	Ubuntu Linux 16.04/18.04/20.04, Debian 7/8 y Red Hat Enterprise Linux 5/6/7.
Versiones del servidor web	IIS 7.5 y versiones posteriores.	Tomcat 8 o versiones posteriores.
Protocolo	Puerto 5985 (HTTP) de WinRM	Puerto 22 (TCP) de SSH
Privilegios requeridos	Administrador local.	Usuario raíz o sudo.

Nota:

Los datos siempre se cifran en reposo y durante el tránsito.

Requisitos para el análisis de dependencias (sin agentes)

El análisis de dependencias le ayuda a analizar las dependencias entre los servidores detectados. Puede visualizar fácilmente las dependencias con una vista de mapa en un proyecto de Azure Migrate. Puede usar dependencias para agrupar servidores relacionados para la migración a Azure. En la tabla siguiente, se resumen los requisitos para configurar el análisis de dependencias sin agente.

Soporte técnico	Detalles
Servidores admitidos	Puede habilitar el análisis de dependencias sin agente en hasta 1000 servidores (en varias instancias de vCenter Server), detectados por dispositivo.
Servidores Windows	Windows Server 2022 Windows Server 2019 Windows Server 2016 Windows Server 2012 R2 Windows Server 2012 Windows Server 2008 R2 (64 bits) Windows Server 2008 (32 bits)
Servidores Linux	Red Hat Enterprise Linux 5.1, 5.3, 5.11, 6.x, 7.x, 8.x, 9.x Ubuntu 12.04, 14.04, 16.04, 18.04, 20.04, 22.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
Requisitos del servidor	Las herramientas de VMware (10.2.1 y versiones posteriores) deben estar instaladas y en ejecución en los servidores que quiere analizar. Los servidores deben tener instalada la versión 2.0 de PowerShell o una versión posterior. La opción WMI debe estar habilitada y disponible en los servidores Windows.
Cuenta de vCenter Server	La cuenta de solo lectura que usa Azure Migrate and Modernize para la evaluación debe tener privilegios para las operaciones de invitado en las máquinas virtuales de VMware.
Acceso a un servidor de Windows	Cuenta de usuario invitado
Acceso a un servidor de Linux	Cuenta de usuario sudo con permisos para ejecutar comandos ls y netstat. Si proporciona una cuenta de usuario sudo, asegúrese de habilitar NOPASSWD para que la cuenta ejecute los comandos necesarios sin solicitar una contraseña cada vez que se invoca un comando sudo. Como alternativa, puede crear una cuenta de usuario que tenga los permisos CAP_DAC_READ_SEARCH y CAP_SYS_PTRACE en los archivos /bin/netstat y /bin/ls, establecidos mediante los comandos siguientes: sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/ls sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/netstat
Acceso a puertos	El dispositivo de Azure Migrate debe poder conectarse al puerto TCP 443 en los hosts ESXi que ejecutan los servidores que tienen dependencias que quiere detectar. El servidor que ejecuta vCenter Server devuelve una conexión de host ESXi para descargar el archivo que contiene los datos de las dependencias.
Método de detección	La información sobre las dependencias entre los servidores se recopila mediante las herramientas de VMware instaladas en el servidor que ejecuta vCenter Server. El dispositivo recopila la información del servidor mediante las API de vSphere. No hay ningún agente instalado en el servidor y el dispositivo no se conecta directamente a los servidores.

Nota:

En algunas versiones recientes del sistema operativo Linux, el comando netstat se reemplazó por el comando ss; tenga eso en cuenta al preparar los servidores.

Requisitos para el análisis de dependencia (con agentes)

El análisis de dependencias le ayuda a identificar las dependencias entre los servidores locales que quiere evaluar y migrar a Azure. En la tabla siguiente se resumen los requisitos para configurar el análisis de dependencias basadas en agentes.

Requisito	Detalles
Antes de la implementación	Debe tener un proyecto al que se le haya agregado la herramienta Azure Migrate: detección y evaluación. La visualización de dependencias se implementa después de configurar un dispositivo de Azure Migrate para detectar los servidores locales. Aprenda a crear un proyecto por primera vez. Aprenda a agregar una herramienta de detección y evaluación a un proyecto existente. Aprenda a configurar un dispositivo de Azure Migrate para la evaluación de Hyper-V, VMware o de servidores físicos.
Servidores admitidos	Compatible con todos los servidores del entorno local.
Log Analytics	Azure Migrate and Modernize utiliza la solución Service Map de los registros de Azure Monitor para la visualización de dependencias. Puede asociar a un proyecto un área de trabajo de Log Analytics nueva o existente. No se puede modificar el área de trabajo de un proyecto después de que agrega el área de trabajo. El área de trabajo debe estar en la misma suscripción que el proyecto. El área de trabajo debe encontrarse en las regiones Este de EE. UU., Sudeste Asiático u Oeste de Europa. Las áreas de trabajo de otras regiones no se pueden asociar a un proyecto. El área de trabajo debe estar en una región en la que se admita Service Map. Puede supervisar máquinas virtuales de Azure en cualquier región. Las máquinas virtuales no se limitan a las regiones admitidas por el área de trabajo de Log Analytics. En Log Analytics, el área de trabajo asociada a Azure Migrate se etiqueta con la clave del proyecto y el nombre del proyecto.
Agentes necesarios	En cada servidor que quiera analizar, instale los siguientes agentes: - Agente de Azure Monitor (AMA) - Dependency Agent Si los servidores locales no están conectados a Internet, descargue e instale la puerta de enlace de Log Analytics en ellas. Obtenga más información sobre cómo instalar el Dependency Agent y el agente de Azure Monitor.
Área de trabajo de Log Analytics	El área de trabajo debe estar en la misma suscripción que el proyecto. Azure Migrate admite áreas de trabajo que se encuentran en las regiones Este de EE. UU., Sudeste Asiático y Oeste de Europa. El área de trabajo debe estar en una región en la que se admita Service Map. Puede supervisar máquinas virtuales de Azure en cualquier región. Las máquinas virtuales no se limitan a las regiones admitidas por el área de trabajo de Log Analytics. No se puede modificar el área de trabajo de un proyecto después de que agrega el área de trabajo.
Costee	La solución de Service Map no incurre en ningún cargo durante los primeros 180 días. El recuento comienza desde el día en que asocia el área de trabajo de Log Analytics con el proyecto. Transcurridos los 180 días, se aplicarán las tarifas normales de Log Analytics. Usar una solución que no sea Service Map en el área de trabajo de Log Analytics asociada generará los gastos estándar de Log Analytics. Cuando se elimina el proyecto, el área de trabajo no se elimina automáticamente. Después de eliminar el proyecto, el uso de Service Map no es gratuito. Cada nodo se cobra según el nivel de pago del área de trabajo de Log Analytics. Si tiene proyectos creados antes de que Azure Migrate estuviera disponible con carácter general (GA el 28 de febrero de 2018), puede incurrir en cargos de Service Map adicionales. Para garantizar el cargo solo después de 180 días, es recomendable que cree un proyecto. Las áreas de trabajo creadas antes de la disponibilidad general siguen siendo facturables
Administración	Al registrar agentes en el área de trabajo, use el identificador y la clave proporcionados por el proyecto. Puede usar el área de trabajo de Log Analytics fuera de Azure Migrate and Modernize. Si elimina el proyecto asociado, el área de trabajo no se elimina automáticamente. Elimínela manualmente. No elimine el área de trabajo creada por Azure Migrate and Modernize, a menos que elimine el proyecto. Si lo hace, la funcionalidad de visualización de dependencias no funciona según lo previsto.
Conectividad de Internet	Si los servidores no están conectados a Internet, instale la puerta de enlace de Log Analytics en ellos.
Azure Government	El análisis de dependencias basado en agente no se admite.

Limitaciones

Requisito	Detalles
Límites del proyecto	Puede crear varios proyectos de Azure Migrate en una suscripción a Azure. Puede detectar y evaluar hasta 50 000 servidores de un entorno de VMware en un único proyecto. Un proyecto puede incluir servidores físicos y servidores de un entorno de Hyper-V, hasta sus respectivos límites de evaluación.
Detección	El dispositivo de Azure Migrate puede detectar hasta 10 000 servidores que se ejecuten en varias instancia de vCenter Server. El dispositivo admite la adición de varias instancias de vCenter Server. Puede agregar hasta 10 instancias de vCenter Server por dispositivo. Esta cantidad también es válida para Azure VMware Solution.
Valoración	Puede agregar hasta 35 000 servidores en un solo grupo. Puede evaluar hasta 35 000 máquinas virtuales en una única evaluación.

Más información sobre las valoraciones.

Importación de servidores mediante RVTools XLSX (versión preliminar)

Como parte del recorrido de migración a Azure mediante el dispositivo de Azure Migrate, primero detectará servidores, inventario y cargas de trabajo. Sin embargo, para obtener una evaluación rápida antes de implementar el dispositivo, puede importar los servidores mediante el archivo RVTools XLSX (versión preliminar).

Ventajas principales

Usar un archivo RVTools XLSX:

• Ayuda a crear un caso de negocio o evaluar los servidores antes de implementar el dispositivo.
• Ayuda como alternativa cuando hay una restricción organizativa para implementar el dispositivo de Azure Migrate.
• Útil cuando no se pueden compartir credenciales que permitan el acceso a servidores locales.
• Resulta útil cuando las restricciones de seguridad impiden recopilar y enviar datos recopilados por el dispositivo a Azure.

Limitaciones

En esta sección, se describen las limitaciones que se deben tener en cuenta.

Consideraciones de casos empresariales

Si va a importar servidores mediante un archivo RVTools XLSX y compilar un caso de negocio, puede experimentar algunas limitaciones:

• La duración del historial de rendimiento en la configuración de Azure no es aplicable.
• Los servidores se clasifican como desconocidos en el gráfico de conclusiones de uso de casos empresariales y tienen el tamaño tal cual sin ajustar el tamaño adecuado para el costo de Azure o Azure VMware Solution.

Consideraciones de evaluación

Si va a importar servidores mediante un archivo XLSX de RVTools para crear una evaluación con los criterios siguientes:

• Criterio de ajuste de tamaño como basado en el rendimiento basado en la CPU y la memoria configuradas (en función de las CPU y las columnas Memory de RVTools XLSX).
• Criterios de almacenamiento (MiB en uso y MB en uso para versiones anteriores a 4.1.2)

No podrá proporcionar información sobre el historial de rendimiento ni el percentil.

Para obtener una idoneidad y preparación precisas del sistema operativo en la máquina virtual de Azure y la evaluación de Azure VMware Solution, escriba la versión del sistema operativo y la arquitectura en las columnas respectivas.

Pasos siguientes

• Revise los procedimientos recomendados de evaluación.
• Aprenda a prepararse para una evaluación de VMware.