VMware a longtemps été un pionnier et une référence de la virtualisation, que cela soit dans le secteur des workstations avec VMware Workstation ou des environnements serveurs avec VMware ESXi Server. Depuis le rachat par Broadcom, les nouvelles politiques mises en place, telles que l’arrêt des licences perpétuelles et l’augmentation des coûts via des abonnements basés sur le nombre de cœurs CPU, les organisations réévaluent leurs infrastructures et les solutions qui les composent. Dans cette recherche de solutions alternatives, OpenStack apparaît comme un choix stratégique et très compétitif pour les entreprises de toute taille.

Par rapport à VMware ESXi Server, OpenStack offre de nombreux avantages :

  • Plus grande flexibilité logicielle et matérielle
  • Réduction importante des coûts (notamment au niveau des licences logicielles)
  • Pas de vendor lock-in (solution open-source avec des standards techniques ouverts)
  • Interopérabilité garantie

Entrons à présent dans le vif du sujet, à savoir comment migrer une ou (plusieurs) machines virtuelles utilisant la technologie VMware ESXI Server vers des infrastructures Openstack.

1. Prérequis technique

  • Une instance sur l’infrastructure Openstack de destination avec un système d’exploitation Rocky Linux ou équivalent que l’on appellera tout au long de cet article « Appliance de migration ». Lors des migrations, cette instance va être utilisée comme « passe-plat » et elle a besoin d’avoir accès directement au(x) volume(s) de destination des machines virtuelles que nous allons migrer. Personnellement, je vais utiliser le Public Cloud d’Infomaniak qui est extrêmement compétitif par rapport à AWS, GCP ou Azure.
  • Un accès SSH (port 22 uniquement) aux serveur ESXi depuis l’appliance de migration (soit par login et mot de passe, soit par clef SSH).
  • Toutes les actions réalisées dans cet article sont à réaliser avec l’utilisateur root

💡 Encore deux précisions importantes avant de passer à la pratique :

  • Cette procédure est uniquement valable pour VMware ESXi et non pas vSphere. En allant explorer la documentation des solutions utilisées dans cet article, vous pourrez sans mal l’adapter en cas de besoin.
  • Sauvegardez vos machines virtuelles avant le processus de migration, je m’en voudrais d’être responsable de vos prochaines nuits blanches si quelque chose venait à mal se passer !

C’est tout ! Passons maintenant à la configuration de notre appliance de migration 🚀

2. Installation de l’appliance de migration

Pour que notre appliance de migration soit fonctionnelle, nous devons installer quelques paquets une fois connectés en SSH à celle-ci :

dnf install centos-release-openstack-caracal
dnf install python-openstackclient virt-v2v

3. Authentification et connexion

Il nous reste deux choses à faire avant de pouvoir lancer notre première migration, afin que notre appliance de migration puisse se connecter à notre serveur ESXi et à notre plateforme Openstack :

  • Pour l’authentification au server ESXi, deux solutions sont possibles : soit par paire de clés, soit avec le nom d’utilisateur et mot de passe.
  • Pour l’authentification avec la plateforme Openstack, il faudra récupérer le fichier de profil openrc et l’envoyer dans notre appliance de migration.

3.1 Authentification avec le serveur ESXi

Je pars du principe que les règles de firewall entre votre instance Openstack et votre serveur ESXi sont paramétrées et fonctionnelles, ainsi que l’activation du service SSH sur le serveur ESXi.

Pour celles et ceux qui ne souhaitent pas mettre en place une authentification par paire de clés, je vous invite à passer directement à la section suivante sur l’authentification avec la plateforme Openstack.

Nous allons à présent mettre en place notre authentification par paire de clés. Rien de compliqué, nous allons aller sur notre appliance de migration et nous allons exécuter les commandes suivantes :

  • On commence par générer notre paire de clés (la paire de clé utilise RSA afin de maximiser la compatibilité avec les anciennes versions d’ESXi):ssh-keygen -t rsa -b 4096
  • Une fois que votre paire de clés est générée, nous allons la déployer sur notre serveur ESXi :ssh-copy-id root@IP_SERVEUR_ESXICette commande va vous demander de saisir le mot de passe root de votre serveur de virtualisation, et va ainsi copier votre clé publique dans celui-ci. Cela vous permettra dorénavant de ne plus avoir besoin de saisir de mot de passe pour vous connecter à votre serveur.

Je vous laisse vérifier que tout a bien fonctionné en essayant de vous connecter à votre serveur ESXi directement depuis l’appliance de migration.

Pour ceux qui veulent utiliser l’authentification par nom d’utilisateur et mot de passe, il faudra simplement créer un fichier texte contenant le mot de passe de votre server ESXi dans votre appliance de migration :

touch passwordfile
echo ‘MOT_DE_PASSE_ESXI’ > passwordfile

Je vous laisse bien sûr vérifier que les informations de connexion sont bonnes en testant celles-ci en établissant une connexion vers votre serveur ESXi.

3.2 Authentification avec la plateforme Openstack

Il nous reste à authentifier notre appliance auprès de la plateforme Openstack. Pour cela, il faut envoyer dans votre instance le fichier de profil openrc que nous allons récupérer depuis le tableau de bord Horizon avant de l’exécuter.

Pour valider que vous êtes bien authentifié auprès de la plateforme Openstack, vous pouvez lancer la commande suivante :

Openstack token issue
Vous devriez avoir un retour comme ci-dessus. Si c’est le cas, c’est que tout est bon, félicitations 🙌

4. Lancement des migrations des machines virtuelles

Pour réaliser les migrations de nos machine virtuelles, nous allons utiliser l’utilitaire virt-v2v développé par RedHat qui est spécifiquement prévu pour ce genre de cas et qui intègre déjà toutes les fonctions et options nécessaires. Sans entrer dans le détail, virt-v2v va créer un nouveau volume dans le projet Openstack où se trouve votre appliance de migration pour y copier intégralement votre machine virtuelle ESXi. Une fois les données copiées, virt-v2v va préparer le volume pour que celui-ci puisse être démarré dans un Openstack.

Un dernier point important avant de commencer (promis, c’est le dernier 🙈) : les machines virtuelles à migrer doivent être éteintes. Pensez aussi à vérifier vos quotas de volume sur la plateforme Openstack afin de ne pas être bloqué lors de la migration.

Voilà, maintenant nous pouvons y aller 😎

Voici la commande qui va nous permettre de migrer nos machines virtuelles. Veillez à bien l’adapter selon vos informations !

Avec authentification par paire de clés

virt-v2v -i vmx -it ssh ssh://root@IP_SERVEUR_ESXI/vmfs/volumes/NOM_DATASTORE/NOM_DE_VM/NOM_DE_VM.vmx -o openstack -oo server-id=ID_INSTANCE_OPENSTACK

Avec authentification par nom d’utilisateur et mot de passe

virt-v2v -i vmx -it ssh -ip FICHIER_MOT_DE_PASSE ssh://root@IP_SERVEUR_ESXI/vmfs/volumes/NOM_DATASTORE/NOM_DE_VM/NOM_DE_VM.vmx -o openstack -oo server-id=ID_INSTANCE_OPENSTACK

💡 Un peu d’explications sur ces options

  • Dans les commandes précédentes, virt-v2v est configuré pour utiliser directement le fichier VMX de la machine virtuelle (-i vmx). Pour accéder à ce fichier, on utilise le protocole SSH (-it SSH).
  • Les options suivantes permettent d’indiquer où se trouve le fichier VMX :
    • IP_SERVEUR EXSI : l’adresse IP du serveur ESXI
    • NOM_DATASTORE : le nom du datastore ou est stocké la machine virtuelle
    • NOM_DE_VM : le nom du dossier qui contient les fichiers de la machine virtuelle
    • NOM_DE_VM.vmx : le nom du fichier VMX
  • L’option -ip FICHIER_MOT_DE_PASSE permet d’indiquer le fichier qui contient le mot de passe de votre serveur ESXi si vous avez opté pour l’authentification par nom d’utilisateur et mot de passe.
  • L’option -o openstack est une information de destination qui indique que l’on envoie notre machine virtuelle vers une platefome Openstack. -oo server-id=ID_INSTANCE_OPENSTACK permet d’indiquer l’utilisation de notre appliance de migration.

Pour récupérer l’ID de votre appliance de migration, vous pouvez entrer la commande suivante directement dans celle-ci :

dmidecode -s system-serial-number

Voilà, notre migration est en cours et il n’y a plus qu’à patienter ⏱️ L’outil va se charger d’aller récupérer directement les informations concernant la machine virtuelle dans le serveur ESXi. Il réalisera automatiquement les actions nécessaires pour que la machine virtuelle fonctionne correctement avec Openstack.

5. Démarrage des machines virtuelles migrées

Une fois notre migration terminée, il ne reste plus qu’à relancer notre instance via la fonction boot from volume d’Openstack. Cette fonction permet d’utiliser directement un volume bootable pour une instance plutôt que de passer par l’utilisation d’une image qui est injectée dans un nouveau volume.

Pour commencer, nous allons récupérer l’ID du volume qui a été créé pour notre migration. On commence donc par lister les volumes de notre projet Openstack :

openstack volume list

Dans la liste des volumes retournés, vous devriez en voir un portant le nom de votre machine virtuelle suivi de –sda (ou sdb, sdc… si votre VM possède plusieurs disques). C’est ce volume qui contient ce qui nous intéresse.

Copiez son identifiant (colonne ID dans le retour de la commande précédente) et entrez ensuite la commande suivante :

openstack server create --flavor a2-ram4-disk0 –volume <VOLUME_ID> --network ext-net1 <NOM_INSTANCE>

Voilà, votre instance est en train de démarrer 😊 Vous pouvez vérifier que tout fonctionne correctement via la console VNC en entant l’URL retournée par la commande suivante dans votre navigateur :

openstack console url show

Vous pouvez aussi vous connecter à celle-ci avec le protocole habituel (SSH, RDP…) en faisant attention à bien avoir ouvert les ports nécessaires dans votre groupe de sécurité.

6. Spécificité avec le Public Cloud d’Infomaniak

Il y a une petite spécificité avec Infomaniak Public Cloud pour que le volume que nous venons de créer fonctionne. Lors de la création de notre volume, virt-v2v ajoute automatiquement des méta-datas à notre volume. Ces dernières permettent de préciser comment configurer la machine virtuelle qui va utiliser notre volume dans l’hyperviseur, mais certaines ne sont pas supportées sur toutes les régions de la plateforme (région dc3-a).

Pour corriger ceci, il suffit de supprimer la propriété qui n’est pas compatible actuellement avec la plateforme. La propriété en question est hw_machine_type=q35. Nous allons donc retirer la propriété de notre volume avec la commande suivante :

openstack volume unset --image-property hw_machine_type <ID_VOLUME>

Une fois cette opération réalisée, vous pouvez lancer votre instance comme décrit précédemment avec la fonction boot from volume de la plateforme.

En savoir plus

Kevin Allioli est Architecte Cloud & Système chez Infomaniak et Expert OpenStack et AWS. Avec son expérience de plus de 10 ans dans le cloud computing, il contribue au développement du Public Cloud d’Infomaniak.