Copying direct volume (multi-disk method)

Migrate multi-disk VMware VMs to VPC by creating target volumes, using worker VMs for conversion with virt-v2v, and provisioning from existing boot volumes.

Architecture Components

The following table lists the architecture components of a direct volume copy migration.

Architecture components for direct volume copy migration method
Architecture components Description
Worker virtual server instance

A temporary virtual server instance that serves as your migration workspace. This virtual server instance needs the following prerequisites:

  • Adequate CPU and memory to run conversion tools

  • Sufficient workspace storage to hold exported VMDKs (or large ephemeral disk)

  • Network connectivity to your VMware environment (if you use live transfer)

  • The qemu-img tool and optionally libguestfs (virt-v2v) for transformations
Ephemeral virtual server instance A short-lived virtual server instance created solely to generate boot and data volumes with the correct configuration. You delete this virtual server instance immediately but keep its volumes.
Target Volumes The actual volumes that become your migrated VM's disks.

Overview of the copying direct volume migration process

The following steps layout the process to migrate by using direct volume copy.

  1. Provision worker virtual server instance

    1. Ubuntu or RHEL instance with adequate workspace
    2. Attach a large secondary volume if workspace is needed for VMDKs
    3. Install the required tools
      • qemu-img
      • libguestfs-tools (for virt-v2v)

  2. Create Ephemeral virtual server instance

    1. Configure it to match your target VM (OS, boot disk size, secondary disk count/sizes)
    2. Critical: Disable auto-delete on all volumes
    3. Critical: Use general-purpose storage profile for boot volume
    4. Network configuration can be throwaway
    5. Note the volume sizes and order

  3. Delete Ephemeral virtual server instance, Retain Volumes

    1. Delete the virtual server instance through UI or CLI
    2. Confirm that volumes still exist and are available for attachment

  4. Attach Volumes to worker virtual server instance

    1. Attach them in the same order that they were created
    2. Note device names (for example, /dev/vdb, /dev/vdc, and so on)
    3. Verify sizes: blockdev --getsize64 /dev/vdb

  5. Transfer and convert VM Disks

    1. If exported: Copy VMDK to worker virtual server instance
    2. Convert and write in one step:
    qemu-img convert -f vmdk -O raw source-vm-boot.vmdk /dev/vdb
qemu-img convert -f vmdk -O raw source-vm-data.vmdk /dev/vdc
    1. Optionally use virt-v2v for Windows driver injection (see the following Windows section)

  6. Verify and Flush

    1. Spot check partition tables: fdisk -l /dev/vdb
    2. Flush buffers: blockdev --flushbufs /dev/vdb

  7. Detach Volumes from worker

    1. Detach all target volumes
    2. They're now ready to be attached to the final virtual server instance

  8. Create Final virtual server instance from Existing Boot Volume

    1. Instead of selecting an image, select "existing boot volume"
    2. Choose the boot volume that you populated
    3. Configure network, security groups, SSH key (required even though it is not used if it is an existing VM)
    4. For secondary volumes: Use CLI/API or attach after creation and restart

  9. Post-Migration Configuration

    1. Boot virtual server instance, access through VNC console if network config needs adjustment
    2. Verify that all disks are present and mounted
    3. Expand boot volume partition if you resized it upward

Direct volume copy design advantages

The following table lists the design advantages of direct volume copy migration.

Design advantages for direct volume copy migration method
Design advantage Description
Multi-Disk Support Multi-disk support handles virtual machines with any number of disks, up to VPC's 12-disk limit.
No Image Proliferation You're not creating a custom image for each virtual machine. Your custom image list stays clean.
Flexible Transformation Enables easy integration with virt-v2v for driver injection, OS tweaks, and so on.
Storage Efficiency Option If you import a base template as a custom image and use it as the boot volume source for your ephemeral virtual server instance (step 2), the final boot volume inherits the linked-clone space efficiency.

Direct volume copy design constraints and limitations

The following table lists the constraints and limitations of a direct volume copy migration.

Limitations and constraints for direct volume copy migration method
Limitation or Constraint Description
Orchestration Complexity There are more steps and moving parts. You need solid runbooks and preferably automation (Terraform, Ansible, scripts).
Volume attachment limitations.

The IBM Cloud UI doesn't support attaching secondary volumes during virtual server instance creation. You must do one of the following:

  • Use CLI: ibmcloud is instance-create ... --volume-attach ...

  • Use API/Terraform for full automation

  • Create the virtual server instance, stop it, attach volumes, then start it
Export overhead If you're exporting VMDKs from VMware, you still incur that overhead (though less than OVA export).

Skip export by using network transfer

You can combine Method 2 with network transfer techniques (detailed in Method 3) to avoid exporting VMDKs entirely. Boot your source VM from an ISO, establish network connectivity to your worker virtual server instance, and stream the disk contents directly:

  1. On the worker virtual server instance (destination), issue the following command:

    nc -l 192.168.100.5 8080 | gunzip | dd of=/dev/vdb bs=16M status=progress

  2. On the source virtual machine (booted from ISO), issue the following command:

    dd if=/dev/sda bs=16M | gzip | nc -N -v 192.168.100.5 8080

This process eliminates export time and export storage requirements.

Using this process for multi-disk VMs, for scenarios where you want precise control, or where avoiding custom image proliferation is important. You can improve efficiency with network transfer too.