Felsöka fel vid redundansväxling av virtuell VMware-dator eller fysisk dator till Azure

Du kan få något av följande fel när du redundansväxlar en virtuell dator till Azure. Om du vill felsöka använder du de beskrivna stegen för varje felvillkor.

Det gick inte att redundansväxla. Felkod: 28031

Site Recovery kunde inte skapa en red misslyckade virtuella datorer i Azure. Det kan inträffa på grund av någon av följande orsaker:

  • Det finns inte tillräckligt med kvot för att skapa den virtuella datorn: Du kan kontrollera den tillgängliga kvoten genom att gå till Prenumeration –> Användning + kvoter. Du kan öppna en ny supportbegäran för att öka kvoten.

  • Du försöker redundansväxlar virtuella datorer av olika storlek i samma tillgänglighetsuppsättning. Se till att du väljer samma storleksfamilj för alla virtuella datorer i samma tillgänglighetsuppsättning. Ändra storlek genom att gå till Beräkningsinställningar för den virtuella datorn och sedan försöka redundans igen.

  • Det finns en princip för prenumerationen som förhindrar att en virtuell dator skapas. Ändra principen så att du kan skapa en virtuell dator och försök sedan redundans igen.

Det gick inte att redundansväxla. Felkod: 28092

Site Recovery kunde inte skapa ett nätverksgränssnitt för den redundansväxlade virtuella datorn. Kontrollera att du har tillräcklig kvot för att skapa nätverksgränssnitt i prenumerationen. Du kan kontrollera den tillgängliga kvoten genom att gå till Prenumeration –> Användning + kvoter. Du kan öppna en ny supportbegäran för att öka kvoten. Om du har en tillräcklig kvot kan det vara ett tillfälligt problem. Försök igen. Om problemet kvarstår även efter återförsök lämnar du en kommentar i slutet av det här dokumentet.

Det gick inte att redundansväxla. Felkod: 70038

Site Recovery kunde inte skapa en red misslyckade klassiska virtuella datorer i Azure. Det kan inträffa eftersom:

  • En av resurserna, till exempel ett virtuellt nätverk som krävs för att den virtuella datorn ska skapas, finns inte. Skapa det virtuella nätverket enligt nätverksinställningarna för den virtuella datorn eller ändra inställningen till ett virtuellt nätverk som redan finns och försök sedan utföra redundansväxlingen igen.

Redundans misslyckades med fel-ID 170010

Site Recovery kunde inte skapa en red misslyckade virtuella datorer i Azure. Det kan inträffa eftersom en intern hydreringsaktivitet misslyckades för den lokala virtuella datorn.

För att få igång en dator i Azure kräver Azure-miljön att vissa drivrutiner är i starttillstånd och att tjänster som DHCP är i autostarttillstånd. Vid tidpunkten för redundansväxlingen konverteras därför starttypen för atapi-, intelide-, storflt-, vmbus- och storvsc-drivrutiner till startstart. Den konverterar också starttypen för några tjänster som DHCP till automatisk start. Den här aktiviteten kan misslyckas på grund av miljöspecifika problem.

Om du vill ändra starttypen för drivrutiner för Windows gästoperativsystem manuellt följer du stegen nedan:

  1. Ladda ned skriptet no-hydration och kör det på följande sätt. Det här skriptet kontrollerar om den virtuella datorn kräver hydrering.

    .\Script-no-hydration.ps1

    Det ger följande resultat om hydrering krävs:

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

    Om den virtuella datorn uppfyller kravet på hydrering utan hydrering ger skriptet resultatet "Det här systemet uppfyller kravet på hydrering utan hydrering". I det här fallet är alla drivrutiner och tjänster i det tillstånd som krävs av Azure och hydrering på den virtuella datorn krävs inte.

  2. Kör skriptet no-hydration-set på följande sätt om den virtuella datorn inte uppfyller kravet på hydrering.

    .\Script-no-hydration.ps1 -set

    Detta konverterar starttypen av drivrutiner och ger resultatet som nedan:

    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.
    

Det går inte att ansluta/RDP/SSH till den redundansväxlade virtuella datorn på grund av att Anslut-knappen är nedtonad på den virtuella datorn

Detaljerade felsökningsanvisningar om RDP-problem finns i vår dokumentation här.

Detaljerade felsökningsanvisningar om SSH-problem finns i vår dokumentation här.

Om knappen Anslut på den rededituella virtuella datorn i Azure är nedtonad och du inte är ansluten till Azure via en Express Route- eller VPN-anslutning från plats till plats,

  1. Gå till Virtuell datorNätverk> och klicka på namnet på det nätverksgränssnitt som krävs. Screenshot shows the Networking page for a virtual machine with the network interface name selected.
  2. Gå till Ip-konfigurationer och klicka sedan på namnfältet för den IP-konfiguration som krävs. Screenshot shows the I P configurations page for the network interface with the I P configuration name selected.
  3. Om du vill aktivera offentlig IP-adress klickar du på Aktivera. Enable IP
  4. Klicka på Konfigurera nödvändigainställningarSkapa> ny. Create new
  5. Ange namnet på den offentliga adressen, välj standardalternativen för SKU och tilldelning och klicka sedan på OK.
  6. Klicka på Spara för att spara ändringarna.
  7. Stäng panelerna och gå till avsnittet Översikt för den virtuella datorn för att ansluta/RDP.

Det går inte att ansluta/RDP/SSH – knappen VM Anslut tillgänglig

Om knappen Anslut på den redigerbara virtuella datorn i Azure är tillgänglig (inte nedtonad) kontrollerar du Startdiagnostik på den virtuella datorn och söker efter fel som anges i den här artikeln.

  1. Om den virtuella datorn inte har startats kan du försöka växla över till en äldre återställningspunkt.

  2. Om programmet på den virtuella datorn inte är igång kan du prova att växla över till en appkonsekvent återställningspunkt.

  3. Om den virtuella datorn är domänansluten kontrollerar du att domänkontrollanten fungerar korrekt. Du kan göra detta genom att följa de angivna stegen nedan:

    a. Skapa en ny virtuell dator i samma nätverk.

    b. Se till att den kan ansluta till samma domän där den virtuella datorn med fel förväntas komma upp.

    c. Om domänkontrollanten inte fungerar korrekt kan du försöka logga in på den redundansväxlat virtuella datorn med ett lokalt administratörskonto.

  4. Om du använder en anpassad DNS-server kontrollerar du att den kan nås. Du kan göra detta genom att följa de angivna stegen nedan:

    a. Skapa en ny virtuell dator i samma nätverk och

    b. Kontrollera om den virtuella datorn kan utföra namnmatchning med hjälp av den anpassade DNS-servern

Anteckning

Om du aktiverar andra inställningar än Startdiagnostik måste Azure VM-agenten installeras på den virtuella datorn före redundansväxlingen

Det går inte att öppna seriekonsolen efter redundansväxling av en UEFI-baserad dator till Azure

Om du kan ansluta till datorn med RDP men inte kan öppna seriekonsolen följer du stegen nedan:

  • Om datorns operativsystem är Red Hat eller Oracle Linux 7.*/8.0 kör du följande kommando på den virtuella Azure-datorn för redundans med rotbehörigheter. Starta om den virtuella datorn efter kommandot .

    grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
    
  • Om datorns operativsystem är CentOS 7.*kör du följande kommando på den virtuella Azure-datorn med rotbehörigheter. Starta om den virtuella datorn efter kommandot .

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

Oväntat avstängningsmeddelande (händelse-ID 6008)

När du startar en Windows virtuell dator efter redundansväxling, om du får ett oväntat avstängningsmeddelande på den återställda virtuella datorn, indikerar det att ett tillstånd för avstängning av virtuell dator inte har registrerats i återställningspunkten som används för redundans. Detta inträffar när du återställer till en punkt då den virtuella datorn inte hade stängts av helt.

Detta är normalt inte en orsak till problem och kan vanligtvis ignoreras för oplanerade redundansväxlingar. Om redundansväxlingen planeras kontrollerar du att den virtuella datorn är korrekt avstängd före redundansväxlingen och att den ger tillräckligt med tid för att väntande replikeringsdata lokalt ska skickas till Azure. Använd sedan alternativet Senasteredundansskärmen så att väntande data i Azure bearbetas till en återställningspunkt, som sedan används för redundansväxling av virtuella datorer.

Det går inte att välja datalagringen

Det här problemet visas när du inte kan se datalagringen i Azure-portalen när du försöker återaktivera skyddet av den virtuella datorn som har genomgått en redundansväxling. Det beror på att huvudmålet inte identifieras som en virtuell dator under vCenters som lagts till i Azure Site Recovery.

Mer information om hur du återaktiverar skyddet för en virtuell dator finns i Återaktivera skydd och återställa datorer till en lokal plats efter redundansväxling till Azure.

Så här löser du problemet:

Skapa huvudmålet manuellt i vCenter som hanterar källdatorn. Datalagringen blir tillgängligt efter nästa vCenter-identifiering och uppdatering av infrastrukturresurser.

Anteckning

Identifieringen och uppdateringen av infrastrukturresurser kan ta upp till 30 minuter att slutföra.

Linux Master Target-registrering med CS misslyckas med TLS-fel 35

Azure Site Recovery Master Target-registreringen med konfigurationsservern misslyckas på grund av att den autentiserade proxyn är aktiverad på huvudmålet.

Det här felet anges av följande strängar i installationsloggen:

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. 

Så här löser du problemet:

  1. Öppna en kommandotolk på den virtuella datorn för konfigurationsservern och kontrollera proxyinställningarna med hjälp av följande kommandon:

    cat /etc/environment echo $http_proxy echo $https_proxy

  2. Om utdata från föregående kommandon visar att antingen inställningarna för http_proxy eller https_proxy har definierats använder du någon av följande metoder för att avblockera huvudmålkommunikationen med konfigurationsservern:

    • Ladda ned PsExec-verktyget.

    • Använd verktyget för att komma åt systemanvändarkontexten och avgöra om proxyadressen har konfigurerats.

    • Om proxyn har konfigurerats öppnar du IE i en systemanvändarkontext med psexec-verktyget.

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

    • För att säkerställa att huvudmålservern kan kommunicera med konfigurationsservern:

      • Ändra proxyinställningarna i Internet Explorer för att kringgå HUVUDmålserverns IP-adress via proxyn.
        Eller
      • Inaktivera proxyn på huvudmålservern.

Nästa steg

Om du behöver mer hjälp kan du publicera frågan på microsofts& QA-frågesida för Site Recovery eller lämna en kommentar i slutet av det här dokumentet. Vi har ett aktivt samhälle som ska kunna hjälpa dig.