IBM Cloud Docs
Migrating VMDK or VHD images to VPC

Migrating VMDK or VHD images to VPC

You can convert your Intel x86-based virtual machine into VMDK or VHD format to IBM Cloud® virtual server instances to import your image to IBM Cloud VPC. You can then use a custom image to create new virtual server instances.

Before you begin

Before you begin migrating your image conversion, review the following requirements:

  1. Back up your source virtual machine that you intend to migrate.
  2. You need an existing IBM Cloud VPC environment.
  3. VMware virtual machine must be created with BIOS firmware type.
  4. Understand IBM Cloud VPC custom image requirements.
    • The custom image must contain a single file or volume
    • Is in qcow2 or vhd format
    • Is cloud-init enabled or can be booted using ESXi kickstart
    • Size doesn't exceed 250 GB
    • The minimum size is 10 GB. For any image that is less than 10 GB, the size is rounded up to 10 GB.
  5. Provision an instance of IBM Cloud Object Storage. For more information, see Granting access to IBM Cloud Object Storage to import images.
  6. You need a server with a browser that has access to both the internet and your Object Storage bucket to perform the image conversion.

Image conversion considerations

  • VMs must be exported as VMDK or VHD.
  • VMs with network-attached storage (NAS) such as iSCSI or NFS are not automatically copied over. Data migration must be done as a separate process.
  • IP addresses are not preserved.
  • Hypervisor specifics are not preserved, such as port groups and teaming.

Step 1: Prepare the image conversion server

  1. Install the IBM Cloud CLI.
  2. Install the IBM Cloud Object Storage CLI plug-in.
  3. Install the IBM Cloud VPC CLI plug-in.
  4. Install the Aspera plug-in for your system. This plug-in helps with the image upload to Object Storage. For more information about Aspera, see Using Aspera high-speed transfer.
  5. Download and install QEMU. For Windows systems, add the QEMU installation path in the system’s environment variable.

Step 2: Validate and prepare the VMs

Make sure that your VM meets the minimum requirements that are listed in the Before you begin section. However, for this step, the VM doesn't need to be in qcow2 format. The image conversion to qcow2 is covered in Step 3.

As a best practice, take a snapshot or backup of your VM before proceeding.

You can run a migration bash script for your system to help validate if the VMs meet the requirements.

Linux systems

  1. Complete steps 2-6 in Creating a Linux custom image to prepare your image.
  2. Edit the fstab file to remove entries other than "/" and "/boot".

Windows systems

See Creating a Windows custom image on how to prepare your Windows image, specific information about cloud-init, and the location for downloading Virtio drivers for Windows.

  1. Back up the administrator user files and settings.

  2. Download and prepare cloud-init.

  3. Download and install Virtio drivers.

  4. Reset network settings to default. This step disables network access to the VM.

    For Windows 2012 and 2012R2, run the following commands:

    netsh winsock reset

    netsh int ip reset c:\resetlog.txt

    For Windows 2016 and Windows 2019, go to Network settings > Network and internet status > Reset network.

    Network reset is not required for classic server migration.

  5. Restart the VM to activate the Virtio drivers.

  6. Run the sysprep command. The sysprep command generalizes and removes system-specific IDs from the operating system.

    C:\Windows\System32\Sysprep\Sysprep.exe /oobe /generalize /shutdown "/unattend:C:\Program Files\Cloudbase Solutions\Cloudbase-Init\conf\Unattend.xml"

Step 3: Convert image to qcow2

  1. Export the VM in a VMDK or VHD image file format.

  2. Copy the VMDK or VHD image to the image conversion server.

  3. Run the following QEMU command for your image file format to convert the image:

    For VMDK images:

    qemu-img convert -f vmdk -O qcow2 -o cluster_size=512k <vm_image_name.  vmdk> <vsi_image_name.qcow2>

    For VHD images:

    qemu-img convert -f vpc -O qcow2 -o cluster_size=512k <vm_image_name.  vhd> <vsi_image_name.qcow2>

If your VM has secondary vHDDs, a separate VMDK or VHD file is available for the VM. This secondary vHHD does not need to be converted to qcow2. This file is uploaded to Object Storage in its native (VMDK or VHD) file format.

You can run a migration bash script to help with the image conversion.

Step 4: Upload to IBM Cloud Object Storage

For more information about uploading to Object Storage by using the console, see Using Aspera high-speed transfer.

The converted boot image can be uploaded through the migration script by opting 'y' when prompted to upload.

Step 5: Create a virtual server instance

  1. Import your image to IBM Cloud VPC. For more information, see Importing and validating custom images into VPC.
  2. To create the virtual server instance, log in to the IBM Cloud console.
  3. Go to the menu icon Menu icon > VPC Infrastructure > Compute > Custom images > Your custom image.
  4. From the Action menu, select New virtual server.

Step 6: (Optional) Create a secondary volume and attach the virtual server instance

This step is for IBM Cloud virtual server instances that have secondary vHDD or secondary volumes.

The secondary volume needs to be equal to or greater than the secondary VMDK image size.

Linux systems

CentOS or Red Hat 7

  1. Create n+1 secondary volumes. If your VM has one secondary vHDD, then you need to create two secondary volumes for the instance. The extra volume is temporary.

  2. Download the secondary (vHDD) VMDK or VHD file from Object Storage to one of the empty secondary volumes.

  3. Install QEMU.

  4. Convert the (VMDK or VHD) image data to disk:

    For VMDK images:

    qemu-img convert -p -f vmdk <data_image.vmdk> /dev/vde

    For VHD images:

    qemu-img convert -p -f vpc <data_image.vhd> /dev/vde

  5. Mount the volume:

    mount /dev/vde1 /mnt

  6. Format and mount the other empty secondary volume:

    mount /dev/vdd1 /data

  7. Copy data over from the temporary volume (vde) to the target volume (vdd):

    cp –avf /mnt /data

  8. Unmount and delete the volume.

  9. Edit the fstab file to automount and be persistent across restart.

CentOS or Red Hat 8, Ubuntu 18.04 and 20.04, Debian 9 and 10

  1. Create secondary volumes, if your VM has secondary vHDD.

  2. Copy the VMDK or VHD image file to the migrated virtual server. Make sure that you have enough space to copy the image file. If necessary, attach a temporary volume with space for copying.

    Skip step 3 if you opted y to guestfs installation prompt when running pre-check script.

  3. Install the guestfs library.

    CentOS or Red Hat

    yum update -y

    yum install libguestfs-tools

    systemctl enable libvirtd

    systemctl start libvirtd

    systemctl status libvirtd

    Ubuntu or Debian

    apt-get update -y

    apt-get install -y libguestfs-tools

  4. Convert the (VMDK or VHD) image data to qcow2:

    For VMDK images (to qcow2):

    qemu-img convert -p -f vmdk -O qcow2 -o cluster_size=512k   secondary_volume.vmdk secondary_volume.qcow2

    For VHD images (to qcow2):

    qemu-img convert -p -f vpc -O qcow2 -o cluster_size=512k   secondary_volume.vhd secondary_volume.qcow2

  5. Mount the volume:

    guestmount -a secondary_volume.qcow2 -m /dev/sda1 --ro /mnt

  6. Format and mount the empty secondary volume:

    mount /dev/vdd1 /data

  7. Copy data over from the /mnt to the target volume (vdd):

    cp –avf /mnt /data

  8. After the copy is completed, unmount and delete the image file, if no longer needed.

    guestunmount /mnt

  9. Edit the fstab file to automount and be persistent across restart.

Windows systems

  1. Create a secondary volume.
  2. Copy the VMDK or VHD disk to Windows.
  3. Mount the image as a disk.