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.
Antes de instalar controladores de transferencia basada en bloques en las cargas de trabajo Windows de origen, asegúrese de que ha aplicado las actualizaciones más recientes de Windows en la carga de trabajo.
Las cargas de trabajo de BIOS deben tener al menos una partición en el disco de arranque y un cargador de arranque instalado en el MBR (registro de arranque principal).
No se admite la conversión de sistemas Linux basados en BIOS a UEFI.
Para convertir una carga de trabajo de origen UEFI Linux en un destino BIOS Linux, se requiere que haya una partición /boot disponible en la carga de trabajo de origen.
Las imágenes de cargas de trabajo no son compatibles con las cargas de trabajo Linux.
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 plataformas de virtualización de destino 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 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. PlateSpin Migrate proporciona métodos de transferencia basada en bloques sin controlador y basados en controlador. Consulte Transferencia basada en bloques para los clústeres. PlateSpin Migrate admite el uso de discos compartidos RDM (asignación de dispositivo en bruto, FC SAN) en máquinas virtuales de destino para la migración semiautomatizada de un clúster de conmutación por error de Windows Server (WSFC) a VMware, donde cada nodo de máquina virtual de destino se encuentra en un host distinto en un clúster de VMware. Consulte Migración avanzada de clústeres de Windows a máquinas virtuales VMware con discos RDM. |
Admite los modelos de quórum:
|
|
Admite los modelos de quórum:
|
|
Admite el modelo de quórum:
|
|
|
Escritorio |
|
|
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.5 |
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. Para las cargas de trabajo Red Hat Enterprise Linux 6.8, Oracle Linux 6.8 y CentOS 6.8 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-696.20.1.el6.x86_64) en la distribución 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. No se admite la migración de una carga de trabajo SLES11 SP4 de 32 bits de origen a un destino Hyper-V. |
|
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. |
Utilice la interfaz Web de PlateSpin Migrate para migrar las cargas de trabajo a Amazon Web Services, Microsoft Azure, VMware vCloud Director y VMware Cloud en AWS.
Migrate admite migraciones P2C y V2C a plataformas de nube de destino. Migrate admite migraciones C2C de cargas de trabajo de origen entre plataformas de nube compatibles. Para obtener información sobre los casos de distribución C2C directa admitidos, consulte el Sección 12.0, Requisitos previos para migraciones de nube a nube.
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 una plataforma de nube de destino está sujeta a que el proveedor de la nube admita el sistema operativo invitado en la plataforma de nube de destino.
Antes de instalar controladores de transferencia basada en bloques en las cargas de trabajo Windows de origen, asegúrese de que ha aplicado las actualizaciones más recientes de Windows en la carga de trabajo.
Las cargas de trabajo de BIOS deben tener al menos una partición en el disco de arranque y un cargador de arranque instalado en el MBR (registro de arranque principal).
Las cargas de trabajo Windows y Linux basadas en UEFI se migran como cargas de trabajo UEFI a las plataformas vCloud de destino. Sin embargo, para otras plataformas de nube de destino como Azure y AWS que no son compatibles con cargas de trabajo UEFI, las cargas de trabajo Windows y Linux basadas en UEFI se migran como cargas de trabajo de BIOS.
Para convertir una carga de trabajo de origen UEFI Linux en un destino BIOS Linux, se requiere que haya una partición /boot disponible en la carga de trabajo de origen.
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 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:
Tabla 2-3 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-4 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.5 |
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. Para las cargas de trabajo Red Hat Enterprise Linux 6.8, Oracle Linux 6.8 y CentOS 6.8 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-696.20.1.el6.x86_64) en la distribución 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 (SP1 a 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. |
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:
Tabla 2-5 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-6 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.5 |
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. Para las cargas de trabajo Red Hat Enterprise Linux 6.8, Oracle Linux 6.8 y CentOS 6.8 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-696.20.1.el6.x86_64) en la distribución 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:Si la partición de arranque (/boot) se encuentra en un disco distinto al de la partición raíz (/), PlateSpin Migrate los migra ambos al primer disco de la máquina virtual de destino en Azure.
PlateSpin Migrate admite las siguientes plataformas para la migración a VMware vCloud Director. Consulte también Sección 2.1.3, Almacenamiento de cargas de trabajo admitido y 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:
Tabla 2-7 vCloud: plataformas Windows compatibles
|
Sistema operativo |
Observaciones |
|---|---|
|
Microsoft Windows Server 2016 |
Requiere vCloud 8.20 o una versión posterior. Los hosts donde se aloja el repositorio de recurso de VMware deben admitir máquinas virtuales con la versión 10 o posterior del hardware. La directiva de centro de datos virtual del proveedor de la última versión del hardware admitida se debe definir como mínimo en la versión 10 del hardware. |
|
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-8 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.5 |
Migrate admite el sistema de archivos XFS v5 en las cargas de trabajo de origen UEFI Linux para las migraciones que usen el PRE de vCloud basado en SLES 12 SP3. Sin embargo, no admite XFS v5 para cargas de trabajo Linux BIOS de origen que se migren mediante el PRE de vCloud basado en SLES 11 SP4. 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. Para las cargas de trabajo Red Hat Enterprise Linux 6.8, Oracle Linux 6.8 y CentOS 6.8 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-696.20.1.el6.x86_64) en la distribución 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. La migración de cargas de trabajo Red Hat Enterprise Linux 7.x solo se admite a VMware vCloud Director 5.5.x, 5.6.x y 9.1. |
|
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. |
Para la migración a VMware Cloud en AWS, PlateSpin Migrate admite las mismas plataformas que para la migración de clústeres DRS de VMware a VMware. Consulte Sección 2.1.1, Cargas de trabajo de origen compatibles para la migración a plataformas que no sean en la nube.
Consulte también Sección 2.1.3, Almacenamiento de cargas de trabajo admitido y 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 en AWS, consulte:
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 admite el sistema de archivos XFS versión 5 (v5) en RHEL 7.3 y versiones posteriores, así como en distribuciones basadas en esas versiones. Sin embargo, la compatibilidad con XFS v5 no se aplica a las cargas de trabajo de BIOS en plataformas de VMware vCloud de destino.
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 almacenamiento, incluidos los discos básicos, los discos dinámicos Windows de origen, LVM2, RAID de hardware, 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: PlateSpin Migrate admite RAID de hardware; sin embargo, no ofrece compatibilidad para RAID de software. Esto es aplicable tanto a cargas de trabajo Windows como Linux.
Migrate admite los cargadores de arranque GRUB y GRUB 2 para cargas de trabajo Linux.
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 E.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 E.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. |
|
Red Hat Enterprise Linux (RHEL) |
|
Para las cargas de trabajo Red Hat Enterprise Linux 6.8, Oracle Linux 6.8 y CentOS 6.8 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-696.20.1.el6.x86_64) en la distribución 6.8. |
|
SUSE Linux Enterprise Server |
11 SP4 |
|
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 plataformas de virtualización 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 plataformas de virtualización 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 la plataforma 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 está configurada como UEFI o BIOS, según la compatibilidad ofrecida por el proveedor de la plataforma de destino. Por ejemplo:
En las plataformas de destino VMware Cloud Director, las cargas de trabajo Windows y Linux basadas en UEFI se migran como cargas de trabajo UEFI a las plataformas DE vCloud de destino.
Para otras plataformas de nube de destino como Azure y AWS que no son compatibles con cargas de trabajo de UEFI, las cargas de trabajo Windows y Linux basadas en UEFI se migran como cargas de trabajo de BIOS.
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 una plataforma de virtualización de 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:
Cuando se migra una carga de trabajo de origen basada en UEFI a una plataforma que no admite UEFI, por ejemplo VMware vSphere 4.x, AWS o Azure, Migrate transforma el firmware de UEFI de la carga de trabajo en firmware de BIOS.
Cuando se migra una carga de trabajo de origen basada 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:
Consulte también la Requisitos previos para la migración a VMware y la Requisitos previos para la migración a VMware Cloud en AWS.
NOTA:para obtener información sobre cómo crear el disco de la máquina virtual de destino en plataformas de VMware mediante la asignación de dispositivo en bruto (RDM), consulte Migración a VMware.
En la Tabla 2-14 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 |
|
El almacenamiento VMware Virtual SAN (vSAN) se admite en plataformas de virtualización de vCenter de destino con las siguientes condiciones:
La asignación de dispositivo en bruto (RDM) para máquinas virtuales de destino se admite mediante el uso del flujo de trabajo X2P. Consulte también Tabla 2-13, Almacenes de datos de VMware compatibles. |
|
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. Consulte también el Tabla 2-13, Almacenes de datos de VMware compatibles. |
|
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. Consulte también Tabla 2-13, Almacenes de datos de VMware compatibles. |
Tabla 2-13 Almacenes de datos de VMware compatibles
|
Tipo de almacén de datos |
Configuraciones compatibles |
|---|---|
|
VMFS |
Se admite en todas las versiones compatibles de plataformas VMware vCenter, ESXi y ESX. |
|
NFS |
|
|
Otros |
No se admiten otros tipos de almacenes de datos, por ejemplo volúmenes virtuales ni vFlash. |
Tabla 2-14 Plataformas de virtualización de destino compatibles solo con el cliente de Migrate
|
Plataforma |
Versiones |
Observaciones |
|---|---|---|
|
Servidor Microsoft Hyper-V |
|
Compatible con el flujo de trabajo automatizado o el flujo de trabajo X2P. Consulte Consulte también Requisitos previos para la migración a Microsoft Hyper-V. |
|
Microsoft Windows Server con Hyper-V |
|
Compatible con el flujo de trabajo automatizado o el flujo de trabajo X2P. Consulte: Consulte también Requisitos previos para la migración a Microsoft Hyper-V. |
|
Citrix XenServer |
|
Se admiten invitados completamente virtualizados. 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.4 |
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 de nube de destino en la interfaz Web de Migrate.
Tabla 2-15 Plataformas de nube de destino compatibles con la interfaz Web de Migrate
|
Plataforma |
Versiones |
Observaciones |
|---|---|---|
|
Amazon Web Services (AWS) |
Entorno EC2 de Amazon |
Consulte también Sección 8.0, Requisitos previos para la migración a Amazon Web Services. |
|
Microsoft Azure |
|
Un servidor de Migrate puede tener varias plataformas de nube de Azure de destino. Especifique el entorno de nube de Azure y la ubicación cuando cree la plataforma de destino. |
|
VMware vCloud Director |
|
Consulte también Requisitos previos para la migración a VMware vCloud Director. Descarga el entorno de réplica de PlateSpin de para vCloud desde el sitio de descargas de PlateSpin Migrate 2018.11. |
|
VMware Cloud en AWS |
Consulte también Requisitos previos para la migración a VMware Cloud en AWS. |
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, las opciones de configuración de PlateSpin y los archivos de ayuda 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.