VMware vCenter Site Recovery Manager 5.0.3.3a | 7. April 2016

VMware vCenter Site Recovery Manager 5.0.3.3 | 29. Oktober 2015 | Build 3022051

VMware vCenter Site Recovery Manager 5.0.3.2 | 22. Juli 2014 | Build 1964819

VMware vCenter Site Recovery Manager 5.0.3.1 | 29. Mai 2014 | Build 1848414

VMware vCenter Site Recovery Manager 5.0.3 | 17. Oktober 2013 | Build 1344912

Letzte Aktualisierung: 7. April 2016

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

Informationen zu Patch-Versionen von Site Recovery Manager 5.0.3.x einschließlich Angaben zu gegebenenfalls erforderlichen Patches für vSphere Replication finden Sie in den entsprechenden Knowledgebase-Artikeln.

Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

Neuigkeiten

VMware vCenter Site Recovery Manager 5.0.3 bietet folgende Verbesserungen:

Lokalisierung

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

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

Kompatibilität

SRM-Kompatibilitätstabelle

Aktuelle Interoperabilitäts- und Produktkompatibilitätsinformationen finden Sie in den Kompatibilitätstabellen für VMware vCenter Site Recovery Manager 5.0.

Kompatible Speicher-Arrays und Speicherreplizierungsadapter

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

VMware VSA-Unterstützung

Virtuelle Maschinen, die sich auf der vSphere Storage Appliance (VSA) befinden, können durch SRM 5.0.3 unter Verwendung von vSphere Replication geschützt werden. VSA benötigt für das Zusammenspiel mit SRM 5.0.3 keinen Speicherreplizierungsadapter (SRA).

Installation und Upgrade

SRM 5.0.3 kann nur dann mit ESXi Server 4.0 und 4.1 sowie mit Virtual Infrastructure 3.5 ausgeführt werden, wenn Sie die Array-basierte Replizierung verwenden. Wenn Sie vSphere Replication verwenden, entweder allein oder in Verbindung mit der Array-basierten Replizierung, müssen Sie als Teil des Upgrade-Vorgangs die ESXi Server-Hosts auf Version 5.0.x aktualisieren.

Weitere Informationen dazu, wie Sie SRM 5.0.3 ohne ein Upgrade von einer vorherigen Version installieren, finden Sie unter Installieren und Aktualisieren von Site Recovery Manager im Administratorhandbuch für Site Recovery Manager .

Upgrade von SRM 5.0.x auf SRM 5.0.3

Sie können ein In-Place-Upgrade von SRM 5.0, 5.0.1 oder 5.0.2 auf SRM 5.0.3 durchführen. Es wird empfohlen, statt Neuinstallationen In-Place-Upgrades durchzuführen, da bei diesem Vorgang alle Verlaufsberichte, Wiederherstellungspläne, Schutzgruppen und Anpassungen der Wiederherstellungspläne beibehalten werden. Sie müssen den Upgrade-Vorgang sowohl auf der geschützten Site als auch auf der Wiederherstellungs-Site durchführen.

  1. Melden Sie sich bei der Maschine an, auf der Sie den SRM-Server auf der geschützten Site ausführen.
  2. Sichern Sie die SRM-Datenbank mit den Tools der Datenbanksoftware.
  3. Laden Sie das Installationsprogramm VMware-srm-5.00,3-1344912.exe herunter und führen Sie es aus.
  4. Klicken Sie auf Ja, um das Upgrade von SRM zu bestätigen.
  5. Klicken Sie auf Weiter, um SRM 5.0.3 mit den Einstellungen der vorherigen SRM-Installation zu verwenden.
  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. Deinstallieren Sie das SRM-Client-Plug-In der früheren Version.
  2. 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.
  3. Wählen Sie Plug-Ins > Plug-Ins verwalten.
  4. Klicken Sie auf Herunterladen und installieren, um das SRM 5.0.3-Client-Plug-In zu installieren.
  5. 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.
  6. Wiederholen Sie den Vorgang für alle vSphere-Client-Instanzen, mit denen Sie eine Verbindung zum SRM-Server herstellen.

HINWEIS: Microsoft hat ein Sicherheitsupdate ausgegeben, das bewirkt, dass Windows keine Zertifikate mit RSA-Schlüsseln akzeptiert, die aus weniger als 1024 Bit bestehen. Weitere Informationen hierzu finden Sie unter http://support.microsoft.com/kb/2661254. Dieser Standard wird Ende 2013 auf 2.048 Bit erhöht. Folglich generiert SRM 5.0.2 und höher automatisch Zertifikate mit 2.048-Bit-RSA-Schlüsseln. SRM 5.0 und 5.0.1 generieren automatisch Zertifikate mit 512-Bit-RSA-Schlüsseln. Beim Upgrade von SRM 5.0 oder 5.0.1 auf 5.0.3 behält SRM die Zertifikate der früheren Installation bei. Wenn Sie das Microsoft-Sicherheitsupdate installieren, müssen Sie daher ein Upgrade der SRM-Zertifikate durchführen, damit diese RSA-Schlüssel mit einer Mindestgröße von 1024 Bit, oder besser noch, 2048 Bit verwenden.

  • Wenn Sie automatisch generierte Zertifikate mit SRM 5.0 oder 5.0.1 verwendet haben, können Sie nach dem Upgrade auf SRM 5.0.3 ein Upgrade der Zertifikate durchführen, indem Sie das SRM 5.0.3-Installationsprogramm im Änderungsmodus erneut ausführen und die Option zum Generieren eines neuen 2048-Bit-Zertifikats wählen.
  • Falls Sie Zertifikate verwendet haben, die von einer Zertifizierungsstelle in SRM 5.0 oder 5.0.1 signiert wurden, müssen Sie Upgrade und Import des Zertifikats manuell vornehmen und sicherstellen, dass RSA-Schlüssel mit einer Mindestgröße von 1024 Bit, oder besser noch, 2048 Bit verwendet werden.

Upgrade von vSphere Replication 1.0.x auf vSphere Replication 1.0.3

Die Versionen SRM 5.0 bis 5.0.2 enthalten vSphere Replication 1.0 bis 1.0.2. SRM 5.0.3 enthält vSphere Replication 1.0.3. Beim Upgrade von SRM 5.0, 5.0.1 oder 5.0.2 auf SRM 5.0.3 wird nicht automatisch ein Upgrade von vSphere Replication 1.0, 1.0.1 oder 1.0.2 auf vSphere Replication 1.0.3 durchgeführt. vSphere Replication 1.0.3 ist funktional identisch mit vSphere Replication 1.0.2, enthält aber zudem Bugfixes. Sie können mit dem vSphere Update Manager ein Update des VRM-Servers und der VR-Server durchführen. Alternativ dazu können Sie das Virtual Appliance Management Interface (VAMI) für den VRM-Server und die VR-Server verwenden, um das Update durchzuführen.

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,0.x kompatibel ist. Lassen Sie die Aktualisierungseinstellungen auf Keine automatischen Aktualisierungen.

So aktualisieren Sie die VRM-Server mithilfe der VAMI:

  1. Upgrade des SRM-Servers und -Clients auf SRM 5.0.3.
  2. Wechseln Sie zur Konfigurationsbenutzeroberfläche des VRM-Servers unter https:// VRM-Serveradresse:8080.
  3. Melden Sie sich bei der VRM-Server-Konfigurationsbenutzeroberfläche als "root" an.
  4. Klicken Sie auf die Registerkarte Update.
  5. Klicken Sie auf Einstellungen.
  6. Wählen Sie Angegebenes Repository verwenden und fügen Sie die Update-URL in das Textfeld Repository-URL ein:
    http://vapp-updates.vmware.com/vai-catalog/valm/vmw/05d561bc-f3c8-4115-bd9d-22baf13f7178/1.0.3.0
    HINWEIS: Informationen zum Erhalt der VAMI-Upgrade-URL für eine Patch-Version von vSphere Replication 1.0.3.x finden Sie im Knowledgebase-Artikel für die entsprechende Patch-Version von Site Recovery Manager 5.0.3.x.
  7. Klicken Sie auf Status.
  8. Klicken Sie auf Updates überprüfen. Die Update-Prüfung zeigt an, dass Version 1.0.3.0 verfügbar ist.
  9. Klicken Sie auf Updates installieren und dann auf OK.
  10. Wählen Sie nach Beendigung des Updates die Registerkarte VRM aus, klicken Sie auf Konfiguration und dann auf Neu starten, um den VRM-Server neu zu starten.
  11. Wiederholen Sie den Vorgang für den VRM-Server auf der Wiederherstellungs-Site.

So aktualisieren Sie die VR-Server mithilfe des VAMI:

  1. Führen Sie ein Upgrade des VRM-Servers durch.
  2. Wechseln Sie zur Konfigurationsbenutzeroberfläche des VR-Servers unter https:// VR-Adresse:5480.
  3. Melden Sie sich bei der VR-Server-Konfigurationsbenutzeroberfläche als "root" an.
  4. Klicken Sie auf die Registerkarte Update.
  5. Klicken Sie auf Einstellungen.
  6. Wählen Sie Angegebenes Repository verwenden und fügen Sie die Update-URL in das Textfeld Repository-URL ein:
    http://vapp-updates.vmware.com/vai-catalog/valm/vmw/9f73d994-d8b5-11df-ace9-18a9053dae02/1.0.3.4117
    HINWEIS: Informationen zum Erhalt der VAMI-Upgrade-URL für eine Patch-Version von vSphere Replication 1.0.3.x finden Sie im Knowledgebase-Artikel für die entsprechende Patch-Version von Site Recovery Manager 5.0.3.x.
  7. Klicken Sie auf Status.
  8. Klicken Sie auf Updates überprüfen. Die Update-Prüfung zeigt an, dass Version 1.0.3 verfügbar ist.
  9. Klicken Sie auf Updates installieren und dann auf OK.
  10. Wählen Sie nach Beendigung des Updates die Registerkarte System aus, klicken Sie auf Informationen und dann auf Neu starten, um den VR-Server neu zu starten.
  11. Wiederholen Sie den Vorgang für alle VR-Server auf der Schutz- und der Wiederherstellungs-Site.

Upgrade von SRM 4.1.2 auf SRM 5.0.3

Sie können ein In-Place-Upgrade von SRM 4.1.2 auf SRM 5.0.3 durchführen. Es wird empfohlen, statt Neuinstallationen In-Place-Upgrades durchzuführen, da bei diesem Vorgang alle Verlaufsberichte, Wiederherstellungspläne, Schutzgruppen und Anpassungen der Wiederherstellungspläne beibehalten werden. Um ein Upgrade des SRM-Clients auf Version 5.0.3 durchzuführen, müssen Sie zunächst den SRM 4.1.2-Client deinstallieren.

HINWEIS: Das Upgrade von SRM 4.1 oder SRM 4.1.1 auf SRM 5.0.3 wird nicht unterstützt.

Um ein Upgrade von SRM 4.1.2 auf SRM 5.0.3 durchzuführen, befolgen Sie die Schritte zum Upgrade von SRM 4.1 bzw. 4.1.1 auf SRM 5.0 unter Durchführen eines Upgrades von SRM im Administratorhandbuch für Site Recovery Manager . Weitere Informationen hierzu finden Sie auch im Blog SRM 5 Upgrade Process .

Open Source-Komponenten

Informationen über Copyright und Lizenzen für die Open Source-Softwarekomponenten, die im Lieferumfang von vCenter Site Recovery Manager 5.0.3 enthalten sind, finden Sie auf der SRM-Downloads-Site. 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

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

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

  • Interoperabilität mit Storage vMotion und Storage DRS
    Aufgrund einiger weniger Fälle, bei denen die Wiederherstellbarkeit während der Speicherverschiebung beeinträchtigt werden kann, wird Site Recovery Manager 5.0.3 weder für die Verwendung mit Storage vMotion (SVmotion) noch für die Verwendung mit SDRS (Storage Distributed Resource Scheduler), einschließlich der Verwendung eines Datenspeicher-Clusters, unterstützt. Wenn Sie SVMotion zum Verschieben einer geschützten virtuellen Maschine aus einem Datenspeicher in einer Schutzgruppe zu einem nicht geschützten Datenspeicher verwenden, müssen Sie den Schutz dieser virtuellen Maschine manuell neu konfigurieren.

  • Die Netzwerkadressenübersetzung (NAT) wird für SRM Server oder vSphere Replication Server nicht unterstützt
    Beim Konfigurieren von SRM müssen Sie SRM Server mit einer IP-Adresse konfigurieren, die für den entsprechenden SRM Server sichtbar ist, mit dem er gekoppelt wird. Weitere diesbezügliche Informationen finden Sie unter NAT-Konfiguration wird in SRM nicht unterstützt.

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

  • Erneuter Schutz und automatisiertes Failback werden nicht durch vSphere Replication unterstützt
    In SRM 5.0.x werden der erneute Schutz und das automatische Failback nur mit Array-basierter Replizierung unterstützt. Virtuelle Maschinen, die Sie mit vSphere Replication schützen, können mithilfe vorhandener Wiederherstellungspläne nicht automatisch auf der ursprünglichen Site wiederhergestellt werden.

  • Bestimmte vSphere-Funktionen und RDM werden von vSphere Replication nicht unterstützt
    Sie können vSphere Replication 1.0.x nicht in Verbindung mit vSphere Fault Tolerance, Vorlagen virtueller Maschinen, verknüpften Klonen oder mit der physischen Raw-Festplattenzuordnung (RDM) verwenden.

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

  • Schutz und Wiederherstellung von virtuellen Maschinen mit Arbeitsspeicherzustand-Snapshots
    Beim Schützen von virtuellen Maschinen mit Arbeitsspeicherzustand-Snapshots müssen die ESX-Hosts der Schutz- und Wiederherstellungs-Sites über kompatible CPUs verfügen, wie dies in den folgenden VMware-Knowledgebase-Artikeln beschrieben ist: vMotion-CPU-Kompatibilitätsanforderungen für Intel-Prozessoren und vMotion-CPU-Kompatibilitätsanforderungen für AMD-Prozessoren. Auf den Hosts müssen außerdem dieselben BIOS-Funktionen aktiviert sein. Wenn die BIOS-Konfigurationen der Server nicht übereinstimmen, wird eine Kompatibilitätsfehlermeldung angezeigt, auch wenn sie ansonsten identisch sind. Die beiden häufigsten Funktionen, die überprüft werden sollten, sind „Non-Execute Memory Protection“ (NX/XD) und „Virtualization Technology“ (VT/AMD-V). Informationen zu weiteren Einschränkungen beim Schutz und der Wiederherstellung von virtuellen Maschinen mit Snapshots finden Sie unter Einschränkungen beim Schutz und der Wiederherstellung von virtuellen Maschinen im Administratorhandbuch für Site Recovery Manager .

  • Maximale Anzahl der Wiederherstellungspläne pro SRM-Serverinstanz
    Sie können maximal die folgende Anzahl von Wiederherstellungsplänen pro SRM-Serverinstanz erstellen:

    • Array-basierte Replizierung: 150 Wiederherstellungspläne
    • vSphere Replication: 250 Wiederherstellungspläne

    Informationen über die Anzahl der Wiederherstellungspläne, die Sie gleichzeitig ausführen können, sowie andere Einschränkungen beim Betrieb von SRM 5.0.x finden Sie im Administratorhandbuch für Site Recovery Manager .

  • Verwenden von MD5-Zertifikaten mit dem vSphere Replication-Verwaltungsserver
    SRM 5.0.3 und vSphere Replication 1.0.3 ermöglichen Ihnen, den vSphere Replication-Verwaltungsserver für die Verwendung von MD5-Zertifikaten zu konfigurieren. Da der MD5-Zertifikat-Signaturalgorithmus allerdings anfällig für Angriffe ist, sollten Sie, falls möglich, mindestens SHA1 als Zertifikat-Signaturalgorithmus verwenden. Sie können MD5-Zertifikate mit SRM 5.0.3 und vSphere Replication 1.0.3 verwenden, aber Sie sollten den Übergang Ihrer Infrastruktur zur Verwendung von mindestens SHA1 als Zertifikat-Signaturalgorithmus so bald wie möglich einleiten.

  • Der Signaturalgorithmus der vCenter Server-Standardzertifikate ist SHA256RSA. SHA256RSA wird von Windows Server 2003 nicht unterstützt. Führen Sie zur Installation von SRM 5.0.3 unter Windows Server 2003 einen der folgenden Schritte aus:

    • Installieren Sie einen der folgenden Hotfixes von Microsoft:
    • Aktualisieren Sie das Host-Betriebssystem für SRM Server auf Windows Server 2008 oder höher.
    • Vergewissern Sie sich, dass Sie SHA1RSA für Ihre vCenter Server-Zertifikate verwenden. Anderenfalls müssen Sie die Zertifikate aktualisieren oder ein Upgrade von vCenter Server und SRM auf die Version 5.5 durchführen.

Behobene Probleme

Die folgenden Probleme wurden in SRM 5.0.3 behoben.

  • NEU Die Patch-Version von Site Recovery Manager 5.0.3.3a behebt ein Problem hinsichtlich einer Sicherheitslücke in der glibc-Bibliothek, das die Remoteausführung von Code zulässt.

    Eine Sicherheitslücke in der glibc-Bibliothek, die die Remoteausführung von Code zulässt, wirkt sich möglicherweise auf Ihre vSphere Replication-Appliance aus.

    Weitere Informationen zum Installieren der Patch-Version von Site Recovery Manager 5.0.3.3a finden Sie unter http://kb.vmware.com/kb/2144832

  • 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. Dies wurde behoben.

  • Bei der Ausführung einer geplanten Migration wird der SRM-Dienst unerwartet beendet, wenn der Host nicht verbunden ist.

    Wenn ein ESXi-Host von vCenter Server getrennt ist und Sie eine geplante Migration ausführen, kann der SRM-Dienst beim Schritt Volume auf Schreibgeschützt festlegen des Wiederherstellungsplans unerwartet beendet werden. Dies wurde behoben.

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

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

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

    Das Wiederherstellen einer virtuellen Windows Server 2012-DC-Maschine ist mithilfe der Array-basierten Replizierung oder von vSphere Replication möglich. Die Durchführung eines Wiederherstellungsvorgangs auf solch einer virtuellen Maschine könnte allerdings zu einem Versagen des Windows Server 2012-DC-Schutzmechanismus führen. Dies wurde behoben.

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

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

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

    Problemumgehung: Wenn Probleme mit nicht verfügbaren Datenspeichern auftreten, können Sie eine neue Einstellung in SRM 5.0.3 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.

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

  • SRM kann VMFS-Volumes nicht mounten, und es wird der Fehler Bereits gemountet ausgegeben.

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

  • Fehlgeschlagene Wiederherstellung sorgt für wiederholte Ausfälle des SRM-Servers.

    Falls ein Wiederherstellungsplan keine Fortschritte erzielt, können Benutzer den Plan erneut ausführen. In seltenen Fällen kann eine erneute Ausführung des Wiederherstellungsplans zu einem unerwarteten Ausfall des SRM-Servers führen. Nach dem Neustart des SRM-Servers verursacht der Wiederherstellungsplan weiterhin unerwartete Serverausfälle. Die Protokolle zeigen mit dem Protokolleintrag IP-Anpassung für VM erfolgreich VM-Namean, dass eine virtuelle Maschine kurz vor dem Ausfall des SRM-Servers geändert wurde. Dies wurde behoben.

  • Der SRM-Dienst wird nach Überprüfung des Lizenz-Managers während des Schutzes einer virtuellen Maschine angehalten.

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

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

  • SRM 5.0.2 kann unter Windows Server 2012 nicht installiert werden.

    SRM Server 5.0.2 konnte unter Windows Server 2012 nicht installiert werden. Dies wurde behoben und SRM 5.0.3 unterstützt nun Windows Server 2012 als Hostbetriebssystem für SRM Server.

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

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

  • SRM Server wird während einer Testbereinigung unerwartet beendet.

    In seltenen Fällen wird SRM Server während einer Testbereinigung mit folgendem Fehler unerwartet beendet Panic: Assert Failed: .../srm/src/replication/providers/storageProvider/data/groupPostFailoverInfoData.cpp:108. Dies wurde behoben.

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

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

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

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

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

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

  • vSphere Replication entfernt Festplattendateien für nicht replizierte virtuelle Maschinen von der Ziel-Site, wenn eine Datei und eine replizierte Festplattendatei denselben Namen haben.

    Wird unmittelbar bevor im Assistenten „Replizierung konfigurieren“ auf „Fertigstellen“ geklickt wird, eine Festplatte mit demselben Namen wie eine replizierte Festplatte im Zielspeicherort des Datenspeichers angezeigt, schlägt die Aufgabe „Replizierung konfigurieren“ fehl, da vSphere Replication nicht erwartet, die Festplatte dort zu finden, und fälschlicherweise die Festplatte entfernt, die nicht von dieser Aufgabe erstellt wurde. Dies wurde behoben.

  • Test-Failover, geplante Migration oder Notfallwiederherstellung schlagen mit dem Fehler Error creating ... image ... NullPointerException" fehl.

    VRMS erhält möglicherweise in einer bestimmten Phase des Notfallwiederherstellungs-Workflows keine Antwort vom VR-Server. Der Notfallwiederherstellungsvorgang schlägt fehl. Erneute Ausführungen des Vorgangs schlagen stets mit dem Fehler Error creating ... image ... NullPointerException" fehl. Dies wurde behoben und erneute Ausführungen des Vorgangs waren erfolgreich.

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

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

  • vSphere Replication löscht virtuelle Testmaschinen, wenn RevertSwap während der Testbereinigung fehlschlägt.

    Wenn RevertSwap bei der Testbereinigung fehlschlägt, werden von vSphere Replication auf der sekundären Site erstellte virtuelle Testmaschinen gelöscht. Dadurch werden auch die übergeordneten Festplatten gelöscht, sodass vor der Durchführung einer echten Wiederherstellung eine vollständige Synchronisierung durchgeführt werden muss. Dies wurde behoben. Anstatt die virtuelle Testmaschine zu löschen, hebt vSphere Replication deren Registrierung auf, wodurch die Festplatten nicht gelöscht werden.

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.

  • Bei großen Festplatten wird unnötigerweise eine vollständige Synchronisierung durchgeführt

    Wenn Festplatten, die größer als 256 GB sind, mit vSphere Replication (VR) geschützt werden, wird bei jedem Vorgang, der zu einem internen Neustart des virtuellen Festplattengeräts führt, eine vollständige Synchronisierung der Festplatte durchgeführt. Interne Neustarts treten in den folgenden Fällen auf:

    • Eine virtuelle Maschine wird neu gestartet
    • Eine virtuelle Maschine wird mit vMotion verschoben
    • Eine virtuelle Maschine wird neu konfiguriert
    • Von einer virtuellen Maschine wird ein Snapshot erstellt
    • Die Replizierung wird angehalten und fortgesetzt

    Die vollständige Synchronisierung wird von ESX initiiert und jede Lösung dieses Problems würde ein Update auf ESX erfordern. Diese Synchronisierungen umfassen zusätzliche E/A für die Festplatten der Schutz- und der Wiederherstellungs-Site, was oft länger dauert als die Recovery Point Objective (RPO) und zur Folge hat, dass das RPO-Ziel verfehlt wird. Dieses Problem besteht in ESXi Server 5.0, wurde aber in ESXi Server 5.0 Update 1 behoben.

    Problemumgehung: Führen Sie ein Upgrade von ESXi Server auf Version 5.0 Update 1 oder höher durch.

  • Die Einstellung von LVM.enableResignature auf 1 bleibt nach einem Test-Failover bestehen

    SRM unterstützt keine ESX-Umgebungen, in denen das Flag LVM.enableResignature auf 0 festgelegt ist. Während eines Test-Failovers oder eines tatsächlichen Failovers legt SRM LVM.enableResignature automatisch auf 1 fest, wenn das Flag nicht bereits festgelegt wurde. SRM legt dieses Flag fest, um die Snapshot-Volumes neu zu signieren, und mountet sie zur Wiederherstellung auf ESX-Hosts. Nach Abschluss des Vorgangs ist das Flag weiterhin auf 1 festgelegt. Weitere Informationen dazu finden Sie unter KB 2010051.

  • vSphere Replication kann auf einer virtuellen Maschine nicht neu konfiguriert werden, nachdem während der Konfiguration der Fehler Fehler beim Übergeben von Transaktionen aufgetreten ist

    Wenn Sie während des Konfigurierens der Replizierung einer virtuellen Maschine den Fehler Fehler beim Übergeben von Transaktionen erhalten, schlagen alle Versuche fehl, die Replizierung auf der virtuellen Maschine neu zu konfigurieren. Dieses Problem tritt auf, weil vSphere Replication nach dem Konfigurationsversuch die Konfigurationsdaten nicht ordnungsgemäß bereinigt. Folglich scheint die Replizierung der virtuellen Maschine für vSphere Replication konfiguriert zu sein, sie ist es aber nicht.

    Problemumgehung: Damit die Konfigurationsdaten ordnungsgemäß bereinigt werden, deaktivieren Sie die Replizierung der virtuellen Maschine über die Befehlszeile.

    1. Melden Sie sich bei der ESXi-Konsole an.
    2. Führen Sie einen Befehl aus, um die ID der virtuellen Maschine im ESXi-Host nachzuschlagen.
      # vim-cmd vmsvc/getallvms | grep 
      virtual_machine_name 
                            
      Die ID der virtuellen Maschine ist die Nummer in der ersten Spalte.
    3. Führen Sie einen Befehl aus, um die Replizierung für die virtuelle Maschine mit der ID, die Sie zuvor ermittelt haben, zu deaktivieren.
      # vim-cmd hbrsvc/vmreplica.disable 
      virtual_machine_ID
                            
  • Das Kontrollkästchen für das erzwungene Failover bleibt ausgewählt, nachdem Sie die geplante Migration aktiviert haben

    Wenn Sie einen Wiederherstellungsplan ausführen, wobei die Option für das erzwungene Failover ausgewählt ist, und Sie dann die geplante Migration aktivieren, indem Sie die Option Geplante Migration wählen, bleibt das Kontrollkästchen für das erzwungene Failover im Assistenten "Wiederherstellungsplan ausführen" ausgewählt und grau dargestellt. Dieses Problem betrifft nur die Benutzeroberfläche und SRM funktioniert ordnungsgemäß.

    Problemumgehung: Schließen und öffnen Sie den Assistenten "Wiederherstellungsplan ausführen" neu, nachdem Sie die Option für das erzwungene Failover deaktiviert haben.

  • Wiederherstellungs- bzw. Migrationsvorgänge können fehlschlagen, wenn Platzhalterdatenspeicher nicht für alle Hosts in einem geschützten Cluster sichtbar sind

    Während der Wiederherstellung und Migration werden Platzhalter-VMs durch wiederhergestellte virtuelle Maschinen ersetzt. Wenn Sie über einen Cluster mit mehreren Hosts auf der Wiederherstellungs-Site verfügen, müssen alle Platzhalterdatenspeicher für alle Hosts im Cluster verfügbar sein, anderenfalls kann das Auslagern virtueller Maschinen fehlschlagen. SRM hindert Sie nicht daran, Platzhalterdatenspeicher auszuwählen, die nicht allen Hosts im Cluster zur Verfügung stehen. Wenn Platzhalterdatenspeicher nicht für alle Hosts sichtbar sind, schlägt der Wiederherstellungsplan mit dem Fehler Fehler - Zugriff auf die Datei [Datenspeicher] nicht möglich. Die Registrierung der geschützten VMs wurde aufgehoben fehl. Hosts müssen Zugriff auf die Datenspeicher haben, die sowohl die Platzhalter-VMs als auch die wiederhergestellten virtuellen Maschinen enthalten.

    Problemumgehung: Überprüfen Sie manuell, dass die Datenspeicher sowohl für die Platzhalter-VMs als auch für die wiederhergestellten virtuellen Maschinen allen Hosts in einem geschützten Cluster sichtbar sind.

  • Nach dem Upgrade werden VRM-Server- und VR-Server-Versionen auf der Registerkarte "Übersicht" der virtuellen Maschine nicht aktualisiert

    Wenn Sie ein Upgrade einer vorhandenen Installation der vSphere Replication Manager Server-Appliance (VRM-Server) von Version 1.0 auf Version 1.0.1 durchführen, werden die Versionsnummern von VRM-Server und VR-Server auf der Registerkarte "Übersicht" der virtuellen Maschine nicht aktualisiert. Wenn Sie in der vCenter Server-Bestandsliste den VRM-Server bzw. einen VR-Server auswählen, wird auf der Registerkarte "Übersicht" selbst dann weiterhin Version 1.0.0.0 angezeigt, wenn der VRM-Server auf Version 1.0.1 aktualisiert wurde. Wenn Sie eine Neuinstallation von VRM-Server-Version 1.0.1 durchführen, wird auf der Registerkarte "Übersicht" die korrekte Versionsnummer angezeigt.

    Problemumgehung: Überprüfen Sie die Versionsnummer in der Verwaltungsschnittstelle der virtuellen VRM-Server-Appliance:

    1. Melden Sie sich bei https:// IP-Adresse des VRM-Servers:8080 an.
    2. Wählen Sie die Registerkarte Update aus.
    3. Klicken Sie auf Status. Die Versionsnummer ist 1.0.1.0.

    Im vSphere-Client wird in der Konsole für den VRM-Server bzw. VR-Server jedoch die korrekte Versionsnummer angezeigt.

  • Die Verwendung nicht unterstützter Datenbanken mit dem vSphere Replication-Verwaltungsserver ist möglich

    Sie können den vSphere Replication-Verwaltungsserver (VRM-Server) zur Verwendung mit Datenbanken konfigurieren, die nicht unterstützt werden, und die VRM-Server-Konfiguration verläuft erfolgreich ohne Warnungen zur Datenbankunterstützung. Allerdings kann die Verwendung einer nicht unterstützten Datenbank zu unvorhersehbarem Verhalten führen. Die folgenden Datenbanken wurden vollständig getestet und werden zur Verwendung mit dem VRM-Server unterstützt:

    • SQL Server 2005 SP4 64-Bit
    • SQL Server 2008 R2 SP1 64-Bit
    • SQL Server 2008 R2 64-Bit

  • Einige SRAs behandeln beim Failover bestimmte Zeitzonen nicht ordnungsgemäß

    Test- und echte Failover werden mit folgender Fehlermeldung angehalten: Das Erstellen der Snapshots der Replikgeräte ist für die Gruppe 'Schutzgruppe-999' unter Verwendung des Array-Paars 'Array-Paar-999' fehlgeschlagen: Vmacore::SystemException "Der Parameter ist falsch. " (87). Dieser Fehler beruht auf einer fehlerhaften Handhabung der Zeitzone, die vom Speicher-Array an den SRA zurückgegeben wird. Dieses Problem tritt bei allen Zeitangaben vor dem 1. Januar 1970 auf. Details und eine Umgehung finden Sie unter KB 2018597.

  • Beim Upgrade von SRM 4.1.2 auf SRM 5.0.3 schlägt der Befehl srm-migration importConfig aufgrund sich ändernder Datenspeicherobjekt-IDs fehl

    Der Upgrade-Vorgang für SRM 5.0.3 wird ohne Fehler durchgeführt, vCenter Server startet neu und die Hosts, Gäste und Speicher werden alle in demselben Zustand online geschaltet, als ob der vCenter Server-Dienst angehalten worden wäre. Allerdings schlagen während der SRM-Migration die Importvorgänge der Schutzgruppe mit folgendem Fehler fehl:

    Der VM-Schutz für alle VMs in der Gruppe ( Gruppe) wird wegen eines Fehlers übersprungen: Ein oder mehrere Datenspeicher werden entweder bereits in einer anderen Gruppe geschützt oder wurden aktuell nicht repliziert.

    Die in der SRM-Datei exportConfig.xml aufgelisteten Datenspeicherobjekt-IDs unterscheiden sich von denselben Datenspeicherobjekt-IDs, die im MOB-Browser angezeigt werden. Dieses Problem ist mit dem unter KB 2007404 beschriebenen Problem verwandt.

    Problemumgehung: Bearbeiten Sie die Datei exportConfig.xml, um die im MOB-Browser angezeigten Datenspeicherobjekt-IDs zu verwenden, und führen Sie den Befehl srm-migration importConfig erneut aus.

  • Ereignisse werden auf koreanischen Betriebssystemen nicht ordnungsgemäß angezeigt

    Wenn der vSphere-Client gestartet wird, ermittelt er das Gebietsschema, auf dem er ausgeführt wird, und wählt die anzuzeigenden Meldungen gemäß des Gebietsschemas aus. Wenn der vSphere-Client auf einem koreanischen Betriebssystem installiert ist, fordert der Client Meldungen aus dem Ordner koder vCenter Server-Installation an, weil vCenter Server und der vSphere-Client für die koreanische Sprache lokalisiert sind. vCenter Server und der vSphere-Client sind für die koreanische Sprache lokalisiert, SRM aber nicht. Daher werden XXX- statt SRM-Servermeldungen angezeigt. Um dieses Problem zu beheben, erstellen Sie eine Kopie des Ordners en, der sich im folgenden Verzeichnis befindet: C:\Programme\VMware\Infrastructure\VirtualCenter Server\extensions\com.vmware.vcDr\locale\. Benennen Sie den Ordner von enin koum und starten Sie die vCenter Server- und SRM-Dienste neu.

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

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

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

    Problemumgehung:  Wenn die primäre Site nicht mehr verfügbar ist, wenden Sie sich an den VMware-Support, um Anweisungen für das manuelle Aktualisieren der VRMS-Datenbank mit der neuen ID des verwalteten Objekts des Datenspeichers zu erhalten.

    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.

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

    Wenn Sie nach einer Wiederherstellung einen 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.

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

  • SRM-Alarm beim Start und zu willkürlichen Zeitpunkten.

    Aufgrund eines Problems in vCenter Server kann SRM Server unerwartet mit dem Fehler panic 'Default' opID=7b0e972e] Duplicate key 'key-vim.host.ScsiDisk-020002000050002ac0000f0c70565620202020' in linkable vim.host.ScsiDisk referenced by field scsiLun (wsdl name scsiLun) beendet werden. Dies wird von einem unter http://kb.vmware.com/kb/2033163 beschriebenen vCenter Server-Fehler verursacht.

    Problemumgehung: Entfernen Sie die Hosts aus der vCenter Server-Bestandsliste und fügen Sie sie dann erneut hinzu.

  • Die erste Anmeldung bei der SRM-Benutzeroberfläche schlägt nach der Installation unter Windows Server 2012 fehl.

    Wenn Sie SRM Server unter Windows Server 2012 installieren, schlägt die erste Anmeldung bei der SRM-Schnittstelle mit Fehlermeldungen fehl, die angeben, dass die Antwort des Remoteservers zu lange dauert. Dieses Problem tritt nur bei der ersten Anmeldung bei SRM nach der Installation unter Windows Server 2012 auf.

    Problemumgehung: Schließen und öffnen Sie vSphere Client erneut und melden Sie sich dann erneut bei SRM an.