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

Artikel
03/07/2024

Varning

Den här artikeln refererar till CentOS, en Linux-distribution som närmar sig EOL-status (End Of Life). Överväg att använda och planera i enlighet med detta. Mer information finns i CentOS End Of Life-vägledningen.

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 redolk över en 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äckligt med 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 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 redolk över den klassiska virtuella datorn i Azure. Det kan hända 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 redundans.

Redundans misslyckades med fel-ID 170010

Site Recovery kunde inte skapa en redolk över en virtuell dator i Azure. Det kan inträffa eftersom en intern aktivitet med hydrering misslyckades för den lokala virtuella datorn.

För att kunna ta upp alla datorer 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äxling konverteras därför starttypen för atapi-, intelide-, storflt-, vmbus- och storvsc-drivrutiner till start. 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:

Ladda ned skriptet utan hydrering 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å ingen hydrering ger skriptet resultatet "Det här systemet uppfyller kravet på ingen 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 nätverkskortet för den virtuella datorn är ogiltigt", om korrekt rensning av en tidigare redundanså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 redundansrensning har utförts, så att redundansväxlingen eller redundanstestet 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ökningsinstruktioner om RDP-problem finns i vår dokumentation här.

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

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

Gå till Nätverk för virtuell dator> och klicka på namnet på det nödvändiga nätverksgränssnittet.
Gå till Ip-konfigurationer och välj sedan i namnfältet för nödvändig IP-konfiguration.
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.
Om du vill spara ändringarna väljer du Spara.
Stäng panelerna och gå till översiktsavsnittet för den virtuella datorn för att ansluta/RDP.

Det går inte att ansluta/RDP/SSH – vm Anslut knapp tillgänglig

Om knappen Anslut på den redigerade 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 startat 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 försöka växla över till en appkonsekvent återställningspunkt.
Om den virtuella datorn är domänansluten kontrollerar du att domänkontrollanten fungerar korrekt. Detta kan göras genom att följa nedanstående angivna steg:

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

b. Se till att den kan ansluta till samma domän som den virtuella datorn förväntas komma upp på.

c. Om domänkontrollanten inte fungerar korrekt kan du försöka logga in på den redundasväxlat virtuella datorn med hjälp av ett lokalt administratörskonto.
Om du använder en anpassad DNS-server kontrollerar du att den kan nås. Detta kan göras genom att följa nedanstående angivna steg:

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

Kommentar

Om du aktiverar andra inställningar än Startdiagnostik krävs att 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 med rotbehörighet. 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 virtuell Windows-dator efter redundansväxlingen, 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 virtuella datorer inte registrerades i återställningspunkten som användes för redundansväxling. Detta inträffar när du återställer till en punkt när den virtuella datorn inte har stängts av helt.

Detta är normalt inte en anledning till problem och kan vanligtvis ignoreras för oplanerade redundansväxlingar. Om redundansväxlingen planeras kontrollerar du att den virtuella datorn stängs av korrekt före redundansväxlingen och 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 dataarkivet

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 dator 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 av 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 kommer att vara tillgänglig efter nästa vCenter-identifiering och uppdatering av infrastrukturresurser.

Kommentar

Identifierings- och uppdateringsinfrastrukturåtgärderna kan ta upp till 30 minuter att slutföra.

Linux Master Target-registrering med CS misslyckas med ett 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 indikeras 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.