PlateSpin Migrate version 12.2 includes new features, enhancements, and bug fixes.
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. You can post feedback in the PlateSpin Migrate forum on NetIQ Communities, our online community that also includes product information, blogs, and links to helpful resources.
The documentation for this product is available on the NetIQ Website in HTML and PDF formats on a page that does not require you to log in. If you have suggestions for documentation improvements, click comment on this topic at the bottom of any page in the HTML version of the PlateSpin Migrate 12.2 documentation posted at the NetIQ Documentation Website.
This product contains undocumented utilities that the Technical Support team might use to diagnose or correct problems.
For documentation that accompanied earlier releases, visit the PlateSpin Migrate 12.2 Documentation Web Site and scroll to Previous Releases.
This Release Notes document provides supplemental documentation for PlateSpin Migrate 12.2. See Linux Boot Partition Requirement
under Supplemental Documentation.
PlateSpin Migrate 12.2 Patch 1 is mandatory fix that you must apply on a base installation of PlateSpin Migrate 12.2 (with or without field patches applied) to update your existing installations of the PlateSpin Server and Migrate Client. It resolves several issues. For more information, see the PlateSpin Migrate 12.2 Patch 1 Readme.
PlateSpin Migrate 12.2 RabbitMQ Fix is a patch that addresses an issue where the Event Messaging components RabbitMQ and Erlang are not installed and configured properly after you have installed or upgraded PlateSpin Migrate 12.2 Server on a drive that is not the C: drive. PlateSpin Transformation Manager 1.1 is the only consumer of the Event Messaging feature. For more information, see the Knowledge Base article The Rabbit MQ server used by PlateSpin Transformation Manager 1.2 is unable to connect to PlateSpin Migrate 12.2 (KB 7018515)
.
You can download the PlateSpin Migrate 12.2 RabbitMQ Fix at Micro Focus Patch Finder.
The following sections outline the key features and functions provided in this release:
PlateSpin Migrate 12.2 introduces support for migration of workloads to VMware vCloud Director and Amazon Web Services (AWS). It also enhances the support for migration of workloads to Azure Cloud.
PlateSpin Migrate 12.2 enhances the Web Interface to let you migrate Windows and Linux workloads to VMware vCloud Director. For a list of the supported workloads, see Supported Workloads For Migration to VMware vCloud Director
in the PlateSpin Migrate 12.2 User Guide.
PlateSpin Migrate 12.2 enhances the PlateSpin Migrate Client to let you migrate Windows and Linux workloads to AWS. For a list of the supported workloads, see Supported Workloads For Migration to Amazon Web Services
in the PlateSpin Migrate 12.2 User Guide.
PlateSpin Migrate 12.2 includes the following support:
Publishing the PlateSpin Migrate Server VM in Azure Market place. See Azure Cloud Based Migrate Server
in the PlateSpin Migrate 12.2 User Guide.
Perform incremental replication of workloads to Azure Cloud.
Use the enhanced Migrate Agent utility to migrate workloads to Azure Cloud over the Internet even when no VPN is configured. See Migrate Agent Utility
in the PlateSpin Migrate 12.2 User Guide
PlateSpin Migrate 12.2 includes support for the following:
PlateSpin Migrate 12.2 includes support for the following operating systems:
Windows Server 2012, 2008, 2003 Cluster
Red Hat Enterprise Linux (RHEL) 6.8
Oracle Enterprise Linux (OEL) 6.8
CentOS 6.8
In addition to the existing BIOS-based support, PlateSpin Migrate 12.2 includes UEFI-based support for the following:
Red Hat Enterprise Linux (RHEL) 7.2, 7.1, 7.0, 6.7
Oracle Enterprise Linux (OEL) 7.2, 7.1, 7.0, 6.7
CentOS 7.2, 7.1, 7.0, 6.7
SLES 11 SP4
See the Supported Configurations
section in the PlateSpin Migrate 12.2 User Guide.
PlateSpin Migrate 12.2 adds support for LVM raw disk volumes for Same as Source storage configurations on Linux workloads.
PlateSpin Migrate 12.2 includes support for the following VM containers:
VMware vCenter 5.1 Update 3, 5.5 Update 3, 6.0 Update 1 and 2
VMware ESXi 5.1 Update 3, 5.5 Update 3, 6.0 Update 1 and 2
SUSE Linux Enterprise Server (SLES) 12 SP1 KVM
Red Hat Enterprise Linux (RHEL) 7.2 KVM
See the Supported Configurations
section in the PlateSpin Migrate 12.2 User Guide.
PlateSpin Migrate 12.2 includes support for VMware vSAN.
PlateSpin Migrate 12.2 provides an updated PlateSpin ISO (Linux Ram Disk) based on SLES 11 SP4 kernel for X2P migrations.
Replication Networks for Source. This option was renamed from Networks Allowed for Replication and moved to follow the Storage options under Migration Settings.
Replication Network for Target. This option was renamed from Replication Network and moved to follow the Storage options under Migration Settings.
You can now plan large scale workload migrations, execute and monitor the workload migrations through PlateSpin Transformation Manager 1.1. PlateSpin Transformation Manager is a planning, tracking, and automation solution for data center transformation projects.
See the PlateSpin Transformation Manager User Guide on the Documentation site.
PlateSpin Migrate 12.2 updates OpenSSL to version 1.0.2h to address vulnerability issues in OpenSSL. For more information see the OpenSSL project.
To install PlateSpin Migrate 12.2, see Installing PlateSpin Migrate
in the PlateSpin Migrate 12.2 Installation and Upgrade Guide.
To upgrade your PlateSpin Server to PlateSpin Migrate 12.2, you must have an existing installation of PlateSpin Migrate 12.1 or PlateSpin Migrate 12.1 Patch Update 1 (P1). See Upgrading PlateSpin Migrate
in the PlateSpin Migrate 12.2 Installation and Upgrade Guide.
Other direct upgrades are not supported. For information about upgrading from PlateSpin Migrate 12.1 to PlateSpin Migrate 12.1 P1, see the PlateSpin Migrate 12.1 Patch Update 1 (P1) Release Notes.
The following is a list of bugs that were fixed for this release:
Issue: The PlateSpin.VMwareRoleTool.exe reported exceptions for some permissions that were missing for the PlateSpin Virtual Machine Manager in the PlateSpinRole.xml file. (Bugs 962265, 958576, 969197)
Fix: The PlateSpinRole.xml file now includes all required minimum permissions.
Issue: If the Languages option of your web browser is set to German, the Web Interface does not display a confirmation dialog when you click Remove next to a target in the Targets list. This issue applies for both VMware targets and Azure targets. The Web Interface displays the Remove Target confirmation dialog for web browsers with Languages set to English or the other supported national languages (French, Japanese, Chinese Simplified, and Chinese Traditional). (Bug 978490)
Fix: A confirmation dialog is available in all supported languages.
Issue: For migrations to Microsoft Azure, the Azure Blob Service created storage artifacts (a page blob and a block blob) in the assigned datastore for the workload’s replication environment. PlateSpin Migrate no longer needs the artifacts after the workload is successfully cut over, aborted, or removed; however, it did not automatically remove the artifacts. Microsoft Azure charged you to store these unneeded data files. (Bug 977308)
Fix: After a workload migration is completed, PlateSpin Migrate now automatically removes the artifacts.
Issue: If you discover a Windows workload with multiple sockets and cores, and then select a VMware container for the migration target, the values for the Sockets and the Cores Per Socket settings on the Migration Settings page in the Web Interface display as 1. (Bug 999444)
Fix: Migrate correctly detects the CPU and sets the Sockets and the Cores Per Socket values properly.
Issue: For a Linux workload with LVM, if you deselect the volume group but do not deselect the corresponding logical volume, the behavior is inconsistent for VMware and Azure. (Bugs 973926 and 970584)
Fix: If you deselect a volume group, a validation error message is displayed and user intervention is required to fix the incorrect configuration:
The LVM volume group <vg_name> assigned to <logical_volume_name> is missing in the target.
Issue: After a full replication for a Microsoft Windows Server 2012 workload running Microsoft SQL Server 2012, the SQL Server’s differential backup fails until a full backup with Microsoft tools runs again. This issue might occur if Microsoft VSS Writer for SQL Server (SqlServerWriter) is running during the replication. (Bug 983567)
Fix: The issue with SqlServerWriter has been resolved. SQL server differential backups are not broken.
As a best practice, ensure that no backups run during the narrow window when the Microsoft VSS Snapshot is created. This practice applies for any software that uses Microsoft's Volume Shadow Copy Service to create snapshots, including anti-virus, SQL backups, and so on.
Issue: During a cutover job, the target VM fails to boot. The cutover process stalls at configuring the services with a Configuration Service Not Started error. The configuration service on the target workload appears to hang, when it actually has completed successfully but could not report back to the PlateSpin server. A hang might also occur if software on the cutover workload keeps processes from continuing until the workload reboots and reboot optimization is enabled (the default) for the Configuration Service. (Bugs 994314, 991068, 991089, 988132, 987156, 986629, 984153, and 982362)
Fix: Cutover jobs perform as expected for most workloads. If the Configuration Service hangs for a Windows workload during a cutover action, you can disable optimized reboots for the Configuration Service, which allows the reboots to occur as requested by software. You can skip optimized reboots for a specific Windows workload or for all Windows workloads See Setting Reboot Method for the Configuration Service.
Issue: Following a conversion to Windows Server 2012 R2 Hyper-V, only the "C" drive displayed. Other partitions were not mounted to drive letters.(Bug 894623/915807)
Fix: The partitions are now mounted to the drives post conversion.
Issue: Discovery fails for Windows Server 2012 workloads where only Microsoft .NET 4.0 is installed. The Discovery expected .NET 2.0 SP2 or .NET 3.5 SP1 to be installed. (Bug 998423)
Fix: Migrate discovery supports Microsoft .NET Framework version 2.0 SP2, 3.5 SP1, or 4.0 installed on Windows sources and Hyper-V hosts.
Issue: If you mistakenly try to migrate an Azure source workload to the same target and datastore location in Azure, the migration setup fails as expected with the error BlobAlreadyExists. The post-failure cleanup of the target workload deletes the source workload because they are the same location. (Bug 971998)
Fix: The option to Remove Workload is disabled in the UI so that you cannot inadvertently delete the source workload.
Issue: For target Linux workloads, the Test Cutover failed with the following message if the specified hostname on the Configuration page contained an underscore:
Failed to configure virtual machine
(Bug 975854)
Fix: Test Cutover is successful even if the hostname contains an underscore.
Issue: For Windows source workloads with dynamic disk types of Simple, Spanned, Striped, Mirrored, and RAID5, the target workload configuration might use the same DiskPath setting for two disks. The migration ignores the duplicate setting and configures unique paths for the two disks on the target workload. The migration completes successfully. (Bug 973271)
Fix: Target disks are named sequentially by their order on the target.
Issue: After you remove a workload with the options Remove Workload and Preserve Source, the discovered workload is in a Not Configured state, and the target location is cleaned up. The validation history relates only to the most recent operation, which was Remove Workload. The validation history for the previous workload discovery is no longer available. (Bug 971118)
Fix: Validation of the discovered machine is re-run when the workload is returned to an Unprotected state during a Delete with preserve source operation.
Issue: When using the PlateSpin Migrate Client to migrate a Windows Server 2008 R2 workload to VMware 5.5 or 6.0, a non-critical error occurs for installing tools when Install VMware Tools is enabled.
Installing Tools [Failed: Non-critical error]
However, the VMware tools are properly installed. (Bug 992705)
Fix: The installation of VMware Tools on a Windows Server 2008 R2 workload completes without errors.
Issue: PlateSpin Migrate Client displays the following warning for a vSAN datastore:
The selected datastore <datastore> is not shared across VMware cluster.
However, the selected datastore is shared across the VMware cluster. The warning is not seen in the Web Interface. (Bug 992643)
Fix: The vSAN datastores are listed as non-local so that the Migrate Client validators correctly identify them as shared storage in a VMware cluster.
Issue: For target Linux workloads on VMware containers, after the data copy completes and the configuration service begins, the cutover hangs and you are prompted to override the vCDROM lockout. This issue did not occur on all target Linux workloads or on all VMware container versions. (Bug 975853)
Fix: Manual intervention is no longer required.
Issue: In the Microsoft Azure Portal, the workload’s DNS name field and Properties > COMPUTER NAME field are empty. (Bug 969489)
Fix: The Azure Portal does not show this information. Use Remote Desktop to log in to the computer, then open the Control Panel to the System page to view the workload’s computer name and DNS name.
The following issues are being researched:
Issue: If you choose to configure a migration job for source Linux workloads with the combination of hostname and LVM name exceeding 63 characters, the job configuration fails. (Bug 978065)
Workaround: Ensure that the combination of the hostname and LVM name on your Linux workload does not exceed 63 characters.
Issue: The confirmation dialog for the Test Cutover or Cutover actions displays a yellow Warning icon next to the Last Replication date and time with the following message:
The last replication is older than 24 hours.
However, the interval between the completion time and the current time is less than 24 hours. All times represent the time zone of the Migrate server. (Bug 1020776)
Workaround: Take one of the following actions in the Test Cutover or Cutover confirmation dialog, as appropriate for your data integrity needs:
Enable Perform Incremental Replication, then click Execute. An incremental replication runs before the cutover as part of the cutover process.
Ignore the warning and click Execute. Data changes made to the source workload since the last replication will not be there on the target workload.
Issue: When you migrate a cluster node from a virtual source machine to a physical target machine and the number of disks that you choose to migrate are less than the number of disks on the target machine, the quorum disk from the source machine is converted as local disk on the target machine irrespective of whether you selected the quorum disk for migration during JOB configuration or not.
Workaround: Rebuild the cluster environment. For information about rebuilding the cluster environment after the migration, see KB Article 7016770.
Issue: During a virtual-to-physical Windows Cluster conversion of the active node using the Migrate Client, a copy of the Quorum disk is created on the second local disk on the target workload. The conversion completes successfully, but Cluster Services are not running. The local copy of the Quorum disk is created whether you select or deselect the Quorum disk during the job setup. (Bug 1017154)
Workaround: Delete the copy of Quorum disk on the target workload’s local disk, and then start the Windows Cluster service.
Issue: An incremental replication can take twice as long as a full replication if the workload needs an MD5 checksum or server-sync action. For example:
Windows: If a failover occurs in Windows with a warning stating switching to server sync mode
, the transfer method fails back to perform an MD5 checksum.
Linux: Incremental replications for Linux workloads take twice the time of a full replication if the workload needs to perform an MD5 checksum or server-sync.
Linux (Azure): After a successful Abort action for an incremental replication of a Linux workload to Azure, the subsequent incremental replication appears to hang at Copy Data at 36% with no error message. An MD5 checksum is being performed on the backend that takes about an hour to complete.
The incremental replications eventually complete successfully. (Bug 1016246)
Workload: None.
On Chinese locales, help is displayed in the English language.
Issue: After you enable Encryption for a Windows workload that is configured for file-based data transfer, the Windows receiver might hang at the end of the transfer for incremental replications. The hang occurs if the last byte read of the transfer is incorrectly set by the encryption process to a non-zero value, indicating that more files are being transferred and to continue reading from the stream. (Bug 944559)
Workaround: You can use block-based data transfer for Windows workloads if you want to enable Encryption for replication data transfers.
Issue: If you choose to install PlateSpin Migrate on a computer where the OS Language setting does not match the OS Locale setting, the installation fails. (Bug 939805)
Workaround: To successfully install PlateSpin Migrate, ensure that the OS Language setting matches the OS Locale setting on the computer. You can change the locale of the computer as per your requirement after the installation is complete.
For example, if the OS Language setting is English, then you must ensure that the OS Locale setting is also English when you install the English or localized version of PlateSpin Migrate. After the installation is complete, you can change the locale as per your requirement.
Issue: When you configure migration for a workload that has block-based drivers already installed, the Install During Prepare Replication option in the Transfer Method setting is enabled and selected by default. This option must be disabled because the block- based drivers are already installed. However, there is no lose in the functionality. (Bug 967018)
Workaround: Ignore the option.
Issue: When you use the PlateSpin Migrate Client to migrate Linux workloads, the following are not supported: (Bug 930355)
Mapping the boot volume to LVM
Mapping any volume to a existing Volume Group
Mapping any volume to new Volume Group
Re-mapping Volume group to disk
Issue: PlateSpin Migrate does not support migrating Linux workloads that have volumes created on raw disks without partitions. (Bug 937071)
Issue: When you migrate a workload to Hitachi LPAR that has an operating system running on it, the migration might not complete. This is because the migration job waits for user intervention during the Configure Target Machine step of migration. (Bug 902489)
Workaround: Modify the UEFI Boot Order of Hitachi LPAR to enable it to boot from the hard disk instead of the ISO image.
Issue: When you migrate a workload to Hitachi LPAR, a warning message similar to the following might get displayed: (Bug 917209)
Device 'Unassigned Hitachi Shared FC Device 3017' is not supported by ......
Workaround: Ignore the message.
Issue: If you use the PlateSpin Migrate Web Interface to discover a Hyper-V container, the Hyper-V container is listed as a workload in the interface. You must not migrate this Hyper-V container. (Bug 929978)
Workaround: You must not migrate this Hyper-V container.
Issue: The migration of a Linux workload fails in the following scenarios because UEFI to BIOS conversion and vice versa is not supported: (Bug 937070)
Migrating a Linux workload with UEFI firmware to a container that supports BIOS firmware.
Migrating a Linux workload with BIOS firmware to a container that supports UEFI firmware.
Issue: The non-default per-volume VSS Settings are not preserved post migration of a Windows workload. (Bug 493589)
Workaround: After the migration, you must re-configure your custom VSS settings.
Issue: Migration operations might fail when they are attempted on ESX datastores that have the “+” or other special characters in the datastore name. (Bug 506154)
See KB Article 7009373.
Issue: VSS snapshots taken by third-party applications on the source workload are not replicated to the target upon migration. (Bug 692680)
Issue: Under some circumstances, when your Migrate server is connected to the VM host over a WAN, and if your VM host has a high number of datastores, the process of locating the appropriate ISO image required for booting the target might take longer than expected. (Bug 702152)
Workaround: To optimize the bandwidth available, plan the migration to occur during non-peak traffic hours.
Issue: If you perform a SLES 11 workload (cloned VM) migration using the semi-automated method to a target VM (faked physical) on a Windows Server 2008 Hyper-V host, the process freezes at the Configuring OS step. (Bug 822601)
Workaround: See KB 7012911.
Issue: When a VM is converted from VMware ESX to Citrix Xen and its boot files are allocated in second disk, the VM does not boot and manual intervention is requested. This is because the Citrix XEN VM tries to boot with disk 0 rather than with the bootfiles allocated to disk 2. (Bug 824724)
Workaround: To resolve this problem, rearrange the virtual-disk position in XenCenter so that the virtual machine boots from the virtual disk containing the operating system. The knowledge article at the Citrix Web site includes information about how to change the position of the virtual disk containing the operating system. See KB Article 7012906.
Issue: XenServer tools on a Windows VM in a Citrix XenServer hypervisor environment are not removed when the VM is converted to a VMware container or a physical container. (Bug 825016)
Workaround: Manually uninstall the XenServer tools after conversion.
Issue: Consider the following scenario:
Scenario: Moving or copying a Windows OS machine with more than three primary partitions to a physical machine where a Windows OS has been installed with minimum 3 primary partitions. At least one primary partition is preserved in the target machine. (Bug 825434)
Effect: After the migration, the Windows OS machine is unable to boot.
Example: The following error occurs when Windows Server 2003 machine is converted to Physical machine:
Windows could not start because the following file is missing or corrupt: <Windows root>\system32\ntoskrnl.exe.Please re-install a copy of the above file.
Workaround: See KB Article 7012913.
Issue: When you undiscover a workload, it displays as such in the Migrate client, but the ESX host shows that the node is not undiscovered (Bug 826545)
Workaround: Undiscover the workload on the ESX host, then refresh the ESX host.
Issue: When there are multiple boot options in the firmware and the hard disk is not the first boot device in the boot options list, the target machine does not boot from hard disk and conversion hangs. (Bug 859440)
Workaround: In the boot options of the physical machine, change the boot order so that Hard Drive is the first option, then restart the machine. See also KB Article 7014623.
Issue: The default OEM installation of Windows 8.1 (UEFI) creates a recovery partition with insufficient free space, making it impossible to create a Volume Shadow Copy (VSS) for the partition. (Bug 864325)
Workaround: Remove or expand the recovery partition. See KB Article 7014696.
Issue: The conversion of a UEFI workload (Windows 6.2 and above kernel versions) to BIOS-based machine fails at the Preparing OS step because the active partition cannot be found to update boot parameters. (Bug 864326)
Workaround: Update the partition type of Disk as MBR where the system volume is present in either the source workload or the image. Use Export and Import of UI options or OFX Browser to edit the XML. For a complete list of steps, see KB Article 7014637.
Issue: If you configure the End State setting of an offline conversion job as Restart, the source machine remains in an under control state after the job completes successfully. (Bug 875562)
Workaround: Manually restart the source when the conversion completes.
Issue: The boot menu of a Windows source machine is not restored after offline conversion. (Bug 878043)
Workaround: After the conversion, the source boot menu displays two options: the Linux RAM disk (LRD) and the Operating System (OS). When you boot for the first time after the conversion, manually select the OS option. This action purges the boot menu of the LRD boot option in future boot operations.
Issue: The command line interface (CLI) tool does not currently support moving or creating a VM under resource pool as a setting in the conversion.ini file. (Bug 891690)
Workaround: After the conversion, manually move the new machine to the resource pool you want.
Issue: Following a conversion to Windows Server 2012 R2 Hyper-V, only the "C" drive is visible. Other partitions are not mounted to drive letters.(Bug 894623)
Workaround: After the conversion, go to disk management and manually assign the drive letters to the partitions.
Issue: After performing a successful RHEL 6.2 x64 block-based migration with the Install Integration Services option selected, running the fdisk -l command shows redundant disks. That is, a single disk is displayed twice as sda and sdb. (Bug 896598)
Workaround: This is a known Microsoft issue and is being addressed.
Issue: PlateSpin Migrate supports VMware Clusters with and without DRS enabled, and with any level of DRS (Manual, Partially Automated, or Fully Automated). However, to be a valid migration target, your VMware Cluster must be discovered via vCenter and not by directly inventorying individual ESX servers. (Bug 896598)
See “Discovery Guidelines for Machine Types and Credentials” in your User Guide.
Issue: If you choose to designate a machine as a PlateSpin Image Server and specify the fully qualified path of an image file that is more than 248 characters, the installation of the image server fails. (Bug 967414)
Workaround: Ensure that the fully qualified path of the specified image file is less than or equal to 248 characters.
Issue: If you choose to migrate a Window 2000 Server source that has one or more NICs, the conversion job fails to configure the NICs on the target machine. (Bug 971414)
Workaround: Manually configure the NICs after the conversion job is complete.
Issue: When you use the Migrate Client to discover an ESX Server either directly or via vCenter server, the discovered server is listed in the Web Interface. If you rediscover the same ESX server again through the Migrate Client, a duplicate entry of the server with an Add Failed error is displayed in the Web Interface. (Bug 975870)
Workaround: Delete the duplicate server entry from the Web Interface.
Issue: Block-based full replication fails for Windows Server 2012 R2 servers with complex partitioning of more than 44 partitions or volumes. High disk utilization can prevent creation of VSS snapshots for any additional partitions or volumes. (Bug 1007833)
Workaround: Ensure that workloads you attempt to replicate have no more than 44 partitions or volumes.
Issue: Migrating Linux workloads using file-based transfer is possible only through offline conversion. If you choose to use the CLI tool to migrate a Linux workload using file-based transfer and edit the settings in [Transfer] section of the INI file to set the TransferType setting to filebased, but incorrectly set the LiveTransferEnabled setting to True instead of False, the job fails to display a validation error. Also, the migration continues using the block-based transfer method. (Bug 994513)
Workaround: To migrate Linux workloads using File-based transfer, you must ensure that the LiveTransferEnabled setting is set to False.
The following issue is being researched:
Issue: If a domain user chooses to install PlateSpin Migrate on a Windows Server 2012 R2 domain computer, the installation fails and an Operating system error message is logged.(Bug 1011557)
Workaround: The user must have administrator privileges to install PlateSpin Migrate on a Windows Server 2012 R2 domain computer.
Issue:
The components needed for Event Messaging are not properly installed and configured if you use a batch file to silently install PlateSpin Migrate as described in Installing the PlateSpin Migrate Software Components Using a Batch File
in the PlateSpin Migrate 12.2 Installation and Upgrade Guide. PlateSpin Transformation Manager 1.2 is the only consumer of the Event Messaging feature. (Bug 1020689)
Workaround: Do not use silent install to set up Migrate servers that you plan to use with PlateSpin Transformation Manager 1.2.
Issue: Event Messaging components are not configured properly if you install or upgrade PlateSpin Migrate Server on a drive that is not the C: drive. PlateSpin Transformation Manager 1.2 is the only consumer of the Event Messaging feature. (Bug 1021229)
Workaround: To avoid this problem, ensure that you install PlateSpin Migrate Server on the C: drive for Migrate servers that you plan to use with PlateSpin Transformation Manager 1.2. If you encounter this issue and need to install PlateSpin Migrate Server on a different drive, contact Customer Support for assistance.
The following issue is being researched:
Issue: After an uninstall of PlateSpin Server, if you reinstall without rebooting, the installation might stall with the following message:
Status: Installing OFX
Enabling STOMP protocol
The Migrate Event Messaging function uses RabbitMQ software, Erlang programming language, and STOMP. The uninstall removes the installed files, but does not automatically stop the related processes. If the processes are still running when you attempt to reinstall PlateSpin Server, the installation stalls. (Bug 999112)
Workaround: After the uninstall of PlateSpin Server, ensure that you stop the following services for the Event Messaging function (if they are running) before you perform the next install:
erlsrv.exe
erl.exe
epmd.exe
The following issues are being researched:
Issue: After you upgrade the Migrate server from version 12.1 to version 12.2, the Web Interface shows an extra workload tag named Default that is assigned the color gray. (Bug 1018730)
Workaround: In the Web Interface, select Settings > Workload Tags, then delete the Default workload tag.
Issue: The upgrade to Migrate 12.2 resets any migration contracts that are in the Configured state to the Not Configured state. You must reconfigure the contracts after the upgrade. (Bug 1018109)
Workaround: Do the following:
Windows Workloads: Before you begin the upgrade, run the Prepare Migration operation for each Windows migration contract that is in the Configured state.
Linux Workloads: After the upgrade, reconfigure the migration contract and run Prepare Migration. See also Linux Workloads Prepared For Migration Before Upgrade Should be Prepared Again Post Upgrade.
Issue: If you have Linux workloads prepared for synchronization or incremental replication and you upgrade the Migrate server to version 12.2, the prepared state of the workloads is reset. (Bug 1018112)
Workaround: Prepare the Linux workloads again post upgrade.
Issue: The upgrade fails if the Migrate Client is running because the installation cannot update the open files. (Bug 992912)
Workaround: Close the Migrate Client before you attempt to run the upgrade for the PlateSpin Server or Migrate Client.
Issue: After you upgrade the Migrate server to version 12.2, if you use the Web Interface to configure incremental replication of a workload for the first time and select an ESX target, the Target Virtual Machines option does not list any virtual machines. (Bug 1017328)
Workaround: Refresh the target ESX computer to enable the listing of the target VMs.
Issue: If you use the PlateSpin Migrate Client to discover workloads and targets and have discovered the same object in different networks of the Migrate Client, then only the object that you discovered in the default network displays on the PlateSpin Migrate Web Interface. However, on upgrading to Migrate 12.2, more than one instance of the discovered object displays on the Web Interface depending on the number of times it has been discovered in the various networks. (Bug 977577)
Workaround: Delete all the extra instances of the object listed in the Web Interface.
Issue: Consider that you have used the Migrate Client to discover a vCenter server in more than one network prior to upgrading to Migrate 12.2. If you now upgrade to Migrate 12.2, the vCenter server discovered in the Migrate Client is synchronized with the Web Interface. If you now choose to add the same vCenter target using the Web Interface, the operation fails with a Could not add target exception. (Bug 977577)
The following issues are being researched:
Issue: A hostname change or domain membership made to the migration contract configuration at Cutover is not honored on the target VM. A replication is required to propagate the hostname or domain membership change to the target VM. A hostname or domain membership change made at Test Cutover is honored because the test cutover process is handled differently than Cutover. (Bug 1019651)
Workaround: After you change the hostname or domain membership in the migration contract configuration, ensure that you run an incremental or full replication before you attempt Cutover.
Issue: Cutover to Azure does not complete for a workload that has a GPT data disk greater than 1 TB in size. If the source machine is BIOS with MBR as the boot disk, you see the following error message:
The Configuration service in the target machine does not seem to have started
(Bug 977922)
Workaround: Azure supports a maximum disk size of 1 TB, whether it is MBR or GPT.
Issue: Because the MAC addresses for NICs on a target Linux VM in Azure are different than the MAC addresses on the source Linux workload, Linux assigns different names to them. For example, the eth0 and eth1 Ethernet interfaces on a source Linux workload become eth2 and eth3 on the target Linux VM in Azure. (Bug 967468)
Workaround: You can manually rename the NICs in the target VM after cutover.
Issue: In an Azure-to-Azure cutover, if you inadvertently select a target VM and datastore that are actually the source objects, Migrate destroys the source workload if you select Abort before the Cutover operation fails on its own. (Bug 1011726)
Workaround: Let the Cutover action fail until the Abort button is replaced by the Configure Migration, Run Cutover, and Remove Workload buttons, then click Remove Workload.
Issue: The IP address for the Migrate Server in Azure can change on shutdown or reboot unless it has a Reserved Virtual IP Address. A change in IP address on the PlateSpin Server breaks the heartbeat communications with source workloads. (Bug 1015893)
Workaround: When you provision the Migrate Server in Azure, specify Static as the allocation method for the public IP address of the Migrate Server to ensure that the IP address does not change when the server is restarted. See Azure Cloud Based Migrate Server and Deploying a Migrate Server in the Azure Cloud in the PlateSpin Migrate User Guide.
If you set up the Migrate Server in Azure with a Dynamic assignment method for the public IP address, you should modify the setting to use the Static assignment method. See Assigning a Reserved IP Address to a Migrate Server in Azure in the PlateSpin Migrate User Guide.
Issue: When you attempt to migrate a workload to an Azure target container, it fails with a Password Is Expired error message from Azure. On the Azure Target Container page, a tooltip displays the Password Is Expired error message for the password.
This error can occur if you allow the password to expire for the Azure user that you created in the Microsoft Azure portal to use for PlateSpin Migrate migrations.
Workaround: Resolve the password issue in Microsoft Azure, update the password stored for the Azure user for any affected Azure target containers, then rerun the failed workload migrations.
Log in to the user account in the Microsoft Azure portal and use the Azure Self-Service Password Reset to set a new password.
Log in to the PlateSpin Migrate Web Interface.
Update the password stored for the Azure user in the Azure target container.
Rerun any failed workload migrations to the Azure target container.
Issue: A race condition can occur during the disk partitioning where PlateSpin Migrate attempts to read the partition table before all of the partition information has been returned by the npart utility. This condition causes the cutover to fail with the following message:
Unable to find a device to map the windows volume
(Bug 959079)
Workaround: Re-run the cutover.
Issue: If you migrate a Windows workload that has multiple NICs with DHCP to Azure, the network connection on the target VM might not get mapped to the correct Azure network or subnet.
For example: Consider that the source workload has three NICs with DHCP and the network connections are mapped as follows:
Ethernet mapped to subnet4
Ethernet2 mapped to subnet3
Ethernet3 mapped to subnet2
After migration, the network connections on the target VM might get mapped as follows:
Ethernet mapped to subnet3
Ethernet2 mapped to subnet4
Ethernet3 mapped to subnet2
(Bug 967316)
Workaround: You cannot use the target workload in this state. You must remove the faulty target workload, then repeat the migration setup and cutover. A second attempt typically succeeds in properly mapping the DHCP NICs to their correct Azure virtual network or subnet assignments.
To remove the faulty target workload and repeat the migration:
In the Web Interface, select the Migrated workload, click Remove Workload, select the Preserve Source and Delete Target VM options, then click Execute.
This action removes the target workload and leaves the source workload in the Not Configured state.
Configure the source workload for migration to Azure, using the same settings as in the first attempt.
Click Run Cutover.
Verify that the NICs are assigned to their correct Azure virtual network or subnet assignments.
Issue: Azure automatically adds a disk to the VM that is not mounted with drive letter. The size of this disk varies, depending on the cloud instance you choose for deployment. (Bug 967314)
Workaround: You can remove the extra Azure disk from the VM configuration.
Issue: PlateSpin Migrate supports Azure VM sizes with up to 64 data disks. For the maximum instance size, Migrate will use one data disk for the OS disk replication in the PlateSpin Replication Environment. After migration, this disk becomes the OS disk, and you can add a data disk. If you submit a source workload for replication with 64 data disks, there is no warning in the UI and the replication fails. (Bug 972053)
Workaround: For the maximum Azure instance size, ensure that your source workload has 63 or fewer data disks when you submit the workload for replication.
Issue: For Windows source workloads with dynamic disk types of Simple, Spanned, Striped, Mirrored, and RAID5, the target workload configuration assigns nonsequential 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)
Workaround: There is no workaround.
Issue: For Windows source workloads with dynamic disk types of Simple, Spanned, Striped, Mirrored, and RAID5, the default Cloud Instance Size for the target workload might be larger than is necessary. The default setting for the data disks component is based on the total disk count on the source workload rather than on the net number of disks to be created on the target workload. (Bug 973265)
Workaround: You must manually change the Cloud Instance Size to the appropriate and desired setting. A Cloud Instance Size with fewer data disks might fit your needs.
Issue: A discovered workload lists all discovered disks on the Configuration page. If you exclude a disk from the migration and save the change, the vdisk list with corresponding disk path is reordered and the expected disk might not be the one excluded. This problem is observed for target VMware and Azure VMs. (Bug 969639)
Workaround: This is a cosmetic modification of the configuration in the UI. The underlying configuration is saved correctly and there is no need for user modification of the disk paths or disk ordering.
Issue: Migration to Azure failed for a SUSE Linux Enterprise Server (SLES) 11 SP 4 workload with only non-LVM disks. Different errors occurred in different attempts:
Command failed. Refer to command details. The Configuration service in the target machine does not seem to have started.
Migrations to Azure are successful in workloads running other versions of SLES and other Linux operating systems that are configured with only non-LVM disks. (Bug 972062)
Workaround: There is no workaround for SLES 11 SP4 workloads using non-LVM disks.
Issue: Linux disks are created in a different order on the target workload than they are on the source workload. All disks and partitions are present; only the disk order differs. (Bug 974156)
Workaround: No workaround available. The target VM is fully functional.
Issue: On a Linux workload with multiple LVM volume groups on the same disk, the LVM volume groups are created in the opposite order on the target workload. For example, if the source volume group order is AB, the target volume group order is BA. This issue occurs for target workloads on Azure and on VMware. (Bug 973227)
Workaround: The order of the LVM volume groups on the disk does not impact functionality. The target machine works as expected.
Issue: On a Linux workload with multiple Linux partitions on the same disk, the partitions are created in the opposite order on the target workload. For example, if the source partition order is AB, the target partition order is BA. This issue occurs for target workloads on Azure and on VMware. (Bug 970822)
Workaround: The order of the Linux partitions on the disk does not impact functionality. The target machine works as expected.
Issue: If you choose to migrate a Windows Small Business Server 2011 workload to Azure, the cutover completes but the target VM in Azure is launched in Safe Mode.(Bug 978131)
Workaround: To boot the target VM in Normal Mode:
Run msconfig.
Uncheck the Boot > Safe boot option.
Reboot the VM.
Issue: After successful cutover of a workload to Azure, the Virtual Machine Settings page of the Azure Portal does not display the size of the Azure VM if the VM belongs to DSX_v2 series. Although the VM size is not shown on the settings page, the underlying VM configuration contains the VM size. (Bug 977497)
Workaround: You can see the VM size in the Azure CLI for VMs in the DSX_v2 series.
Issue: Migration to Azure fails for a SUSE Linux Enterprise Server (SLES) 11 SP4 workload that has /boot on the second drive (sdb). The migration job fails with a Configuration Not Started error. (Bug 978115)
Workaround: This configuration is not supported. Migrate supports Linux workloads with /boot on the first disk (sda).
Issue: After a successful Abort action during cutover of a source Linux VM on VMware to a target Linux VM in Azure, a subsequent cutover attempt fails with an error:
Under-control conversion of a Linux source with LVM snapshots is not supported: See /dev/<source-hostname>/root-PS-snapshot
This error occurs because the root-PS-snapshot symbolic link was not removed during the clean up process for the Abort action. (Bug 1016619)
Workaround: Manually delete root-PS-snapshot symbolic link.
Issue: On Red Hat Enterprise Linux (RHEL) 6.7, Oracle Linux 6.7, and CentOS 6.7 workloads running kernel version 2.6.32-573.el6, incremental replications do not transfer data from source to target for LVM volumes. Full replications and server sync work with this kernel version. (Bug 1018176)
Workaround: Do one of the following for RHEL 6.7, Oracle Linux 6.7, and CentOS 6.7 workloads if they have LVM volumes:
Run only full replications or server sync for workloads running the RHEL kernel version 2.6.32-573.el6.
Register with the Red Hat network and update the workload by using the Red Hat Package Manager (yum update) to get the latest available kernel fixes for RHEL 6.7. The workload is updated to use the same kernel version 2.6.32-642.13.1.el6 that is used by the RHEL 6.8 distribution. Both full and incremental replications perform as expected with this kernel version.
The following blkwatch drivers are available for RHEL 6.7, Oracle Linux 6.7, and CentOS 6.7 workloads running kernel 2.6.32-642:
Issue: On a Red Hat 6.7 or 7.1 workload, after you configure migration for a workload with no warnings or validation errors, if you enable Bandwidth Throttling and save the configuration, a validation warning pops up:
This configuration contains validation warnings. You can save the configuration or review the warnings.
The warning is triggered even if the Bandwidth Throttling setting is valid. (Bug 1021521)
Workaround: If you set a valid value, you can save the configuration and continue.
The following issues are being researched:
Issue: If you choose to migrate a RHEL 7.2 source workload that is installed with a non-default disk layout, the migration fails. (Bug 1032569)
Workaround: None.
Issue: If you choose to migrate a source workload that has volume labels containing special characters, the migration fails at the Creating and Partitioning Volumes step. (Bug 1017270)
Workaround: Ensure that the volume labels on the source workload does not contain any special characters.
Issue: If you migrate a RHEL 7.x BIOS workload having GPT partitioning scheme, the migration fails if the non-volume storage setting in the Drive Configuration > Hard Drive section of the migration job window is not selected. (Bug 1022235)
Workaround: Before migrating a RHEL 7.x BIOS workload to VMware ESX, ensure that you have selected the non-volume storage, which must be recreated during the migration, in the Drive Configuration > Hard Drive section of the migration job window.
Issue: Discovery of a Windows workload in AWS fails if you use a private IP address or if you use the WMI discovery method. Possible error messages include:
Cannot connect to named pipe Workload authentication failed
(Bug 1012001)
Workaround: For successful discovery of Windows workloads in AWS, use the workload’s public IP address and the Common Inventory discovery method.
The following issue is being researched:
Issue: On migrating a Linux workload that does not have the boot partition in the first disk to a vCloud target, the target workload fails to boot and the migration job moves to recoverable error. (Bug 1006972)
Workaround: None.
Issue: After discovery, if you select vCloud as the target container for a discovered source workload, the discovered source values for the cores and sockets settings are not correctly displayed on the Configuration page. For example, the Configuration page displays 1 core and 1 socket for a workload with discovered values of 2 cores and 2 sockets. (Bug 1020264)
Workaround: Configure the cores and sockets settings to values that you want to implement on the vCloud target.
The following issues are being researched:
Issue: For Windows source workloads with dynamic disk types of Simple, Spanned, Striped, Mirrored, and RAID5, the target workload configuration assigns nonsequential 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)
Workaround: There is no workaround.
Issue: A discovered workload lists all discovered disks on the Configuration page. If you exclude a disk from the migration and save the change, the vdisk list with corresponding disk path is reordered and the expected disk might not be the one excluded. This problem is observed for target VMware and Azure VMs. (Bug 969639)
Workaround: This is a cosmetic modification of the configuration in the UI. The underlying configuration is saved correctly and there is no need for user modification of the disk paths or disk ordering.
Issue: On a Linux workload with multiple LVM volume groups on the same disk, the LVM volume groups are created in the opposite order on the target workload. For example, if the source volume group order is AB, the target volume group order is BA. This issue occurs for target workloads on Azure and on VMware. (Bug 973227)
Workaround: The order of the LVM volume groups on the disk does not impact functionality. The target machine works as expected.
Issue: On a Linux workload with multiple Linux partitions on the same disk, the partitions are created in the opposite order on the target workload. For example, if the source partition order is AB, the target partition order is BA. This issue occurs for target workloads on Azure and on VMware. (Bug 970822)
Workaround: The order of the Linux partitions on the disk does not impact functionality. The target machine works as expected.
Issue: On Red Hat Enterprise Linux (RHEL) 6.7, Oracle Linux 6.7, and CentOS 6.7 workloads running kernel version 2.6.32-573.el6, incremental replications do not transfer data from source to target for LVM volumes. Full replications and server sync work with this kernel version. (Bug 1018176)
Workaround: Do one of the following for RHEL 6.7, Oracle Linux 6.7, and CentOS 6.7 workloads if they have LVM volumes:
Run only full replications or server sync for workloads running the RHEL kernel version 2.6.32-573.el6.
Register with the Red Hat network and update the workload by using the Red Hat Package Manager (yum update) to get the latest available kernel fixes for RHEL 6.7. The workload is updated to use the same kernel version 2.6.32-642.13.1.el6 that is used by the RHEL 6.8 distribution. Both full and incremental replications perform as expected with this kernel version.
The following blkwatch drivers are available for RHEL 6.7, Oracle Linux 6.7, and CentOS 6.7 workloads running kernel 2.6.32-642:
Issue: Configuration fails for migration of a Oracle Linux 5.x with a Paravirtual kernel under Citrix XenServer to a target VM under VMware. One of the following errors might be seen in the Migrate Client or the Web Interface:
64-bit
PlateSpin.Forge.DataAccess.Connector.PowerConvert.ConnectorException: Wrapped IndexOutOfRangeException ---> System.IndexOutOfRangeException: Index was outside the bounds of the array.
32-bit
Error, (Source) The boot loader unknown is not supported
In Migrate Client, no NIC displays in the Source Take Control adapter field. (Bugs 1001424, 1001433, 1001436)
Workaround: None. You cannot migrate an Oracle Linux 5.x (32-bit or 64-bit) workload that is paravirtualized under Citrix XenServer to VMware.
The VMware Paravirtual SCSI (PVSCSI) adapter does not support boot disks for guest operating systems running Red Hat Enterprise Linux 5.x (32-bit and 64-bit). This restriction applies to distributions based on RHEL 5.x such as Oracle Linux 5.x and CentOS 5.x. See the VMware Knowledge Base article Configuring disks to use VMware Paravirtual SCSI (PVSCSI) adapters (1010398)
.
For Linux workloads, the boot partition of the source workload must have a minimum of 100 MB free space. PlateSpin Migrate creates a new initrd image with required drivers on the source /boot directory for the initial boot of the target workload.
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.netiq.com/company/legal/.
Copyright © 2017 NetIQ Corporation. All Rights Reserved.