Step-by-Step Guide to Migrating from VMware to Red Hat OpenShift - Keyva

Red Hat’s OpenShift platform is a Kubernetes solution that has been gaining popularity in recent years, thanks in part to the rising popularity of containerization, be it for micro-services, cloud-native appliances, or simply for ease of CI/CD integrations and portability. Beyond such benefits, many companies and now looking into containerization as a possible alternative following recent licensing changes to VMware’s suite of products following its Broadcom acquisition.

Moving from one abstraction platform to another is a harrowing prospect, particularly with the maturity of virtualization as a technology. I remain something of a holdout against going all in on containerization, but nevertheless, more and more of my services are being moved to containerization over time. While I still use virtualization for application development (VMware Workstation on my Linux-based daily driver machine and Parallels on my Mac laptop), reasons to not use containerization are dwindling as the containerization space matures. OpenShift, in particular, offers a management interface that should feel right at home to vCenter administration veterans, and interaction with the containers it runs have been very smooth from my experience as well.

And so, I would like to take some time to offer a high-level overview of how to try OpenShift using environments that you may be familiar with already.

OpenShift is at its core a Kubernetes platform to assist in the deployment and management of containers. Some of the features include CI/CD pipelines, easier to understand security assignments, and the aforementioned management interface in the form of a web-based console. Of course, if you are already familiar with management via command line tools, the oc command with open shift will feel quite similar to the k8s or k3s commands you may already be used to.

Operating systems that are officially certified for containerization with OpenShift and continually changing. At present, RHEL, SUSE, Ubuntu and Windows systems are supported, but I suggest looking into this listing in case this post becomes out of date. At the time of writing, this list can be found here.

For the sake of brevity, I will assume an environment in which OpenShift is already installed and proceed to the steps required to migrate your existing VMware virtual machines. If you’ve already decided to use OpenShift beyond a testing capacity don’t forget to also configure storage, networking and Identity Access Management.

Before attempting to import existing machine, you will need to open the OpenShift console and install the “Migration Toolkit for Virtualization Operator” found through the administration role under [Operators -> OperatorHub]. Once installed, an additional menu will appear as [Migration].

Once this is done, proceed to [Migration -> Providers for Virtualization]. There will already be something here for the host cluster you are running, but you will need to add your vCenter appliance to this configuration. Start by clicked “Create Provider” on the upper right. Multiple options will appear here, but the one needed for this sort of migration is vSphere. Fill out the following screen, paying attention to the note for the URL field. For instance, if your vCenter appliance is hosted at “https://vcenter.mycorporation.local”, you will want to provide “https://vcenter.mycorporation.local/sdk” as the response.

Next is the VDDK image. This is not required but can significantly increase speed of transfers if used. The VDDK, or Virtual Disk Development Kit, can be downloaded from the Broadcom developer site.

Beyond this, a vSphere REST API username (with an FQDN, e.g. “os-migration-user@vcenter.mycorporation.local”) and password needs to be provided.

Lastly, the SHA-1 fingerprint for your vCenter application can be added here. This is a suggested step but may be skipped with the “skip certificate validation” option. You should get the SHA-1 fingerprint from the certificate with the command openssl x509 -in <cert file location> -noout -fingerprint -sha1 You can also find the fingerprint in the certificate information of your web browser when visiting your vCenter appliance, though this is less recommended than using your cert file as a source of truth.

Once complete, OpenShift will immediately start populating the inventory from vCenter.

When this is finished (it will likely be instant), proceed to [Migration -> Plans for virtualization]. Click “Create plan” and give the new plan a name of your choosing. Select your newly created provider as your source provider, and the already included provider (named “host” by default) as the target provider. Select a namespace (“imported-vms” is suggested).

Proceed to the VM selection step. Select your cluster and your VMs for transfer here.

The next step involves selecting a network mapping. If you have not set this up already and if you are already using the VMware data network, you can simply select the pod network as the target namespace.

For storage on the next step, select the default storage class.

After this, you can select the type of migration you wish to use. A cold migration is the most straightforward and involves shutting down your VMs fully to transfer them. However, a “warm” migration option also exists if downtime is not possible. This will transfer your currently running machines and post incremental updates (similar to snapshot deltas) until it’s time to cut over.

Once done, click Finish, and you will be returned to the [Plans for virtualization] menu with your newly assembled plan. Click the “Start” button for your plan to begin the transfer. The following page will give you the status of your initiated transfer, including allocation, the copy itself, and the conversion step from VMDK to KubeVirt. Depending on the size of your VMs and your network speed, this may take several minutes to complete.

Your migrated systems now can be found under [Virtualization -> Virtual Machines]. Once started, you can proceed into details for any of your VMs by clicking there name. From here, you can see the status of your machine, including a VNC console to interact with it.

Migrating from VMware infrastructure to containerized virtualization can feel daunting on its surface. Thankfully, the landscape for containerized infrastructure has significantly matured to make this a process that can reasonably be set up to run in less than a half hour; minutes even, if you’re experienced with the process. Hopefully this high-level guide can provide useful on your own discovery into the applications of containerized infrastructure.