PlateSpin Migrate admite la migración de las siguientes cargas de trabajo Windows y Linux a plataformas que no están en la nube; por ejemplo, equipos físicos y máquinas virtuales en hipervisores compatibles. Consulte Plataformas de virtualización del destino admitidas.
Las siguientes funciones de migración se admiten para la migración a plataformas que no están en la nube:
Migraciones par a par (P2V, V2V, V2P, P2P).
Sincronización de cargas de trabajo par a par (P2V, V2V, P2P, V2P).
NOTA:no todas las cargas de trabajo se admiten en todas las plataformas de virtualización de destino. La migración de cargas de trabajo a una plataforma de virtualización de destino está sujeta a que el proveedor del host admita el sistema operativo invitado en el host de destino.
Consulte las siguientes secciones:
PlateSpin Migrate admite las siguientes plataformas de Microsoft Windows para la migración a máquinas virtuales en hosts de virtualización o equipos físicos, excepto como se indica en la Tabla 2-1. Consulte también Almacenamiento de cargas de trabajo admitido y Arquitecturas de cargas de trabajo compatibles.
Tabla 2-1 Plataformas no en la nube: cargas de trabajo Windows admitidas
|
Sistema operativo |
Observaciones |
|---|---|
|
Servidores |
|
|
Windows Server 2016 |
La migración a una máquina virtual VMware requiere VMware vCenter 6.0 o posterior. |
|
|
|
Incluidos sistemas de controladores de dominio (DC) y las ediciones Small Business Server (SBS) No se admite la migración de Windows Server 2008 R2 SP0 a Hyper-V porque Microsoft ya no la admite. Consulte el sitio Web de Microsoft TechNet. |
|
|
|
Clústeres |
|
|
Windows Server 2016 Cluster Admite los modelos de quórum:
|
Tanto el cliente de Migrate como la interfaz Web admiten la migración automatizada de clústeres de Windows a contenedores de VMware vCenter. El cliente de Migrate también admite la migración semiautomatizada de clústeres de Windows a equipos físicos mediante el flujo de trabajo X2P. Consulte el Sección 23.0, Preparación para migrar clústeres de Windows. Para la migración de clústeres de Windows Server 2016 a VMware se requiere VMware 6.0 o posterior. PlateSpin Migrate no es compatible con la migración de clústeres de Windows Server a las siguientes infraestructuras de destino:
Para los clústeres, PlateSpin Migrate solo admite la réplica de nivel de bloques. No se admite la réplica de nivel de archivos. La compatibilidad incluye la transferencia de datos basada en bloques con un controlador (solo en las SAN de canal de fibra) o sin un controlador para las réplicas incrementales de clústeres. ADVERTENCIA:no intente utilizar el controlador basado en bloques en clústeres con unidades iSCSI compartidas, ya que el clúster terminaría siendo inservible. |
Admite los modelos de quórum:
|
|
Admite los modelos de quórum:
|
|
Admite el modelo de quórum:
|
|
|
corporativos |
|
|
Windows 8 y 8.1 |
Requiere el plan de energía de alto rendimiento. |
|
Windows 7 |
Se admiten solo las versiones Professional, Enterprise y Ultimate. |
PlateSpin Migrate admite las siguientes plataformas de Linux para la migración a máquinas virtuales en hosts de virtualización o equipos físicos, excepto como se indica en la Tabla 2-2. Consulte también Almacenamiento de cargas de trabajo admitido y Arquitecturas de cargas de trabajo compatibles.
Tabla 2-2 Plataformas no en la nube: cargas de trabajo Linux admitidas
|
Distribución de Linux |
Versiones |
Observaciones |
|---|---|---|
|
Red Hat Enterprise Linux (RHEL) |
AS/ES/WS 4.x, 5.0 a 5.11, 6.0 a 6.9 y 7.0 a 7.3 |
PlateSpin Migrate no admite el sistema de archivos XFS versión 5 (v5) de RHEL 7.3 y distribuciones basadas en RHEL 7.3. Para las cargas de trabajo Red Hat Enterprise Linux 6.7, Oracle Linux 6.7 y CentOS 6.7 con volúmenes LVM, PlateSpin Migrate solo admite la réplica incremental para la versión más reciente del núcleo (2.6.32-642.13.1.el6.) para la distribución 6.7. Es el mismo núcleo que se utiliza en la distribución RHEL 6.8. Para RHEL 5 se admite la migración de una carga de trabajo de origen paravirtualizada a una plataforma de destino como carga de trabajo totalmente virtualizada. Consulte Cargas de trabajo de origen paravirtualizadas. |
|
SUSE Linux Enterprise Server (SLES) |
9, 10, 11 (SP1, SP2, SP3 y SP4) |
No se admite SLES 11 SP2 (32 bits) con el núcleo 3.0.13-0.27-pae. El núcleo de esta versión de SLES debe actualizarse a 3.0.51-0.7.9-pae para que la conversión funcione. Para SLES 10 y 11 se admite la migración de una carga de trabajo de origen paravirtualizada a una plataforma de destino como carga de trabajo totalmente virtualizada. Consulte Cargas de trabajo de origen paravirtualizadas. |
|
CentOS |
Consulte Red Hat Enterprise Linux. |
El mismo nivel de compatibilidad que las cargas de trabajo que ejecutan RHEL, excepto que CentOS 4.x no se admite para Hyper-V. Para la migración de CentOS 7.x a VMware se requiere VMware vCenter 5.5 o posterior. |
|
Oracle Linux (OL, anteriormente Oracle Enterprise Linux) |
Consulte Red Hat Enterprise Linux. |
El mismo nivel de compatibilidad para los núcleos estándar que para las cargas de trabajo que ejecutan RHEL, excepto que OEL 4.x no se admite para Hyper-V. El mismo nivel de compatibilidad que para los núcleos Unbreakable Enterprise Kernel (UEK) en las distribuciones de RHEL compatibles para OL 6.7 y versiones posteriores. |
NOTA:se aplican las siguientes directrices para las migraciones de Linux a plataformas de destino que no sean en la nube:
Las imágenes de cargas de trabajo no son compatibles con las cargas de trabajo Linux.
No se admite la conversión de sistemas Linux basados en BIOS a UEFI.
Para migrar cargas de trabajo a Microsoft Azure y VMware vCloud Director, utilice la interfaz Web de PlateSpin Migrate. Para migrar cargas de trabajo a Amazon Web Services, use el cliente de PlateSpin Migrate.
Solo se admiten migraciones P2C y V2C.
NOTA:
No todas las cargas de trabajo se admiten en todas las plataformas de nube de destino. La migración de cargas de trabajo a un contenedor de nube destino está sujeta a que el proveedor de la nube admita el sistema operativo invitado en la plataforma de nube de destino.
Las cargas de trabajo Windows y Linux de UEFI se migran como cargas de trabajo de BIOS a la plataforma de nube de destino.
Antes de migrar una carga de trabajo de origen Linux paravirtualizada que se ejecute en Citrix XenServer o KVM a una plataforma de destino como sistema invitado totalmente virtualizado, consulte Cargas de trabajo de origen paravirtualizadas.
Consulte las siguientes secciones:
PlateSpin Migrate admite las siguientes plataformas para la migración a la nube de Microsoft Azure para el entorno global y el entorno de Azure China independiente. Consulte también Almacenamiento de cargas de trabajo admitido y Arquitecturas de cargas de trabajo compatibles.
Para obtener información sobre cómo migrar cargas de trabajo a Microsoft Azure, consulte Requisitos previos para la migración a Microsoft Azure y Migración a Microsoft Azure.
Tabla 2-3 Azure: plataformas Windows compatibles
|
Sistema operativo |
Observaciones |
|---|---|
|
Microsoft Windows Server 2016 |
|
|
Microsoft Windows Server 2012 R2 |
|
|
Microsoft Windows Server 2012 |
|
|
Microsoft Windows Server 2008 R2 |
|
Tabla 2-4 Azure: plataformas Linux compatibles
|
Distribución de Linux |
Versiones |
Observaciones |
|---|---|---|
|
Red Hat Enterprise Linux (RHEL) |
6.7 a 6.9 y 7.1 a 7.3 |
PlateSpin Migrate no admite el sistema de archivos XFS versión 5 en RHEL 7.3 ni en distribuciones basadas en RHEL 7.3. Para las cargas de trabajo Red Hat Enterprise Linux 6.7, Oracle Linux 6.7 y CentOS 6.7 con volúmenes LVM, la réplica incremental solo se admite para la versión más reciente del núcleo (2.6.32-642.13.1.el6) para la distribución 6.7. Es el mismo núcleo que se utiliza en la distribución RHEL 6.8. |
|
SUSE Linux Enterprise Server (SLES) |
11 (SP3 y SP4) |
Para SLES 11 se admite la migración de una carga de trabajo de origen paravirtualizada a una plataforma de destino como carga de trabajo totalmente virtualizada. Consulte Cargas de trabajo de origen paravirtualizadas. |
|
CentOS |
Consulte Red Hat Enterprise Linux. |
El mismo nivel de compatibilidad que las cargas de trabajo que ejecutan RHEL. |
|
Oracle Linux (OL, anteriormente Oracle Enterprise Linux) |
Consulte Red Hat Enterprise Linux. |
El mismo nivel de compatibilidad para los núcleos estándar que para las cargas de trabajo que ejecutan RHEL. El mismo nivel de compatibilidad que para los núcleos Unbreakable Enterprise Kernel (UEK) en las distribuciones de RHEL compatibles para OL 6.7 y versiones posteriores. |
NOTA:PlateSpin Migrate no admite la migración de cargas de trabajo Linux de origen a Azure si la partición de arranque (/boot) no se encuentra en la partición raíz (/).
PlateSpin Migrate admite las siguientes plataformas para la migración a VMware vCloud Director. Consulte también la Sección 2.1.3, Almacenamiento de cargas de trabajo admitido y la Sección 2.1.4, Arquitecturas de cargas de trabajo compatibles.
Para obtener información sobre cómo migrar cargas de trabajo a VMware Cloud Director, consulte el Sección 10.0, Requisitos previos para la migración a VMware vCloud Director y el Sección 29.0, Migración a VMware vCloud Director.
Tabla 2-5 vCloud: plataformas Windows compatibles
|
Sistema operativo |
Observaciones |
|---|---|
|
Microsoft Windows Server 2016 |
|
|
Microsoft Windows Server 2012 R2 |
|
|
Microsoft Windows Server 2012 |
|
|
Microsoft Windows Server 2008 R2 |
|
|
Microsoft Windows Server 2008 |
|
|
Microsoft Windows Server 2003 R2 |
DoNotReplaceSysFiles debe definirse como True (Verdadero). |
|
Microsoft Windows Server 2003 con Service Pack 1 (SP1) o posterior |
DoNotReplaceSysFiles debe definirse como True (Verdadero). |
Tabla 2-6 vCloud: plataformas Linux compatibles
|
Distribución de Linux |
Versiones |
Observaciones |
|---|---|---|
|
Red Hat Enterprise Linux (RHEL) |
4.x, 5.0 a 5.11, 6.0 a 6.9 y 7.0 a 7.3 |
PlateSpin Migrate no admite el sistema de archivos XFS versión 5 en RHEL 7.3 ni en distribuciones basadas en RHEL 7.3. Para las cargas de trabajo Red Hat Enterprise Linux 6.7, Oracle Linux 6.7 y CentOS 6.7 con volúmenes LVM, la réplica incremental solo se admite para la versión más reciente del núcleo (2.6.32-642.13.1.el6) para la distribución 6.7. Es el mismo núcleo que se utiliza en la distribución RHEL 6.8. Para RHEL 5 se admite la migración de una carga de trabajo de origen paravirtualizada a una plataforma de destino como carga de trabajo totalmente virtualizada. Consulte Cargas de trabajo de origen paravirtualizadas. |
|
SUSE Linux Enterprise Server (SLES) |
10 y 11 (SP1, SP2, SP3 y SP4) |
Para SLES 10 y 11 se admite la migración de una carga de trabajo de origen paravirtualizada a una plataforma de destino como carga de trabajo totalmente virtualizada. Consulte Cargas de trabajo de origen paravirtualizadas. |
|
CentOS |
Consulte Red Hat Enterprise Linux. |
El mismo nivel de compatibilidad que las cargas de trabajo que ejecutan RHEL. |
|
Oracle Linux (OL, anteriormente Oracle Enterprise Linux) |
Consulte Red Hat Enterprise Linux. |
El mismo nivel de compatibilidad para los núcleos estándar que para las cargas de trabajo que ejecutan RHEL. El mismo nivel de compatibilidad que para los núcleos Unbreakable Enterprise Kernel (UEK) en las distribuciones de RHEL compatibles para OL 6.7 y versiones posteriores. |
PlateSpin Migrate admite las siguientes plataformas para la migración a Amazon Web Services. Consulte también la Sección 2.1.3, Almacenamiento de cargas de trabajo admitido y la Sección 2.1.4, Arquitecturas de cargas de trabajo compatibles.
Para obtener información sobre cómo migrar cargas de trabajo a Amazon Web Services, consulte el Sección 8.0, Requisitos previos para la migración a Amazon Web Services y el Sección 27.0, Migración a Amazon Web Services.
Tabla 2-7 AWS: plataformas Windows compatibles
|
Sistema operativo |
Observaciones |
|---|---|
|
Microsoft Windows Server 2016 |
|
|
Microsoft Windows Server 2012 R2 |
|
|
Microsoft Windows Server 2012 |
|
|
Microsoft Windows Server 2008 R2 |
|
|
Microsoft Windows Server 2008 |
|
|
Microsoft Windows Server 2003 R2 |
|
|
Microsoft Windows Server 2003 con Service Pack 1 (SP1) o posterior |
|
Tabla 2-8 AWS: plataformas Linux compatibles
|
Distribución de Linux |
Versiones |
Observaciones |
|---|---|---|
|
Red Hat Enterprise Linux (RHEL) |
5.1 a 5.11, 6.1 a 6.9 y 7.0 a 7.3 |
PlateSpin Migrate no admite el sistema de archivos XFS versión 5 en RHEL 7.3 ni en distribuciones basadas en RHEL 7.3. Para las cargas de trabajo Red Hat Enterprise Linux 6.7, Oracle Linux 6.7 y CentOS 6.7 con volúmenes LVM, la réplica incremental solo se admite para la versión más reciente del núcleo (2.6.32-642.13.1.el6) para la distribución 6.7. Es el mismo núcleo que se utiliza en la distribución RHEL 6.8. Para RHEL 5 se admite la migración de una carga de trabajo de origen paravirtualizada a una plataforma de destino como carga de trabajo totalmente virtualizada. Consulte Cargas de trabajo de origen paravirtualizadas. |
|
SUSE Linux Enterprise Server (SLES) |
11 (SP2 y SP3) |
Para SLES 11 se admite la migración de una carga de trabajo de origen paravirtualizada a una plataforma de destino como carga de trabajo totalmente virtualizada. Consulte Cargas de trabajo de origen paravirtualizadas. |
|
CentOS |
Consulte Red Hat Enterprise Linux. |
El mismo nivel de compatibilidad que las cargas de trabajo que ejecutan RHEL. |
|
Oracle Linux (OL, anteriormente Oracle Enterprise Linux) |
Consulte Red Hat Enterprise Linux. |
El mismo nivel de compatibilidad para los núcleos estándar que para las cargas de trabajo que ejecutan RHEL. El mismo nivel de compatibilidad que para los núcleos Unbreakable Enterprise Kernel (UEK) en las distribuciones de RHEL compatibles para OL 6.7 y versiones posteriores. |
Las siguientes directrices sobre almacenamiento de la carga de trabajo se aplican a todas las migraciones:
PlateSpin Migrate admite los esquemas de particionamiento MBR (registro de arranque maestro) y GPT (tabla de particiones GUID) para cargas de trabajo Windows y Linux. Las cargas de trabajo y el almacenamiento para la migración deben configurarse en discos particionados con MBR o GPT. Aunque GPT permite hasta 128 particiones por cada disco, PlateSpin Migrate solo admite 57 o menos particiones GPT por disco.
PlateSpin Migrate solo admite el sistema de archivos NTFS en cualquier sistema Windows compatible. No se admiten los sistemas de archivos Windows FAT ni ReFS para la migración.
NOTA:si los volúmenes están cifrados con la función de cifrado de disco BitLocker, deben desbloquearse (descifrarse) para la migración.
PlateSpin Migrate admite los sistemas de archivos EXT2, EXT3, EXT4, REISERFS y XFS.
NOTA:
PlateSpin Migrate no admite el sistema de archivos XFS versión 5 en RHEL 7.3 ni en distribuciones basadas en RHEL 7.3.
No se admite la migración de volúmenes cifrados. Si los volúmenes están cifrados, deben desbloquearse (descifrar) para la migración.
PlateSpin Migrate admite varios tipos de discos de datos, incluidos los discos básicos, los discos dinámicos Windows de origen, LVM2, RAID, NAS y SAN.
NOTA:las advertencias siguientes se aplican a los discos de almacenamiento:
Discos dinámicos de Windows: PlateSpin Migrate no admite los discos dinámicos Windows en el destino.
Para los discos dinámicos, el almacenamiento no sigue la estrategia de asignación "igual que el origen". Tanto los volúmenes dinámicos simples como los distribuidos residirán en la carga de trabajo de destino como discos de volúmenes básicos simples. El disco de destino se particiona como GPT si el tamaño total combinado de los discos miembro del volumen dinámico supera el límite de tamaño de la partición MBR. Para obtener más información, consulte el artículo de Microsoft TechNet: Understanding the 2 TB limit in Windows Storage (Explicación del límite de 2 TB en el almacenamiento de Windows).
RAID de software de Linux: PlateSpin Migrate no admite cargas de trabajo Linux con volúmenes en RAID de software.
Migrate admite cargas de trabajo Linux con /boot en el primer disco (sda).
La partición de arranque de una carga de trabajo Linux de origen debe tener un mínimo de 100 MB de espacio libre. Durante el proceso de migración, PlateSpin Migrate usa el espacio libre para crear una imagen initrd nueva con todos los controladores necesarios para preparar el equipo para el proceso de arranque inicial.
El almacenamiento sin volúmenes, como una partición de intercambio asociada con la carga de trabajo de origen, se vuelve a crear en la carga de trabajo migrada.
El diseño de los grupos de volúmenes y de los volúmenes lógicos para LVM2 se conserva según la estrategia de asignación "igual para el origen" a fin de que se pueda volver a crear durante la migración.
Los volúmenes de disco en bruto LVM se admiten en configuraciones de tipo "igual que el origen" en las cargas de trabajo Linux.
Para cargas de trabajo Linux, Migrate admite solo la transferencia de datos en tiempo real basada en bloques con un controlador blkwatch. Para obtener una lista de controladores blkwatch precompilados, consulte la Sección D.2.2, Lista de distribuciones.
Algunas versiones de Linux admitidas requieren compilar el módulo blkwatch de PlateSpin para su núcleo específico. Estas cargas de trabajo se identifican explícitamente.
Hay disponibles controladores blkwatch precompilados para el núcleo estándar y para Unbreakable Enterprise Kernel (UEK), como se indica en la Sección D.2.2, Lista de distribuciones. Para otras distribuciones Oracle Linux, hay disponibles controladores precompilados solo para el núcleo compatible de Red Hat (RHCK) correspondiente.
PlateSpin Migrate es compatible con el protocolo de comunicaciones SAN de canal de fibra (FC).
Para las migraciones P2P y P2V de las cargas de trabajo indicadas en la Tabla 2-9, se admite el protocolo Fibre Channel over Ethernet (FCoE). La migración se ha probado con dispositivos FCoE de Qlogic.
Tabla 2-9 Cargas de trabajo de origen admitidas para FCoE
|
Cargas de trabajo de origen con FCoE |
Versión |
Observaciones |
|---|---|---|
|
|
Solo servidores independientes, no clústeres. |
|
SUSE Linux Enterprise Server |
11 SP4 |
|
Hay disponibles controladores de FCoE y funciones de asistencia en la imagen ISO de PlateSpin. Consulte Descarga de imágenes ISO de PlateSpin.
PlateSpin Migrate admite la migración de una carga de trabajo de origen configurada para E/S de varias vías (MPIO) en un entorno SAN de canal de fibra (FC). La carga de trabajo de destino puede encontrarse en el mismo entorno SAN o en uno diferente. La carga de trabajo de origen y la de destino deben tener solo discos SAN.
NOTA:la carga de trabajo debe arrancar desde un disco SAN. No se admiten cargas de trabajo con una mezcla de discos locales y discos SAN, excepto si se indica lo contrario en la Tabla 2-10.
Hay disponibles funciones de asistencia de MPIO en la imagen ISO de PlateSpin. Consulte Descarga de imágenes ISO de PlateSpin.
Consulte la Tabla 2-10 para obtener una lista de plataformas que se han probado para las migraciones en entornos MPIO.
Tabla 2-10 Cargas de trabajo de origen compatibles con MPIO
|
Plataforma |
Versiones |
Observaciones |
|---|---|---|
|
Microsoft Windows Server |
|
|
|
Microsoft Windows Server en un clúster de failover |
2012 R2 |
La migración del clúster también se ha probado con un disco de sistema local con todos los discos de datos en una SAN de FC. Consulte el artículo 7022400 de la base de conocimientos para obtener información sobre cómo restaurar el clúster después de migrar el nodo activo a un almacenamiento de FC compartido nuevo. |
|
Red Hat Enterprise Linux (RHEL) |
|
|
MPIO requiere que se instale software multivía adicional en el sistema operativo, en forma de característica de Windows o de paquete o módulo de Linux. Las herramientas de gestión de MPIO se usan para habilitar MPIO y configurar sus directivas para los dispositivos SAN con varias vías. Consulte la documentación del proveedor para obtener información sobre cómo configurar el hardware a fin de proporcionar varias vías a un dispositivo de almacenamiento y sobre cómo instalar y configurar MPIO.
Consulte la Tabla 2-11 para obtener información sobre las situaciones de migración de MPIO admitidas y qué se debe esperar de la carga de trabajo de destino.
Tabla 2-11 Escenarios de migración de MPIO admitidos
|
Carga de trabajo de origen |
Carga de trabajo de destino |
|
|---|---|---|
|
Software de MPIO |
Varias vías de almacenamiento disponibles |
Una vía de almacenamiento disponible |
|
El software de MPIO está instalado. MPIO está habilitado y configurado. |
El software de MPIO se reconfigura automáticamente en la carga de trabajo de destino del entorno de MPIO de destino. Para inhabilitar MPIO, debe reconfigurar manualmente MPIO en la carga de trabajo. |
El software de MPIO se conserva y MPIO se vuelve a configurar para una única vía. Puede dejar el software o eliminarlo de forma manual, según precise para la red que tiene prevista. Si desea añadir hardware de MPIO después de que se complete la migración, debe volver a configurar manualmente MPIO en la carga de trabajo. |
|
El software de MPIO está instalado. MPIO está inhabilitado. |
El software de MPIO permanece instalado, pero inhabilitado. Para habilitar MPIO, debe configurar manualmente MPIO en la carga de trabajo. |
El software de MPIO permanece instalado, pero inhabilitado. Puede dejar el software o eliminarlo de forma manual, según precise para la red que tiene prevista. Si desea añadir hardware de MPIO después de que se complete la migración, debe configurar manualmente MPIO en la carga de trabajo. |
|
El software de MPIO no está instalado. |
El software de MPIO no está instalado. Para habilitar MPIO, debe instalar y configurar manualmente MPIO en la carga de trabajo. |
No se realizan cambios relacionados con MPIO para la carga de trabajo. |
Las siguientes directrices sobre arquitectura de la carga de trabajo se aplican a todas las migraciones:
Las cargas de trabajo de origen Linux deben ejecutarse en un servidor de shell segura (SSH).
PlateSpin Migrate admite la migración de cargas de trabajo físicas y virtuales basadas en x86 en el centro de datos:
64 bits
32 bits
Para contenedores de máquinas virtuales que usen VMware 5.1, 5.5 y 6.0 con un nivel mínimo de hardware de máquina virtual de 8, PlateSpin Migrate permite especificar el número de zócalos y de núcleos por zócalo para la carga de trabajo de destino. El total de núcleos se calcula automáticamente. Este parámetro se aplica durante la primera instalación de una carga de trabajo con el valor de réplica inicial de Full Replication (Réplica completa).
NOTA:el número máximo de núcleos que puede usar la carga de trabajo depende de factores externos, como el sistema operativo invitado, la versión del hardware de la máquina virtual, la licencia de VMware para el host de ESXi y la capacidad de cálculo máxima del host de ESXi para vSphere. Consulte Máximos de configuración de ESXi/ESX (artículo 1003497 de la base de conocimientos de VMware).
Algunas distribuciones de un sistema operativo invitado podrían no respetar la configuración de núcleos o de núcleos por zócalo. Por ejemplo, los sistemas operativos invitados que usan SLES 10 SP4 conservan la configuración de núcleos y zócalos original de la instalación, mientras que otras distribuciones de SLES y RHEL sí respetan la configuración.
Para contenedores de máquinas virtuales que usen VMware 4.1, PlateSpin Migrate permite especificar el número necesario de vCPU (CPU virtuales) que se deben asignar a la carga de trabajo de destino. Este parámetro se aplica durante la primera instalación de una carga de trabajo con el valor de réplica inicial de Full Replication (Réplica completa). Cada vCPU se presenta al sistema operativo invitado en el contenedor de máquinas virtuales como un único núcleo con un solo zócalo.
Se admite la migración de cargas de trabajo de origen Windows y Linux basadas en UEFI en todas las plataformas de destino. La carga de trabajo de destino se convierte de UEFI a BIOS en las plataformas de nube de destino: Amazon Web Services, Microsoft Azure y VMware vCloud Director. En otras plataformas, la carga de trabajo de destino se configura como UEFI o BIOS, según admita el proveedor de la plataforma de destino.
Migrate transfiere las cargas de trabajo del origen al destino, al tiempo que aplica el firmware compatible a los sistemas operativos correspondientes de origen y destino. Cuando se inicia cualquier migración entre sistemas UEFI y BIOS, Migrate la analiza e informa sobre su validez.
NOTA:si va a migrar una carga de trabajo basada en UEFI a un contenedor de destino vSphere y desea seguir usando el mismo modo de arranque del firmware, debe usar como destino un contenedor vSphere 5.0 o posterior.
A continuación, se muestran algunos ejemplos del comportamiento de Migrate para realizar la conversión entre sistemas basados en UEFI y en BIOS:
Para migrar una carga de trabajo basada en UEFI a un contenedor VMware vSphere 4.x o Cloud (que no admite UEFI), Migrate transforma el firmware UEFI de la carga de trabajo en firmware BIOS.
Cuando se migra un origen basado en UEFI a un destino basado en BIOS, Migrate convierte los discos de arranque del sistema UEFI, en formato GPT, en discos MBR.
(Cargas de trabajo Windows) Cuando se migra una carga de trabajo BIOS a un destino basado en UEFI, Migrate convierte los discos de arranque del sistema BIOS, que son MBR, en discos GPT.
Se admite la conversión de las siguientes cargas de trabajo de origen paravirtualizadas a totalmente virtualizadas en un host virtual de Citrix XenServer o KVM:
Red Hat Enterprise Linux (RHEL) 6.0 y distribuciones Linux basadas en RHEL 6.0
Red Hat Enterprise Linux (RHEL) 5.x y distribuciones Linux basadas en RHEL 5.x
SUSE Linux Enterprise Server 10 y 11
Solo se admiten las conversiones basadas en bloques.
Antes de migrar una carga de trabajo de origen Linux paravirtualizada que se ejecute en Citrix XenServer o KVM a una plataforma de destino como sistema invitado totalmente virtualizado, haga lo siguiente:
Asegúrese de que tanto el núcleo paravirtual como el núcleo estándar están instalados en la carga de trabajo de origen paravirtualizada.
Compile manualmente los controladores basados en bloques del núcleo de Xen.
PlateSpin Migrate admite las siguientes plataformas de virtualización de destino.
En la Tabla 2-12 se indican las plataformas VMware de destino compatibles con la interfaz Web de PlateSpin Migrate y el cliente de Migrate. El cliente de Migrate admite la migración automatizada o semiautomatizada mediante el flujo de trabajo X2P. La interfaz Web admite la migración automatizada. Consulte la:
Consulte también Requisitos previos para la migración a VMware.
NOTA:para obtener información sobre cómo crear el disco de la máquina virtual de destino en contenedores de VMware mediante la asignación de dispositivo en bruto (RDM), consulte Migración a VMware.
En la Tabla 2-13 se indican las plataformas de virtualización de destino para el cliente de PlateSpin Migrate con el flujo de trabajo semiautomatizado X2P.
NOTA:
La migración de cargas de trabajo a una plataforma de virtualización de destino está sujeta a que el proveedor del host admita el sistema operativo invitado en el host de destino.
se necesita una licencia del sistema operativo para la carga de trabajo de destino migrada.
Tabla 2-12 Plataformas VMware de destino compatibles con la interfaz Web de PlateSpin Migrate y el cliente de Migrate
|
Plataforma |
Versiones |
Observaciones |
|---|---|---|
|
VMware vCenter |
|
Para vCenter 6.2, se admiten los contenedores de destino que usen VMware Virtual SAN (vSAN) 6.2. Para vCenter 5.5, se admiten los contenedores de destino que usen VMware Virtual SAN (vSAN) 5.5. La asignación de dispositivo en bruto (RDM) para máquinas virtuales de destino se admite mediante el uso del flujo de trabajo X2P. No se admiten los siguientes tipos de almacén de datos de VMware disponibles en VMware 6.0 y versiones posteriores:
|
|
VMware ESXi |
|
Todas las versiones de ESXi deben disponer de una licencia de pago. La migración no se admite en estos sistemas si funcionan con una licencia gratuita. La asignación de dispositivo en bruto (RDM) para máquinas virtuales de destino se admite mediante el uso del flujo de trabajo X2P. No se admiten los siguientes tipos de almacén de datos de VMware disponibles en VMware 6.0 y versiones posteriores:
|
|
VMware ESX |
|
La asignación de dispositivo en bruto (RDM) para máquinas virtuales de destino se admite mediante el uso del flujo de trabajo X2P. |
Tabla 2-13 Plataformas de virtualización de destino compatibles solo con el cliente de Migrate
|
Plataforma |
Versiones |
Observaciones |
|---|---|---|
|
Microsoft Windows Server con Hyper-V |
|
Compatible con el flujo de trabajo automatizado o el flujo de trabajo X2P. Consulte la Consulte también Requisitos previos para la migración a Microsoft Hyper-V. |
|
Citrix XenServer |
6.0 a 6.2 y 6.5 |
Se admiten invitados completamente virtualizados. Use la imagen ISO de PlateSpin para SUSE Linux Enterprise Server 11 SP3 como LRD para arrancar la máquina virtual. Citrix XenServer 6.5 y versiones anteriores no admiten SLES 11 SP4. Se admite mediante el flujo de trabajo X2P. Consulte Migración a máquinas virtuales en Citrix XenServer. Consulte también Requisitos previos para la migración a máquinas virtuales en Citrix XenServer. |
|
SUSE Linux Enterprise Server con Xen |
11 SP3 y 11 SP4 |
Se admiten invitados completamente virtualizados. Se admite mediante el flujo de trabajo X2P. Consulte Migración a máquinas virtuales en Xen. Consulte también Requisitos previos para la migración a máquinas virtuales en Xen. |
|
SUSE Linux Enterprise Server (SLES) con KVM |
11 SP4 y 12 SP1 |
Se admiten invitados completamente virtualizados. Se admiten dispositivos Virtio. Se admite mediante el flujo de trabajo X2P. Consulte Migración a máquinas virtuales en KVM. Consulte también Requisitos previos para la migración a máquinas virtuales en KVM. |
|
Red Hat Enterprise Linux (RHEL) con KVM |
7.0 y 7.2 |
Se admiten invitados completamente virtualizados. Se admiten dispositivos Virtio. Se admite mediante el flujo de trabajo X2P. Consulte Migración a máquinas virtuales en KVM. Consulte también Requisitos previos para la migración a máquinas virtuales en KVM. |
PlateSpin Migrate admite la migración de cargas de trabajo a plataformas en la nube de destino. Microsoft Azure y VMware vCloud Director son compatibles con la interfaz Web de Migrate. Amazon Web Services es compatible con el cliente de Migrate. Consulte la Tabla 2-14 y la Tabla 2-15.
Tabla 2-14 Plataformas de nube de destino compatibles con la interfaz Web de Migrate
|
Plataforma |
Versiones |
Observaciones |
|---|---|---|
|
Microsoft Azure |
|
Cada servidor de PlateSpin admite solo uno de los entornos de Azure a la vez. Consulte la Sección 9.9, Configuración del entorno de IaaS de destino para la nube de Azure. NOTA:póngase en contacto con los servicios de asistencia técnica de Micro Focus para obtener ayuda si desea migrar cargas de trabajo a otros entornos independientes de Azure. Consulte también Requisitos previos para la migración a Microsoft Azure. |
|
VMware vCloud Director |
5.5.x y 5.6.x |
Consulte también Requisitos previos para la migración a VMware vCloud Director. |
Tabla 2-15 Plataforma de nube de destino compatible con el cliente de Migrate
|
Plataforma |
Versiones |
Observaciones |
|---|---|---|
|
Amazon Web Services (AWS) |
Entorno EC2 de Amazon |
Consulte también Requisitos previos para la migración a Amazon Web Services. |
Además del inglés, PlateSpin Migrate proporciona compatibilidad con otros idiomas: alemán (DE-DE), chino simplificado (ZH-CN), chino tradicional (ZH-TW), francés (FR-FR) y japonés (JA-JP).
Hay disponible documentación en línea traducida en estos idiomas, además de en español (ES-ES) y en portugués brasileño (PT-BR).
La interfaz Web de PlateSpin Migrate y las opciones de configuración de PlateSpin están disponibles en un navegador Web compatible:
Google Chrome, versión 34.0 y posteriores
Microsoft Internet Explorer, versión 11.0 y posteriores
Mozilla Firefox, versión 29.0 y posteriores
NOTA:JavaScript (Active Scripting) debe estar habilitado en el navegador.
Para utilizar la interfaz Web de en uno de los idiomas admitidos, consulte Configuración de idiomas para versiones internacionales.