VMware vCenter Site Recovery Manager 5.1.1 | 25. April 2013 | Build 1082082

Letzte Aktualisierung: 21. Okt. 2013

Ü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.1

VMware vCenter Site Recovery Manager 5.1.1 fügt die im Abschnitt Behobene Probleme beschriebenen Fehlerkorrekturen hinzu.

Lokalisierung

VMware vCenter Site Recovery Manager 5.1.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.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.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.1.1 keinen Speicherreplizierungsadapter (SRA).

Installation und Upgrade

Das Evaluierungshandbuch zur Unterstützung mit einer technischen Komplettlösung der wichtigsten Funktionen und Fähigkeiten von Site Recovery Manager 5.1.1 finden Sie unter 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.1

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

Führen Sie ein Upgrade von SRM 4.1.2 auf SRM 5.0.2 durch, bevor Sie ein Upgrade auf SRM 5.1.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.1 oder 5.1 u1 ist ein unterstützter Upgrade-Pfad. Allerdings ist ein direktes SRM-Upgrade von Version 4.1.2 auf Version 5.1.1 kein unterstützter Upgrade-Pfad. 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 ein Upgrade von vCenter Server auf Version 5.0 oder 5.0 u1 durchführen, bevor Sie SRM auf Version 5.0.2 aktualisieren. Wenn Sie ein direktes Upgrade von vCenter Server von Version 4.1.2 auf Version 5.1 oder 5.1u1 durchführen und Sie versuchen, ein SRM-Upgrade von Version 4.1.2 auf 5.0.2 durchzuführen, schlägt das SRM-Upgrade fehl. SRM 5.0.2 kann keine Verbindung zu einer vCenter Server 5.1-Instanz herstellen.

Upgrade einer vorhandenen SRM 5.0.2-Installation auf SRM 5.1.1

Um ein Upgrade einer vorhandenen SRM 5.0.2-Installation auf SRM 5.1.1 durchzuführen, laden Sie das Installationsprogramm VMware-srm-5.1.1-1082082.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- oder 5.1.0.1-Installation auf SRM 5.1.1

Führen Sie die folgenden Schritte aus, um ein Upgrade einer vorhandenen SRM 5.1- oder 5.1.0.1-Installation auf SRM 5.1.1 durchzuführen.

  1. Führen Sie ein Upgrade von vCenter Server auf Version 5.1 u1 durch.
  2. Melden Sie sich bei der Maschine an, auf der Sie den SRM-Server auf der geschützten Site ausführen.
  3. Sichern Sie die SRM-Datenbank mit den Tools der Datenbanksoftware.
  4. Laden Sie das Installationsprogramm VMware-srm-5.1.1-1082082.exe herunter und führen Sie es aus.
  5. Klicken Sie auf Ja, um das Upgrade von SRM zu bestätigen.
  6. Klicken Sie auf Ja, um zu bestätigen, dass Sie die SRM-Datenbank gesichert haben.
  7. Klicken Sie auf Beenden, wenn die Installation abgeschlossen ist.
  8. 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.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.1.1

Wenn Sie vSphere Replication mit einer vorherigen Version installiert haben und Sie ein Upgrade auf SRM 5.1.1 durchführen, müssen Sie auch ein Upgrade von vSphere Replication auf Version 5.1.1 durchführen. Zudem müssen Sie ein Upgrade der vSphere Replication-Server auf Version 5.1.1 durchführen.

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 des vSphere Replication-Servers auf Version 5.1.1 ü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.1.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 nicht mit SRM und vCenter Server 5.1.x kompatibel ist. Lassen Sie die Aktualisierungseinstellungen auf Keine automatischen Aktualisierungen.

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.1 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 Speicher-DRS
    Wegen einiger bestimmter und eingeschränkter Fälle, bei denen die Wiederherstellbarkeit während der Speicherverschiebung beeinträchtigt werden kann, wird Site Recovery Manager 5.1.1 weder für die Verwendung mit Storage vMotion (SVmotion) noch für die Verwendung mit SDRS (Storage Distributed Resource Scheduler), einschließlich der Verwendung von Datenspeicher-Clustern, unterstützt.

  • Interoperabilität mit vCloud Director
    Site Recovery Manager 5.1.1 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.1 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.

  • Das Wiederherstellen einer virtuellen Windows Server 2012-Domänencontroller-Maschine bricht den DC-Schutzmechanismus, wenn vSphere Replication verwendet wird.
    Das Wiederherstellen einer virtuellen Windows Server 2012-DC-Maschine ist mithilfe der Array-basierten Replizierung möglich. Wenn Sie jedoch eine Wiederherstellung mithilfe von vSphere Replication in einem Wiederherstellungsplan durchführen, den Sie von der SRM-UI aus ausführen, entfernt vSphere Replication vm.genid und vm.genidX aus der VMX-Datei nicht. Das Durchführen einer Wiederherstellung mithilfe von vSphere Replication vom vSphere Web Client verläuft erfolgreich.

Behobene Probleme

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

  • Vorgänge für die Testwiederherstellung, die geplante Migration oder den erneuten Schutz können mit folgender Fehlermeldung fehlschlagen: Zeitüberschreitung beim Vorgang.

    Dieser Fehler kann auftreten, wenn mehrere Vorgänge mit mehreren primären Sites ausgeführt werden. Dies wurde behoben.

  • Vorgänge zum erneuten Schutz für mehrere virtuelle Maschinen, mit mehreren Remote-Sites, schlagen mit der Meldung Die Replizierung für die virtuelle Maschine VM-Name konnte nicht umgekehrt werden. Zeitüberschreitung beim Vorgang.

    vSphere Replication antwortet nicht mehr auf SRM-Abfragen, wenn ein erneuter Schutz mehrerer virtueller Maschinen auf mehreren Remote-Sites vorgenommen wird. Dies wurde behoben.

  • Die IP-Anpassung schlägt beim Testen eines Wiederherstellungsplans mit einem japanischen Namen fehl.

    Wenn der Name eines Wiederherstellungsplans japanische Zeichen enthält und Sie die IP-Anpassung auf einer virtuellen Windows-Maschine konfigurieren, die im japanischen Gebietsschema ausgeführt wird, schlägt der Anpassungsschritt mit einem Skriptfehler fehl. Dies wurde behoben.

  • Auf der Registerkarte "Geräte" werden in der Ansicht "Array-Manager" der SRM-Benutzeroberfläche doppelte Volumes angezeigt.

    Dieses Problem tritt auf, wenn die Zielnummer einer LUN mit der Quellnummer einer anderen LUN identisch ist. Dieses UI-Problem wurde behoben.

  • Die Durchführung einer Wiederherstellung mithilfe der vSphere Replication-Benutzeroberfläche schlägt mit folgender Fehlermeldung fehl: Das Verarbeiten der Konfigurationsdatei der wiederhergestellten virtuellen Maschine ... ist fehlgeschlagen ... HTTP-Anforderung fehlgeschlagen: org.apache.http.conn.HttpHostConnectException: Verbindung mit https:// vCenter_Server-Hostname verweigert.

    Wenn vCenter Server mit einem benutzerdefinierten Port für HTTPS, z. B. Port 444, installiert wird, schlägt die Wiederherstellung beim Versuch, die replizierte VMX-Datei zu aktualisieren, fehl. Dies wurde behoben.

  • Wenn sich der Zielspeicherort auf einem NFS-Datenspeicher befindet, verursacht das Konfigurieren der Replizierung im erweiterten Modus die folgende Fehlermeldung: Format für die virtuelle Festplatte auswählen.

    Dies wurde behoben.

  • Erneute Prüfungen von Datenspeichern auf der Wiederherstellungs-Site schlagen fehl, weil Speichergeräte nicht bereit sind.

    SRAs können Antworten an SRM senden, bevor ein heraufgestuftes Speichergerät auf der Wiederherstellungs-Site für die ESXi-Hosts verfügbar ist. Wenn SRM eine Antwort von einem SRA empfängt, wird eine erneute Prüfung der Speichergeräte durchgeführt. Wenn die Speichergeräte noch nicht vollständig verfügbar sind, erkennt der ESXi-Server sie nicht und SRM findet die replizierten Geräte beim Durchführen der erneuten Prüfungen nicht. Datenspeicher werden nicht erstellt und wiederhergestellte virtuelle Maschinen können nicht gefunden werden.

    Umgehung: Wenn Probleme mit nicht verfügbaren Datenspeichern auftreten, können Sie eine neue Einstellung in SRM 5.1.1 verwenden, um eine Verzögerung für den Start der erneuten Prüfungen nach dem Heraufstufen eines Speichergeräts durch einen SRA festzulegen.

    1. Klicken Sie mit der rechten Maustaste auf eine SRM-Site und wählen Sie Erweiterte Einstellungen aus.
    2. Klicken Sie auf storageProvider.
    3. Legen Sie mit dem Parameter storageProvider.hostRescanDelaySec die Verzögerung für den Start der erneuten Speicherprüfungen in Sekunden fest. Ein Wert zwischen 20 und 180 ist sinnvoll.
    4. Starten Sie den SRM-Dienst neu.

    HINWEIS: In früheren Versionen haben Sie möglicherweise den Parameter storageProvider.hostRescanRepeatCnt verwendet, um eine Verzögerung bei Wiederherstellungen festzulegen. Verwenden Sie stattdessen den neuen Parameter storageProvider.hostRescanDelaySec.

  • SRM wird während einer geplanten Migration unerwartet beendet, wenn die Verbindung zwischen dem ESXi-Server und vCenter Server auf der geschützten Site getrennt wird.

    Wird der ESXi-Server auf der geschützten Site von vCenter Server getrennt oder geht die Verbindung zu vCenter Server aufgrund eines Problems verloren, wird SRM unerwartet beendet, wenn Sie versuchen, eine geplante Migration durchzuführen. Dieses Problem wurde behoben und SRM wird beim Ausführen einer geplanten Migration nicht beendet. Die geplante Migration schlägt mit einem Fehler fehl.

    Umgehung:

    1. Entfernen Sie den ESXi-Server aus der vCenter Server-Bestandsliste.
      Wenn der Host absichtlich ausgeschaltet oder in den Wartungsmodus versetzt wurde, sollten auf ihm keine virtuellen Maschinen ausgeführt werden. In diesem Fall gehen nur Ressourcen-Pools und Ordner verloren. War der Host Teil eines Clusters, werden Ressourcen-Pools und Ordner einmal neu erstellt, wenn Sie den Host wiederherstellen.
    2. Stellen Sie den Host und die Verbindung zu vCenter Server wieder her.
    3. Führen Sie eine Notfallwiederherstellung aus, um die virtuellen Maschinen auf die Wiederherstellungs-Site zu migrieren.

  • Zeitüberschreitungen mit dem Fehler "Replizierter Datenspeicher wurde aufgrund einer Zeitüberschreitung bei der erneuten HBA-Prüfung nicht gefunden" treten auf.

    Dieses Problem wurde behoben, um die Erkennung von Fehlern und Fehlermeldungen für Zeitüberschreitungen bei erneuten Hostprüfungen zu verbessern.

  • Installationen von SRM 5.1 oder Upgrades auf SRM 5.1 mit importierten Zertifikaten schlagen fehl.

    Wenn Sie versuchen, unter Verwendung eines importierten PKCS12-Zertifikats anstelle eines automatisch generierten Zertifikats eine Installation von SRM 5.1 oder ein Upgrade auf SRM 5.1 durchzuführen, wird das Installationsprogramm vollständig ausgeführt, schlägt aber dann mit dem Fehler "Zertifikat konnte nicht installiert werden" fehl. Dies wurde behoben.

  • SRM Server auf der Wiederherstellungs-Site wird während der Bereinigung nach dem Testen eines Array-basierten Wiederherstellungsplans unerwartet beendet.

    Wird nach dem Testen eines Array-basierten Wiederherstellungsplans ein Bereinigungsvorgang durchgeführt, wird SRM Server auf der Wiederherstellungs-Site unerwartet beendet. Die Protokolle enthalten die Fehlermeldung: Panic: Win32-Ausnahme: Zugriffsverletzung. Dies wurde behoben.

  • Benutzerdefinierte Wiederherstellungsschritte verhindern nicht, dass virtuelle Maschinen vor der IP-Anpassung eingeschaltet werden.

    Wenn Sie nach dem Schritt "Snapshot des beschreibbaren Speichers erstellen" in einer Testwiederherstellung bzw. nach dem Schritt "Wiederherstellungs-Site-Speicher auf 'Beschreibbar' ändern" in einer echten Wiederherstellung einen benutzerdefinierten Wiederherstellungsschritt einfügen und die virtuelle Maschine für die IP-Anpassung konfiguriert ist, wartet der Wiederherstellungsplan mit dem Einschalten der virtuellen Maschine nicht auf die Fertigstellung des benutzerdefinierten Wiederherstellungsschritts. Dies wurde behoben.

  • Wenn benutzerdefinierte Zertifikate mit VCVA verwendet werden, schlägt die Kopplung von SRM-Servern fehl.

    Bei Verwendung von benutzerdefinierten Zertifikaten für SRM-Server und die virtuelle vCenter Server-Appliance schlägt die Kopplung von SRM-Servern mit dem folgenden Fehler fehl: Die Berechtigung zur Durchführung dieses Vorgangs wurde verweigert. Dies wurde 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.

  • Der Vorgang zum erneuten Schützen mit vSphere Replication schlägt mit einem Authentifizierungsfehler fehl.

    Der Vorgang zum erneuten Schützen mit vSphere Replication wird zu etwa 89 % ausgeführt, hält an und schlägt dann mit dem Fehler runHbrReprotect: com.vmware.vim.binding.vim.fault.NotAuthenticated fehl. Die virtuellen Maschinen auf der sekundären Site befinden sich dann in einem ungültigen Zustand. Dies wurde behoben.

  • SRM schlägt während der Wiederherstellung beim Vorbereiten der virtuellen Maschinen für die Migration auf der geschützten Site fehl.

    Wenn sich eine geschützte virtuelle Maschine in einem Datenspeicher befindet, der von mehreren Hosts gemeinsam genutzt wird, und sich diese Hosts in unterschiedlichen Datencentern befinden, kann SRM während einer Wiederherstellung beim Schritt "VMs auf der Schutz-Site für die Migration vorbereiten" fehlschlagen. Die Protokolle enthalten die Fehlermeldung: SRM Panic: Assert Failed: "ok" @ Pfad/deactivateStorage.cpp:1170. 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.

      • Es treten bei SRM möglicherweise Fehler beim Mounten von Datenspeichern während Wiederherstellungen auf

        Während einer Testwiederherstellung oder eines tatsächlichen Failovers wartet SRM darauf, dass wiederhergestellte Datenspeicher verfügbar werden. Sobald die Datenspeicher verfügbar werden, versucht SRM, alle nicht gemounteten Datenspeicher zu mounten. In seltenen Fällen werden diese Datenspeicher automatisch gemountet, bevor SRM sie mounten kann. Falls dies während eines Test-Failovers erfolgt, wird das Failover nicht abgeschlossen. Tritt dies während einer tatsächlichen Wiederherstellung auf, wird die Wiederherstellung mit einem Fehler abgeschlossen. Wiederholen Sie die Wiederherstellung, um dieses Problem zu beheben.

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

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

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

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

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

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

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

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

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

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

        Umgehung: Führen Sie den Wiederherstellungsplan erneut aus. Wenn der Fehler weiter auftritt, konfigurieren Sie Wiederherstellungs-Site-Cluster-DRS auf den manuellen Modus und 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.
      • 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 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.

      • 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 #&lthost-managed-object-id&gt.

        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.

      • Wenn der Name eines Ordners auf einer Wiederherstellungs-Site ein Prozentsymbol (%) enthält, wird während der Replizierung ein neuer Ordner erstellt.

        Wenn Sie ein Prozentsymbol (%) im Namen eines Ordners auf einer Wiederherstellungs-Site verwenden und versuchen, den Ordner als Replizierungsziel zu konfigurieren, wird möglicherweise in einen anderen Ordner mit zusätzlicher Codierung repliziert. Wenn Sie beispielsweise den Ordner %3dTest erstellen, legt vSphere Replication einen neuen Ordner %253dTest an und repliziert in diesen Ordner.

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

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

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

      • Der Vorgang zum erneuten Schützen schlägt mit einer Fehlermeldung fehl: Zeitüberschreitung beim Vorgang: 7200 Sekunden VR-Synchronisierung für VRM-Gruppe &ltUnavailable&gt fehlgeschlagen. Zeitüberschreitung beim Vorgang: 7200 Sekunden.

        Wenn Sie den Vorgang zum erneuten Schützen ausführen, führt SRM eine Online-Synchronisierung für die Replizierungsgruppe durch, wodurch eine Zeitüberschreitung auftreten kann. Der Standardwert für die Zeitüberschreitung beträgt 2 Stunden.

        Umgehung: Erhöhen Sie den Wert der Zeitüberschreitung in SRM unter "Erweiterte Einstellungen".

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

      • Der vSphere Replication-Appliance-Status lautet "Getrennt", wenn das SRM-Client-Plug-In auf Windows XP oder Windows 2003 ausgeführt wird.

        Der Status der vSphere Replication-Appliance wird auf der Registerkarte Übersicht für eine vSphere Replication-Site als "Getrennt" angezeigt. Der Versuch, die Verbindung neu zu konfigurieren, führt zu dem Fehler Verbindung zum lokalen VRMS-Server unter Serveradresse:8043 unterbrochen. (Der Client konnte keine vollständige Anforderung an den Server 'Serveradresse' senden. (Die zugrunde liegende Verbindung wurde getrennt: Beim Senden ist ein unerwarteter Fehler aufgetreten.)). Dieses Problem tritt auf, weil das SRM-Client-Plug-In und der vSphere-Client die Kryptographie nicht aushandeln können, wenn das SRM-Client-Plug-In auf einer älteren Version von Windows ausgeführt wird. Wenn Sie die Desktopversion des vSphere-Clients und das SRM-Client-Plug-In unter Windows XP 64-Bit oder Windows Server 2003 SP2 ausführen, treten möglicherweise Inkompatibilitäten bei der Kryptographieunterstützung zwischen Server und Client auf.

        Umgehung: Laden Sie den Microsoft-Hotfix aus dem Microsoft KB-Artikel 948963 herunter und installieren Sie ihn. Dieser Hotfix wird bei den regulären Windows-Updates nicht angewendet, deshalb müssen Sie den Fix manuell herunterladen und anwenden.

      • Synchronisieren der virtuellen Maschinen, Wiederherstellung oder Vorgang zum erneuten Schutz schlagen mit einem allgemeinen vSphere Replication-Fehler fehl: Die angeforderte Instanz mit ID=<...> wurde auf der Remote-Site nicht gefunden.

        Obwohl der Vorgang einen Fehlschlag meldet, synchronisiert vSphere Replication erfolgreich den Status der virtuellen Maschine auf die Remote-Site. Dieser Fehler kann auftreten, wenn Sie einen Synchronisierungsvorgang anfordern oder Hauptvorgänge wie Wiederherstellung oder erneuten Schutz ausführen, die diesen Vorgang verwenden. Dies wurde behoben.

      • Koppeln der Sites aufgrund unterschiedlicher Zertifikatsvertrauensmethoden fehlgeschlagen

        Beim Koppeln von SRM-Sites wird der Fehler Lokale und Remoteserver verwenden unterschiedliche Zertifikatvertrauensmethodenangezeigt. Dieses Problem tritt auf, wenn das Rootzertifikat für die Zertifizierungsstelle (CA), die das Zertifikat signiert, auf dem SRM-Server fehlt. Um dieses Problem zu beheben, installieren Sie das Rootzertifikat für die signierende Zertifizierungsstelle des SRM-Zertifikats mithilfe der Microsoft Management Console. Führen Sie nach der Installation des Zertifikats einen Änderungsvorgang für die SRM-Installation durch, um das benutzergenerierte Zertifikat erneut anzugeben.

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

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

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

        Umgehung: Verwenden Sie einen Host mit einer einzelnen für den Verwaltungsdatenverkehr für Datenspeicher an der sekundären Site ausgewählten virtuellen Netzwerkkarte. Sie können das Hostnetzwerk auch neu konfigurieren, sodass sich die Adresse der ersten virtuellen Verwaltungsnetzwerkkarte von einem Netzwerk stammt, auf das vSphere Replication zugreifen kann.

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

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

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

        Umgehung: Verwenden Sie die Windows-Systemsteuerung, um das SRM-Installationsprogramm im Änderungsmodus zu starten.

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

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

        Dieses Problem entsteht durch Namenskollisionen.

        Umgehung: Führen Sie die Testwiederherstellungen oder Bereinigungsvorgänge auf derselben vCenter Server-Instanz nacheinander aus. Führen Sie für alle registrierten SRM-Server-Instanzen auf derselben vCenter Server-Instanz immer nur einen Workflow aus. Dieses Problem tritt nicht in allen gemeinsam genutzten Wiederherstellungs-Site-Umgebungen auf und es ist normalerweise nicht erforderlich, jeden Vorgang einzeln auszuführen. Namenskollisionen sind relativ selten.

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