#15 on Fast Company’s Best Workplaces for Innovators List – Learn more

Migrating your unloved end-of-life legacy applications to Google Cloud

legacy-application-migration-to-the-cloud

The reality of end-of-life legacy applications

At DoiT International, we see customers at various stages on the cloud journey. Some are already cloud native and do not have much technical debt yet, whereas others have legacy applications they have kept for different reasons. Some try to keep their legacy applications up-to-date, and some end up being the subject of this article – hosting unloved legacy applications on end-of-life (EOL) operating systems. If you have such applications and wish to move them to Google Cloud, this article is for you. You will learn about the options available to you, which will hopefully help you make the right decisions for your workloads.

The genesis for this article came from observing a few customers looking at Google Cloud VMware Engine (GCVE) to run their legacy applications running on Google Cloud. Being VMware under the covers, GCVE is a great way to run certain VMs, including those with EOL operating systems.  The problem with GCVE is that it doesn’t scale down very well for smaller workloads, and it is a cost-efficient option only if you’re leveraging the resources in the smallest configuration available.

While GCVE is definitely an option for running your legacy applications on Google Cloud, I wouldn’t recommend it as the first option unless your workloads demand that sort of scale. We’ll talk more about this later.

I investigated why customers were concluding they needed GCVE to run their legacy EOL applications and found a few roadblocks:

First, I saw customers trying to create new virtual machines from EOL operating systems, such as Centos 6.  You’ll soon find that the image is no longer listed in Google’s publicly available images.  Okay, what’s next?

The next step was to attempt using Google Compute Engine’s import feature, which performs ad-hoc imports of VM images.  You would expect this to work with past OS versions, but when I tried to import an EOL OS – Centos 6 in this example – I received sad news:

$ gcloud compute instances import centos-6 --source-uri=gs://eol-migration1322/centos6 --zone=us-central1-a 

WARNING: Importing OVF. This may take 40 minutes for smaller OVFs and up to a couple of hours for larger OVFs.

Created [https://cloudbuild.googleapis.com/v1/projects/johnd-test-01/locations/us-central1/builds/0e67bbb8-3389-4a34-adae-5f5566732085].

Logs are available at [https://console.cloud.google.com/cloud-build/builds;region=us-central1/0e67bbb8-3389-4a34-adae-5f5566732085?project=306419495665].

starting build "0e67bbb8-3389-4a34-adae-5f5566732085"

[import-ovf]: 2022-07-05T21:25:20Z Starting OVF import workflow.

[import-ovf]: 2022-07-05T21:25:21Z Found gs://eol-migration1322/centos6/centos6.ovf

[import-ovf]: 2022-07-05T21:25:21Z Found gs://eol-migration1322/centos6/centos6-disk1.vmdk

[import-ovf]: 2022-07-05T21:25:21Z Didn't find valid OS info in OVF descriptor. OS will be detected from boot disk.

[import-ovf]: 2022-07-05T21:25:21Z Will create instance of `g1-small` machine type.

[import-disk-1]: 2022-07-05T21:25:22Z Inspecting the image file...

[import-disk-1]: 2022-07-05T21:28:26Z Inspecting disk for OS and bootloader

[import-disk-1]: 2022-07-05T21:30:05Z Inspection result=os_release:{cli_formatted:"centos-6"  distro:"centos"  major_version:"6"  minor_version:"10"  architecture:X64  distro_id:CENTOS}  elapsed_time_ms:98933  os_count:1

[import-ovf]: 2022-07-05T21:30:06Z Cleaning up.

[import-ovf]: 2022-07-05T21:30:06Z os `centos-6` is invalid. Allowed values: [centos-7 centos-8 debian-10 debian-11 debian-8 debian-9 opensuse-15 rhel-6 rhel-6-byol rhel-7 rhel-7-byol rhel-8 rhel-8-byol rocky-8 sles-12 sles-12-byol sles-15 sles-15-byol sles-sap-12 sles-sap-12-byol sles-sap-15 sles-sap-15-byol ubuntu-1404 ubuntu-1604 ubuntu-1804 ubuntu-2004 windows-10-x64-byol windows-10-x86-byol windows-2008r2 windows-2008r2-byol windows-2012 windows-2012-byol windows-2012r2 windows-2012r2-byol windows-2016 windows-2016-byol windows-2019 windows-2019-byol windows-2022 windows-2022-byol windows-7-x64-byol windows-7-x86-byol windows-8-x64-byol windows-8-x86-byol]

ERROR

ERROR: build step 0 "us-central1-docker.pkg.dev/compute-image-tools/wrappers/gce_ovf_import:release" failed: step exited with non-zero status: 1

ERROR: (gcloud.compute.instances.import) build 0e67bbb8-3389-4a34-adae-5f5566732085 completed with status "FAILURE"

So the image import option only supports select OSs and versions – Centos-6 not being one of them.  Whether you do this from the Google Cloud console or the command line, the result is the same. That closes the door on the “easy button” option of importing the disk images directly into Google Compute Engine (GCE).

At this point, someone might find GCVE and discover it will still run anything VMware is capable of running. A cluster gets spun up and configured and VMs get imported – just like on-prem. Job done, great!  Or is it?

Current state of Google Cloud support for EOL OS images

Much of Google’s support documentation regarding EOL operating systems focuses on recommendations on updating the EOL operating system first. This is certainly best practice, but not everyone can do this. The application’s developers may no longer be available, or there may be dependencies on certain libraries or just a lack of resources to update the application. 

Options for importing your EOL OS virtual machines to GCE

Here are the options available in no particular order. Each has their pros and cons.

Option 1: Reinstall the legacy application using a deprecated public GCE image

As mentioned earlier, I’ve seen customers who have tried to use native Google Cloud images being unable to find any initially. It turns out Google has kept the images available, just not easily visible.  Reading some of the support documentation for EOL images, I found the images are available but marked depreciated. Here’s some sample documentation for Centos 6.

From the Google Cloud GCE Console under Images, a toggle switch shows depreciated images.  Turn this on and voilà, a list of all past GCE images appears:

application migration

Filter for what you’re looking for, in my case, Centos 6 images, select the image you would like to use, and you can create a GCE instance from that image.  

From the command line, you can achieve the same with:

gcloud compute images list --show-deprecated

The advantage with this option is that you have an original Google image with Google tools such as the os-agent and any OS-level changes needed for the OS to run on Compute Engine already made.  If your application is easy to re-install and you have a small number of instances to move over, this may be attractive.

Option 2: Manually convert your existing VM image to a GCE-friendly format and manually import

Google has support documentation for manually importing images and then making adjustments for the imported images so that it works well within GCE.  This process may be helpful if you have bespoke VM appliances or just a small number of servers with single volumes to migrate to GCE. This process is manual, so it does introduce potential for error.

The basic steps for this process are as follows, continuing the Centos 6 example:

    1. Plan your path. You will need to store an image exported from your source environment and a way to boot the image to make changes to it and then convert the image to a GCE-friendly format.  Make sure you have enough disk space to accommodate the image, the compressed image and some extra space, so you don’t run into out-of-space errors.
    2. Make a copy of the image, boot it up in the source environment and make required changes to the OS before converting, such as:
      1. Edit the linux boot configuration file, /etc/grub.conf in our example and remove the line configuring the boot spashimage.  Also remove kernel parameters rhgb and quiet.  Add console=ttyS0,38400n8d to kernel parameters. 
      2. Ensure you can log in via the console with username and password. This may be handy if you have issues with the network interface coming up correctly once booted in GCE.
      3. Also ensure you have a ssh key to access the image, just in case.
      4. Confirm your Centos repos still work. I found I needed to update the Centos repos to vault.centos.org.
      5. Update the default network interface config. For centos-6, this was /etc/sysconfig/network-scripts/ifcfg-eth0.  Remove HW_ADDR and UUID lines and add ONBOOT=yes and MTU=1460 to the file.
      6. Remove VMware or other hypervisor tools.
      7. Copy the image to some place where you can execute the next steps.
    3. Convert the image to a format GCE accepts.  
        1. The easiest way I found to convert an image was using the qemu-img utility. Install qemu.
        2. In this example, I am taking a VMware .vmdk file and converting it to raw format, which is what GCE requires:

          qemu-img convert -f vmdk -O raw PATH/TO/VM.VMDK  PATH/TO/disk.raw

       

        1. Now that the .VMDK file is converted to .raw, it must be tar’d up in the oldgnu format:

          tar –format=oldgnu -Sczf compressed-image.tar.gz disk.raw

       

        1. Upload the compressed-image.tar.gz file to a Google Cloud Storage (GCS) bucket:

          gsutil cp compressed-image.tar.gz gs://BUCKET_NAME

       

      1. Finally, create the GCE image:

        gcloud compute images create IMAGE_NAME --source-uri \ gs://BUCKET_NAME/compressed-image.tar.gz

    4. Create a VM from the resulting image, install the Google os-agent and make any necessary changes.
      1. Create a VM from the resulting image from Step 3e.

        gcloud compute instances create VM_NAME --zone ZONE --image IMAGE_NAME

      2. Log in to the image via the ssh key suggested in step 2c.  
      3. If you cannot log in to your instance, likely a new network interface was found on boot up. Log in to your instance via the serial console with username/password and fix the network interface for what was detected.
      4. Once logged in, install the Google os-agent.

If the instructions above all seem too much, perhaps the next option is for you. I recommend that you read through the Google support documentation  for manually importing images and then making adjustments for the imported images. I have noted the basic steps above and some of the issues I encountered. There are several requirements and limitations, so please read.

Option 3: Use Migrate to Virtual Machines if you have several VMs to bring to GCE

Migrate to Virtual Machines (formerly Migrate for GCE) is a migration tool designed to lift and shift on-prem servers to GCE. The latest version of Migrate to Virtual Machines is focused on VMware migrations. If your legacy applications are already running on VMware, this may be the best option for you. Using Migrate to Virtual Machines involves a little setup work, but once it's done, you can migrate a large number of virtual machines easily, reliably and with minimal downtime.

Migrate to Virtual Machines works by installing a migration appliance in to your existing VMware environment. This migrate appliance will interface Google Cloud and your on-prem vSphere so that Migrate to Virtual Machines can view your vSphere environment, select VMs to migrate, set up data replication and then manage cloning for tests or cutovers for when you are ready to move your applications to Google Cloud.

I think this option will be the most attractive for most users. Unlike the manual import process from option 2, it automates many of the steps and, from my experience, reliably migrates images over.  If you have more than a few servers to move over, this will be the quickest way.  Migrate to Virtual Machines supports several current and legacy operating systems as well.

Migrate to Virtual Machines requires the migrate connector to be able to speak directly to Google APIs, whether this is over the internet or via any private connectivity you have between your VMware environment and Google Cloud. This support page reviews the options for you.

The basic steps to use Migrate to Virtual Machines are:

  1. Set up the prerequisites, such as enabling the associated Google Cloud APIs and deciding on which projects and IAM permissions to use.
  2. Install, configure and register the migrate connector in your existing VMware environment
  3. Start migrating VMs. The migration process can be broken down into the following steps:
    1. Onboard the VMs into Migrate to Virtual Machines.
    2. Start replication for select VMs or all VMs. Replication can be done while your source VMs are still running.
    3. Set up the target VM details, such as selecting the VM instance types, networking configuration, etc.
    4. Optionally, you can test a migration via the clone function. I recommend doing this with an isolated target environment. Your source images will still be running in VMware.
    5. Cut over. This will shut down the source VM, take a final replication and then provision the target VMs. This step involves downtime. For the images I tested with, I was seeing approximately 15 minutes of downtime between the source image being shut down until the new instance came up on Google Cloud. Most of the downtime was image processing, so the size of the image may vary this downtime.
    6. Clean up.

Option 4: Use Google Cloud VMware Engine to host large or numerous legacy applications

Using Google Cloud VMware Engine is where I see most start off because the other options are not well advertised. GCVE is a great product when used with the right use cases, but running a small number of virtual machines on a GCVE cluster can get costly.  

The minimum GCVE configuration is a 3-node cluster. Each node is a ve1-standard-72 instance, meaning there are 72 hyperthreaded cores (36 physical), 768GB of RAM and 20+ TB of SSD. Each node at On-Demand pricing comes up $9.29/hr per node, so the minimum sized cluster of 3 nodes will run at $20,345.10 per month. Discounting for 1 year and 3 year commitments can bring this pricing down substantially.

Google does offer a 1-node configuration, which brings the pricing and resources down a bit, but Google limits 1-node configurations to a 60-day period, as they’re mainly for POC use. Please do not run your production workloads on this configuration.  

GCVE is still a viable option for running end-of-lIfe legacy applications, providing your resource requirements call for it, your workloads have licensing that is less compatible with the Cloud (Windows Server, Oracle, etc) or if you already heavily leverage VMware on-prem and wish to continue using it for certain workload s to keep investments in tooling or operations.

Bonus Option 5: Use Migrate to Containers tool to containerize certain legacy applications

Using Google Cloud’s Migrate to Containers tool could be an option for certain workloads. If you’re already comfortable with running containers and aren’t looking to run more GCE virtual machines, Migrate to Containers may be a viable option for you. Migrate for Containers will analyze your workloads and, if fit for containerization, will produce a container of your VM-based workload for use on platforms such as Google Kubernetes Engine and Cloud Run. 

One caveat with this method is that not all workloads are suitable for conversion. Google has examples of workloads that are a good fit and those which are not. An analysis tool can also help determine this.  Some modifications may be needed as well. Several current and legacy operating systems are supported.

What’s best for your unloved legacy application?

Based on what I have seen with customers, I think Migrate to Virtual Machines is the best overall solution, offering a good balance of effort needed, automation, reliability and the least amount of downtime needed for stateful workloads.

If you have 1-2 images to deal with, reinstalling your app on a deprecated Google Cloud image or a manual conversion may be less effort to get a virtual machine up and running on GCE. These options aren’t great for migrating stateful workloads that can’t tolerate much downtime as well.

If you’re already running containerized apps, are willing to do some modification to your workloads if needed and don’t wish to bring virtual machines into your mix, Migrate to Containers could be an interesting option. The downside is that not all workloads are suitable for this process, and your applications could need some modifications for this to work.

Finally, if you have large-scale needs, especially with existing VMware environments that may have licensing complications on the cloud, GCVE allows you to preserve some of your existing licensing agreements that do not allow for some workloads to cost-effectively run on GCE as well as leverage existing skillsets and tools you may already have.  That said, GCVE is generally not a price-effective solution for just a few small applications.

Subscribe to updates, news and more.

Leave a Reply

Your email address will not be published.