Skip to main content
Version: vStor 4.17

Migrating Volumes

Prerequisites

To be eligible for migration, both the volume and the Destination Pool must meet specific criteria:

  1. Destination Pool:
    • Must not be the same as the current volume pool.
    • Must be in an ONLINE state.
    • Must have sufficient space to accommodate the migrating volume.
  2. Volume:
    • Must not have an ongoing migration.
    • The type must be FILESYSTEM, MINIO, or LUN.
    • Must not be a clone, have replication relationships, shares, or child volumes.
Tip.

If a Volume has Shares, you will be prompted with an option to detach them all at once in the web interface. This option appears after a failed migration attempt due to these conditions.

Migrating a volume using the vStor Web Interface

To migrate a volume using the vStor Web Interface:

  1. In Storage, locate a volume you want to migrate.
  2. Click More Actions (•••) and select Migrate to different pool to launch the Migrate to Different Pool dialog window.

[image expected here]

  1. Select Destination Pool and click Migrate. The migration will be run as a background task.

Migrating a volume using vStor CLI

To migrate a volume using the vStor CLI, see the following help menu for the migrate command:

vstor volume migrate --help`

Volume migration process

Creating a snapshot

  • If the Volume does not have any snapshots before the migration, an initial snapshot named volume_move_base_snapshot_<32 random character UUID> is created.
  • The migration can be queued once all pre-conditions are met and there is at least one snapshot on the Volume.

Restrictions during the migration process

During the migration, the following operations are restricted for the migrating volume and impacted pools:

  • Updating MINIO type Volume settings.
  • Locking the Volume.
  • Updating the Volume's auto-lock feature.
  • Resizing the Volume.
  • Creating child Volumes.
  • Mounting the Volume for Agentless File Restore in DPX.
  • Cloning the Volume.
  • Creating Shares, Relationships, and Host Mappings on the migrating volume.
  • Destroying or changing the state of the Pool from which the volume is being migrated, as well as the destination Pool.
  • Migrating one volume to multiple Pools simultaneously is not allowed.
Tip.

Multiple migrations can be queued, but only two will be processed concurrently.

Space Reservation and Resilience

Space is reserved on the destination Pool immediately upon starting the migration and is released upon completion, cancellation, or failure. If the migration is suspended, the reservation remains until it is resumed or canceled.

If the system or vStor service is shut down or rebooted, migrations will automatically restart within fifteen minutes after the vStor service is initialized.

Suspending and Canceling

Migration consists of two stages:

  • Stage One: The Volume remains mounted and can be written to via the host filesystem. This stage involves moving existing snapshots.
  • Stage Two: The Volume is unmounted, and a final snapshot is created to carry over data added after the move began. This stage does not concern volumes that are sources in an offload relationship.

The progress bar updates every thirty seconds, with the ETA being an approximation and subject to change based on host performance.

Suspending or canceling migration is possible, but there are protected periods when these actions cannot be taken:

  • Approximately 45–60 seconds after Stage One starts and before it finishes.
  • Approximately 45–60 seconds after Stage Two starts and before it finishes.

If you are migrating small volumes, the entire process might complete before you can suspend it. In that case, you can schedule another migration to return the volume to its original pool.

A suspended migration can be resumed from the volume details

[image expected here]

or from the Tasks view.

See also.

For more details on best practices for backup storage, see Backup Storage: Best Practices.