Hohe Verfügbarkeit

Wichtig:

Citrix Hypervisor 8.2 Kumulatives Update 1 wird am 25. Juni 2025 End of Life. Planen Sie jetzt Ihr Upgrade auf XenServer 8, um einen reibungslosen Übergang und kontinuierlichen Support zu gewährleisten. Weitere Informationen finden Sie unter Upgrade.

Wenn Sie Ihre Citrix Virtual Apps and Desktops-Lizenzdateien verwenden, um Ihre Citrix Hypervisor 8.2 Cumulative Update 1-Hosts zu lizenzieren, sind diese Lizenzdateien nicht mit XenServer 8 kompatibel. Vor dem Upgrade müssen Sie XenServer Premium Edition-Socket-Lizenzdateien für die Verwendung mit XenServer 8 erwerben. Diese Socket-Lizenzdateien sind als Berechtigung für die Abonnements Citrix für Private Cloud, Citrix Universal Hybrid Multi-Cloud, Citrix Universal MSP und Citrix Platform License für die Ausführung Ihrer Citrix-Workloads verfügbar. Citrix-Kunden, die noch nicht auf diese neuen Abonnements umgestiegen sind, können die Teilnahme an einer kostenlosen Aktion für 10.000 XenServer Premium Edition-Socket-Lizenzen anfordern. Weitere Informationen finden Sie unter XenServer (Englisch).

Wenn Sie vor dem Upgrade keine kompatible Lizenz für XenServer 8 erhalten, werden Ihre Hosts beim Upgrade auf die 90-Tage-Testversion zurückgesetzt. Die Testversion bietet die gleichen Funktionen wie die Premium Edition, jedoch mit einigen Einschränkungen. Weitere Informationen finden Sie unter Übersicht über die XenServer 8-Lizenzierung.

Hochverfügbarkeit ist eine Reihe automatischer Funktionen, die für die Planung und sichere Wiederherstellung nach Problemen konzipiert sind, die Citrix Hypervisor-Server zum Absturz bringen oder unerreichbar machen. Beispielsweise bei physischen Netzwerkstörungen oder Host-Hardwarefehlern.

Übersicht

Durch hohe Verfügbarkeit wird sichergestellt, dass, wenn ein Host nicht erreichbar oder instabil wird, die auf diesem Host laufenden VMs automatisch und sicher auf einem anderen Host neu gestartet werden. Dadurch ist kein manueller Neustart der VMs mehr erforderlich, was zu minimalen VM-Ausfallzeiten führt.

Wenn der Pool-Master nicht erreichbar oder instabil wird, kann durch Hochverfügbarkeit auch die administrative Kontrolle über einen Pool wiederhergestellt werden. Durch die hohe Verfügbarkeit wird sichergestellt, dass die administrative Kontrolle automatisch und ohne manuelles Eingreifen wiederhergestellt wird.

Optional kann die Hochverfügbarkeit auch den Neustart von VMs auf Hosts automatisieren, von denen bekannt ist, dass sie sich ohne manuelles Eingreifen in einem guten Zustand befinden. Der Neustart dieser VMs kann in Gruppen geplant werden, um Zeit zum Starten der Dienste zu haben. Dadurch können Infrastruktur-VMs vor den abhängigen VMs gestartet werden (beispielsweise ein DHCP-Server vor dem abhängigen SQL-Server).

Warnungen:

Nutzen Sie hohe Verfügbarkeit zusammen mit Multipath-Speicher und Bonded Networking. Konfigurieren Sie Multipath-Speicher und verbundene Netzwerke, bevor Sie versuchen, eine hohe Verfügbarkeit einzurichten. Bei Kunden, die keinen Multipath-Speicher und kein Bonded Networking einrichten, kann es bei einer Instabilität der Infrastruktur zu unerwartetem Host-Neustartverhalten (Self-Fencing) kommen.

Alle Grafiklösungen (NVIDIA vGPU, AMD MxGPU (veraltet) und vGPU-Pass-Through) können in einer Umgebung mit hoher Verfügbarkeit verwendet werden. VMs, die diese Grafiklösungen verwenden, können jedoch nicht mit Hochverfügbarkeit geschützt werden. Diese VMs können nach bestem Wissen und Gewissen neu gestartet werden, solange Hosts mit den entsprechenden freien Ressourcen vorhanden sind.

Übermäßiges Engagement

Ein Pool ist überlastet, wenn die aktuell ausgeführten VMs nach einer benutzerdefinierten Anzahl von Hostausfällen nicht an anderer Stelle neu gestartet werden können. Eine Überbelegung kann auftreten, wenn nach einem Fehler nicht genügend freier Speicher im gesamten Pool vorhanden ist, um diese VMs auszuführen. Es gibt jedoch auch subtilere Änderungen, die eine hohe Verfügbarkeit unhaltbar machen können: Änderungen an Virtual Block Devices (VBDs) und Netzwerken können sich darauf auswirken, welche VMs auf welchen Hosts neu gestartet werden können. Citrix Hypervisor kann nicht alle möglichen Aktionen überprüfen und feststellen, ob sie zu einer Verletzung der Hochverfügbarkeitsanforderungen führen. Wenn die hohe Verfügbarkeit jedoch nicht mehr aufrechterhalten werden kann, wird eine asynchrone Benachrichtigung gesendet.

Citrix Hypervisor verwaltet dynamisch einen Failoverplan, der detailliert beschreibt, was zu tun ist, wenn eine Gruppe von Hosts in einem Pool zu einem bestimmten Zeitpunkt ausfällt. Ein wichtiges Konzept, das es zu verstehen gilt, ist die Zu tolerierende Hostfehler Wert, der als Teil der Hochverfügbarkeitskonfiguration definiert ist. Der Wert von zu tolerierenden Hostausfällen bestimmt die Anzahl der zulässigen Hostausfälle, während alle geschützten VMs noch neu gestartet werden können. Stellen Sie sich beispielsweise einen Ressourcenpool vor, der aus 64 Hosts und Zu tolerierende Hostfehler auf 3 festgelegt ist. In diesem Fall berechnet der Pool einen Failover-Plan, der den Ausfall von drei beliebigen Hosts zulässt und die VMs anschließend auf anderen Hosts neu startet. Wenn kein Plan gefunden werden kann, gilt der Pool als überbucht. Der Plan wird basierend auf VM-Lebenszyklusvorgängen und -Bewegung dynamisch neu berechnet. Wenn Änderungen (z. B. das Hinzufügen neuer VMs zum Pool) dazu führen, dass der Pool überlastet wird, werden Warnungen entweder über XenCenter oder per E-Mail gesendet.

Warnung vor Überbelegung

Wenn jeder Versuch, eine VM zu starten oder fortzusetzen, zu einer Überlastung des Pools führen würde, wird in XenCenter eine Warnmeldung angezeigt. Sie können den Vorgang dann abbrechen oder trotzdem fortfahren. Wenn Sie fortfahren, wird der Pool überlastet und eine Nachricht wird an alle konfigurierten E-Mail-Adressen gesendet. Dies ist auch als Nachrichteninstanz über die Verwaltungs-API verfügbar. Die von VMs mit unterschiedlichen Prioritäten verwendete Speichermenge wird auf Pool- und Hostebene angezeigt.

Gastgeber-Fechten

Manchmal kann ein Server aufgrund eines Verlusts der Netzwerkverbindung oder aufgrund eines Problems mit dem Steuerstapel ausfallen. In solchen Fällen führt der Citrix Hypervisor-Server eine Selbstabgrenzung durch, um sicherzustellen, dass die VMs nicht gleichzeitig auf zwei Servern ausgeführt werden. Wenn eine Fence-Aktion ausgeführt wird, wird der Server sofort und abrupt neu gestartet, was dazu führt, dass alle darauf laufenden VMs gestoppt werden. Die anderen Server erkennen, dass die VMs nicht mehr ausgeführt werden, und starten die VMs dann entsprechend der ihnen zugewiesenen Neustartprioritäten neu. Der eingezäunte Server führt eine Neustartsequenz durch und versucht nach dem Neustart, sich wieder dem Ressourcenpool anzuschließen.

Hinweis:

Hosts in Clusterpools können sich auch selbst abschirmen, wenn sie nicht mit mehr als der Hälfte der anderen Hosts im Ressourcenpool kommunizieren können. Weitere Informationen finden Sie unter Clustered Pools.

Konfigurationsanforderungen

Um die Hochverfügbarkeitsfunktion nutzen zu können, benötigen Sie:

• Citrix Hypervisor-Pool (diese Funktion bietet hohe Verfügbarkeit auf Serverebene innerhalb eines einzelnen Ressourcenpools).

  Hinweis:

  Wir empfehlen, Hochverfügbarkeit nur in Pools zu aktivieren, die mindestens 3 Citrix Hypervisor-Server enthalten. Weitere Informationen finden Sie unter CTX129721 – Hochverfügbarkeitsverhalten, wenn der Heartbeat in einem Pool verloren geht.

• Gemeinsam genutzter Speicher, einschließlich mindestens einer iSCSI-, NFS- oder Fibre Channel-LUN mit einer Größe von 356 MB oder mehr – der Heartbeat SR. Der Hochverfügbarkeitsmechanismus erstellt zwei Volumes auf dem Heartbeat SR:

  • 4 MB Heartbeat-Volumen: Wird verwendet, um einen Heartbeat bereitzustellen.
  • 256 MB Metadatenvolumen: Zum Speichern der Pool-Mastermetadaten, die bei einem Master-Failover verwendet werden sollen.

  Hinweis:

  Bisher haben wir empfohlen, ein dediziertes NFS- oder iSCSI-Speicherrepository als Heartbeat-Datenträger mit hoher Verfügbarkeit zu verwenden. Dies ist jedoch nur dann von Vorteil, wenn das Speicher-Repository keine Ressourcen auf dem zugrunde liegenden Speichergerät gemeinsam nutzt, da es andernfalls lediglich die Komplexität und den Ressourcenverbrauch in der Kontrolldomäne (dom0) des Hosts erhöht.

  Wenn es sich bei Ihrem Pool um einen Cluster-Pool handelt, muss Ihr Heartbeat-SR ein GFS2-SR sein.

  Bei der Authentifizierung per CHAP kann über SMB oder iSCSI angeschlossener Speicher nicht als Heartbeat-SR verwendet werden.

• Statische IP-Adressen für alle Hosts.

  Warnung:

  Wenn sich die IP-Adresse eines Servers ändert, während die Hochverfügbarkeit aktiviert ist, geht die Hochverfügbarkeit davon aus, dass das Netzwerk des Hosts ausgefallen ist. Die Änderung der IP-Adresse kann den Host eingrenzen und ihn in einen nicht mehr startbaren Zustand versetzen. Um diese Situation zu beheben, deaktivieren Sie die Hochverfügbarkeit mit dem Befehl host-emergency-ha-disable , setzen Sie den Pool-Master mit pool-emergency-reset-masterzurück und aktivieren Sie die Hochverfügbarkeit anschließend erneut.

• Für maximale Zuverlässigkeit empfehlen wir die Verwendung einer dedizierten verbundenen Schnittstelle als Hochverfügbarkeits-Verwaltungsnetzwerk.

• Das Verwaltungsnetzwerk muss UDP-Netzwerk-Heartbeat-Verkehr über Port 694 zulassen.

Damit eine VM durch hohe Verfügbarkeit geschützt ist, muss sie agil sein. Dies bedeutet für die VM:

• Die virtuellen Datenträger müssen sich auf einem gemeinsam genutzten Speicher befinden. Sie können jede Art von gemeinsam genutztem Speicher verwenden. iSCSI, NFS oder Fibre Channel LUN wird nur für den Speicher-Heartbeat benötigt und kann für den virtuellen Festplattenspeicher verwendet werden.

• Kann Livemigration verwenden.

• Es ist keine Verbindung zu einem lokalen DVD-Laufwerk konfiguriert.

• Verfügt über virtuelle Netzwerkschnittstellen in poolweiten Netzwerken.

Hinweis:

Wenn Hochverfügbarkeit aktiviert ist, empfehlen wir dringend, auf den Servern im Pool eine gebundene Verwaltungsschnittstelle und einen Multipfad-Speicher für den Heartbeat SR zu verwenden.

Wenn Sie VLANs und verbundene Schnittstellen über die CLI erstellen, sind diese möglicherweise trotz ihrer Erstellung nicht angeschlossen und aktiv. In dieser Situation kann es so aussehen, als sei eine VM nicht agil und nicht durch Hochverfügbarkeit geschützt. Sie können den CLI-Befehl pif-plug verwenden, um das VLAN zu aktivieren und PIFs zu bündeln, damit die VM agil werden kann. Sie können auch genau bestimmen, warum eine VM nicht agil ist, indem Sie den CLI-Befehl xe diagnostic-vm-status verwenden. Dieser Befehl analysiert die Platzierungsbeschränkungen und Sie können bei Bedarf Abhilfemaßnahmen ergreifen.

Konfigurationseinstellungen neu starten

Virtuelle Maschinen können als geschützt, Best-Effort-geschützt oder durch Hochverfügbarkeit ungeschützt betrachtet werden. Der Wert von ha-restart-priority definiert, ob eine VM als geschützt, Best-Effort- oder ungeschützt behandelt wird. Das Neustartverhalten für VMs in jeder dieser Kategorien ist unterschiedlich.

Geschützt

Hohe Verfügbarkeit garantiert den Neustart einer geschützten VM, die offline geht oder deren Host offline geht, vorausgesetzt, der Pool ist nicht überlastet und die VM ist agil.

Wenn eine geschützte VM bei einem Serverausfall nicht neu gestartet werden kann, versucht die Hochverfügbarkeit, die VM zu starten, wenn in einem Pool freie Kapazität vorhanden ist. Versuche, die VM zu starten, wenn zusätzliche Kapazität vorhanden ist, könnten jetzt erfolgreich sein.

ha-restart-priority Wert: Neustart

Best-Effort-Ansatz

Wenn der Host einer Best-Effort-VM offline geht, versucht die Hochverfügbarkeit, die Best-Effort-VM auf einem anderen Host neu zu starten. Dieser Versuch wird erst unternommen, nachdem alle geschützten VMs erfolgreich neu gestartet wurden. Bei hoher Verfügbarkeit wird nur ein Versuch unternommen, eine Best-Effort-VM neu zu starten. Wenn dieser Versuch fehlschlägt, unternimmt die Hochverfügbarkeit keine weiteren Versuche, die VM neu zu starten.

ha-restart-priority Wert: Best-Effort

Ungeschützt

Wenn eine ungeschützte VM oder der Host, auf dem sie ausgeführt wird, gestoppt wird, versucht die Hochverfügbarkeit nicht, die VM neu zu starten.

ha-restart-priority Wert: Wert ist eine leere Zeichenfolge

Hinweis:

Durch die hohe Verfügbarkeit wird eine laufende VM niemals gestoppt oder migriert, um Ressourcen für den Neustart einer geschützten oder Best-Effort-VM freizugeben.

Wenn im Pool Serverausfälle auftreten und die Anzahl der tolerierbaren Ausfälle auf Null sinkt, kann nicht garantiert werden, dass die geschützten VMs neu gestartet werden. In solchen Fällen wird eine Systemwarnung generiert. Wenn ein weiterer Fehler auftritt, verhalten sich alle VMs, für die eine Neustartpriorität festgelegt ist, gemäß dem Best-Effort-Verhalten.

Reihenfolge starten

Die Startreihenfolge ist die Reihenfolge, in der Citrix Hypervisor High Availability versucht, geschützte VMs bei einem Fehler neu zu starten. Die Werte der Eigenschaft order für jede der geschützten VMs bestimmen die Startreihenfolge.

Die Eigenschaft Reihenfolge einer VM wird von Hochverfügbarkeit und auch von anderen Funktionen verwendet, die VMs starten und herunterfahren. Für jede VM kann die Eigenschaft in der Reihenfolge festgelegt werden, nicht nur für die VMs, die als für hohe Verfügbarkeit geschützt markiert sind. Für hohe Verfügbarkeit wird die Eigenschaft in der Reihenfolge jedoch nur für geschützte VMs verwendet.

Der Wert der Eigenschaft Ordnung ist eine Ganzzahl. Der Standardwert ist 0, was der höchsten Priorität entspricht. Geschützte VMs mit einem -Order- -Wert von 0 werden zuerst durch Hochverfügbarkeit neu gestartet. Je höher der Wert der Eigenschaft order , desto später in der Sequenz wird die VM neu gestartet.

Sie können den Wert der Eigenschaft order einer VM mithilfe der Befehlszeilenschnittstelle festlegen:

  xe vm-param-set uuid=<vm uuid> order=<int>
<!--NeedCopy-->

Oder legen Sie in XenCenter im Bereich „ Startoptionen “ für eine VM die Option „ Startreihenfolge “ auf den erforderlichen Wert fest.

Aktivieren Sie Hochverfügbarkeit in Ihrem Citrix Hypervisor-Pool

Sie können die Hochverfügbarkeit in einem Pool entweder mithilfe von XenCenter oder der Befehlszeilenschnittstelle (CLI) aktivieren. In beiden Fällen geben Sie eine Reihe von Prioritäten an, die bestimmen, welchen VMs die höchste Neustartpriorität zugewiesen wird, wenn ein Pool überlastet ist.

Warnungen:

• Wenn Sie Hochverfügbarkeit aktivieren, werden möglicherweise einige Vorgänge deaktiviert, die den Plan zum Neustarten von VMs gefährden (z. B. das Entfernen eines Servers aus einem Pool). Sie können die Hochverfügbarkeit vorübergehend deaktivieren, um solche Vorgänge auszuführen, oder alternativ durch Hochverfügbarkeit geschützte VMs ungeschützt machen.

• Wenn Hochverfügbarkeit aktiviert ist, können Sie das Clustering in Ihrem Pool nicht aktivieren. Deaktivieren Sie vorübergehend die Hochverfügbarkeit, um das Clustering zu aktivieren. Sie können für Ihren Clusterpool eine hohe Verfügbarkeit aktivieren. Einige Verhaltensweisen zur Hochverfügbarkeit, wie beispielsweise die Selbsteingrenzung, sind bei Clusterpools anders. Weitere Informationen finden Sie unter Clustered Pools.

Aktivieren Sie Hochverfügbarkeit mithilfe der CLI

1. Stellen Sie sicher, dass an Ihren Pool ein kompatibles Speicher-Repository (SR) angeschlossen ist. iSCSI-, NFS- oder Fibre Channel SRs sind kompatibel. Informationen zum Konfigurieren eines solchen Speicher-Repositorys mithilfe der CLI finden Sie unter Speicher-Repositorys verwalten.

2. Legen Sie für jede VM, die Sie schützen möchten, eine Neustartpriorität und Startreihenfolge fest. Sie können die Neustartpriorität wie folgt festlegen:

     xe vm-param-set uuid=<vm uuid> ha-restart-priority=restart order=1
   <!--NeedCopy-->
   

3. Aktivieren Sie die Hochverfügbarkeit für den Pool und geben Sie optional ein Timeout an:

     xe pool-ha-enable heartbeat-sr-uuids=<sr uuid> ha-config:timeout=<timeout in seconds>
   <!--NeedCopy-->
   

   Alternativ können Sie ein Standard-Timeout für Ihren Pool festlegen. Weitere Informationen zum Festlegen eines Timeouts finden Sie unter Konfigurieren eines Timeouts für hohe Verfügbarkeit.

4. Führen Sie den Befehl pool-ha-compute-max-host-failures-to-tolerateaus. Dieser Befehl gibt die maximale Anzahl von Hosts zurück, die ausfallen können, bevor nicht mehr genügend Ressourcen vorhanden sind, um alle geschützten VMs im Pool auszuführen.

     xe pool-ha-compute-max-host-failures-to-tolerate
   <!--NeedCopy-->
   

   Die Anzahl der zu tolerierenden Fehler bestimmt, wann eine Warnung gesendet wird. Das System berechnet einen Failover-Plan neu, wenn sich der Status des Pools ändert. Mithilfe dieser Berechnung wird die Poolkapazität ermittelt und ermittelt, wie viele weitere Ausfälle möglich sind, ohne dass die Aktivitätsgarantie für geschützte VMs verloren geht. Eine Systemwarnung wird generiert, wenn dieser berechnete Wert unter den angegebenen Wert für ha-host-failures-to-toleratefällt.

5. Geben Sie den Parameter ha-host-failures-to-tolerate an. Der Wert muss kleiner oder gleich dem berechneten Wert sein:

     xe pool-param-set ha-host-failures-to-tolerate=2 uuid=<pool uuid>
   <!--NeedCopy-->
   

Konfigurieren des Timeouts für hohe Verfügbarkeit

Das Timeout für hohe Verfügbarkeit ist der Zeitraum, in dem für die Hosts in Ihrem Pool kein Zugriff auf das Netzwerk oder den Speicher möglich ist. Wenn ein Citrix Hypervisor-Server innerhalb des Timeout-Zeitraums nicht auf das Netzwerk oder den Speicher zugreifen kann, kann er sich selbst abschirmen und neu starten. Das Standard-Timeout beträgt 60 Sekunden. Sie können diesen Wert jedoch mit dem folgenden Befehl ändern.

Legen Sie ein Standard-Timeout für hohe Verfügbarkeit für Ihren Pool fest:

  xe pool-param-set uuid=<pool uuid> other-config:default_ha_timeout=<timeout in seconds>
<!--NeedCopy-->

Wenn Sie Hochverfügbarkeit aktivieren, indem Sie XenCenter statt der xe CLI verwenden, gilt diese Standardeinstellung weiterhin.

Alternativ können Sie ein Timeout festlegen, wenn Sie Hochverfügbarkeit aktivieren:

  xe pool-ha-enable heartbeat-sr-uuids=<sr uuid> ha-config:timeout=<timeout in seconds>
<!--NeedCopy-->

Beachten Sie: Wenn Sie beim Aktivieren der Hochverfügbarkeit ein Timeout festlegen, gilt dieses nur für diese bestimmte Aktivierung. Wenn Sie die Hochverfügbarkeit deaktivieren und später erneut aktivieren, wird für die Hochverfügbarkeitsfunktion daher wieder das Standardtimeout verwendet.

Entfernen des Hochverfügbarkeitsschutzes von einer VM mithilfe der CLI

Um Hochverfügbarkeitsfunktionen für eine VM zu deaktivieren, verwenden Sie den Befehl xe vm-param-set , um den Parameter ha-restart-priority auf eine leere Zeichenfolge festzulegen. Durch Festlegen des Parameters ha-restart-priority werden die Einstellungen für die Startreihenfolge nicht gelöscht. Sie können die Hochverfügbarkeit für eine VM wieder aktivieren, indem Sie den Parameter ha-restart-priority je nach Bedarf auf Neustart oder Best-Effort setzen.

Einen nicht erreichbaren Host wiederherstellen

Wenn ein Host aus irgendeinem Grund nicht auf die Hochverfügbarkeitsstatusdatei zugreifen kann, besteht die Möglichkeit, dass der Host nicht mehr erreichbar ist. Um Ihre Citrix Hypervisor-Installation wiederherzustellen, müssen Sie möglicherweise die Hochverfügbarkeit mit dem Befehl host-emergency-ha-disable deaktivieren:

  xe host-emergency-ha-disable --force
<!--NeedCopy-->

Wenn der Host der Pool-Master war, wird er normal mit deaktivierter Hochverfügbarkeit gestartet. Poolmitglieder stellen die Verbindung wieder her und deaktivieren automatisch die Hochverfügbarkeit. Wenn der Host ein Poolmitglied war und den Master nicht kontaktieren kann, müssen Sie möglicherweise eine der folgenden Aktionen ausführen:

• Erzwingt einen Neustart des Hosts als Pool-Master (xe pool-emergency-transition-to-master)

     xe pool-emergency-transition-to-master uuid=<host uuid>
   <!--NeedCopy-->
  

• Teilen Sie dem Host mit, wo sich der neue Master befindet (xe pool-emergency-reset-master):

     xe pool-emergency-reset-master master-address=<new master hostname>
   <!--NeedCopy-->
  

Wenn alle Hosts erfolgreich neu gestartet wurden, aktivieren Sie die Hochverfügbarkeit erneut:

  xe pool-ha-enable heartbeat-sr-uuid=<sr uuid>
<!--NeedCopy-->

Herunterfahren eines Hosts bei aktivierter Hochverfügbarkeit

Gehen Sie beim Herunterfahren oder Neustarten eines Hosts besonders vorsichtig vor, um zu verhindern, dass der Hochverfügbarkeitsmechanismus davon ausgeht, dass der Host ausgefallen ist. Um einen Host bei aktivierter Hochverfügbarkeit sauber herunterzufahren, deaktivieren Sie den Host, evakuieren Sie den Host und fahren Sie ihn schließlich mithilfe von XenCenter oder der CLI herunter. Um einen Host in einer Umgebung herunterzufahren, in der Hochverfügbarkeit aktiviert ist, führen Sie diese Befehle aus:

  xe host-disable host=<host name>
  xe host-evacuate uuid=<host uuid>
  xe host-shutdown host=<host name>
<!--NeedCopy-->

Herunterfahren einer durch hohe Verfügbarkeit geschützten VM

Wenn eine VM im Rahmen eines Hochverfügbarkeitsplans geschützt und auf automatischen Neustart eingestellt ist, kann sie nicht heruntergefahren werden, während dieser Schutz aktiv ist. Um eine VM herunterzufahren, deaktivieren Sie zuerst ihren Hochverfügbarkeitsschutz und führen Sie dann den CLI-Befehl aus. XenCenter bietet Ihnen ein Dialogfeld zum automatischen Deaktivieren des Schutzes, wenn Sie die Schaltfläche Herunterfahren einer geschützten VM auswählen.

Hinweis:

Wenn Sie eine VM innerhalb des Gasts herunterfahren und die VM geschützt ist, wird sie automatisch unter den Hochverfügbarkeits-Fehlerbedingungen neu gestartet. Durch den automatischen Neustart wird sichergestellt, dass eine geschützte VM nicht aufgrund eines Bedienerfehlers versehentlich heruntergefahren wird. Wenn Sie diese VM herunterfahren möchten, deaktivieren Sie zuerst ihren Hochverfügbarkeitsschutz.