VMware vCenter Site Recovery Manager 5.5.1 | 11. März 2014 | Build 1647061

Letzte Aktualisierung: 11. März 2014

Überprüfen Sie, ob Erweiterungen und Updates für diese Versionshinweise zur Verfügung stehen.

Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

Neuheiten in SRM 5.5.1

VMware vCenter Site Recovery Manager 5.5.1 weist die folgenden neuen Funktionen und Verbesserungen auf.

Lokalisierung

VMware vCenter Site Recovery Manager 5.5.1 ist in den folgenden Sprachen verfügbar:

  • Englisch
  • Französisch
  • Deutsch
  • Japanisch
  • Koreanisch
  • Vereinfachtes Chinesisch

Kompatibilität

SRM-Kompatibilitätstabelle

Weitere Informationen zur Interoperabilität und Produktkompatibilität, darunter die unterstützten Gastbetriebssysteme und die Unterstützung für das Anpassen von Gastbetriebssystemen, finden Sie in den Kompatibilitätstabellen für VMware vCenter Site Recovery Manager 5.5.

Kompatible Speicher-Arrays und Speicherreplizierungsadapter

Die aktuelle Liste der unterstützten kompatiblen Speicher-Arrays und SRAs finden Sie im Site Recovery Manager-Speicherpartner-Kompatibilitätshandbuch.

VMware Virtual SAN-Unterstützung

SRM 5.5.1 kann mithilfe von vSphere Replication virtuelle Maschinen schützen, die sich auf VMware Virtual SAN befinden. Virtual SAN benötigt für das Zusammenspiel mit SRM 5.5.1 keinen Speicherreplizierungsadapter (SRA).

VMware VSA-Unterstützung

SRM 5.5.1 kann mithilfe von vSphere Replication virtuelle Maschinen schützen, die sich auf der vSphere Storage Appliance (VSA) befinden. VSA benötigt für das Zusammenspiel mit SRM 5.5.1 keinen Speicherreplizierungsadapter (SRA).

Installation und Upgrade

Das Evaluierungshandbuch zur Unterstützung mit einer technischen Komplettlösung der wichtigsten Funktionen und Merkmale von Site Recovery Manager 5.5.1 finden Sie in den VMware vCenter Site Recovery Manager-Ressourcen.

Weitere Informationen zu den unterstützten Upgrade-Pfaden für SRM finden Sie in den VMware-Produktinteroperabilitätstabellen. Wählen Sie Upgrade-Pfad der Lösung und VMware vCenter Site Recovery Manager aus.

Installieren von SRM 5.5.1

Um SRM 5.5.1 neu zu installieren, laden Sie das Installationsprogramm VMware-srm-5,5.1-1647061.exe herunter und führen Sie es aus.

Weitere Informationen hierzu finden Sie unter Installieren von SRM im Handbuch Installation und Konfiguration von Site Recovery Manager 5.5.

Upgrade einer vorhandenen SRM 4.1.2-Installation auf SRM 5.5.1

Führen Sie ein Upgrade von SRM 4.1.2 auf SRM 5.0.x durch, bevor Sie ein Upgrade auf SRM 5.5.1 durchführen.

Weitere Informationen hierzu finden Sie unter Durchführen eines Upgrades von SRM im Administratorhandbuch für Site Recovery Manager 5.0.

WICHTIG: Ein direktes vCenter Server-Upgrade von Version 4.1.2 auf Version 5.5.1 ist ein unterstützter Upgrade-Pfad. Allerdings ist ein direktes SRM-Upgrade von Version 4.1.2 auf Version 5.5.1 kein unterstützter Upgrade-Pfad, und Sie müssen ein SRM-Upgrade auf Version 5.0.x durchführen, bevor Sie ein Upgrade auf Version 5.5.1 durchführen können. Wenn Sie ein Upgrade einer vCenter Server 4.1.2-Instanz durchführen, die eine SRM 4.1.2-Installation enthält, müssen Sie auch ein Upgrade von vCenter Server auf Version 5.0.x durchführen, bevor Sie SRM auf Version 5.0.x aktualisieren. Wenn Sie ein direktes Upgrade von vCenter Server von Version 4.1.2 auf Version 5.5.1 durchführen und versuchen, ein SRM-Upgrade von Version 4.1.2 auf 5.0.x durchzuführen, schlägt das SRM-Upgrade fehl. SRM 5.0.x kann keine Verbindung zu einer vCenter Server 5.5-Instanz herstellen.

Upgrade einer vorhandenen SRM 5.0.x- oder 5.1.x-Installation auf SRM 5.5.1

Um ein Upgrade einer vorhandenen SRM 5.0.x- oder 5.1.x-Installation auf SRM 5.5.1 durchzuführen, laden Sie das Installationsprogramm VMware-srm-5.5.1-1647061.exe herunter und führen Sie es aus.

Weitere Informationen hierzu finden Sie unter Durchführen eines Upgrades von SRM im Handbuch Installation und Konfiguration von Site Recovery Manager 5.5.

Update einer vorhandenen SRM 5.5-Installation auf SRM 5.5.1

Führen Sie die folgenden Schritte aus, um ein Update einer vorhandenen SRM 5.5-Installation auf SRM 5.5.1. durchzuführen.

  1. Melden Sie sich bei der Maschine an, auf der Sie den SRM-Server auf der geschützten Site ausführen.
  2. Sichern Sie die SRM-Datenbank mit den Tools der Datenbanksoftware.
  3. Laden Sie das Installationsprogramm VMware-srm-5.5.1-1647061.exe herunter und führen Sie es aus.
  4. Klicken Sie auf Ja, um das Upgrade von SRM zu bestätigen.
  5. Klicken Sie auf Ja, um zu bestätigen, dass Sie die SRM-Datenbank gesichert haben.
  6. Klicken Sie auf Beenden, wenn die Installation abgeschlossen ist.
  7. Wiederholen Sie den Upgrade-Vorgang auf der Wiederherstellungs-Site.

Nach dem Update des SRM-Servers müssen Sie das SRM-Client-Plug-In neu installieren.

  1. Melden Sie sich bei einer Maschine an, auf der eine vSphere-Client-Instanz ausgeführt wird, anhand der Sie eine Verbindung zu SRM herstellen.
  2. Deinstallieren Sie das SRM 5.5-Client-Plug-In.
  3. Melden Sie sich bei einer vSphere-Client-Instanz an und stellen Sie eine Verbindung zu dem vCenter Server her, mit dem der SRM-Server verbunden ist.
  4. Wählen Sie Plug-Ins > Plug-Ins verwalten.
  5. Klicken Sie auf Herunterladen und installieren, um das SRM 5.5.1-Client-Plug-In zu installieren.
  6. Wenn die Installation des Plug-Ins abgeschlossen ist, melden Sie sich bei SRM an und stellen Sie sicher, dass die Konfiguration der vorherigen Version beibehalten wurde.
  7. Wiederholen Sie den Vorgang für alle vSphere-Client-Instanzen, mit denen Sie eine Verbindung zum SRM-Server herstellen.

Upgrade von vSphere Replication auf vSphere Replication 5.5.1

Wenn Sie vSphere Replication mit einer früheren Version von SRM installiert haben und ein Upgrade auf SRM 5.5.1 durchführen, müssen Sie auch vSphere Replication auf Version 5.5.1 aktualisieren. Für die vSphere Replication-Server müssen Sie ebenfalls ein Upgrade auf Version 5.5.1 durchführen. Achten Sie darauf, dass Sie das Upgrade von SRM auf Version 5.5.1 und das Upgrade von vCenter Server auf mindestens Version 5.5 in jedem Fall durchführen, bevor Sie vSphere Replication auf Version 5.5.1 aktualisieren.

  • Verwenden Sie für das Upgrade von vSphere Replication von Version 1.0.x oder 5.1.x auf Version 5.5.1 die herunterladbare ISO-Datei für vSphere Replication 5.5.1.
  • Wenn Sie vSphere Replication von Version 5.5 auf Version 5.5.1 aktualisieren möchten, verwenden Sie entweder die herunterladbare ISO-Datei für vSphere Replication 5.5.1, vSphere Update Manager oder das Virtual Appliance Management Interface (VAMI) der vSphere Replication-Appliance.
  • Wenn Sie vSphere Replication von Version 5.5 auf Version 5.5.1 aktualisieren möchten, während bereits eine neuere Update-Version verfügbar ist, verwenden Sie die herunterladbare ISO-Datei für vSphere Replication 5.5.1 oder fügen Sie in der Option "Angegebenes Repository verwenden" im VAMI die URL https://vapp-updates.vmware.com/vai-catalog/valm/vmw/05d561bc-f3c8-4115-bd9d-22baf13f7178/5.5.1.0 ein.

Weitere Informationen hierzu finden Sie unter Durchführen eines Upgrades von vSphere Replication im Handbuch Installation und Konfiguration von Site Recovery Manager.

WICHTIG: Wählen Sie nicht die Option unter Update > Einstellungen in der VAMI aus, um vSphere Replication automatisch zu aktualisieren. Wenn Sie automatische Updates auswählen, aktualisiert VAMI vSphere Replication auf die neueste Version 5.x, die möglicherweise nicht mit SRM und vCenter Server 5.5.x kompatibel ist. Behalten Sie die Aktualisierungseinstellung Keine automatischen Aktualisierungen bei.

Grenzwerte für den Betrieb von SRM und vSphere Replication

Die Grenzwerte für den Betrieb von SRM 5.5.x und vSphere Replication 5.5.x finden Sie hier: http://kb.vmware.com/kb/2034768.

Informationen zu den Beschränkungen für Schutz und Wiederherstellung bei der Verwendung von SRM 5.5.x und vSphere Replication 5.5.x in einer Konfiguration mit gemeinsam genutzter Wiederherstellungs-Site finden Sie unter http://kb.vmware.com/kb/2008061.

SRM SDKs

Ein Handbuch zur Verwendung der SOAP-basierten API von SRM finden Sie unter VMware vCenter Site Recovery Manager-API.

Open Source-Komponenten

Informationen über Copyright und Lizenzen für die Open Source-Softwarekomponenten, die im Lieferumfang von Site Recovery Manager 5.5.1 enthalten sind, finden Sie unter VMware vCenter Site Recovery Manager-Downloads. Sie können auch die Quelldateien für jede GPL-, LGPL- oder vergleichbare Lizenz herunterladen, die es erfordert, den Quellcode oder Änderungen des Quellcodes für die neueste allgemein verfügbare Version von vCenter Site Recovery Manager zur Verfügung zu stellen.

Probleme und Einschränkungen

  • SRM 5.5.1 bietet eine eingeschränkte Unterstützung für vCloud Director-Umgebungen. Die Verwendung von SRM, um virtuelle Maschinen innerhalb von vCloud-Ressourcenpools (virtuelle Maschinen, die für eine Organisation bereitgestellt wurden) zu schützen, wird nicht unterstützt. Die Verwendung von SRM zum Schützen der Verwaltungsstruktur von vCD wird unterstützt. Informationen dazu, wie SRM zum Schützen der vCD-Serverinstanzen, vCenter Server-Instanzen und Datenbanken verwenden, die die Verwaltungsinfrastruktur für vCloud Director bereitstellen, finden Sie in der VMware vCloud Director-Infrastrukturflexibilitäts-Fallstudie.
  • Windows Server 2003 ist keine unterstützte Plattform für SRM-Server, aber mit dem SRM-Installationsprogramm können Sie SRM unter Windows Server 2003 installieren.
  • vSphere Flash Read Cache ist nach der Wiederherstellung auf virtuellen Maschinen deaktiviert und die Reservierung ist auf Null gesetzt. Merken Sie sich die Cachereservierung der virtuellen Maschine von vSphere Web Client, bevor Sie eine Wiederherstellung auf einer virtuellen Maschine durchführen, die für die Verwendung von vSphere Flash Read Cache konfiguriert ist. Sie können vSphere Flash Read Cache nach der Wiederherstellung auf der virtuellen Maschine neu konfigurieren.

Behobene Probleme

In dieser Version wurden die folgenden Probleme aus früheren Versionen behoben.

  • Wird SRM während des Tests eines Wiederherstellungsplans unerwartet beendet, wird SRM auch beim Versuch, den Test erneut auszuführen, beendet.

    Wird SRM während des Tests eines Wiederherstellungsplans unerwartet beendet, so hat dies zur Folge, dass SRM auch bei jedem erneuten Versuch, den Plan auszuführen, beendet wird. Grund hierfür ist eine Assertion-Prüfung des Status einer virtuellen Maschine, die sich aufgrund der vorzeitig beendeten Testwiederherstellung in einem ungültigen Zustand befindet. Dies wurde behoben.

  • Bei der Neukonfiguration der Replizierung zur Aufnahme einer zuvor ausgeschlossenen Festplatte und Verwendung eines Replizierungsspeichers für diese Festplatte wird der Replizierungsspeicher in vSphere Replication fälschlicherweise entfernt.

    Wird eine Replizierung mit einer ausgeschlossenen Festplatte so neu konfiguriert, dass die Festplatte eingeschlossen wird, und wird danach eine Festplattendatei manuell zur Verwendung als Replizierungsspeicher kopiert, entfernt vSphere Replication die kopierte VMDK-Datei, auch wenn es sich um eine anfängliche Kopie handelt, die nicht durch vSphere Replication erstellt wurde. Daher ist es erforderlich, die VMDK-Datei erneut auf die Ziel-Site zu kopieren. Dies wurde behoben.

  • Das Aufheben der Konfiguration der Replizierungen oder das Ausführen des erneuten Schützens schlägt nach dem Upgrade von SRM und vSphere Replication fehl.

    Wenn Sie eine Testwiederherstellung ohne Durchführung der Bereinigung ausgeführt haben und dann vSphere Replication auf die Version 5.5 aktualisiert haben, schlägt das Aufheben der Konfiguration einer Replizierung oder das Durchführen des erneuten Schützens mit dem folgenden Fehler fehl: VRM-Server - generischer Fehler ... 'Fehler beim Übergeben von Transaktionen'. Dieser Fehler tritt auf, da die Bereinigung der Daten für das Test-Image durch vSphere Replication während des Upgrades in der vSphere Replication-Datenbank fehlschlägt, wodurch weiteres Entfernen der Replizierung verhindert wird. Dies wurde behoben.

  • IP-Anpassung schlägt während einer Wiederherstellung bzw. Testwiederherstellung fehl.

    Bei der Durchführung einer Wiederherstellung bzw. Testwiederherstellung eines Wiederherstellungsplans schlägt die IP-Anpassung für einige oder alle virtuellen Maschinen aus einem der folgenden Gründe fehl:

    • Auf einigen virtuellen Windows-Maschinen mit geänderten Pfaden für temporäre Ordner wird bei der IP-Anpassung am verkehrten Speicherort nach den Ergebnisprotokollen gesucht. Weitere Einzelheiten enthält KB 2021083. Dies wurde behoben.
    • Sofern während der IP-Anpassung auf virtuellen Windows-Maschinen kein Zwischenergebnisprotokoll verfügbar war, wird die Anpassung zwar erfolgreich abgeschlossen, doch wird der Fehler Fehler - Die Anpassung kann nicht abgeschlossen werden, möglicherweise wegen des Laufzeitfehlers eines Skripts oder wegen ungültiger Skriptparameter. (Fehlercode: -1). Einige IP-Einstellungen wurden möglicherweise übernommen. ausgegeben. Dies wurde behoben. Die IP-Anpassung führt nunmehr zu einem korrekten Abschluss.
  • SRM kann VMFS-Volumes nicht mounten, und es wird der Fehler Bereits gemountet ausgegeben.

    Beim Eingang von Informationen von vCenter Server bei SRM zeigt SRM an, dass das Volume, das eine virtuelle Maschine enthält, nicht gemountet ist. Allerdings wird das Volume gleichzeitig erfolgreich vom ESXi-Server gemountet. SRM unternimmt den Versuch, das Volume auf Grundlage der zuvor von vCenter Server erhaltenen Informationen zu mounten, und gibt an, dass das Volume sich in einem ungültigen Zustand befindet und bereits gemountet wurde. Dies wurde behoben.

  • Die SRM-Installation führt zu einem MsiExec-Fehler unter Windows Server 2012 und kann mit dem Fehler FEHLER: Dienst konnte nicht geöffnet werden: ProtectedStorage fehlschlagen.

    Das SRM-Installationsprogramm versucht, den Protected Storage-Dienst zu starten, der jedoch auf Server 2012 nicht vorhanden ist. In den meisten Fällen ist die Installation erfolgreich, doch zeichnet das Windows-Ereignisprotokoll einen MsiExec-Fehler auf. Falls die Windows-Fehlerberichterstattung auf „Ich möchte nicht teilnehmen. Nicht erneut fragen“ eingestellt ist, schlägt die SRM-Installation fehl, und sie wird zurückgesetzt. Dies wurde behoben.

  • Bei mehrmaligem Versuch, eine Verbindung mit vCenter Server oder vSphere Replication Server herzustellen, reagiert der vSphere Replication-Verwaltungsserver aufgrund eines potenziellen Arbeitsspeicherverlusts nicht mehr.

    Dieses Problem wurde in dieser Version behoben.

  • SRM-Dienst wird während einer Testwiederherstellung beim Schritt „SCSI-LUN anhängen“ angehalten.

    Bei Ausführung eines Wiederherstellungsplan-Tests wird der SRM-Dienst während des Schritts „SCSI-LUN anhängen“ unerwartet angehalten. Der Wiederherstellungsplan-Test wird korrekt gestartet und gelangt bis zum Schritt „Snapshot des beschreibbaren Speichers erstellen“, wird dann aber nicht weitergeführt. Im System wird letztendlich angegeben, dass der SRM-Dienst nicht mehr verfügbar ist. Die SRM-Protokolle enthalten den Fehler Panic: Assert Failed: "_completions.find(tag) == _completions.end() (Operation added with duplicate tag)". Nach einem Neustart des SRM-Diensts wird der Test des Wiederherstellungsplans als unvollständig ausgewiesen. Eine erneute Ausführung des Tests schlägt fehl, und als einzige Option steht die Bereinigung zur Verfügung. Dieses Problem tritt auf, wenn SCSI-LUNs doppelte Geräte-IDs aufweisen, z. B. wenn zwei LUNs auf verschiedenen Arrays eine identische ID haben. Dies wurde behoben.

  • Beim Aufrufen des Failovers aus der SRM API wird eine Notfallwiederherstellung durchgeführt.

    Wenn Sie den Failover in SRM 5.0.x und 5.1.x mithilfe der SRM API aufgerufen haben, hat SRM eine geplante Migration durchgeführt. Dies stimmte nicht mit der API-Dokumentation überein. SRM stellt in SRM 5.5 die Konsistenz zwischen der Dokumentation und Implementierung der API durch das Durchführen der Notfallwiederherstellung sicher. Dies ist das korrekte Verhalten.

  • Die geplante Migration schlägt beim Herunterfahren einiger virtueller Maschinen fehl, da diese sich in einem ungültigen Zustand befinden.

    Die geplante Migration schlägt für einige virtuelle Maschinen mit folgendem Fehler fehl: Fehler – SOAP-Antwortfehler von [ virtuelle Maschine] erhalten: shutdownGuest Der versuchte Vorgang kann im aktuellen Zustand (Eingeschaltet) nicht durchgeführt werden. Dieser Fehler wird dadurch verursacht, dass SRM versucht, eine virtuelle Maschine herunterzufahren, während diese sich noch im Prozess der Zustandsänderung befindet. SRM versucht nun 3 Mal, eine virtuelle Maschine herunterzufahren, bevor dieser Fehler gesendet wird. Wird der Fehler weiterhin angezeigt, führen Sie die Wiederherstellung erneut durch.

  • Der SRM-Server wird während des erneuten Schützens bei der erzwungenen Wiederherstellung unerwartet beendet.

    Wenn Sie bei der Verwendung von vSphere Replication und nach der Durchführung einer Wiederherstellung, bei der die Option für die erzwungene Wiederherstellung ausgewählt war, den Vorgang des erneuten Schützens ausführen, wird der SRM-Server mit folgendem Fehler unerwartet beendet: Panic: Assert Failed: "!peerHmsServerRef.IsNull()". Der SRM-Server konnte den vSphere Replication-Remote-Verwaltungsserver nicht finden. Dies wurde behoben.

Bekannte Probleme

Die folgenden bekannten Probleme wurden beim Testen der Software erkannt. Sie helfen Ihnen, das Verhalten, auf das Sie in dieser Version treffen, besser zu verstehen.

  • Die Aufgabe zum Schutz der virtuellen Maschine scheint bei 100 % zu verharren.

    Der Bereich "Kürzlich bearbeitete Aufgaben" vom VI-Client zeigt, dass eine virtuelle Maschine während der Aufgabe VM schützen bei 100 % verharrt. SRM markiert die virtuelle Maschine als Konfiguriert und zeigt damit an, dass sie geschützt wurde. Es sind keine Maßnahmen erforderlich, da SRM die virtuelle Maschine erfolgreich geschützt hat.

  • Datenspeicherbrowser zeigen Datenspeicherordner nicht an, wenn der Datenspeichername bestimmte Zeichen enthält.

    Wenn der Datenspeichername beim Auswählen eines Zieldatenspeicherordners für vSphere Replication bestimmte Zeichen wie öffnende und schließende Klammern oder ein Leerzeichen enthält, zeigt das Datenspeicherbrowserfenster nicht die Unterordner des Datenspeichers an.

    Problemumgehung: Um einen Unterordner eines Datenspeichers auszuwählen, der eine Klammer oder ein Leerzeichen enthält, wählen Sie den Datenspeicher aus und klicken Sie im Datenspeicherbrowser auf die Schaltfläche Öffnen. Dadurch wird der Datenspeicher geöffnet und der Datenspeicherordner wird angezeigt.

  • Beenden der Datenspeicherreplizierung für geschützte virtuelle Maschinen führt zu falschen Fehlermeldungen

    Es ist möglich, eine virtuelle Maschine zu schützen, die über Festplatten auf mehreren Datenspeichern verfügt, und anschließend die Replizierung für einen der Datenspeicher zu deaktivieren. In einem solchen Fall wechselt der Status der virtuellen Maschine in der Schutzgruppe zu Ungültig: Die virtuelle Maschine 'VM' wird nicht mehr geschützt. Interner Fehler: Es kann kein Locator für Festplatte'2001' erstellt werden...Diese Informationen sind falsch. Der Status sollte geändert werden zu Der Datenspeicher '[ Datenspeichername]' wird nicht mehr repliziert.

  • Die Wiederherstellung einer vSphere Replication-Schutzgruppe schlägt mit dem Fehler Der angegebene Schlüssel, Name oder Bezeichner ist bereits vorhanden fehl.

    Falls Sie denselben Datenspeicher wählen, wenn Sie den Platzhalter für eine virtuelle Maschine konfigurieren und vSphere Replication auf dieser virtuellen Maschine konfigurieren, befinden sich der Platzhalter und die Dateien der wiederhergestellten virtuellen Maschine möglicherweise in demselben Pfad. Dies kann während der Wiederherstellung zu Fehlern führen.

    Problemumgehung: Wählen Sie verschiedene Datenspeicher für Platzhalter-VMs und vSphere Replication.

  • Eine virtuelle Maschine mit einer RDM-Festplatte im physischen Modus kann selbst dann nicht konfiguriert werden, wenn die Festplatte von der Replizierung ausgenommen wird.

    Wenn Sie vSphere Replication auf einer virtuellen Maschine mit einer RDM-Festplatte im physischen Modus konfigurieren, erhalten Sie möglicherweise die folgende Fehlermeldung:

    VRM-Server - generischer Fehler. Suchen Sie in der Dokumentation nach Informationen zur Fehlerbehebung. Die detaillierte Ausnahme ist: HMS kann die Festplatten-UUID für Festplatten der VM nicht festlegen: MoRef: type = VirtualMachine, value = , serverGuid = null'.

    Problemumgehung: Keine. Sie können vSphere Replication nicht auf virtuellen Maschinen konfigurieren, die RDM-Festplatten im physischen Modus enthalten.

  • Nicht-ASCII-Kennwörter werden von der VAMI (Virtual Appliance Management Interface) nicht akzeptiert

    Versuche, sich bei der VAMI mittels eines Kontos mit einem Kennwort mit Nicht-ASCII-Zeichen anzumelden, schlagen fehl. Dies geschieht auch dann, wenn die richtigen Authentifizierungsinformationen angegeben werden. Dieses Problem tritt in allen Fällen auf, bei denen Nicht-ASCII-Kennwörter mit VAMI verwendet werden. Verwenden Sie ASCII-Kennwörter oder stellen Sie die Verbindung über SSH her, um dieses Problem zu vermeiden.

  • Der erneute Schutz schlägt mit einer Fehlermeldung der folgenden Art fehl: Kommunikation mit dem Remotehost nicht möglich, da er nicht verbunden ist.

    Dieser Fehler kann darauf zurückzuführen sein, dass der Cluster der geschützten Site auf die Verwendung von Distributed Power Management (DPM) konfiguriert wurde und einer der für den Vorgang erforderlichen ESX-Hosts in den Standby-Modus versetzt wurde. Dies kann auftreten, wenn DPM erkannt hat, dass der Host im Leerlauf war, und ihn daher in den Standby-Modus versetzt hat. SRM musste mit dem Host kommunizieren, um auf den replizierten Datenspeicher zuzugreifen, der von diesem Host verwaltet wurde. SRM verwaltet den DPM-Status auf der geschützten Site nicht, hingegen den DPM-Status während der Wiederherstellung, des Tests und der Bereinigung auf der Wiederherstellungs-Site.

    Problemumgehung: Wenn der Fehler weiterhin anhält, schalten Sie DPM vorübergehend ab und vergewissern Sie sich, dass die ESX-Hosts, die die replizierten Datenspeicher auf der geschützten Site verwalten, eingeschaltet werden, bevor versucht wird, einen erneuten Schutz durchzuführen.

  • Das Unmounten von Datenspeichern schlägt auf DPM-aktivierten Clustern fehl

    Geplante Migrationen und Notfallwiederherstellungen können keine Datenspeicher von an einen DPM-Cluster angehängten Hosts unmounten, wenn der Host in den Standby-Modus wechselt. Folgender Fehler wird möglicherweise angezeigt: Fehler: Es kann kein Unmounten des Datenspeichers Datenspeichername vom Host Hostname durchgeführt werden. Kommunikation mit dem Remotehost nicht möglich, da er nicht verbunden ist. Um dieses Problem zu beheben, schalten Sie DPM an der Schutz-Site aus, bevor Sie die geplanten Migrationen bzw. die Notfallwiederherstellungen durchführen. Sie können DPM nach Abschluss der Wiederherstellungsaufgaben wieder einschalten.

  • SRM stoppt während eines Versuchs, eine bereits erneut geschützte, Array-basierte virtuelle Maschine mithilfe von vSphere Replication zu schützen.

    Wenn Sie eine Wiederherstellung vornehmen und danach versuchen, vSphere Replication zu verwenden, um eine virtuelle Maschine zu schützen, die bereits durch eine Array-basiert Schutzgruppe geschützt ist, setzt sich der SRM-Server durch.

    Problemumgehung: Starten Sie den SRM-Server erneut und heben Sie den Schutz der Array-basierten geschützten virtuellen Maschine auf, bevor Sie sie mithilfe der vSphere Replication schützen. Alternativ können Sie den Array-basierten Schutz fortsetzen und nicht mit vSphere Replication schützen. SRM unterstützt den Schutz durch beide Provider nicht.

  • Bereinigung schlägt fehl, wenn sie innerhalb von 10 Minuten nach dem Neustart der Wiederherstellung der Site-ESXi-Hosts aus dem Wartungsmodus versucht wird.

    Der Bereinigungsvorgang versucht, die Platzhalter auszulagern, und hält sich dabei an den Host-Ausfallsicherheit-Cache, der eine Aktualisierungsspanne von 10 Minuten hat. Wenn Sie einen Auslagerungsvorgang bei ESXi-Hosts versuchen, die innerhalb dieser Zeitspanne von 10 Minuten erneut gestartet wurden, aktualisiert SRM die Informationen im SRM-Host-Ausfallsicherheitscache nicht, und der Auslagerungsvorgang schlägt fehl. Der Bereinigungsvorgang schlägt ebenfalls fehl.

    Problemumgehung: Warten Sie 10 Minuten ab, bevor Sie den Bereinigungsvorgang erneut versuchen.

  • Die Wiederherstellung virtueller Maschinen schlägt aufgrund eines Fehlers bei der Festplattenkonfiguration fehl

    Es ist möglich, verschiedene Festplatten und Konfigurationsdateien für eine einzelne geschützte virtuelle Maschine auf mehreren Datenspeichern zu platzieren. Während der Wiederherstellung muss SRM Zugriff auf die Raw-Festplattenzuordnung und die übergeordneten Festplattendateien haben. Ohne diesen Zugriff kann SRM während der Wiederherstellung nicht die Festplattentypen ermitteln. In solch einem Fall erkennt SRM möglicherweise eine RDM-Festplatte nicht als solche, was dazu führt, dass die Neukonfiguration fehlschlägt. Um dieses Problem zu verhindern, stellen Sie sicher, dass alle Hosts, die auf die Konfigurationsdateien von wiederhergestellten virtuellen Maschinen zugreifen können, auch auf die RDM-Zuordnungsdateien und alle übergeordneten Festplatten zugreifen können, falls solche Festplatten vorhanden sind.

  • Ein erneutes Ausführen des Vorgangs zum erneuten Schützen schlägt mit einem Fehler fehl: Die Schutzgruppe '{protectionGroupName}' verfügt über geschützte VMs mit Platzhaltern, die repariert werden müssen.

    Wenn ein Vorgang ReloadFromPath während des ersten Vorgangs zum erneuten Schützen nicht erfolgreich verläuft, wechseln die entsprechenden geschützten virtuellen Maschinen in den Status repairNeeded. Wenn SRM einen Vorgang zum erneuten Schützen für die Schutzgruppe durchführt, kann SRM die geschützten virtuellen Maschinen nicht reparieren und auch die virtuellen Platzhaltermaschinen nicht wiederherstellen. Der Fehler tritt auf, wenn der erste Vorgang zum erneuten Schützen bei einer virtuellen Maschine fehlschlägt, weil der entsprechende ReloadFromPath-Vorgang fehlschlug.

    Problemumgehung: Führen Sie den Vorgang zum erneuten Schützen mit aktivierter Option Bereinigung erzwingen erneut durch. Diese Option schließt den Vorgang zum erneuten Schützen ab und aktiviert die Option Platzhalter neu erstellen. Klicken Sie auf Platzhalter neu erstellen, um die geschützten virtuellen Maschinen zu reparieren und die virtuellen Platzhaltermaschinen wiederherzustellen.

  • Die Wiederherstellung wird nicht weiter ausgeführt, nachdem eine Verbindung zur Schutz-Site ausgefallen ist

    Falls die Schutz-Site während eines Deaktivierungsvorgangs oder während RemoteOnlineSync bzw. RemotePostReprotectCleanup nicht mehr erreichbar ist (und beide treten während des erneuten Schützens auf), wird der Wiederherstellungsplan möglicherweise nicht weiter ausgeführt. In solch einem Falle wartet das System darauf, dass die virtuellen Maschinen oder Gruppen, die Teil der Schutz-Site waren, diese unterbrochenen Aufgaben fortführen und beenden. Falls dieses Problem während des erneuten Schutzes auftritt, müssen Sie die Verbindung zur ursprünglichen Schutz-Site erneut herstellen und den Wiederherstellungsplan dann abbrechen und neu starten. Falls dieses Problem bei einer Wiederherstellung auftritt, reicht es aus, den Wiederherstellungsplan abzubrechen und neu zu starten.

  • vSphere Replication-Appliance unterstützt gültige ESX-Hosts nicht

    Wenn während der vSphere Replication-Konfiguration für eine unterstützte ESX-Version ein Datenspeicher ausgewählt wird, wird die Meldung Der VR-Server Servername verfügt über keine Hosts, über die auf den Zieldatenspeicher zugegriffen werden kannangezeigt. Dies geschieht beim Hinzufügen eines neuen Hosts zu vCenter Server oder während der Registrierung des vSphere Replication-Servers, wenn die Kommunikation zwischen der vSphere Replication-Appliance und dem vSphere Replication-Server vorübergehend unterbrochen wird. Kommunikationsprobleme treten in der Regel auf, wenn die Verbindung vorübergehend verloren geht oder die Serverdienste gestoppt werden.

    Starten Sie zum Beheben dieses Problems den vSphere Replication-Verwaltungsserver-Dienst neu.

    1. Melden Sie sich bei der VAMI (Virtual Appliance Management Interface) der vSphere Replication-Appliance unter "https://vr_applliance_address:5480" an.
    2. Klicken Sie unter Dienststatus auf Konfiguration > Neu starten.
  • Der wiederhergestellte VMFS-Datenträger mountet nicht und meldet folgenden Fehler: Der Datenspeicher konnte nicht wiederhergestellt werden.

    Dieser Fehler kann auftreten, wenn eine Latenz zwischen vCenter, ESXi und dem SRM-Server besteht.

    Problemumgehung: Führen Sie den Wiederherstellungsplan erneut aus.

  • Wenn die LUNs der Schutzsite auf "Keine Pfade verfügbar" (All Paths Down, APD) oder "Permanenter Geräteverlust" (Permanent Device Loss, PDL) stoßen, kann SRM gegebenenfalls Raw-Festplattenzuordnungs-LUNs (Raw Disk Mapping, RDM) nicht wiederherstellen.

    Während des ersten Versuchs einer geplanten Migration sehen Sie gegebenenfalls folgende Fehlermeldung, wenn SRM versucht, die geschützte virtuelle Maschine herunterzufahren:

    Fehler - Der Vorgang kann zurzeit nicht zugelassen werden, weil noch eine Anfrage für die virtuelle Maschine offen ist: 'msg.hbacommon.askonpermanentdeviceloss: Bei dem Speicher, der die virtuelle Festplatte VM1-1.vmdk stützt, kommt es zu permanentem Geräteverlust. Möglicherweise können Sie dieses virtuelle Gerät im laufenden Betrieb von der virtuellen Maschine entfernen und nach dem Klicken auf "Wiederholen" fortfahren. Klicken Sie auf "Abbrechen", um diese Sitzung zu beenden.

    Wenn die geschützten virtuellen Maschinen RDM-Geräte haben, stellt in einigen Fällen SRM die RDM LUN nicht wieder her.

    Problemumgehung:

    1. Wenn LUNs in APD/PDL eintreten, markiert ESXi Server alle entsprechenden virtuellen Maschinen mit einer Frage, die Vorgänge der virtuellen Maschine blockiert.
      1. Bei PDL klicken Sie auf Abbrechen, um die virtuelle Maschine abzuschalten.
      2. Bei APD klicken Sie auf Wiederholen.

      Wenn Sie eine geplante Migration durchführen, schaltet SRM virtuelle Maschinen in der Produktionsumgebung nicht ab.
    2. Wenn die virtuellen Maschinen RDM-Geräte haben, kann SRM die Spur des RDM-Geräts verlieren und nicht wiederherstellen. Führen Sie eine erneute Prüfung aller HBAs durch und achten Sie darauf, dass alle betroffenen LUNs aus dem APD/PDL-Status zurückgekehrt sind.
    3. Prüfen Sie die vCenter Server-Bestandsliste und beantworten Sie die PDL-Frage, die die virtuelle Maschine blockiert.
    4. Wenn Sie die PDL-Frage beantworten, bevor die LUNs wieder online sind, erkennt der SRM-Server auf der geschützten Site fälschlicherweise, dass das RDM-Gerät nicht mehr an dieser virtuellen Maschine angehängt ist und entfernt das RDM-Gerät. Wenn Sie das nächste Mal eine Wiederherstellung ausführen, stellt SRM diese LUN nicht wieder her.
    5. Prüfen Sie alle HBAs erneut, um sicherzugehen, dass alle LUNs in der vCenter Server-Bestandsliste online sind, und schalten Sie alle betroffenen virtuellen Maschinen ein. vCenter Server verbindet die verlorenen RDMs mit geschützten virtuellen Maschinen.
    6. Prüfen Sie die Registerkarte Array-Manager in der SRM-Schnittstelle. Wenn alle geschützten Datenspeicher und RDM-Geräte nicht angezeigt werden, klicken Sie auf Aktualisieren, um die Geräte zu erkennen und die Datenspeichergruppen erneut zu berechnen.
    7. Achten Sie darauf, dass die Option Gruppeneinstellungen anzeigen alle geschützten Datenspeicher und RDM-Geräte anzeigt und der Schutzstatus der virtuellen Maschinen keine Fehler aufweist.
    8. Starten Sie eine geplante Migration, um alle geschützten LUNs, einschließlich der RDM-Geräte, wiederherzustellen.
  • Während Sie eine virtuelle Maschine erneut schützen, kann die folgende Fehlermeldung während des Schritts "Schutz für die umgekehrte Richtung konfigurieren" auftreten: Fehler - Der Vorgang wurde für die Schutzgruppe 'Schutzgruppenname' nur teilweise ausgeführt, da eine zur Gruppe gehörende geschützte VM den Vorgang nicht erfolgreich abschließen konnte. Die virtuelle Maschine 'VM-Name' wird nicht von VR repliziert.

    Dieser Fehler tritt während des zweiten Vorgangs des erneuten Schutzes auf, wenn der erste Vorgang mit dem Fehler Zeitüberschreitung beim Vorgang während des Schritts "Speicher für die umgekehrte Richtung konfigurieren" fehlgeschlagen ist.

    Problemumgehung: Konfigurieren Sie die Umkehrung der Replizierung manuell für die betroffenen virtuellen Maschinen und führen Sie den Vorgang zum erneuten Schutz erneut aus. Informationen zur Umkehrung der Replizierung finden Sie unter Verwaltung von vSphere Replication: Failback von virtuellen Maschinen in vSphere Replication.

  • Der vorübergehende Verlust von vCenter Server-Verbindungen kann zu Wiederherstellungsproblemen bei virtuellen Maschinen mit Raw-Festplattenzuordnungen führen

    Falls die Verbindung mit vCenter Server während einer Wiederherstellung verloren geht, kann einer der folgenden Zustände eintreten:

    • vCenter Server bleibt weiterhin nicht verfügbar und die Wiederherstellung schlägt fehl. Um dieses Problem zu beheben, stellen Sie die Verbindung mit vCenter Server wieder her und führen Sie die Wiederherstellung erneut durch.
    • In seltenen Fällen steht vCenter Server erneut zur Verfügung und die virtuelle Maschine wurde wiederhergestellt. Sofern die virtuelle Maschine über Raw-Festplattenzuordnungen verfügt, werden diese in einem solchen Fall möglicherweise nicht ordnungsgemäß zugeordnet. Da die Raw-Festplattenzuordnungen nicht ordnungsgemäß zugeordnet wurden, kann es vorkommen, dass die virtuelle Maschine nicht eingeschaltet werden kann oder Fehler im Zusammenhang mit dem Gastbetriebssystem oder Anwendungen auf dem Gastbetriebssystem auftreten können.
      • Falls es sich um eine Testwiederherstellung handelt, führen Sie einen Bereinigungsvorgang durch und wiederholen Sie den Test.
      • Handelt es sich um eine tatsächliche Wiederherstellung, müssen Sie die richtige Raw-Festplattenzuordnung manuell zur wiederhergestellten virtuellen Maschine hinzufügen.

    Weitere Informationen über das Hinzufügen von Raw-Festplattenzuordnungen finden Sie in der vSphere-Dokumentation über das Bearbeiten von Einstellungen der virtuellen Maschine.

  • Abbrechen des Wiederherstellungsplans nicht abgeschlossen

    Beim Ausführen eines Wiederherstellungsplans wird versucht, virtuelle Maschinen zu synchronisieren. Es ist möglich, den Wiederherstellungsplan abzubrechen. Allerdings wird die Planausführung nur nach Abschluss bzw. Ablauf der Synchronisierung abgebrochen. Die Standardeinstellung für den Ablauf beträgt 60 Minuten. Die folgenden Optionen können zum Abbrechen des Wiederherstellungsplans verwendet werden:

    • Unterbrechen der vSphere Replication, was dazu führt, dass die Synchronisierung fehlschlägt. Verwenden Sie, sobald die Wiederherstellung einen Fehlerzustand aufweist, den vSphere-Client, um auf der gleichnamigen Registerkarte vSphere Replication neu zu starten. Nach dem Neustart der Replizierung kann bei Bedarf der Wiederherstellungsplan erneut ausgeführt werden.
    • Warten Sie, bis die Synchronisierung abgeschlossen ist oder eine Zeitüberschreitung eintritt. Dies kann einige Zeit dauern, wird jedoch irgendwann beendet. Nachdem die Synchronisierung beendet oder abgelaufen ist, wird der Abbruch des Wiederherstellungsplans fortgesetzt.

  • Fehler im Wiederherstellungsplan beim Herunterfahren der geschützten virtuellen Maschinen: Fehler - Zeitüberschreitung beim Vorgang: 900 Sekunden während des Herunterfahrens von virtuellen Maschinen beim Schutz-Site-Schritt.

    Wenn Sie SRM zum Schutz von Datenspeichern auf Arrays einsetzen, die dynamische Auslagerung verwenden, beispielsweise Clariion, kann es bei einer Notfallwiederherstellung, bei der die geschützte Site teilweise heruntergefahren ist oder eine erzwungene Wiederherstellung läuft, zu Fehlern führen, sofern der Wiederherstellungsplan für den Betrieb an der geschützten Site erneut durchgeführt wird. Ein derartiger Fehler tritt auf, wenn die geschützte Site wieder online ist, aber SRM nicht in der Lage ist, die geschützten virtuellen Maschinen herunterzufahren. Dieser Fehler tritt in der Regel auf, wenn bestimmte Arrays die geschützten LUNs mit Schreibschutz versehen, sodass ESXi nicht in der Lage ist, die E/A-Vorgänge für eingeschaltete geschützte virtuelle Maschinen abzuschließen.

    Problemumgehung: Starten Sie die ESXi-Hosts an der geschützten Site neu, die schreibgeschützte LUNs aufweisen.

  • Geplante Migration schlägt fehl mit Fehler: Die Konfigurationsdatei konnte nicht kopiert werden...

    Wenn zwei ESXi-Hosts in einem Cluster untergebracht sind und ein Host die Konnektivität mit dem Speichermedium verliert, kann der andere Host in der Regel die replizierten virtuellen Maschinen wiederherstellen. In manchen Fällen kann der andere Host die virtuellen Maschinen nicht wiederherstellen und die Wiederherstellung schlägt mit der folgenden Meldung fehl: Fehler: Die Konfigurationsdatei konnte nicht kopiert werden...

    Problemumgehung: Führen Sie die Wiederherstellung erneut durch.

  • Nach dem Wiederherstellen eines Snapshots kommt es zu einem Stillstand der Replizierung, wenn dieser Snapshot aufgenommen wurde, während die Replizierung angehalten wurde.

    Wenn Sie die Replizierung für eine virtuelle Maschine konfigurieren und die Replizierung anhalten, einen Snapshot aufnehmen, anschließend die Replizierung fortsetzen und den Snapshot wiederherstellen, anstatt in den Status "Angehalten" zu wechseln, ändert sich der Replizierungsstatus in der Benutzeroberfläche nicht und macht keinen Fortschritt.

    Problemumgehung: Halten Sie die Replizierung an und setzen Sie sie dann fort.

  • vSphere Replication-Vorgänge schlagen manchmal mit dem Fehler "Zeitüberschreitung beim Lesen" fehl.

    vSphere Replication-Vorgänge schlagen manchmal mit dem Hauptursachenfehler java.net.SocketTimeoutException: Zeitüberschreitung beim Lesen fehl. Dies kann auftreten, wenn der ESXi Server-Host zu langsam ist oder viele andere Vorgänge wie z. B. Storage vMotion gleichzeitig mit der vSphere Replication ausführt, die Replizierungen konfiguriert, neu konfiguriert, stoppt oder umkehrt. Der folgende Fehler tritt bei einer umgekehrten Replizierung auf: Die Replizierung für die virtuelle Maschine virtual_machine kann nicht umgekehrt werden. VRM-Server - generischer Fehler. Suchen Sie in der Dokumentation nach Informationen zur Fehlerbehebung. Die detaillierte Ausnahme ist: 'java.net.SocketTimeoutException: Zeitüberschreitung beim Lesen'

    Problemumgehung: Führen Sie den Vorgang erneut durch, wenn andere Vorgänge auf dem ESXi Server abgeschlossen wurden.

  • vSphere Replication-Vorgänge schlagen mit dem Fehler "Keine Authentifizierung" fehl.

    Wenn Sie einen Vorgang auf einer SRM-Site starten, beispielsweise das Konfigurieren von vSphere Replication auf einer virtuellen Maschine, und dann vCenter Server und die vSphere Replication-Appliance auf einer anderen Site neu starten, können die vSphere Replication-Vorgänge mit dem folgenden Fehler fehlschlagen: VRM-Server - generischer Fehler. Suchen Sie in der Dokumentation nach Informationen zur Fehlerbehebung. Die detaillierte Ausnahme ist: 'com.vmware.vim.binding.vim.fault.NotAuthenticated'. Dieses Problem wird dadurch verursacht, dass der vSphere Replication-Server in seinem Cache die Verbindungssitzung vor dem Neustart von vCenter Server und der vSphere Replication-Appliance beibehält.

    Problemumgehung: Löschen Sie den vSphere Replication-Verbindungscache, indem Sie den SRM-Client oder vSphere Web Client abmelden und wieder anmelden.

  • Die Bereinigung einer Testwiederherstellung schlägt fehl, nachdem ESXi-Hosts in den Wartungsmodus versetzt und aus diesem geholt wurden.

    Falls Sie eine Testwiederherstellung durchführen, wenn sich ESXi-Hosts auf der Wiederherstellungs-Site im Wartungsmodus befinden, schlägt die Testwiederherstellung wie erwartet fehl. Wenn Sie die ESXi-Hosts aus dem Wartungsmodus holen und die Bereinigung durchführen, schlägt die Bereinigung mit Fehlern fehl, nach denen sich die Hosts weiterhin im Wartungsmodus befinden.

    Problemumgehung: Nachdem Sie die Hosts aus dem Wartungsmodus geholt haben, warten Sie etwa zehn Minuten bis zur Ausführung der Bereinigung. Starten Sie alternativ den SRM-Server neu, nachdem Sie die Hosts aus dem Wartungsmodus geholt haben, bevor Sie die Bereinigung ausführen.

  • Der vSphere-Client kann nicht auf einem Domänencontroller installiert werden.

    In vorherigen Versionen war es möglich, den vSphere-Client auf einer Hostmaschine zu installieren, bei der es sich um einen Active Directory-Domänencontroller handelt. Wenn das vSphere-Installationsprogramm Active Directory-Dienste in vSphere 5.5 erkennt, können Sie den vSphere-Client nicht installieren.

    Problemumgehung: Installieren Sie den vSphere-Client, bevor Sie die Active Directory-Dienstrollen installieren oder den Server zu einem Active Directory-Domänencontroller heraufstufen.

  • Der SRM-Server wird während der Vorgänge zum erneuten Schützen unerwartet auf der Schutz-Site gestoppt.

    Der SRM-Server auf der geschützten Site wird möglicherweise unerwartet beendet, wenn Sie direkt nach einer erfolgreich geplanten Migration einen Vorgang zum erneuten Schützen beginnen. Dies geschieht aufgrund einer Verzögerung beim Auffinden der Liste der replizierten Geräte auf dem Speicher-Array nach einer geplanten Migration. Wenn dieses Problem auftritt, wird in den Protokollen folgender Fehler angezeigt:

    Fehler - Das Umkehren der Replizierung für Geräte mit Failover ist fehlgeschlagen. Der SRA-Befehl 'prepareReverseReplication' ist fehlgeschlagen. Die Adresse des Speicher-Arrays kann nicht erreicht werden. Das Speicher-Array ist möglicherweise ausgefallen oder die eingegebene IP-Adresse ist möglicherweise falsch. Stellen Sie sicher, dass das Speicher-Array aktiv ist und ausgeführt wird und dass die IP-Adresse des Speicher-Arrays über die Befehlszeilenschnittstelle erreichbar ist.

    Problemumgehung: Warten Sie nach dem Durchführen der Wiederherstellung ungefähr 10 Minuten, bevor Sie das erneute Schützen ausführen.

  • vSphere Replication-Serverregistrierung kann abhängig von der Anzahl der Hosts in der vCenter Server-Bestandsliste sehr lange dauern.

    Wenn die vCenter Server-Bestandsliste einige hundert Hosts oder mehr enthält, benötigt die Aufgabe VR-Server registrieren 10 bis 20 Minuten für ihren Abschluss, da vSphere Replication die SSL-Fingerabdruckregistrierung jedes Hosts aktualisiert.

    Problemumgehung: Warten Sie, bis die Registrierungsaufgabe abgeschlossen ist. Nachdem sie abgeschlossen ist, können Sie vSphere Replication für ankommende Replizierungsvorgänge verwenden. Weitere Informationen finden Sie auch unter vSphere Replication-Serverregistrierung dauert einige Minuten.

  • Das Ausführen des erneuten Schützens auf wiederhergestellten virtuellen Maschinen mit Snapshots schlägt mit einem Fehler eines gesperrten Datenspeichers fehl, wenn Sie ESXi Server 5.0 verwenden.

    Wenn Sie eine virtuelle Maschine wiederherstellen, die Sie mit vSphere Replication schützen, und wenn die virtuelle Maschine über Snapshots verfügt, führt das Ausführen des erneuten Schützens nach der Wiederherstellung zu einem Fehler eines gesperrten Datenspeichers. Dieser Fehler tritt nur auf, wenn Sie ESXi Server 5.0 ausführen und wenn Sie die erweiterten Einstellungen nicht ausgewählt haben, um mehrere Point-in-Time-Snapshots (MPIT) auf der Wiederherstellung beizubehalten.

    Problemumgehung: Entfernen Sie die Replizierung aus der wiederhergestellten virtuellen Maschine und konfigurieren Sie dann vSphere Replication neu. Anschließend können Sie das erneute Schützen durchführen.

  • Das Ausführen eines Wiederherstellungsplans schlägt mit einem Fehler der virtuellen Maschine beim Schritt zum Konfigurieren des Speichers fehl.

    Nachfolgende Ausführungen des Wiederherstellungsplans schlagen für dieselbe virtuelle Maschine bei demselben Schritt zum Konfigurieren des Speichers mit dem Fehler Der angegebene Schlüssel, Name oder Bezeichner ist bereits vorhanden. fehl. Wenn Sie in die vCenter Server-Bestandsliste schauen, sehen Sie zwei virtuelle Maschinen mit demselben Namen wie die fehlgeschlagene virtuelle Maschine, von denen sich eine im Ordner "Discovered Virtual Machines" befindet. Dieses Problem wird durch ein bekanntes Kommunikationsproblem zwischen vCenter Server und der ESXi Server-Instanz verursacht.

    Problemumgehung: Heben Sie die Registrierung der doppelten virtuellen Maschine im Ordner "Discovered Virtual Machines" von vCenter Server auf. Führen Sie anschließend den Wiederherstellungsplan für alle betroffenen virtuellen Maschinen erneut aus.

  • Die schnelle Durchführung der Testwiederherstellung nach dem Ausführen eines Bereinigungsvorgangs führt zu einem Fehler.

    Wenn Sie eine Testwiederherstellung nach dem Ausführen eines Bereinigungsvorgangs nach einer vorherigen Testwiederherstellung zu schnell durchführen, kann die Wiederherstellung mit dem Fehler Die Datei ist bereits vorhanden fehlschlagen. Dies geschieht in der Regel, wenn Sie die Testwiederherstellung von einem Automatisierungscode anstatt von einer SRM-Schnittstelle ausführen.

    Problemumgehung: Warten Sie einige Minuten und versuchen Sie dann, den Vorgang erneut durchzuführen.

  • Das Ausführen mehrerer vCenter Server-Instanzen im verknüpften Modus führt zur Anzeige doppelter SRM-Rollen

    Wenn Sie die vCenter Server-Instanzen auf den Schutz- und Wiederherstellungs-Sites zum Ausführen im verknüpften Modus konfigurieren, werden doppelte SRM-Rollen im Fenster "Berechtigungen zuweisen" angezeigt.

    Problemumgehung: Bearbeiten Sie die SRM-Rollen auf jeder vCenter Server-Instanz, um sie mit eindeutigen Namen bereitzustellen.

  • Die Konfiguration des Schutzes schlägt mit einem Fehler bezüglich der Platzhaltererstellung fehl

    Gleichzeitiges Erstellen des Schutzes auf vielen virtuellen Maschinen schlägt entweder mit einem Zeitüberschreitungsfehler oder einem Benennungsfehler bezüglich der Platzhaltererstellung fehl.

    • Fehler bezüglich der Erstellung einer Platzhalter-VM:Zeit für Vorgang überschritten:300 Sekunden
    • Fehler bezüglich der Erstellung einer Platzhalter-VM: Der Name 'Platzhaltername' ist bereits vorhanden

    Problemumgehung: Weitere Informationen finden Sie im Abschnitt Die Konfiguration des Schutzes schlägt mit einem Fehler bezüglich der Platzhaltererstellung fehl in der SRM 5.5-Verwaltung.

  • In einer Konfiguration der gemeinsam genutzten Wiederherstellungs-Site schlagen Vorgänge mit dem Fehler Die Verbindung zum Remoteserver ist unterbrochen fehl.

    Vorgänge zur Testwiederherstellung, zur Wiederherstellung und zum erneuten Schützen können in einer gemeinsam genutzten Konfiguration der Wiederherstellungs-Site fehlschlagen, wenn der vSphere Replication-Server eine schwere Arbeitslast zu bewältigen hat.

    Problemumgehung: Führen Sie gleichzeitige Vorgänge nicht auf mehr als 200 virtuellen Maschinen mit maximal 20 virtuellen Maschinen pro Schutz-Site durch.

  • Während der Replizierung mehrerer virtueller Maschinen wechselt der vSphere Replication-Server möglicherweise in einen Zustand, bei dem er keine weiteren VRMS-Verbindungen akzeptiert, die virtuellen Maschinen allerdings weiterhin repliziert.

    Problemumgehung: Starten Sie den vSphere Replication-Server neu.

  • Das Verschieben mehrerer Replizierungen von einem vSphere Replication-Server zu einem anderen führt zu einem Fehler.

    vSphere Replication-Neukonfiguration oder Verschiebevorgänge schlagen mit dem Fehler SocketTimeoutException: Zeitüberschreitung beim Lesen fehl und Replizierungen werden in den Fehlerzustand versetzt. Wenn der Quell- bzw. Zielserver von vSphere Replication und der Speicher stark ausgelastet sind, kann das Verschieben einer Replizierung ein paar Minuten dauern und zu einem Zeitüberschreitungsfehler führen.

    Problemumgehung: Konfigurieren Sie die Replizierung auf dem neuen vSphere Replication-Server neu.

  • Testwiederherstellung einer virtuellen Maschine mit RDM schlägt im Schritt „Speicher konfigurieren“ während des Einschaltens der virtuellen Maschine fehl.

    Testwiederherstellung schlägt in den folgenden Situationen fehl:

    • Eine virtuelle Maschine, auf der RDM konfiguriert ist, ist auf der primären Site geschützt.
    • Unter Sites > Ressourcenzuordnungen ist die Ressource der geschützten Site, die die virtuelle Maschine enthält, einer vApp als Ressource der sekundären Site zugeordnet.

    Problemumgehung: Ordnen Sie die virtuelle Maschine einem Ressourcentyp auf der sekundären Site zu, der keine vApp ist, z. B. einem Host.

  • Die Testbereinigung schlägt mit einer Fehlermeldung über das Unmounten des Datenspeichers fehl.

    Die Ausführung einer Bereinigung nach einer Testwiederherstellung kann mit dem folgenden Fehler fehlschlagen: Fehler - Unmounten für Datenspeicher ' Datenspeichername' von Host ' Hostname' kann nicht ausgeführt werden. Der Vorgang ist im aktuellen Zustand nicht zulässig. Dieses Problem tritt auf, wenn der Host das Unmounten für den Datenspeicher bereits durchgeführt hat, bevor Sie den Bereinigungsvorgang ausführen.

    Problemumgehung: Führen Sie den Bereinigungsvorgang erneut aus.

  • Die geplante Migration schlägt während vSphere vMotion mit einem Fehler beim Schritt "VMs auf der Schutz-Site herunterfahren" fehl.

    Wird vSphere vMotion einer geschützten virtuellen Maschine während der geplanten Migration ausgeführt, wenn der Schritt "VMs auf der Schutz-Site herunterfahren" startet, schlägt der Schritt möglicherweise mit dem Fehler Fehler - Der versuchte Vorgang kann im aktuellen Zustand nicht durchgeführt werden (eingeschaltet) fehl. Dies geschieht, weil hostd die Herunterfahr- und Ausschaltvorgänge während der Migration der virtuellen Maschine fehlerhaft ausführt. Dies wurde behoben.

  • MAC-Adresse des VNIC der virtuellen Maschine bleibt in der Regel während der Wiederherstellung erhalten.

    Unter sehr seltenen Umständen kann es sein, dass der Test oder die Wiederherstellung eine bestimmte virtuelle Maschine nicht wiederherstellen kann, weil vCenter unerwarteterweise der VNIC der virtuellen Maschine auf der Wiederherstellungs-Site eine neue MAC-Adresse zugewiesen hat. Die Fehlermeldung in der Ergebnisspalte der Wiederherstellungsschritte lautet: Fehler - Die Anpassung kann nicht abgeschlossen werden, möglicherweise wegen des Laufzeitfehlers eines Skripts oder wegen ungültiger Skriptparameter. (Fehlercode: 255). Einige IP-Einstellungen wurden möglicherweise übernommen. Die SRM-Protokolle enthalten eine Meldung: Fehler beim Suchen des angegebenen Netzwerkadapters für die MAC-Adresse = xx::xx:xx:xx:xx, wobei xx::xx:xx:xx:xx die erwartete MAC-Adresse ist.

    Problemumgehung: Ändern Sie die MAC-Adresse der betroffenen virtuellen Maschine manuell in den Eigenschaften der virtuellen Maschine des vSphere-Clients auf "xx::xx:xx:xx:xx" und starten Sie den Wiederherstellungsplan erneut.

  • Ereignisse werden auf Betriebssystemen in traditionellem Chinesisch nicht ordnungsgemäß angezeigt

    Wenn der vSphere-Client gestartet wird, ermittelt er das Gebietsschema, auf dem er ausgeführt wird, und wählt die anzuzeigenden Meldungen gemäß des Gebietsschemas aus. Wenn der vSphere-Client auf einem Betriebssystem in traditionellem Chinesisch installiert ist, fordert der Client Meldungen aus dem Ordner zh_TWder vCenter Server-Installation an, weil vCenter Server und der vSphere-Client für traditionelles Chinesisch lokalisiert sind. vCenter Server und der vSphere-Client sind für traditionelles Chinesisch lokalisiert, SRM aber nicht. Daher werden XXX- statt SRM-Servermeldungen angezeigt.

    Problemumgehung:

    1. Erstellen Sie eine Kopie des Ordners en, der sich im folgenden Verzeichnis befindet: C:\Program Files\VMware\Infrastructure\VirtualCenter Server\extensions\com.vmware.vcDr\locale\.
    2. Benennen Sie den Ordner von enin zh_TWum.
    3. Starten Sie vCenter Server und die SRM-Dienste neu.
  • IP-Anpassung schlägt aufgrund einer Zeitüberschreitung beim Hochladen von Anpassungsskripts auf virtuelle Maschinen über VIX API fehl.

    Das Hochladen von IP-Anpassungsskripts auf virtuelle Maschinen anhand von VIX schlägt bei Ausführung von Wiederherstellungsplänen mit einer Zeitüberschreitung fehl.

    Problemumgehung: Keine.

  • Der SRM-Server wird unerwartet beendet, wenn eine Testbereinigung nach dem Upgrade auf SRM 5.5.1 ohne Upgrade der SRAs ausgeführt wird.

    Wenn Sie bei Verwendung der arraybasierten Replizierung ein Upgrade von SRM auf Version 5.5.1 durchführen, ohne die SRAs ebenfalls zu aktualisieren, wird der SRM-Server bei Ausführung einer Testbereinigung unerwartet angehalten.

    Problemumgehung: Führen Sie ein Upgrade der SRAs auf die für 5.5.1 geeignete Version durch.

  • Die Anzahl der Pro-CPU-Lizenzen ist nicht korrekt

    Einige Kunden, die SRM 1.x und SRM 4.0 erworben haben, verwenden möglicherweise immer noch Pro-CPU-Lizenzen anstelle von Pro-VM-Lizenzen. Möglicherweise werden weniger Pro-CPU-Lizenzen gewährt als von SRM 5.5 erfordert werden.

    Problemumgehung: Keine.

  • Das erneute Schützen schlägt nach dem Neukonfigurieren der Replizierung einer virtuellen Maschine zum ursprünglichen Platzhalterordner der virtuellen Maschine fehl.

    Wenn Sie vSphere Replication aus einer virtuellen Maschine entfernen, die Sie in eine Schutzgruppe sowie einen Wiederherstellungsplan aufgenommen haben, danach die Replizierung auf der virtuellen Maschine neu konfigurieren und die Option Zielordner angeben verwenden, um den ursprünglichen Platzhalter-Datenspeicherordner der virtuellen Maschine auszuwählen, verläuft die Wiederherstellung zwar erfolgreich, aber das erneute Schützen schlägt mit folgendem Fehler fehl: Fehler: Die Replizierung für die virtuelle Maschine ' virtuelle_Maschine' kann nicht umgekehrt werden. Eine wiederhergestellte Festplatte wurde für die replizierte Festplatte mit UUID nicht gefunden.

    Problemumgehung: Erstellen Sie beim Neukonfigurieren von vSphere Replication auf virtuellen Maschinen, die bereits in einer SRM-Schutzgruppe enthalten sind, die Schutzgruppe neu. Verwenden Sie beim Konfigurieren der Replizierung nicht die Option Zielordner angeben.

  • X-vMotion einer virtuellen Maschine mit Virtual SAN aus einem High Availability (HA)-Cluster kann zu einem Alarm führen.

    Wenn Sie X-vMotion einer virtuellen Maschine mit Virtual SAN aus einem HA-Cluster zu einem anderen Cluster und zu einem anderen Speicher durchführen, meldet die virtuelle Maschine einen Alarm ähnlich dem folgenden: Failover der virtuellen vSphere HA-Maschine fehlgeschlagen.

    Problemumgehung: Keine.