Beheben von Fehlern beim Ausführen eines Failovers einer VMware-VM oder eines physischen Computers nach Azure

Bei einem Failover eines virtuellen Computers nach Azure tritt eventuell einer der folgenden Fehler auf. Gehen Sie für die Problembehandlung gemäß den für den jeweiligen Fehlerzustand beschriebenen Schritten vor.

Fehler beim Failover mit der Fehler-ID 28031

Site Recovery konnte einen virtuellen Computer, für den ein Failover ausgeführt wurde, nicht in Azure erstellen. Dies kann aus einem der folgenden Gründe auftreten:

  • Das verfügbare Kontingent reicht nicht zum Erstellen des virtuellen Computers: Sie können das verfügbare Kontingent unter „Abonnement“ > „Nutzung + Kontingente“ prüfen. Sie können eine neue Supportanfrage eröffnen, um das Kontingent zu erhöhen.

  • Sie versuchen, ein Failover für virtuelle Computer unterschiedlicher Größensätze in derselben Verfügbarkeitsgruppe durchzuführen. Verwenden Sie unbedingt dieselben Größen Familien für alle virtuellen Computer in derselben Verfügbarkeitsgruppe. Sie können die Größe ändern, indem Sie zu den Einstellungen Compute des virtuellen Computers navigieren. Wiederholen Sie das Failover anschließend.

  • Eine Richtlinie für das Abonnement verhindert die Erstellung eines virtuellen Computers. Ändern Sie die Richtlinie, um das Erstellen eines virtuellen Computers zuzulassen, und wiederholen dann das Failover.

Fehler beim Failover mit der Fehler-ID 28092

Site Recovery konnte für den virtuellen Computer, für den ein Failover ausgeführt wurde, keine Netzwerkschnittstelle erstellen. Stellen Sie sicher, dass Sie in Ihrem Abonnement über ein ausreichendes Kontingent zum Erstellen von Netzwerkschnittstellen verfügen. Sie können das verfügbare Kontingent unter „Abonnement“ > „Nutzung + Kontingente“ prüfen. Sie können eine neue Supportanfrage eröffnen, um das Kontingent zu erhöhen. Wenn Sie über ein ausreichendes Kontingent verfügen, ist dies möglicherweise nur ein vorübergehendes Problem. Wiederholen Sie den Vorgang. Wenn das Problem auch nach Wiederholungen weiter besteht, hinterlassen Sie am Ende dieses Dokuments einen Kommentar.

Fehler beim Failover mit der Fehler-ID 70038

Site Recovery konnte einen klassischen virtuellen Computer, für den ein Failover ausgeführt wurde, nicht in Azure erstellen. Dies kann mehrere Ursachen haben:

  • Eine der Ressourcen – z.B. ein virtuelles Netzwerk, das für die Erstellung des virtuellen Computers erforderlich ist – ist nicht vorhanden. Erstellen Sie das virtuelle Netzwerk wie in den Netzwerk-Einstellungen des virtuellen Computers angegeben oder ändern Sie die Einstellung in ein virtuelles Netzwerk, das bereits vorhanden ist. Wiederholen Sie dann das Failover.

Fehler beim Failover mit der Fehler-ID 170010

Site Recovery konnte einen virtuellen Computer, für den ein Failover ausgeführt wurde, nicht in Azure erstellen. Dies kann passieren, wenn bei einer internen Hydration für den lokalen virtuellen Computer ein Fehler auftritt.

Um einen Computer in Azure aufzurufen, erfordert die Azure-Umgebung, dass sich einige der Treiber im Boot-Startzustand befinden und Dienste wie DHCP im Autostartzustand sind. Durch die Hydration zum Zeitpunkt des Failover wird der Startuptyp von atapi-, intelide-, storflt-, vmbus- und storvsc-Treibern in Bootstart umgewandelt. Außerdem wird der Starttyp einiger Dienste wie DHCP in Autostart konvertiert. Aufgrund umgebungsspezifischer Probleme können bei dieser Aktivität Fehler auftreten.

Um den Starttyp der Treiber für das Windows-Gastbetriebssystem manuell zu ändern, führen Sie die folgenden Schritte aus:

  1. Laden Sie das „no-hydration“- Skript herunter, und führen Sie es folgendermaßen aus: Dieses Skript überprüft, ob für die VM eine Hydration erforderlich ist.

    .\Script-no-hydration.ps1

    Es wird folgendes Ergebnis ausgegeben, wenn eine Hydration erforderlich ist:

    REGISTRY::HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\storvsc           start =  3 expected value =  0
    
    This system doesn't meet no-hydration requirement.
    

    Wenn für die VM keine Hydration erforderlich ist, gibt das Skript folgendes Ergebnis aus: „Für dieses System ist keine Hydration erforderlich“. In diesem Fall befinden sich alle Treiber und Dienste im von Azure geforderten Zustand und eine Hydration auf der VM ist nicht erforderlich.

  2. Führen Sie das „no-hydration-set“-Skript wie folgt aus, wenn die VM die Anforderung nicht erfüllt und eine Hydration erforderlich ist.

    .\Script-no-hydration.ps1 -set

    Damit wird der Startuptyp der Treiber und konvertiert und das folgende Ergebnis ausgegeben:

    REGISTRY::HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\storvsc           start =  3 expected value =  0
    
    Updating registry:  REGISTRY::HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\storvsc   start =  0
    
    This system is now no-hydration compatible.
    

Fehler beim Verbindungsaufbau über RDP/SSH mit dem virtuellen Computer (VM), für den ein Failover ausgeführt wurde, aufgrund ausgegrauter Schaltfläche „Verbinden“ auf der VM

Ausführliche Anweisungen zur Behandlung von RDP-Problemen finden Sie in der Dokumentation hier.

Ausführliche Anweisungen zur Behandlung von SSH-Problemen finden Sie in der Dokumentation hier.

Wenn die Schaltfläche Verbinden auf dem fehlerhaften virtuellen Computer abgeblendet ist und Sie nicht über ExpressRoute oder Site-to-Site-VPN mit Azure verbunden sind, gehen Sie wie folgt vor:

  1. Navigieren Sie zu VM > Netzwerk, und klicken Sie auf den Namen der jeweiligen Netzwerkschnittstelle. Screenshot der Netzwerkseite für einen virtuellen Computer mit dem ausgewählten Namen der Netzwerkschnittstelle
  2. Navigieren Sie zu IP-Konfigurationen, und klicken Sie dann auf das Namensfeld der gewünschten IP-Konfiguration. Screenshot zeigt die Seite „IP-Konfigurationen“ für die Netzwerkschnittstelle mit dem ausgewählten Namen der IP-Konfiguration
  3. Um die öffentliche IP-Adresse zu aktivieren, klicken Sie auf Aktivieren. Aktivieren der IP-Adresse
  4. Klicken Sie auf Erforderliche Einstellungen konfigurieren > Neue erstellen. Neu erstellen
  5. Geben Sie den Namen der öffentliche Adresse ein, wählen Sie die Standardoptionen für SKU und Zuweisung, und klicken Sie dann auf OK.
  6. Um die Änderungen nun zu speichern, klicken Sie auf Speichern.
  7. Schließen Sie die Bereiche, und navigieren Sie zum Abschnitt Übersicht des virtuellen Computers, mit dem per RDP eine Verbindung hergestellt werden soll.

Verbindung nicht möglich/RDP/SSH – Schaltfläche zum Verbinden des virtuellen Computers verfügbar

Wenn die Schaltfläche Verbinden auf dem fehlerhaften virtuellen Computer in Azure verfügbar ist (nicht abgeblendet), überprüfen Sie Startdiagnose auf Ihrem virtuellen Computer, und suchen Sie nach den in diesem Artikel aufgeführten Fehlern.

  1. Falls der virtuelle Computer nicht gestartet wurde, führen Sie ein Failover auf einen früheren Wiederherstellungspunkt aus.

  2. Wird die Anwendung auf dem virtuellen Computer nicht gestartet, führen Sie ein Failover auf einen anwendungskonsistenten Wiederherstellungspunkt aus.

  3. Ist der virtuelle Computer Mitglied einer Domäne, stellen Sie sicher, dass der Domänencontroller ordnungsgemäß funktioniert. Dies kann durch Ausführen der unten angegebenen Schritte geschehen:

    a. Erstellen Sie einen neuen virtuellen Computer im selben Netzwerk.

    b. Stellen Sie sicher, dass dieser derselben Domäne beitreten kann, in der der fehlerhafte virtuelle Computer erwartet wird.

    c. Funktioniert der Domänencontroller nicht ordnungsgemäß, melden Sie sich bei dem virtuellen Computer, für den ein Failover ausgeführt wurde, mit einem lokalen Administratorkonto an.

  4. Vergewissern Sie sich bei Verwendung eines benutzerdefinierten DNS-Servers, dass dieser erreichbar ist. Dies kann durch Ausführen der unten angegebenen Schritte geschehen:

    a. Erstellen Sie einen neuen virtuellen Computer im selben Netzwerk.

    b. Überprüfen Sie, ob der virtuelle Computer Namen mit dem benutzerdefinierten DNS-Server auflösen kann.

Hinweis

Der Azure-VM-Agent muss vor dem Failover auf dem virtuellen Computer installiert werden, wenn Sie andere Einstellungen als die Startdiagnose aktivieren möchten.

Serielle Konsole kann nach einem Failover eines UEFI-basierten Computers in Azure nicht geöffnet werden

Wenn Sie eine Verbindung mit dem Computer über RDP herstellen, aber die serielle Konsole nicht öffnen können, führen Sie die folgenden Schritte aus:

  • Wenn das Betriebssystem des Computers Red Hat oder Oracle Linux 7.*/8.0 ist, führen Sie den folgenden Befehl auf der Azure-Failover-VM mit root-Berechtigungen aus. Starten Sie die VM nach dem Befehl neu.

    grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
    
  • Wenn das Betriebssystem des Computers CentOS  7.* ist, führen Sie den folgenden Befehl auf der Azure-Failover-VM mit root-Berechtigungen aus. Starten Sie die VM nach dem Befehl neu.

    grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg
    

Nachricht über unerwartetes Herunterfahren (Ereignis-ID 6008)

Wenn beim Starten eines virtuellen Windows-Computers nach dem Failover auf dem wiederhergestellten virtuellen Computer eine Nachricht über ein unerwartetes Herunterfahren ausgegeben wird, bedeutet dies, dass ein Status des Herunterfahrens des virtuellen Computers nicht in dem für das Failover verwendeten Wiederherstellungspunkt erfasst wurde. Dies geschieht, wenn Sie eine Wiederherstellung zu einem Zeitpunkt durchführen, zu dem der virtuelle Computer nicht vollständig heruntergefahren war.

Normalerweise ist das kein Anlass zur Sorge und kann in der Regel für ungeplante Failover ignoriert werden. Stellen Sie im Fall eines geplanten Failovers sicher, dass der virtuelle Computer vor dem Failover ordnungsgemäß heruntergefahren wird, und lassen Sie genügend Zeit, damit ausstehende lokale Daten zur Replikation an Azure gesendet werden können. Verwenden Sie dann die Option Neueste auf dem Bildschirm Failover, damit alle ausstehenden Daten in Azure in einem Wiederherstellungspunkt verarbeitet werden, der dann für VM-Failover verwendet wird.

Datenspeicher kann nicht ausgewählt werden

Dieses Problem wird angezeigt, falls der Datenspeicher im Azure-Portal nicht angezeigt werden kann, wenn Sie versuchen, den virtuellen Computer, für den ein Failover ausgeführt wurde, erneut zu schützen. Der Grund: Das Masterziel wird unter vCenter-Instanzen, die Azure Site Recovery hinzugefügt wurden, nicht als virtueller Computer erkannt.

Weitere Informationen zum erneuten Schützen eines virtuellen Computers finden Sie unter Erneutes Schützen und Ausführen eines Failbacks für Computer auf einen lokalen Standort nach einem Failover auf Azure.

So lösen Sie das Problem:

Erstellen Sie das Masterziel manuell in der vCenter-Instanz, die Ihren Quellcomputer verwaltet. Der Datenspeicher ist nach der nächsten vCenter-Ermittlung und Fabric-Aktualisierung verfügbar.

Hinweis

Ermittlung und Fabric-Aktualisierung können bis zu 30 Minuten dauern.

TLS-Fehler 35 bei der Linux-Masterzielregistrierung beim Konfigurationsserver

Die Azure Site Recovery-Masterzielregistrierung beim Konfigurationsserver ist nicht erfolgreich, da auf dem Masterziel der authentifizierte Proxy aktiviert ist.

Dieser Fehler wird durch folgende Zeichenfolgen im Installationsprotokoll angegeben:

RegisterHostStaticInfo encountered exception config/talwrapper.cpp(107)[post] CurlWrapper Post failed : server : 10.38.229.221, port : 443, phpUrl : request_handler.php, secure : true, ignoreCurlPartialError : false with error: [at curlwrapperlib/curlwrapper.cpp:processCurlResponse:231]   failed to post request: (35) - SSL connect error. 

So lösen Sie das Problem:

  1. Öffnen Sie auf dem virtuellen Konfigurationsservercomputer eine Eingabeaufforderung, und überprüfen Sie die Proxyeinstellungen mithilfe folgender Befehle:

    cat /etc/environment echo $http_proxy echo $https_proxy

  2. Sollte in der Ausgabe der vorherigen Befehle angegeben sein, dass die Einstellung „http_proxy“ oder „https_proxy“ definiert ist, verwenden Sie eine der folgenden Methoden, um die Blockierung der Masterzielkommunikation mit dem Konfigurationsserver zu beseitigen:

    • Laden Sie das PsExec-Tool herunter.

    • Verwenden Sie das Tool, um auf den Systembenutzerkontext zuzugreifen und zu ermitteln, ob die Proxyadresse konfiguriert ist.

    • Ist der Proxy konfiguriert, öffnen Sie Internet Explorer mithilfe des PsExec-Tools in einem Systembenutzerkontext.

      psexec -s -i "%programfiles%\Internet Explorer\iexplore.exe"

    • So stellen Sie sicher, dass der Masterzielserver mit dem Konfigurationsserver kommunizieren kann:

      • Ändern Sie die Proxyeinstellungen in Internet Explorer, um die IP-Adresse des Masterzielservers über den Proxy zu umgehen.
        oder
      • Deaktivieren Sie den Proxy auf dem Masterzielserver.

Nächste Schritte

Wenn Sie weitere Hilfe benötigen, veröffentlichen Sie Ihre Anfrage auf der Microsoft F&A-Seite für Site Recovery, oder hinterlassen einen Kommentar am Ende dieses Dokuments. Wir verfügen über eine aktive Community, die Sie unterstützen kann.