Changer de socle de virtualisation : une décision lourde
Migrer un hyperviseur en production, c’est changer le moteur d’un avion en plein vol. Chaque machine virtuelle de chaque client doit continuer à tourner. Chez Datacampus, nous avons fait ce choix en connaissance de cause, et nous voulons partager ce retour d’expérience avec transparence.
Pourquoi Xen au départ
Quand Datacampus a construit son infrastructure de virtualisation, Xen était un choix logique. Hyperviseur open source de référence, soutenu par Citrix via XenServer (devenu Citrix Hypervisor), il offrait :
- Une paravirtualisation performante et éprouvée
- Un modèle open source avec support commercial disponible
- Une communauté active et une documentation fournie
- Une intégration correcte avec les outils de gestion
Pendant plusieurs années, Xen a rempli son rôle sans problème majeur. Mais le paysage a évolué.
Ce qui a changé
Plusieurs facteurs convergents nous ont poussés à reconsidérer notre choix :
| Facteur | Impact |
|---|---|
| Rachat par Cloud Software Group | Orientation vers le cloud privé/hybride, désintérêt pour l’hébergement classique |
| Déclin de la communauté | Moins de contributeurs, mises à jour moins fréquentes, documentation vieillissante |
| Intégration Ceph limitée | Pas d’intégration native, nécessité de scripts maison pour le stockage distribué |
| Interface de gestion | XenCenter vieillissant, pas d’interface web moderne native |
| Montée en puissance de Proxmox | Communauté grandissante, intégration Ceph native, interface web complète |
Le signal déclencheur a été l’évolution stratégique de Citrix/Cloud Software Group, qui rendait incertain le futur de XenServer tel que nous l’utilisions. Attendre n’était plus une option.
Pourquoi Proxmox VE
Après évaluation de plusieurs alternatives (VMware écarté pour le coût et le risque de dépendance post-Broadcom, oVirt pour son avenir incertain), Proxmox VE s’est imposé :
- 100 % open source (licence AGPL), modèle économique basé sur le support
- KVM + LXC : virtualisation complète et conteneurs sur la même plateforme
- Ceph intégré nativement : déploiement, gestion et monitoring depuis l’interface
- Interface web complète : gestion de cluster, réseau, stockage, firewall
- API REST puissante pour l’automatisation
- Communauté dynamique : forums actifs, documentation à jour, écosystème riche
- Support commercial disponible via Proxmox Server Solutions
Le plan de migration
Nous avons découpé la migration en phases pour minimiser les risques :
Phase 1 : Préparation (2 mois)
- Déploiement d’un cluster Proxmox de test
- Tests de conversion de VM (formats de disque, drivers, configuration réseau)
- Validation de l’intégration Ceph avec Proxmox
- Rédaction des procédures de migration pas à pas
- Formation de l’équipe technique sur Proxmox
Phase 2 : Migration pilote (1 mois)
- Migration d’un premier lot de VM internes (monitoring, outils internes)
- Validation du processus en conditions réelles
- Ajustement des procédures selon les retours
Phase 3 : Migration clients par vagues (4 mois)
- Planification de créneaux de migration avec chaque client
- Migration progressive, service par service
- Validation post-migration systématique
- Rollback préparé en cas de problème
Phase 4 : Décommissionnement Xen (1 mois)
- Vérification finale de toutes les VM migrées
- Arrêt des hyperviseurs Xen
- Récupération et réaffectation du matériel
Les défis techniques
La migration n’a pas été sans obstacles. Voici les principaux défis rencontrés :
Conversion des formats de disque
Xen utilise des formats de disque spécifiques (VHD) tandis que Proxmox/KVM travaille avec QCOW2 ou raw. La conversion a nécessité :
- Export des disques depuis XenServer
- Conversion via
qemu-img convertvers le format raw ou qcow2 - Import dans Ceph via RBD
- Vérification d’intégrité post-conversion
Drivers et paravirtualisation
Les VM Xen utilisent des Xen PV drivers (paravirtualisés). Sous KVM, il faut passer aux VirtIO drivers. Pour les VM Linux, l’adaptation a été relativement simple — les noyaux récents incluent les deux. Pour les VM Windows, il a fallu :
- Installer les drivers VirtIO avant la migration
- Modifier la configuration de boot
- Tester minutieusement chaque VM Windows après conversion
Réseau et adressage
Le modèle réseau de Xen (bridges, VLANs, bonding) diffère de celui de Proxmox. Nous avons dû reconfigurer l’intégralité du réseau virtuel : bridges Linux, VLAN tagging, bonding avec LACP, et intégration du réseau dédié Ceph. La préparation minutieuse du schéma réseau en amont a été déterminante.
Migration du stockage vers Ceph
L’un des objectifs de la migration était de passer d’un stockage local/SAN à Ceph distribué. Cela a impliqué :
- Déploiement du cluster Ceph sur les nœuds Proxmox
- Configuration des pools RBD en réplication triple
- Import des images disque dans Ceph après conversion
- Optimisation des paramètres Ceph pour notre profil de charge
Les leçons apprises
Ce qui a bien fonctionné
- La phase pilote sur nos VM internes a révélé 80 % des problèmes
- La communication transparente avec les clients a facilité la planification
- Les procédures écrites ont permis à toute l’équipe de migrer des VM
- Le rollback préparé n’a finalement servi que deux fois
Ce qu’on ferait différemment
- Automatiser davantage la conversion des disques (scripts batch)
- Prévoir plus de temps pour les VM Windows anciennes
- Tester la charge réseau Ceph plus tôt en conditions réalistes
- Intégrer les tests de performance dans le processus de validation
Les résultats
Après la migration complète, les gains sont tangibles :
| Métrique | Avant (Xen) | Après (Proxmox + Ceph) |
|---|---|---|
| Haute disponibilité | Manuelle (scripts maison) | Intégrée (HA cluster natif) |
| Migration à chaud | Complexe, stockage partagé requis | Clic unique via Ceph RBD |
| Performances I/O | Stockage local SSD | Ceph NVMe (latence divisée par 3) |
| Interface de gestion | XenCenter (Windows uniquement) | Interface web accessible partout |
| Résilience stockage | RAID local (perte serveur = perte VM) | Ceph triple réplica (perte serveur = zéro impact) |
| Automatisation | API limitée | API REST complète + Terraform provider |
Ce que ça change pour nos clients
Concrètement, la migration Xen → Proxmox a apporté à nos clients :
- Une meilleure disponibilité : la perte d’un serveur physique n’impacte plus les VM grâce à Ceph et au HA Proxmox
- Des performances en hausse : le passage au stockage Ceph NVMe a significativement réduit les latences
- Des maintenances transparentes : les migrations à chaud permettent de mettre à jour les hyperviseurs sans coupure
- Plus de flexibilité : redimensionnement, snapshots, clones disponibles en quelques clics
Cette migration illustre une conviction forte chez Datacampus : il ne faut jamais rester prisonnier d’un éditeur. Choisir des technologies open source, c’est garder la liberté de faire évoluer son infrastructure au rythme de ses besoins, pas au rythme des stratégies commerciales d’un tiers.
L’équipe Datacampus — hébergeur et infogérant français, entreprise à mission, basé au Futuroscope.