Migration VMware vers Proxmox VE — Stretched Cluster D1/D2/D3

OPS

GUIDE TECHNIQUE · MIGRATION INFRASTRUCTURE · JUIN 2026

◆◆◆

MIGRATION VMWARE
VERS PROXMOX VE
Stretched Cluster D1 · D2 · Témoin D3
Étude générique · Stack complète

◆

De l'analyse du lock-in VMware/Broadcom
au plan de migration opérationnel en 5 phases

◆◆◆

6Couches lock-in VMware

3Datacenters D1/D2/D3

5Phases de migration

7Couches stack migrées

◆

SOMMAIRE — 10 PAGES

◆ Page 2 · Anatomie du lock-in VMware/Broadcom

◆ Page 3 · Architecture VMware de référence (état actuel)

◆ Page 4 · Architecture Proxmox cible

◆ Page 5 · Risques spécifiques stretched cluster

◆ Page 6 · Plan de migration en 5 phases

◆ Page 7 · Stack open-source de référence

◆ Page 8 · Gestion du changement & skills

◆ Page 9 · Grille de décision & ROI approximatif

◆ Page 10 · Outils & ressources

◆◆◆

Ce document est une étude technique générique. Les configurations mentionnées sont illustratives.
Il ne constitue pas un conseil d'ingénierie individualisé. Document public · CC BY-NC-SA 4.0

◆

Amine RAITI · Architecte Infrastructure & SRE
Document public · CC BY-NC-SA 4.0 · AI Powered by Amine

OPS

PAGE 2 · ANATOMIE DU LOCK-IN VMWARE/BROADCOM

LOCK-IN VMWARE — 6 COUCHES · CONTEXTE BROADCOM

◆

◆ CONTEXTE BROADCOM POST-NOVEMBRE 2023RUPTURE TARIFAIRE DOCUMENTÉE

Le rachat de VMware par Broadcom en novembre 2023 a restructuré immédiatement la tarification : suppression des licences perpétuelles · passage forcé aux abonnements annuels · augmentations documentées de ×3 à ×12 selon les configurations · suppression des éditions Standard et Essentials au profit de bundles imposés. C'est la couche 2 (tarifaire) du vendor lock-in appliquée à l'infrastructure on-premise — même mécanique que les egress fees hyperscalers cloud. La différence : l'augmentation est immédiate et sans alternative contractuelle.

Couche

Mécanisme VMware/Broadcom

Intensité

Nature de la sortie

1 · Contractuel

Licences perpétuelles supprimées · abonnements non résiliables · support conditionné à l'abonnement actif · Product Terms modifiables unilatéralement

●●●●

Juridique · négociation ou migration

2 · Tarifaire

Augmentation ×3 à ×12 post-Broadcom · bundles imposés · coût de double-run pendant la migration · pas d'alternative sans migration complète

●●●●

Financière · ROI <24 mois dans la plupart des cas

3 · Technique

Format VMDK (convertible) · APIs vSphere propriétaires · NSX-T overlay réseau · vSAN stockage · Tanzu K8s · SPBM policies

●●●

Technique modérée · outils de conversion disponibles

4 · Compétences

Certifications VCP/VCAP/VCDX omniprésentes · biais d'attachement équipes ops · résistance passive management intermédiaire

●●●

Formation · plan de requalification

5 · Demande

vCenter comme référentiel cognitif des équipes infra · "on veut vSphere" exprimé par les métiers avant toute évaluation alternative

●●

Change management · reformulation fonctionnelle

6 · Cognitif

KPIs infra définis dans vCenter/vRealize · tableaux de bord Aria comme étalon de mesure · impossible de comparer les performances hors de cet étalon

●●●

Irréversible sans migration · reconstruire les KPIs

⚠ SPÉCIFICITÉ STRETCHED CLUSTER — 3 DIMENSIONS DE COMPLEXITÉ SUPPLÉMENTAIRES

La configuration D1/D2/D3 ajoute trois contraintes critiques absentes des migrations standard : (1) synchronisation vSAN inter-sites avec tolérance à la perte d'un site complet — le witness D3 ne stocke pas de données mais arbitre le quorum ; (2) NSX T0/T1 Gateway en mode actif/standby inter-datacenter avec gestion des flux Nord-Sud entre sites ; (3) risque de split-brain si la liaison D1↔D2 est coupée — sans arbitrage D3, les deux sites peuvent diverger. Ces trois dimensions imposent une séquence de migration stricte : réseau avant stockage avant compute.

OPS

PAGE 3 · ARCHITECTURE VMWARE DE RÉFÉRENCE — ÉTAT ACTUEL

ARCHITECTURE VMWARE STRETCHED CLUSTER — D1 · D2 · D3

◆

D1 (Site Principal) D2 (Site Secondaire) D3 (Témoin / Witness) ├── Hôtes ESXi (N) ├── Hôtes ESXi (N) └── VMware Witness Appliance ├── vSAN datastore (preferred) ├── vSAN datastore (secondary) (vote seul — zéro donnée) ├── NSX Edge T0/T1 (actif) ├── NSX Edge T0/T1 (standby) ├── vCenter Server (actif) └── vCenter Server (passif HA) └── DRS + HA activés └────────── vSAN Stretched Cluster ──────────┘ Réplication synchrone D1 ↔ D2 · FTT=1 PFTT=1 Latence max recommandée : 5ms RTT D1↔D2 · 200ms D1/D2↔D3

◆ COUCHE STOCKAGE — vSAN STRETCHED

vSAN Stretched Cluster avec Fault Tolerance Method FTT=1 et Primary Failure To Tolerate PFTT=1 : tolère la perte complète d'un site (D1 ou D2) sans perte de données. Le Witness Appliance sur D3 porte les composants de métadonnées (witness components) pour arbitrer le quorum sans stocker de données VM. Politique de stockage SPBM : les objets vSAN sont distribués entre D1 et D2 selon la règle de placement site-aware. En cas de perte de D1, toutes les VMs basculent sur D2 via vSphere HA — le Witness D3 maintient le quorum.

◆ COUCHE RÉSEAU — NSX-T

NSX-T Tier-0 Gateway en mode actif/standby inter-sites : le T0 actif sur D1 traite le routage Nord-Sud · le T0 standby sur D2 prend le relais en cas de perte de D1. Tier-1 Gateways par tenant/segment. Overlay GENEVE sur le transport réseau physique. Distributed Firewall (DFW) appliqué sur chaque vNIC de VM — le firewall suit la VM indépendamment de sa localisation physique. VTEP (Virtual Tunnel Endpoint) sur chaque hôte ESXi.

◆ COUCHE ORCHESTRATION — vCENTER

vCenter Server en mode HA ou Enhanced Linked Mode. DRS (Distributed Resource Scheduler) : équilibrage de charge inter-hôtes avec règles d'affinité site-aware pour éviter le placement suboptimal inter-sites. vSphere HA : redémarrage automatique des VMs sur le site survivant en cas de perte d'un site. Gestion des Fault Domains : D1 = Preferred · D2 = Secondary.

◆ COUCHE K8s — TANZU

VMware Tanzu Kubernetes Grid (TKG) ou vSphere with Tanzu : clusters K8s supervisés par vCenter · stockage via vSAN CSI driver · réseau via NSX-T NCP (NSX Container Plugin). Les workloads Tanzu sont co-localisés avec les VMs sur le même fabric vSAN/NSX — la migration Tanzu → K3s/K8s vanilla nécessite Velero pour le backup/restore des workloads.

◆ COUCHE PROTECTION

Veeam Backup & Replication ou VMware SRM (Site Recovery Manager) pour les plans de reprise d'activité. RPO/RTO définis par tier de criticité : Tier 1 (RPO <15min · RTO <1h) · Tier 2 (RPO <1h · RTO <4h) · Tier 3 (RPO <24h · RTO <24h).

OPS

PAGE 4 · ARCHITECTURE PROXMOX VE CIBLE — D1 · D2 · D3

ARCHITECTURE PROXMOX STRETCHED — CEPH · OVN · COROSYNC

◆

D1 (Site Principal) D2 (Site Secondaire) D3 (Arbitre / Tiebreaker) ├── Hôtes Proxmox VE (N) ├── Hôtes Proxmox VE (N) └── Corosync QDevice (corosync-qnetd) ├── Ceph OSD (rack: dc1) ├── Ceph OSD (rack: dc2) MON tiebreaker Ceph ├── Ceph MON / MGR ├── Ceph MON / MGR (vote seul — zéro OSD) ├── OVN Chassis (actif) ├── OVN Chassis (actif) └── Proxmox cluster node └── Proxmox cluster node └──────── Ceph Stretched Cluster ───────────┘ Réplication synchrone D1 ↔ D2 · stretch_mode Latence max acceptable : 10ms RTT D1↔D2 · 30ms D1/D2↔D3

◆ COUCHE STOCKAGE — CEPH STRETCHED

Ceph en mode stretched cluster avec CRUSH map personnalisée : bucket type datacenter contenant les racks D1 et D2. Règle CRUSH : stretch_mode true · mon stretch_cluster · min_size=2 · size=4 (2 copies D1 + 2 copies D2). Le MON tiebreaker sur D3 arbitre le quorum Ceph sans OSD. RBD (RADOS Block Device) comme backend de stockage VM — interface directe avec Proxmox VE via le pool Ceph.

◆ COUCHE RÉSEAU — OVN + OVS

OVN (Open Virtual Network) avec Open vSwitch : remplacement fonctionnel complet de NSX-T. Routeur logique distribué OVN : équivalent T0/T1. Overlay GENEVE (même protocole que NSX-T — même encapsulation). ACLs OVN : équivalent Distributed Firewall NSX. BGP EVPN avec FRRouting pour le routage inter-datacenter et la symétrie des flux D1↔D2. VTEP OVS sur chaque hôte Proxmox.

◆ COUCHE ORCHESTRATION — PROXMOX CLUSTER

Cluster Proxmox VE via Corosync + QDevice (corosync-qnetd) sur D3. HA Groups par datacenter : restricted=1 pour les VMs tier 1 (restent sur leur site préféré) · restricted=0 pour les VMs tier 2/3 (migration auto vers site survivant). Fence devices par site : IPMI/iDRAC pour l'isolation physique en cas de split. Migration à chaud entre D1 et D2 via KVM live migration (équivalent vMotion).

◆ COUCHE K8s — K3s / K8s VANILLA

K3s ou Kubernetes vanilla sur VMs Proxmox · Longhorn ou Ceph RBD CSI driver pour le stockage persistant · Calico ou Cilium pour le réseau pod · Velero pour le backup/restore des workloads (migration depuis Tanzu). K3s recommandé pour les petits clusters (<20 nœuds) · K8s vanilla pour les environnements plus complexes.

◆ COUCHE PROTECTION

Proxmox Backup Server (PBS) : backup incrémentiel des VMs avec déduplication · rétention configurable · chiffrement client-side. En complément ou remplacement : Veeam Community Edition (gratuit jusqu'à 10 workloads) ou Veeam avec licence existante si le contrat le permet pendant la transition.

Fonction vSAN

Équivalent Ceph

Fonction NSX-T

Équivalent OVN

Fault domain (site)

CRUSH bucket datacenter

T0/T1 Gateway

OVN Logical Router

Witness Appliance

MON tiebreaker D3

Distributed Firewall

OVN ACLs

PFTT=1 (site fault)

stretch_mode min_size=2

GENEVE overlay

GENEVE (même protocole)

SPBM policies

Ceph pools + RBD

NSX-T NCP (Tanzu)

Calico/Cilium CNI

vSAN Encryption

Ceph at-rest encryption

VTEP (per ESXi host)

VTEP OVS (per PVE host)

OPS

PAGE 5 · RISQUES SPÉCIFIQUES STRETCHED CLUSTER D1/D2/D3

RISQUES CRITIQUES — SPLIT-BRAIN · LATENCE · SÉQUENÇAGE

◆

◆ RISQUE 1 — SPLIT-BRAIN : LE RISQUE PRINCIPAL DU STRETCHED CLUSTERCRITIQUE

Si la liaison réseau D1↔D2 est interrompue, les deux sites peuvent continuer à fonctionner indépendamment avec des données divergentes. Sans arbitrage externe (D3), les deux sites se considèrent comme le site "vivant" et continuent d'accepter des écritures — produisant une divergence de données irrécupérable.

vSAN STRETCHED
Le Witness D3 arbitre via le quorum vSAN. Le site sans quorum passe en read-only. Récupération automatique à la reconnexion D1↔D2.

CEPH STRETCHED
Le MON tiebreaker D3 arbitre le quorum Ceph. Le site sans quorum cesse d'accepter les écritures (PG dégradées). Récupération automatique à la reconnexion.

COROSYNC/HA
QDevice D3 arbitre le quorum Proxmox. Fence STONITH par site. Politique HA : fence du site minoritaire avant relocalisation des VMs.

Prérequis critique : la liaison D1/D2↔D3 doit être indépendante de la liaison D1↔D2. Si D3 est sur le même chemin réseau que D1↔D2, le tiebreaker ne peut pas arbitrer une panne de cette liaison.

◆ RISQUE 2 — LATENCE INTER-SITES : CONTRAINTES COMPARÉESÉLEVÉ

Technologie

Latence max recommandée

Latence max acceptable

Impact si dépassée

vSAN Stretched D1↔D2

5ms RTT

10ms RTT

Performances dégradées · timeouts SCSI

Ceph Stretched D1↔D2

10ms RTT

20ms RTT

OSD heartbeat warnings · performance I/O

Corosync/QDevice D↔D3

10ms RTT

30ms RTT

Quorum instable · faux positifs HA

vMotion / Live migration

150ms RTT

250ms RTT

Durée migration augmente

vSAN D1/D2 ↔ D3 Witness

200ms RTT

500ms RTT

Quorum vSAN instable

Point clé : Ceph stretched tolère une latence D1↔D2 de 10ms contre 5ms pour vSAN — ce qui rend la migration vers Proxmox/Ceph compatible avec des configurations inter-sites existantes qui étaient en limite de tolérance vSAN.

◆ RISQUE 3 — SÉQUENÇAGE DE MIGRATION : ORDRE IMPÉRATIFÉLEVÉ

La migration d'un stretched cluster ne peut pas se faire couche par couche de façon indépendante. L'ordre est impératif pour éviter de dégrader la tolérance aux pannes pendant la transition :

1. Infrastructure D3 (QDevice + MON tiebreaker Ceph) → prerequis de tout le reste
2. Réseau (OVN/OVS en parallèle de NSX-T) → double-stack pendant la transition
3. Stockage (Ceph stretched en parallèle de vSAN) → migration des données VM tier par tier
4. Compute (Proxmox VE en parallèle d'ESXi) → migration des VMs après stockage validé
5. K8s (K3s/K8s après compute) → Velero backup/restore depuis Tanzu
6. Protection (PBS remplacement Veeam/SRM) → en dernier, après validation complète

Ne jamais décommissionner vSAN avant que Ceph stretched soit validé en production. La période de double-run stockage est la phase la plus coûteuse mais la moins risquée.

OPS

PAGE 6 · PLAN DE MIGRATION EN 5 PHASES — SÉQUENCE OPÉRATIONNELLE

5 PHASES · SÉQUENCE STRICTE · DOUBLE-RUN CONTRÔLÉ

Les durées sont des estimations indicatives pour une configuration 20 hôtes / 200 VMs / 3 sites. Votre contexte peut varier significativement.

◆

PHASE 0 · AUDIT & PRÉPARATION (estimation : 4–6 semaines)

DSI/CTO : inventaire complet VMs · classification Tier 1/2/3 · calcul coût double-run · audit contrats Broadcom · identification fenêtres de maintenance · décision go/no-go par couche

SRE/Architecte : mesure latence D1↔D2↔D3 · sizing Ceph (OSD/MON/MGR) · sizing Proxmox VE · plan d'adressage OVN · définition CRUSH rules · validation bande passante inter-sites

PHASE 1 · INFRASTRUCTURE PARALLÈLE (estimation : 2–4 semaines)

Installation Proxmox VE sur nouveaux hôtes (ou cohabitation si dimensionnement suffisant) · Cluster Corosync D1+D2+QDevice D3 · Ceph MON tiebreaker D3 · Ceph OSD initiaux D1 et D2 · OVN/OVS configuration de base · PBS installé et configuré. Aucune VM migrée. Phase de validation infrastructure uniquement : test split-brain simulé · test basculement Corosync · test quorum Ceph · validation latences.

PHASE 2 · MIGRATION TIER 3 (DEV/TEST) (estimation : 3–4 semaines)

Conversion VMDK → qcow2 avec virt-v2v ou Proxmox import · migration à froid des VMs non critiques · validation performances Ceph stretched en charge réelle · validation live migration entre D1 et D2 · validation failover Ceph en cas de simulation perte d'un site · formation équipes sur interface Proxmox. Réseau : premier segment OVN en production parallèle à NSX-T.

PHASE 3 · MIGRATION TIER 2 (PRODUCTION NON CRITIQUE) (estimation : 4–8 semaines)

Migration par vagues de 10–20 VMs · validation HA Proxmox sur perte simulée d'un site · migration des flux NSX-T vers OVN segment par segment · validation ACLs OVN équivalentes au DFW NSX · K8s Tier 2 : migration Tanzu → K3s avec Velero. Réseau : bascule progressive NSX-T → OVN avec double-stack maintenu.

PHASE 4 · MIGRATION TIER 1 (PRODUCTION CRITIQUE) (estimation : 4–8 semaines)

Migration planifiée avec fenêtre de maintenance courte (<30 min par batch) · bascule finale NSX-T → OVN pour flux critiques · désactivation progressive vSAN après validation Ceph en production · test disaster recovery complet D1 → D2 · validation RPO/RTO par tier · test retour arrière documenté. K8s Tier 1 : migration en dernier après validation complète Tier 2.

PHASE 5 · DÉMANTÈLEMENT VMWARE (estimation : 2–4 semaines)

Résiliation abonnements Broadcom · archivage licences · suppression hôtes ESXi · démantèlement NSX-T managers · suppression vCenter · archivage configurations · documentation finale architecture Proxmox · bilan ROI effectif vs estimé · audit de gouvernance logicielle post-migration.

◆ RÈGLE D'OR DU STRETCHED CLUSTER — NE JAMAIS DÉCOMMISSIONNER AVANT VALIDATION

vSAN ne doit pas être décommissionné avant que Ceph stretched ait tourné en production sur tous les Tier migrés pendant au moins 4 semaines sans incident. NSX-T ne doit pas être décommissionné avant que OVN ait géré l'ensemble des flux en production pendant 2 semaines. Le coût du double-run est le prix de la sécurité.

OPS

PAGE 7 · STACK OPEN-SOURCE DE RÉFÉRENCE — 7 COUCHES MIGRÉES

TABLEAU DE MIGRATION COMPLET — VMware → OPEN-SOURCE

Portabilité : T=Totale (standard ouvert) · P=Partielle (adaptation requise) · Effort : F=Faible · M=Moyen · É=Élevé

◆

Couche · Composant VMware

Équivalent open-source

Méthode de migration

Effort

Portabilité

Hyperviseur
VMware ESXi + vSphere

Proxmox VE (KVM/QEMU)
proxmox.com · Licence AGPLv3

virt-v2v · import OVA · Proxmox import plugin · migration à froid ou à chaud

M

T · KVM standard

Stockage distribué
vSAN Stretched

Ceph RBD Stretched
ceph.io · Licence LGPL

Export VMDK → qcow2 · import RBD pool · CRUSH rules stretched · MON tiebreaker D3

É

T · standard RADOS

Réseau overlay
NSX-T · GENEVE · DFW

OVN + Open vSwitch
ovn.org · ovs.org · Apache 2.0

Reconfiguration segment par segment · ACLs OVN · BGP EVPN FRRouting · même protocole GENEVE

É

T · standards ouverts

Orchestration cluster
vCenter Server · DRS · HA

Proxmox Cluster Mgr + Corosync
QDevice D3 tiebreaker

Reparamétrage HA groups · fence devices · migration policies · QDevice corosync-qnetd

M

T · Corosync standard

Kubernetes
VMware Tanzu (TKG)

K3s / K8s vanilla
k3s.io · kubernetes.io

Velero backup/restore · Ceph RBD CSI driver · Calico ou Cilium CNI · recréation clusters

M

T · CNCF standard

Backup / PRA
Veeam · VMware SRM

Proxmox Backup Server (PBS)
+ Velero pour K8s

Installation PBS · configuration jobs · rétention · chiffrement · test restore complet

M

T · format ouvert

Monitoring / Observabilité
vRealize / Aria Operations

OTel + Prometheus + Grafana
+ Loki logs

Installation stack OTel · dashboards Proxmox · dashboards Ceph · alertes équivalentes

F

T · CNCF standard

IaC
vSphere Terraform provider

OpenTofu + Proxmox provider
opentofu.org · telmate/proxmox

Réécriture des manifests Terraform → OpenTofu · provider proxmox · même logique HCL

M

T · HCL compatible

◆ CE QU'ON GAGNE AU-DELÀ DU COÛT

Compétences portables sur des standards ouverts (KVM · Ceph · OVN · K8s) · certifications Linux Foundation et CKAD/CKA valorisées sur le marché · communauté active (Proxmox Forum · Ceph upstream · OVN GitHub) · support entreprise disponible (Proxmox GmbH ~1 400€/an/nœud · Red Hat Ceph Storage · IBM) · zéro dépendance à une licence propriétaire pour continuer à faire tourner l'infrastructure · Data Act art. 25 compatible : migration possible à tout moment sans obstacle contractuel.

OPS

PAGE 8 · GESTION DU CHANGEMENT — SKILLS LOCK-IN VMWARE

3 PROFILS DE RÉSISTANCE · PLAN DE FORMATION · CERTIFICATIONS

◆

3 PROFILS DE RÉSISTANCE SPÉCIFIQUES VMWARE — NATURE · LEVIER · CE QU'ON NE DIT PAS

① L'INGÉNIEUR VCP/VCAP — Certifié VMware depuis 3–8 ans

Résistance : "Mes certifications VMware ne valent plus rien si on migre vers Proxmox. J'ai investi 3 ans à les obtenir."

Levier : Les compétences KVM/Linux/Ceph/OVN sont plus portables et plus rémunérées que les certifications propriétaires VMware. CKAD, CKA, Linux Foundation — marché plus large. L'embarquer comme architecte de la migration : il devient l'expert le plus précieux du projet.

Ce qu'on ne dit pas : Sa résistance est rationnelle à court terme. Sur 3–5 ans, les compétences ouvertes l'exposent à un marché beaucoup plus large que les certifications Broadcom.

② L'ARCHITECTE NSX — Expert réseau VMware

Résistance : "OVN c'est compliqué, NSX-T je le connais par cœur. Le projet va durer 2 fois plus longtemps si on change le réseau."

Levier : OVN utilise le même protocole GENEVE que NSX-T. La logique de routage distribué est identique. Le delta d'apprentissage est 6–8 semaines, pas 6 mois. Le faire découvrir OVN en parallèle de NSX-T pendant la phase de double-stack.

Ce qu'on ne dit pas : Son expertise NSX-T est directement transférable à OVN — les concepts sont isomorphes. C'est souvent lui le meilleur formateur OVN de l'équipe après 4 semaines de pratique.

③ L'OPS "vCENTER ADDICT" — 5+ ans de confort console

Résistance : "vCenter fait tout en clic. Proxmox c'est de la ligne de commande, on va perdre en productivité."

Levier : Proxmox a une interface web complète et intuitive. Les opérations quotidiennes (créer/cloner/migrer une VM) sont aussi rapides en GUI Proxmox qu'en vCenter. La ligne de commande est un plus, pas une obligation pour les ops courants.

Ce qu'on ne dit pas : L'UX vCenter a été conçue pour créer cette dépendance. La nommer aide à la dépasser. Une démonstration live de 30 minutes suffit généralement à réduire l'anxiété.

◆ PLAN DE FORMATION — 3 PHASES · CARTOGRAPHIE DES COMPÉTENCES

Compétence VMware actuelle

Équivalent open-source

Delta

Durée formation

ESXi / vSphere admin

Proxmox VE + KVM/QEMU

Moyen

3–4 semaines

vSAN admin

Ceph admin (OSD/MON/CRUSH)

Élevé

6–8 semaines

NSX-T architect

OVN + OVS + FRRouting

Moyen

4–6 semaines

Tanzu / vSphere K8s

K3s / K8s vanilla + Velero

Moyen

3–5 semaines

Terraform vSphere provider

OpenTofu + Proxmox provider

Faible

1–2 semaines

OPS

PAGE 9 · GRILLE DE DÉCISION · ROI APPROXIMATIF

SUIS-JE PRÊT À MIGRER ? · 12 QUESTIONS · SCORE /24

Outil d'aide à la décision · Non exhaustif · Les chiffres de ROI sont des estimations approximatives à titre illustratif

◆

Q.

Question de décision · Oui = 2 pts · Non = 0 pt

Couche

1

Mon abonnement Broadcom a-t-il augmenté de plus de 50% depuis le rachat VMware ?

Tarifaire

2

Mon contrat actuel comporte-t-il des engagements non résiliables dépassant 12 mois ?

Contractuel

3

Ma latence D1↔D2 est-elle inférieure à 10ms RTT (compatible Ceph stretched) ?

Technique

4

Ai-je un site D3 indépendant des chemins réseau D1↔D2 pour le tiebreaker ?

Technique

5

Mon équipe dispose-t-elle d'au moins 2 ingénieurs Linux avancés capables d'administrer Ceph ?

Skills

6

Ai-je des VMs Tier 3 (dev/test) sans contrainte de disponibilité pour servir de pilote ?

Migration

7

Mon stockage vSAN utilise-t-il des politiques SPBM complexes difficiles à reproduire en Ceph ?

Technique

8

Mes flux NSX-T sont-ils documentés (topologie T0/T1, segments, ACLs DFW) ?

Réseau

9

J'utilise Tanzu : mes workloads K8s sont-ils stateless ou avec stockage persistant documenté ?

K8s

10

Ai-je un budget pour 6 mois de double-run (VMware + Proxmox en parallèle) ?

Financier

11

Mon management a-t-il validé une fenêtre de maintenance pour les VMs Tier 1 critiques ?

Gouvernance

12

Mon plan de disaster recovery actuel est-il documenté et testé dans les 6 derniers mois ?

PRA

0–8 pts

Prérequis insuffisants · Audit approfondi avant décision

9–14 pts

Migration faisable · Commencer par Tier 3 · Résoudre les gaps identifiés

15–18 pts

Migration recommandée · Plan 5 phases applicable

19–24 pts

Migration prioritaire · ROI rapide · Commencer Phase 0 immédiatement

◆ ROI APPROXIMATIF — EXEMPLE ILLUSTRATIF (20 HÔTES · 200 VMs · 3 SITES)

Ces chiffres sont purement illustratifs et approximatifs — votre situation réelle peut différer significativement selon la négociation Broadcom, le dimensionnement matériel et le coût de migration interne.
Coût VMware/Broadcom estimé (illustratif) : 300 000€/an (abonnement post-Broadcom ×3 sur une base antérieure de 100 000€).
Coût Proxmox estimé (illustratif) : Support Proxmox GmbH optionnel ~28 000€/an (20 nœuds × 1 400€) · licences logicielles : 0€ (AGPLv3).
Économie annuelle estimée : ~272 000€/an après migration complète.
Coût de migration estimé : 6 mois de double-run (~150 000€ infrastructure) + formation/consulting (~50 000€) = ~200 000€.
ROI estimé : moins de 9 mois après fin de migration. Ces estimations sont indicatives — à recalculer avec vos chiffres réels.

OPS

PAGE 10 · OUTILS · RESSOURCES · RÉFÉRENCES

OUTILS DE MIGRATION · DOCUMENTATION · COMMUNAUTÉS

◆

◆ OUTILS DE CONVERSION VM

virt-v2v — conversion de VMs VMware (VMDK) vers KVM (qcow2) · supporte ESXi, vCenter · gestion des drivers virtio automatique · libguestfs-tools
qemu-img — conversion manuelle VMDK → qcow2 · qemu-img convert -f vmdk -O qcow2 vm.vmdk vm.qcow2
Proxmox import plugin — import direct depuis datastore ESXi via l'interface Proxmox · disponible Proxmox VE 8.x
ovftool — export VMware vers OVA/OVF · utilisé en amont de virt-v2v

◆ OUTILS CEPH STRETCHED

ceph-deploy / cephadm — déploiement Ceph · cephadm recommandé pour Ceph 16+
crushtool — compilation et validation des CRUSH maps
ceph mon stretch cluster — commande d'activation du mode stretched
radosgw-admin — gestion objets RGW si stockage objet requis

◆ OUTILS RÉSEAU OVN

ovn-nbctl / ovn-sbctl — gestion des bases de données North/South OVN
ovs-vsctl — configuration Open vSwitch
FRRouting (FRR) — BGP EVPN pour routage inter-sites
Proxmox SDN — interface Proxmox pour OVN (simplifie la configuration)

◆ OUTILS K8s & BACKUP

Velero — backup/restore workloads K8s · migration Tanzu → K3s/K8s vanilla · vmware-tanzu/velero
K3s — Kubernetes léger · idéal <20 nœuds · k3s.io
Ceph CSI driver — stockage persistant K8s via RBD · github.com/ceph/ceph-csi
PBS (Proxmox Backup Server) — backup incrémentiel VMs · déduplication · chiffrement · gratuit

◆ DOCUMENTATION DE RÉFÉRENCE

Proxmox VE Admin Guide — pve.proxmox.com/pve-docs/
Ceph Documentation — docs.ceph.com · section "Stretched Clusters"
OVN Architecture Guide — ovn.org/documentation
FRRouting docs — docs.frrouting.org · BGP EVPN
RFC 7348 — VXLAN encapsulation
RFC 8365 — EVPN pour l'interconnexion de datacenters

◆ COMMUNAUTÉS & SUPPORT

Proxmox Community Forum — forum.proxmox.com · très actif · réponses rapides
Ceph Mailing Lists — lists.ceph.io · ceph-users pour les questions opérationnelles
OVN GitHub — github.com/ovn-org/ovn · issues et discussions
Support Proxmox GmbH — ~1 400€/an/nœud · SLA garanti
Red Hat Ceph Storage — support entreprise Ceph

◆ COMMANDES CLÉS — DÉMARRAGE RAPIDE

      # Conversion VMDK → qcow2

      virt-v2v -i vmx vm.vmx -o local -os /var/lib/vz/images/100/

      # Activation Ceph stretched mode

      ceph mon enable_stretch_mode <tiebreaker_mon> datacenter

      # QDevice Corosync sur D3

      pvecm qdevice setup <qdevice-ip>

      # Migration VM live D1 → D2

      qm migrate <vmid> <target-node-d2> --online --with-local-disks 0

Ce guide est une étude technique générique. Les configurations sont illustratives.
Ce document ne constitue pas un conseil d'ingénierie individualisé.
Nemo supra legem est
Amine RAITI · Architecte Infrastructure & SRE · Document public · CC BY-NC-SA 4.0 · AI Powered by Amine