Migration de machines virtuelles depuis VMware ESXi vers Proxmox VE

25 juillet 2021 virtualisation linux

J’ai récemment migré des machines virtuelles depuis VMware ESXi vers Proxmox VE et rencontré quelques problèmes au cours du processus. Voici mes notes au cas où ça pourrait aider.

VMware ESXi et Proxmox VE sont tous deux compatibles OVF. Le but est d’exporter une VM au format OVF depuis VMware ESXi puis d’importer l’OVF sur Proxmox VE.

Prérequis

Si VMware ESXi est accessible depuis Proxmox VE, on peut utiliser VMware OVF Tool directement depuis Proxmox VE afin d’exporter et copier l’OVF en un seul coup.

Installer VMware OVF Tool sur Proxmox VE:
- Télécharger le fichier .bundle (nécessite un compte VMware, qu’on peut créer gratuitement).
- Le chmod +x puis l’éxecuter.
Arrêter la VM sur VMware ESXi.

Exporter une VM depuis VMware ESXi

Utilisation :

# ovftool vi://<username>@<host>:<port>/

Si on utilise SSL avec un certificat auto-signé, ajouter --noSSLVerify.

OVF Tool demandera le mot de passe et listera les objets disponibles :

# ovftool --noSSLVerify vi://root@XXX.XXX.XXX.XXX:443/
Enter login information for source vi://XXX.XXX.XXX.XXX/
Username: root
Password: ***************
Error: Found wrong kind of object (ResourcePool). Possible completions are:
  vm1
  vm2
  dir1/
  dir2/

On peut récursivement lister les objets, e.g. ici avec un répertoire :

# ovftool --noSSLVerify vi://root@XXX.XXX.XXX.XXX:443/dir1/
Enter login information for source vi://XXX.XXX.XXX.XXX/
Username: root
Password: ***************
Error: Found wrong kind of object (ResourcePool). Possible completions are:
  vm3

Lors de l’accès à une VM, les détails de la VM à exporter via OVF s’affichent :

# ovftool --noSSLVerify vi://root@XXX.XXX.XXX.XXX:443/dir1/vm3
Enter login information for source vi://XXX.XXX.XXX.XXX/
Username: root
Password: ***************
OVF version:   1.0
VirtualApp:    false
Name:          vm3

Download Size:  Unknown

Deployment Sizes:
  Flat disks:   100.00 GB
  Sparse disks: Unknown

Networks:
  Name:        Foo
  Description: Bar

Virtual Machines:
  Name:               vm3
  Operating System:   debian10_64guest
  Virtual Hardware:
    Families:         vmx-13
    Number of CPUs:   4
    Cores per socket: 4
    Memory:           6.00 GB

    Disks:
      Index:          0
      Instance ID:    9
      Capacity:       50.00 GB
      Disk Types:     SCSI-VirtualSCSI

      Index:          1
      Instance ID:    10
      Capacity:       50.00 GB
      Disk Types:     SCSI-VirtualSCSI

    NICs:
      Adapter Type:   VmxNet3
      Connection:     Foo

References:
  File:  /12/ParaVirtualSCSIController0:0
  File:  /12/ParaVirtualSCSIController0:1

Une fois la VM à exporter identifiée, on peut enregistrer l’OVF dans un fichier local sur Proxmox VE :

# ovftool --noSSLVerify vi://root@XXX.XXX.XXX.XXX:443/dir2/vm4 .
Enter login information for source vi://XXX.XXX.XXX.XXX/
Username: root
Password: ***************
Opening VI source: vi://root@XXX.XXX.XXX.XXX:443/dir2/vm4
Opening VI source: vi://root@XXX.XXX.XXX.XXX:443/dir2/vm4
Opening OVF target: .
Writing OVF package: ./vm4/vm4.ovf
Disk progress: 12%
[...]
Transfer Completed
Completed successfully

Problèmes

Pour certaines VM, j’ai eu cette erreur :

# ovftool --noSSLVerify vi://root@XXX.XXX.XXX.XXX:443/dir2/vm4
Enter login information for source vi://XXX.XXX.XXX.XXX/
Username: root
Password: ***************
Error: Fault cause: vim.fault.FileNotFound

Diagnostic : le périphérique CD/ROM connecté à la VM fait référence à un fichier ISO du Datastore inaccessible pour OVF Tool.
Solution : détacher le périphérique CD/ROM de la VM.

Importer une VM sur Proxmox VE

Avec l’OVF disponible localement, on peut importer la VM via l’outil en ligne de commande qm.

Utilisation :

qm importovf <id> path/to/file.ovf <proxmox_storage>

On peut également spécifier --format <qcow2 | raw | vmdk> pour utiliser un format d’image disque spécifique lors de l’import. À noter que cela n’aura aucun effet si on importe dans un stockage ZFS car ce dernier utilise une émulation block device et n’autorise que raw.

Exemple avec l’OVF plus haut :

qm importovf 400 vm4/vm4.ovf local-zfs
transferred 0.0 B of 50.0 GiB (0.00%)
[...]
transferred 50.0 GiB of 50.0 GiB (100.00%)

La VM devrait maintenant être disponible dans l’interface web de Proxmox VE.

Contrôle post-migration

Vérifier la configuration importée. En particulier :

Examiner le matériel de la VM :
- Réfléchir à changer le type de CPU (idéalement host pour de meilleures performances).
- Réfléchir à changer le type de contrôleur SCSI (idéalement VirtIO pour de meilleures performances).
- Ajouter le(s) périphérique(s) réseau, ceux-ci n’étant pas importés et devant être recréés (idéalement VirtIO pour de meilleures performances).
Examiner les options de la VM :
- Réfléchir à démarrer la VM au démarrage.
- Ajuster le type de système d’exploitation pour qu’il corresponde au système d’exploitation réel de la VM.

Une fois satisfait, essayer de démarrer la VM. Avec la VM opérationnelle, on peut :

Mettre à jour la configuration réseau, le nom de l’interface et/ou la passerelle pouvant avoir changés.
Installer QEMU Guest Agent:
- Sur les systèmes basés sur Debian, c’est aussi simple que :
```
# apt install qemu-guest-agent
```
- Une fois installé, arrêter la VM et activer QEMU Guest Agent dans les options de la VM.
- Redémarrer la VM et vérifier que le service QEMU Guest Agent tourne correctement :
```
# systemctl status qemu-guest-agent
```

Supprimer les guest additions VMware:

Quelques pointeurs pour vérifier s’ils étaient installés :

# ls /usr/lib/vmware-tools
# systemctl status vmware
# which vmware-toolbox
# which vmware-toolbox-cmd
# dpkg -l | grep -I vm
# apt search open-vm-tools

Puis :

# vmware-uninstall-tools.pl
# apt purge open-vm-tools

Problèmes

Certaines VM ne démarraient pas après avoir passé le bootloader, ne trouvant pas les partitions du disque.

Diagnostic : modules VirtIO manquants.
Solution : basculer temporairement le type de contrôleur SCSI en VMware PVSCSI, démarrer la VM, et charger les modules VirtIO manquants dans initramfs.

Sur les systèmes basés sur Debian :

Ajouter les modules à /etc/initramfs-tools/modules :

virtio_blk
virtio_scsi

Mettre à jour initramfs et arrêter la VM :

# update-initramfs -u
# shutdown now

Basculer à nouveau sur le contrôleur SCSI VirtIO.
La VM devrait maintenant démarrer correctement.

Je soupçonne qu’un problème similaire pourrait se produire avec le périphérique réseau si le module virtio_net manque également. Pour consulter la liste des modules chargés :

# lsmod | grep virtio
virtio_net             53248  0
net_failover           20480  1 virtio_net
virtio_console         32768  1
virtio_balloon         20480  0
virtio_blk             20480  0
virtio_scsi            20480  2
scsi_mod              249856  4 virtio_scsi,sd_mod,libata,sg
virtio_pci             28672  0
virtio_ring            28672  6 virtio_console,virtio_balloon,virtio_scsi,virtio_pci,virtio_blk,virtio_net
virtio                 16384  6 virtio_console,virtio_balloon,virtio_scsi,virtio_pci,virtio_blk,virtio_net

Article précédent Article suivant