Actuellement en pleine refonte de différents cluster Proxmox, j’ai eu l’occasion d’utiliser Proxmox Datacenter Manager (PDM) pour migrer des VM d’un cluster vers un autre.
Proxmox Datacenter Manager (PDM) est un outil qui permet de gérer plusieurs clusters Proxmox depuis un seul endroit. On peut le comparer (à quelques fonctionnalités près) à VMware vCenter. En plus d’avoir les informations de vos clusters dans une interface unique, PDM permet d’effectuer des migrations de VM entre les clusters PVE de manière simplifiée.
Contexte de la migration#
Voici l’environnement de travail :
- Un cluster source (
CV1) avec deux sous-réseaux différents et les VMs actuellement placées ; - Un cluster destination (
CV2) pour décorréler les sous-réseaux et avoir un cluster par SI ; - Toutes les VMs sont basées sur Debian.
- Les VMs ont des sauvegardes (snapshots) effectuées par Proxmox Backup Server.
Il était temps de séparer les SI, et de migrer les VMs d’un cluster à l’autre. Il y a encore plusieurs mois, une des solutions pour migrer des VMs entre clusters était de les exporter/importer via des commandes scp ou rsync, ce qui nécessitait de les arrêter.
Avec PDM, il est possible de faire des migrations en live, ce qui est beaucoup plus pratique. Cependant, il y a quelques petites subtilités à connaître.
J’omets volontairement de détailler les étapes de configuration de PDM, car celles-ci sont bien documentées sur le site de Proxmox. Aussi, selon votre configuration réseau, certaines étapes peuvent varier, notamment l’ouverture de ports et la configuration des pare-feux de vos environnements.
Les spécificités des VM#
Les machines virtuelles à migrer sont pour la plupart similaires, notamment avec ce type de configuration :
- Processeur virtuel de type ‘x86-64-v3’ ;
- Un ou plusieurs disques virtuels sur un stockage de type Ceph ;
- Plusieurs cartes réseau (virtio) par machine virtuelle ;
- Certaines VMs sont créées via OpenTofu ;
- Certaines VMs utilisent cloud-init pour la configuration initiale.
En soi, les machines virtuelles ne sont pas si complexes qu’elles n’y paraissent. Cependant, il est important de bien comprendre leur configuration avant de lancer une migration. J’ai des machines virtuelles dont le stockage est un disque physique attaché directement à la machine virtuelle, ou encore des GPU passés en direct I/O. Ces machines ne peuvent pas être migrées en l’état, elles feront l’objet d’une migration manuelle.
La préparation et mise en place de la migration#
PDM se connecte aux clusters PVE via l’API de Proxmox. Vous devrez créer un utilisateur, un api-token sur chaque cluster et attribuer le rôle PVEAdmin sur l’utilisateur et l’api-token pour que PDM puisse se connecter. Une fois les connexions établies, vous pourrez commencer les migrations.
Le cluster CV2 doit être prêt à réceptionner les machines virtuelles et leur flux de travail. Cette préparation inclut la configuration des réseaux, des stockages, et des politiques de sécurité. Dans mon cas, j’ai dû configurer en plus un stockage pour réceptionner les fichiers .yml utilisés par cloud-init. Ce stockage est, pour mon contexte, un stockage de type cephfs (pour l’exemple, le stockage s’appellera sto-cephfs-snippets) dans le cluster CV2. Depuis un noeud du cluster CV1, j’ai transféré les fichiers .yml de cloud-init vers le stockage sto-cephfs-snippets de CV2. La commande était la suivante :
rsync -av --progress /mnt/pve/sto-cephfs-snippets/snippets/* root@cv2-node1:/mnt/pve/sto-cephfs-snippets/snippets/Lancement d’une migration et tests de bon fonctionnement#
Le cluster CV2 est prêt à réceptionner les machines virtuelles, il est temps de lancer une migration d’une machine virtuelle peu critique. Grâce à l’assistant graphique proposé par PDM, vous allez être guidé par les différentes cases. Un mode “simple” effectue la migration sans personnalisation, tandis qu’un mode “avancé” vous permet de choisir les options de migration.
Il est fortement recommandé d’utiliser le mode “avancé” pour ajuster les paramètres (choix des vmbr, des stockages, du noeud de destination).
Une fois la VM sélectionnée, la migration s’est lancée et s’est déroulée sans encombre. La VM a été migrée en live, ce qui a permis de minimiser l’interruption de service.
Pour vérifier le bon fonctionnement de la VM, j’ai dû me connecter à celle-ci via la console web de Proxmox depuis le nouveau cluster CV2 - RàS. La VM avait un disque virtuel d’une taille de 96 Go, dont environ 22 Go utiles ; la migration s’est effectuée en une dizaine de minutes, ce que j’ai trouvé assez lent. Cette lenteur soulève une question : est-ce que la migration se fait sur le réseau de gestion ou sur le réseau de données ? Hélas, sur le réseau de gestion.
Les limitations lors de cette migration#
Durant la migration, j’ai rencontré plusieurs limitations :
- Des machines étaient créées avec OpenTofu, le state de déploiement n’est plus à jour après la migration ;
- La migration des fichiers
.ymlde cloud-init n’a pas été automatique et aucune option ne le permet ; - L’interface web de PDM ne permet pas de choisir par quelle carte réseau la migration doit se faire (c’est mon plus gros souci) ;
- Les VMs ayant des disques physiques, des GPU, des USB attachés ou des répertoires locaux montés, ne peuvent pas être migrées via PDM.
Il y a toutefois de bons points à retenir :
- Vous pouvez lancer plusieurs migrations en même temps vers différents noeuds ;
- L’assistant proposé par PDM est simple et pratique.
- Une fois la VM migrée sans activer l’option “supprimer la source”, sur l’ancien cluster la VM sera identifiée dans l’état “migrate”, empêchant toute action dessus.
Le résultat#
Je suis satisfait d’une manière générale, mais ce n’était pas la solution idéale pour mon environnement. L’interface de PDM est simple, facile à utiliser, fonctionnelle et a permis de migrer de simples machines virtuelles avec succès.
Cependant, le résultat est mitigé, compte tenu de mon contexte d’utilisation (cloud-init et OpenTofu). Proxmox Datacenter Manager est un produit encore jeune et qui nécessite encore du temps pour atteindre sa maturité. Aujourd’hui, il fonctionne très bien pour centraliser la gestion de vos clusters Proxmox, mais il manque de fonctionnalités pour être pleinement utilisé dans un environnement de production (notamment comme dans mon cas d’usage).
Les machines migrées via PDM sont fonctionnelles, les services sont opérationnels. Il n’y a eu aucune casse ni interruption de service. Je pense que la migration de VM via PDM est une solution intéressante pour migrer des VMs simples, mais pas encore idéale pour des environnements où l’automatisation est légion.
Finalement, j’ai migré plus d’une dizaine de VMs différentes via PDM, ce qui m’a permis de valider la solution et de constater ses limites. Pour les autres machines, je les ai recréées via OpenTofu.

