Migrer des machines virtuelles VMware vers OpenStack : virt-v2v et export OVF

1. Qualifier la VM avant de la convertir

La plupart des conversions ratées se décident avant la première commande. Pour chaque VM, notez le système invité et sa version, le type de firmware (BIOS ou UEFI), le nombre et la taille des disques, la chaîne de snapshots, les interfaces réseau avec leurs MAC et IP fixes, et toute licence liée à des identifiants matériels. Cet inventaire alimente la matrice d'éligibilité : migration directe, remédiation préalable, reconstruction sur la cible ou décommissionnement.

# Inventory with govc (read-only against vCenter)
export GOVC_URL='https://<VCENTER_HOST>' GOVC_USERNAME='<VCENTER_USER>' GOVC_INSECURE=1
govc vm.info -json <VM_NAME> | jq '.virtualMachines[0] | {guest: .config.guestFullName, firmware: .config.firmware, cpu: .config.hardware.numCPU, memMB: .config.hardware.memoryMB}'
govc device.info -vm <VM_NAME> disk-* ethernet-*
govc snapshot.tree -vm <VM_NAME>          # must be empty (or consolidated) before export

2. Voie A : conversion directe avec virt-v2v

virt-v2v s'exécute sur un serveur de conversion Linux, lui-même une instance OpenStack, avec accès réseau à vCenter et aux API OpenStack. La sortie -o openstack crée un volume Cinder par disque (nommés VM_NAME-sda, VM_NAME-sdb, etc.), en les attachant temporairement au serveur de conversion identifié par -oo server-id.

2.1 Prérequis sur le nœud de conversion

# Install virt-v2v and guestfs tools on the Linux conversion node (Debian/Ubuntu)
apt-get install virt-v2v libguestfs-tools -y

# Windows guests: virt-v2v needs the virtio-win drivers (ISO from the Fedora virtio-win project)
export VIRTIO_WIN=/opt/virtio-win.iso

# OpenStack credentials for the -o openstack output (tenant API endpoints are enough)
source /etc/kolla/admin-openrc.sh    # or the tenant project's openrc

2.2 Convertir directement depuis ESXi vers des volumes Cinder

# Power off the source VM first, then run virt-v2v against vCenter.
# Must run as root (Cinder volumes appear as /dev devices); sudo -E keeps the OS_* variables.
export LIBGUESTFS_BACKEND=direct
sudo -E virt-v2v -ic 'vpx://<VCENTER_USER>@<VCENTER_HOST>/<DATACENTER>/<ESXI_HOST>' \
  -ip /root/vcenter-password <VM_NAME> \
  -o openstack -oo server-id=<CONVERSION_SERVER_ID> \
  -os <VOLUME_TYPE> -oo guest-id=<VM_NAME>

# -os sets the Cinder volume type; -oo guest-id tags every created volume (virt_v2v_guest_id).
# Keep TLS certificate verification enabled; reserve ?no_verify=1 for controlled diagnostics only.
# -of and -oa are not supported with -o openstack: volumes are always written raw into Cinder.

2.3 Démarrer l'instance depuis le volume système converti

# UEFI guests: pin the firmware and machine types on the boot volume before first boot
openstack volume set --image-property hw_firmware_type=uefi --image-property hw_machine_type=q35 "<VM_NAME>-sda"

# Boot from the system volume, attach data volumes afterwards
openstack server create --volume "<VM_NAME>-sda" \
  --flavor <FLAVOR_NAME> \
  --network <TENANT_NET_ID> \
  "<VM_NAME>_migrated"
openstack server add volume "<VM_NAME>_migrated" "<VM_NAME>-sdb"

3. Voie B : export OVF, conversion et import Glance

La procédure standard, entièrement maîtrisable : exporter les disques ESXi, les convertir hors ligne, puis les réinjecter dans Glance et Cinder. Idéale pour les environnements isolés et les migrations de masse scriptées, au prix d'un stockage intermédiaire et d'une fenêtre plus longue par VM.

3.1 Exporter la VM depuis ESXi / vCenter

# Export the powered-off VM as an OVA package (password is prompted interactively)
ovftool vi://<VCENTER_USER>@<VCENTER_HOST>/<DATACENTER>/vm/<VM_NAME> /tmp/<VM_NAME>.ova

# Extract the VMDK file(s) from the OVA archive
mkdir -p /tmp/export && tar -xvf /tmp/<VM_NAME>.ova -C /tmp/export/

3.2 Convertir le VMDK en RAW

# RAW is optimal for Ceph RBD (native thin provisioning, no format translation on boot)
qemu-img convert -f vmdk -O raw -p /tmp/export/<VM_NAME>-disk1.vmdk /tmp/<VM_NAME>.raw
qemu-img info /tmp/<VM_NAME>.raw

# Optional: adapt the guest offline; local output is named <VM_NAME>-sda, -sdb, and so on
mkdir -p /tmp/converted
virt-v2v -i disk /tmp/<VM_NAME>.raw -o local -os /tmp/converted/ -of raw

3.3 Importer dans Glance et démarrer depuis un volume Cinder

# Upload the raw image to Glance with VirtIO properties (private to the project)
openstack image create "<VM_NAME>_migrated" \
  --file /tmp/converted/<VM_NAME>-sda \
  --disk-format raw --container-format bare \
  --property hw_disk_bus=virtio --property hw_vif_model=virtio
#   add --property hw_firmware_type=uefi --property hw_machine_type=q35 for UEFI guests
#   add --property os_type=windows for Windows guests (RTC and timer handling)

# Create a volume from the image and boot the Nova instance
openstack volume create --image "<VM_NAME>_migrated" --size <SIZE_GB> "<VM_NAME>_vol"
openstack server create --volume "<VM_NAME>_vol" --flavor <FLAVOR> --network <NET_ID> "<VM_NAME>"

4. Quelle voie pour quel parc

5. Les pièges neutralisés avant qu'ils ne surviennent

• ■Pilotes VirtIO Windows : sans pilotes de stockage VirtIO injectés avant le premier démarrage, les invités Windows plantent au boot. Injectez-les et vérifiez-les pendant la conversion, pas après.
• ■Conservation des IP et MAC : licences applicatives, règles de pare-feu et configurations en dur dépendent des adresses. Créez le port Neutron avec IP et MAC fixes (openstack port create --fixed-ip ip-address=… --mac-address …) quand la continuité l'exige.
• ■Désinstallation de VMware Tools : des VMware Tools résiduels dégradent l'invité migré. virt-v2v les retire ; sur la voie export, désinstallez-les avant l'export et installez qemu-guest-agent sur la cible.
• ■UEFI ou BIOS : un invité UEFI démarré en mode BIOS échoue systématiquement. Inventoriez le type de firmware par VM et fixez hw_firmware_type sur l'image Glance ou le volume de boot.
• ■Volumes de plusieurs téraoctets : les gros disques allongent considérablement les fenêtres d'export. Convertissez en flux direct vers Ceph RBD (qemu-img convert … rbd:pool/volume-…) et dimensionnez les fenêtres de bascule sur des débits mesurés, pas estimés.
• ■Snapshots et chaînes CBT : des chaînes de snapshots non consolidées corrompent ou alourdissent les exports. Consolidez les snapshots et suspendez les intégrations de sauvegarde avant toute sortie de disque de vSphere.

6. Recette et retour arrière

La VM source reste éteinte mais intacte sur vSphere jusqu'à la signature de la recette. Le retour arrière est un runbook documenté et testé : rallumer la source, rebrancher les flux, journaliser l'écart et le réinjecter dans la matrice d'éligibilité. Ce n'est qu'ensuite que la VM vSphere est supprimée et son stockage récupéré.

# Post-migration checks on the OpenStack side
openstack server show "<VM_NAME>" -c status -c addresses -c "OS-EXT-SRV-ATTR:hypervisor_hostname"
openstack console log show "<VM_NAME>" | tail -n 50      # kernel/boot messages, driver detection
openstack console url show "<VM_NAME>"                    # interactive check through the VNC/SPICE console

# Rollback (vSphere side): the source VM was never deleted
govc vm.power -on <VM_NAME>