4.16 Managing Custom Actions

PlateSpin Migrate provides you with the capability to automatically execute custom actions, such as batch files and scripts.

4.16.1 Managing Post-Migration Actions (Windows and Linux)

To automate specific post-migration tasks on your target, you can include a custom action, such as a batch file, a shell script, or a program executable, in your migration job. At the end of the migration process, PlateSpin Migrate uploads the specified action, along with its dependencies, to the target and executes it.

Custom post-migration actions are supported for the following job types:

  • One-time Server Sync

  • Peer-to-peer workload migration

For the capability to select a post-migration action to run as part of a migration job, you must first save the action and its dependencies in a dedicated directory and add it to the PlateSpin Server’s library. The maximum size of the directory must not exceed 64 MB. For information about raising this limit, see Increasing the Size Limit on Post-Migration Actions.

Use the following procedure for adding a post-migration action to the PlateSpin Server’s library of custom actions.

  1. Create the action, test it on a sample workload, and save it together with its dependencies in a directory that the PlateSpin Server can access.

    Take special care when developing post-migration actions for Linux workloads, which allow different characters in file names and support different ACL (Access Control List) permissions. For Linux operating systems, amalgamate the action’s directory structure into a single file.

    See KB Article 7970214.

  2. In the PlateSpin Migrate Client, click Tools > Manage Actions.

  3. Click Add.

  4. In the Add Action window, type a name for your custom action, select the target operating system type, then browse to and select the directory that contains the required action with its dependencies.

    PlateSpin Migrate populates the list with the contents of the selected folder.

  5. In the File Name column, select the required executable, then click Set.

  6. In the Default Options section, specify any required command line arguments and an execution timeout, then click OK.

    PlateSpin Migrate packages and uploads the library.

The action is now available for selection in migration jobs. See Including a Custom Post-migration Action in a Migration Job.

4.16.2 Freeze and Thaw Scripting Capabilities (Linux Block-Level Migrations)

PlateSpin Migrate provides an additional means of control over your Linux block-level migration process — the freeze and thaw shell scripts.

These scripts are executed during Linux workload migrations, at the beginning and end of block-level data transfer sessions. Specifically, they interject in the migration process in the following fashion:

  1. First pass of all volumes without snapshots:

    • Regular (non-LVM) volumes

    • LVM without enough space to take a snapshot

  2. Freeze script

  3. Take snapshots

  4. Second pass of all non-snapshot volumes

  5. Thaw script

  6. Transfer volume snapshots

You can use this capability to complement the automated daemon control feature provided through the user interface (see Handling Source Workload Services or Daemons During Live Transfer (Windows and Linux).

For example, you might want to use this feature to cause an application to flush its data to disk so that the workload remains in a more consistent state during a Live Transfer migration.

To use the feature, do the following before setting up your migration job:

  1. Create the following files:

    • platespin.freeze.sh— to contain the freeze shell script logic

    • platespin.thaw.sh— to contain the thaw shell script logic

    • platespin.conf. A text file defining any required arguments, along with a timeout value.

      The required format for the contents of the platespin.conf file is:


      (optional) FreezeArguments=<arguments>

      (optional) ThawArguments=<arguments>

      (optional) TimeOut=<timeout>

      Replace <arguments> with the required command arguments, separated by a space, and <timeout> with a timeout value in seconds. If unspecified, the default timeout is used (60 seconds).

  2. Save the scripts, along with the .conf file, on your Linux source workload, in the following directory: