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 redursväxlande virtuell dator 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 redväxade 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 redursväxlande virtuell dator i Azure. Det kan inträffa eftersom en intern hydreringsaktivitet misslyckades för den lokala virtuella datorn.
För att kunna öppna 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.
Följ stegen nedan om du vill ändra starttypen för drivrutiner för Windows-gästoperativsystem manuellt:
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.
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.
Redundansen misslyckades med ett fel som anger att replik-IP-adresser för nätverkskortet för den virtuella datorn är ogiltiga
Redundanstest eller redundansväxling kan misslyckas för en dator med felet "En eller flera replik-IP-adresser för den virtuella datorns nätverkskort är ogiltiga", om korrekt rensning av en tidigare redundansväxlingsåtgärd inte utfördes. Därför kan testdatorn fortfarande finnas i Azure-miljön och använda samma IP-adress. Det gör att målkonfigurationen för den virtuella datorn blir kritisk.
Lös problemet genom att se till att en fullständig rensning av redundanstestet har utförts, så att redundans- eller redundansteståtgärden kan lyckas.
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 redigerbara 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
- Gå tillNätverk för virtuell dator> och klicka på namnet på det nätverksgränssnitt som krävs.
- Gå till Ip-konfigurationer och välj sedan namnfältet för den IP-konfiguration som krävs.
- Om du vill aktivera offentlig IP-adress väljer du Aktivera.
- Klicka på Konfigurera nödvändiga inställningar>Skapa ny.
- Ange namnet på den offentliga adressen, välj standardalternativen för SKU och tilldelning och välj sedan OK.
- Spara ändringarna genom att välja Spara.
- 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 VMConnect är 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.
Om den virtuella datorn inte har startats kan du försöka växla över till en äldre återställningspunkt.
Om programmet på den virtuella datorn inte är igång kan du prova att växla över till en appkonsekvent återställningspunkt.
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 redundasväxlata virtuella datorn med ett lokalt administratörskonto.
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)
Om du får ett oväntat avstängningsmeddelande på den återställda virtuella datorn när du startar en virtuell Windows-dator efter redundansväxlingen indikerar det att ett tillstånd för avstängning av virtuell dator inte registrerades på återställningspunkten som användes för redundans. Detta inträffar när du återställer till en punkt när 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 Senaste på redundansskä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 Portal när du försöker återaktivera skyddet av den virtuella dator som har rågivit för 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:
Ö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
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 hjälp av 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.
- Ändra proxyinställningarna i Internet Explorer för att kringgå HUVUDmålserverns IP-adress via proxyn.
Nästa steg
Om du behöver mer hjälp kan du publicera din fråga på microsofts&Q A-frågesida för Site Recovery eller lämna en kommentar i slutet av det här dokumentet. Vi har en aktiv community som ska kunna hjälpa dig.