Copying direct volume (multi-disk method)

For multi-disk virtual machines where you can to avoid image proliferation and scenarios requiring precise control over volume configuration, you can migrate to a virtual server using the direct volume copy (multi-disk migration) migration method. Instead of importing a virtual machine as an image, you instead create empty volumes with the exact specifications you need. You then directly write your virtual machine's contents to those volumes.

Architecture Components

The following tables 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: 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 using 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'll delete this virtual server instance immediately but keep its volumes.
Target Volumes	The actual volumes that will become your migrated VM's disks.

Overview of the copying direct volume migration process

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

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 required tools
  - qemu-img
  - libguestfs-tools (for virt-v2v)
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
Delete Ephemeral virtual server instance, Retain Volumes**
1. Delete the virtual server instance via UI or CLI
2. Confirm volumes still exist and are available for attachment
Attach Volumes to Worker virtual server instance**
1. Attach them in the same order they were created
2. Note device names (e.g., /dev/vdb, /dev/vdc, etc.)
3. Verify sizes: blockdev --getsize64 /dev/vdb
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 Windows section below)
Verify and Flush**
1. Spot check partition tables: fdisk -l /dev/vdb
2. Flush buffers: blockdev --flushbufs /dev/vdb
Detach Volumes from Worker**
1. Detach all target volumes
2. They're now ready to be attached to the final virtual server instance
Create Final virtual server instance from Existing Boot Volume**
1. Instead of selecting an image, select "existing boot volume"
2. Choose the boot volume you populated
3. Configure network, security groups, SSH key (required even though it won't be used if this is an existing VM)
4. For secondary volumes: Use CLI/API or attach after creation and reboot
Post-Migration Configuration**
1. Boot virtual server instance, access via VNC console if network config needs adjustment
2. Verify 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, etc.
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 constratins 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:

On the workter virtual server instance (destination), issue the following command:
```
nc -l 192.168.100.5 8080 | gunzip | dd of=/dev/vdb bs=16M status=progress
```
On the source virtual machined (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 to.