Aller au contenu
6 minutes

HA sur AHV : best effort ou réservation garantie, et qui redémarre en premier

Par défaut, AHV relance ce qu’il peut après la perte d’un hôte. Le mode garanti réserve de la mémoire et filtre chaque démarrage de VM. Taille de la réserve, chronologie d’une panne, ordre de redémarrage.

HA sur AHV : best effort ou réservation garantie, et qui redémarre en premier

Quand un hôte AHV tombe, ses VM redémarrent ailleurs, s’il reste de la place. Le mode par défaut ne la garantit pas ; le mode garanti la réserve, et le fait payer à chaque démarrage de VM.

Deux modes

La Nutanix Bible décrit deux modes de VM High Availability (VMHA) :

  • Default (best effort) : actif dès l’installation, sans réserve : « Not all of the failed VMs restart if the remaining hosts do not have sufficient resources. »
  • Guarantee : non activé par défaut, il réserve de la place sur les hôtes pour que toutes les VM d’un hôte en panne redémarrent. Il s’active par la case Enable HA, qui affiche ensuite la mémoire réservée et le nombre de pannes d’hôte tolérées.

Ce que le cluster réserve

La réserve suit le replication factor des containers (Bible) : l’équivalent d’un hôte si tous sont en RF2 (FT1), de deux hôtes si au moins un est en RF3 (FT2). Avec des hôtes de mémoire inégale, elle se calcule sur le plus gros. Un seul container RF3 double donc la réserve (RF2, RF3 ; dimensionnement dans la simulation de capacité).

Avant AOS 5.0, on pouvait réserver des hôtes entiers ou des segments. Depuis, seuls les segments existent, appliqués automatiquement en mode Guarantee : la réserve est répartie sur tous les hôtes (réglage interne kAcropolisHAReserveSegments).

Selon un employé Nutanix (forum, 2021), avec des containers en RF2, la protection contre deux pannes d’hôte se règle en aCLI depuis une CVM :

acli ha.update num_host_failures_to_tolerate=<N>

Le contrôle d’admission

En mode garanti, avant de démarrer une VM, le cluster vérifie (Bible) :

  • qu’elle peut tourner sur l’hôte cible et sur au moins un autre hôte ;
  • que toutes les VM en cours pourraient tourner ailleurs si un hôte disparaissait ;
  • en tenant compte des règles d’affinité et des contraintes GPU.

Pendant ce calcul, le cluster ne démarre aucune autre VM et refuse les migrations à chaud. Un démarrage refusé alors que Prism montre de la RAM libre peut venir de la réserve, pas d’une panne.

Le rôle d’ADS et le cas des VM épinglées à un hôte sont traités dans affinité, HA et ADS.

Chronologie d’une panne

Le leader Acropolis échange une communication par seconde avec le libvirtd de chaque hôte. Pour un hôte perdu, la Bible donne :

  • T0 : perte de connexion avec le libvirtd de l’hôte ;
  • T20 : début d’un délai de 40 secondes ;
  • T60 : Stargate bloque les I/O venant de cet hôte ;
  • T120 : le leader lance le redémarrage des VM sur les hôtes disponibles.

Un hôte isolé du réseau peut garder ses VM, mais elles s’arrêtent 45 secondes après la première erreur d’I/O, pour éviter deux copies d’une même VM. Au retour de l’hôte, ses VM y reviennent par migration, pour la data locality (employé Nutanix, 2021).

Qui redémarre, et dans quel ordre

Une VM peut être exclue de VMHA : retirée du calcul, elle n’est pas relancée sur un autre hôte et redémarre au retour du sien (employé Nutanix, 2021).

acli vm.update <VM> ha_priority=-1

Pour l’ordre, le blog Nutanix (billets NCI 7.5 et AHV, décembre 2025) annonce la VM Startup Policy d’AHV : des chaînes de dépendances appliquées après un événement HA ou un redémarrage de cluster. Le billet AHV constate que, sans elle, les VM reviennent « without any defined order ».

Selon un blog personnel (Taylor Norris), la politique se crée dans Prism Central à partir de catégories, et chaque étape attend la mise sous tension ou le démarrage de l’OS signalé par NGT ; les VM sans politique démarrent ensuite, sans ordre. Vérifiez sur votre version.

Ce qu’il faut retenir

  • Par défaut, HA relance ce qu’il peut : sans réserve, des VM peuvent rester éteintes.
  • Le mode garanti réserve en segments un hôte en RF2, deux si un container est en RF3, calculés sur le plus gros hôte.
  • Comptez environ 120 secondes dans le scénario d’hôte injoignable décrit par la Bible.
  • Sans VM Startup Policy (NCI 7.5), aucun ordre de redémarrage n’est garanti.

In English

By default, AHV restarts what it can after losing a host. Guaranteed mode reserves memory and screens every VM start. Reserve size, failure timeline and restart order: the reserve equals one host if all containers are RF2 and two if one is RF3, and without VM Startup Policy, VMs restarted by HA come back in no defined order.

Sources & vérification

Relevé sur : Documentation publique Nutanix (Nutanix Bible, blog Nutanix, Nutanix Community) et blog personnel, relevé 2026-10

Comment les billets sont vérifiés et corrigés