PlateSpin Migrate 11.1 Release Notes

September 24, 2014

PlateSpin Migrate version 11.1 provides a number of new features, enhancements, and bug fixes.

For documentation that accompanied earlier releases, visit the PlateSpin Migrate 11.1 Documentation Web Site and scroll to Previous Releases.

1.0 What’s New in This Release

  • Fully automatic conversion to Windows Server 2012 Hyper-V/Windows Server 2012 R2 Hyper-V containers.

  • Command Line Interface (CLI) support for migrations to VMware targets, including these operations:

    • discovery

    • undiscovery

    • conversion

    • server sync

    • imaging

  • Offline transfer support for Windows workloads (added to existing offline transfer support for Linux workloads).

  • Newly supported: This release introduces workload and container support for the following platforms:

    • Novell Open Enterprise Server (OES) 11 SP2

    The following are also now supported:

    • vSphere 5.0 Update 3, vSphere 5.1 Update 2, and vSphere 5.5 Update 1 workload containers

    • Windows Server 2008 R2 cluster.

    • Semi-Automatic conversion to

      • SUSE Linux Enterprise Server (SLES) 11 SP3 Xen container for fully virtualized guests

      • SLES 11 SP3 KVM

      • Redhat Enterprise Linux (RHEL) 6.4 KVM

  • Miscellaneous: The following features are also worthy of note in this release:

    • Ability to upgrade from PlateSpin Migrate 11.0

    • The product has been localized for installation and use on machines configured for the German, French, and Japanese languages.

Not supported in this release

  • Installation of the PlateSpin Migrate 11.1 server on a Microsoft Windows 2008 64-bit host is currently not supported.

2.0 Bug Fixes

The following is a list of bugs that were fixed for this release:

  • 815417 - Source Server disappears from UI if Target VM folder name is the same as the source hostname. The behavior has been corrected.

  • 874419 - “Select Platespin Network Location” is not available when using boot ISO. The user can now discover and execute conversions by specifying custom network name.

  • 877675 - Refresh does not update the discovery time data for VMs. Workload properties are now refreshed properly.

  • 880457/880868 - Migrate Conversion job UI does not allow to add more than 13 disks. A drive letter is assigned on the target for each mount point on the source server. The behavior has been corrected.

  • 884726 - PlateSpin Migrate 11 data transfer speed is much slower than earlier versions of the product. This release (11.1) runs substantially faster than PlateSpin Migrate 11.0.

  • 888956 - Discovery of Linux source workload fails if using sudo user in the password requiredmode. The correct options/switches were not being used in the sudo command in the code. The behavior has been corrected.

  • 890463 - Job fails at the Prepare OS to boot step. Error: The drive name does not exist Parametername. The package installer now sets the correct registry key. The behavior has been corrected.

  • 892171 - Generating diagnostics fails with Diagnostic HTML generation failed error. Localization changes made in Migrate 11.0 (escape character missing in filename invocations) caused the problem. The behavior has been corrected in the 11.1 release.

3.0 Known Issues

  • No software RAID support for Linux workloads: PlateSpin Migrate does not support Linux workloads with volumes on software RAID.

  • Requirements for VMware DRS Cluster support: 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.

    See “Discovery Guidelines for Machine Types and Credentials” in your User Guide.

  • 493589 - (Windows sources) Non-default per-volume VSS settings are not preserved after migration: This issue is under consideration for an upcoming fix.

  • 505426 - (ESX4) No warning or error on wrong vCPU selection: If the number of the requested vCPUs exceeds the number of physical CPUs on the ESX 4 host, the requested number is ignored and the target VM is created with a single vCPU without a warning. This issue is under consideration for an upcoming fix.

  • 506154 - Special character in datastore name causing migration problems: Migration operations might fail when they are attempted on ESX datastores that have the “+” or other special characters in the datastore name.

    See KB Article 7009373.

  • 595490 - Preserving boot partition causes migration problems: In some migration scenarios, the system improperly allows you to preserve your boot partition on the target, preventing the proper workload from booting. This issue is under investigation.

    Workaround: Do not opt to preserve your boot partition on the target.

  • 604320 - (Linux to ESX 4) Problem completing migration if the source OS has autologin or CD automount features enabled: The migration is also affected if you log in to the target during the job’s Configuration step.

    Workaround: Disable the autologin and CD automount features on the source; avoid logging in to the target workload prior to the completion of the migration.

  • 619942 - Failure to execute a post-migration script with Unicode characters in the filename: If you use Unicode characters in the filename of your post-migration script, the script fails to execute.

    Workaround: Use only ASCII characters when naming a post-migration action.

  • 655828 - Failure to mount NSS volumes: After a migration is completed, NSS volumes with snapshots enabled are not automatically mounted as expected.

    See KB Article 7008773.

  • 660790 - User cannot skip VMware Tools uninstall during migration. If the user sets the Install VMware Tools for ESX option to Yes before running a migrate job, the tools do not uninstall and reinstall.

  • 680259 - (VMware 4.1) Poor networking performance by traffic-forwarding VMs: In some scenarios, the replica of a workload that is forwarding network traffic (for example, if the workload’s purpose is to serve as a network bridge for NAT, VPN, or a firewall) might show significant network performance degradation. This is related to a problem with VMXNET 2 and VMXNET 3 adapters that have LRO (large receive offload) enabled.

    Workaround: Disable LRO on the virtual network adapter. For guidance, see the VMware vSphere 4.1 Release Notes (scroll down to the bulleted item Poor TCP performance...).

  • 685509 - Failure with Access Denied error during replication to an image stored on a network share: The Controller service on Image servers that use network shares for storage does not preserve the service Log On As credentials after an upgrade. Image operations fail with an Access Denied message until the controller service is updated with the correct Log On As credentials.

    See KB Article 7008772.

  • 692680 - VSS snapshots are not preserved: VSS snapshots taken by third-party applications on the source workload are not replicated to the target upon migration.

  • 702152 - Migration over WAN taking a long time if target VM host has a high number of datastores: Under some circumstances, when your Migrate server is connected to the VM host over 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. This issue is under investigation.

  • 779194 - Unmapped /home directory is disabled and unmounted after one time server sync: If you perform a server sync and then unman the /home partition to none, the partition /home directory should be mounted and enabled on the target server, instead it is disabled and unmounted.

    Workaround: Following the Server Sync, uncomment the appropriate line in the target server’s /etc/fstab file.

    See KB Article 7014638.

  • 810460 - VMware tools are not installed during a conversion of a Windows 20212 server core: VMware tools are not installed during a conversion of a Windows 2012 server core.

    Workaround: Install the VMware tools manually after the conversion.

  • 822601 - Network card is not initialized on SLES 11 target VM hosted on Windows 2008 Hyper-V host: If you perform a SLES 11 workload (cloned VM) migration using the semi-automated method to a target VM (faked physical) on a Windows 2008 Hyper-V host, the process freezes at the "Configuring OS" step.

    Workaround: For information about working around this issue, see KB 7012911.

  • 824724 - Target VM does not boot after migration from VMware ESX to Citrix Xen if boot files are located in second disk: 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 Citrix XEN VM tries to boot with disk 0 rather than with the bootfiles allocated to disk 2.

    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 also KB Article 7012906.

  • 825016 - XenServer tools are not being removed after conversion: 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.

    Workaround: The user must manually uninstall the XenServer tools after conversion.

  • 825434 - After migration, the primary partition (C:\) is converted to a logical partition on the target: 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.

    Effect: After the migration, the Windows OS machine is unable to boot.

    Example: The following error occurs when Windows 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: For information about working around this issue, see KB Article 7012913.

  • 826545 - When Migrate undiscovers a machine, the machine node shown on the ESX host is not undiscovered: When you undiscover a workload, it displays as such in the Migrate client, but the ESX host shows that the node is not undiscovered.

    Workaround: Undiscover the workload on the ESX host, then refresh the ESX host.

  • 839329 - Attempt to retrieve data from VMware vCenter Server failed with the following exception: Permission to perform this operation was denied. This problem can be corrected by following the procedures to define VMware Roles with tools as described in Using Tools to Define VMware Roles in the PlateSpin Migrate 11.1 User Guide.

  • 843431 - Attempting to boot from Hard Drive (C:) - Error loading operating System. MBR is corrupted. This problem can be corrected by running the ./BcdEditor /fixboot command in the LRD.

    See also KB Article 7014709.

  • 859440 - V2P conversion hangs at the configuringoperating system step. 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.

    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.

  • 864325 - Windows 8.1 workloads converting UEFI to BIOS fail to convert at the “sending files” step. 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.

    Workaround: Remove or expand the recovery partition. For more information, see KB Article 7014696.

  • 864326 - Conversion fails while downgrading from UEFI to BIOS firmware: 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.

    Workaround: To work around this problem, 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.

  • 865570 - File-based transfer breaks for Windows 2012 R2 UEFI workload: X2P File-based transfer of Windows 6.2 and above kernel versions fails during the sending and receiving files stage.

    Workaround: To force file transfer to work in this X2P scenario, you need to disable the CPU advanced flags in the firmware: VT-d, VT-s, Execute Disable Bit. For more information, see KB Article 7014698.

  • 866467 - Image capture of a Windows 32-bit OS fails: Migrate expects a folder named C:\Windows\Boot\EFI to be present in the source server for exporting content for future use. The folder is not present in Windows 32-bit operating systems earlier than Windows 2008/Vista, so when Migrate exports BCD information to the folder, the operation fails with the error:

    Error message: Failed: C:\Windows\Boot\EFI
    

    Workaround: To work around this issue, you need to create the C:\Windows\Boot\EFI folder, then create a Directory Junction under C:\Windows for C:\Windows\System32. For more information, see KB Article 7014710.

  • 875562 - Source machine stays in an “under control” state after offline conversion,: 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.

    Workaround: Manually restart the source when the conversion completes.

  • 878043 - Source machine boot configuration is not restored after offline conversion: The boot menu of windows source machine is not restored after offline conversion.

    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 purges the boot menu of the LRD boot option in future boot operations.

  • 891690 - Creating and moving a VM under resource pool as a setting is not supported in the CLI tool: The command line interface (CLI) tool added as a new feature in this release does not currently support moving or creating a VM under resource pool as a setting in the conversion.ini file.

    Workaround: After the conversion, manually move the new machine to the resource pool you want.

  • 894623 - Partitions are not mounted to drive letters after conversion: Following a conversion to Hyper-V 2012 R2, only the "C" drive is visible. Other partitions are not mounted to drive letters.

    Workaround: After conversion, go to disk management and manually assign the drive letters to the partitions.

  • 896584 - Adding disk and volume mapping does not work properly for a conversion of a workload to Hyper-V2012 R2: Booting the Hyper-V VM with LRD returns randomly listed devices in Hard Disk Devices List, whether IDEs, SCSIs, or a mix of both.

    Workaround: The list should contain IDE disks at the top, and SCSI disks following. Use the Migrate Client to customize the list.

    The following scenarios provide examples of the list behavior. Assumptions in these scenarios: The target VM is Generation 1. You need to create three or more virtual disk drives:

    Scenario 1-- IDE to SCSI Behavior

    Given initial setting:

    • Disk2: IDE
    • Disk3: IDE
    • If Disk2 changes to SCSI, Disk3 changes to SCSI. List settings after the modification display as:

      • Disk2: SCSI
      • Disk3: SCSI
    • If Disk3 changes to SCSI, Disk2 does not change. List settings after the modification display as:

      • Disk2: IDE
      • Disk3: SCSI

    Scenario 2-- SCSI to IDE Behavior

    Given initial setting:

    • Disk2: SCSI
    • Disk3: SCSI
    • If Disk2 changes to IDE, Disk3 does not change. List settings after the modification display:

      • Disk2: IDE
      • Disk3: SCSI
    • If Disk3 changes to IDE, Disk2 changes to IDE. List settings after the modification display:

      • Disk2: IDE
      • Disk3: IDE
  • 896598 -Redundant disks present after a RHEL 6.2 x64 block migration to Hyper-V 2012 R2: 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.

    This is a known Microsoft issue and is being addressed.