vSphere vers Proxmox : ce qui migre vraiment

Tous les guides de migration pour quitter VMware commencent par le disque, parce que le disque est la partie qui a un fichier. Convertir le VMDK, l’importer, démarrer, terminé.

Le disque est la partie facile. Ce qui fait fonctionner une machine vSphere se trouve dans quatre autres endroits, aucun à l’intérieur du VMDK : la façon dont la plateforme identifie la machine, la façon dont l’invité est configuré au premier démarrage, le matériel virtuel pour lequel l’invité possède des pilotes, et l’agent installé dans l’invité qui répond aux questions le concernant. Chacun est un problème différent sur Proxmox, et un seul d’entre eux s’annonce quand il tourne mal.

Voici ce que nous avons trouvé en construisant des chemins de lecture et d’écriture contre les deux, mesurés contre vCenter 6.7.0 build-24323669.

Le disque, et l’appel qui n’existe pas

Il y a deux formes de disque virtuel en jeu. Une VM vSphere en fonctionnement possède un VMDK plat plus un petit descripteur. Une OVA ou une image cloud téléchargée possède un VMDK stream-optimized : compressé, séquentiel et non amorçable en l’état.

Le chemin de conversion évident est CopyVirtualDisk_Task avec une spécification de destination nommant le format cible. Cet appel existe sur un hôte ESXi autonome et n’existe pas sur vCenter : il répond « The requested operation is not implemented by the server ». C’est un bon exemple d’un piège plus général dans cette API, où la même opération existe à un niveau de gestion et pas à un autre.

Deux choses fonctionnent, et mieux vaut les connaître dans cet ordre :

• CopyVirtualDisk_Task sans spécification de destination fonctionne sur vCenter 6.7 et copie un disque en conservant son type. Sur ce vCenter, il exige l’argument datacenter ; la forme qui ne donne qu’un chemin de banque de données est refusée.
• Le chemin d’import OVF (CreateImportSpec → ImportVApp → HttpNfcLease → HTTP POST → HttpNfcLeaseComplete) accepte un disque stream-optimized et le convertit au passage. Il n’a besoin que du descripteur .ovf, pas de l’OVA entière : une OVA est une archive tar avec le descripteur en tête, récupérable par une seule requête de plage de 128 ko.

Côté Proxmox, l’équivalent est qm disk import, qui prend un VMDK et l’écrit dans le stockage cible au format propre à ce stockage. Cette partie-là est réellement simple.

Le provisionnement est modélisé différemment des deux côtés. vSphere a deux indicateurs, thinProvisioned et eagerlyScrub, et ce n’est pas un choix à trois branches : le thin exclut l’eager, si bien que les états valides sont thin, thick lazy zeroed et thick eager zeroed. Tout ce qui modélise cela comme une énumération unique à quatre valeurs finira par envoyer une combinaison impossible.

L’identité : l’ID que vous détenez n’en est pas une

Celui-ci mord des mois plus tard, pas le jour de la migration.

Un objet vSphere est adressé par une référence d’objet géré, quelque chose comme vm-101. Cela ressemble à un identifiant et n’en est pas un : c’est une clé dans la base de données de ce vCenter précis. Reconstruisez ou restaurez cette base et la référence ne suit pas la machine, et elle est redistribuée à une autre VM. Ce que vous aviez stocké il y a six mois désigne désormais la machine de quelqu’un d’autre, et l’opération que vous vous apprêtiez à exécuter est une mise hors tension.

L’identifiant durable est config.instanceUuid. Stockez celui-là, et résolvez la référence à chaque opération via FindByUuid.

Proxmox a la forme inverse. Une VM est un vmid : stable, lisible par un humain, visible dans chaque commande, unique par cluster. C’est plus agréable à manipuler, et cela a sa propre conséquence pour une migration. Vous choisissez de nouvelles identités, donc chaque système externe qui désignait une machine par son identifiant vSphere doit être repointé.

Le modèle d’emplacement diffère aussi. Avec DRS activé, l’hôte sur lequel tourne une VM change sans que personne ne le demande, si bien qu’un clone reçoit un pool de ressources et que vSphere choisit. Sur Proxmox, le nœud est l’unité et le déplacement entre nœuds est explicite. Un inventaire qui notait « quel hôte » pour un cluster DRS notait une chose qui change toute seule.

La personnalisation de l’invité est un autre mécanisme

Les deux plateformes savent configurer un invité au premier démarrage. Elles le font de façons qui ne partagent aucune ligne de code.

Sur vSphere, la voie qui fonctionne sans dépendre de l’invité est guestinfo : quatre clés dans extraConfig, lues par la source de données VMware de cloud-init.

Les clés .encoding ne sont pas facultatives. Omettez-les et cloud-init lit le texte base64 comme s’il était le contenu lui-même, et la machine démarre avec un nom d’hôte de quarante caractères d’absurdités. Aucune erreur, juste une mauvaise réponse.

L’alternative, le CustomizeVM_Task propre à VMware, exige VMware Tools dans l’invité et, sur les vieux modèles Linux, un perl fonctionnel, ce qui est le genre d’exigence que l’on découvre quand un provisionnement reste bloqué à mi-course.

Sur Proxmox, la personnalisation passe par un lecteur cloud-init attaché à la VM, configuré avec un petit ensemble de clés : ipconfig0 à ipconfig3, nameserver, searchdomain, ciuser, cipassword, sshkeys, citype, ciupgrade.

L’une d’elles cache un piège qui reste invisible jusqu’à la plainte d’un client. ciupgrade vaut default = 1 dans le schéma Proxmox, donc l’omettre ne signifie pas « ne pas mettre à jour les paquets au premier démarrage » ; cela signifie « mettre à jour ». Une case décochée doit être envoyée comme un ciupgrade=0 explicite, sinon la case ment. Cette clé n’existe pas non plus avant PVE 8.1, où l’envoyer est une erreur bloquante et non une clé ignorée.

Deux autres choses tournent mal de la même manière des deux côtés. L’identifiant d’instance doit changer quand une machine reçoit une nouvelle identité : le iid-local01 de la plupart des exemples signifie qu’une machine clonée conserve la configuration du modèle. Et l’interface ne portera pas le nom attendu : ens160 sur VMware, autre chose sur KVM. C’est Netplan avec match: {name: "e*"} plutôt qu’un nom de périphérique deviné qui fait qu’une même image fonctionne des deux côtés.

Du matériel virtuel pour lequel l’invité a des pilotes

vmxnet3 est la carte réseau par défaut raisonnable sur VMware, et elle a une condition préalable : elle exige VMware Tools dans l’invité. Installez un modèle sans Tools, donnez-lui une carte vmxnet3, et le système d’exploitation ne voit aucune carte réseau du tout.

Cela compte deux fois. Avant, parce qu’un modèle qui démarre très bien sur ESXi peut avoir besoin d’e1000e à la place. Et après, parce que le choix haute performance de Proxmox est virtio, qui exige ses propres pilotes : présents dans un Linux moderne, absolument pas dans une image Windows d’origine. e1000 est l’option lente, ennuyeuse et universelle sur les deux plateformes, et c’est le bon premier démarrage pour une machine que vous déplacez.

Le contrôleur de disque pose le même genre de problème : sur Proxmox, la voie rapide est virtio-scsi, ce qui est encore une question de pilotes. Nous n’avons pas mesuré ce que change un changement de type de contrôleur sur un invité déjà installé, et c’est une cause fréquente de machine qui migre proprement puis refuse de démarrer.

L’agent dans l’invité change de nom

Une part surprenante de ce qu’affiche un panneau ne vient pas du tout de l’hyperviseur.

Sur vSphere, guest.ipAddress vient de VMware Tools. L’occupation disque réelle aussi, via guest.disk : le summary.storage.committed au niveau de la banque de données est le chiffre du provisionnement et se lit de travers pour un disque thin. Si Tools ne tourne pas, ces champs sont vides, et vide veut dire « je ne sais pas », jamais « la machine n’a pas d’adresse ».

Après le déplacement, la même information vient de qemu-guest-agent, un autre paquet portant un autre nom, qu’il faut installer. Une flotte qui migre sans lui ressemble, dans votre propre inventaire, à une flotte qui a perdu ses adresses.

Une mise en garde de plus sur cette adresse : elle arrive par le canal propre de l’hyperviseur vers l’invité, pas par le réseau. Elle peut être parfaitement exacte pour une machine dont la carte n’est reliée à rien. La seule chose qui prouve la joignabilité, c’est de la joindre.

Le réseau, et la connexion qui n’en est pas une

vSphere a deux types de raccordement réseau et ils ne se ressemblent pas. Un Network standard est désigné par son nom ; un DistributedVirtualPortgroup par l’UUID de son commutateur plus sa propre clé de groupe de ports.

Ne construisez que la première forme et, dans tout environnement doté d’un commutateur distribué, vous obtenez une carte reliée à rien. vCenter ne refuse pas, car le nom existe bel et bien en tant qu’objet réseau. La machine démarre sans connectivité et l’erreur se trouve à l’intérieur de l’invité.

Proxmox est plus simple : une carte nomme un pont, avec une étiquette VLAN facultative. La correspondance est à vous d’écrire ; il n’existe aucune traduction automatique d’un groupe de ports vers un pont. Deux autres choses à décider avant le premier déplacement :

• Les adresses MAC. Les transporter garde valides les réservations DHCP et les liaisons de licence, et signifie que deux machines partagent une MAC si la source est un jour rallumée. Choisissez explicitement.
• Le pare-feu par VM. vSphere n’en a pas ; c’est NSX, un produit distinct. Proxmox en a un. Les machines venues de VMware n’ont jamais eu de pare-feu au niveau de l’hyperviseur, et en activer un est un projet plutôt qu’une case à cocher.

Ce qui ne voyage pas, et n’est dans aucun fichier

Certaines choses n’ont aucun équivalent, et un plan qui ne les nomme pas les découvre une par une :

• Les instantanés. La machine traverse sous forme de disque plat ; un arbre d’instantanés est une structure vSphere qui n’a rien pour l’accueillir.
• Le suivi des blocs modifiés, et avec lui tout historique de sauvegarde incrémentale qui en dépendait.
• Les étiquettes, les attributs personnalisés et les dossiers. Ils vivent dans la base de données de vCenter, pas sur la machine.
• Les pools de ressources, les règles DRS, les réservations et les parts. Proxmox n’a pas d’ordonnanceur équivalent, donc une politique de placement écrite en règles DRS devient une série de décisions sur le nœud où une machine se pose.
• La version du matériel virtuel. Un concept vSphere sans équivalent Proxmox, donc tout ce qui s’y accroche dans votre automatisation est désormais du code mort.

Ce que notre propre outillage fait, et ne fait pas

Soyons clairs : nous n’avons pas construit de migration vSphere vers Proxmox. Notre outillage de migration couvre aujourd’hui exactement une route, entre deux panneaux de jeu, et il se trouve derrière un drapeau de fonctionnalité désactivé.

Deux règles tirées de la construction de cette unique route valent tout de même d’être reprises, car elles rendent une migration vérifiable plutôt qu’optimiste. La source est en lecture seule, sous forme de constante et non de drapeau, si bien qu’il n’existe aucune configuration dans laquelle l’outil écrit sur le système que vous quittez. Et une exécution à blanc est obligatoire avant une application, avec ensuite un décompte par catégorie, source contre destination. Une migration incapable de vous dire combien de machines elle a déplacées n’a pas terminé ; elle s’est arrêtée.

Ce texte est né de la construction des intégrations vSphere et Proxmox pour Provibr, un panneau de gestion de serveurs destiné aux hébergeurs, où les deux hyperviseurs doivent être lisibles à travers une seule interface sans que l’un soit décrit comme l’autre. Les notes d’installation se trouvent dans les documentations vSphere et Proxmox.