Verwalten von Speicher-Repositories

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.

In diesem Abschnitt wird beschrieben, wie Sie Speicher-Repository-Typen erstellen und für Ihren Citrix Hypervisor-Server verfügbar machen. Darüber hinaus werden verschiedene Vorgänge abgedeckt, die für das laufende Management von Storage Repositories (SRs) erforderlich sind, einschließlich der Live-VDI-Migration.

Erstellen von Speicher-Repositories

In diesem Abschnitt wird erläutert, wie Sie Storage Repositories (SRs) verschiedener Typen erstellen und für Ihren Citrix Hypervisor-Server verfügbar machen. Die bereitgestellten Beispiele behandeln das Erstellen von SRs mit der xe CLI. Weitere Informationen zur Verwendung der Neues Speicher-Repository Assistent zum Hinzufügen von SRs mit XenCenter finden Sie unter XenCenter-Dokumentation.

Hinweis:

Lokale SRs vom Typ lvm und ext können nur mit der xe CLI erstellt werden. Nach der Erstellung können Sie alle SR-Typen entweder über XenCenter oder die xe CLI verwalten.

Es gibt zwei grundlegende Schritte, um ein Speicher-Repository für die Verwendung auf einem Host mithilfe der CLI zu erstellen:

1. Testen Sie den SR-Typ, um Werte für alle erforderlichen Parameter zu bestimmen.

2. Erstellen Sie die SR, um das SR-Objekt und die zugehörigen PBD-Objekte zu initialisieren, schließen Sie die PBDs an und aktivieren Sie die SR.

Diese Schritte unterscheiden sich je nach Typ der zu erstellenden SR im Detail. In allen Beispielen gibt der Befehl sr-create im Erfolgsfall die UUID des erstellten SR zurück.

SRs können sein zerstört wenn es nicht mehr verwendet wird, um das physische Gerät freizugeben. SRs können auch vergessen , um die SR von einem Citrix Hypervisor-Server zu trennen und an einen anderen anzuhängen. Weitere Informationen finden Sie unter Entfernen von SRs im folgenden Abschnitt.

Sondieren eines SR

Der Befehl sr-probe kann auf folgende Arten verwendet werden:

• So identifizieren Sie unbekannte Parameter für die Erstellung einer SR
• So geben Sie eine Liste vorhandener SRs zurück

In beiden Fällen funktioniert sr-probe , indem ein SR-Typ und ein oder mehrere Gerätekonfigurationsparameter für diesen SR-Typ angegeben werden. Wenn ein unvollständiger Parametersatz angegeben wird, gibt der Befehl sr-probe eine Fehlermeldung zurück, die auf fehlende Parameter und die möglichen Optionen für die fehlenden Parameter hinweist. Wenn ein vollständiger Satz von Parametern angegeben wird, wird eine Liste der vorhandenen SRs zurückgegeben. Die gesamte sr-probe -Ausgabe wird als XML zurückgegeben.

Beispielsweise kann ein bekanntes iSCSI-Ziel durch Angabe seines Namens oder seiner IP-Adresse überprüft werden. Der Satz von IQNs, die auf dem Ziel verfügbar sind, wird zurückgegeben:

      xe sr-probe type=lvmoiscsi device-config:target=192.168.1.10

      Error code: SR_BACKEND_FAILURE_96
      Error parameters: , The request is missing or has an incorrect target IQN parameter, \
      <?xml version="1.0" ?>
      <iscsi-target-iqns>
          <TGT>
              <Index>
                  0
              </Index>
              <IPAddress>
                  192.168.1.10
              </IPAddress>
              <TargetIQN>
                  iqn.192.168.1.10:filer1
              </TargetIQN>
          </TGT>
      </iscsi-target-iqns>
<!--NeedCopy-->

Wenn Sie dasselbe Ziel erneut prüfen und sowohl den Namen/die IP-Adresse als auch den gewünschten IQN angeben, wird der Satz von SCSIids (LUNs) zurückgegeben, der auf dem Ziel/IQN verfügbar ist.

      xe sr-probe type=lvmoiscsi device-config:target=192.168.1.10  \
      device-config:targetIQN=iqn.192.168.1.10:filer1

      Error code: SR_BACKEND_FAILURE_107
      Error parameters: , The SCSIid parameter is missing or incorrect, \
      <?xml version="1.0" ?>
      <iscsi-target>
          <LUN>
              <vendor>
                  IET
              </vendor>
              <LUNid>
                  0
              </LUNid>
              <size>
                  42949672960
              </size>
              <SCSIid>
                  149455400000000000000000002000000b70200000f000000
              </SCSIid>
          </LUN>
      </iscsi-target>
<!--NeedCopy-->

Wenn Sie dasselbe Ziel untersuchen und alle drei Parameter angeben, wird eine Liste der SRs zurückgegeben, die auf der LUN vorhanden sind, sofern vorhanden.

      xe sr-probe type=lvmoiscsi device-config:target=192.168.1.10  \
      device-config:targetIQN=192.168.1.10:filer1 \
      device-config:SCSIid=149455400000000000000000002000000b70200000f000000

      <?xml version="1.0" ?>
      <SRlist>
          <SR>
              <UUID>
                  3f6e1ebd-8687-0315-f9d3-b02ab3adc4a6
              </UUID>
              <Devlist>
                  /dev/disk/by-id/scsi-149455400000000000000000002000000b70200000f000000
              </Devlist>
          </SR>
      </SRlist>
<!--NeedCopy-->

Die folgenden Parameter können für jeden SR-Typ getestet werden:

Entfernen von SRs

Ein Storage Repository (SR) kann entweder vorübergehend oder dauerhaft entfernt werden.

Abtrennen: Unterbricht die Verbindung zwischen dem Speichergerät und dem Pool oder Host (PBD Unplug). Auf die SR (und ihre VDIs) kann nicht mehr zugegriffen werden. Der Inhalt der VDIs und die Metainformationen, die von VMs für den Zugriff auf die VDIs verwendet werden, bleiben erhalten. Detach kann verwendet werden, wenn Sie eine SR vorübergehend offline nehmen, z. B. für Wartungszwecke. Eine abgelöste SR kann später wieder angebracht werden.

Vergessen: Der Inhalt der SR wird auf dem physischen Datenträger beibehalten, aber die Informationen, die eine VM mit ihren VDIs verbinden, werden dauerhaft gelöscht. Ermöglicht es Ihnen beispielsweise, die SR erneut an einen anderen Citrix Hypervisor-Server anzuhängen, ohne den SR-Inhalt zu entfernen.

Zerstören: Löscht den Inhalt der SR von der physischen Festplatte.

Hinweis:

Wenn Sie SMB-Speicher verwenden, entfernen Sie die Freigabe nicht aus dem Speicher, bevor Sie den SMB-SR trennen.

Für Destroy or Forget muss die PBD, die mit dem SR verbunden ist, vom Host getrennt werden.

1. Trennen Sie die PBD, um die SR vom entsprechenden Citrix Hypervisor-Server zu trennen:

     xe pbd-unplug uuid=pbd_uuid
   <!--NeedCopy-->
   

2. Verwenden Sie den Befehl sr-destroy , um einen SR zu entfernen. Der Befehl zerstört die SR, löscht die SR und die entsprechende PBD aus der Citrix Hypervisor-Serverdatenbank und löscht den SR-Inhalt von der physischen Festplatte:

     xe sr-destroy uuid=sr_uuid
   <!--NeedCopy-->
   

3. Verwenden Sie den Befehl sr-forget , um einen SR zu vergessen. Der Befehl entfernt die SR und die entsprechende PBD aus der Citrix Hypervisor-Serverdatenbank, lässt jedoch den tatsächlichen SR-Inhalt auf dem physischen Medium intakt:

     xe sr-forget uuid=sr_uuid
   <!--NeedCopy-->
   

Hinweis:

Es kann einige Zeit dauern, bis das Softwareobjekt, das der SR entspricht, von der Garbage Collection erfasst wird.

Einführung eines SR

Um eine frühere vergessen SR, erstellen Sie eine PBD. Schließen Sie die PBD manuell an die entsprechenden Citrix Hypervisor-Server an, um die SR zu aktivieren.

Das folgende Beispiel führt einen SR vom Typ lvmoiscsiein.

1. Untersuchen Sie die vorhandene SR, um ihre UUID zu bestimmen:

     xe sr-probe type=lvmoiscsi device-config:target=192.168.1.10 \
         device-config:targetIQN=192.168.1.10:filer1 \
         device-config:SCSIid=149455400000000000000000002000000b70200000f000000
   <!--NeedCopy-->
   

2. Geben Sie die vorhandene SR-UUID ein, die vom Befehl sr-probe zurückgegeben wurde. Die UUID der neuen SR wird zurückgegeben:

     xe sr-introduce content-type=user name-label="Example Shared LVM over iSCSI SR" \
         shared=true uuid=valid_sr_uuid type=lvmoiscsi
   <!--NeedCopy-->
   

3. Erstellen Sie eine PBD, die die SR begleitet. Die UUID der neuen PBD wird zurückgegeben:

     xe pbd-create type=lvmoiscsi host-uuid=valid_uuid sr-uuid=valid_sr_uuid \
         device-config:target=192.168.0.1 \
         device-config:targetIQN=192.168.1.10:filer1 \
         device-config:SCSIid=149455400000000000000000002000000b70200000f000000
   <!--NeedCopy-->
   

4. Stecken Sie die PBD ein, um die SR anzuschließen:

     xe pbd-plug uuid=pbd_uuid
   <!--NeedCopy-->
   

5. Überprüfen Sie den Status des PBD-Steckers. Bei Erfolg ist die aktuell angehängte Eigenschaft `` wahr:

     xe pbd-list sr-uuid=sr_uuid
   <!--NeedCopy-->
   

Hinweis:

Führen Sie die Schritte 3 bis 5 für jeden Server im Ressourcenpool aus. Diese Schritte können auch mit der Funktion “Storage Repository reparieren” in XenCenter ausgeführt werden.

Live-LUN-Erweiterung

Um die Kapazitätsanforderungen zu erfüllen, müssen Sie dem Speicherarray möglicherweise Kapazität hinzufügen, um die Größe der LUN zu erhöhen, die auf dem Citrix Hypervisor-Server bereitgestellt wird. Mit der Live-LUN-Erweiterung können Sie die Größe der LUN ohne VM-Ausfallzeiten erhöhen.

Nachdem Sie Ihrem Speicher-Array weitere Kapazität hinzugefügt haben, geben Sie

  xe sr-scan sr-uuid=sr_uuid
<!--NeedCopy-->

Mit diesem Befehl wird die SR erneut gescannt, und alle zusätzlichen Kapazitäten werden hinzugefügt und verfügbar gemacht.

Dieser Vorgang ist auch in XenCenter verfügbar. Wählen Sie die SR aus, deren Größe geändert werden soll, und klicken Sie dann auf Neu abtasten.

Warnungen:

• Es ist nicht möglich, LUNs zu verkleinern oder abzuschneiden. Das Reduzieren der LUN-Größe auf dem Speicher-Array kann zu Datenverlust führen.

Live-VDI-Migration

Die Live-VDI-Migration ermöglicht es dem Administrator, das Virtual Disk Image (VDI) der VM zu verschieben, ohne die VM herunterzufahren. Diese Funktion ermöglicht Verwaltungsvorgänge wie:

• Verschieben einer VM von kostengünstigem lokalem Speicher zu schnellem, ausfallsicherem, Array-gestütztem Speicher.
• Verschieben einer VM von einer Entwicklungs- in eine Produktionsumgebung.
• Wechseln zwischen Speicherebenen, wenn eine VM durch die Speicherkapazität begrenzt ist.
• Durchführen von Speicher-Array-Upgrades.

Einschränkungen und Vorbehalte

Die Live-VDI-Migration unterliegt den folgenden Einschränkungen und Vorbehalten

• Auf dem Ziel-Repository muss ausreichend Speicherplatz verfügbar sein.

So verschieben Sie virtuelle Festplatten mit XenCenter

1. Im Betriebsmittel , wählen Sie die SR aus, in der das virtuelle Laufwerk gespeichert ist, und klicken Sie dann auf das Symbol Lagerung Registerkarte.

2. Im Virtuelle Festplatten , wählen Sie das virtuelle Laufwerk aus, das Sie verschieben möchten, und klicken Sie dann auf Bewegen.

3. Im Verschieben des virtuellen Laufwerks Wählen Sie die Ziel-SR aus, in die Sie die VDI verschieben möchten.

   Hinweis:

   Stellen Sie sicher, dass die SR über ausreichend Speicherplatz für ein weiteres virtuelles Laufwerk verfügt: Der verfügbare Speicherplatz wird in der Liste der verfügbaren SRs angezeigt.

4. Klicken Bewegen , um das virtuelle Laufwerk zu verschieben.

Eine Referenz zur XE-CLI finden Sie unter vdi-pool-migrate.

Cold-VDI-Migration zwischen SRs (Offline-Migration)

VDIs, die einer VM zugeordnet sind, können von einer SR in eine andere kopiert werden, um Wartungsanforderungen oder Tiered Storage-Konfigurationen zu erfüllen. XenCenter ermöglicht es Ihnen, eine VM und alle ihre VDIs auf dieselbe oder eine andere SR zu kopieren. Eine Kombination aus XenCenter und der xe CLI kann zum Kopieren einzelner VDIs verwendet werden.

Eine Referenz zur XE-CLI finden Sie unter vm-migrate.

Kopieren Sie alle VDIs einer VM in eine andere SR

Die XenCenter Copy VM-Funktion erstellt Kopien aller VDIs für eine ausgewählte VM auf derselben oder einer anderen SR. Die Quell-VM und VDIs sind standardmäßig nicht betroffen. Um die VM in die ausgewählte SR zu verschieben, anstatt eine Kopie zu erstellen, wählen Sie im Dialogfeld Virtuelle Maschine kopieren die Option Ursprüngliche VM entfernen aus.

1. Fahren Sie die VM herunter.
2. Wählen Sie in XenCenter die VM aus und wählen Sie dann die VM > VM kopieren Option.
3. Wählen Sie die gewünschte Ziel-SR aus.

Kopieren einzelner VDIs in eine andere SR

Eine Kombination aus der xe CLI und XenCenter kann verwendet werden, um einzelne VDIs zwischen SRs zu kopieren.

1. Fahren Sie die VM herunter.

2. Verwenden Sie die xe CLI, um die UUIDs der zu verschiebenden VDIs zu identifizieren. Wenn die VM über ein DVD-Laufwerk verfügt, wird ihre VDI-UUID als aufgeführt, nicht in der Datenbank , und kann ignoriert werden.

     xe vbd-list vm-uuid=valid_vm_uuid
   <!--NeedCopy-->
   

   Hinweis:

   Der Befehl vbd-list zeigt sowohl die VBD- als auch die VDI-UUIDs an. Achten Sie darauf, die VDI-UUIDs und nicht die VBD-UUIDs aufzuzeichnen.

3. Wählen Sie in XenCenter die Option VM-Speicher Registerkarte. Wählen Sie für jeden VDI, der verschoben werden soll, den VDI aus und klicken Sie auf das Symbol Abtrennen Knopf. Dieser Schritt kann auch mit dem Befehl vbd-destroy ausgeführt werden.

   Hinweis:

   Wenn Sie den Befehl vbd-destroy zum Trennen der VDI-UUIDs verwenden, prüfen Sie zuerst, ob im VBD der Parameter other-config:owner auf truegesetzt ist. Setzen Sie diesen Parameter auf false. Durch Ausführen des Befehls vbd-destroy mit other-config:owner=true wird auch der zugehörige VDI zerstört.

4. Verwenden Sie den Befehl vdi-copy , um alle VM-VDIs zu kopieren, die in den gewünschten SR verschoben werden sollen.

     xe vdi-copy uuid=valid_vdi_uuid sr-uuid=valid_sr_uuid
   <!--NeedCopy-->
   

5. Wählen Sie in XenCenter die Option VM-Speicher Registerkarte. Klicken Sie auf das Symbol Befestigen und wählen Sie die VDIs aus der neuen SR aus. Dieser Schritt kann auch mit dem Befehl vbd-create ausgeführt werden.

6. Um die ursprünglichen VDIs zu löschen, wählen Sie die Schaltfläche Lagerung Registerkarte der ursprünglichen SR in XenCenter. Die ursprünglichen VDIs werden mit einem leeren Wert für das Feld VM aufgelistet. Verwenden Sie die Schaltfläche Löschen , um den VDI zu löschen.

Konvertieren von lokalen Fibre Channel-SRs in gemeinsam genutzte SRs

Verwenden Sie die xe CLI und das XenCenter Reparieren des Speicher-Repositorys Funktion zum Konvertieren einer lokalen FC-SR in eine gemeinsam genutzte FC-SR:

1. Aktualisieren Sie alle Hosts im Ressourcenpool auf Citrix Hypervisor 8.2.

2. Stellen Sie sicher, dass die LUN der SR auf allen Hosts im Pool ordnungsgemäß in Zonen unterteilt ist. Weitere Informationen zur Verwendung des Befehls sr-probe zum Überprüfen, ob die LUN auf jedem Host vorhanden ist, finden Sie unter Prüfen eines SR .

3. Konvertieren Sie die SR in eine freigegebene:

     xe sr-param-set shared=true uuid=local_fc_sr
   <!--NeedCopy-->
   

4. Die SR wird in XenCenter von der Host-Ebene auf die Pool-Ebene verschoben, was darauf hinweist, dass sie jetzt freigegeben ist. Die SR ist mit einem roten Ausrufezeichen gekennzeichnet, um anzuzeigen, dass sie derzeit nicht auf allen Hosts im Pool angeschlossen ist.

5. Wählen Sie die SR aus, und wählen Sie dann die Option Lagerung > Reparieren des Speicher-Repositorys Option.

6. Klicken Reparieren , um eine PBD für jeden Host im Pool zu erstellen und anzuschließen.

Freigeben von Speicherplatz für blockbasierten Speicher auf dem Backing-Array mithilfe von discard

Sie können die Speicherplatzrückgewinnung verwenden, um ungenutzte Blöcke auf einer Thin Provisioning-LUN freizugeben. Nachdem der Speicherplatz freigegeben wurde, kann das Speicher-Array diesen zurückgewonnenen Speicherplatz wiederverwenden.

Hinweis:

Die Speicherplatzrückgewinnung ist nur für einige Arten von Speicher-Arrays verfügbar. Informationen dazu, ob Ihr Array diese Funktion unterstützt und ob eine bestimmte Konfiguration erforderlich ist, finden Sie in der Hardware-Kompatibilitätsliste und die spezifische Dokumentation Ihres Speicheranbieters.

So beanspruchen Sie den Speicherplatz mit XenCenter zurück:

1. Wählen Sie die Schaltfläche Infrastruktur , und wählen Sie dann den Server oder Pool aus, der mit der SR verbunden ist.

2. Klicken Sie auf das Symbol Lagerung Registerkarte.

3. Wählen Sie die SR aus der Liste aus, und klicken Sie auf Freigeben von Speicherplatz zurückgewinnen.

4. Klicken Ja , um den Vorgang zu bestätigen.

5. Klicken Benachrichtigungen Und dann Ereignisse , um den Status des Vorgangs anzuzeigen.

Für weitere Informationen drücken Sie F1in XenCenter, um auf die Online-Hilfe zuzugreifen.

Um Speicherplatz mithilfe der xe CLI freizugeben, können Sie den folgenden Befehl verwenden:

  xe host-call-plugin host-uuid=host_uuid \
      plugin=trim fn=do_trim args:sr_uuid=sr_uuid

Hinweise:

• Der Vorgang ist nur für LVM-basierte SRs verfügbar, die auf Thin Provisioned LUNs auf dem Array basieren. Lokale SSDs können auch von der Speicherplatzrückgewinnung profitieren.
• Für dateibasierte SRs wie NFS und EXT3/EXT4 ist keine Speicherplatzrückgewinnung erforderlich. Das Freigeben von Speicherplatz zurückgewinnen ist in XenCenter für diese SR-Typen nicht verfügbar.
• Wenn Sie den Befehl space reclamation xe für eine dateibasierte SR oder eine LVM-basierte SR mit Thick-Provisioning ausführen, gibt der Befehl einen Fehler zurück.
• Die Rückgewinnung von Speicherplatz ist ein intensiver Vorgang und kann zu einer Verschlechterung der Leistung von Speicher-Arrays führen. Initiieren Sie diesen Vorgang daher nur, wenn eine Speicherplatzrückgewinnung auf dem Array erforderlich ist. Es wird empfohlen, diese Arbeit außerhalb der Spitzenzeiten des Array-Bedarfs zu planen.

Automatisches Zurückgewinnen von Speicherplatz beim Löschen von Snapshots

Beim Löschen von Snapshots mit Citrix Hypervisor wird der auf LVM-basierten SRs zugewiesene Speicherplatz automatisch zurückgewonnen und ein Neustart der VM ist nicht erforderlich. Dieser Vorgang wird als “Online-Koaleszenz” bezeichnet. Die Online-Zusammenführung gilt für alle Arten von SR. GFS2-SRs können jedoch keine Blattzusammenführung durchführen, d. h., der VDI, in den die VM schreibt, kann nicht mit dem übergeordneten Element auf einer GFS2-SR zusammengeführt werden.

In bestimmten Fällen kann die automatische Speicherplatzrückgewinnung möglicherweise nicht fortgesetzt werden. Es wird empfohlen, das Offline-Koaleszenztool in den folgenden Szenarien zu verwenden:

• Unter Bedingungen, unter denen ein VM-E/A-Durchsatz beträchtlich ist
• Unter Bedingungen, unter denen der Speicherplatz nach einer bestimmten Zeit nicht zurückgewonnen wird

Hinweise:

• Beim Ausführen des Offline-Koaleszenztools kommt es aufgrund der ausgeführten Vorgänge zum Anhalten/Fortsetzen zu Ausfallzeiten für die VM.
• Löschen Sie vor dem Ausführen des Werkzeugs alle Snapshots und Klone, die Sie nicht mehr benötigen. Das Tool gibt so viel Speicherplatz wie möglich unter Berücksichtigung der verbleibenden Snapshots/Klone zurück. Wenn Sie den gesamten Speicherplatz freigeben möchten, löschen Sie alle Snapshots und Klone.
• VM-Datenträger müssen sich entweder im freigegebenen oder im lokalen Speicher für einen einzelnen Host befinden. VMs mit Festplatten in beiden Speichertypen können nicht zusammengeführt werden.

Gewinnen Sie Speicherplatz zurück, indem Sie das Offline-Koaleszenzwerkzeug verwenden

Aktivieren Sie die versteckten Objekte mit XenCenter. Klicken Ansehen > Versteckt Objekte. Wählen Sie im Bereich Ressource die VM aus, für die Sie die UUID abrufen möchten. Die UUID wird in der Datei Allgemein Registerkarte.

Im Ressource den Ressourcenpoolmaster (den ersten Host in der Liste) aus. Das Allgemein zeigt die UUID an. Wenn Sie keinen Ressourcenpool verwenden, wählen Sie den Host des virtuellen Computers aus.

1. Öffnen Sie eine Konsole auf dem Host und führen Sie den folgenden Befehl aus:

     xe host-call-plugin host-uuid=host-UUID \
         plugin=coalesce-leaf fn=leaf-coalesce args:vm_uuid=VM-UUID
   <!--NeedCopy-->
   

   Wenn die VM-UUID beispielsweise 9bad4022-2c2d-dee6-abf5-1b6195b1dad5 und die Host-UUID b8722062-de95-4d95-9baa-a5fe343898eaist, führen Sie den folgenden Befehl aus:

     xe host-call-plugin host-uuid=b8722062-de95-4d95-9baa-a5fe343898ea \
         plugin=coalesce-leaf fn=leaf-coalesce args:vm_uuid=9bad4022-2c2d-dee6-abf5-1b6195b1dad5
   <!--NeedCopy-->
   

2. Mit diesem Befehl wird die VM angehalten (es sei denn, sie ist bereits heruntergefahren), der Speicherplatzrückgewinnungsprozess initiiert und dann die VM fortgesetzt.

Hinweise:

Es wird empfohlen, die VM manuell herunterzufahren oder anzuhalten, bevor Sie das Offline-Koaleszenztool ausführen. Sie können die VM entweder mit XenCenter oder der Citrix Hypervisor CLI herunterfahren oder anhalten. Wenn Sie das Koaleszenztool auf einer ausgeführten VM ausführen, hält das Tool die VM automatisch an, führt die erforderlichen VDI-Koaleszenzvorgänge aus und setzt die VM fort. Agile-VMs werden möglicherweise auf einem anderen Host neu gestartet.

Wenn sich die zu koalisierenden Virtual Disk Images (VDIs) auf einem freigegebenen Speicher befinden, müssen Sie das Offline-Koaleszenztool auf dem Poolmaster ausführen.

Wenn sich die zu koalzierenden VDIs auf dem lokalen Speicher befinden, führen Sie das Offline-Koaleszenztool auf dem Server aus, an den der lokale Speicher angefügt ist.

Arbeiten mit Datenträger-I/O

Sie können den Datenträger-E/A-Scheduler und die Einstellungen für die Datenträger-E/A-Priorität konfigurieren, um die Leistung Ihrer Datenträger zu ändern.

Hinweis:

Die in diesem Abschnitt beschriebenen Festplatten-E/A-Funktionen gelten nicht für EqualLogic-, NetApp- oder NFS-Speicher.

Anpassen des Festplatten-E/A-Schedulers

Aus Gründen der allgemeinen Leistung wird der Standard-Festplattenplaner noop auf alle neuen SR-Typen angewendet. Der noop -Scheduler bietet die fairste Leistung für konkurrierende VMs, die auf dasselbe Gerät zugreifen.

1. Passen Sie den Festplattenplaner mit dem folgenden Befehl an:

     xe sr-param-set other-config:scheduler=<option> uuid=<sr_uuid>
   <!--NeedCopy-->
   

   Der Wert von <option> kann einer der folgenden Terme sein: noop, cfqoder deadline.

2. Trennen Sie die entsprechende PBD und stecken Sie sie wieder ein, damit der Scheduler-Parameter wirksam wird.

     xe pbd-unplug uuid=<pbd_uuid>
     xe pbd-plug uuid=<pbd_uuid>
   <!--NeedCopy-->
   

Um eine Priorisierung der Datenträger-E/A-Anforderungen anzuwenden, überschreiben Sie die Standardeinstellung und weisen Sie dem SR den Datenträger-Scheduler cfq zu.

Priorisierung von E/A-Anforderungen für virtuelle Festplatten

Virtuelle Festplatten verfügen über optionale Einstellungen für die Priorität von E/A-Anforderungen. Sie können diese Einstellungen verwenden, um die E/A-Vorgänge für den Datenträger einer bestimmten VM gegenüber anderen zu priorisieren.

Stellen Sie vor dem Konfigurieren von Parametern für die Priorität von Festplatten-E/A-Anforderungen für ein VBD sicher, dass der Festplattenplaner für die SR ordnungsgemäß eingestellt wurde. Der Scheduler-Parameter muss auf dem SR auf cfq gesetzt werden und das zugehörige PBD muss ausgesteckt und wieder eingesteckt werden. Weitere Informationen zum Anpassen des Schedulers finden Sie unter Anpassen des Festplatten-E/A-Schedulers.

Bei gemeinsam genutzten SRs, bei denen mehrere Hosts auf dieselbe LUN zugreifen, wird die Prioritätseinstellung auf VBDs angewendet, die vom selben Host aus auf die LUN zugreifen. Diese Einstellungen werden nicht auf alle Hosts im Pool angewendet.

Der Host gibt eine Anforderung an den Remote-Speicher aus, aber die Priorisierung der Anforderung erfolgt durch den Remote-Speicher.

Festlegen von Parametern für Datenträger-E/A-Anforderungen

Diese Einstellungen können auf vorhandene virtuelle Datenträger angewendet werden, indem der Befehl xe vbd-param-set mit den folgenden Parametern verwendet wird:

• qos_algorithm_type – Dieser Parameter muss auf den Wert ionicegesetzt werden. Dies ist der einzige Algorithmus, der für virtuelle Datenträger unterstützt wird.

• qos_algorithm_param – Verwenden Sie diesen Parameter, um Schlüssel/Wert-Paare festzulegen. Für virtuelle Datenträger benötigt qos_algorithm_param einen sched -Schlüssel und, abhängig vom Wert, auch einen class -Schlüssel.

  Der Schlüssel qos_algorithm_param:sched kann einen der folgenden Werte haben:

  • sched=rt oder sched=real-time – Dieser Wert setzt den Planungsparameter auf Echtzeitpriorität, was einen Parameter der Klasse `` erfordert, um einen Wert festzulegen.

  • sched=idle – Dieser Wert setzt den Planungsparameter auf Leerlaufpriorität, wodurch kein Klassenparameter erforderlich ist, um einen beliebigen Wert festzulegen.

  • sched=anything – Dieser Wert setzt den Planungsparameter auf Best-Effort-Priorität, was einen -Klassenparameter erfordert, um einen Wert festzulegen.

  Der Schlüssel qos_algorithm_param:class kann einen der folgenden Werte haben:

  • Eines der folgenden Schlüsselwörter: höchster, hoch, normal, niedrig, niedrigster.

  • Eine ganze Zahl zwischen 0 und 7, wobei 7 die höchste und 0 die niedrigste Priorität hat. Beispielsweise erhalten E/A-Anforderungen mit einer Priorität von 5 Vorrang vor E/A-Anforderungen mit einer Priorität von 2.

Beispiel

Beispielsweise stellen die folgenden CLI-Befehle das VBD der virtuellen Festplatte so ein, dass die Echtzeitpriorität 5verwendet wird:

  xe vbd-param-set uuid=<vbd_uuid> qos_algorithm_type=ionice
  xe vbd-param-set uuid=<vbd_uuid> qos_algorithm_params:sched=rt
  xe vbd-param-set uuid=<vbd_uuid> qos_algorithm_params:class=5
  xe sr-param-set uuid=<sr_uuid> other-config:scheduler=cfq
  xe pbd-unplug uuid=<pbd_uuid>
  xe pbd-plug uuid=<pbd_uuid>
<!--NeedCopy-->