Migration of servers on VMware to OpenStack

25 January, 2024

Daniel Bodky
Daniel Bodky
Senior Platform Advocate

Daniel kam nach Abschluss seines Studiums im Oktober 2021 zu NETWAYS und beriet zwei Jahre lang Kunden zu den Themen Icinga2 und Kubernetes, bevor es ihn weiter zu Managed Services zog. Seitdem redet und schreibt er viel über cloud-native Technologien und ihre spannenden Anwendungsfälle und gibt sein Bestes, um Neues und Interessantes rund um Kubernetes zu vermitteln. Nebenher schreibt er in seiner Freizeit kleinere Tools für verschiedenste Einsatzgebiete, nimmt öfters mal ein Buch in die Hand oder widmet sich seinem viel zu großen Berg Lego. In der wärmeren Jahreszeit findet man ihn außerdem oft auf dem Fahrrad oder beim Wandern.

by | Jan 25, 2024

In this tutorial we look at migrating servers on VMware to OpenStack. Following the recent acquisition of VMware by Broadcom, many smaller Cloud Service Providers (CSPs) have received notices to terminate their membership in VMWare’s partner program in recent weeks. Many end customers are therefore in an uncertain situation, which is made even more acute by the lack of information.
The first providers of compatible software are already considering the possibility of supporting alternative platforms. One of these possible alternatives could be OpenStack, the world’s most widely used open source cloud software. The virtual private clouds (VPCs) at NWS are also based on OpenStack.

If you would rather learn more about OpenStack with the NWS CLoud and why it can be a sensible alternative to VMware’s proprietary products, you are in the right place on our information page!

Try OpenStack in the NETWAYS Cloud!
Fast, transparent and can be canceled monthly.

Prerequisites

To apply the migration steps described in this tutorial, we need a Linux server that will serve as a “migration server” as well as auxiliary software. All software is open source, freely available and can be installed from the official package sources of all common operating systems.

The migration server

The Linux server is mainly needed to convert the VM image exported by VMware as .vmdk into an OpenStack-compatible raw image. As we then have to upload the converted image to OpenStack, it is advisable to set up our migration server as close as possible to our OpenStack from a network perspective.

As far as the operating system is concerned, there is no wrong choice – the required software is available in the official package sources of all common operating systems. I have chosen Ubuntu 22.04.3 LTS (Jammy Jellyfish) for this tutorial.

The auxiliary software

We install the following software on our migration server once it has been set up:

  • the openstack CLI
  • the qemu-img CLI

Under Ubuntu, these dependencies can be installed using the following software packages:

apt install qemu-utils python3-openstackclient

After successful installation, we can test the installed tools:

openstack --version
  openstack 5.8.0
 
qemu-img --version
  qemu-img version 6.2.0 (Debian 1:6.2+dfsg-2ubuntu6.16)
  © (c) 2003-2021 Fabrice Bellard and the QEMU Project developers

Preparing the image

ostende vCenter:

  1. Navigate to the host in the vCenter UI
  2. Identify the datastore that holds the host’s data
  3. Navigate to the identified datastore and open the Datastore Browser
  4. Find the folder named after the host
  5. Download the .vmdk file via the corresponding dialog

In fact, two files should now be downloaded, a small file called tutorial-host.vmdk, and a large file called tutorial-host-flat.vmdk.

After a successful download, both files must be transferred to our migration server before we can start the conversion: We want to convert our .vmdk files into a single raw image, which works with the following command:

qemu-img convert -p -f vmdk -O raw tutorial-host.vmdk tutorial-host.raw

The conversion should now take place while the CLI keeps us up to date with a progress bar. After a few minutes – depending on the size of the .vmdk files – a new file tutorial-host.raw should be visible in the working directory.

Preparing the OpenStack environment

Before we can continue the migration of our server from VMware to OpenStack, there are still some preparations to be made, some of which are mandatory(uploading the converted image) and some of which are optional (setting IP and/or MAC addresses).

Let’s start by uploading the image.

Upload the image to OpenStack

As we (want to) communicate directly with OpenStack from here on, we must first configure our openstack CLI. Specifically, we need to define authentication and project. The required information can be downloaded from Horizon (OpenStack’s web interface) – detailed instructions can be found in the official documentation.

If you follow the tutorial on an OpenStack operated by NWS, you can download the required information from your OpenStack overview page on my.nws.netways.de. This way you can authenticate yourself with your NWS ID in the OpenStack CLI.

Once we have downloaded our OpenStackRC file, we can read it in and then upload the converted image to Glance (OpenStack’s image storage):

source <OpenstackRC.sh>;
openstack image create --disk-format raw \
   --file tutorial-host.raw --progress tutorial-host-image

Like qemu-img, openstack also shows us the progress of the action. Once the image has been successfully uploaded, we can start our virtual machine on OpenStack!

Configuring network settings

penStack. Using this port, we can attach specific IP or MAC addresses to our virtual machine in order to migrate the original network settings as well as the secured state of the machine.

To configure such a port, we need some information from OpenStack:

  1. the ID of the network in which the port is to be created; we can list all available networks as follows:
    openstack network list
  2. the ID of a subnet within the selected network; again we can list all options:
    openstack subnet list
  3. [optional] the ID(s) of the security groups that we want to link to the port and therefore also to our VM:
    openstack security group list

Once we have all the required information together, we can create the port – the selected IDs or IP/MAC addresses must be entered in the appropriate places:

openstack port create --fixed-ip "subnet=<subnet-id>,ip-address=<ip-address>" \
    --security-group <securitygroup-id> \
    --network <network-id> \
    --mac-address <mac-address> \
    tutorial-host-port

If we want to link several security groups to our VM, we can simply repeat the parameter --security-group and enter the corresponding IDs. Similarly, we can also omit the parameter if we do not want to create any links for the time being.

If we want to create our VM in OpenStack later in the tutorial and use the port we have just configured, we can reference it with the following parameter: --port tutorial-host-port

Starting the virtual machine

We have now fulfilled all the necessary and optional requirements to be able to start our virtual machine in OpenStack – but again, there are various options in terms of reliability and data persistence.

For this reason, we will look at two different ways to start our VM in OpenStack at the end of the tutorial.

Starting the virtual machine from an image

The easiest way to complete the migration of our server on VMware to OpenStack is to boot directly from our uploaded image. Our VM is just one command away:

openstack server create --image tutorial-host-image --flavor s1.small \
    --wait tutorial-host

After a few moments, the openstack CLI should give us the information of the newly created VM. We can check the status of the machine in Horizon:

To do this, we navigate via Compute > Instances to the overview of all servers in the respective project and should now see a VM called tutorial-host in the Power State Running.

That was easy! However, this simplicity also has its disadvantages: Since we boot our VM directly from the imported image, all of the VM’s data is only stored on its hypervisor.

So if we have data persistence across restarts of the VM, things look bad in the event of a hypervisor failure: We cannot move the VM’s data to another hypervisor. Even after deleting the VM itself, the stored data is lost.

If your use case is not affected by these limitations, that’s great – but if you need a more robust solution, read on to find out how we can start our VMs from persistent volumes.

Starting the virtual machine from a volume

Instead of starting our virtual machine directly from an image as in the last section and thus being completely dependent on the hypervisor, we can boot from a volume instead. This has a few advantages:

  • if a hypervisor fails, we can move the VM to another hypervisor – the persistent data can also be accessed from there
  • after deleting a VM, we can keep the volume for later use

The corresponding command on the openstack CLI is as follows:

openstack server create --image tutorial-host-image --flavor s1.small \
    --boot-from-volume 8 --wait tutorial-host

Note the new parameter --boot-from-volume 8 compared to the example above. We use it to tell OpenStack that it should create a new volume (8GB) based on our referenced image, which serves as the root disk of our VM.

With this measure, we boot from a dedicated volume that properly persists the data on the VM.

Similar to the example above, we can check the status of our VM under Compute > Instances in Horizon – everything should be fine.

What happens next?

Even though we have now dealt with various basic migration scenarios including network and storage settings from servers on VMware to OpenStack, there are of course a few other things to consider:

What about Windows VMs, for example? What about additionally mounted disks? And what about additional scripts, SSH keys and other files that may end up on the VMs?

We want to address questions like these in future tutorials, so check back or subscribe to our newsletter to stay up to date. If you have any questions about OpenStack, our NWS portfolio or the tutorial itself, feel free to send us a message.

Our portfolio

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

How did you like our article?