Lorsque vous mettez à jour des objets vSphere dans un cluster dans lequel vSphere Distributed Resource Scheduler (DRS), vSphere High Availability (HA) et vSphere Fault Tolerance (FT) sont activés, vous pouvez temporairement désactiver vSphere Distributed Power Management (DPM), le contrôle d'accès HA et FT pour le cluster entier. Une fois la mise à jour effectuée, Update Manager restaure ces fonctions.

Les mises à jour peuvent nécessiter que l'hôte passe en mode de maintenance au cours de la correction. Les machines virtuelles ne peuvent pas fonctionner lorsqu'un hôte est en mode de maintenance. Pour assurer la disponibilité, vCenter Server peut migrer les machines virtuelles vers d'autres hôtes ESXi dans un cluster avant que l'hôte passe en mode de maintenance. vCenter Server migre les machines virtuelles si le cluster est configuré pour vSphere vMotion et si DRS est activé.

Si un hôte n'a pas de machines virtuelles actives, VMware DPM peut placer l'hôte en mode veille et interrompre une opération Update Manager. Pour garantir que l'analyse et le transfert sont effectués correctement, Update Manager désactive DPM pendant ces opérations. Pour que la correction soit effectuée correctement, autorisez Update Manager à désactiver DPM et le contrôle d'admission HA avant l'opération de correction. Une fois l'opération effectuée, Update Manager restaure DPM et le contrôle d'admission HA. Update Manager désactive le contrôle d'admission HA avant le transfert et la correction, mais pas avant l'analyse.

Si DPM a déjà placé les hôtes en mode veille, Update Manager met sous tension les hôtes avant l'analyse, le transfert et la correction. Une fois l'analyse, le transfert ou la correction réalisés, Update Manager active DPM et le contrôle d'admission HA et laisse DPM mettre les hôtes en mode veille, si nécessaire. Update Manager ne corrige pas les hôtes hors tension.

Si les hôtes sont en mode veille et que vous activez manuellement DPM, Update Manager ne corrige pas les hôtes, ni ne les met sous tension.

Au sein d'un cluster, désactivez temporairement le contrôle d'admission HA pour autoriser vSphere vMotion à poursuivre. Cette action empêche l'arrêt des machines sur les hôtes que vous corrigez. Après la correction de l'ensemble du cluster, Update Manager restaure les paramètres de contrôle d'admission HA.

Si la tolérance de panne est activée pour les machines virtuelles sur les hôtes du cluster, vous devez la désactiver temporairement avant toute opération Update Manager dans le cluster. Si elle est activée pour les machines virtuelles sur un hôte, Update Manager ne corrige pas l'hôte. Corrigez tous les hôtes dans un cluster avec les mêmes mises à jour, pour que la tolérance de panne puisse être réactivée après la correction. Une machine virtuelle principale et une machine virtuelle secondaire ne peuvent pas résider sur des hôtes dont la version d'ESXi ou le niveau de correctif est différent.

Lorsque vous corrigez les hôtes appartenant à un cluster Virtual SAN, vous devez tenir compte du comportement suivant :

  • Le processus de correction d'un hôte peut être très long à s'exécuter.

  • De part sa conception même, un seul hôte d'un cluster Virtual SAN peut être en mode de maintenance à la fois.

  • Update Manager corrige les hôtes faisant partie d'un cluster Virtual SAN de manière séquentielle même si vous définissez l'option permettant de corriger les hôtes en parallèle.

  • Si un hôte est un membre d'un cluster Virtual SAN et si l'une des machines virtuelles sur l'hôte utilise une stratégie de stockage de machine virtuelle avec pour paramètre « Nombre d'échecs à tolérer=0 », l'hôte risque de présenter des retards inhabituels en entrant en mode de maintenance. Ces retards se produisent du fait que Virtual SAN doit migrer les données de la machine virtuelle d'un disque vers un autre dans le cluster de la banque de données Virtual SAN. Les retards peuvent durer plusieurs heures. Vous pouvez contourner ce problème en définissant le paramètre « Nombre d'échecs à tolérer=1 » pour la stratégie de stockage de machine virtuelle, ce qui entraîne la création de deux copies de fichiers de la machine virtuelle dans la banque de données Virtual SAN.