Pour redémarrer des VM après la perte d'un serveur, Proxmox HA est une alternative à VMware HA. Le projet change de nature lorsque la production s'appuie aussi sur la surveillance des OS invités, une réserve de capacité imposée ou des dépendances de redémarrage. Ces protections doivent être examinées une par une.
Un cluster utilisant essentiellement la reprise après panne matérielle peut donc trouver dans Proxmox une réponse adaptée. Une plateforme qui exploite les automatismes avancés de vSphere HA demande davantage de travail d'architecture. Cette différence compte dans le coût, le calendrier et les procédures de la migration.
Cet épisode de la série VMware Exit prend pour références vSphere HA 8.x et Proxmox VE 9.2, avec les précisions documentaires en fin d'article. Il compare la reprise par redémarrage ; VMware Fault Tolerance et la continuité applicative sans interruption restent hors de ce périmètre.
Ce qui se transpose, ce qui change
| Protection | VMware vSphere HA | Proxmox HA |
|---|---|---|
| Perte d'un hôte | Redémarrage des VM protégées | Reprise des ressources inscrites dans HA |
| Isolement du cluster | Réponse configurable pour les VM | Quorum et auto-fencing du nœud |
| OS invité figé | VM Monitoring, si activé | Pas de reprise équivalente par le seul contrôle HA |
| Réserve de secours | Admission Control | Marge à maintenir par dimensionnement et exploitation |
| Ordre de reprise | Priorités et dépendances entre groupes | Affinités de placement, sans équivalent au même séquencement |
| Perte des chemins de stockage | Politiques VMCP APD/PDL | Comportement lié au stockage et à l'état de la ressource |
Le point décisif est l'usage réel de ces fonctions. Une option VMware disponible mais désactivée ne représente pas une protection à reconstruire.
Un serveur s'éteint : les deux plateformes savent reprendre les VM
Prenons un cas simple : trois hôtes, des disques accessibles depuis les survivants et assez de capacité pour absorber la panne. Un serveur s'éteint brutalement. Les VM qu'il exécutait s'arrêtent avec lui.
vSphere HA s'appuie sur les agents FDM présents dans les ESXi. Un agent primaire coordonne la protection et demande le redémarrage des VM sur les hôtes survivants. Dans Proxmox, le gestionnaire HA du cluster prend la décision et les gestionnaires locaux exécutent les actions. La reprise attend que l'état de l'ancien nœud soit sécurisé pour éviter une double exécution.
Le service rendu est comparable : les VM protégées peuvent repartir ailleurs sans attendre la réparation du serveur. Leur mémoire perdue n'est pas récupérée. Le système invité redémarre, puis l'application reprend son activité, avec les éventuelles opérations de récupération de sa base de données.
L'inscription dans le périmètre protégé mérite toutefois une attention différente. Dans vSphere, HA protège les VM du cluster selon ses paramètres et exceptions. Dans Proxmox, les VM et conteneurs doivent être explicitement confiés au gestionnaire HA. Ajouter un hôte au cluster ne protège pas automatiquement toutes les charges qu'il héberge.
Pour une entreprise dont le besoin se limite à cette reprise, Proxmox couvre donc la fonction essentielle. La disponibilité des disques, la cohérence du réseau et la capacité restante restent des conditions communes aux deux architectures. La migration à chaud pendant une maintenance relève d'un autre mécanisme.
L'hôte reste allumé mais perd le cluster : la coupure peut être plus large
Considérons maintenant une autre panne : un hôte perd ses communications avec le cluster, tandis que ses VM disposent encore de leurs disques et de leur réseau applicatif. Leurs utilisateurs peuvent continuer à travailler pendant que les hyperviseurs perdent leur coordination.
VMware HA dispose de plusieurs signaux : échanges réseau FDM, heartbeats datastore lorsque cette voie existe, et adresses de détection d'isolement. La réponse à l'isolement peut laisser les VM allumées, les éteindre ou tenter leur arrêt avant reprise, selon la configuration. La disparition d'un signal réseau n'impose donc pas systématiquement un redémarrage de l'ESXi.
Proxmox utilise le quorum Corosync pour autoriser les décisions du cluster. Lorsqu'un nœud perd ce quorum avec des ressources HA actives, le mécanisme de watchdog peut provoquer son auto-fencing : c'est alors le serveur entier qui redémarre.
Cette portée change l'incident. Des VM non gérées par HA, présentes sur le même hôte, s'arrêtent elles aussi ; leur reprise automatique ailleurs n'est pas assurée. La continuité du réseau applicatif ne suffit pas à les préserver de cette réinitialisation.
Les choix faits sur VMware pour une situation d'isolement doivent donc être repris dans la conception Proxmox. Cela concerne les chemins Corosync et le placement des charges protégées et non protégées. Sur un cluster à deux nœuds, un QDevice peut fournir un vote externe pour l'arbitrage. Il n'apporte ni copie des disques ni capacité de calcul supplémentaire.
Ce scénario est illustratif, comme le précédent. Il montre une différence d'architecture, sans revendiquer un incident client ou un délai de reprise mesuré.
Une VM « en marche » peut avoir un OS bloqué
Le périmètre de surveillance est un autre écart concret. Avec VM Monitoring activé, VMware peut exploiter les heartbeats VMware Tools et l'activité d'entrées/sorties pour décider de réinitialiser une VM dont l'OS ne répond plus. Le serveur physique peut être parfaitement sain.
Le contrôle HA Proxmox de la VM vérifie son état d'exécution côté hyperviseur. L'implémentation publiée ne teste pas la santé du service métier ou de l'OS invité. Il en découle qu'un invité figé dont le processus QEMU reste considéré comme actif peut ne déclencher aucune action HA.
Une supervision externe ou un mécanisme dans l'invité peut compléter cette protection. L'installation de QEMU Guest Agent ne recrée pas, à elle seule, la politique VM Monitoring de VMware.
L'enjeu pour la migration est précis : si VM Monitoring participe aujourd'hui à la reprise de vos applications, il faut décider comment conserver cette couverture. Si cette option est désactivée, le besoin est différent. Dans les deux cas, vérifier la santé d'un OS ne prouve pas qu'une transaction métier aboutit.
Une réserve de capacité et un ordre de reprise peuvent disparaître sans bruit
Admission Control et les dépendances de redémarrage sont moins visibles qu'une panne d'hôte. Leur absence peut pourtant se révéler au premier incident.
Admission Control peut empêcher une mise sous tension qui compromettrait la réserve de bascule VMware, selon la politique et les réservations configurées. CRS, dans Proxmox, choisit le placement et peut équilibrer les ressources ; cette fonction ne constitue pas une réserve N+1 imposée lors de l'admission de nouvelles charges. Le Dynamic Load Balancer introduit dans VE 9.2 ne change pas cette distinction.
Un cluster peut ainsi accueillir ses VM en fonctionnement normal puis manquer de RAM sur les hôtes de reprise. La marge doit être maintenue par des règles de capacité et revue quand le parc évolue.
Le séquencement pose une question différente. VMware HA permet de définir des priorités et des dépendances entre groupes de VM, avec des conditions comme la détection de heartbeats invités. Les affinités Proxmox déterminent où les ressources fonctionnent ; elles ne signifient pas qu'une application attendra sa base de données.
La documentation Proxmox précise aussi que les VM gérées par HA ne suivent pas le Boot Order classique. Renseigner cet ordre ne reprend donc pas la chaîne de dépendances VMware. Pour une application à plusieurs étages, les services doivent tolérer l'indisponibilité temporaire de leurs dépendances, ou une orchestration doit assurer leur reprise.
Même sur VMware, un heartbeat invité ne garantit pas qu'une base accepte déjà les connexions. La disponibilité applicative reste une exigence à traiter au-delà du démarrage des VM.
Si les disques deviennent inaccessibles, HA ne suffit pas
VMware propose VM Component Protection, ou VMCP, pour appliquer des réponses aux pertes de chemins de stockage : APD, lorsque tous les chemins sont indisponibles, et PDL, lorsque la perte du périphérique est déclarée permanente. Les modes APD conservateur et agressif encadrent différemment la décision d'arrêter une VM pour tenter sa reprise.
Proxmox HA ne transpose pas directement ces politiques. Il peut traiter un échec de démarrage ou une ressource détectée comme arrêtée, puis essayer un autre nœud. Une VM toujours considérée comme active et bloquée sur des E/S peut rester hors de ce cas.
Une perte de stockage sans perte de quorum ne déclenche donc pas nécessairement le fencing ni la reprise attendue. Le type de stockage, la redondance des chemins et la manifestation de la panne déterminent aussi le résultat. Un prochain épisode de la série VMware Exit comparera vSAN et Ceph pour approfondir cette couche de protection.
Ce que cela signifie pour votre sortie de VMware
Proxmox HA est un choix cohérent lorsque l'objectif est de retrouver une reprise automatique après panne d'hôte sur une architecture correctement dimensionnée. Il couvre également les conteneurs Linux gérés par Proxmox. Pour ce périmètre, la présence de fonctions supplémentaires dans VMware ne suffit pas à écarter la cible.
Lorsque la production dépend de VM Monitoring, d'Admission Control, de VMCP ou de règles de reprise entre applications, ces écarts doivent entrer dans le projet et son chiffrage. Une adaptation peut être raisonnable ; elle doit avoir un propriétaire et une place dans l'exploitation future.
Vous préparez une migration vers Proxmox ? VSHIFT Solutions vous accompagne pour identifier les protections HA à conserver et valider leur reprise sur l'architecture cible.
Échanger sur votre architecture →
Références et limites de la comparaison
Analyse documentaire au 15 octobre 2026, sans benchmark de temps de reprise. Le périmètre VMware est vSphere HA 8.x ; certaines fiches couvrent aussi les versions 7.x ou l'architecture FDM de VCF 9.0. La référence Proxmox est VE 9.2, avec la documentation du projet en version 9.2.13. Les liens du projet ci-dessous figent les révisions consultées ; les fonctions et leurs réglages restent à rapprocher des versions installées.
- Broadcom : agents FDM, pannes et isolement, VM Monitoring.
- Broadcom : Admission Control, dépendances de redémarrage, politiques VMCP.
- Proxmox : gestionnaire HA et fencing, Boot Order, quorum et QDevice.
- Proxmox : contrôle d'état de la VM dans le gestionnaire HA 5.2.5, équilibrage dynamique de VE 9.2.