Automate the Migration of a Workload Based on Virtual Servers from Classic Infrastructure to VPC

4 min read

Learn how to use IBM Cloud CLI and Terraform to move a virtual server between Classic Infrastructure and VPC

There are tons of existing workloads running on virtual machines. On IBM Cloud, they could be running under a hypervisor on a bare-metal server, in a public virtual server, or even on a dedicated virtual server. And these are only a subset of the available options. Over time, requirements evolve, and for cloud-native applications, deploying virtual instances in a Virtual Private Cloud (VPC) might become a better option to run in an isolated environment with the agility and ease of a public cloud.

Today, I'll be focusing on virtual server instances running on Classic Infrastructure and how to move them to a VPC.

Migrating one virtual server instance

In the Classic Infrastructure, you have the ability to capture an image template of a running virtual server instance. With the image template, you can quickly replicate the server configuration with minimal changes in the order process.

The good news is that the same image can then be used to provision a virtual server instance in VPC if you follow the documented steps.

At a high-level, the migration steps are as follows:

  1. Capture an image of a running instance.
  2. Export the image to a bucket in Cloud Object Storage.
  3. Import this image in the list of custom images for VPC.
  4. Provision a virtual server instance for VPC from this image.
Migrating a virtual server instance from Classic Infrastructure to Virtual Private Cloud on Classic.

Migrating a virtual server instance from Classic Infrastructure to Virtual Private Cloud on Classic.

Using automation to avoid repetitive steps

Going through this process for one virtual server is okay but if you have several virtual server instances to migrate, you may want to look on the automation side.

This is exactly what I did; once you go through the steps manually, it becomes clear that all those steps in the IBM Cloud console can be automated with their command line counterparts. Equipped with IBM Cloud CLI and Terraform, I decided to write a set of shell scripts and terraform templates to prove it.

The files can be found in the Git repository. Note that you will find more VPC examples in other folders in this repository. These examples are companions to our VPC tutorials.

The scripts under vpc-migrate-from-classic show an example to migrate a CentOS VSI running in the Classic Infrastructure to a VSI running in VPC. The scripts automate all steps you would find while going through the documentation:

  1. Create a Cloud Object Storage (COS) instance and a bucket to store the image to capture.
  2. Set up an IAM authorization between COS and the VPC Image service so that the VPC Image Service can read the image from the bucket in COS.
  3. Create a VSI in the Classic Infrastructure.
  4. Install Nginx on the VSI so that later we can verify the new VSI also runs Nginx.
  5. Capture the VSI image and wait for the image to be ready.
  6. Copy the image to COS.
  7. Import the image into the VPC Custom Image list once the image is ready in COS.
  8. Provision a new VSI in VPC from this image.

Running the automation scripts

To make it easier to understand what happens, I created several scripts mapping to the high-level steps:

 ~/dev/vpc-tutorials/vpc-migrate-from-classic>  ls -1a 0*
000-prereqs.sh
010-prepare-cos.sh
020-create-classic-vm.sh
030-capture-classic-to-cos.sh
040-import-image-to-vpc.sh
050-provision-vpc-vsi.sh
060-cleanup.sh

Instructions on how to run the scripts can be found in the folder README. You will need the right permissions to work with VSIs in Classic Infrastructure, with images, with VPC, with Cloud Object Storage. 

In addition the scripts rely on IBM Cloud CLI, Terraform, IBM Cloud Provider for Terraform, and JQ. You will also need a SSH key—which you should be familiar with if you are working with virtual servers.

Once you have configured your environment with the local.env file, you can start running the scripts 000-prereqs.sh, 010-prepare-cos.sh... Only call 060-cleanup.sh to remove all resources created by the previous scripts.

000-prereqs.sh performs basic checks about the target resource group, the required IBM Cloud plugins and external tools.

010-prepare-cos.sh creates a Cloud Object Storage service and a bucket. It also sets up an authorization with the VPC Image Service so that later on this service can read the image stored in Cloud Object Storage.

The bucket where the captured image will be stored.

The bucket where the captured image will be stored.

020-create-classic-vm.sh uses Terraform to provision a virtual server instance with a public IP address. It also installs Nginx on the server and waits for the server to be ready.

The virtual server instance provisioned with Terraform.

The virtual server instance provisioned with Terraform.

030-capture-classic-to-cos.sh creates an image template for the server. 

Image template of the virtual server instance.

Image template of the virtual server instance.

Once this image is captured, it copies the image to Cloud Object Storage.

Image copied to Cloud Object Storage.

Image copied to Cloud Object Storage.

040-import-image-to-vpc.sh imports the image into VPC Image Service.

Image imported into VPC Custom Images.

Image imported into VPC Custom Images.

050-provision-vpc-vsi.sh uses Terraform to create a VPC, a subnet, and a virtual server instance from the imported image. It assigns a public IP address to the instance and tries to access the installed Nginx server. If it works, we have successfully migrated a VSI running on Classic Infrastructure to VPC!

Virtual Server Instance created from the image.

Virtual Server Instance created from the image.

Nginx accessible at http://floating-ip-assigned-to-the-instance.

060-cleanup.sh deletes all the resources used in the scripts including VPC, VSI, COS, images using a mix of IBM Cloud CLI and Terraform.

Conclusion

The scripts listed here handle the most simple migration case but give the foundation of more complex setup. 

Keep in mind that only instances created with a cloud-init enabled image can be migrated with this process. Also, only image templates with a single primary boot volume (or disk) and associated file can be imported to IBM Cloud VPC infrastructure. Secondary disks and their associated files for an image template are not supported.

If you have feedback, suggestions, or questions about this post, please reach out to me on Twitter (@L2FProd).

Be the first to hear about news, product updates, and innovation from IBM Cloud