2.2 Supported Data Transfer Methods

Depending on the selected workload and the migration type, PlateSpin Migrate enables you to select different methods for transferring workload data from the source to the target.

For information on how to select a transfer method, see Specifying Conversion Options.

2.2.1 File-Level Transfer (Live)

The File-Based Live Transfer method, available for Windows workloads, copies data and replicates changes at the file level.

To ensure data consistency, this method leverages the Microsoft Volume Shadow Copy Service (VSS) if available. Many enterprise apps are integrated with VSS; for those which are not, PlateSpin Migrate provides the capability to briefly pause services while the VSS snapshot is captured, to ensure that the data of those applications is captured in a consistent state.

If VSS unavailable (for example, in workloads running Windows Server 2003 with no service packs), PlateSpin Migrate monitors source volumes for changes while transferring data. When the initial transfer is complete, migrate re-sends any files that have changed. If the rate of file system changes is consistently high, data transfer is stopped and a job progress warning is shown.

You can configure your migration job to stop high-transaction services, such as Microsoft SQL Server or Microsoft Exchange Server, during the transfer (see Handling Source Workload Services or Daemons During Live Transfer (Windows and Linux)). This has two benefits:

  • It ensures that the databases of these applications are transferred in a more consistent state.

  • It reduces the rate of file system changes so that PlateSpin Migrate is able to keep up with them and complete the transfer.

This method might be appropriate for moderately active systems and it provides you with the capability to resize your volumes on the target workload.

2.2.2 Block-Level Transfer (Live)

The Block-Based Live Transfer method, available for both Windows and Linux workloads, enables PlateSpin Migrate to transfer data at the block level, providing an exact copy of the source workload.

For Windows workloads, PlateSpin Migrate leverages the Microsoft Volume Snapshot Service (VSS) (Windows 2003 SP1 and later) with applications and services that support VSS.

For Linux workloads, Migrate supports only block-based data transfer with a blkwatch driver. The Migrate distribution includes precompiled blkwatch drivers for workloads running the standard, non-debug kernels of supported Linux distributions. See Pre-compiled blkwatch Drivers for Linux Distributions.

If your workloads have a non-standard, customized, or newer kernel, you can build a custom blkwatch driver for your specific kernel. See Knowledgebase Article 7005873 How to Build a Custom Block-Based Linux Kernel Driver.

NOTE:Deployment or removal of the blkwatch driver is transparent, has no continuity impact, and requires no intervention and no reboot.

The blkwatch driver leverages LVM snapshots if they are available. Copying data from the snapshot helps avoid potential open file conflicts. See Knowledgebase Article 7005872 Using LVM Snapshots for Migrating and Protecting Linux Workloads. If LVM snapshots are not available, Migrate locks and releases each block in turn for data transfer.

The Block-Based Live Transfer method is the preferred data transfer method for both Windows and Linux workloads.

2.2.3 Offline Transfer with Temporary Boot Environment

This method enables PlateSpin Migrate to boot your source machine into a temporary pre-execution environment and transfer the data while the source is offline. This method is not applicable with the PlateSpin Migrate Web Interface.

NOTE:The Offline Transfer method lets you migrate the Windows Server 2003 SP0 workloads:

Before you use the Offline Transfer method to migrate a Windows Server 2003 workload, you must do the following:

  1. Edit the boot.ini file on the workload to set the /noexecute parameter to alwaysoff.

  2. Restart the workload.

The pre-execution environment underlying the Offline transfer method makes use of a Linux Ramdisk, which contains a minimal set of system files, drivers, and executables, sufficient for an initial, temporary boot. To ensure that the source operating system properly loads and operates in the temporary pre-execution environment, PlateSpin Migrate temporarily modifies its boot files and restores them to their original state after the pre-execution environment has successfully loaded.

The Ramdisk is also used to temporarily boot target physical machines in X2P migrations, as well as to boot target VMs in semi-automated migrations.

See also, Discovering Target Physical Machines, and Migrating a Workload to a VM Host Using the X2P Workflow.