VMware vSAN vers Proxmox + Ceph : pourquoi et comment migrer

Mis à jour en 2026 · 10 min de lecture

VMware vSAN

Proxmox VE

Ceph

Depuis le rachat de VMware par Broadcom, de nombreuses entreprises constatent une hausse sensible du coût de leurs licences vSphere et vSAN : fin des licences perpétuelles, passage à l'abonnement, regroupement forcé dans des offres plus larges et plus chères. Pour beaucoup, la facture de licence devient disproportionnée par rapport à l'usage réel de l'infrastructure.

Cet article explique pourquoi cette situation pousse de plus en plus d'entreprises à regarder vers Proxmox VE et Ceph comme alternative, et détaille les grandes étapes d'une migration, sans entrer dans le détail le plus technique.

Pourquoi quitter VMware vSAN ?

La fin des licences perpétuelles a transformé un investissement ponctuel en charge récurrente obligatoire : impossible désormais de continuer à utiliser une version sans renouveler un abonnement, même sans besoin de nouvelles fonctionnalités.

Les nouvelles offres regroupent souvent vSphere, vSAN et d'autres briques en un seul pack, avec une licence calculée au nombre de cœurs physiques et un minimum de cœurs par socket. Résultat : une entreprise qui n'utilisait qu'une partie de la suite se retrouve à payer pour l'ensemble.

Pour vSAN spécifiquement, le coût suit la capacité de stockage et le nombre de nœuds, avec une liste de matériel certifié (vSAN ReadyNodes) qui limite le choix des serveurs. Une contrainte de plus, qui pèse sur le coût total de possession à moyen terme.

Pourquoi Proxmox + Ceph ?

Proxmox VE est un hyperviseur open source basé sur KVM/QEMU pour la virtualisation et LXC pour les conteneurs, sans licence par cœur. Un abonnement support est disponible mais reste optionnel, avec un coût largement inférieur à celui d'une suite VMware équivalente.

Ceph remplit le même rôle que vSAN : du stockage distribué, répliqué entre les nœuds, qui tolère la panne d'un serveur ou d'un disque sans interruption de service. Il tourne sur du matériel standard, sans liste de compatibilité aussi restrictive que celle de VMware.

C'est exactement l'architecture que j'ai déployée et documentée dans l'étude de cas Cluster HCI Proxmox + Ceph : un cluster multi-nœuds en haute disponibilité, sans dépendance à un éditeur unique.

Procédure de migration, étape par étape

Une migration d'hyperviseur ne se fait pas en une seule bascule. Voici les grandes étapes d'une démarche progressive et maîtrisée.

Audit et cadrage

Inventaire des VM, des dépendances applicatives et des volumes de données. Définition des fenêtres de maintenance acceptables et des objectifs de reprise (RTO/RPO).

Conception de l'architecture cible

Dimensionnement du cluster Proxmox (nombre de nœuds), du réseau dédié au stockage Ceph et du niveau de réplication souhaité, sur la base de l'audit.

Validation sur un pilote

Migration de quelques VM non critiques en premier, pour valider la compatibilité, les performances et le bon fonctionnement de la sauvegarde sur le nouvel environnement.

Préparation du cluster cible

Installation et durcissement de Proxmox, mise en place du cluster Ceph, et tests de charge avant toute bascule de machines de production.

Migration des machines virtuelles

Bascule par vagues, du moins critique au plus critique, avec un plan de retour arrière clair et validé à chaque étape.

Bascule de la sauvegarde

Adaptation de la stratégie de sauvegarde existante (Veeam) au nouvel environnement Proxmox, avec vérification des premières sauvegardes et restaurations.

Validation et hypercare

Surveillance renforcée après chaque vague de migration, tests fonctionnels avec les équipes métier, et ajustements de performance si besoin.

Décommissionnement de VMware

Une fois la période de stabilisation validée, libération des licences et du matériel devenu inutile, après confirmation qu'aucun retour arrière n'est nécessaire.

Points de vigilance

●Les pilotes invités VMware Tools doivent être remplacés par le QEMU Guest Agent sur chaque VM migrée.
●Le format des disques virtuels change : une conversion est nécessaire lors de l'import des VM.
●Les licences des systèmes invités (Windows notamment) doivent être vérifiées : le modèle BYOL s'applique différemment hors VMware.
●Les équipes d'exploitation ont besoin d'un temps de montée en compétence sur les outils d'administration Proxmox.
●La sauvegarde et la restauration doivent être testées sur le nouvel environnement avant de couper l'ancien.

Une migration VMware vers Proxmox à l'étude ?

Audit de l'existant, chiffrage et accompagnement de la migration : on peut en discuter.

Me contacter