Faire face aux pannes de machines
Important :
La mise à jour cumulative 1 de Citrix Hypervisor 8.2 prend fin le 25 juin 2025. Planifiez votre mise à niveau vers XenServer 8 dès maintenant pour assurer une transition en douceur et un support continu. Pour plus d’informations, consultez Mise à niveau.
Si vous utilisez vos fichiers de licence Citrix Virtual Apps and Desktops pour obtenir une licence pour vos hôtes Citrix Hypervisor 8.2 Cumulative Update 1, ces fichiers de licence ne sont pas compatibles avec XenServer 8. Avant la mise à niveau, vous devez acquérir les fichiers de licence socket XenServer Premium Edition à utiliser avec XenServer 8. Ces fichiers de licence de socket sont disponibles en tant que droits des abonnements Citrix pour le cloud privé, Citrix Universal Hybrid Multi-Cloud, Citrix Universal MSP et Citrix Platform License pour l’exécution de vos charges de travail Citrix. Les clients Citrix qui n’ont pas encore migré vers ces nouveaux abonnements peuvent demander à participer à une promotion gratuite pour 10 000 licences de sockets XenServer Premium Edition. Pour plus d’informations, consultez XenServer.
Si vous n’obtenez pas de licence compatible pour XenServer 8 avant la mise à niveau, lorsque vous mettez à niveau vos hôtes, ils reviennent à l’édition d’essai de 90 jours. L’édition d’essai offre les mêmes fonctionnalités que l’édition Premium, avec quelques limitations. Pour plus d’informations, consultez Présentation des licences XenServer 8.
Cette section fournit des détails sur la procédure de récupération à partir de divers scénarios d’échec. Tous les scénarios de récupération après échec nécessitent l’utilisation d’un ou de plusieurs des types de sauvegarde répertoriés dans Sauvegarde.
Défaillances des membres
En l’absence de haute disponibilité, les nœuds maîtres détectent les défaillances des membres en recevant régulièrement des messages de pulsation. Si aucun battement de cœur n’a été reçu pendant 600 secondes, le maître suppose que le membre est mort. Il existe deux façons de se remettre de ce problème :
-
Réparez l’hôte mort (par exemple, en le redémarrant physiquement). Lorsque la connexion au membre est rétablie, le maître marque le membre comme étant à nouveau vivant.
-
Arrêtez l’hôte et demandez au maître d’oublier le nœud membre à l’aide de la commande
xe host-forgetCI. Une fois le membre oublié, toutes les machines virtuelles qui s’y exécutaient sont marquées comme hors ligne et peuvent être redémarrées sur d’autres serveurs Citrix Hypervisor.Il est important de s’assurer que le serveur Citrix Hypervisor est réellement hors ligne, sinon la corruption des données de la machine virtuelle peut se produire.
N’avez pas à diviser votre pool en plusieurs pools d’un seul hôte en utilisant
xe host-forget. Cette action peut les amener tous à mapper le même stockage partagé et à corrompre les données de la machine virtuelle.
Avertissement :
- Si vous comptez à nouveau utiliser l’hôte oublié en tant qu’hôte actif, effectuez une nouvelle installation du logiciel Citrix Hypervisor.
- Ne pas utiliser
xe host-forgetsi HA est activé sur le pool. Désactivez d’abord HA, puis oubliez l’hôte, puis réactivez HA.
Lorsqu’un serveur Citrix Hypervisor membre échoue, il se peut que des machines virtuelles soient encore enregistrées dans le course état. Si vous êtes sûr que le serveur Citrix Hypervisor membre est définitivement en panne, utilisez l’option xe vm-reset-powerstate CLI pour définir l’état d’alimentation des machines virtuelles sur Arrêté. Voir vm-reset-powerstate pour plus de détails.
Avertissement :
Une utilisation incorrecte de cette commande peut entraîner une corruption des données. N’utilisez cette commande que si nécessaire.
Avant de pouvoir démarrer des machines virtuelles sur un autre serveur Citrix Hypervisor, vous devez également libérer les verrous sur le stockage des machines virtuelles. Seul un hôte à la fois peut utiliser chaque disque dans un SR. Il est essentiel de rendre le disque accessible aux autres serveurs Citrix Hypervisor une fois qu’un hôte a échoué. Pour ce faire, exécutez le script suivant sur le maître de pool pour chaque SR contenant les disques de toutes les machines virtuelles affectées : /opt/xensource/sm/resetvdis.py host_UUID SR_UUID maître
Vous n’avez besoin de fournir la troisième chaîne (« master ») que si l’hôte défaillant était le maître SR au moment de l’incident. (Le maître SR est le maître de pool ou un serveur d’hyperviseur Citrix utilisant le stockage local.)
Avertissement :
Assurez-vous que l’hôte est en panne avant d’exécuter cette commande. Une utilisation incorrecte de cette commande peut entraîner une corruption des données.
Si vous tentez de démarrer une machine virtuelle sur un autre serveur Citrix Hypervisor avant d’exécuter le resetvdis.py script, puis vous recevez le message d’erreur suivant : VDI <UUID> RW déjà attaché.
Défaillances du maître
Chaque membre d’un pool de ressources contient toutes les informations nécessaires pour reprendre le rôle de maître si nécessaire. Lorsqu’un nœud maître échoue, la séquence d’événements suivante se produit :
-
Si HA est activé, un autre maître est automatiquement élu.
-
Si HA n’est pas activé, chaque membre attend le retour du maître.
Si le maître remonte à ce stade, il rétablit la communication avec ses membres et le fonctionnement revient à la normale.
Si le maître est mort, choisissez l’un des membres et exécutez la commande xe pool-emergency-transition-to-master dessus. Une fois qu’il est devenu le maître, exécutez la commande xe pool-recover-slaves et les membres désignent maintenant le nouveau maître.
Si vous réparez ou remplacez le serveur qui était le serveur maître d’origine, il vous suffit de le mettre en service, d’installer le logiciel Citrix Hypervisor et de l’ajouter au pool. Étant donné que les serveurs Citrix Hypervisor du pool sont censés être homogènes, il n’est pas vraiment nécessaire de faire du serveur remplacé le maître.
Lorsqu’un serveur Citrix Hypervisor membre est passé à l’état de maître, vérifiez que le référentiel de stockage de pool par défaut est défini sur une valeur appropriée. Cette vérification peut être effectuée à l’aide de l’icône xe pool-param-list et en vérifiant que la commande default-SR pointe vers un référentiel de stockage valide.
Défaillances de pool
Dans le cas malheureux où l’intégralité de votre pool de ressources échouerait, vous devez recréer la base de données du pool à partir de zéro. Assurez-vous de sauvegarder régulièrement vos métadonnées de pool à l’aide de la commande xe pool-dump-database CLI (voir pool-dump-database).
Pour restaurer un pool ayant complètement échoué :
-
Installez un nouvel ensemble d’hôtes. Ne les regroupez pas à ce stade.
-
Pour l’hôte désigné comme maître, restaurez la base de données du pool à partir de votre sauvegarde à l’aide de la commande
xe pool-restore-databasecommande (voir base de données-de-restauration_pool). -
Connectez-vous à l’hôte maître à l’aide de XenCenter et assurez-vous que tout votre stockage partagé et vos machines virtuelles sont à nouveau disponibles.
-
Effectuez une opération de jonction de pool sur les hôtes membres nouvellement installés restants et démarrez vos machines virtuelles sur les hôtes appropriés.
Faire face aux pannes dues à des erreurs de configuration
Si l’ordinateur hôte physique est opérationnel, mais que la configuration du logiciel ou de l’hôte est corrompue :
-
Exécutez la commande suivante pour restaurer le logiciel hôte et la configuration :
xe host-restore host=host file-name=hostbackup <!--NeedCopy--> -
Redémarrez à partir du CD d’installation de l’hôte et sélectionnez Restauration à partir d’une sauvegarde.
Défaillance physique de la machine
Si la machine hôte physique est défaillante, utilisez la procédure appropriée de la liste suivante pour récupérer.
Avertissement :
Toutes les machines virtuelles exécutées sur un membre précédent (ou l’hôte précédent) qui ont échoué sont toujours marquées comme
Coursedans la base de données. Ce comportement est pour la sécurité. Le démarrage simultané d’une machine virtuelle sur deux hôtes différents entraînait une grave corruption du disque. Si vous êtes sûr que les machines (et les machines virtuelles) sont hors ligne, vous pouvez réinitialiser l’état d’alimentation de la machine virtuelle surArrêté:
xe vm-reset-powerstate vm=vm_uuid --forceLes machines virtuelles peuvent ensuite être redémarrées à l’aide de XenCenter ou de l’interface de ligne de commande.
Pour remplacer un maître ayant échoué par un membre toujours en cours d’exécution :
-
Exécutez les commandes suivantes :
xe pool-emergency-transition-to-master xe pool-recover-slaves <!--NeedCopy--> -
Si les commandes réussissent, redémarrez les machines virtuelles.
Pour restaurer un pool avec tous les hôtes ayant échoué :
-
Exécutez la commande :
xe pool-restore-database file-name=backup <!--NeedCopy-->Avertissement :
Cette commande ne réussit que si la machine cible dispose d’un nombre approprié de cartes réseau nommées de manière appropriée.
-
Si la machine cible dispose d’une vue du stockage différente de celle de la machine d’origine, modifiez la configuration du stockage à l’aide de la commande
pbd-détruirecommander. Ensuite, utilisez lepbd-créationpour recréer des configurations de stockage. Voir Commandes PBD pour la documentation de ces commandes. -
Si vous avez créé une configuration de stockage, utilisez
prise PBDou Stockage > Réparer le référentiel de stockage dans XenCenter pour utiliser la nouvelle configuration. -
Redémarrez toutes les machines virtuelles.
Pour restaurer une machine virtuelle lorsque le stockage de la machine virtuelle n’est pas disponible :
-
Exécutez la commande suivante :
xe vm-import filename=backup metadata=true <!--NeedCopy--> -
Si l’importation des métadonnées échoue, exécutez la commande :
xe vm-import filename=backup metadata=true --force <!--NeedCopy-->Cette commande tente de restaurer les métadonnées de la machine virtuelle dans la mesure du possible.
-
Redémarrez toutes les machines virtuelles.