VMware vCenter Site Recovery Manager 5.1.0.1 | 20. Dezember 2012 | Build 941848
VMware vCenter Site Recovery Manager 5.1 (nur ISO) | 10. September 2012 | Build 820150

Letzte Aktualisierung: 9. Januar 2013

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

Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

Neuheiten in SRM 5.1.0.1

SRM 5.1.0.1 bietet die folgenden Verbesserungen:

  • Behebt kritische Probleme in SRM 5.1. Wenn Sie SRM 5.1 (Build 820150) installiert haben, müssen Sie ein Upgrade auf SRM 5.1.0.1 (Build 941848) durchführen.
  • Enthält vSphere Replication 5.1.0.1. Wenn Sie vSphere Replication 5.1 installiert haben, müssen Sie nach dem Upgrade von SRM auf Version 5.1.0.1 auch ein Upgrade von vSphere Replication auf vSphere Replication 5.1.0.1 durchführen.

Weitere Anweisungen zu Upgrades finden Sie unter Hinweise zu Installation und Upgrade.

Behobene Probleme in SRM 5.1.0.1

  • Das Installieren von SRM 5.1 oder das Upgrade auf SRM 5.1 unter Verwendung eines importierten Zertifikats schlägt fehl
    Wenn Sie versuchen, unter Verwendung eines importierten PKCS12-Zertifikats anstelle eines automatisch generierten Zertifikats eine Installation von oder ein Upgrade auf SRM 5.1 durchzuführen, wird das Installationsprogramm vollständig ausgeführt, schlägt aber dann mit dem Fehler Zertifikat konnte nicht installiert werden fehl. Weitere Informationen finden Sie unter KB 2036909. Dieses Problem wurde in SRM 5.1.0.1 behoben.
  • Das Bereinigen der Wiederherstellungspläne auf der Wiederherstellungs-Site durch den SRM-Server schlägt fehl
    Das Bereinigen durch den SRM-Server schlägt auf der Wiederherstellungs-Site wiederholt fehl, wenn es nichts zum Bereinigen gibt, beispielsweise wenn es keine LUNs gibt, für die ein Trennvorgang durchgeführt werden muss, oder wenn es keine Datenspeicher zum Unmounten gibt. Dieses Problem tritt auf, wenn für den Befehl zum Starten der Testwiederherstellung vom SRM-Server an den SRA eine Erfolgsmeldung mit mindestens einer LUN erfolgt, aber keine LUNs gefunden werden, wenn die ESXi-Hosts auf der Wiederherstellungs-Site eine erneute Prüfung ausführen. Dieses Problem wurde in SRM 5.1.0.1 behoben.

Neuheiten in SRM 5.1

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

  • SRM 5.1 unterstützt das erneute Schützen und Failback mit vSphere Replication. In vorherigen Versionen war das Ausführen des erneuten Schützens und des Failbacks nur bei Array-basierten Schutzgruppen möglich. Bei SRM 5.1 können Sie vSphere Replication-Schutzgruppen erneut schützen und für sie ein Failback durchführen.
  • Der SRM-Server in SRM 5.1 ist jetzt eine vollständige 64-Bit-Anwendung.
  • Verbesserte Handhabung von Datenspeichern, wenn keine Pfade verfügbar ("All Paths Down", APD) sind. Wenn SRM erkennt, dass sich ein Datenspeicher an der Schutz-Site im Status "Keine Pfade verfügbar" befindet und verhindert, dass eine virtuelle Maschine heruntergefahren wird, wartet SRM, bevor es erneut versucht, die virtuelle Maschine herunterzufahren. Der Status "Keine Pfade verfügbar" ist in der Regel vorübergehend. Also wartet SRM, bis ein Datenspeicher mit dem Status "Keine Pfade verfügbar" wieder online ist, um die geschützten virtuellen Maschinen auf diesem Datenspeicher ordnungsgemäß herunterzufahren.
  • Verbesserte Neusignierung von VFMS-Festplatten.

Lokalisierung

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

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

Kompatibilität

SRM-Kompatibilitätstabelle

Informationen über die aktuelle Interoperabilität und die Produktkompatibilitätstabelle finden Sie unter Kompatibilitätstabellen für VMware vCenter Site Recovery Manager 5.1.

Kompatible Speicher-Arrays und Speicherreplizierungsadapter

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

VMware VSA-Unterstützung

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

Hinweise zu Installation und Upgrade

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

Installieren von SRM 5.1.0.1

Um SRM 5.1.0.1 neu zu installieren, laden Sie das Installationsprogramm VMware-srm-5.1.0-941848.exe herunter und führen Sie es aus. Weitere Informationen hierzu finden Sie unter Installieren von SRM im Handbuch Installation und Konfiguration von Site Recovery Manager.

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

Um ein Upgrade einer vorhandenen SRM 5.0.x-Installation auf SRM 5.1.0.1 durchzuführen, laden Sie das Installationsprogramm VMware-srm-5.1.0-941848.exe herunter und führen Sie es aus. Weitere Informationen hierzu finden Sie unter Durchführen eines Upgrades von SRM im Handbuch Installation und Konfiguration von Site Recovery Manager.

Upgrade einer vorhandenen SRM 5.1-Installation auf SRM 5.1.0.1

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

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

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

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

Wenn Sie vSphere Replication 5.1 installiert haben, müssen Sie auch ein Upgrade von vSphere Replication auf vSphere Replication 5.1.0.1 durchführen. Weitere Informationen hierzu finden Sie unter Durchführen eines Upgrades von vSphere Replication im Handbuch Installation und Konfiguration von Site Recovery Manager.

Grenzwerte für den Betrieb von SRM und vSphere Replication

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

SRM SDKs

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

Open Source-Komponenten

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

Probleme und Einschränkungen

  • Das Installieren oder das Upgrade auf SRM 5.1 unter Verwendung eines importierten Zertifikats schlägt fehl
    Wenn Sie versuchen, unter Verwendung eines importierten PKCS 12-Zertifikats anstelle eines automatisch generierten Zertifikats eine Installation von oder ein Upgrade auf SRM 5.1 durchzuführen, wird das Installationsprogramm vollständig ausgeführt, schlägt aber dann mit dem Fehler Zertifikat konnte nicht installiert werden fehl. Weitere Informationen finden Sie unter KB 1009801. Dieses Problem wurde in der Version SRM 5.1.0.1 behoben. Um ein importiertes PKCS12-Zertifikat zu verwenden, führen Sie ein Upgrade auf SRM 5.1.0.1 durch.

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

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

  • Lizenzanzahl bei der SRM-Konvertierung von pro CPU in pro virtuelle Maschine ist falsch
    Einige Kunden, die SRM 1.x und SRM 4.0 erworben haben, verwenden möglicherweise immer noch pro CPU zugeteilte Lizenzen. Es liegt ein bekanntes Problem beim Konvertieren dieser älteren pro-CPU-Lizenzen in pro-virtuelle-Maschine-Lizenzen für SRM 5.1 vor, bei dem die Formel zum Zählen der verwendeten CPU-Lizenzen zu großzügig ist. In diesem Szenario ist es möglich, dass bei der Konvertierung fälschlicherweise zu viele pro-virtuelle-Maschinen-Lizenzen für SRM 5.1 zugeteilt werden. Dieses Verhalten ist falsch und wird im Rahmen eines Patches für SRM behoben. Überwachen Sie Ihren Lizenzkonvertierungszähler genau, um sicherzustellen, dass Sie den Vertragsbedingungen Ihrer Lizenzvereinbarung entsprechen und die Anzahl der geschützten VMs nicht überschreiten, für die Sie lizenziert sind.

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

  • SRM 5.1 unterstützt 2 Microsoft Cluster Server-Knoten (MSCS)
    vSphere 5.1 unterstützt bis zu 5 MSCS-Knoten. SRM 5.1 unterstützt 2 MSCS-Knoten.

Behobene Probleme in SRM 5.1

In dieser Version wurden die folgenden Probleme bei SRM 5.0 behoben.

  • Das Koppeln oder das Entkoppeln von vSphere Replication-Appliances schlägt mit der Ausnahme "LockingFailedException" fehl

    In seltenen Fällen schlägt beim Koppeln oder Entkoppeln zwischen vSphere Replication-Appliance-Servern der Vorgang mit folgender Fehlermeldung fehl, wenn der vSphere-Dienst gleichzeitig gestoppt wird:

    LockingFailedException: Fehlgeschlagenes Schreibschutzobjekt: com.vmware.hms.db.entities.HmsLocalServerEntity: VRM Server GUID

    Dies wurde behoben.

  • Gültige Zertifikate führen zu Warnungen

    Bei vSphere Replication-Appliances schlägt die Koppelung wegen Problemen mit Zertifikaten fehl, wenn die folgenden Voraussetzungen beide zutreffen:

     

    • Das Zertifikat des Servers enthält einen Wert für den Hostnamen, der nicht mit der Adresse der vSphere Replication-Appliance übereinstimmt.
      Der Wert für den Hostnamen enthält möglicherweise einen Objektnamen oder alternative Objektnamen. Die vSphere Replication-Appliance-Adresse wird bei der Anwendungskonfiguration in der Virtual Appliance Management Infrastructure (VAMI) angegeben.
    • Der Peer-vSphere Replication-Appliance-Server verfügt über eine gültige Vertrauenskette zu einer Zertifizierungsstelle (CA) für das Zertifikat.
      Dies geschieht, wenn das Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle, wie z. B. Verisign oder Go Daddy, oder von einer unbekannten Zertifizierungsstelle ausgegeben wurde, deren Zertifikat zur Datei hms-truststore.jksdes Peer-vSphere Replication-Appliance-Servers hinzugefügt wurde, wodurch die Vertrauenswürdigkeit hergestellt wurde.

     

    Dies wurde behoben.

     

  • Das Installieren mehrerer vSphere-Client-SRM-Plug-Ins schafft Probleme

    Nur eine Version des vSphere-Client-SRM-Plug-Ins sollte zu einem gegebenen Zeitpunkt installiert sein. Benutzer werden nicht daran gehindert, das Client-Plug-In für Version 4.0.x oder 4.1.0 über das Plug-In für SRM 5.0 zu installieren. Dies wurde behoben.

  • Beim erneuten Schützen können Benutzer möglicherweise unzulässige Aufgaben durchführen

    Wenn Benutzer einen Vorgang zum erneuten Schützen durchführen, können sie möglicherweise Aufgaben durchführen, für deren Durchführung sie nicht über die entsprechenden Rechte verfügen. Zu den Aufgaben, die Benutzer möglicherweise durchführen können, obwohl sie nicht über die entsprechenden Rechte verfügen, gehört das Erstellen von virtuellen Maschinen auf der Zielsite für das erneute Schützen oder das Schützen neuer Geräte auf der Quellsite für das erneute Schützen. Dies kann eintreten, wenn der Vorgang des erneuten Schützens initiiert wird, nachdem andere Benutzer virtuelle Maschinen auf dem alten Produktionsstandort gelöscht oder jene virtuellen Maschinen geändert haben, die beim Durchführen eines Failovers als Ziele für virtuelle Maschinen dienten. Dies wurde behoben.

  • Die Benutzerschnittstelle ändert sich unerwartet während einer geplanten Migration

    Während einer geplanten Migration werden virtuelle Maschinen deaktiviert und mit der Wiederherstellungs-Site synchronisiert. Während dieses Vorgangs werden Schutzgruppen und deren virtuellen Maschinen vorübergehend mit dem Status Teilweise wiederhergestellt angezeigt. Der vSphere-Client aktiviert die passenden Schaltflächen für diese Zustände, wie z. B. Schutzgruppe bearbeiten und Schutzgruppe entfernen, aber die von diesen Schaltflächen ausgelösten Vorgänge schlagen fehl. Diese unterschiedlichen Zustände und die Schaltflächenverfügbarkeit können für Benutzer verwirrend sein. Dies wurde behoben.

  • Wiederherstellungsverläufe können nach einem Upgrade auf SRM 5.0 verloren gehen

    Während eines Server-Migrations-Upgrades schlägt das Installationsprogramm den Standard-Site-Namen anstelle des momentan verwendeten Site-Namens vor. Wenn Sie den Standard-Site-Namen nicht durch den aktuellen Site-Namen ersetzen, gehen die Wiederherstellungsverläufe möglicherweise verloren. Dies wurde behoben.

  • Lizenzhinweise ohne informativen Inhalt bei der Verwendung von Standard-Site-Namen

    SRM-Lizenzhinweise werden in vCenter anhand des SRM-Site-Namens bezeichnet. Wenn der Standard-Site-Name verwendet wird und mehrere SRM-Server in derselben vCenter-Gruppe registriert sind, sorgt die Standardbenennung der SRM-Server dafür, dass die Lizenzhinweise ununterscheidbar sind. Dies wurde behoben.

  • Installation von SRM auf Maschinen mit Nicht-ASCII-Zeichen führt zu Zugriffsproblemen

    Wenn SRM auf einer Maschine installiert wird, deren Name Nicht-ASCII-Zeichen enthält, können Probleme beim Benutzerzugriff auftreten. Da der Maschinenname zur Generierung von URLs verwendet wird, sind die URLs, die Nicht-ASCII-Zeichen enthalten, möglicherweise nicht gültig. Dies wurde behoben.

  • Nicht-ASCII-DNS-Suffixe werden nach dem Anpassen von Windows XP und Windows 2003 nicht ordnungsgemäß festgelegt

    Wenn Sie ein Nicht-ASCII-DNS-Suffix auf die Registerkarte "DNS" des Abschnitts "IP-Einstellungen" des Dialogfelds "Eigenschaften für die Wiederherstellung der virtuellen Maschine" eingeben, um Windows XP oder Windows 2003 anzupassen, wird die Anpassung als erfolgreich gemeldet, aber das Nicht-ASCII-DNS-Suffix wird nicht ordnungsgemäß festgelegt. Dies wurde behoben.

  • Benutzerdefinierte Wiederherstellungsschritte mit der Ausgabe von Nicht-ASCII-Zeichen führen zu einem Absturz des SRM-Servers

    Erstellen Sie keine benutzerdefinierten Wiederherstellungsschritte, die eine Nicht-ASCII-Ausgabe erzeugen. Wenn Sie solche Schritte zu einem Plan hinzufügen und anschließend einen Test oder eine Wiederherstellung ausführen, stürzt der SRM-Server ab. Wenn ein Plan verwendet wird, der einen Schritt enthält, der Nicht-ASCII-Ausgaben erzeugt, wechselt der Plan in einen Zustand, bei dem er nicht geändert oder gelöscht werden kann. Dies wurde behoben.

  • Konfigurationsbenutzeroberfläche des Wiederherstellungsplans zeigt ungültige Netzwerkoptionen an

    Bei der Konfiguration eines Wiederherstellungsplans müssen Netzwerke für die Zuordnung mit virtuellen Maschinen ausgewählt sein. Die Benutzeroberfläche des Wiederherstellungsplans zeigt DVS-Uplink-Portgruppen als mögliche Auswahl an, auch wenn dies keine gültigen Optionen sind. Dies wurde behoben.

  • Status der virtuellen Maschine wird nach der Trennung der Verbindung zu vSphere Replication-Appliances nicht aktualisiert

    vSphere Replication-Appliances tauschen zwischen Sites Informationen über die Replizierung virtueller Maschinen aus. Wenn die Verbindung mit der vSphere Replication-Appliance durch die Option Verbindung mit vSphere Replication-Appliance unterbrechen getrennt wird, wird der Informationsaustausch über replizierte virtuelle Maschinen nicht automatisch neu eingerichtet, wenn Sie die Verbindung mit der vSphere Replication-Appliance neu konfigurieren. Dies kann zu unvollständigen Informationen über die Replizierung virtueller Maschinen führen, einschließlich der Informationen, welche virtuellen Maschinen zum Hinzufügen zu Schutzgruppen verfügbar sind. Dies wurde behoben.

  • Im vSphere-Client angezeigte Informationen sind möglicherweise veraltet

    Während des Änderns von SRM-Daten, z. B. von Inhalten von Wiederherstellungsplänen, werden die angezeigten Informationen möglicherweise nicht aktualisiert, sobald die SRM-Informationen geändert werden. So werden zum Beispiel nach dem Hinzufügen einer nicht kritischen virtuellen Maschine zum Anhalten eines Wiederherstellungsplans die Informationen über diese Änderung nicht automatisch angezeigt. Dies wurde behoben.

  • Ungültige Zertifikate werden während der Authentifizierung abgelehnt

    SRM unterstützt die zertifikatsbasierte Authentifizierung. Falls ein SRM-Server über ein ungültiges Zertifikat verfügt, wenn der vSphere-Client das SRM-Plug-In verwendet, um eine Verbindung zum SRM-Server herzustellen, treten Fehler auf. Ungültige Zertifikate können auftreten, wenn ein Zertifikat in der Zertifikatskette abgelaufen oder noch nicht gültig ist. In einem solchen Fall wird die folgende Meldung angezeigt: Die SSL-Verbindung zum Remotehost wurde beendet. Das Remotehostzertifikat weist folgende Probleme auf: Ein Zertifikat in der Hostkette ist zeitlich nicht gültig.Dieses Problem wurde behoben.

  • Vorgänge schlagen möglicherweise fehl, wenn viele vSphere-Clients eine Verbindung zu SRM herstellen

    SRM verwendet einen großen Pool an Verbindungen mit fester Größe zum Kommunizieren mit vCenter Servern und dem SRM-Server am anderen Standort, um Aufgaben auszuführen. Die Anzahl an verfügbaren Verbindungen verringert sich, wenn sich die Anzahl an verbundenen vSphere-Clients erhöht. In vielen Fällen wirkt sich dies nicht negativ auf die Systemleistung aus, aber im Falle vieler gleichzeitiger Vorgänge, wie z. B. dem Schützen und Aufheben des Schutzes einer großen Anzahl an virtuellen Maschinen oder dem Ausführen und Testen vieler Wiederherstellungspläne, können Probleme auftreten. Bei Vorgängen kann es zu Zeitüberschreitungen führen oder sie schlagen aus verschiedenen Gründen fehl. Dies wurde behoben.

  • Versuche, Wiederherstellungspläne im gemischten Modus erneut zu schützen, führen zum Zustand "Erneuter Schutz unvollständig"

    Schutzgruppen können SAN- oder vSphere Replication-basiert sein und Wiederherstellungspläne können sich aus beiden Schutzgruppentypen zusammensetzen. Der erneute Schutz kann nicht auf einem Plan ausgeführt werden, der einen Mix aus SAN- und VR-basierten Schutzgruppen enthält. Der erneute Schutz stellt nicht sicher, dass die Schutzgruppen nicht nur SAN- oder nur VR-basiert sind. Wenn versucht wird, Schutzgruppen erneut zu schützen, die aus einem Mix aus Schutzgruppentypen zusammengesetzt sind, schlägt der Vorgang fehl und der Wiederherstellungsplan bleibt im Zustand "Erneuter Schutz unvollständig" zurück. Um dieses Problem zu vermeiden, erstellen Sie keine Wiederherstellungspläne, die verschiedene Schutztypen enthalten. Dies wurde behoben.

  • Vom Benutzer aktivierter Alarm wird niemals ausgelöst

    Benutzer können den Alarm Neu konfigurierte Schutzeinstellungen für VMaktivieren, aber dieser Alarm wird niemals ausgelöst. Das Problem liegt darin, dass Benutzer in dieser Version keine Schutzeinstellungen bearbeiten können. Um vom Benutzer initiierte Änderungen an Einstellungen virtueller Maschinen in SRM zu verfolgen, müssen Administratoren den Alarm Neu konfigurierte Einstellungen des Wiederherstellungsspeicherorts für VMaktivieren. Dies wurde behoben.

  • Versuche des Benutzers zum Konfigurieren von vSphere Replication schlagen fehl

    Benutzer mit Administratorrechten können vSphere Replication möglicherweise immer noch nicht konfigurieren. Die Ursache hierfür liegt oft darin, dass Benutzern nicht das Recht VRM-Datenspeicher-Mapper > Ansichterteilt wurde. Dies wurde behoben.

  • Das Synchronisieren von Speicher während einer Wiederherstellung führt zu Fehlern

    In seltenen Fällen tritt bei aktivierter Synchronisierung während der Ausführung des Schritts Speicher synchronisieren möglicherweise der folgende Fehler auf: VR-Synchronisierung für die VRM-Gruppe Gruppenname fehlgeschlagen. VRM-Server - generischer Fehler. Suchen Sie in der Dokumentation nach Informationen zur Fehlerbehebung. Die detaillierte Ausnahme ist: 'Fehler bei optimistischen Sperren'. Dieses Problem tritt eher auf, wenn bei der Ausführung eines Wiederherstellungsplans eine große Datenmenge übertragen wird, z. B. wenn es eine größere Anzahl an virtuellen Maschinen und eine größere Menge an zu synchronisierenden Daten gibt. Dies wurde behoben.

  • Das Herstellen einer Verbindung mit NFC schlägt fehl oder Kopierfehler bei der Wiederherstellung

    Bei einer Wiederherstellung können die folgenden Fehlermeldungen auftreten:

     

    • Es konnte keine Verbindung zum NFC-Dienst unter Hosthergestellt werden.
    • Kopieren der Datei Dateipfad nach Neuer_Dateipfad fehlgeschlagen: Fehlercode - Fehlermeldung.

     

    Dieses Problem tritt auf, wenn eine große Anzahl an gleichzeitigen Vorgängen durchgeführt wird. Das Problem tritt in der Regel unter folgenden Bedingungen auf:

     

    • Beim Wiederherstellen von 40 oder mehr virtuellen Maschinen, die mit vSphere Replication (VR) geschützt sind.
    • Beim Wiederherstellen von 10 oder mehr Datenspeichern auf einem ESX 3.5-Host.
    • Beim Ausführen einer großen Anzahl an Wiederherstellungsplänen, wenn die Wiederherstellungspläne virtuelle Maschinen beeinträchtigen, die über Festplatten mit Raw-Festplattenzuordnung (RDM) verfügen. Dieses Problem tritt in der Regel auf, wenn auf 4.x-Hosts mindestens 20 oder auf 5.0-Hosts mindestens 40 Wiederherstellungspläne ausgeführt werden.

     

    Dies wurde behoben.

  • Nach der Replizierung auswählbare virtuelle Maschinen sind nicht konfiguriert

    Wenn der Assistent zum Konfigurieren der Replizierung für mehrere virtuelle Maschinen verwendet wird, werden einige virtuelle Maschinen möglicherweise nicht erfolgreich konfiguriert. Obwohl deren Konfiguration fehlgeschlagen ist, werden die virtuellen Maschinen im Assistenten Schutzgruppe erstellen als Auswahlmöglichkeiten aufgelistet. Dies liegt daran, dass das Fehlschlagen der Konfiguration nicht kommuniziert wurde. Dies wurde behoben.

  • Netzwerkinformationsfelder enthalten keine gültigen Informationen, wenn IPv6 erforderlich ist

    Wenn die vSphere Replication-Appliance für die alleinige Verwendung von IPv6 konfiguriert ist, treten folgende Probleme auf:

     

    • Auf der Startseite der Virtual Appliance Management Infrastructure (VAMI) ist das vCenter Server-Adressfeld vorab mit einer literalen IPv4-Adresse gefüllt. Diese Adresse ist für reine IPv6-Appliances unbrauchbar. Um dieses Problem zu beheben, bearbeiten Sie das Feld und geben Sie einen gültigen DNS-Namen oder eine gültige literale IPv6-Adresse ein.
    • Das Feld "Site-Name" wird nicht vorab gefüllt. Dieses Feld ist in der Regel vorab gefüllt mit dem Namen der virtuellen Maschine der Appliance in der vCenter Server-Bestandsliste. Um dieses Problem zu beheben, geben Sie einen gültigen Site-Namen ein. Ein gültiger Site-Name unterscheidet sich von dem Site-Namen der Peer-Site.

    Dies wurde behoben.

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

  • Die geplante Migration führt möglicherweise zu einer Verlangsamung der ESX-Hosts

    Während der geplanten Migration instruiert SRM zuerst die ESX-Hosts, ein Unmounten der replizierten Datenspeicher durchzuführen und die LUNs zu trennen, die für ein Backing dieser Datenspeicher sorgen. Dann instruiert SRM die Speicher-Array-Software, die getrennten LUNs vor Schreibzugriffen zu schützen. Dieser Vorgang stellt sicher, dass bei Geräten auf ESX-Hosts kein Zustand des Typs "Keine Pfade verfügbar" (All Paths Down, APD) für die Datenspeicher und LUNs eintritt, die migriert werden. Das Migrieren einer virtuellen Maschine mit RDMs führt möglicherweise dazu, dass bei RDM LUNs ein APD-Zustand eintritt. Nachdem bei RDMs ein APD-Zustand eingetreten ist, versuchen ESX-Hosts weiterhin, eine neue Verbindung zu den verloren gegangenen RDM LUNs herzustellen. Da sich die Anzahl der nicht verfügbaren RDMs erhöht, erhöht sich entsprechend die Anzahl der Versuche des ESX-Hosts, eine neue Verbindung zu den verloren gegangenen RDMs herzustellen. Wenn dieser Prozess fortschreitet, antwortet der ESX-Host möglicherweise langsamer und vCenter Server kommt letztendlich zu dem Ergebnis, dass die Hosts nicht mehr reagieren. Dies tritt eher bei bestimmten Speicher-Arrays auf. Beispielsweise tritt dies eher auf, wenn ein SRA ein ISCSI-Ziel pro LUN unterstützt. Um diese Probleme zu beheben, starten Sie den ESX-Host neu. Dies wurde behoben.

Bekannte Probleme in SRM 5.1

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.

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

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

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

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

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

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

  • Abbrechen des Wiederherstellungsplans nicht abgeschlossen

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

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

     

  • Gültige Zertifikate führen zu Warnungen

    Beim Hochladen und Installieren von Zertifikaten auf die vSphere Replication-Appliance tritt der folgende Fehler auf:

    Das Zertifikat wurde mit Warnungen installiert. Remote-VRM-Systeme, bei denen die Option "Nur von einer vertrauenswürdigen Zertifizierungsstelle signiertes SSL-Zertifikat annehmen" aktiviert ist, können möglicherweise aus dem folgenden Grund keine Verbindung mit dieser Site herstellen: Das Zertifikat wurde nicht zur Verwendung mit dem angegebenen Hostnamen ausgegeben: VRM-Hostname

    Dieser Fehler kann ignoriert werden oder Sie können diesen Fehler vermeiden, indem Sie einen anderen unterstützten Browser als Internet Explorer verwenden.

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

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

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

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

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

     

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

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

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

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

  • Koppeln der Sites aufgrund unterschiedlicher Zertifikatsvertrauensmethoden fehlgeschlagen

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

  • 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 tritt auf, wenn ein gültiger Host als UNSUPPORTED (nicht unterstützt) gekennzeichnet wird, obwohl es sich bei dem Host um eine gültige Auswahl handelt. Während der vSphere Replication-Serverregistrierung wird das Ereignis Der Host ist für vSphere Replication konfiguriertauf dem Host nicht ausgelöst. Das Kennzeichnen von Hosts als "Nicht unterstützt" tritt bei der Registrierung der vSphere Replication-Server oder bei der Verbindung eines neuen Hosts mit der vCenter Server-Bestandsliste aufgrund eines Fehlers bei oder einer Unterbrechung der Kommunikation zwischen vSphere Replication-Appliances und vSphere Replication-Servern auf. Die Kommunikationsprobleme treten in der Regel auf, weil die Verbindung vorübergehend verloren geht oder die Serverdienste gestoppt werden.

    Um dieses Problem zu beheben und die Hosts zur Verwendung mit vSphere Replication zu aktivieren, müssen Sie die folgenden Schritte ausführen:

    1. Suchen Sie die vSphere Replication-Appliance-Datenbank an der Wiederherstellungs-Site.
    2. Entfernen Sie darin alle Datensätze aus der HostEntity-Tabelle mit Status 4 (UNSUPPORTED - Nicht unterstützt), die von der HbrHostEntity-Tabelle (vcMoId-Wert) nicht referenziert werden. Wenn es vorhandene Referenzen von der HbrHostEntity-Tabelle (den vcMoId-Wert) gibt, entfernen Sie den Datensatz nicht. Aktualisieren Sie stattdessen den Statuswert von 4 auf 1 (ACTIVE - Aktiv).
    3. Trennen Sie den Host von der vCenter Server-Bestandsliste und verbinden Sie ihn neu.
    4. Stellen Sie sicher, dass das Ereignis Der Host ist für vSphere Replication konfiguriertauf dem Host ausgelöst wird.

     

    Ein Beispiel für diese Art von Abfragen, die Sie möglicherweise zum Beheben dieses Problems in der Datenbank des vSphere Replication-Appliance-Servers verwenden, lautet wie folgt:

    1. Abfragen
      • So fragen Sie alle Hosts ab, die mit UNSUPPORTED gekennzeichnet und keinem vSphere Replication-Server zugewiesen sind:
        select * from HostEntity h where state=4 and not exists (select * from HbrHostEntity where h.vcMoId=HbrHostEntity.vcHost_vcMoId).
      • So fragen Sie alle Hosts ab, die mit UNSUPPORTED gekennzeichnet und einem vSphere Replication-Server zugewiesen sind: select * from HostEntity h where state=4 and exists (select * from HbrHostEntity where h.vcMoId=HbrHostEntity.vcHost_vcMoId).
    2. Löschen und Ändern
      • So löschen Sie UNSUPPORTED-Datensätze für Hosts, die keinem vSphere Replication-Server zugewiesen sind:
        delete from HostEntity where state=4 and not exists (select * from HbrHostEntity where vcMoId=HbrHostEntity.vcHost_vcMoId).
      • So ändern Sie den Status von mit UNSUPPORTED gekennzeichneten Hosts, die einem vSphere Replication-Server zugewiesen sind, auf ACTIVE:
        update HostEntity set state=1 where state=4 and exists (select * from HbrHostEntity where vcMoId=HbrHostEntity.vcHost_vcMoId).

     

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

  • Fehlfunktion bei vSphere Replication-Servern, die mit einer nicht spezifizierten Netzwerkkonfiguration bereitgestellt werden

    vSphere Replication-Server werden mithilfe des OVF-Bereitstellungsassistenten von einer OVF-Datei bereitgestellt. Der Bereitstellungsassistent enthält eine Seite zum Angeben der Netzwerkkonfiguration des vSphere Replication-Servers. Falls für die Netzwerkkonfiguration keine Netzwerkeinstellungen angegeben sind, wird die DHCP-Adressierung verwendet, die aber von vSphere Replication-Servern nicht unterstützt wird. Um dieses Problem zu vermeiden, geben Sie bei der Bereitstellung gültige Netzwerkeinstellungen für den vSphere Replication-Server an.

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

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

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

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

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

    Weitere Informationen finden Sie unter KB 1009801 .

  • SRM kann nach einem RDM-Fehler keine virtuellen Maschinen wiederherstellen.

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

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

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

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

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

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

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

    Umgehung:

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

     

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

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

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

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

  • 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 Aufgabe zum Schutz der virtuellen Maschine scheint bei 100 % zu verharren.

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

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

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

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

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

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

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

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

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

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

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

    Wenn Sie eine Replizierung für eine virtuelle Maschine im physischen Modus konfigurieren, erhalten Sie möglicherweise die folgende Fehlermeldung:

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

    Umgehung: Keine.

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

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

    Umgehung: Führen Sie die Wiederherstellung erneut durch.

  • Während Sie eine virtuelle Maschine erneut schützen, kann die folgende Fehlermeldung während des Schritts "Schutz für die umgekehrte Richtung konfigurieren" auftreten: Fehler - Der Vorgang wurde für die Schutzgruppe 'Schutzgruppenname' nur teilweise ausgeführt, da eine zur Gruppe gehörende geschützte VM den Vorgang nicht erfolgreich abschließen konnte. Die virtuelle Maschine 'VM-Name' wird nicht von VR repliziert.

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

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

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

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

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

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

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

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

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

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

  • SRM Version 5.0 kann mit einem SRM-Server Version 5.1, der einem Upgrade unterzogen wurde, während der Wiederherstellung kommunizieren.

    Wenn Sie ein Upgrade der Wiederherstellungs-Site von Version 5.0 auf Version 5.1 vornehmen und eine Notfallwiederherstellung auf der einem Upgrade unterzogenen Site versuchen, können SRM-Server der Version 5.0 auf der geschützten Site und der SRM-Server der Version 5.1 auf der Wiederherstellung-Site miteinander kommunizieren und Vorgänge auf der geschützten Site durchführen. Wenn Sie einen Vorgang für einen erneuten Schutz durchführen, bevor Sie ein Upgrade der geschützten Site vornehmen, läuft der Vorgang sehr lange, ohne dass ein Fortschritt eintritt.

    Bevor Sie eine Wiederherstellung einer Site nach einem Upgrade vornehmen, stoppen Sie alle SRM 5.0-Dienste, die noch auf der Remote-Site laufen. Sonst können SRM-Server mit inkompatiblen Versionen weiterhin miteinander kommunizieren.

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

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

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

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

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

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

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

    Umgehung: Führen Sie den fehlgeschlagenen Vorgang erneut aus.

  • Der wiederhergestellte VMFS-Datenträger mountet nicht und meldet folgenden Fehler: Der Datenspeicher konnte nicht wiederhergestellt werden.

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

    Umgehung: Führen Sie den Wiederherstellungsplan erneut aus.

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

    Wenn die vCenter Server-Bestandsliste einige hundert Hosts oder mehr enthält, benötigt die Aufgabe VR-Server registrieren mehr als eine Stunde für ihren Abschluss, da vSphere Replication die SSL-Fingerabdruckregistrierung jedes Hosts aktualisiert. Im Bereich Ereignisse von vCenter Server wird für jeden Host die Meldung Der Host ist für vSphere Replication konfiguriert angezeigt, wenn die vSphere Replication-Serverregistrierungsaufgabe fortschreitet.

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

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

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

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

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

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

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

    Umgehung: Führen Sie den fehlgeschlagenen Vorgang erneut aus.

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

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

    Umgehung: Führen Sie den Wiederherstellungsplan erneut aus. Wenn der Fehler weiter auftritt, konfigurieren Sie Wiederherstellungs-Site-Cluster-DRS auf den manuellen Modus und führen Sie den Wiederherstellungsplan erneut aus.

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

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

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

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

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

    Umgehung: Ändern Sie einige vSphere Replication-Parameter:

    1. Stoppen Sie den vSphere Replication-Managementserver: /etc/init.d/hms stop
    2. Bearbeiten Sie /opt/vmware/hms/conf/hms-configuration.xml und ändern Sie hms-db-max-connections von 99 auf 500.
    3. Bearbeiten Sie /var/lib/vrmsdb/postgresql.conf und ändern Sie max_connections von 100 auf 501.
    4. Starten Sie die eingebettete vPostgres-Datenbank neu: /etc/init.d/hms-vpostgres stop /etc/init.d/hms-vpostgres start
    5. Ändern Sie die hms-vlsi-server-Thread-Poolgröße: /opt/vmware/vpostgres/1.0/bin/psql -U vrmsdb vrmsdb update ConfigEntryEntity set configValue='250' where configKey = 'hms-vlsi-server-threadpool-size'
    6. Erhöhen Sie den Heap-Speicher für den vSphere Replication-Managementserverprozess: Bearbeiten Sie /etc/init.d/hms und fügen Sie -Xmx1536M in JAVA_TOOL_OPTIONS hinzu.
    7. Starten Sie den vSphere Replication-Managementserver: /etc/init.d/hms start
    8. Führen Sie den fehlgeschlagenen Vorgang erneut aus.

     

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

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

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

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

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

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

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

  • Der Test der Wiederherstellungsbereinigung kann fehlschlagen, wenn einer der Hosts die Verbindung mit einem Platzhalter-Datenspeicher verliert.

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

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

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

    Wenn Sie mehrere Wiederherstellungspläne gleichzeitig ausführen, kann der erneute Schutz mit folgender Fehlermeldung fehlschlagen: Fehler - Der Vorgang wurde für die Schutzgruppe 'Schutzgruppenname' nur teilweise ausgeführt, da eine zur Gruppe gehörende geschützte VM den Vorgang nicht erfolgreich abschließen konnte.

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

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

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

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

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

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

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

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

    Umgehung:

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

      Wenn Sie eine geplante Migration durchführen, schaltet SRM virtuelle Maschinen in der Produktionsumgebung nicht ab.
    2. Wenn die virtuellen Maschinen RDM-Geräte haben, kann SRM die Spur des RDM-Geräts verlieren und nicht wiederherstellen. Führen Sie eine erneute Prüfung aller HBAs durch und achten Sie darauf, dass alle betroffenen LUNs aus dem APD/PDL-Status zurückgekehrt sind.
    3. Prüfen Sie die vCenter Server-Bestandsliste und beantworten Sie die PDL-Frage, die die virtuelle Maschine blockiert.
    4. Wenn Sie die PDL-Frage beantworten, bevor die LUNs wieder online sind, erkennt der SRM-Server auf der geschützten Site fälschlicherweise, dass das RDM-Gerät nicht mehr an dieser virtuellen Maschine angehängt ist und entfernt das RDM-Gerät. Wenn Sie das nächste Mal eine Wiederherstellung ausführen, stellt SRM diese LUN nicht wieder her.
    5. Prüfen Sie alle HBAs erneut, um sicherzugehen, dass alle LUNs in der vCenter Server-Bestandsliste online sind, und schalten Sie alle betroffenen virtuellen Maschinen ein. vCenter Server verbindet die verlorenen RDMs mit geschützten virtuellen Maschinen.
    6. Prüfen Sie die Registerkarte Array-Manager in der SRM-Schnittstelle. Wenn alle geschützten Datenspeicher und RDM-Geräte nicht angezeigt werden, klicken Sie auf Aktualisieren, um die Geräte zu erkennen und die Datenspeichergruppen erneut zu berechnen.
    7. Achten Sie darauf, dass die Option Gruppeneinstellungen anzeigen alle geschützten Datenspeicher und RDM-Geräte anzeigt und der Schutzstatus der virtuellen Maschinen keine Fehler aufweist.
    8. Starten Sie eine geplante Migration, um alle geschützten LUNs, einschließlich der RDM-Geräte, wiederherzustellen.
  •  

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

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

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

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

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

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