PlateSpin Migrate 2019.8 includes new features and enhancements and resolves several previous known issues.
The documentation for this product is available in HTML and PDF formats on the PlateSpin Migrate 2019.8 Documentation website.
This product contains undocumented utilities that the Technical Support team might use to diagnose or correct problems.
The following changes have been made to this document since the release of PlateSpin Migrate 2019.8.
|
Location |
Update |
|---|---|
|
Updated this section to include information about the availability of PlateSpin Migrate 2019.8 server image and replication environment for Azure China in Microsoft Azure Marketplace. |
|
Location |
Update |
|---|---|
|
Updated the section to list all the enhancements made in Migrate API. |
|
Location |
Update |
|---|---|
|
PlateSpin Migrate 2019.8 server image and replication environment for Azure Global are available in Microsoft Azure Marketplace. |
|
|
This section is new. |
|
|
Discontinues support for using shared RDM (raw device mapping) disks on target VMs for the semi-automated migration of a Windows Server Failover Cluster (WSFC) to VMware. |
PlateSpin Migrate 2019.8 server image and replication environment for Azure Global and Azure China are available in Microsoft Azure Marketplace. In the Azure Marketplace, search for “PlateSpin”, then select the PlateSpin Migrate and PlateSpin Replication Environment images from Micro Focus.
PlateSpin Migrate updates the AWS Quick Start support to help you quickly and easily deploy PlateSpin Migrate 2019.8 server on the AWS Cloud. For more information about the Quick Start, see Micro Focus PlateSpin Migrate on AWS.
PlateSpin Migrate 2019.8 includes several new features and enhancements.
Many of these improvements were made in direct response to suggestions from our customers. We thank you for your time and valuable input. We hope you continue to help us ensure that our products meet all your needs.
Support for New AWS Instance Types
PlateSpin Migrate adds support for the following new AWS instance types for x86 and x86_64 processor architectures offered by Amazon Web Services since the Migrate 2019.5 release:
t3a, x1e, i3en
Enhanced Support for AWS Metal Instance Types
PlateSpin Migrate now supports AWS EC2 Bare Metal instances (m5.metal, m5d.metal, r5.metal, r5d.metal, z1d.metal, i3.metal) on Windows Server 2012 workloads in addition to the existing support for these metal instances on Windows Server 2012 R2, Windows Server 2016, and all supported Linux workloads for migration to AWS.
Support for Azure Tags
PlateSpin Migrate enables you to define Azure tags and configure them for workload migrations to Azure. You can use these tags to help identify VMs and resources that Migrate creates on your behalf in target Azure platforms. See Using Azure Cloud Tags for Azure Migrations
in the User Guide.
Support for Duplicate Azure Locations in Different Subscriptions
PlateSpin Migrate supports the creation and use of target platforms that have a duplicate Azure location where each target has a different Subscription ID.
Support for New Azure Instance Types
PlateSpin Migrate adds support for new Azure instance types offered by Microsoft Azure since the Migrate 2019.5 release.
Support for New Azure Locations
PlateSpin Migrate adds support for South Africa and UAE North locations as target platforms.
Support for Automated Migration to Hyper-V
PlateSpin Migrate adds support in the Migrate Web Interface for automated migrations to Hyper-V virtualization platforms. See Migration to Microsoft Hyper-V
in the User Guide.
Support for Semi-Automated Migration of Source Workloads to Oracle Cloud
PlateSpin Migrate adds support in the Migrate Client and Migrate Web Interface for semi-automated (X2P) migrations of source workloads to Oracle Cloud Infrastructure. See Migration to Oracle Cloud Infrastructure
in the User Guide.
Ability to specify multiple IP addresses per NIC on Linux workloads for migrations to VMware, physical machines, and the cloud (AWS, Azure, vCloud). For migrations to VMware, you can also specify IP addresses for multiple default gateways.
NOTE:For a RHEL 5.x workload that you configure multiple IP addresses per NIC and migrate to AWS, only the primary IP address is set on the NIC of the migrated workload. See Unable to Set Multiple IP Addresses for NIC on a RHEL 5.x Workload for Migrations to AWS.
Ability to configure the storage layout with a single click by selecting Same as Source (default) or One Volume (or Volume Group) Per Disk. See Storage Disks and Volumes Using Migrate Web Interface
in the User Guide.
Ability to create custom post-migration actions and configure the migration job to execute the action on your target workload. See Managing Post-Migration Actions
and Custom Post-Migration Actions
in the User Guide.
Adds support for incremental replications for semi-automated (X2P) workload migrations to physical targets. See Prerequisites for Migration to Physical Machines
in the User Guide.
Ability to view the IP address and boot mode information of a source workload when you hover the mouse over the workload name on the Workloads page.
PlateSpin Migrate adds support in the Migrate API for the following:
Headless migrations to Amazon Web Services, VMware, and VMware vCloud platforms in addition to its current support for headless migrations to Microsoft Azure. See Overview of Migrate API
in the Migrate API Getting Started Reference.
Multiple IP addresses per NIC, Azure tags, workload tags, and a licensing endpoint.
Resolves issues for the start/stop options and cutover options.
Improves the networking architecture to work better with the multiple IP addresses per NIC feature.
Ability to Define Azure Tags on the Migrate Server
You can define up to eight (8) Azure tags for your PlateSpin Server by using the DefaultCloudTagsAzure parameter on the PlateSpin Configuration page. Globally defined Azure tags are available on the Workload Configuration page for all migrations to Azure. Migrate applies the tags to resources it creates in the target Azure environment. See Using Azure Cloud Tags for Azure Migrations
in the User Guide.
Ability to Assign Public IP Address to Primary NIC on Cloud Target Instances
PlateSpin Migrate lets you specify whether or not a public IP address should be assigned to the primary network interface of AWS and Azure instances by using the EnablePublicIPForCloudInstance parameter on the PlateSpin Configuration page. See Enabling Public IP Address for Target Instances on Cloud
in the User Guide.
PlateSpin Migrate 2019.8 discontinues support for the following configurations and functions.
IMPORTANT:Before you upgrade from PlateSpin Migrate 2019.5 to PlateSpin Migrate 2019.8, ensure that you complete planned migrations that involve configurations and functions that will be deprecated in version 2019.8.
PlateSpin Migrate 2019.8 discontinues support in this release for migration to Azure Government cloud and Azure Germany cloud.
PlateSpin Migrate 2019.8 discontinues support for the following:
Manually deployed Migrate servers in Amazon Web Services EC2 cloud or in Microsoft Azure cloud.
The System Identifier (SID) and Generate New SID options. These configuration options were used previously for migration of source workloads running Windows Server 2008 (non-R2) to VMware, vCloud, and Hyper-V platforms. Windows Server 2008 is no longer supported for migrations to these platforms.
Using shared RDM (raw device mapping) disks on target VMs for the semi-automated migration of a Windows Server Failover Cluster (WSFC) to VMware.
Micro Focus strives to ensure our products provide quality solutions for your enterprise software needs. The following issues are currently being researched. If you need further assistance with any issue, please contact Micro Focus Support and Services.
For information about known issues in previous releases, see Previous Releases
.
Issue: During the Migrate server installation, the Validate Credentials action fails on the Database Administrative Credentials dialog with the following error: (Bug 1115474)
The Microsoft SQL Server 2012 Native Client is required. Install this package and rerun the PlateSpin Migrate Install.
Workaround:
The PlateSpin Migrate Installer requires Microsoft SQL Server 2012 Native Client for communications with remote SQL Server databases. See Prerequisite Software
in the Installation and Upgrade Guide.
Issue: When you use the PlateSpin Migrate Installation Launcher to install PlateSpin Migrate Client on a computer that is not a PlateSpin Migrate Server host, the Install PlateSpin Client option is disabled (grayed out). (Bug 1148654)
Workaround: Do one of the following:
Download the Client from your PlateSpin Server and install it by following the on-screen instructions. See Downloading the Client from Your PlateSpin Server in the in the Installation and Upgrade Guide.
Extract the PlateSpin Migrate setup executable (PlateSpinMigrateSetup-2019.8.0.x.exe) to a temporary location, navigate to the \PlateSpinImage\ClientInstall folder, and double-click the MigrateClientSetup application to install the client.
Issue:
After you upgrade to PlateSpin Migrate 2019.8, existing migrations might fail if they have been configured for deprecated source workloads or target platforms. See Deprecated Configurations and Functions
.
Workaround: Before you upgrade your Migrate Server to version 2019.8, ensure that you complete planned migrations for source workloads or to target platforms that are not supported for 2019.8.
Issue: In PlateSpin Migrate 2019.5, the Migrate Web Interface displays details for Hyper-V servers, whether they are discovered using Migrate Client or Migrate Web Interface. After an upgrade, the Web Interface does not display details for Hyper-V servers that were previously discovered with the Migrate Client. It properly display details for new discoveries of Hyper-V servers in the Migrate Client. (Bug 1142148)
Workaround: Undiscover the previously discovered Hyper-V servers in the Migrate Client, then rediscover them by using the Migrate Web Interface.
Issue: If you configure multiple IP addresses for a NIC on a RHEL 5.x workload and migrate the workload to AWS, only the primary IP address is set on the migrated workload. (Bug 1142732)
Workaround: None.
Issue: Replication fails for an Oracle 5.11 UEK with kernel version 2.6.39-400.215.10.el5uek for migrations to AWS. Diagnostics show error mkinitrd command failed.
Replication of this workload completes successfully for migrations to VMware and vCloud. (Oracle 5.x is not supported for migrations to Azure.) Replication of Oracle 5.11 RHCK with kernel version 2.6.18-398.el5 completes successfully for migrations to AWS. (Bug 1136126)
Workaround: None. You cannot migrate a workload running Oracle 5.11 UEK with kernel version 2.6.39-400.215.10.el5uek to AWS.
Issue: On the Configuration page for migrations to Azure, Migrate suggests default names for managed disks in the Managed Name field when Azure Managed Disks is enabled (default). If you switch back and forth between the Storage Layouts and disable and re-enable Azure Managed Disks, the suggested names in the Managed Name fields are no longer available. (Bug 1143724)
Workaround: To resolve this issue, specify custom names in the Managed Name field for each of the managed disks. If you want to use default names for managed disks, ensure that you make a note of those names before you disable Azure Managed Disks.
Issue: For migrations to Azure, a Managed Disk Name error might occur for Windows workloads that have multiple types of dynamic disk volumes (Spanned, Striped, Mirror, and RAID-5). The error message states the following naming requirements for Azure Managed Disks: (Bug 1146900)
Azure Managed disk names may be up to 80 characters long. They must begin with an alphanumeric character then may include alphanumeric, underscore, period, or hyphen characters.
Workaround: If the displayed Managed Disk Name is valid, the migration should complete successfully. You can temporarily disable the validator rule triggered the error for the Managed Disk Name. Run the migration. After the migration completes successfully, re-enable the validator.
To disable the validator:
Log in as Administrator to the PlateSpin Migrate Web Interface, then open the PlateSpin Server Configuration page at:
https://Your_PlateSpin_Server/platespinconfiguration/
Replace Your_PlateSpin_Server with the DNS host name or IP address of your Migrate Server.
Identify the validator rule that triggered the error.
Locate and enable the DisplayValidatorRuleName parameter.
A reboot or restart of PlateSpin services is not required to apply the change.
Go to the Workload Configuration page for the source workload, then view the validator rule that triggered the Managed Disk Name error.
Make a note of the validator rule name.
Return to the PlateSpin Server Configuration page, and disable the DisplayValidatorRuleName parameter.
Disable the validator rule. On the PlateSpin Server Configuration page, locate the DisabledValidators parameter, click Edit, add the validator rule to the list, and then click Save.
Return to the Workload Configuration page, and save the workload configuration.
Perform the migration.
After the migration completes successfully, re-enable the validator rule by removing it from the DisabledValidators list.
Issue: For migrations to Hyper-V, you get a warning message for the Hyper-V target if the workload’s storage requirements will result in insufficient free space to be available on the specified Hyper-V server to meet its current storage allocations. (Bug 1144075)
Adding this disk to the selected datastore may exceed the amount of free space required for recovery points for other workloads
In addition, warning messages might be displayed for the workload volumes:
Insufficient disk space <volname>: is under allocated by xx GB
Workaround: Assess the storage availability on the target Hyper-V server, and address storage capacity requirements before you begin the migration. Alternatively, you can select a different Hyper-V target that has sufficient storage.
Issue: Target Hyper-V Server 2012 R2 or 2016 servers discovered using the Migrate Client are not available as targets on the Targets page in the Migrate Web Interface. Instead they appear on the Workloads page with the following validation error:
The discovered workload is a Container. It might have Hyper-V Server or PlateSpin Image Server and so cannot be supported for migration. Command failed. Refer to command details.
Target discovery of Hyper-V servers using the Migrate Web Interface works as expected, and the discovered servers are available as targets in the Web Interface. (Bug 1145564)
Workaround: To recover from this error, clean up the Hyper-V target from both the Migrate Client and the Migrate Web Interface, and then re-discover the target Hyper-V server by using the Migrate Web Interface.
For migrations to Hyper-V target platforms using the Web Interface, ensure that you discover the Hyper-V servers as targets by using the Web Interface.
Issue: When you use the PlateSpin Migrate Client to migrate a workload to a physical target, the physical target is removed from the Migrate Client after successful migration. However, the physical target continues to be listed in the Migrate Web Interface. If you use the Migrate Web Interface to configure migrations to this physical target, the following error message is displayed: (Bug 1144676)
Target workload is no longer available because it might have been removed using PlateSpin Migrate Client. Manually remove this target from the Web Interface and add it again.
Workaround: Use the Web Interface to manually remove the physical target and add it again. Then, configure migration to the newly added physical target.
Issue: When you configure network settings for migrations to Microsoft Azure, some source workload DNS configurations might result in empty string values for a connection’s DNS entry. These empty values cause the Azure API to throw an exception. The migration fails to run. (Bug 1146916)
Workaround: Ensure that the only valid DNS values are included for the source, then try again.
Issue: When you use PlateSpin Migrate Web Interface for semi-automated migrations to physical targets or for migrations to VMware, the migration fails if the target disk or datastore does not have enough space. The Web Interface does not prevent the configuration if the size difference is small. However, the migration fails if there is insufficient space available on the target at cutover or test cutover.
For X2P migrations, the migration fails with the following error: There is not enough space on target disk.
For VMware migrations, the migration fails with the following error: The ReConfigVM_task submitted to the VMware ESX server failed. Insufficient disk space on datastore.
(Bug 1136920)
Workaround: Ensure that the disk or datastore has at least 1 GB more storage space than the workload you want to migrate.
Issue: An incremental replication of a Linux workload with kernel versions 3.10.0-957.el7.x86_64 or newer might not properly replicate a file. After an apparently successful incremental replication, a file on the target shows symptoms of an incomplete replication, such as a target file checksum (md5sum, sha checksum) that differs from the source file checksum, an executable file that does not load or run, or a text file with incomplete data. (Bug 1144113)
Tested kernel versions:
3.10.0-957.el7.x86_643.10.0-957.27.2.el7.x86_64
Workaround: To resolve the problem, perform a full replication for the workload. Ensure that you perform a full replication with cutover for workloads with kernel versions 3.10.0-957.el7.x86_64 or newer.
Issue: For source Windows workloads where IPv6 is not enabled for NICs, IPv6 has been improperly enabled for NICs on the target Windows workload after cutover and test cutover. (Bug 1139336)
Workaround: Disable IPv6 as appropriate on target Windows workloads after cutover or test cutover.
Issue: On the Configuration Summary page for a NIC, the Gateway IP Address summary displays an IP address for the primary gateway and 0.0.0.0 for the non-primary gateways. On the Configuration page, each of multiple static IP addresses is configured to use the same gateway IP address. (Bug 1146069)
Workaround: The target workload uses the primary gateway IP address for each of the static IP addresses for the NIC.
PlateSpin Migrate 2019.8 resolves the following previously known issues.
Issue: When you migrate a RHEL, OEL, or CentOS 7.x workload to a physical target, the migration job fails with a recoverable error in Shutdown source step even though the source workload has been successfully shutdown. (Bug 1137115)
Fix: The error is no longer reported for successful migrations and source shutdown.
Issue: On the Workload Configuration page for migrations to Azure, the Use Managed Disks and Storage Type settings for Azure Managed Disks should be read only after you select Prepare Workload, similar to the behavior for Disk settings. If you deselect Use Managed Disks after Prepare, the Datastore and Path options for Disks are displayed but cannot be set because Disks settings are disabled at Prepare. (Bug 1137376)
Fix: After Prepare Workload, the Use Managed Disk and Storage Type controls are disabled in the Web Interface and APIs.
Issue: On the Workload Configuration page for migrations to Azure, if Use Managed Disks is enabled (the default), non-volume storage on the source workload is excluded in the default selection of disks to be migrated. The non-volume storage is not displayed in the Managed Disks list for the target workload. Non-volume storage refers to disks that contain a partition, but do not have a mount point. (Bug 1134799)
Fix: PlateSpin Migrate supports migration of non-volume storage disks to Azure when using Azure Managed Disks. You must specify the disk path to include it in the migration.
Issue: When you perform cutover of a supported Linux 7.x BIOS workload to vCloud, the cutover is successful and the static IP address that you configured in the migration job correctly displays in the vCloud Director. However, the configured static IP address and DNS servers are not set on the cutover target VM and the VM uses a DHCP address instead. This issue is not seen when you perform a test cutover of the Linux workload. (Bug 1124879)
Fix: The static IP addresses and DNS Servers list are properly set for the Test Cutover Target VM and the Cutover Target VM.
Issue: When you use Migrate API to migrate a workload to Azure with Azure Managed Disks enabled (the default), the first full replication fails if the Storage Disks resource group is set to a custom name that does not match the Transformation resource group name. (Bug 1138897)
Fix: Separate resource groups are properly created and named in Azure for the transformation objects and the managed disk objects.
Issue: When you use the PlateSpin Migrate Web Interface to migrate workloads to physical targets, the warning message displayed in the interface for any missing drivers is not complete and does not list the names of the missing drivers. (Bug 1136409)
Fix: For information about the missing drivers, see the diagnostic reports.
Issue: When you use the PlateSpin Migrate Web Interface to migrate workloads to physical targets and generate a diagnostic report for the job, the introduction paragraph and header in the report displays the source and target hostnames as variables instead of displaying the correct hostnames. (Bug 1136442)
Fix: The source and target hostnames are properly displayed in the report.
Issue: For Windows source workloads with dynamic disk types of Simple, Spanned, Striped, Mirrored, and RAID5, the target workload configuration assigns non-sequential numbers in disk names and disk indexes. The non-sequential numbering is an artifact of the types of dynamic disks on the source workload. All necessary disks are present for the target workload. This issue occurs for target Azure workloads and target VMware workloads. (Bug 973266)
Fix: Disk numbers on a dynamic disk workload are in sequential order.
Issue: When you use Migrate API to execute a First Full Replication with Cutover operation from a Prepared state, the cutover options set to shut down the source or target are ignored. A full replication occurs before the cutover runs and cutover completes successfully; however, the specified shut down action is not performed. (Bug 1138321)
Fix: PlateSpin Migrate API honors the cutover options in the request body for shut down source and shut down target.
Issue: When you use Migrate API to execute a Cutover operation from a Replicated state, the default behavior is to run an incremental replication before cutover. If the request body includes cutover options to shut down the source or target, the default setting to perform an incremental replication is ignored. Cutover completes successfully; however, no incremental replication occurs before the cutover runs. The specified shut down action is performed. (Bug 1138331)
Fix: By default, an incremental replication runs at Cutover when the reply body contains cutover options for shut down source and shut down target.
Issue: When you use Migrate API to execute a Cutover operation from a Replicated state, cutover options set to shut down the source or target are ignored if the request body also includes the Cutover option to perform an incremental replication with a setting of true ("performIncremental": true). An incremental replication occurs before the cutover runs and cutover completes successfully; however, the specified shut down action is not performed. (Bug 1138348)
Fix: PlateSpin Migrate API honors the cutover options in the request body for shut down source and shut down target.
Issue: When you perform migration of a workload that has been configured to use a Nitro instance during run cutover and a non-Nitro instance during test cutover, or the opposite mixed-type usage, the migration of the workload to AWS target fails with a recoverable error. (Bug 1133056)
Fix: When you configure migration of a Windows workload to AWS, the instance type you select for the Target Workload and Target Workload Test Settings need not be of the same type. You can use a combination of Nitro and non-Nitro instances for the Target Workload and Target Workload Test Settings. However, this issue is still applicable for Linux workloads.
PlateSpin Migrate 2019.8 provides the Install PlateSpin Migrate Prerequisites PowerShell script to check for and install prerequisite software and apply the appropriate configuration: ASP.NET, IIS, and .NET Framework. See Installing Prerequisite Software
in the Installation and Upgrade Guide.
To install PlateSpin Migrate 2019.8, see Installing PlateSpin Migrate
in the Installation and Upgrade Guide.
To apply PlateSpin Migrate 2019.8 to your PlateSpin Server, you must have an existing installation of PlateSpin Migrate 2019.2 on a supported Windows platform. See Upgrading Migrate
in the Installation and Upgrade Guide.
NOTE:To upgrade from an existing installation of PlateSpin Migrate 2019.5 Server to a supported new host platform, see Upgrading Migrate to a New Host Platform
in the Installation and Upgrade Guide.
For information about activating a new license, see PlateSpin Migrate Product Licensing
in the User Guide.
For documentation that accompanied earlier releases, visit the PlateSpin Documentation website and scroll to the release that you are looking for.
For specific product issues, contact Micro Focus Support at https://support.microfocus.com/contact/.
Additional technical information or advice is available from several sources:
Product information and resources: https://www.microfocus.com/products/platespin-migrate/
Micro Focus Customer Center: https://www.microfocus.com/customercenter/
Product knowledge base and videos: https://www.microfocus.com/support-and-services/
Micro Focus Communities for PlateSpin: https://community.microfocus.com/t5/PlateSpin/ct-p/PlateSpin/
PlateSpin Idea Exchange: https://community.microfocus.com/t5/PlateSpin-Idea-Exchange/idb-p/PlateSpin_Ideas/tab/most-recent/
For information about legal notices, trademarks, disclaimers, warranties, export and other use restrictions, U.S. Government rights, patent policy, and FIPS compliance, see https://www.microfocus.com/about/legal/.
© Copyright 2007 – 2019 Micro Focus or one of its affiliates.
The only warranties for products and services of Micro Focus and its affiliates and licensors (“Micro Focus”) are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. Micro Focus shall not be liable for technical or editorial errors or omissions contained herein. The information contained herein is subject to change without notice.