It may happen that you are hosting servers whose operating systems are not supported by Nutanix Move. In these rare cases, you will then have to proceed manually to migrate your virtual machines and you may be faced with post-migration boot issues.

For the demonstration, I chose a really old operating system: Ubuntu 12.04.

This version is not part of the list of systems supported by Nutanix Move for migration and the migration must therefore be done manually:

I have set up a manual migration plan for this virtual machine and I am proceeding with its migration which is going smoothly:

Unfortunately, when starting the virtual machine on the Nutanix AHV side, I encounter a boot problem:

To fix this issue, I shut down the virtual machine, log into my Prism Central, and navigate to the “Compute and Storage > Images” menu:

I click on “Add Image”, select “VM Disk” as the image source and select my Ubuntu12 VM:

I name the disk with an explicit name and click on “Next”:

I leave the image placement option in its default configuration and save:

My disk image will appear in the list of images available on my Nutanix cluster:

I then go back to the “Compute and Storage > VMs” menu and open the control panel of my virtual machine:

The part that interests us concerns the machine’s 2 disks with a virtual disk and a CD-ROM type reader:

The first step is to delete all disks by clicking on the trash icon:

Then, once the 2 disks are deleted, click on “Attach Disk”:

Configure the disk as follows:

• 1 – Type : Disk
• 2 – Operation : Clone From Image
• 3 – Image : select the disk you added initially
• 4 – Capacity : you can make it any size you want
• 5 – Bus Type : select PCI

Validate the new configuration of your virtual machine and boot it. The boot problem is now fixed, and the operating system boots perfectly fine:

Welcome to Ubuntu 12.04 LTS (GNU/Linux 3.2.0-23-generic x86_64)

Documentation: https://help.ubuntu.com/ System information as of Thu Sep 26 15:58:58 CEST 2024 System load: 0.0 Processes: 67
Usage of /: 3.5% of 37.68GB Users logged in: 1
Memory usage: 2% IP address for eth0: 192.168.2.137
Swap usage: 0% Graph this data and manage this system at https://landscape.canonical.com/

0 packages can be updated.
0 updates are security updates.

Your Ubuntu release is not supported anymore.
For upgrade information, please visit:
http://www.ubuntu.com/releaseendoflife

New release '14.04.6 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

Last login: Thu Sep 26 15:58:05 2024
nutanix@ubuntu24hv:~$

The main problem encountered when migrating these obsolete systems is a boot issue. By following this method, you should be able to migrate all your virtual machines without any problems.

It may happen that you host servers whose operating systems are not supported by Nutanix Move. In these rare cases, you will then have to proceed manually to migrate your virtual machines and you may encounter post-migration network issues.

In my example, I deployed on my ESXi an Ubuntu Server machine in version 24.04LTS, an operating system released only a few months ago. It is not yet officially supported by Nutanix Move according to the documentation:

When creating my migration plan, I did not encounter any errors, I was able to validate the options without any problems, in automatic mode and I start it immediately.

Unfortunately, the automatic preparation of the virtual machine fails:

The message is clear, Nutanix Move cannot install the necessary drivers:

Drivers Installation Failed. Driver(s) virtio_scsi could not be installed for kernel 6.8.0-45-generic

So I delete my migration plan, create a new one manually and shut down the virtual machine without running the scripts:

I then start my migration plan to migrate the virtual machine to my AHV cluster and everything goes well:

Once the data transfer is complete, I launch the switch immediately. The server is migrated:

On the Nutanix AHV side, I can clearly see my freshly migrated virtual machine:

I start the virtual machine to check that the migration went well. The VM starts correctly but it does not take an IP address…

This problem is common with recent operating systems. As a general rule, they integrate the modules and components necessary for full support by Nutanix. However, it is common for the configuration of the network cards not to be correctly resumed after migration.

To correct the malfunction, you must open a console on your VM and perform the configuration manually.

We start by retrieving the name of the interface:

nutanix@ubuntu24e1:~$ sudo lshw -class network
[sudo] password for nutanix:
*-network
description: Ethernet controller
product: Virtio network device
vendor: Red Hat, Inc.
physical id: 3
bus info: pci@0000:00:03.0
version: 00
width: 64 bits
clock: 33MHz
capabilities: msix bus_master cap_list rom
configuration: driver=virtio-pci latency=0
resources: irq:11 ioport:c040(size=32) memory:febd1000-febd1fff memory:fe000000-fe003fff memory:feb80000-febbffff
*-virtio0
description: Ethernet interface
physical id: 0
bus info: virtio@0
logical name: ens3
serial: 50:6b:8d:c0:82:7b
capabilities: ethernet physical

Here it is ens3. Now we will modify the network card configuration file:

nutanix@ubuntu24e1:~$ sudo vi /etc/netplan/50-cloud-init.yaml
This file is generated from information provided by the datasource. Changes to it will not persist across an instance reboot. To disable cloud-init's network configuration capabilities, write a file /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
network: {config: disabled}
network:
ethernets:
ens160:
dhcp4: true
version: 2

Correct the “ens” line with the correct name of your network card and save the file. Apply the configuration:

sudo netplan apply

That’s it, the machine retrieves an IP address.

You get the idea, my example is based on Ubuntu but reproducible on other recent Linux distributions, as long as you adapt the commands to the operating system.

You thought it was over and that we would go straight to the migration? Well, not quite! I still have a few things to say and share with you before: my final tips and best practices based on my experience!

Careful preparation

The first and I think most important advice I can give you is to prepare your migration well. List your virtual machines, identify the installed operating systems, check that they are up to date and that the migration prerequisites are met…

It takes time, but it is the key to a successful migration every time.

Measured migration plans

My second piece of advice is to create migration plans of a reasonable size. If the software limit can go up to 100 virtual machines per migration plan, I would advise you to limit yourself to a maximum of twenty machines.

This allows you to better manage your migration, to have fewer potential errors to manage and to be able to correct problems more quickly if you encounter them once the virtual machines have been switched over and to limit the risk of prolonged service interruption.

Homogeneous migration plans

As far as possible, try to create migration plans grouping virtual machines that are similar in terms of operating system. Again, in the event of a problem during the migration, it will always be easier to look for a common error on several servers with the same operating system than between disparate servers.

Take your time

Above all, do not rush! It is better to take your time and make a smooth migration, rather than rushing, encountering problems, being forced to backtrack, etc. Take the time to build your migration plans, to prepare them well, to configure them in their smallest details so that they go smoothly.

Some good practices to follow

Here are some good practices to follow that will allow you to avoid a certain number of inconveniences. There are probably others that I have not mentioned but this already constitutes a solid base:

• Check the compatibility of your operating systems.

• Check that all the prerequisites are respected upstream.

• Check that your clusters can communicate with each other.

• Stop the backup jobs before starting your migrations.

If in doubt, refer to the official documentation: https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Move-v5_4:Nutanix-Move-v5_4

Now, you are ready to finalize the migration of your virtual machines…

After the source cluster under VMware ESXi, we must now add the target cluster which run Nutanix AHV.

The process is similar to the one used previously for WMware ESXi and Microsoft Hyper-V clusters and I will start by adding an account dedicated to Move on my cluster.

Adding a Move service account

To add the service account dedicated to Nutanix Move on your Nutanix AHV cluster, connect to Prism Element then go to “Settings > Local User Management” and click on “New User”:

Fill in the fields with the necessary information and check the “Cluster Admin” role. Your service account is ready, now let’s add the Nutanix AHV cluster on Nutanix Move.

Adding the AHV cluster on Nutanix Move

In the “Environments” section of Nutanix Move, click on “+ Add Environment”:

Next, fill in the fields with the information corresponding to the Nutanix AHV cluster to which you want to migrate the VMs from the ESXi and Hyper-V clusters:

The required information is as follows:

• 1 – Environment type, select Nutanix AHV
• 2 – Name the added cluster
• 3 – Enter the IP address of the cluster (Prism Element or Prism Central of your choice)
• 4 – Enter the logins and password of the service account previously created

Wait for a few minutes and your cluster will then be available in NutanixMove :

Your source and destination clusters are now all configured on Nutanix Move, the next step will be to create the migration plans.