VMware vCenter Site Recovery Manager 5.5 | 22. September 2013 | Build 1315893

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

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

Lokalisierung

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

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

Kompatibilität

SRM-Kompatibilitätstabelle

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

Kompatible Speicher-Arrays und Speicherreplizierungsadapter

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

VMware VSA-Unterstützung

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

Installation und Upgrade

Das Evaluierungshandbuch zur Unterstützung mit einer technischen Komplettlösung der wichtigsten Funktionen und Möglichkeiten von Site Recovery Manager 5.x finden Sie unter VMware vCenter Site Recovery Manager-Ressourcen für Business Continuity.

Weitere Informationen zur Installation und zum Upgrade von SRM finden Sie unter Installation und Konfiguration von Site Recovery Manager.

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.

WICHTIG: Wählen Sie beim Durchführen eines Upgrades für vSphere Replication im Virtual Appliance Management Interface (VAMI) unter Update > Einstellungen nicht die Option zum automatischen Aktualisieren von vSphere Replication aus. Wenn Sie automatische Updates auswählen, aktualisiert VAMI vSphere Replication auf die neueste Version, die möglicherweise nicht mit SRM 5.5 und vCenter Server 5.5 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.5 und vSphere Replication 5.5 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.5 enthalten sind, finden Sie unter VMware vCenter Site Recovery Manager-Downloads. Sie können auch die Quelldateien für jede GPL-, LGPL- oder vergleichbare Lizenz herunterladen, die es erfordert, den Quellcode oder Änderungen des Quellcodes für die neueste allgemein verfügbare Version von vCenter Site Recovery Manager zur Verfügung zu stellen.

Probleme und Einschränkungen

  • vSphere 5.5 enthält VMware Virtual SAN als eine experimentelle Funktion. Sie können mit Virtual SAN Tests durchführen, aber Virtual SAN nicht in einer Produktionsumgebung verwenden. Das Verwenden von SRM und vSphere Replication mit VMware Virtual SAN ist möglich, wird aber nicht unterstützt. Weitere Informationen zu den Einschränkungen bei der Verwendung von Virtual SAN mit SRM und vSphere Replication finden Sie unter Verwenden von vSphere Replication mit Virtual SAN Storage. Weitere Informationen zum Aktivieren von Virtual SAN finden Sie in der Virtual SAN Public Beta Community. VMware kann Fehler nicht beheben und Umgehungen oder Fehlerkorrekturen für Virtual SAN nicht anbieten. Wenn Sie mit Virtual SAN experimentieren, ist VMware an Ihrer Kritik und Anregungen interessiert. Reichen Sie über die Zugriffsmethoden, die auf den Virtual SAN Public Beta Community-Seiten beschrieben sind, eine Supportanfrage ein:
  • SRM 5.5 bietet eine eingeschränkte Unterstützung für vCloud Director-Umgebungen. Die Verwendung von SRM, um virtuelle Maschinen innerhalb von vCloud-Ressourcenpools (virtuelle Maschinen, die für eine Organisation bereitgestellt wurden) zu schützen, wird nicht unterstützt. Die Verwendung von SRM zum Schützen der Verwaltungsstruktur von vCD wird unterstützt. Informationen dazu, wie SRM zum Schützen der vCD-Serverinstanzen, vCenter Server-Instanzen und Datenbanken verwenden, die die Verwaltungsinfrastruktur für vCloud Director bereitstellen, finden Sie in der VMware vCloud Director-Infrastrukturflexibilitäts-Fallstudie.
  • Windows Server 2003 ist keine unterstützte Plattform für SRM-Server, aber mit dem SRM-Installationsprogramm können Sie SRM unter Windows Server 2003 installieren.
  • SRM 5.5 unterstützt nicht mehr IBM DB2 als SRM-Datenbank. DB2 als unterstützte Datenbank wird für vCenter Server 5.5 ebenfalls nicht mehr unterstützt. Wenn Sie DB2 als die SRM-Datenbank oder als eine externe vSphere Replication-Datenbank verwenden, wenden Sie sich an den VMware-Support für Anweisungen zum Migrieren Ihrer Daten auf eine unterstützte Datenbank.
  • vSphere Flash Read Cache ist nach der Wiederherstellung auf virtuellen Maschinen deaktiviert und die Reservierung ist auf Null gesetzt. Merken Sie sich die Cachereservierung der virtuellen Maschine von vSphere Web Client, bevor Sie eine Wiederherstellung auf einer virtuellen Maschine durchführen, die für die Verwendung von vSphere Flash Read Cache konfiguriert ist. Sie können vSphere Flash Read Cache nach der Wiederherstellung auf der virtuellen Maschine neu konfigurieren.
  • Einschränkungen gelten, wenn Sie SRM 5.5 in einer Konfiguration der gemeinsam genutzten Wiederherstellungs-Site (N:1) verwenden. Weitere Informationen finden Sie unter Bekannte Probleme unter Verwendung von SRM 5.5 in einer Konfiguration der gemeinsam genutzten Wiederherstellungs-Site.
  • Sie können Array-basierten Schutz mit SRM 5.5 verwenden, um maximal 50 LUNs zu schützen. Weitere Informationen finden Sie unter Einschränkungen bei der Verwendung von SRM mit Array-basierter Replizierung in umfangreichen Umgebungen.

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.

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

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

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

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

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

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

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

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

    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.

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

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

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

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

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

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

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

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

    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.

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

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

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

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

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

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

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

    Umgehung: Führen Sie den Wiederherstellungsplan erneut aus.

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

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

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

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

    Umgehung:

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

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

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

    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.

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

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

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

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

  • Abbrechen des Wiederherstellungsplans nicht abgeschlossen

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

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

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

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

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

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

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

    Umgehung: Führen Sie die Wiederherstellung erneut durch.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Umgehung: Führen Sie die geplante Migration erneut durch, nachdem vSphere vMotion der virtuellen Maschine abgeschlossen wurde.

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

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

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

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

    Umgehung: Starten Sie den vSphere Replication-Server neu.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Wenn Sie eine Wiederherstellung auf einer virtuellen Maschine durchführen, die eine leere Thin-bereitgestellte Festplatte enthält, und wenn Sie SRM dafür konfiguriert haben, nicht auf VMware Tools zu warten oder diese virtuelle Maschine einzuschalten, führt das erneute Schützen innerhalb einiger Sekunden nach der Wiederherstellung dazu, dass der SRM-Server unerwartet auf der Schutz-Site gestoppt wird. Wenn Sie den SRM-Server neu starten, wird in den Protokollen der folgende Fehler angezeigt:

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

    Das Ausführen der Bereinigung führt zu demselben Fehler. Dieser Fehler tritt nicht bei virtuellen Maschinen mit Festplatten auf, die nicht leer sind und ein Betriebssystem installiert haben. Dieses Problem tritt in der Regel auf, wenn Sie das erneute Schützen mithilfe von SRM API starten. Wenn Sie das erneute Schützen von der SRM-Schnittstelle starten, reicht die Zeit zwischen dem Ende der Wiederherstellung und dem Zeitpunkt aus, an dem Sie das erneute Schützen gestartet haben, damit dieses Problem nicht auftritt.

    Umgehung: Warten Sie nach dem Durchführen der Wiederherstellung einige Sekunden, bevor Sie das erneute Schützen ausführen.

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

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

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

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

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

    Umgehung: Führen Sie die Testbereinigung aus, bevor Sie ein Upgrade von SRM und vSphere Replication auf die Version 5.5 durchführen. Wenn Sie bereits ein Upgrade von SRM und vSphere Replication auf die Version 5.5 durchgeführt haben, müssen Sie die Testdaten manuell von der vSphere Replication-Datenbank auf der Wiederherstellungs-Site löschen.

    Externe SQL Server- oder Oracle Server-Datenbank:

    1. Melden Sie sich bei der Hostmaschine für die vSphere Replication-Datenbank auf der Wiederherstellungs-Site an.
    2. Führen Sie die folgenden SQL-Anweisungen auf der vSphere Replication-Datenbank aus:

      delete from DiskImageEntity where vmImage_dbId in (select dbId from VmImageEntity where groupImage_dbId not in (select COALESCE(committedImage_dbId, 0) from SecondaryGroupEntity));
      delete from ConfigFileImageEntity where vmImage_dbId in (select dbId from VmImageEntity where groupImage_dbId not in (select COALESCE(committedImage_dbId, 0) from SecondaryGroupEntity));
      delete from VmImageEntity where groupImage_dbId not in (select COALESCE(committedImage_dbId, 0) from SecondaryGroupEntity);
      delete from GroupImageEntity where dbId not in (select COALESCE(committedImage_dbId, 0) from SecondaryGroupEntity);

    Eingebettete PostgreSQL-vSphere Replication-Datenbank:

    1. Melden Sie sich bei der vSphere Replication-Appliance auf der Wiederherstellungs-Site an.
    2. Geben Sie den folgenden Befehl ein:

      /opt/vmware/vpostgresql/1.0/bin/psql -U vrmsdb

    3. Führen Sie die folgenden SQL-Anweisungen aus:

      delete from DiskImageEntity where vmImage_dbId in (select dbId from VmImageEntity where groupImage_dbId not in (select COALESCE(committedImage_dbId, 0) from SecondaryGroupEntity));
      delete from ConfigFileImageEntity where vmImage_dbId in (select dbId from VmImageEntity where groupImage_dbId not in (select COALESCE(committedImage_dbId, 0) from SecondaryGroupEntity));
      delete from VmImageEntity where groupImage_dbId not in (select COALESCE(committedImage_dbId, 0) from SecondaryGroupEntity);
      delete from GroupImageEntity where dbId not in (select COALESCE(committedImage_dbId, 0) from SecondaryGroupEntity);

    4. Geben Sie \q ein oder drücken Sie zum Beenden STRG+D.
    1. Das Ausführen des erneuten Schützens auf wiederhergestellten virtuellen Maschinen mit Snapshots schlägt mit einem Fehler eines gesperrten Datenspeichers fehl, wenn Sie ESXi Server 5.0 verwenden.

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

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

    Bekannte Probleme unter Verwendung von SRM 5.5 in einer Konfiguration der gemeinsam genutzten Wiederherstellungs-Site

    Wenn Sie SRM 5.5 mit einer Konfiguration der gemeinsam genutzten Wiederherstellungs-Site verwenden, die auch als N:1-Konfiguration bekannt ist, gelten die folgenden Einschränkungen:

    • Die Wiederherstellung von vSphere Replication schlägt mit dem Fehler Synchronisierungsüberwachung abgebrochen fehl.

      Beim Ausführen einer Wiederherstellung von vSphere Replication in einer Konfiguration der gemeinsam genutzten Wiederherstellungs-Site schlägt die Wiederherstellung möglicherweise mit dem folgenden Fehler fehl: Fehler - VR-Synchronisierung für VRM-Gruppe replication_group fehlgeschlagen. Synchronisierungsüberwachung abgebrochen. Überprüfen Sie den Replizierungsdatenverkehr zwischen Quell-Host und VR-Zielserver auf mögliche Verbindungsprobleme. Die Synchronisierung wird automatisch fortgesetzt, sobald die Verbindungsprobleme behoben sind. Dieses Problem tritt möglicherweise auf, wenn die Wiederherstellungs-Site wie folgt geladen wird:

      • Es sind virtuelle Maschinen mit Festplatten größer als 2 TB vorhanden
      • Es sind viele wiederherzustellende virtuelle Maschinen vorhanden

      Umgehung:

      1. Melden Sie sich bei der vSphere Replication-Appliance als "root" an.
      2. Öffnen Sie die Datei /opt/vmware/hms/conf/hms-configuration.xml.
      3. Ändern Sie den Wert im Tag <hms-sync-secondary-passive-state-toleration-period> auf 900.000 Millisekunden.
      4. Speichern Sie die Änderungen und starten Sie den vSphere Replication-Dienst neu:

        service hms restart

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

    • SRM meldet Zeitüberschreitungsfehler während des Einschaltens der virtuellen Maschinen auf der gemeinsam genutzten Wiederherstellungs-Site.

      Wenn ein einzelner vCenter Server bei einer großen SRM-Einrichtung eine große Anzahl von virtuellen Maschinen auf der gemeinsam genutzten Wiederherstellungs-Site verwaltet, wie beispielsweise 1000 oder mehr, kann SRM die Zeitüberschreitungsfehler melden, während virtuelle Maschinen auf der gemeinsam genutzten Wiederherstellungs-Site eingeschaltet werden. Die Fehlermeldung lautet Fehler:Zeit für Vorgang überschritten:900 Sekunden.

      Umgehung:

      1. Wechseln Sie auf der SRM-Server-Hostmaschine auf der Wiederherstellungs-Site zu C:\Program Files\VMware\VMware vCenter Site Recovery Manager\config.
      2. Öffnen Sie vmware-dr.xml in einem Texteditor.
      3. Erhöhen Sie den Standardwert für die Zeitüberschreitung RemoteManager von 900 auf beispielsweise 1200.
        <RemoteManager>
            <DefaultTimeout>900</DefaultTimeout>
         </RemoteManager>
                          
      4. Starten Sie den SRM-Server-Dienst neu.

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

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

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

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

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

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

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