Transfer VM From GCP Compute Engine to Akamai Using Disk Images

In modern cloud computing, virtual machine (VM) migration is a process that enables organizations to transition workloads between cloud platforms to optimize costs, improve performance, or enhance flexibility. By migrating VMs, organizations can select the capabilities of various cloud providers that best satisfy their business needs.

This guide focuses on migrating a VM from Google Cloud Platform (GCP) to Akamai Cloud using disk images suggests how to plan, execute, and validate the migration.

Before You Begin

1. Log in to your Akamai Cloud account to prepare the destination environment.

2. Create a Linode API token (personal access token) so you can authenticate with the Linode CLI.

3. Install and configure the Linode CLI on your local system.

4. You must also have access to a GCP account with sufficient permissions to work with Disks, Storage, and Build Jobs.

5. Install and configure the GCP CLI (gcloud) to interact with your GCP VM instances.

6. Install QEMU to convert the exported disk image into a format compatible with Akamai Cloud.

Preparing Your Compute Engine Image for Migration

Before migrating, review your GCP environment to ensure compatibility with Akamai Cloud. Note any instance-specific dependencies, such as storage size, image type, or hardware requirements, that may impact the transition.

Record the configuration details of your Compute Engine VM to help choose an Akamai Cloud plan that matches your resource needs after migration.

Assess Current Compute Engine Requirements

Assess your Compute Engine VM using either the GCP Console or the gcloud CLI. Use these methods to gather the CPU, memory, storage, networking, and firewall details needed for migration.

Optional: Back up Your Compute Engine Disk

Before starting your migration, consider backing up the Compute Engine disk in case a restoration is needed in the future.

gcloud compute snapshots \
    create SNAPSHOT_NAME \
    --source-disk=DISK_NAME \
    --source-disk-zone=ZONE

Creating gce snapshot my-vm-snapshot...done.

Migrating to Akamai Cloud

Migrating a Google Compute Engine VM to Akamai Cloud involves the following steps:

• Export the VM disk image from your Compute Engine instance.
• Resize and prepare the image file for import.
• Upload the compressed image to Akamai Cloud.
• Launch a new Linode Compute Instance from the uploaded image.
• Verify and configure the new instance.

Export Your Compute Engine VM Disk Image

Export your VM to a Machine Image using either the Google Cloud Console or the gcloud CLI:

The following steps (exporting and downloading the image) require the gcloud CLI, as these operations are not available through the Google Cloud Console:

1. Create a Cloud Storage bucket to store the exported image. Replace BUCKET_NAME with a unique bucket name (e.g. migration-vm-images) and REGION with a supported region for Cloud Build image exports (e.g. us or us-central1). See Google’s list of supported regions:

   gcloud storage buckets create gs://BUCKET_NAME --location=REGION

   Creating gs://migration-vm-images/...

2. Export a compressed copy of the image to the bucket:

   gcloud compute images export \
       --destination-uri=gs://BUCKET_NAME/IMAGE_NAME \
       --image=IMAGE_NAME

   Created [https://cloudbuild.googleapis.com/v1/projects/gcp-vm-migration-450215/builds/b6d6fbf5-bc51-4228-9ca5-c1b988477fe4\].
   Logs are available at [https://console.cloud.google.com/cloud-build/builds/b6d6fbf5-bc51-4228-9ca5-c1b988477fe4?project=133697932277\].
   [image-export]: 2025-02-08T15:39:47Z Fetching image "my-vm-image" from project "gcp-vm-migration-450215".
   [image-export-ext]: 2025-02-08T15:39:48Z Validating workflow
   [image-export-ext]: 2025-02-08T15:39:48Z Validating step "setup-disks"
   [image-export-ext]: 2025-02-08T15:39:48Z Validating step "export-disk"
   [image-export-ext.export-disk]: 2025-02-08T15:39:48Z Validating step "setup-disks"
   [image-export-ext.export-disk]: 2025-02-08T15:39:48Z Validating step "run-export-disk"
   ...
   [image-export-ext]: 2025-02-08T15:39:50Z Uploading sources
   [image-export-ext]: 2025-02-08T15:39:50Z Running workflow
   [image-export-ext]: 2025-02-08T15:39:50Z Running step "setup-disks" (CreateDisks)
   ...
   [image-export-ext]: 2025-02-08T15:42:30Z Step "export-disk" (IncludeWorkflow) successfully finished.
   [image-export-ext]: 2025-02-08T15:42:30Z Running step "delete-disks" (DeleteResources)
   [image-export-ext.delete-disks]: 2025-02-08T15:42:30Z DeleteResources: Deleting disk "disk-image-export-ext".
   [image-export-ext]: 2025-02-08T15:42:30Z Step "delete-disks" (DeleteResources) successfully finished.
   [image-export-ext]: 2025-02-08T15:42:30Z Serial-output value -> source-size-gb:10
   [image-export-ext]: 2025-02-08T15:42:30Z Serial-output value -> target-size-gb:10
   [image-export-ext]: 2025-02-08T15:42:30Z Workflow "image-export-ext" cleaning up (this may take up to 2 minutes).
   [image-export-ext]: 2025-02-08T15:42:30Z Workflow "image-export-ext" finished cleanup.

???

1. Verify the file was exported, replacing BUCKET_NAME with your actual bucket name (e.g. migration-vm-images):

   gcloud storage ls gs://BUCKET_NAME

   gs://migration-vm-images/my-vm-image

2. Download the file to your local machine:

   gsutil cp gs://BUCKET_NAME/IMAGE_NAME .

   Copying gs://migration-vm-images/my-vm-image...
   | [1 files][ 10.0 GiB/ 10.0 GiB]   22.8 MiB/s
   Operation completed over 1 objects/10.0 GiB.

3. Confirm the download and check the current size of the compressed disk image file in megabytes:

   du -BM IMAGE_NAME

   748M	my-vm-image

4. Decompress the downloaded archive:

   tar -xzvf IMAGE_NAME

   disk.raw

5. Check the size of the uncompressed raw disk image:

   du -BM disk.raw

   10241M  disk.raw

   GCP persistent disks have a minimum size of 10 GB. An uncompressed size of 10 GB and a compressed size of just 750 MB indicates that the exported image includes a large amount of unused disk space.

Resize Disk Image

To import a VM image into Akamai Cloud, it must be smaller than 5 GB zipped and 6 GB unzipped. If your actual disk usage is below those limits, you can reduce the image size by deallocating unused disk space and truncating the disk size.

Shrinking the disk image involves using parted (or fdisk) and qemu-img on your local machine. These utilities operate on block devices, so you must attach the raw image using a loopback device before resizing partitions and truncating the file.

1. Enable loopback support:

   sudo modprobe loop

2. Attach the image to a free loop device:

   sudo losetup -f --show disk.raw

   /dev/loop3

3. Inspect partitions to find the main root partition number:

   sudo parted /dev/loopLOOP_NUMBER print

   In the example below, the main partition is number 1:

   Model: Loopback device (loopback)
   Disk /dev/loop3: 10.7GB
   Sector size (logical/physical): 512B/512B
   Partition Table: gpt
   Disk Flags:
   
   Number  Start   End     Size    File system  Name  Flags
   14      1049kB  4194kB  3146kB                     bios_grub
   15      4194kB  134MB   130MB   fat16              boot, esp
    1      134MB   10.7GB  10.6GB  ext4

4. Reload partition info:

   sudo partprobe /dev/loopLOOP_NUMBER

5. Mount the main partition:

   sudo mount /dev/loopLOOP_NUMBERpPARTITION_NUMBER /mnt

6. Check used space:

   df -h /mnt

   In the example below, the main partition is actually only using 2.1 GB of disk space.

   Filesystem      Size  Used Avail Use% Mounted on
   /dev/loop3p1    9.7G  2.1G  7.1G  23% /mnt

7. Unmount the main partition:

   sudo umount /mnt

8. Use parted to resize the partition to the actual usage plus a buffer of free space (e.g. 2.5GB):

   sudo parted /dev/loopLOOP_NUMBER -- resizepart 1 2.5GB

   Enter Yes and press Enter when prompted:

   Warning: Shrinking a partition can cause data loss, are you sure you want to
   continue?
   Yes/No? Yes
   
   Information: You may need to update /etc/fstab.

9. Check and resize the file system inside the resized partition:

   sudo e2fsck -f /dev/loopLOOP_NUMBERpPARTITION_NUMBER
   sudo resize2fs /dev/loopLOOP_NUMBERpPARTITION_NUMBER

10. Detach the loop device:

    sudo losetup -d /dev/loopLOOP_NUMBER
    

11. Truncate the disk image file to match the new end:

    qemu-img resize --shrink IMAGE_NAME 2.5G

12. Fix the GPT backup header to match the new size:

    sudo sgdisk --move-second-header IMAGE_NAME

13. Verify the final file size:

    du -BM IMAGE_NAME

    2500M my-vm-image

OLD

1. Use sgdisk to shrink the partition table to match the last used partition:

   sudo sgdisk --set-alternative-lba IMAGE_NAME

2. Use qemu-img to shrink the disk image file, leaving some additional buffer space. For example, if your disk image is approximately 5.5 GB, shrink the image file to 5.8 GB:

   qemu-img resize -f raw --shrink IMAGE_NAME 5.8G

3. Use gdisk to recreate the partition table headers using:

   sudo gdisk IMAGE_NAME

   Within gdisk, enter the following commands:

   • x: Switch to expert mode.
   • e: Relocate backup GPT to end of disk.
   • w: Write the new GPT to disk and exit.
   • Y: Confirm write when prompted.

   ...
   Command (? for help): x
   
   Expert command (? for help): e
   Relocating backup data structures to the end of the disk
   
   Expert command (? for help): w
   
   Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!!
   
   Do you want to proceed? (Y/N): Y
   OK; writing new GUID partition table (GPT) to my-vm-image.
   Warning: The kernel is still using the old partition table.
   The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8)
   The operation has completed successfully.

4. Confirm that the resulting disk image file is now within the size constraints for import into Akamai Cloud:

   du -BM IMAGE_NAME

   5940M	my-vm-image

5. Detach the loopback device:

   sudo losetup -d /dev/loop48

Import and Deploy VM Image on Akamai Cloud

To provision a Linode by importing an existing VM image, ensure the image is in the proper format and compressed with gzip.

Prepare Image File for Import

Linode requires image files to use the .img extension. If your exported image file does not already have this extension, rename it accordingly.

1. Rename the file to use the .img extension:

   mv my-vm-image my-vm-image.img

2. Compress the image using gzip to reduce its size:

   gzip my-vm-image.img

3. Confirm the compressed image was created and check its size:

   du -BM my-vm-image.img.gz

   1060M	my-vm-image.img.gz

Upload the Compressed File to Akamai Cloud

Use the Linode CLI to upload your compressed image file. Replace the filename with your specific .gz image, and specify the label, description, and region based on your use case.

linode-cli image-upload \
    --label "gcp-vm-migration" \
    --description "GCP VM Import" \
    --region "us-lax" \
    ./my-vm-image.img.gz

┌-----------------------┬-----------┬----------------┐
│ label                 │ is_public │ status         │
├-----------------------┼-----------┼----------------┤
│ gcp-vm-migration      │ False     │ pending_upload │
└-----------------------┴-----------┴----------------┘

The upload process may take several minutes depending on the size of your image and network speed.

Verify the Successful Image Upload

After uploading the image, verify that is was processed and is available for use. Run the following command to list your private images:

linode-cli images list --is_public false

┌------------------┬-----------------------┬-----------┬--------┐
│ id               │ label                 │ status    │ size   │
├------------------┼-----------------------┼-----------┼--------┤
│ private/30127625 │ gcp-vm-migration      │ available │ 5940   │
└------------------┴-----------------------┴-----------┴--------┘

Check that the status is available. If the status is pending, wait a few minutes and try again.

You can also monitor the upload status from the Images section of the Akamai Cloud Manager:

Launch a Linode Compute Instance from the Uploaded Image

Once your image is available, you can deploy it to a new Linode instance. For this command, provide the ID of your uploaded image (shown in the previous step). Also include the following values:

• --label: A unique label for the instance.
• --region: The preferred deployment region.
• --type: The type of instance to deploy.
• --root_pass: A secure root password for SSH access.

This example deploys a g6-standard-2 Linode with 2 vCPUs, 80 GB storage, 4 GB RAM, and a 4000 Mbps transfer rate. This is a comparable configuration to the original GCP e2-medium VM instance, which also features 2 vCPUs and 4 GB RAM. See the Akamai Cloud pricing page for more details on available instance types and their associated costs.

linode-cli linodes create \
    --image IMAGE_ID \
    --label "migrated-from-gcp" \
    --region "us-lax" \
    --type "g6-standard-2" \
    --root_pass "ROOT_PASSWORD"

┌-----------------------┬--------┬---------------┬--------------┐
│ label                 │ region │ type          │ status       │
├-----------------------┼--------┼---------------┼--------------┤
│ migrated-from-gcp     │ us-lax │ g6-standard-2 │ provisioning │
└-----------------------┴--------┴---------------┴--------------┘

By default, Linode boots instances using its own kernel. To instead boot from the kernel embedded in your imported image:

1. Navigate to your Linode under Compute > Linodes in the Akamai Cloud Manager.

2. Select your Linode instance.

3. Open the Configurations tab at the bottom, then click Edit.

4. Under Boot Settings, select Direct Disk as the kernel option.

   

5. Click Save Changes, then Reboot your Linode.

After several minutes, your Linode instance should be running using the image exported from your GCP VM.

Configure and Validate the Linode Instance

Migrating using a disk image exported from your GCP VM and disk ensures that the operating system and all installed software and services are preserved on the newly provisioned Linode. This reduces the time needed to reconfigure the Linode instance to closely match the original VM.

However, you must still configure the Linode’s networking to align with your workload. Refer to the configuration details from your original GCP Compute Engine VM and apply them to your Linode as appropriate:

• IP Addresses
• Firewall Rules
• Load Balancing
• DNS

Linode does not have a direct equivalent to GCP security groups. However, you can still implement a firewall with rules to control traffic. Options include:

• Akamai Cloud Firewall to set up inbound and outbound rules through the Akamai Cloud Manager, the Linode CLI, or API.
• iptables or ufw to manage the Linux kernel firewall (Netfilter).

To replicate GCP’s HTTPS LoadBalancers, use Akamai Cloud’s NodeBalancers to distribute traffic across multiple Linode instances.

If you used Cloud DNS to route traffic to your GCP VM, you need to update your DNS records to route traffic to your new Linode instance instead. This may involve pointing your domain nameservers to Akamai Cloud and creating DNS rules within the Akamai Cloud Manager.

After completing your configurations, test your Linode instance to verify that the migration was successful. Validation steps may include:

• Check Running Services: Confirm that all critical services (e.g. web servers, databases, and application processes) are running as expected and configured to start on boot.
• Test Application Functionality: Access your applications through their web interface or API endpoints to confirm that they behave as expected, including core functionality and error handling.
• Inspect Resource Utilization: Monitor the Linode’s CPU, memory, and disk usage to ensure the system performs within acceptable thresholds post-migration.
• Validate DNS Configuration: Ensure that any DNS changes are propagating correctly, pointing to your Linode instance, and resolving to the expected IP addresses.
• Check External Connectivity: Verify that the Linode can access any required external resources (e.g. third-party APIs, databases, or storage) and that outbound requests succeed.
• Review Logs: Examine system and application logs for errors or warnings that might indicate migration-related issues.
• Backup and Snapshot Functionality: To safeguard your data post-migration, confirm that backups and snapshots can be created successfully.
• Verify Externally Attached Storage: Ensure that any additional storage volumes, block devices, or network-attached storage are properly mounted and accessible. Check /etc/fstab entries and update disk mappings as needed.

Additional Considerations

Cost Management

Review the pricing for your current GCP Compute Engine VM instance including compute, storage, and bandwidth. Compare those costs with the Akamai Cloud pricing plans using Akamai’s Cloud Computing Calculator to estimate your usage.

Data Consistency and Accuracy

After importing your image and launching your Linode, verify that all expected files, configurations, and application data are intact. Verification steps may include:

• Generate and Compare File Checksums: Use tools like md5sum to generate checksums of both the source VM and your Linode. Ensure the checksums match to confirm data integrity.

• Count Files and Directories: Use commands like find or ls to count the number of files and directories in key locations (e.g. find /path -type f | wc -l). Compare these counts between the source VM and your Linode to identify any discrepancies.

• Check Application Logs and Settings: Compare configuration files, environment variables, and application logs between the source VM and your Linode to confirm they are identical (or appropriately modified for the new environment). Common locations to review may include:

  Application	Configuration	Location
  Apache Web Server	Main	/etc/apache2/apache2.conf
  	Virtual hosts	/etc/apache2/sites-available
  		/etc/apache2/sites-enabled
  NGINX Web Server	Main	/etc/nginx/nginx.conf
  	Virtual hosts	/etc/nginx/sites-available
  		/etc/nginx/sites-enabled
  Cron	Application	/etc/cron.d
  	System-wide cron jobs	/etc/crontab
  	User-specific cron jobs	/var/spool/cron/crontabs
  MySQL/MariaDB	Main	/etc/mysql
  PostgreSQL	Main	/etc/postgresql
  SSH	Main	/etc/ssh/sshd_config
  Networking	Hostname	/etc/hostname
  	Hosts file	/etc/hosts
  Rsyslog	Main	/etc/rsyslog.conf

• Review Symbolic Links and Permissions: Use CLI tools and commands to confirm that symbolic links and file permissions on your Linode match those on the source VM. Examples include:

  Description	Command
  List all symbolic links in folder (recursive).	`ls -Rla /path/to/folder
  Calculate md5 hash for all files in a folder, then sort by filename and write to file. Then, compare files from both VMs using diff.	`find /path/to/folder/ -type f -exec md5sum {} +
  Write to file the folder contents (recursive) with permissions, owner name, and group name. Then, compare permissions files from both VMs using diff.	tree /path/to/folder -fpuig > permissions.txt

After deploying your Linode, confirm that configurations (network settings, environment variables, and application dependencies) match the source VM to avoid runtime issues.

Security and Access Controls

GCP IAM roles govern instance access. To migrate these roles and permissions to Akamai Cloud:

• Create Linode API tokens and fine-tune user permissions.
• Reproduce GCP security group policy rules on the Akamai Cloud Firewall or existing system firewall.
• Properly configure SSH keys and disable root login if not required.

Alternative Migration Options

If exporting a disk image is not viable due to provider restrictions or image size limits, consider these alternative migration options:

• Data-only Transfer: Provision a Linode with resource levels comparable to your source VM, then use rclone to move all data from your source VM to your new Linode.
• Infrastructure-as-Code (Ia): Replicate your source VM on Akamai Cloud using tools like Ansible, Terraform, Chef, and Puppet. These tools can help replicate server configurations, deploy applications, and ensure consistency.
• Containerization: Containerize workloads and deploy them to a Linode Kubernetes Engine (LKE) cluster, eliminating the need to migrate the VM entirely.

Resources

GCP:

• GCP CLI Documentation
• GCP Export Custom Image
• VM Migration Guide
• Regions with Build Capabilities
• Troubleshooting VM Export and Import

Akamai Cloud:

• Linode CLI and Object Storage
• Uploading an image
• Deploying an Image

Other:

• QEMU Disk Imaging Utility
• rclone
• Shrinking images on Linux

More Information

You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.

• Link Title 1
• Link Title 2