Remplacer vCenter par Proxmox : gains, pertes et contournements qui fonctionnent vraiment

Le cadre de décision : ce que vous remplacez réellement

Remplacer vCenter par Proxmox n’est pas « changer d’hyperviseur ». C’est remplacer tout un modèle opérationnel :

• Plan de contrôle : vCenter (et souvent SSO, historique PSC, plugins, modèle de rôles) vs gestion de cluster Proxmox VE (pve-cluster/corosync) avec une interface web et une API.
• Couche calcul : ESXi vs KVM + QEMU (et optionnellement LXC).
• Histoire du stockage : VMFS+SAN/NVMe-oF/vSAN vs ZFS/Ceph/NFS/iSCSI/FC (oui, le FC existe toujours).
• Réseau : vDS/NSX vs bridges Linux, bonds, VLANs, OVS (optionnel) et ce que votre réseau physique est réellement.
• Opérations : « Tout est une case à cocher » vs « la plupart des choses sont un fichier, une commande et un journal ».

Le dernier point est le plus important. vSphere est une suite de produits conçue pour rendre la plupart des choses sûres pour les personnes qui ne veulent pas SSH. Proxmox est conçu pour rendre les choses possibles pour les personnes qui le veulent.

Aucune approche n’est moralement supérieure. Mais une seule s’alignera sur les instincts de votre équipe. Si l’outil de dépannage par défaut de votre équipe est « ouvrir un ticket », vous devrez investir dans la formation et des garde-fous. Si l’outil par défaut est « tail -f », Proxmox ressemblera à rentrer chez soi dans un appartement légèrement désordonné où vous pouvez enfin déplacer les meubles.

Faits intéressants et contexte historique (qui comptent opérationnellement)

1. KVM est entré dans le noyau Linux en 2007, transformant la virtualisation de « sauce spéciale » en « fonctionnalité du noyau ». C’est pourquoi la couche calcul de Proxmox paraît banale—et dans le bon sens.
2. QEMU est antérieur à KVM ; KVM l’a accéléré. En pratique, la plupart de la « magie » des VM dans Proxmox est une configuration QEMU plus le plomberie Linux.
3. Proxmox VE existe depuis 2008. Ce n’est pas un projet de week-end ; c’est une distribution durable avec des opinions fortes.
4. L’objectif initial de Ceph était le matériel grand public à grande échelle. Cette histoire se retrouve dans sa personnalité opérationnelle : résiliente, puissante et allergique aux hypothèses vagues sur le stockage.
5. ZFS est né chez Sun avec des sommes de contrôle bout en bout et copy-on-write. ZFS est le système de stockage qui suppose que vous vous mentez à vous-même à propos de vos disques.
6. La migration à la vMotion n’est pas une seule fonctionnalité ; c’est la compatibilité CPU, le stockage partagé ou les flux de migration, la stabilité réseau et la logique d’ordonnancement qui travaillent ensemble.
7. Les règles de quorum de Corosync viennent du monde de l’évitement du split-brain. Ce n’est pas négociable ; ce sont la physique et les systèmes distribués qui sont impolis.
8. La domination de vSphere tenait en partie à l’UX opérationnelle : une GUI cohérente, des concepts constants et un vaste écosystème de partenaires. Quand vous partez, vous quittez un écosystème, pas seulement un hyperviseur.
9. Les snapshots VMware sont devenus un anti-modèle culturel car ils étaient trop faciles. Proxmox facilite aussi les snapshots, donc vous aurez besoin de la même supervision mature.

Ce que vous gagnez avec Proxmox (les vrais avantages)

1) Un plan de gestion plus simple qu’il n’en a l’air

Le modèle de cluster de Proxmox est franc : adhésion corosync, un système de fichiers de configuration distribué (pmxcfs) et des nœuds qui doivent s’accorder sur la réalité. Vous n’obtenez pas un inventaire à mille objets avec des plugins collés dessus.

En production, cela se traduit souvent par une récupération plus rapide quand les choses dérapent. Moins de pièces en mouvement signifie moins de moments « le truc de gestion qui gère le truc de gestion est cassé ».

2) KVM est largement compris (et largement débogué)

Si vous recrutez des personnes Linux, vous pouvez constituer cette équipe. Si vous devez recruter des « personnes vCenter », vous cherchez sur un marché plus petit avec des salaires plus élevés.

De plus : quand vous rencontrez un problème noyau/driver, vous êtes dans le courant principal de Linux. Cela compte pour les cartes NIC, HBA, NVMe et les plateformes serveur particulières dont les vendeurs prétendent qu’elles sont « certifiées » jusqu’à ce que vous demandiez la version exacte du firmware.

3) Choix de stockage qui correspondent à la réalité

Proxmox n’impose pas une vision unique du stockage. Vous pouvez exécuter :

• ZFS local pour des performances prévisibles et une simplicité opérationnelle.
• Ceph pour un stockage partagé et distribué avec tolérance aux pannes—au prix de la complexité et d’une sensibilité à la latence.
• NFS/iSCSI/FC lorsque l’entreprise possède déjà un baquet de stockage et que vous n’êtes pas là pour commencer une religion.

Le gain n’est pas « plus d’options ». Le gain est de pouvoir choisir un modèle de stockage aligné avec votre charge, vos domaines de panne et les compétences de votre personnel.

4) Configuration transparente et points d’accroche pour l’automatisation

Proxmox se prête bien à l’infrastructure en tant que code sans vous forcer dans l’écosystème d’un fournisseur. L’API est utilisable, la CLI existe, et beaucoup de pièces critiques sont du texte sur disque.

Ce n’est pas « plus facile ». C’est récupérable. Quand l’UI est indisponible, vous pouvez toujours travailler. C’est une fonctionnalité sous-estimée jusqu’à 02h17 quand votre onglet de navigateur est vide.

5) Maîtrise des coûts au-delà des licences

Oui, les licences motivent. Mais l’histoire des coûts ne se limite pas au prix de l’abonnement. C’est aussi :

• Une moindre dépendance au savoir propriétaire.
• Plus de flexibilité dans le cycle de vie du matériel.
• La possibilité de standardiser sur des outils Linux pour la supervision, la journalisation et la réponse aux incidents.

Blague #1 : vCenter peut ressembler à un bateau de croisière de luxe. Proxmox, c’est plutôt un cargo : moins de buffets, plus de boîtes à outils.

Ce que vous perdez (et ce qui fait mal en production)

1) Intégration écosystémique et « un interlocuteur à blâmer »

L’écosystème de vSphere est toujours inégalé pour les intégrations d’entreprise : plugins de stockage, fournisseurs de sauvegarde, outils de sécurité, rapports de conformité et équipes qui savent déjà l’exploiter.

Avec Proxmox, les intégrations existent, mais supposez que vous passerez par des protocoles et des API standard plutôt que par la magie des fournisseurs. Ça va—jusqu’au moment où un audit corporatif attend des captures d’écran d’un tableau de bord précis.

2) Ordonnancement de niveau DRS et moteurs de politique matures

vSphere DRS n’est pas seulement « déplacer des VMs ». C’est un ordonnanceur opinionné affiné depuis des années, avec une UI qui le rend inévitable.

Proxmox propose HA, migration à chaud et des outils, mais son ordonnancement est plus simple. Si vous comptez sur DRS pour masquer des problèmes chroniques de planification de capacité, Proxmox exposera ces problèmes comme un projecteur.

3) Certaines « fonctionnalités confort entreprise »

Des choses qui peuvent vous manquer selon votre environnement :

• Des modèles RBAC profonds couvrant de nombreux objets et plugins.
• Le confort de l’« tout est supporté si c’est sur la HCL » pour les achats.
• Des expériences de gestion du cycle de vie très polis (Proxmox a des outils, mais moins adaptés aux grandes entreprises).

4) Garde-fous opérationnels (ceux qui empêchent les ingénieurs malavisés)

Proxmox vous donne du pouvoir. Le pouvoir, c’est génial jusqu’à ce qu’un ingénieur bien intentionné « optimise » quelque chose et fasse tomber un cluster. Dans vSphere, l’UI et les valeurs par défaut empêchent souvent la créativité. Dans Proxmox, Linux vous permettra poliment de faire des erreurs à la vitesse de la ligne de commande.

5) La réalité des attentes de support

Le support Proxmox est réel, mais ce n’est pas la même expérience culturelle qu’une grande équipe d’un méga-fournisseur. Si votre organisation a besoin qu’un fournisseur assiste chaque postmortem et bénisse chaque mise à jour de firmware, planifiez en conséquence.

Blague #2 : Certains disent « personne ne se fait virer pour avoir acheté VMware ». C’est vrai—jusqu’à ce que la facture arrive et que la finance devienne votre chef d’incident.

Contournements qui fonctionnent réellement (et lesquels ne fonctionnent pas)

Remplacer DRS : acceptez le « assez bon », puis ajoutez des garde-fous

Ce qui marche :

• Groupes HA Proxmox + priorités pour définir « ces VMs doivent revenir en premier ».
• Affinité/anti-affinité VM via tags + automatisation (contrôles de placement scriptés) pour les quelques charges qui en ont vraiment besoin.
• Marge de capacité comme politique : fonctionner à une utilisation plus faible en régime permanent pour ne pas avoir besoin d’un ordonnanceur omniscient.

Ce qui ne marche pas : tenter de recréer DRS parfaitement. Vous construirez un clone d’ordonnanceur fragile qui échoue sur les cas limites et fera haïr l’astreinte.

Remplacer vSAN : choisissez entre Ceph et « garder le SAN », puis engagez-vous

Ceph fonctionne quand : vous avez au moins 4–6 nœuds, un réseau rapide et redondant, des disques cohérents et la volonté de traiter le stockage comme un service de première classe.

ZFS local fonctionne quand : vous pouvez tolérer que « les VMs vivent là où les données vivent », et vous acceptez la réplication/sauvegarde plutôt que les sémantiques de stockage partagé.

Garder NFS/iSCSI/FC fonctionne quand : vous avez déjà une équipe stockage et que vous voulez des performances prévisibles avec moins de complexité opérationnelle sur le cluster d’hyperviseurs.

Ce qui ne marche pas : « Ceph sur 3 nœuds avec 1GbE parce que le labo a marché. » Le labo marche toujours. La production est l’endroit où la latence révèle votre personnalité.

Remplacer les workflows vMotion : standardisez vos chemins de migration

Proxmox supporte la migration à chaud, mais votre expérience dépend du stockage partagé et de la qualité réseau. Pour la maintenance planifiée, la migration à chaud suffit. Pour « il faut évacuer un nœud tout de suite », vous avez besoin de contraintes prévisibles :

• Même famille de CPU et flags compatibles si vous voulez des migrations transparentes.
• Stockage partagé (Ceph/NFS/iSCSI) ou acceptez que les migrations copient les disques et prennent du temps.
• Réseau de migration dédié ou QoS afin qu’il ne concurrence pas la réplication de stockage.

Remplacer les suites de sauvegarde d’entreprise : décidez si vous voulez cohérence applicative ou cohérence au crash

Proxmox Backup Server (PBS) est bon pour ce pour quoi il est conçu : sauvegardes rapides, dédupliquées et incrémentales avec tests de restauration. Beaucoup d’outils tiers supportent aussi Proxmox/KVM.

La vraie décision : avez-vous besoin de snapshots cohérents applicativement (VSS, quiescence de base de données, etc.) ou la cohérence au crash est-elle acceptable avec des processus de récupération au niveau applicatif ? Si vous prétendez que la cohérence au crash suffit pour tout, votre première vraie restauration de base de données deviendra une leçon pour la direction.

Remplacer « vCenter comme source de vérité » : choisissez-en une nouvelle

Dans beaucoup d’organisations, vCenter devient le CMDB de facto. Ce n’est pas un compliment, mais ça arrive.

Ce qui marche : choisissez un système pour posséder l’inventaire (CMDB, modèle type NetBox, même Git) et faites de Proxmox la couche d’exécution, pas la couche vérité.

Ce qui ne marche pas : laisser la vérité dériver entre des feuilles de calcul, l’UI Proxmox et la mémoire de quelqu’un.

Une citation de fiabilité pour vous garder honnête

« L’espoir n’est pas une stratégie. » — General Gordon R. Sullivan

Tâches pratiques : commandes, sorties et décisions

Ce sont les vérifications quotidiennes qui séparent « nous avons migré » de « nous opérons ». Chaque tâche inclut une commande, une sortie d’exemple, ce que ça signifie et la décision à prendre.

Task 1: Verify cluster membership and quorum

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-pve
Config Version:   42
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Sun Dec 28 10:12:08 2025
Quorum provider:  corosync_votequorum
Nodes:            5
Node ID:          0x00000003
Ring ID:          1.54
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   5
Highest expected: 5
Total votes:      5
Quorum:           3
Flags:            Quorate

Meaning: “Quorate: Yes” means the cluster agrees on membership; you can safely make cluster-wide changes.

Decision: If not quorate, stop doing anything “clever.” Fix corosync links, node reachability, or split-brain risk first.

Task 2: Check corosync link health (packet loss and latency)

cr0x@server:~$ corosync-cfgtool -s
Printing ring status.
Local node ID 3
RING ID 0
    id    = 10.10.10.13
    status= ring 0 active with no faults
RING ID 1
    id    = 10.10.11.13
    status= ring 1 active with no faults

Meaning: Multiple healthy rings reduce the chance that a single network issue takes out quorum.

Decision: If a ring shows faults, treat it like a production incident. Cluster flapping is how you get “random” VM HA events.

Task 3: See which nodes are ready and what versions they run

cr0x@server:~$ pvecm nodes
Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 pve01
0x00000002          1 pve02
0x00000003          1 pve03
0x00000004          1 pve04
0x00000005          1 pve05

Meaning: If a node disappears here but still pings, you may have corosync issues, not host failure.

Decision: Don’t start maintenance until membership is stable for several minutes.

Task 4: Confirm storage latency at the OS level (ZFS or general IO)

cr0x@server:~$ iostat -xz 1 3
Linux 6.8.12-4-pve (pve03)  12/28/2025  _x86_64_ (64 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.12    0.00    2.01    8.45    0.00   83.42

Device            r/s     w/s   rKB/s   wKB/s  await  svctm  %util
nvme0n1         220.0   410.0  8800.0 16400.0  3.20   0.15  9.60
sdg              10.0    80.0    90.0  1200.0 25.40   1.10  8.90

Meaning: await is end-to-end latency. One slow device can bottleneck ZFS mirrors/RAIDZ vdevs or Ceph OSD journals.

Decision: If await spikes during incidents, chase storage before blaming “the hypervisor.”

Task 5: Check ZFS pool health and error counters

cr0x@server:~$ zpool status -x
all pools are healthy

Meaning: No known device faults or checksum errors.

Decision: If you see checksum errors, plan disk replacement and check cabling/backplane; don’t “monitor it for a while.”

Task 6: Check ZFS compression and space pressure

cr0x@server:~$ zfs get -o name,property,value -r compression,compressratio,used,avail rpool
NAME   PROPERTY       VALUE
rpool  compression    zstd
rpool  compressratio  1.62x
rpool  used           3.41T
rpool  avail          820G

Meaning: Compression is on and effective; available space is getting tight.

Decision: At ~80–85% pool usage, schedule expansion. ZFS under space pressure becomes “why is everything slow?”

Task 7: Check Ceph cluster health (if you run it)

cr0x@server:~$ ceph -s
  cluster:
    id:     3a9b5d4a-6f3c-4ed7-a4a5-1f2cc1dcb8b2
    health: HEALTH_WARN
            1 slow ops, oldest one blocked for 31 sec

  services:
    mon: 3 daemons, quorum pve01,pve02,pve03 (age 2d)
    mgr: pve01(active, since 2d), standbys: pve02
    osd: 15 osds: 15 up (since 2d), 15 in (since 2d)

  data:
    pools:   3 pools, 256 pgs
    objects: 1.20M objects, 4.6 TiB
    usage:   14 TiB used, 28 TiB / 42 TiB avail
    pgs:     256 active+clean

Meaning: “slow ops” is usually latency: disks, network, or an overloaded OSD.

Decision: Treat slow ops as a storage incident. VM “random pauses” often trace here.

Task 8: Identify which Ceph daemon is misbehaving

cr0x@server:~$ ceph health detail
HEALTH_WARN 1 slow ops, oldest one blocked for 31 sec
[WRN] SLOW_OPS: 1 slow ops, oldest one blocked for 31 sec, daemons [osd.7] have slow ops.

Meaning: You have a suspect: osd.7.

Decision: Inspect that host’s disk latency, CPU steal, NIC errors. Don’t rebalance blindly.

Task 9: Validate bridge/VLAN/bond state on a node

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
eno1             UP             3c:fd:fe:aa:bb:01
eno2             UP             3c:fd:fe:aa:bb:02
bond0            UP             3c:fd:fe:aa:bb:01
vmbr0            UP             3c:fd:fe:aa:bb:01
vmbr1            UP             3c:fd:fe:aa:bb:01

Meaning: Links and bridges are up. This doesn’t prove VLAN tagging is correct, but it rules out “interface is down.”

Decision: If vmbr for storage/migration is down, stop migrations and expect Ceph/replication pain.

Task 10: Check bond health and active links

cr0x@server:~$ cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: eno1
MII Status: up
Actor Churn State: none
Partner Mac Address: 24:5a:4c:11:22:33

Slave Interface: eno2
MII Status: up
Actor Churn State: none
Partner Mac Address: 24:5a:4c:11:22:33

Meaning: LACP is up on both links, churn is none. Good.

Decision: If one slave flaps, expect intermittent storage timeouts and corosync weirdness. Fix physical networking before tuning Linux.

Task 11: See if VMs are experiencing ballooning or memory pressure

cr0x@server:~$ qm list
      VMID NAME                 STATUS     MEM(MB)    BOOTDISK(GB) PID
       101 api-prod-01          running    8192              80.00 22011
       114 db-prod-02           running   32768             500.00 18433
       130 kafka-03             running   16384             200.00 27190

Meaning: Basic VM inventory and current state.

Decision: If a “running” VM is slow, confirm host memory headroom next; don’t assume it’s the guest.

Task 12: Check host memory and swap activity

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           251Gi       198Gi       8.2Gi       2.1Gi        45Gi        41Gi
Swap:           16Gi       3.5Gi        12Gi

Meaning: Swap is in use. That can be normal or a warning, depending on trend and latency sensitivity.

Decision: If swap grows during peak and IO latency increases, reduce overcommit, disable ballooning for critical workloads, or add RAM.

Task 13: Detect CPU steal and scheduling contention

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 6  0  356812 856432  9012 328912    0    0   120   450 1200 4100 18  6 70  6  0
 9  0  356812 844120  9012 329500    0    0   140   520 1350 4700 22  7 64  7  0
 7  0  356812 838900  9012 329910    0    0   160   610 1420 4900 25  6 60  9  0
 5  0  356812 834220  9012 330020    0    0   130   480 1280 4300 19  6 68  7  0
 6  0  356812 830440  9012 330120    0    0   110   460 1250 4200 17  5 72  6  0

Meaning: wa indicates IO wait. If it spikes, the CPU is waiting on storage. If st spikes (on nested virt/cloud), CPU is being stolen.

Decision: High IO wait points to storage latency; stop tuning CPU governors and look at disks/network.

Task 14: Confirm time sync (corosync and Ceph both care)

cr0x@server:~$ timedatectl
               Local time: Sun 2025-12-28 10:15:44 UTC
           Universal time: Sun 2025-12-28 10:15:44 UTC
                 RTC time: Sun 2025-12-28 10:15:44
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Meaning: Clock is synchronized.

Decision: If clocks drift, fix NTP before diagnosing “random auth errors” or cluster instability.

Task 15: Inspect HA manager state and failures

cr0x@server:~$ ha-manager status
quorum OK
master pve02 (active, Wed Dec 24 11:02:14 2025)
lrm pve01 (active, Wed Dec 24 11:03:10 2025)
lrm pve02 (active, Wed Dec 24 11:02:14 2025)
lrm pve03 (active, Wed Dec 24 11:03:05 2025)
lrm pve04 (active, Wed Dec 24 11:03:02 2025)
lrm pve05 (active, Wed Dec 24 11:03:00 2025)
service vm:114 (started)

Meaning: Quorum OK, HA master elected, local resource managers are active.

Decision: If HA is flapping, check corosync first. HA is downstream of cluster health.

Task 16: Convert a VMware disk to a Proxmox-friendly format

cr0x@server:~$ qemu-img convert -p -f vmdk -O qcow2 disk-flat.vmdk vm-101-disk-0.qcow2
    (100.00/100%)

Meaning: Disk converted. qcow2 supports snapshots; raw is often faster. Pick intentionally.

Decision: For high-IO databases, prefer raw on ZFS zvol or Ceph RBD; for general workloads, qcow2 may be fine.

Playbook de diagnostic rapide : trouvez le goulot d’étranglement avant d’émettre des hypothèses

Ceci est la checklist des « dix premières minutes » quand quelqu’un dit : « Proxmox est lent » ou « les VMs se bloquent ». La rapidité compte. L’ego est coûteux.

Premier : état du cluster et quorum (ne déboguez pas des fantômes)

• Vérifier le quorum : pvecm status → si pas quorate, arrêtez et réparez l’adhésion.
• Vérifier les anneaux corosync : corosync-cfgtool -s → cherchez des fautes.
• Vérifier HA : ha-manager status → si HA n’est pas stable, traitez comme un problème de cluster.

Second : latence stockage (la plupart des « problèmes hyperviseur » sont du stockage)

• Local/ZFS : iostat -xz 1 3, zpool status, saturation du pool.
• Ceph : ceph -s, ceph health detail pour les slow ops et les OSD coupables.
• Cartographie des symptômes : pauses VM, fort IO wait, sauvegardes bloquées, timeouts invités.

Troisième : réseau (parce que le stockage en dépend, et le quorum aussi)

• État des liens : ip -br link, état des bonds dans /proc/net/bonding/*.
• Erreurs : ethtool -S (non montré ci-dessus, mais à utiliser) pour CRC, drops, resets.
• Ségrégation : corosync et le trafic stockage ne devraient pas se battre avec l’est-ouest des VMs à moins que vous aimiez la latence imprévisible.

Ensuite : contention calcul

• Mémoire : free -h, réglages de ballooning, tendance de croissance du swap.
• CPU : vmstat, épinglage CPU par VM seulement si justifié.
• Journaux noyau : journalctl -k pour resets de drivers et bizarreries IOMMU.

Règle d’or : si vous ne pouvez pas prouver une hypothèse avec une commande et un extrait de journal, vous êtes encore en train de deviner.

Trois mini-récits d’entreprise depuis le terrain

Incident causé par une mauvaise hypothèse : « C’est juste comme vMotion »

Une entreprise SaaS de taille moyenne a migré un ensemble de VMs applicatives de vSphere vers Proxmox pendant une ruée sur les licences. Ils avaient un stockage partagé sur NFS et un réseau 10GbE dédié. Sur vSphere, ils faisaient depuis des années des fenêtres de maintenance en direct : évacuer l’hôte, patcher, redémarrer, passer à autre chose. La mémoire musculaire est puissante.

Sur Proxmox, ils ont activé la migration à chaud et lancé une évacuation planifiée d’un nœud. Ça a fonctionné pour la couche d’applications sans état. Puis ils ont essayé la VM base de données. La migration a démarré, progressé, puis ralenti jusqu’à l’arrêt. L’équipe applicative a signalé des timeouts. L’astreinte a supposé que c’était une « lenteur normale de migration » et l’a laissée continuer.

Ce n’était pas normal. La VM base de données avait une NIC virtuelle sur un bridge qui partageait la bande passante avec le trafic de migration parce que le « réseau de migration » n’était pas réellement isolé ; c’était un VLAN sur le même bond sans QoS et une politique de switch qui ne le traitait pas spécialement. Sous charge, le flux de migration a compressé le trafic de réplication de la base, ce qui a déclenché des retries applicatifs, augmentant l’IO, augmentant la mémoire sale, ce qui a rendu la migration encore plus lente. Une boucle de rétroaction, le genre qui fait ressembler les graphiques à une mauvaise journée en bourse.

La correction n’a pas été héroïque. Ils ont séparé le trafic de migration sur sa propre paire de NIC physiques (ou au moins appliqué du QoS), limité la bande passante de migration, et arrêté de migrer les VMs stateful pendant les périodes d’écriture de pointe. Ils ont aussi mis à jour leur runbook : « La migration à chaud est un outil, pas un rituel. »

La mauvaise hypothèse était subtile : ils supposaient que « la migration à chaud » est une fonctionnalité binaire. En réalité c’est un contrat de performance avec votre réseau et votre stockage. vSphere les accompagnait davantage. Proxmox leur a montré la physique brute.

Optimisation qui s’est retournée contre eux : « On va pousser la réplication et la compression partout »

Une grande équipe IT interne a déplacé un parc de VMs Windows et Linux sur Proxmox avec ZFS sur chaque nœud et une réplication asynchrone entre nœuds pour un « pauvre stockage partagé ». Le design était correct. L’exécution est devenue… ambitieuse.

Quelqu’un a décidé que puisque la compression ZFS est quasi gratuite (souvent vrai), il fallait utiliser la compression la plus forte et répliquer tout toutes les cinq minutes. Le cluster avait beaucoup de CPU, alors pourquoi pas ? Ils ont activé zstd à un niveau élevé sur des datasets contenant des disques VM, activé des jobs de réplication fréquents et se sont félicités d’être modernes.

Deux semaines plus tard, le helpdesk a observé un motif : lenteur intermittente des VMs pendant les heures de bureau. Rien de « down », juste lent. Les graphiques de stockage montraient des pics périodiques. Les graphiques réseau montraient des pics périodiques. Les sauvegardes étaient parfois en retard.

La cause racine n’était pas la compression en elle-même. C’était la combinaison d’intervalles de réplication agressifs avec des charges ayant des écritures en rafales. La réplication créait des tempêtes IO périodiques. La forte compression ajoutait une charge CPU pendant ces tempêtes. Et comme la réplication était synchronisée sur l’horloge, plusieurs nœuds piquaient en même temps. Ils avaient construit un thundering herd distribué.

La correction a été banale : réduire le niveau de compression (ou garder zstd mais à un défaut raisonnable), échelonner les horaires de réplication, et créer des niveaux : VMs critiques répliquées fréquemment, les autres moins souvent. Après cela, les performances se sont stabilisées et le taux d’incidents a baissé. La morale : les fonctionnalités « gratuites » ne le sont pas quand vous les programmez pour vous frapper toutes les cinq minutes.

Pratique ennuyeuse mais correcte qui a sauvé la mise : « Règles de quorum, accès hors bande et maintenance disciplinée »

Une entreprise régulée exploitait un cluster Proxmox dans deux racks au sein du même hall. Pas glamour. Leur équipe SRE a insisté sur trois choses que personne ne voulait budgéter : un réseau corosync dédié avec switches redondants, un accès hors-bande documenté pour chaque nœud, et un processus de maintenance progressif strict avec une porte de « vérification du quorum ».

Un après-midi, un switch top-of-rack a commencé à laisser tomber des paquets de manière intermittente à cause d’un problème de firmware. Le symptôme initial était étrange : certaines VMs allaient bien, d’autres bégayaient, et le cluster Ceph avertissait parfois de slow ops. C’est le genre de panne qui adore vous faire perdre une journée.

Parce que leur réseau corosync était séparé et redondant, le cluster n’a pas flappé. HA n’a pas paniqué en migrant les VMs inutilement. Cela a suffi à empêcher une cascade. Ensuite, l’accès hors-bande leur a permis d’extraire les journaux et de valider les erreurs de lien même avec des parties du réseau défaillantes. Ils ont isolé le switch, basculé les liens et remplacé le firmware de façon contrôlée.

Rien là-dedans n’était impressionnant en démonstration. Mais cela a évité une indisponibilité. Leur post-mortem a été presque ennuyeux—ce qui est le compliment suprême qu’une équipe d’opérations puisse se faire.

Erreurs courantes : symptômes → cause racine → correction

1) Symptom: random VM pauses, “stun-like” behavior, timeouts

Root cause: storage latency (Ceph slow ops, ZFS pool near full, single slow disk, or network drops on storage VLAN).

Fix: check ceph -s/ceph health detail or iostat and pool fullness; separate storage traffic; replace failing disks; keep ZFS under ~80–85%.

2) Symptom: HA keeps restarting services or migrating VMs unexpectedly

Root cause: corosync instability, packet loss, or quorum flapping.

Fix: validate pvecm status and corosync-cfgtool -s; put corosync on a dedicated network; fix LACP and switch issues.

3) Symptom: live migrations are slow or fail intermittently

Root cause: migration traffic contending with VM/storage traffic; lack of shared storage; dirty memory rate too high; CPU compatibility issues.

Fix: dedicate a migration network or enforce QoS; schedule migrations; reduce write load during migrations; standardize CPU families or use compatible CPU types.

4) Symptom: backups are inconsistent, restores are “surprisingly bad”

Root cause: relying on crash-consistent snapshots for apps that need quiescing; snapshot sprawl; no restore testing.

Fix: define app-consistency requirements; use guest agents where applicable; enforce snapshot TTL; test restores monthly.

5) Symptom: network works for some VLANs but not others

Root cause: bridge VLAN awareness mismatch, trunk configuration mismatch on the switch, or using the wrong interface for management vs VM traffic.

Fix: verify Linux bridge config, switch trunk allowed VLANs, and bond mode; validate with ip link and packet captures when needed.

6) Symptom: “Proxmox UI is slow” but VMs seem fine

Root cause: management plane contention, DNS issues, time drift, or browser-to-node connectivity problems.

Fix: check node load and memory; validate DNS resolution from your workstation and nodes; confirm timedatectl synchronized; keep management traffic stable.

7) Symptom: performance tanks after “tuning”

Root cause: premature optimization: over-aggressive ZFS settings, too many replication jobs, Ceph mis-sized placement groups, or CPU pinning without measurements.

Fix: revert to known-good defaults; change one variable at a time; measure latency and throughput; stagger heavy jobs.

8) Symptom: cluster upgrade causes surprises

Root cause: mixed repository configurations, inconsistent package versions, or upgrading without checking quorum/HA state.

Fix: standardize repos; do rolling upgrades; gate on pvecm status and ha-manager status; keep console access available.

Listes de contrôle / plan étape par étape

Plan de migration étape par étape (vCenter → Proxmox avec un minimum de drame)

1. Inventaire réel : lister les VMs, types d’OS, modes de démarrage (BIOS/UEFI), périphériques spéciaux, patterns de type RDM, besoins GPU et exigences de cohérence applicative.
2. Choisissez d’abord votre modèle de stockage : Ceph vs baie partagée vs ZFS local+réplication. Si vous décidez tard, vous devrez tout refaire.
3. Concevez les réseaux intentionnellement : au minimum séparer management, stockage (si Ceph) et migration. Si vous ne pouvez pas séparer physiquement, appliquez du QoS et documentez-le.
4. Construisez un petit cluster Proxmox : pas un jouet de labo—utilisez des NICs, MTU, VLANs et stockage proches de la production. Validez le comportement en cas de panne.
5. Définissez la compatibilité CPU : choisissez un modèle CPU de référence pour les VMs si vous prévoyez des migrations entre hôtes hétérogènes.
6. Décidez de l’outil de sauvegarde : PBS ou tiers ; définissez RPO/RTO par charge ; fixez les attentes avec les propriétaires applicatifs.
7. Construisez la supervision avant la migration : santé des nœuds, latence stockage, erreurs NIC, alertes cluster/quorum. Si vous attendez, le premier incident vous l’enseignera en public.
8. Migrez par vagues : commencez par les services sans état, puis les stateful à faible risque, puis les workloads critiques en dernier.
9. Exécutez une double exploitation brièvement : gardez vSphere en lecture seule si possible pendant les fenêtres de basculement ; documentez les chemins de retour.
10. Standardisez les templates : cloud-init pour Linux quand possible, drivers cohérents, QEMU guest agent et formats de disque raisonnés.
11. Appliquez l’hygiène du cycle de vie : cadence de patch, mises à jour noyau, alignement firmware et fenêtres de changement.
12. Faites des exercices de restauration : prouvez que vous pouvez restaurer la VM « difficile » (base de données) et pas seulement un serveur web jetable.

Checklist opérationnelle pour un cluster Proxmox sain

• Quorum stable, plusieurs anneaux corosync si possible.
• Synchronisation temporelle verte sur tous les nœuds.
• Réseaux dédiés ou contrôlés pour stockage/migration.
• Pools ZFS pas proches de la saturation ; planning de scrub ; erreurs disque traitées.
• Ceph : pas d’HEALTH_WARN persistant ; slow ops traités comme incidents.
• Sauvegardes surveillées ; restaurations testées ; TTL des snapshots appliqué.
• Mises à niveau progressives avec un runbook écrit et une porte « arrêter si pas quorate ».

FAQ

1) Proxmox peut-il remplacer complètement vCenter pour une entreprise ?

Pour beaucoup d’entreprises, oui—si vous définissez « remplacer » comme « exploiter et gérer la virtualisation de façon fiable ». Si vous entendez « reproduire chaque workflow de plugin vCenter et chaque moteur de politique », non. Prévoyez des outils différents pour RBAC, CMDB et reporting de conformité.

2) Quel est l’équivalent le plus proche de vSphere HA ?

HA Proxmox peut redémarrer des VMs sur d’autres nœuds et gérer des priorités. C’est efficace quand corosync est stable et que le stockage est partagé (Ceph/NFS/iSCSI) ou lorsque vous acceptez que les VMs sur stockage local aient des patterns de récupération différents.

3) Quel est l’équivalent le plus proche de DRS ?

Il n’y a pas d’équivalent un-à-un. Utilisez des règles de placement simples, une politique de marge et de l’automatisation pour les quelques charges « à séparer ». Si vous dépendez de DRS pour garder l’infrastructure en vie, améliorez d’abord la planification de capacité.

4) Dois-je utiliser Ceph ou ZFS ?

Si vous avez besoin de stockage partagé et de comportements HA comme « la VM peut redémarrer n’importe où avec son disque », Ceph est la voie native Proxmox—mais il exige un réseau bas-latence et du matériel cohérent. Si vous privilégiez la simplicité et des performances prévisibles par nœud, ZFS est excellent. Beaucoup d’environnements de production combinent les deux : Ceph pour l’usage général, ZFS pour les workloads critiques en latence.

5) Ai-je besoin d’un réseau séparé pour corosync ?

Vous n’en avez pas strictement besoin, mais vous devriez vous comporter comme si c’était le cas. Corosync déteste la perte de paquets et la gigue. Si corosync partage un réseau congestionné, l’instabilité HA deviendra votre nouveau hobby.

6) Comment migrer en toute sécurité des VMs VMware vers Proxmox ?

Chemin standard : exporter/convertir les disques (VMDK → qcow2/raw), recréer la config VM et valider le mode de démarrage et les drivers. Pour des flottes larges, automatisez la conversion et la génération de configuration. Testez toujours les VMs « bizarres » en premier : UEFI, drivers NIC spéciaux, bases de données et tout ce qui a des licences liées au hardware virtuel.

7) Proxmox Backup Server est-il suffisant pour la production ?

Oui, pour beaucoup d’environnements. Il est rapide, dédupliqué et opérationnellement sensé. La question clé n’est pas « PBS est-il bon ? » mais « avez-vous besoin de sauvegardes cohérentes applicativement et testez-vous les restaurations ? » Les outils ne remplacent pas la discipline.

8) Qu’en est-il du RBAC et de la multi-tenantisation ?

Proxmox offre des rôles et des permissions, mais si vous faites de l’hébergement multi-tenant strict avec séparation profonde, vous aurez besoin de contrôles supplémentaires : segmentation réseau, séparation du stockage et processus opérationnels stricts. Pour un usage interne en entreprise, c’est généralement suffisant.

9) Quel est le coût caché le plus important en migrant hors de vCenter ?

La remise à niveau opérationnelle et la reconstruction de la « mémoire musculaire » institutionnelle : supervision, réponse aux incidents, workflows de sauvegarde/restauration et conception réseau/stockage. Le changement d’hyperviseur est la partie facile.

10) Quel est le risque le plus important ?

Sous-estimer à quel point les valeurs par défaut de vCenter vous protégeaient de votre propre organisation. Avec Proxmox, vous pouvez absolument bâtir une plateforme robuste—mais vous devez choisir et appliquer des standards.

Prochaines étapes que vous pouvez exécuter cette semaine

1. Rédigez votre « définition de fini » pour la migration : stabilité du quorum, comportement HA, RPO/RTO de sauvegarde et couverture de supervision.
2. Choisissez le stockage intentionnellement (Ceph vs ZFS vs baie) et documentez les domaines de panne que vous concevez.
3. Déployez un pilote 3–5 nœuds avec un réseau proche de la production. Validez : perte de nœud, perte de switch, perte de disque et procédures de restauration.
4. Créez un runbook de migration qui inclut : étapes de conversion, vérifications, chemin de retour et « conditions d’arrêt » (pas quorate, Ceph health WARN, etc.).
5. Instrumentez le minimum : alertes quorum, slow ops Ceph, santé pool ZFS, erreurs NIC, échecs de sauvegarde et rappels de tests de restauration.
6. Faites un exercice : simulez la défaillance d’un nœud et mesurez le temps de récupération et le temps pour comprendre l’incident. Si vous ne pouvez pas expliquer l’incident en 15 minutes, améliorez l’observabilité.

Remplacez vCenter par Proxmox quand vous voulez une plateforme que vous pouvez raisonner sous stress. Ne le faites pas parce que quelqu’un vous a promis « pareil mais moins cher ». Ce n’est pas pareil. Ça peut être meilleur—si vous le construisez en y mettant de l’intention.