Alternatives à ESXi pour PME : Proxmox vs XCP-ng vs Hyper-V

Décision en 60 secondes

Si vous voulez le chemin le plus court vers « ça fonctionne comme une pile VMware moderne » dans une petite structure : choisissez Proxmox, surtout si vous êtes à l’aise avec Linux et que vous voulez des sauvegardes intégrées solides, du clustering et une histoire claire pour le stockage (ZFS pour hôte unique ou petits clusters ; Ceph si vous avez réellement le nombre de nœuds et le réseau requis).

Si vous voulez de la virtualisation basée sur Xen avec une séparation claire des responsabilités et un écosystème solide : choisissez XCP-ng avec Xen Orchestra. C’est adapté si vous appréciez des hôtes de type appliance et une gestion qui semble conçue pour la virtualisation, pas bricolée dessus.

Si vous êtes une PME orientée Windows avec AD, des administrateurs Windows et des licences Microsoft déjà payées : choisissez Hyper-V avec Failover Clustering si vous avez besoin de HA, ou Hyper-V autonome si ce n’est pas le cas. C’est ennuyeux, supporté et très efficace pour les charges Windows. Mais votre conception de stockage et de sauvegarde doit être explicite, pas basée sur des impressions.

À éviter : un design « HA » à 2 nœuds sans témoin, sans restauration testée et avec un plan de stockage qui se résume à « on a un NAS ». Ce n’est pas de l’architecture ; c’est un futur rapport d’incident.

Ce dont une PME a vraiment besoin (et ce qu’elle croit vouloir)

Les exigences réelles

• Mises à jour prévisibles qui ne tournent pas en archéologie du week-end.
• Sauvegardes restaurables sans prière, notamment pour les contrôleurs de domaine, les applications métier et les serveurs de fichiers.
• Comportement du stockage explicable : latence, durabilité des écritures, cache, snapshots, réplication. « Rapide » n’est pas un plan.
• Ergonomie opérationnelle : console distante, cycle de vie des VM, modifications réseau et journaux lisibles.
• Un modèle de défaillance : que se passe-t-il quand un hôte meurt, un switch tombe ou un datastore se remplit.

Les fausses exigences (illusions courantes)

• « Nous avons besoin de HA » alors qu’ils ont vraiment besoin de restaurations rapides et d’un hôte de rechange.
• « Nous avons besoin d’hyperconvergence » alors qu’ils n’ont ni nœuds, ni réseau, ni maturité opérationnelle.
• « On utilisera juste ce NAS » sans vérifier la sécurité du cache d’écriture et le comportement multipath.
• « Nous avons besoin de la migration à chaud » mais ils ne financeront pas le stockage partagé ou un design compatible migration.

La fiabilité est une chaîne de petites décisions peu séduisantes. L’hyperviseur n’est qu’un maillon, mais c’est celui que vous touchez chaque fois que quelque chose casse.

Faits intéressants et contexte historique

1. Xen est plus ancien que la plupart des intitulés « cloud-native » : l’hyperviseur Xen est né au début des années 2000 comme projet de recherche et est devenu une base importante en industrie.
2. Citrix XenServer a façonné beaucoup d’opérations Xen en entreprise pendant des années ; XCP-ng a grandi comme une continuité communautaire quand des organisations ont voulu plus d’ouverture et de contrôle.
3. KVM est devenu le moteur de virtualisation mainstream de Linux et est la base sur laquelle Proxmox s’appuie, bénéficiant d’investissements au niveau du noyau.
4. ZFS a été conçu pour l’intégrité des données de bout en bout, pas seulement « RAID avec une interface plus jolie », ce qui explique son attrait chez ceux qui ont vu la corruption silencieuse de près.
5. Hyper-V n’est pas « nouveau » : c’est un rôle central de Windows Server depuis de nombreuses versions et il a beaucoup mûri grâce aux besoins cloud internes de Microsoft.
6. Le clustering de basculement précède le battage actuel autour de la virtualisation ; le modèle de clustering Windows suppose depuis longtemps un stockage partagé et des mathématiques de quorum — toujours pertinentes, toujours faciles à mal configurer.
7. L’abus de snapshots revient sur toutes les plateformes : c’est une machine à remonter le temps pratique jusqu’à ce que cela devienne une grenade de performance et une fuite de stockage.
8. SMB3 a apporté une vraie plomberie de stockage (comme multichannel et meilleure résilience) et est devenu un transport légitime pour les charges Hyper-V dans de nombreux environnements.

Comparaison des plateformes : Proxmox vs XCP-ng vs Hyper-V

Proxmox : le couteau suisse pragmatique (avec des bords tranchants)

Proxmox VE est une plateforme basée sur Debian qui marie la virtualisation KVM et les conteneurs LXC avec une interface web cohérente, du clustering et une option de serveur de sauvegarde intégré (Proxmox Backup Server). En termes PME : vous pouvez acheter quelques serveurs corrects, installer Proxmox et obtenir quelque chose de proche de VMware sans devoir « assembler votre propre plan de gestion ».

Où Proxmox brille :

• Excellente histoire de stockage pour PME : ZFS est de première classe et vous pouvez faire de la réplication sensée sans SAN.
• Les sauvegardes sont un vrai produit : PBS gère bien la déduplication, l’incrémentiel et reste opérationnellement raisonnable.
• La gestion du cluster est simple une fois que vous respectez quorum et les réalités de fencing.
• Affinité Linux : si votre équipe connaît Linux, le « recours CLI » est toujours disponible.

Où Proxmox peut mordre :

• Ceph n’est pas un jouet. Il est excellent quand il est bien fait et coûteux quand il est mal fait (surtout en temps, pas en licences).
• L’optimisation réseau et stockage compte si vous voulez une latence déterministe. Les valeurs par défaut sont correctes, mais pas toujours optimales.
• Le support existe, mais vous opérez toujours Linux. Si votre équipe traite Linux comme une rumeur, vous souffrirez.

XCP-ng : la stabilité Xen avec une couche de gestion que vous utiliserez réellement

XCP-ng est un hyperviseur basé sur Xen avec une empreinte hôte relativement orientée appliance. Associez-le à Xen Orchestra (auto-hébergé ou supporté) et vous obtenez un flux opérationnel solide : gestion des VM, sauvegardes, snapshots, migrations, templates — sans devoir coller une douzaine de composants.

Où XCP-ng brille :

• Clarté opérationnelle : les hôtes sont cohérents ; la gestion est cohésive avec Xen Orchestra.
• Bonne expérience du cycle de vie des VM et modèle de virtualisation mature.
• Les sauvegardes via XO sont pratiques, surtout avec des dépôts et une politique de rétention bien conçus.

Où XCP-ng peut mordre :

• Les choix de stockage peuvent être moins « tout compris » que Proxmox+ZFS pour les petits clusters, selon votre architecture.
• Moins de part de marché que Hyper-V ; recrutement et connaissances locales peuvent être plus rares dans certaines régions.
• Certaines fonctionnalités avancées sont limitées par la complexité opérationnelle plutôt que par la licence — et ce sera toujours votre problème à 2 h du matin.

Hyper-V : le choix sensé quand Windows est votre religion (ou votre masse salariale)

Hyper-V est l’hyperviseur que beaucoup de PME possèdent déjà via leurs licences Windows Server, et il s’intègre proprement à Active Directory, aux outils Windows et à l’univers opérationnel Microsoft. Pour des charges Windows, c’est un choix rationnel par défaut — surtout si votre équipe maîtrise PowerShell.

Où Hyper-V brille :

• Performance et support des charges Windows sont excellents.
• Failover Clustering est mature et fait exactement ce qu’il promet, à condition de respecter le quorum et le stockage.
• Bonne intégration opérationnelle dans les environnements Microsoft : surveillance, patching, identité et gestion s’alignent.

Où Hyper-V peut mordre :

• Le design du stockage partagé peut être impitoyable. CSV, iSCSI, partages SMB3 — chacun a des angles vifs s’il est mal configuré.
• L’écosystème de sauvegarde varie énormément. Certains outils sont excellents, d’autres font « des fichiers, donc c’est une sauvegarde ».
• Les invités Linux fonctionnent bien, mais si vous êtes principalement Linux et orienté stockage, Proxmox est souvent un conducteur quotidien plus fluide.

Mon classement SME subjectif (avec réserves)

• Meilleur choix général pour PME : Proxmox, si vous vous engagez à l’apprendre correctement (surtout ZFS et l’hygiène des sauvegardes).
• Meilleur choix « appliance + exploitation propre » : XCP-ng avec Xen Orchestra, si vous voulez une pile de virtualisation ciblée avec des workflows solides.
• Meilleur choix orienté Windows : Hyper-V, si vous exécutez déjà Windows Server partout et pouvez concevoir le stockage partagé de façon responsable.

Une petite blague pour nettoyer le palais : les discussions sur la licence de virtualisation sont les seules réunions où l’on peut perdre de l’argent en restant parfaitement immobile.

Réalités du stockage : ZFS, Ceph, SMB3, iSCSI et le « NAS qui ment »

Commencez par la charge : la sensibilité à la latence prime sur le marketing IOPS

La virtualisation en PME est généralement un mélange : quelques éléments de type base de données, du fichier et impression, AD, peut-être un outil RMM, une appliance VoIP et l’application métier que votre fournisseur qualifie de « légère ». La vérité : beaucoup de charges PME sont sensibles à la latence, pas avides de débit. Vos utilisateurs remarquent une latence de stockage de 30 ms bien plus vite qu’un pic d’IOPS.

Stockage Proxmox : ZFS est la réponse par défaut pour une raison

Si vous n’achetez pas de SAN, ZFS vous donne une histoire cohérente : checksumming, snapshots, réplication, compression et outils prévisibles. Mais ZFS ne vous pardonnera pas de faire comme si la RAM et une disposition correcte des vdev étaient optionnelles.

• Les vdevs en miroir sont le point doux courant pour les PME : latence prévisible et survivabilité.
• RAIDZ peut convenir aux charges axées capacité, mais la latence d’écritures aléatoires peut pénaliser certains mixes de VM.
• SLOG et L2ARC ne sont pas des cartes magiques « accélère tout » ; ils ont des usages et des modes de défaillance précis.

Stockage Proxmox : Ceph est excellent quand vous avez la bonne topologie

Ceph brille quand vous avez suffisamment de nœuds (typiquement 4+ pour des opérations confortables, bien que des gens utilisent 3) et un réseau qui ne le sabote pas. Si votre « réseau de stockage » est un switch unique sans redondance et un VLAN que vous oubliez parfois, Ceph vous éduquera.

Ceph bien fait vous donne : stockage distribué, auto-réparation et bonne intégration avec Proxmox. Ceph mal fait vous donne : « pourquoi tout est lent » et « pourquoi le cluster est passé en lecture seule ».

Stockage XCP-ng : choisissez un design que vous pouvez expliquer sur un tableau blanc

XCP-ng prend en charge plusieurs types de dépôts de stockage, et le bon choix dépend de votre environnement. En PME, vous vous retrouvez souvent sur un stockage partagé iSCSI/NFS, ou un stockage local avec stratégies de réplication/sauvegarde. Le risque le plus grand est de traiter le stockage partagé comme « juste un endroit pour mettre des VM » plutôt que comme un composant avec des réglages multipath, le comportement du cache d’écriture et la gestion des pannes.

Stockage Hyper-V : le triangle CSV/SMB3/iSCSI

Hyper-V peut fonctionner sur stockage local, mais le scénario HA typique utilise Failover Clustering avec Cluster Shared Volumes (CSV) sur un stockage bloc partagé, ou des partages SMB3 pour le stockage des VM. SMB3 est légitime, mais il exige une configuration NIC correcte, une planification multichannel et un serveur de stockage qui tient sous I/O VM soutenu. Un NAS grand public qui semble correct à 50 Mo/s lors d’un test de copie peut s’effondrer quand vous le bombardez de petites écritures aléatoires provenant de 20 VM.

Deuxième courte blague, parce que le stockage le mérite : un NAS sans cache d’écriture protégé par batterie est comme un parachute fait d’optimisme — parfait jusqu’au moment où vous en avez besoin.

Gestion et exploitation : le jour-2 compte plus que le jour-1

Exploitation Proxmox

L’interface web de Proxmox est solide, mais le vrai pouvoir vient du fait que c’est Linux en dessous. C’est à la fois une force et un piège. Vous pouvez réparer presque tout, ce qui signifie aussi que vous pouvez « réparer » des choses d’une façon qui diverge de l’UI et vous surprenne lors des mises à jour.

Conseils opérationnels qui comptent vraiment :

• Conservez les changements d’hôte déclaratifs autant que possible (config de cluster, définitions de stockage, configuration réseau suivies).
• Utilisez Proxmox Backup Server plutôt que d’improviser des exportations de snapshots.
• Planifiez le quorum (nombre impair de votants ; utilisez un qdevice si nécessaire).

Exploitation XCP-ng

Les hôtes XCP-ng sont relativement orientés appliance, ce qui réduit la dispersion des configurations. Xen Orchestra devient le centre opérationnel : calendriers de sauvegarde, rétention, tests de restauration, journaux de tâches et inventaire. C’est bénéfique pour les PME car « une vitre » réduit l’erreur humaine sous pression.

La discipline opérationnelle principale : garder Xen Orchestra sain et sauvegardé, et traiter le patching des hôtes comme une routine, pas un moment héroïque.

Exploitation Hyper-V

L’exploitation Hyper-V vit dans un monde Windows : Failover Cluster Manager, Windows Admin Center, PowerShell et vos outils de gestion des patches. En PME, le danger est la complexité accidentelle : un admin crée un cluster, un autre ajoute des exceptions « temporaires » et six mois plus tard personne ne peut expliquer pourquoi la migration à chaud ne fonctionne que le mardi.

La superpuissance opérationnelle d’Hyper-V est son adéquation aux gouvernances Windows existantes. Sa faiblesse opérationnelle est que le stockage partagé et le réseau de cluster doivent être conçus volontairement.

Sécurité et correctifs : l’ennuyeux gagne

La sécurité n’est pas « activer MFA et considérer le travail fait ». Pour les hyperviseurs, il s’agit surtout d’un patching prévisible, d’une surface d’attaque minimale et d’un auditabilité.

Proxmox

• Base Debian implique un patching Linux classique, plus le packaging Proxmox.
• Gardez les dépôts cohérents entre nœuds ; des dépôts mixtes créent classiquement le chaos de dépendances.
• Verrouillez les interfaces de gestion : VLAN de gestion dédié, règles de pare-feu et pas d’« exposition à Internet pour convenance ».

XCP-ng

• La cadence de patch est simple ; traitez les mises à jour du pool comme une maintenance planifiée.
• L’accès à XO est sensible ; c’est effectivement votre plan de contrôle de virtualisation.

Hyper-V

• Le patching Windows est bien compris ; planifiez une mise à jour compatible cluster ou des workflows équivalents.
• Renforcez la gestion : restreignez RDP, utilisez RBAC quand possible, journalisez PowerShell et les actions admin.

Une idée de fiabilité paraphrasée (attribution incluse) : l’idée paraphrasée — Gene Kranz : « Les opérations réussies viennent de la discipline et de la préparation, pas de l’improvisation. »

Sauvegardes et PRA : la partie que tout le monde regrette plus tard

La hiérarchie de sauvegarde qui fonctionne réellement en PME

• Sauvegardes locales rapides pour des restaurations rapides (minutes à heures).
• Copies hors ligne ou immuables pour survivre aux ransomwares (heures à jours).
• Réplication hors site pour perte de site (jours, mais au moins vous survivez).

Proxmox + PBS

Proxmox Backup Server est l’une des meilleures raisons de choisir Proxmox. Il est conçu pour les sauvegardes de VM avec déduplication et incrémentiels qui rendent les sauvegardes fréquentes possibles sans exploser le stockage.

Que faire : considérez le stockage PBS comme des données de production. Surveillez-le, scrutez-le (si ZFS), et testez les restaurations mensuellement. « Nous avons des sauvegardes » n’est vrai qu’après un test de restauration.

XCP-ng + Xen Orchestra

Le système de sauvegarde de Xen Orchestra est convivial opérationnellement. Vous pouvez exécuter des sauvegardes delta, gérer la rétention et restaurer de manière fiable — si votre dépôt de sauvegarde est assez rapide et que votre politique de rétention n’est pas une décharge.

Que faire : séparez le trafic de sauvegarde, surveillez la performance du dépôt et testez les restaurations avec des contrôles au niveau applicatif.

Sauvegardes Hyper-V

Hyper-V dispose d’une bonne intégration VSS, mais le résultat de la sauvegarde dépend fortement de votre choix d’outil et de votre conception de stockage. De bons produits existent ; il existe aussi des configurations qui ignorent silencieusement des VM tout en envoyant un email « succès ». Vous voulez des journaux de tâches qui rapportent par-VM et un processus qui échoue bruyamment.

Trois mini-histoires du monde de l’entreprise (anonymisées, plausibles, techniquement réelles)

Incident causé par une mauvaise hypothèse : « les snapshots NAS sont des sauvegardes »

Une société de services de taille moyenne est passée d’un hyperviseur legacy à un nouveau cluster brillant. Ils ont utilisé un stockage partagé sur un NAS et se sentaient malins : « Le NAS prend des snapshots horaires. On est couverts. » Les sauvegardes ont été dépriorisées car la migration a déjà consommé budget et patience.

Trois mois plus tard, un ransomware a frappé une station de travail, puis s’est propagé via des partages de fichiers et finalement aux partages invités VM. Les snapshots du NAS existaient, certes — mais le calendrier et la rétention des snapshots étaient conçus pour « oups j’ai supprimé un fichier », pas pour « revenir en arrière d’une semaine d’un dataset activement chiffré ». Plusieurs snapshots étaient déjà pollués et le point propre le plus ancien était hors fenêtre de rétention.

La mauvaise hypothèse n’était pas que les snapshots sont inutiles. C’était de supposer que les snapshots sont des sauvegardes. Les sauvegardes sont isolées, restaurables et vérifiées opérationnellement. Les snapshots sont une fonctionnalité de commodité avec des angles vifs.

Ils ont reconstruit à partir d’exports partiels, récupéré certaines bases depuis des points incohérents et appris une leçon qui aurait pu être un test de restauration trimestriel au lieu d’un incident coûteux.

Une optimisation qui s’est retournée : « activons la déduplication partout »

Une petite entreprise SaaS avec un parc mixte de VM voulait réduire les coûts de stockage. Ils ont activé une déduplication et compression agressives au niveau stockage sans benchmarquer. Les premiers résultats semblaient bons : les graphiques de capacité s’amélioraient, la direction souriait et tout le monde est passé à autre chose.

Puis la latence a grignoté. Pas constante. Par pics. Le genre qui fait râler les serveurs SQL, fait varier les temps de connexion et multiplie les tickets « Internet lent ». Les CPU du stockage avaient la charge de la déduplication et le working set ne se dédupliait pas autant qu’espéré. Pire : l’équipe avait ajouté un dispositif de cache rapide sans protection contre la perte de puissance, parce qu’il « benchmarquait bien ».

Ils ont fini par rétablir la déduplication sur les datasets chauds, garder la compression là où elle aidait et dimensionner le système pour l’I/O réel plutôt que pour des mathématiques de capacité optimistes. L’optimisation n’était pas mauvaise ; elle était non mesurée et appliquée universellement.

Le retour de bâton n’était pas seulement la performance. C’était la confiance opérationnelle. Quand les utilisateurs cessent de faire confiance à la plateforme, tout devient un problème d’hyperviseur — même quand ce ne l’est pas.

Une pratique ennuyeuse mais correcte qui a sauvé la mise : « quorum et fencing ne sont pas optionnels »

Une PME industrielle exploitait un cluster de virtualisation à deux nœuds sur un site distant. Rien de fancy. Ils ont fait quelque chose d’impopulaire : ils ont ajouté un troisième vote de quorum approprié (un petit témoin/service), documenté le modèle de défaillance et validé qu’une perte de nœud déclenchait le comportement attendu. Ils ont aussi configuré le fencing pour qu’un nœud partitionné ne puisse pas continuer d’écrire sur des ressources partagées.

Six mois plus tard, un switch réseau a échoué d’une façon qui a scindé la communication du cluster. Dans beaucoup de PME, c’est là que l’on obtient un split-brain et une corruption des données qui apparaît des semaines plus tard comme des « bizarreries aléatoires de base de données ».

Au lieu de cela, le cluster a pris une décision propre. Un côté avait le quorum et a continué. L’autre côté s’est arrêté. C’était bruyant mais sûr — exactement ce que vous voulez. Ils ont remplacé le switch, ramené le nœud et poursuivi leur activité. Pas de volumes corrompus, pas d’archéologie.

C’est la vérité peu sexy : les pratiques ennuyeuses n’ont pas de super slides, mais elles empêchent les types d’incidents qui ruinent des carrières.

Tâches pratiques avec commandes, sorties et décisions (12+)

Voici les vérifications que j’exécute quand je reprends un cluster, suspecte un goulot d’étranglement ou planifie une migration. Les commandes sont montrées avec des sorties réalistes et ce que vous en déduisez.

1) Proxmox : confirmer la santé du cluster et le quorum

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             smb-cluster
Config Version:   12
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             2025-12-28 10:14:05
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2f
Quorate:          Yes

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

Ce que cela signifie : Vous êtes en quorum. Les votes attendus correspondent aux votes réels. Pas de « 2 nœuds qui se font passer pour du HA ».

Décision : Si Quorate: No ou si les votes ne correspondent pas, cessez de planifier migrations/updates et réparez le quorum d’abord (qdevice, troisième nœud ou stratégie de témoin).

2) Proxmox : vérifier la santé de Ceph (si utilisé)

cr0x@server:~$ ceph -s
  cluster:
    id:     3b1f5e2a-9c1b-4c9b-8f0c-6b2a2a7c9d11
    health: HEALTH_WARN
            1 slow ops, oldest one blocked for 37 sec

  services:
    mon: 3 daemons, quorum pve1,pve2,pve3 (age 4h)
    mgr: pve1(active, since 2h), standbys: pve2
    osd: 9 osds: 9 up (since 3h), 9 in (since 3h)

  data:
    pools:   3 pools, 128 pgs
    usage:   2.1 TiB used, 4.9 TiB / 7.0 TiB avail
    pgs:     128 active+clean

Ce que cela signifie : Les données sont propres, mais vous avez des opérations lentes. C’est généralement la latence : disques, réseau ou OSD occupé.

Décision : N’ignorez pas les slow ops. Vérifiez la latence des OSD et les pertes réseau avant que les utilisateurs ne s’en aperçoivent.

3) Proxmox : santé du pool ZFS et compteurs d’erreurs

cr0x@server:~$ zpool status -v
  pool: rpool
 state: ONLINE
status: Some supported features are not enabled on the pool.
action: Upgrade the pool to enable all features.
  scan: scrub repaired 0B in 00:19:12 with 0 errors on Sun Dec 22 03:10:41 2025
config:

        NAME                                             STATE     READ WRITE CKSUM
        rpool                                            ONLINE       0     0     0
          mirror-0                                       ONLINE       0     0     0
            ata-SAMSUNG_MZ7L3480HBLT-00003_S6H7NX0T12345 ONLINE       0     0     0
            ata-SAMSUNG_MZ7L3480HBLT-00003_S6H7NX0T67890 ONLINE       0     0     0

errors: No known data errors

Ce que cela signifie : Le pool est sain ; les scrubs ont lieu ; aucun indicateur de corruption silencieuse.

Décision : Si vous voyez des CKSUM non nuls ou des erreurs de lecture, investiguez le câblage/HBA/firmware des disques avant d’accuser « l’hyperviseur ».

4) Proxmox : vérifier le risque de thin provisioning (LVM-thin)

cr0x@server:~$ lvs -a -o+seg_monitor,lv_size,data_percent,metadata_percent vg0
  LV                VG  Attr       LSize   Pool     Data%  Meta%  Monitor
  data              vg0 twi-aotz--  <3.64t           88.21  12.44  monitored
  vm-101-disk-0     vg0 Vwi-aotz--  120.00g data     67.02
  vm-102-disk-0     vg0 Vwi-aotz--  200.00g data     91.13

Ce que cela signifie : Votre thin pool est à 88% de remplissage. Au-delà d’environ 90% vous entrez en territoire où les VM peuvent se mettre en pause ou se corrompre si le pool se remplit.

Décision : Étendez le pool, supprimez les vieux snapshots ou migrez les VM. Aussi, définissez des alertes à 70/80/90%.

5) Hôte Linux : trouver rapidement la latence de stockage avec iostat

cr0x@server:~$ iostat -x 1 3
Linux 6.8.12 (pve1)  12/28/2025  _x86_64_  (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.21    0.00    3.44    8.77    0.00   77.58

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz await r_await w_await  svctm  %util
nvme0n1         85.00  220.00  4200.0 18000.0    170.9     2.15   7.90    2.10   10.10   0.38  11.5
sda              1.00   55.00    12.0   820.0     30.9    12.40 220.00   15.00  223.00   2.10  12.0

Ce que cela signifie : sda a 220 ms d’attente sur les écritures. C’est une latence ressentie par les utilisateurs, même si le %util n’est pas maximal.

Décision : Identifiez ce qui est sur sda (journal, cible de sauvegarde, datastore lent) et cessez d’y mettre des workloads d’écriture aléatoires.

6) Proxmox : voir la pression I/O disque par VM

cr0x@server:~$ pvesh get /nodes/pve1/qemu/101/status/current
{
  "cpu": 0.12,
  "diskread": 10485760,
  "diskwrite": 52428800,
  "mem": 3435973836,
  "name": "sql-small",
  "netin": 1048576,
  "netout": 786432,
  "status": "running",
  "uptime": 172800
}

Ce que cela signifie : Cette VM écrit beaucoup plus qu’elle ne lit. Associez cela aux contrôles de latence stockage.

Décision : Si le « voisin bruyant » est évident, déplacez-le sur du stockage plus rapide ou isolez-le sur son propre vdev/LUN.

7) XCP-ng : vérifier l’état du pool et des hôtes

cr0x@server:~$ xe pool-list
uuid ( RO)                : 2c7f6c2c-1b75-4a8b-8a8e-4a1d3d2a2f31
          name-label ( RW): smb-xcp-pool
    name-description ( RW): Primary virtualization pool
              master ( RO): 0a1b2c3d-4e5f-6789-aaaa-bbbbccccdddd

Ce que cela signifie : Vous avez un pool défini et un master. En univers Xen, la santé du master importe pour l’orchestration.

Décision : Si le master est instable, réparez-le avant de faire des upgrades ou des migrations ; les opérations de pool en dépendent.

8) XCP-ng : lister les dépôts de stockage et repérer les « presque pleins » tôt

cr0x@server:~$ xe sr-list params=name-label,uuid,type,physical-size,physical-utilisation
name-label ( RW): iSCSI-SR
uuid ( RO)      : 11111111-2222-3333-4444-555555555555
type ( RO)      : lvmoiscsi
physical-size ( RO): 4398046511104
physical-utilisation ( RO): 4026531840000

Ce que cela signifie : ~4.0 To utilisés sur 4.4 To. C’est dangereusement serré pour les snapshots et la surcharge métadonnée.

Décision : Étendez le SR ou évacuez des VM. Réduisez aussi la rétention des snapshots s’ils servent de machine à remonter le temps.

9) XCP-ng : vérifier l’impact des sauvegardes en repérant la prolifération de snapshots

cr0x@server:~$ xe snapshot-list params=uuid,name-label,creation-time | head
uuid ( RO)         : 9a9a9a9a-1111-2222-3333-444444444444
name-label ( RO)   : xo_backup_delta_101_2025-12-28T02:00:01Z
creation-time ( RO): 2025-12-28 02:00:03Z

Ce que cela signifie : XO a créé des snapshots de sauvegarde. C’est normal — sauf s’ils ne sont pas nettoyés.

Décision : Si les snapshots persistent au-delà de la fenêtre du job, investiguez des sauvegardes bloquées et les performances du dépôt avant que ça ne dégénère.

10) Hyper-V : vérifier le rôle de l’hôte et les VM en cours

cr0x@server:~$ powershell -NoProfile -Command "Get-VM | Select-Object Name,State,Status | Format-Table -AutoSize"
Name             State   Status
----             -----   ------
AD01             Running Operating normally
FILE01           Running Operating normally
SQL01            Running Operating normally
RDSH01           Running Operating normally

Ce que cela signifie : Inventaire de base. Les « Status » problématiques ici se corrèlent souvent avec des problèmes de stockage ou de services d’intégration.

Décision : Si des VM montrent une intégration dégradée, corrigez cela avant de tester migrations ou sauvegardes.

11) Hyper-V : vérifier le quorum du cluster et la santé des nœuds

cr0x@server:~$ powershell -NoProfile -Command "Get-Cluster | Select-Object Name,QuorumArbitrationTimeMax,QuorumType | Format-List"
Name  : SMB-CLUSTER
QuorumArbitrationTimeMax : 60
QuorumType : NodeAndFileShareMajority

Ce que cela signifie : Vous avez un témoin (share) et un modèle de quorum capable de survivre à une perte de nœud.

Décision : Si vous êtes sur un cluster à 2 nœuds sans témoin, ajoutez-en un avant de l’appeler « HA ».

12) Hyper-V : santé des CSV et détection de I/O redirigé

cr0x@server:~$ powershell -NoProfile -Command "Get-ClusterSharedVolume | Select-Object Name,State,OwnerNode | Format-Table -AutoSize"
Name                      State  OwnerNode
----                      -----  ---------
Cluster Disk 1 (CSV)      Online HVNODE1
Cluster Disk 2 (CSV)      Online HVNODE2

Ce que cela signifie : Les CSVs sont en ligne. Mais « en ligne » ne veut pas dire « rapide ». Le I/O redirigé peut toujours vous pénaliser.

Décision : Si vous suspectez du I/O redirigé, vérifiez les événements du cluster et la conception réseau ; le trafic de stockage pourrait faire du hairpinning.

13) Réseau : repérer les mismatches MTU et les pertes sur hôtes Linux

cr0x@server:~$ ip -s link show dev bond0
2: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 3c:ec:ef:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
     9812312312 8123123      0   12450       0  12345
    TX:  bytes packets errors dropped carrier collsns
     8123123123 7123123      0       0       0      0

Ce que cela signifie : Paquets RX perdus sur une liaison de stockage/migration est suspect. Mismatch MTU, tamponnage switch ou congestion.

Décision : N’activez pas les jumbo frames « parce que ça booste » à moins que chaque saut soit cohérent et testé avec du vrai trafic.

14) Proxmox : vérifier que les jobs de sauvegarde se sont réellement exécutés et leur durée

cr0x@server:~$ cat /var/log/pve/tasks/active | head
UPID:pve1:0002A1B3:01A2B3C4:676F6D10:vzdump:101:root@pam:
UPID:pve1:0002A1B4:01A2B3C5:676F6D12:vzdump:102:root@pam:

Ce que cela signifie : Des tâches sont en cours. Corrélez avec les logs de fin pour vous assurer qu’elles se terminent et ne sont pas bloquées.

Décision : Si des tâches traînent ou se chevauchent pendant les heures ouvrées, ajustez les plannings, les limites de bande passante et le débit du stockage.

Mode opératoire de diagnostic rapide

Voici la séquence « arrêter de deviner » quand les utilisateurs se plaignent que « tout est lent » ou quand les migrations/sauvegardes tournent au ralenti. L’objectif est de trouver le goulot en minutes, pas en heures.

Première étape : est-ce la latence de stockage, la contention CPU ou des pertes réseau ?

• Latence stockage : lancez iostat -x sur les hôtes ; vérifiez les tableaux de bord de stockage de l’hyperviseur ; recherchez un await élevé, la profondeur de file et la saturation.
• Contention CPU : vérifiez les symptômes de steal/ready CPU (selon la plate-forme) ; confirmez que vous n’avez pas surcommitté outrageusement sur une machine avec une charge d’interrupt élevée.
• Pertes réseau : regardez les compteurs de drops d’interface et les erreurs de port switch ; confirmez la cohérence MTU sur les réseaux de stockage/migration.

Deuxième étape : isoler le voisin bruyant

• Identifiez les VM avec des taux d’écriture élevés (bases de données, logging, proxys de sauvegarde).
• Recherchez les chaînes de snapshots et les thin pools proches du plein.
• Confirmez que les sauvegardes ne martèlent pas le stockage de production pendant les pics.

Troisième étape : confirmez que le plan de contrôle ne vous ment pas

• Cluster/quorum : si le quorum est instable, tout le reste devient étrange.
• Synchronisation temporelle : la dérive horaire casse TLS, l’auth et la logique de cluster de façon créative.
• Journaux d’événements : cherchez des flap de chemins de stockage, des défaillances multipath, du I/O redirigé CSV ou des slow ops Ceph.

Quatrième étape : décider de l’action corrective

• Si la latence stockage est élevée : déplacez les VM chaudes, corrigez la sécurité du cache, ajoutez des miroirs ou améliorez le réseau de stockage.
• Si pertes réseau : corrigez MTU/flow control/bonding, mettez à jour firmware/drivers NIC ou repensez la séparation VLAN.
• Si les sauvegardes posent problème : ajoutez un datastore/repo de sauvegarde dédié, limitez le débit des jobs ou échelonnez les plannings.

Erreurs courantes : symptômes → cause racine → correction

1) VM se mettent en pause ou le stockage devient lecture seule sous charge

Symptômes : VM figées, erreurs I/O, système de fichiers soudainement « lecture seule », thin pools en panique.

Cause racine : pool de thin provisioning rempli (LVM-thin, SR surcommis, Ceph nearfull), ou un datastore atteint 100%.

Correction : Définissez des seuils d’alerte stricts ; étendez le stockage avant 80–85% ; réduisez la rétention des snapshots ; déplacez les gros disques hors des thin pools sauf si surveillés.

2) La migration à chaud échoue aléatoirement

Symptômes : Parfois ça marche, parfois ça time-out ; vitesse de migration incohérente.

Cause racine : le réseau de migration partage la bande passante avec du trafic production, mismatch MTU, ou problèmes DNS/temps dans le plan de contrôle.

Correction : VLAN/NIC dédiés pour la migration ; vérifiez MTU bout en bout ; assurez une résolution de noms stable et une synchronisation temporelle.

3) Les sauvegardes réussissent mais les restaurations sont cassées

Symptômes : La restauration démarre mais l’application est corrompue ; AD ou SQL se plaint ; les sauvegardes « réussies » ne contiennent pas de données cohérentes.

Cause racine : pas de snapshots cohérents applicatifs (VSS ne fonctionne pas), chaînes de snapshots trop longues ou outils d’intégration invités mal configurés.

Correction : Validez les outils invités ; testez les writers VSS ; effectuez des drills de restauration mensuels avec vérifications applicatives, pas seulement « ça a booté ».

4) Performance Ceph médiocre malgré des disques rapides

Symptômes : slow ops, latence incohérente, clients ressentent des blocages aléatoires.

Cause racine : réseau sous-dimensionné (pas de redondance, bande passante insuffisante), ou layout OSD non adapté aux types de disques ; recovery en compétition avec la production.

Correction : Séparez les réseaux Ceph si approprié ; assurez 10/25GbE en base ; tunez recovery/backfill ; évitez de mélanger OSD HDD lents avec des pools VM sensibles à la latence.

5) Le cluster Hyper-V « fonctionne » mais les performances sont affreuses

Symptômes : CSVs en ligne, mais VM saccadent ; latences stockage pendant basculement ou sauvegarde.

Cause racine : problèmes de chemin de stockage partagé, I/O redirigé CSV dû à des soucis réseau/stockage, ou réseau SMB3/iSCSI mal conçu.

Correction : Validez le multipath ; séparez les réseaux de stockage ; vérifiez les événements de cluster ; confirmez que le stockage supporte la charge (pas seulement « c’est un NAS »).

6) « Lenteur mystérieuse » ZFS après ajout d’un dispositif cache

Symptômes : Stalls occasionnels, pics de latence bizarres, parfois après des événements d’alimentation.

Cause racine : mauvais usage du SLOG/L2ARC ou SSD sans protection PLP utilisé là où la durabilité d’écriture compte.

Correction : N’utilisez un SLOG que pour l’accélération des écritures synchrones avec protection contre la perte d’alimentation ; benchmarquez et validez ; n’appliquez pas des réglages ZFS en mode cargo-cult.

Listes de vérification / plan étape par étape

Une carte de décision pratique pour PME

1. Inventoriez les compétences du personnel. Si personne ne peut dépanner le réseau ou le stockage Linux, Proxmox/XCP-ng restent possibles — mais budgétez formation/support.
2. Définissez votre objectif HA. Cherchez-vous « l’hôte peut mourir et les VM redémarrent » ou « zéro downtime » ? Les PME ont généralement besoin du premier.
3. Choisissez votre stratégie de stockage.
   • Un hôte : ZFS local sur Proxmox est difficile à battre.
   • Deux hôtes : prudence — risques de quorum et split brain. Ajoutez un témoin/qdevice.
   • Trois+ hôtes : le clustering devient sensé ; Ceph devient plausible si le réseau est solide.
   • SAN existant : n’importe lequel des trois peut fonctionner ; la question devient l’outillage ops et l’intégration sauvegarde.
4. Choisissez votre plateforme de sauvegarde. Proxmox+PBS est un excellent défaut ; XCP-ng+XO est solide ; Hyper-V dépend de l’outil choisi et de la discipline processus.
5. Faites un pilote de migration. Une VM Windows, une VM Linux, une VM « douloureuse » (base de données ou I/O élevé). Mesurez, ne devinez pas.

Plan de migration qui n’engendre pas un mois de chaos

1. Construisez de nouveaux hôtes avec un réseau de gestion propre. Séparez la mgmt du trafic VM quand c’est possible.
2. Décidez la topologie de stockage à l’avance. Miroirs vs RAIDZ, design CSV, conception SR, emplacement du dépôt de sauvegarde.
3. Mettez en place la supervision avant le basculement en production. Latence stockage, capacité des pools, succès des sauvegardes, pression mémoire des hôtes.
4. Faites des tests de restauration pendant le pilote. Une restauration de fichier, une restauration complète de VM, une restauration cohérente applicative.
5. Déplacez d’abord des VM à faible risque. Puis les moyennes. Gardez l’appliance fournisseur étrange pour quand vous aurez du temps et du café.
6. Documentez le modèle de défaillance. Que se passe-t-il si un hôte meurt ? Qui est appelé ? Quels sont les RTO/RPO ?
7. Cadence de patchs et contrôle des changements. Définissez une fenêtre mensuelle. Respectez-la. « On ne patch jamais » n’est pas stabilité ; c’est une panne différée.

Checklist d’hygiène opérationnelle (mensuelle)

• Vérifier le quorum et l’appartenance au cluster.
• Contrôler l’espace libre des datastores/pools et la tendance de croissance.
• Revoir les logs des jobs de sauvegarde pour le succès par VM et la dérive de durée.
• Effectuer au moins un test de restauration avec vérification applicative.
• Revoir les snapshots : âge, nombre et objectif.
• Vérifier les compteurs d’erreurs/drops NIC et la santé des ports switch.
• Confirmer la synchronisation temporelle sur les hôtes et VM critiques.

FAQ

1) Quelle est la meilleure alternative à ESXi pour une PME typique avec 2–4 hôtes ?

Proxmox est le meilleur défaut si vous pouvez exploiter Linux de façon compétente. Pour une sensation plus appliance, XCP-ng avec Xen Orchestra est un très bon second. Hyper-V l’emporte si vous êtes Windows-first et gérez déjà bien le clustering.

2) Proxmox est-il « de niveau entreprise » ou juste pour homelab ?

C’est capable d’entreprise. La question est de savoir si vos opérations sont de niveau entreprise : patching, monitoring, sauvegardes et contrôle des changements. Proxmox ne vous empêchera pas de faire des erreurs créatives.

3) Les PME doivent-elles utiliser Ceph ?

Seulement si vous avez suffisamment de nœuds, une bande passante/réseau redondant correct et l’appétit pour opérer du stockage distribué. Si vous faites 2 nœuds et une prière, restez sur ZFS local plus réplication/sauvegardes.

4) XCP-ng est-il plus difficile à exploiter que Proxmox ?

Pas nécessairement. Les hôtes XCP-ng sont assez appliance-like, et Xen Orchestra offre un flux propre. Proxmox vous donne plus de flexibilité « native Linux », ce qui peut être plus simple ou plus difficile selon votre équipe.

5) Hyper-V peut-il gérer correctement les charges Linux ?

Oui, surtout les distributions modernes avec les composants d’intégration. Mais si votre parc est majoritairement Linux et axé stockage, Proxmox a tendance à être un ajustement opérationnel plus naturel.

6) Quel est le mode de défaillance stockage le plus courant en virtualisation PME ?

Faire fonctionner le stockage trop plein — thin pools, SRs, datastores — jusqu’à ce que quelque chose atteigne 100%. La performance se dégrade d’abord, puis vous observez pauses, erreurs ou état corrompu. La surveillance de capacité n’est pas optionnelle.

7) Ai-je vraiment besoin d’un serveur/repository de sauvegarde dédié ?

Vous avez besoin d’une cible de sauvegarde qui ne meurt pas avec l’hyperviseur et idéalement qui ne sera pas chiffrée avec le reste de l’environnement. Cela signifie souvent un serveur séparé ou un dépôt durci, pas « un share sur le même NAS ».

8) Quelle est la HA la plus simple qui soit réellement sûre ?

Un cluster à 3 nœuds (ou 2 nœuds plus un témoin/qdevice approprié) avec un comportement de quorum clair, des tests de basculement et des sauvegardes restaurables. Tout le reste est une démo, pas un système.

9) Comment garder les coûts raisonnables tout en améliorant la fiabilité ?

Dépensez sur les éléments ennuyeux : RAM ECC, SSDs en miroir, switches redondants (ou au moins chemins redondants) et une cible de sauvegarde avec immutabilité/offline. Ne surpayez pas pour des fonctionnalités que vous n’allez pas exploiter.

Étapes suivantes que vous pouvez exécuter

1. Choisissez votre gagnant en fonction de la réalité du personnel : Proxmox pour les équipes compétentes Linux, XCP-ng+XO pour une opération appliance-like, Hyper-V pour les organisations Windows-first.
2. Rédigez votre modèle de défaillance (perte d’hôte, perte de switch, perte de stockage) et assurez-vous que le design quorum/témoin y correspond.
3. Construisez un pilote avec des VM représentatives et mesurez la latence stockage, la durée des sauvegardes et la réussite des restaurations.
4. Implémentez la supervision et les alertes pour la capacité, la latence et le succès des sauvegardes avant de migrer tout.
5. Planifiez des tests de restauration mensuels et traitez les échecs comme des incidents de production — parce que c’en sont, juste différés.

Si vous voulez une règle simple : choisissez la plateforme que votre équipe peut exploiter en confiance à 2 h du matin. Le meilleur hyperviseur est celui que vous pouvez réparer sous pression sans improviser jusqu’à une panne plus grave.