VMware vCenter Site Recovery Manager 5.1.2 | 16. Januar 2014 | Build 1527967

Letzte Aktualisierung: 28. Januar 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.1.2

VMware vCenter Site Recovery Manager 5.1.2 weist die im Abschnitt Behobene Probleme beschriebenen Fehlerkorrekturen auf.

Lokalisierung

VMware vCenter Site Recovery Manager 5.1.2 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.1.

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 VSA-Unterstützung

SRM 5.1.2 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.1.2 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.1.2 finden Sie in den VMware vCenter Site Recovery Manager-Ressourcen für Business Continuity.

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.1.2

Um SRM 5.1.2 neu zu installieren, laden Sie das Installationsprogramm VMware-srm-5.1.2-1527967.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.1.

Upgrade einer vorhandenen SRM 4.1.2-Installation auf SRM 5.1.2

Führen Sie ein Upgrade von SRM 4.1.2 auf SRM 5.0.x durch, bevor Sie ein Upgrade auf SRM 5.1.2 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.1.2 ist ein unterstützter Upgrade-Pfad. Allerdings ist ein direktes SRM-Upgrade von Version 4.1.2 auf Version 5.1.2 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.1.2 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.1.x 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.1.x-Instanz herstellen.

Upgrade einer vorhandenen SRM 5.0.x-Installation auf SRM 5.1.2

Um ein Upgrade einer vorhandenen SRM 5.0.x-Installation auf SRM 5.1.2 durchzuführen, laden Sie das Installationsprogramm VMware-srm-5.1.2-1527967.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.1.

Upgrade einer vorhandenen SRM 5.1.x-Installation auf SRM 5.1.2

Führen Sie die folgenden Schritte aus, um ein Upgrade einer vorhandenen SRM 5.1.x-Installation auf SRM 5.1.2 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.1.2-1527967.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 Upgrade 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.1-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.1.2-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.1.2

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

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

Um ein Upgrade der vSphere Replication-Appliance und etwaiger weiterer vSphere Replication-Server auf Version 5.1.2 über die VAMI (Virtual Appliance Management Interface) durchzuführen, verwenden Sie die folgende URL:

http://vapp-updates.vmware.com/vai-catalog/valm/vmw/05d561bc-f3c8-4115-bd9d-22baf13f7178/5.1.2.0

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.1.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.1.x und vSphere Replication 5.1.x finden Sie hier: http://kb.vmware.com/kb/2034768.

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.1.2 enthalten sind, finden Sie unter Herunterladen von VMware vCenter Site Recovery Manager. 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

  • Interoperabilität mit Storage vMotion und Storage DRS
    Aufgrund einiger weniger Fälle, bei denen die Wiederherstellbarkeit während der Speicherverschiebung beeinträchtigt werden kann, wird Site Recovery Manager 5.1.2 weder für die Verwendung mit Storage vMotion (SVmotion) noch für die Verwendung mit SDRS (Storage Distributed Resource Scheduler), einschließlich der Verwendung eines Datenspeicher-Clusters, unterstützt.

  • Interoperabilität mit vCloud Director
    Site Recovery Manager 5.1.2 bietet nur 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.

  • Die Interoperabilität mit vSphere Replication
    vSphere Replication unterstützt eine maximale Festplattengröße von 2032 GB.

  • SRM 5.1.2 unterstützt 2 Microsoft Cluster Server-Knoten (MSCS)
    vSphere 5.1.x unterstützt bis zu 5 MSCS-Knoten. SRM 5.1.x unterstützt 2 MSCS-Knoten. Weitere Informationen hierzu finden Sie unter Schützen von MSCS und fehlertoleranten virtuellen Maschinen im Administratorhandbuch für Site Recovery Manager.

  • Die vSphere Replication-Appliance und vSphere Replication-Server-Appliances unterliegen der Novell Security Advisory CVE-2008-5161
    Novell Security Advisory CVE-2008-5161 bezieht sich auf SUSE Linux Enterprise Server (SLES) SP1, das Betriebssystem für die vSphere Replication-Appliance und vSphere Replication-Server-Appliances. Novell teilt im Dokument unter http://support.novell.com/security/cve/CVE-2008-5161.html mit, dass die Sicherheitsrisiken niedrig sind. Um die Sicherheitsrisiken bei Bedarf weiter zu reduzieren, können Sie anhand von Novell Advisory Ihre SSH-Konfigurationen anpassen. Im Falle der vSphere Replication-Appliance und der vSphere Replication-Server-Appliances können Sie nur die AES-Verschlüsselungen beibehalten, indem Sie die folgende Direktive in die Dateien sshd_config und ssh_config einfügen:

  • Ciphers aes128-ctr,aes256-ctr

    Deaktivieren Sie RC4 und alle anderen CBC-Verschlüsselungen, einschließlich arcfour256, arcfour, aes128-cbc und aes256-cbc.

  • Windows Server 2003 unterstützt keine SHA256RSA-Zertifikate. Für die Installation von SRM 5.1.2 unter Windows Server 2003 und Verwendung von benutzerdefinierten, signierten SHA256RSA-Zertifikaten müssen Sie eines der folgenden Hotfixes von Microsoft installieren:

  • ESXi Server 5.0.0 und 5.0.1 sowie ESXi Server 5.1.0 unterstützen nicht die Anpassung von Gastbetriebssystemen von virtuellen Maschinen unter Windows 8 oder Windows Server 2012
    Die Anpassung von Gastbetriebssystemen von virtuellen Maschinen unter Windows 8 oder Windows Server 2012 wird bei ESXi Server 5.0 u2 und höher sowie bei ESXi Server 5.1 u1 und höher unterstützt. Bei Ausführung von ESXi Server 5.0 oder 5.0.1 bzw. ESXi Server 5.1.0 auf der Wiederherstellungs-Site schlagen Testwiederherstellungen und echte Wiederherstellungen fehl, da ESXi Server den Startvorgang für Windows 8 oder Windows Server 2012 auf der Wiederherstellungs-Site nicht abschließen kann. Die virtuelle Maschine auf der Wiederherstellungs-Site zeigt den Windows-Anmeldebildschirm nicht an. SRM gibt in den Wiederherstellungsschritten eine Fehlermeldung darüber aus, dass während des Einschaltens und vor dem IP-Anpassungsschritt eine Zeitüberschreitung bei den VM-Tools auftritt.

    Umgehung: Führen Sie ein Upgrade von ESXi Server auf der Wiederherstellungs-Site auf Version 5.0 u2 oder höher bzw. auf ESXi Server 5.1 u1 oder höher durch.

Behobene Probleme

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

  • SRM kann virtuelle Maschinen mit einer oder mehreren RDM-Festplatten nicht schützen, sofern sie Teil einer vApp sind.

    Ist dies der Fall und verwendet die virtuelle Maschine RDM-Festplatten, wird bei der Schutzkonfiguration die Fehlermeldung Gerät nicht gefunden: Festplatte X im Schutzstatus ausgegeben. Bei dieser Fehlermeldung entspricht Festplatte X der RDM-Festplatte, die an die virtuelle Maschine angeschlossen ist. Dies wurde behoben.

  • DR IP Customizer-Tool wird auf Windows 2003-Gastbetriebssystemen ohne Benachrichtigung unerwartet angehalten.

    Das DR IP Customizer-Tool wird auf Windows 2003-Gastbetriebssystemen unerwartet angehalten. Es erfolgt zwar keine Benachrichtigung, doch enthalten die SRM-Protokolle den Fehler C:\WINDOWS\TEMP\vmware-SYSTEM\netshIPv6.vbs(279, 4) Microsoft VBScript runtime error: Object doesn't support this property or method: 'GUID'. Dieses Problem wird durch einen unbehandelten Fehler beim Versuch des Zugriffs auf eine nicht vorhandene GUID-Eigenschaft verursacht. Dies wurde behoben.

  • SRM wird unerwartet angehalten, wenn ein lokalisiertes Windows-Gastbetriebssystemen eine Meldung an SRM Server sendet.

    Dieses Problem tritt auf, wenn SRM Server unter einem Windows-Betriebssystem mit Gebietsschema JP, KO oder CN und vCenter Server mit dem Gebietsschema EN ausgeführt werden. Wenn z. B. ein Post-Power-On-Skript einen Befehl ausführt, durch den eine Fehlermeldung mit japanischen Zeichen zurückgegeben wird, übersetzt vCenter Server diese nicht in die korrekte Kodierung. SRM empfängt eine ungültige Ausnahme und wird unerwartet angehalten. Dies wurde behoben.

  • Gastbetriebssystem-Stilllegungsoption ist für virtuelle Maschinen unter Windows Server 2012 nicht verfügbar.

    Bei der Konfiguration von vSphere Replication auf einer virtuellen Maschine mit Windows Server 2012-Gastbetriebssystem ist die Option zur Aktivierung der Gastbetriebssystem-Stilllegung nicht verfügbar. Dies wurde behoben.

  • Das Wiederherstellen einer virtuellen Windows Server 2012-Domänencontroller-Maschine bricht den DC-Schutzmechanismus.

    Das Wiederherstellen einer virtuellen Windows Server 2012-DC-Maschine ist mithilfe der Array-basierten Replizierung oder von vSphere Replication möglich. Die Durchführung eines Wiederherstellungsvorgangs auf solch einer virtuellen Maschine könnte allerdings zu einem Versagen des Windows Server 2012-DC-Schutzmechanismus führen. 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.
  • Der SRM-Dienst wird nach Überprüfung des Lizenz-Managers während des Schutzes einer virtuellen Maschine angehalten.

    Bei der Konfiguration des Schutzes auf einer virtuellen Maschine wird SRM Server unerwartet angehalten. Die Protokolle enthalten die Fehlermeldung: Panic: Assert Failed: "found == _reservations.get<by::vm>().end() (There is already a Reservation for VM [vim.VirtualMachine: virtuelle_Maschine])". Dies wurde behoben.

  • 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 Ausführung des SRM-Installationsprogramms im Änderungsmodus über die Befehlszeile mit der Option CUSTOM_SETUP führt zu einem Fehler.

    Wenn Sie SRM unter Verwendung der Option CUSTOM_SETUP installiert haben, z. B. um ein gemeinsam genutztes Wiederherstellungs-Site-Setup zu erstellen, führt der Versuch, das SRM-Installationsprogramms im Änderungsmodus über die Befehlszeile mit der Option CUSTOM_SETUP auszuführen, zum Fehler Die Befehlszeile CUSTOM_SETUP wird nicht unterstützt, wenn bereits eine Standardinstallation vorhanden ist. Dies wurde behoben.

  • Ein Wiederherstellungs- oder Testworkflow schlägt für die virtuelle Maschine mit folgender Fehlermeldung fehl: Fehler - Unerwarteter Fehler '3008' bei der Kommunikation mit ESX oder der Gast-VM: Es kann keine Verbindung zu der virtuellen Maschine hergestellt werden.

    Unter seltenen Umständen kann dieser Fehler auftreten, wenn Sie die IP-Anpassung oder einen Callout-Befehl im Gast für die virtuelle Maschine konfigurieren und der Wiederherstellungs-Site-Cluster im vollautomatischen DRS-Modus ist. Ein unerwarteter vMotion-Befehl kann einen vorübergehenden Kommunikationsfehler mit der virtuellen Maschine bewirken, wodurch ein Fehler im Anpassungsskript entsteht. Dies wurde behoben.

  • SRM-Upgrade kann fehlschlagen, wenn sich die zugeordneten vCenter Server-Instanzen im verknüpften Modus befinden.

    SRM-Upgrade kann fehlschlagen, wenn sich die zugeordneten vCenter Server-Instanzen im verknüpften Modus befinden. Dies wurde behoben.

  • Der SRM-Dienst schlägt fehl mit dem Fehler Panic: Assert Failed: "!vmKernelIp.empty()" @ d:/build/ob/bora-820150/srm/src/storage/vc/accessMapUtil.cpp:108.

    Während der Durchführung einer Testwiederherstellung schlägt der vCenter Site Recovery Manager- (SRM-)Dienst in folgenden Fällen auf der Wiederherstellungs-Site fehl:

    • NAS-Appliances (Network Attached Storage) werden ausschließlich anhand von IPv6 für SRM konfiguriert, und IPv4 ist auf den ESXi-Hosts der Wiederherstellungs-Site deaktiviert.
    • Array-Manager verwenden ausschließlich IPv6-Adressen.

    Dieses auch in KB 2057469 beschriebene Problem 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.

  • 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 Tags aufweisen, z. B. haben zwei LUNs auf verschiedenen Arrays eine identische ID. Dies wurde behoben.

  • Replizierungskonfiguration schlägt mit ungültigem UTF-8-Zeichen (einem Surrogatzeichen)für jede virtuelle Maschine fehl, die Unicode-Surrogatzeichen im Namen enthält.

    Dieses Problem wurde in dieser Version behoben.

  • vSphere Replication Management Server erkennt einen Arbeitsspeicherverlust und reagiert bei Verbindung mit vCenter Server oder vSphere Replication Server nicht mehr.

    Dieses Problem wurde in dieser Version 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.

  • vSphere Replication kann über Hosts mit mehreren virtuellen Verwaltungsnetzwerkkarten nicht auf Datenspeicher zugreifen und postet DatastoreInaccessibleEvent in vCenter Server: vSphere Replication kann nicht auf den Datenspeicher zugreifen.

    Wenn ein Host mit mehreren virtuellen Netzwerkkarten konfiguriert ist und Sie mehr als eine Netzwerkkarte für den Verwaltungsdatenverkehr auswählen, registriert vSphere Replication nur die erste Netzwerkkarte und verwendet diese zum Zugriff auf Zieldatenspeicher. Wenn sich die vSphere Replication-Serveradresse nicht auf dem ersten Verwaltungsnetzwerk des Hosts befindet, kommuniziert vSphere Replication nicht mit dem Host. Dies wurde behoben.

  • Beim Durchführen von gleichzeitigen Testwiederherstellungen in einem gemeinsam genutzten Wiederherstellungs-Site-Setup wird in der Ansicht "Kürzlich bearbeitete Aufgaben" auf der Wiederherstellungs-Site ein "Doppelter Name"-Fehler angezeigt.

    Die Durchführung mehrerer gleichzeitiger Testwiederherstellungen in einem gemeinsam genutzten Wiederherstellungs-Site-Setup (n:1-Umgebung) kann unter verschiedenen Bedingungen zu den folgenden Fehlern führen:

    • Der angegebene Schlüssel, Name oder Bezeichner ist bereits vorhanden (wenn ein virtueller Switch oder eine Portgruppe hinzugefügt wird).
    • Das Objekt oder Element, auf das Bezug genommen wurde, konnte nicht gefunden werden (wenn ein virtueller Switch oder eine Portgruppe während der Testbereinigung entfernt wird).
    • Die Ressource ' Ressourcenname' ist in Gebrauch (wenn ein virtueller Switch oder eine Portgruppe während der Testbereinigung entfernt wird).

    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.

  • 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.

    Umgehung: Ä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.

  • 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 eine Replizierung für eine virtuelle Maschine 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'.

    Umgehung: Keine.

  • vSphere Replication meldet "Auf den Datenspeicher kann nicht zugegriffen werden" für Datenspeicher auf einem Host, der der vCenter Server-Bestandsliste hinzugefügt wurde, während der vSphere Replication-Server registriert wurde.

    vSphere Replication wählt alle unterstützten Hosts aus der vCenter-Bestandsliste und aktiviert sie als Teil der vSphere Replication-Registrierung. Wenn Sie vCenter einen Host hinzufügen, während vSphere Replication noch registriert wird, wählt vSphere Replication diesen Host nicht aus und kann auf Datenspeicher auf der Wiederherstellungs-Site nicht zugreifen.

    Umgehung: Trennen Sie den Host in der vCenter-Bestandsliste für vSphere Replication und verbinden Sie ihn wieder, um ihn zu aktivieren.

  • 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 mehr als eine Stunde für ihren Abschluss, da vSphere Replication die SSL-Fingerabdruckregistrierung jedes Hosts aktualisiert. Im Bereich Ereignisse von vCenter Server wird für jeden Host die Meldung Der Host ist für vSphere Replication konfiguriert angezeigt, wenn die vSphere Replication-Serverregistrierungsaufgabe fortschreitet.

    Umgehung: Warten Sie, bis die Registrierungsaufgabe abgeschlossen ist. Nachdem sie abgeschlossen ist, können Sie vSphere Replication für ankommende Replizierungsvorgänge verwenden.

  • vSphere Replication-Registrierung kann mit der folgenden Fehlermeldung fehlschlagen: VRM-Server - generischer Fehler... Die Zeile wurde durch eine andere Transaktion aktualisiert oder gelöscht... HostEntity #<host-managed-object-id>.

    Der Vorgang VR-Server registrieren kann mit dieser Fehlermeldung fehlschlagen, wenn vCenter Server einige große Anzahl von Hosts in seiner Bestandsliste hat und Sie folgende Aktionen ausführen, während die Registrierung läuft:

    • Entfernen Sie einen Host aus der vCenter Server-Bestandsliste.
    • Entfernen Sie einen Host aus der Bestandsliste und verbinden Sie ihn wieder.
    • Ändern Sie den SSL-Fingerabdruck des Hosts.

    Umgehung: Versuchen Sie den Vorgang zum Registrieren des VR-Servers erneut.

  • Die Wiederherstellung schlägt fehl mit der Meldung: Fehler beim Erstellen des 'Test-Bubble'-Images aus der Gruppeninstanz... Die detaillierte Ausnahme ist Fehler beim Abruf von Host-Mounts für den Datenspeicher: managed-object-id...oder Das Objekt wurde bereits gelöscht oder noch nicht vollständig erstellt.

    Wenn Sie eine Testwiederherstellung oder eine geplante Wiederherstellung vornehmen und der Wiederherstellungsplan mit der spezifischen Ausnahmebedingung fehlschlägt, wurde die LUN, die für das Speichern der Replizierungsdaten verwendet wird, vorübergehend von ESXi getrennt. Wenn die Verbindung wieder aufgenommen wird, läuft die Replizierung normal weiter und es gehen keine Replizierungsdaten verloren. Die Ausnahmebedingung tritt während dieser Szenarien auf:

    • vSphere Replication kann die LUN nicht finden, weil die LUN ihre interne ID geändert hat.
    • Die interne ID des Zieldatenspeichers ändert sich, wenn der Host, der den Zieldatenspeicher enthält, aus der vCenter-Bestandsliste entfernt und später hinzugefügt wird.

    Sie müssen die Replizierung manuell neu konfigurieren, um die neue ID zu aktualisieren.

    Umgehung: Wenn die primäre Site nicht mehr verfügbar ist, lassen Sie sich vom VMware-Support anweisen, wie ein spezieller Konfigurationseintrag in der vSphere Replication-Appliance-Datenbank hinzugefügt wird, der eine automatische Reparatur der geänderten internen Datenspeicher-ID vornimmt, um die Wiederherstellung zu ermöglichen. Wenn die primäre Site immer noch verfügbar ist:

    1. Führen Sie einen Bereinigungsvorgang für den fehlgeschlagenen Wiederherstellungsplan aus.
    2. Klicken Sie in der vSphere Replication-Ansicht auf der Registerkarte Virtuelle Maschinen mit der rechten Maustaste auf eine virtuelle Maschine und wählen Sie Replizierung konfigurieren.
    3. Klicken Sie auf Weiter und dann auf Durchsuchen, um den Speicherort der Dateien auf dem Datenspeicher zu ändern, dessen Verbindung getrennt und anschließend wiederhergestellt wurde, und wählen Sie denselben Datenspeicher und dieselben Ordnerstandorte wie vorher aus.
    4. Verwenden Sie die bestehenden Festplatten wieder und konfigurieren Sie die Replizierung der virtuellen Maschine neu. Der vSphere Replication-Managementserver übernimmt die Identität des geänderten Datenspeichers (ID des verwalteten Objekts) in vCenter Server.
    5. Warten Sie, bis die anfängliche Synchronisierung beendet ist. Diese Synchronisierung verwendet bestehende Festplatten für die Datenkonsistenz.

  • Anzeige von veraltetem Replizierungsstatus, wenn Datenspeicher nicht mehr verfügbar ist

    Es ist möglich, dass der Zieldatenspeicher nach dem Start der Synchronisierung der virtuellen Maschine nicht mehr verfügbar ist. In einem solchen Fall sollte der Gruppenstatus Informationen über diesen Fehler anzeigen, der Status bleibt jedoch unverändert. Um Probleme in Verbindung mit nicht verfügbaren Datenspeichern zu erkennen, verwenden Sie die Ereignisse, die vom Zieldatenspeicher generiert werden. Die folgenden Ereignisse werden in einem solchen Fall generiert:

    • Der VR-Server kann nicht auf den Datenspeicher zugreifen...Wird sofort generiert, nachdem nicht mehr auf den Datenspeicher zugegriffen werden kann
    • Es wurde gegen das vSphere Replication-RPO der VM verstoßen...Replik kann nicht innerhalb des angegebenen Wiederherstellungspunkts (RPO) generiert werden

  • Generische Fehlermeldung wird angezeigt, wenn aufgrund strenger Zertifikatsrichtlinien die Serverkoppelung fehlschlägt

    Versuche, Server zwischen Sites zu koppeln, schlagen möglicherweise fehl und die folgende Fehlermeldung wird angezeigt: Das Koppeln von Sites oder der Unterbrechungsvorgang ist fehlgeschlagen. Details: VRM-Server - generischer Fehler.Dieser Fehler tritt möglicherweise auf, wenn eine Site für die Verwendung einer strengen Zertifikatsrichtlinie und die andere Site für die Verwendung einer großzügigen Zertifikatsrichtlinie konfiguriert wird. In einem solchen Fall sollte die Koppelung fehlschlagen, wie dies tatsächlich der Fall ist. Ändern Sie nach einem solchen Fehler die großzügige in eine strenge Zertifikatsrichtlinie und stellen Sie ein gültiges Zertifikat bereit.

  • Eine virtuelle Maschine kann aufgrund des Fehlers "Offene Anfrage" nicht abgeschaltet werden.

    Wenn Sie die Situation "Dauerhafter Geräteverlust" (Permanent Device Loss, PDL) absichtlich oder zufällig erstellen, indem Sie einen Initiator aus dem SAN auf dem Host ablegen, auf dem die virtuelle Maschine registriert ist, kann folgende Fehlermeldung auftreten:

    Fehler: Der Vorgang kann zurzeit nicht zugelassen werden, weil noch eine Anfrage für die virtuelle Maschine offen ist...

    Dieser Fehler tritt auf, wenn die Hardware während des PDL-Zustands fehlschlägt, während eine Bereinigung stattfindet, nachdem Sie einen Wiederherstellungsplan im Testwiederherstellungsmodus durchgeführt haben.

    Umgehung: Beantworten Sie die Frage auf der Registerkarte "Übersicht" der virtuellen Maschine. Danach führen Sie die Bereinigung im erzwungenen Bereinigungsmodus erneut durch. Nachdem der Bereinigungsvorgang abgeschlossen wurde, ist die virtuelle Maschine möglicherweise auf der Wiederherstellungs-Site noch vorhanden. In diesem Fall entfernen Sie sie manuell.

  • 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.

  • Interner Fehler tritt während der Wiederherstellung auf.

    SRM ruft während des Wiederherstellungsprozesses verschiedene Informationen von vCenter ab. Wenn wichtige Informationen, die für die Fortsetzung erforderlich sind, nicht empfangen werden, tritt ein interner Fehler CannotFetchVcObjectPropertyauf. Dieser Fehler kann auftreten, wenn vCenter unter schwerer Belastung steht oder ein ESXi-Host aufgrund schwerer Belastung unverfügbar wird. Dieser Fehler kann auch auftreten, wenn SRM versucht, Informationen auf einem ESXi-Host abzurufen, der nicht verbunden ist oder aus der vCenter-Bestandsliste entfernt wurde.

    Umgehung: Führen Sie den Wiederherstellungsplan erneut aus.

  • Nachdem Sie einen Neustart von vCenter Server durchgeführt haben, wenn Sie vSphere Replication verwenden, schlagen Vorgänge zum erneuten Schutz mit folgender Fehlermeldung fehl: Fehler - Die Replizierung für die virtuelle Maschine Virtuelle_Maschine kann nicht umgekehrt werden. Die Sitzung wurde nicht authentifiziert.

    Nach dem Neustart von vCenter Server können einige Sitzungen nicht wiederhergestellt werden, die SRM benutzt, um mit vSphere Replication zu kommunizieren, und daher schlägt der erneute Schutz fehl.

    Umgehung: Starten Sie die SRM-Dienste auf beiden Siten neu.

  • Der erneute Schutz schlägt mit einem Fehler fehl, wenn mehrere Wiederherstellungspläne gleichzeitig laufen.

    Wenn Sie mehrere Wiederherstellungspläne gleichzeitig ausführen, kann der erneute Schutz mit folgender Fehlermeldung fehlschlagen: 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.

    Umgehung: Führen Sie den Vorgang zum erneuten Schutz erneut aus.

  • 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.

  • Nicht-ASCII-Kennwörter werden zum Anmelden bei VAMI (Virtual Appliance Management Infrastructure) nicht angenommen

    Benutzer können die vSphere Replication-Appliance mithilfe von VAMI verwalten. Versuche, sich bei 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.

  • 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.

  • 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.
  • 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 kann nach einem RDM-Fehler keine virtuellen Maschinen wiederherstellen.

    RDM-LUNs schlagen möglicherweise fehl, während LUNs, die Datenspeicher stützen, nicht betroffen sind. In einem solchen Fall kann SRM keine virtuellen Maschinen mit RDMs wiederherstellen.

    Umgehung: Stellen Sie die betroffenen virtuellen Maschinen manuell wieder her. Führen Sie ein Failover der RDM-LUN durch und schließen Sie sie als RDM-Festplatte an der wiederhergestellten virtuellen Maschine neu an.

  • 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.

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

  • 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.

  • 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.

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

  • 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.

    Umgehung: 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.

  • 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...

    Umgehung: Führen Sie die Wiederherstellung erneut durch.

  • 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.

    Umgehung: Führen Sie den Wiederherstellungsplan erneut aus.

  • Einige von SRM eingeleitete Aufgaben, die mit einem NoPermission-Fehler fehlschlagen und die Fehlermeldung anzeigen: Interner Fehler: vim.fault.NoPermissionanstelle von Die Berechtigung zur Durchführung dieses Vorgangs wurde verweigert.

    Der vSphere-Client ermittelt, ob eine gespiegelte Aufgabe eine MoRef zu einem Objekt enthält, das nicht ein vCenter Server- oder SRM-Objekt ist.

    Umgehung: Wenn die fehlgeschlagene SRM-Aufgabe eine Wiederherstellungsaufgabe ist, entnehmen Sie eine genauere Fehlermeldung dem Bereich der Wiederherstellungsaufgabe. Bei einem Fehlschlag einer vCenter Server-Aufgabe orientieren Sie sich an den Unteraufgaben, die weitere Informationen enthalten.

  • 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.

    Umgehung: 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.

  • 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.

    Umgehung:

    1. Wenn LUNs in APD/PDL eintreten, markiert der 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.
  • Der Test der Wiederherstellungsbereinigung kann fehlschlagen, wenn einer der Hosts die Verbindung mit einem Platzhalter-Datenspeicher verliert.

    Wenn Sie eine Testwiederherstellung in einem Cluster mit zwei Hosts auf der Wiederherstellungssite ausführen und einer der Hosts im Cluster die Verbindung mit einem Platzhalter-Datenspeicher verliert, kann die Bereinigung der Testwiederherstellung fehlschlagen.

    Umgehung: Führen Sie die Bereinigung im Erzwingungsmodus aus. Entfernen Sie auf der Wiederherstellungssite die Platzhalter, die virtuelle Maschinen auf dem Host erstellt haben, der die Verbindung mit dem Platzhalter-Datenspeicher verloren hat. Entfernen Sie die Replizierungskonfiguration der virtuellen Maschine und konfigurieren Sie die Replizierung neu. Führen Sie eine Neukonfiguration des Schutzes der virtuellen Maschine aus den Schutzgruppeneigenschaften durch.

  • In Internet Explorer 7 kann auf die kontextbezogene Hilfe nicht zugegriffen werden.

    Weitere Informationen finden Sie unter KB 1009801 .

  • Durch das Generieren von Support-Paketen in einer stark ausgelasteten Umgebung werden möglicherweise laufende vSphere Replication-Vorgänge beeinträchtigt.

    Das Generieren von Support-Paketen in stark ausgelasteten Umgebungen kann bei Wiederstellungsvorgängen vSphere Replication-Verbindungsprobleme verursachen. Dies geschieht insbesondere dann, wenn der Speicher für die virtuelle vSphere Replication-Maschine überladen ist.

    Umgehung: Wenn ein Vorgang nicht gestartet werden kann, weil der vSphere Replication-Server durch das Generieren des Support-Pakets blockiert ist, versuchen Sie, den Vorgang erneut durchzuführen. Überprüfen Sie die erwarteten Anforderungen für die Speicherbandbreite des Clusters sowie die Netzwerkbandbreite, falls es sich bei dem Speicher um NAS handelt.

  • Der Wert "Umfang der letzten Synchronisierung" für eine virtuelle Maschine, die durch vSphere Replication geschützt wird, ist die Menge an Daten, die seit der letzten Synchronisierung geändert wurden.

    Auch wenn Sie eine vollständige Synchronisierung auf einer virtuellen Maschine vornehmen, die vSphere Replication schützt, zeigt der Wert "Umfang der letzten Synchronisierung" die Menge an Daten, die seit der letzten Synchronisierung geändert wurden, und nicht die Größe der vollen virtuellen Maschine. Dies kann fälschlicherweise interpretiert werden, als wäre die Synchronisierung nicht abgeschlossen worden. Nach der ersten Synchronisierung, während einer vollständigen Synchronisierung einer virtuellen Maschine, vergleicht vSphere Replication ganze Festplatten, überträgt aber nur geänderte Daten, nicht die gesamte Festplatte.

    Um die Größe und die Dauer der ersten Synchronisierung anzuzeigen, können Sie die Ereignisse überprüfen, die vSphere Replication an vCenter Server meldet. Dieses Problem tritt nur in ESXi 5.0.x-Hosts auf. Dieses Verhalten wurde auf ESXi 5.1-Hosts bereinigt.

  • Die Wiederherstellung oder Testwiederherstellung kann mit der Fehlermeldung "Kein Host mit Hardwareversion '7' und Datenspeicher 'ds_id', die eingeschaltet und nicht im Wartungsmodus sind, sind verfügbar..." in den Fällen fehlschlagen, in denen kürzliche Änderungen in der Host-Bestandsliste auftreten.

    SRM-Server bewahrt einen Cache des Hostbestandslistenstatus auf. Wenn kürzliche Änderungen in der Bestandsliste vorgenommen wurden, beispielsweise wenn die Verfügbarkeit des Hosts ausfällt, der getrennt wird oder seine Verbindung mit einigen Datenspeichern verliert, kann es vorkommen, dass der SRM-Server bis zu 15 Minuten zum Aktualisieren des Caches benötigt. Wenn der SRM-Server den falschen Hostbestandslistenstatus in seinem Cache bewahrt, kann eine Wiederherstellung oder eine Testwiederherstellung fehlschlagen.

    Umgehung: Warten Sie 15 Minuten, bevor Sie eine Wiederherstellung durchführen, wenn Sie Änderungen an der Hostbestandsliste vorgenommen haben. Wenn Sie den oben genannten Fehler beobachten, warten Sie 15 Minuten und führen Sie die Wiederherstellung dann erneut durch.

  • Die Wiederherstellung dauert übermäßig lang und das erneute Schützen schlägt mit folgendem Fehler fehl: Überprüfung der Anmeldedaten nicht möglich. Ausfall der Authentifizierungsdienst-Infrastruktur.

    Dieser Fehler tritt auf, weil in vCenter Server, das auf einem Windows 2003-Server ausgeführt wird, die flüchtigen Ports aufgebraucht sind. Der SRM-Server kann nicht mit vCenter Server kommunizieren.

    Umgehung:

    1. Installieren Sie den Microsoft-Hotfix aus dem KB-Artikel 979230, um das Problem im Treiber tcpip.sys zu beheben.
    2. Legen Sie die folgenden regedit-Werte fest, indem Sie entweder die Änderungen manuell vornehmen oder die folgende .reg-Datei importieren:
      Windows Registry Editor Version 5.00
      
      [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
      "MaxUserPort"=dword:00002710
      "TcpTimedWaitDelay"=dword:0000001E
                      
    3. Falls die Registrierungswerte nicht vorhanden sind, erstellen Sie sie.
    4. Nachdem Sie die Änderungen vorgenommen haben, starten Sie die Windows 2003 Server-Maschine neu.

  • Vorgänge zur Synchronisierung, Wiederherstellung oder zum erneuten Schutz virtueller Maschinen schlagen mit vSphere Replication fehl:

    Dieser Fehler kann auftreten, wenn Sie einen Synchronisierungsvorgang anfordern oder Vorgänge wie Wiederherstellung oder erneuten Schutz ausführen. Die Fehlermeldungen sehen etwa wie folgt aus:

    • VR-Synchronisierung für die VRM-Gruppe Gruppe fehlgeschlagen. VRM-Server - generischer Fehler. Suchen Sie in der Dokumentation nach Informationen zur Fehlerbehebung. Die detaillierte Ausnahme ist: 'Die angeforderte Instanz mit Id= ID wurde auf der Remote-Site nicht gefunden.'
    • Fehler – VR-Synchronisierung für die VRM-Gruppe Gruppe fehlgeschlagen. Der Speicher ist für den Datenspeicherpfad '[ path] *.vmdk.vmdk' gesperrt.

    Dieser Fehler tritt mit größerer Wahrscheinlichkeit auf, wenn virtuelle Maschinen mit einer hohen Arbeitslast auf der geschützten Site ausgeführt werden.

    Umgehungen:

    • Wiederholen Sie den Vorgang. Dies führt möglicherweise nicht zum Erfolg.
    • Da dieses Problem damit zusammenhängt, dass die Last auf der geschützten Site ausgeführt wird, müssen Sie die Wiederherstellungen zeitlich außerhalb der Geschäftszeiten planen.
    • Wenn Sie eine Testwiederherstellung durchzuführen versuchen, aktivieren Sie nicht die Option „Neueste Änderungen an der Wiederherstellungs-Site replizieren“.
    • Upgrade auf SRM 5.5. SRM 5.5 enthält in Verbindung mit vSphere 5.5 eine Reihe von Updates, mit denen dieses Problem gelöst wird.

  • 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.

    Umgehung: 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.

  • Eine vSphere Replication-Appliance auf einer gemeinsam genutzten Wiederherstellungs-Site wird während des erneuten Schützens in der SRM-UI als "getrennt" angezeigt.

    Während des erneuten Schützens und nach dem Konfigurieren der Replizierungen in umgekehrter Richtung warten SRM und die vSphere Replication-Appliance auf den Abschluss der anfänglichen Synchronisierungsvorgänge in der umgekehrten Richtung. Wenn der Wiederherstellungsplan mehr als 100 virtuelle Maschinen umfasst, sorgen die Überwachungsaufgaben der anfänglichen Synchronisierungsvorgänge dafür, dass die vSphere Replication-Appliance nicht auf Aufrufe von der SRM-UI reagiert.

    Umgehung: Warten Sie, bis die anfängliche Synchronisierung der umgekehrten Replizierungen abgeschlossen ist. Der Replizierungsstatus in der SRM-UI ändert sich schließlich von "Synchronisieren" in "OK". Versuchen Sie erneut, eine Verbindung von der SRM-UI aus mit der vSphere Replication-Appliance auf der gemeinsam genutzten Site herzustellen.

  • Durch das Abmelden vom SRM-C#-Client während des erneuten Schützens schlägt der Synchronisierungsschritt eines Vorgangs zum erneuten Schützen mit der folgenden Fehlermeldung fehl: Fehler beim Abrufen der lokalen VC-Ansicht.

    Während des erneuten Schützens und nach dem Konfigurieren der Replizierungen in umgekehrter Richtung warten SRM und die vSphere Replication-Appliance auf den Abschluss der anfänglichen Synchronisierungsvorgänge in der umgekehrten Richtung. SRM startet einen separaten Synchronisierungsvorgang, um sicherzustellen, dass es keine Probleme mit der Replizierung gibt. Wenn Sie sich während dieses Synchronisierungsvorgangs von der SRM-UI abmelden, wird der Vorgang zum erneuten Schützen fortgesetzt, aber vSphere Replication kann die Identität des Benutzers nicht annehmen und der Synchronisierungsvorgang schlägt fehl.

    Umgehung: Ignorieren Sie den Fehler, der im Synchronisierungsschritt des Workflows zum erneuten Schützen angezeigt wird, oder verwenden Sie die SRM-UI, um nach Abschluss des Vorgangs zum erneuten Schützen einen Synchronisierungsvorgang zu starten.

  • Zum Ändern oder Reparieren einer SRM-Server-Installation sind Administratorrechte erforderlich oder die Benutzerkontensteuerung (UAC) muss deaktiviert werden.

    Wenn Sie ein Mitglied der Administratorengruppe, aber kein Administrator sind, müssen Sie die Windows-Benutzerkontensteuerung ( UAC) deaktivieren, bevor Sie versuchen, eine SRM-Server-Installation über die Windows-Systemsteuerung zu ändern oder zu reparieren. Wenn Sie SRM-Server auf einem Windows Server 2012-Host installiert haben, deaktivieren Sie die Benutzerkontensteuerung, indem Sie die Registrierung bearbeiten.

    Umgehung: Melden Sie sich als Administrator bei der Windows Server 2012-Maschine an, wenn Sie das SRM-Installationsprogramm im Modus "Ändern" oder "Reparieren" ausführen, oder deaktivieren Sie die Benutzerkontensteuerung. Informationen zum Deaktivieren der Benutzerkontensteuerung unter Windows Server 2012 finden Sie unter http://social.technet.microsoft.com/wiki/contents/articles/13953.windows-server-2012-deactivating-uac.aspx.

  • SRM wird während einer Testwiederherstellung unerwartet mit einem "Panic"-Fehler beendet. Sie können den SRM-Dienst neu starten, aber er stoppt wieder, wenn Sie den Test fortsetzen.

    In seltenen Fällen wird SRM während der Testwiederherstellung mit dem Fehler Panic: Assert Failed: "this->_childJobs.size() == this->_jobsToRemove.size() (Ungültiger Status, Auftrag kann nicht abgeschlossen werden, solange untergeordnete Aufträge ausstehen unerwartet beendet. Versuche, den Test nach dem Neustarten des SRM-Diensts noch einmal auszuführen, führen zum Beenden von SRM mit demselben Fehler. Dieses Problem tritt auf, wenn die SRM-Datenbank sich nicht im richtigen Status befindet.

    Umgehung: Wenden Sie sich an den VMware-Support.

  • Der erneute Schutz schlägt fehl, nachdem der nicht verbundene Host auf der geschützten Site entfernt wurde.

    Wenn Sie den nicht verbundenen Host von der geschützten Site entfernen und "Neu schützen" ausführen, kann der Vorgang zum erneuten Schutz mit dem Fehler Interner Fehler: std::exception 'class Vmacore::Exception" fehlschlagen.

    Umgehung: Führen Sie den Vorgang zum erneuten Schützen mit aktivierter Option "Bereinigung erzwingen" erneut durch.

  • 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.

    Umgehung: Keine.

  • Testen der Wiederherstellung von virtuellen Maschinen mit RDM in einer vApp schlägt mit einem Verbindungsfehler fehl.

    Das Testfailover schlägt mit der Fehlermeldung Verbindung zum VC-Remoteserver unterbrochen fehl, wenn eine vApp von der geschützten Site einer vApp auf der Wiederherstellungs-Site zugeordnet ist und die vApp mindestens eine virtuelle Maschine mit RDM enthält.

    Umgehung: Befolgen Sie die Aufforderungen auf dem Bildschirm, um die Verbindung zur vCenter Server-Remoteinstanz erneut herzustellen.

  • SRM Server wird unerwartet angehalten, wenn eine Testbereinigung nach dem Upgrade auf SRM 5.1.2 ohne Upgrade der SRAs ausgeführt wird.

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

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

  • 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.

    Umgehung: Führen Sie den Bereinigungsvorgang erneut aus.

    •