Felsöka problem med replikering av virtuella datorer i Azure till Azure-scenarier

I den här artikeln beskrivs hur du felsöker vanliga fel i Azure Site Recovery under replikering och återställning av virtuella Azure-datorer (VM) från en region till en annan. Mer information om konfigurationer som stöds finns i supportmatrisen för replikering av virtuella Azure-datorer.

Problem med Azure-resurskvoter (felkod 150097)

Kontrollera att din prenumeration är aktiverad för att skapa virtuella Azure-datorer i målregionen som du planerar att använda som haveriberedskapsregion. Din prenumeration behöver tillräcklig kvot för att skapa virtuella datorer av nödvändiga storlekar. Som standard väljer Site Recovery en VM-målstorlek som är samma som den virtuella källdatorns storlek. Om matchande storlek inte är tillgänglig väljer Site Recovery automatiskt den närmaste tillgängliga storleken.

Om det inte finns någon storlek som stöder konfigurationen av den virtuella källdatorn visas följande meddelande:

Replication couldn't be enabled for the virtual machine <VmName>.

Möjliga orsaker

• Ditt prenumerations-ID är inte aktiverat för att skapa några virtuella datorer på målregionens plats.
• Ditt prenumerations-ID är inte aktiverat eller har inte tillräcklig kvot för att kunna skapa specifika VM-storlekar på målregionens plats.
• Ingen lämplig VM-målstorlek hittades som matchar den virtuella källdatorns antal nätverkskort (2) för prenumerations-ID:t på målregionens plats.

Åtgärda problemet

Kontakta Azure-faktureringssupporten för att aktivera din prenumeration för att skapa virtuella datorer av de storlekar som krävs på målplatsen. Försök sedan utföra den misslyckade åtgärden igen.

Om målplatsen har en kapacitetsbegränsning inaktiverar du replikering till den platsen. Aktivera sedan replikering till en annan plats där din prenumeration har tillräcklig kvot för att kunna skapa virtuella datorer med de storlekar som krävs.

Betrodda rotcertifikat (felkod 151066)

Om inte alla de senaste betrodda rotcertifikaten finns på den virtuella datorn kan ditt jobb för att aktivera replikering för Site Recovery misslyckas. Autentisering och auktorisering av Site Recovery-tjänstanrop från den virtuella datorn misslyckas utan dessa certifikat.

Om det inte går att aktivera replikeringsjobbet visas följande meddelande:

Site Recovery configuration failed.

Möjlig orsak

De betrodda rotcertifikat som krävs för auktorisering och autentisering finns inte på den virtuella datorn.

Åtgärda problemet

Windows

För en virtuell dator som kör Windows-operativsystemet installerar du de senaste Windows-uppdateringarna så att alla betrodda rotcertifikat finns på den virtuella datorn. Följ den vanliga processen för hantering av Windows-uppdatering eller hantering av certifikatuppdatering i din organisation för att hämta de senaste rotcertifikaten och listan över uppdaterade certifikatåterkallning på de virtuella datorerna.

• Om du befinner dig i en frånkopplad miljö följer du windows-standarduppdateringsprocessen i din organisation för att hämta certifikaten.
• Om de nödvändiga certifikaten inte finns på den virtuella datorn misslyckas anropen till Site Recovery-tjänsten av säkerhetsskäl.

Om du vill kontrollera att problemet är löst går du till login.microsoftonline.com från en webbläsare på den virtuella datorn.

Mer information finns i Konfigurera betrodda rötter och otillåtna certifikat.

Linux

Följ vägledningen från distributören av din Version av Linux-operativsystemet för att hämta de senaste betrodda rotcertifikaten och den senaste listan över återkallade certifikat på den virtuella datorn.

Eftersom SUSE Linux använder symboliska länkar, eller symlänkar, för att underhålla en certifikatlista följer du dessa steg:

1. Logga in som en rotanvändare . Hash-symbolen (#) är standardkommandot.

2. Om du vill ändra katalogen kör du det här kommandot:

   cd /etc/ssl/certs

3. Kontrollera om Symantec-rotcertifikatutfärdarcertifikatet finns:

   ls VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem

   • Om Symantec-rotcertifikatutfärdarcertifikatet inte hittas kör du följande kommando för att ladda ned filen. Kontrollera eventuella fel och följ rekommenderade åtgärder för nätverksfel.

     wget https://docs.broadcom.com/docs-and-downloads/content/dam/symantec/docs/other-resources/verisign-class-3-public-primary-certification-authority-g5-en.pem -O VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem

4. Kontrollera om Baltimore-rotcertifikatutfärdarcertifikatet finns:

   ls Baltimore_CyberTrust_Root.pem

   • Om baltimorerotcertifikatutfärdarcertifikatet inte hittas kör du det här kommandot för att ladda ned certifikatet:

     wget https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem -O Baltimore_CyberTrust_Root.pem

5. Kontrollera om DigiCert_Global_Root_CA certifikatet finns:

   ls DigiCert_Global_Root_CA.pem

   • Om DigiCert_Global_Root_CA inte hittas kör du följande kommandon för att ladda ned certifikatet:

     wget http://www.digicert.com/CACerts/DigiCertGlobalRootCA.crt
     
     openssl x509 -in DigiCertGlobalRootCA.crt -inform der -outform pem -out DigiCert_Global_Root_CA.pem
     

6. Om du vill uppdatera certifikatämneshasherna för de nyligen nedladdade certifikaten kör du omhash-skriptet:

   c_rehash

7. Kör följande kommandon för att kontrollera om ämnet hashar som symlinks skapades för certifikaten:

   ls -l | grep Baltimore
   

   lrwxrwxrwx 1 root root   29 Jan  8 09:48 3ad48a91.0 -> Baltimore_CyberTrust_Root.pem
   
   -rw-r--r-- 1 root root 1303 Jun  5  2014 Baltimore_CyberTrust_Root.pem
   

   ls -l | grep VeriSign_Class_3_Public_Primary_Certification_Authority_G5
   

   -rw-r--r-- 1 root root 1774 Jun  5  2014 VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem
   
   lrwxrwxrwx 1 root root   62 Jan  8 09:48 facacbc6.0 -> VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem
   

   ls -l | grep DigiCert_Global_Root
   

   lrwxrwxrwx 1 root root   27 Jan  8 09:48 399e7759.0 -> DigiCert_Global_Root_CA.pem
   
   -rw-r--r-- 1 root root 1380 Jun  5  2014 DigiCert_Global_Root_CA.pem
   

8. Skapa en kopia av filen VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem med filnamnet b204d74a.0:

   cp VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem b204d74a.0

9. Skapa en kopia av filen Baltimore_CyberTrust_Root.pem med filnamnet 653b494a.0:

   cp Baltimore_CyberTrust_Root.pem 653b494a.0

10. Skapa en kopia av filen DigiCert_Global_Root_CA.pem med filnamnet 3513523f.0:

    cp DigiCert_Global_Root_CA.pem 3513523f.0

11. Kontrollera att filerna finns:

    ls -l 653b494a.0 b204d74a.0 3513523f.0
    

    -rw-r--r-- 1 root root 1774 Jan  8 09:52 3513523f.0
    
    -rw-r--r-- 1 root root 1303 Jan  8 09:52 653b494a.0
    
    -rw-r--r-- 1 root root 1774 Jan  8 09:52 b204d74a.0
    

Utgående URL:er eller IP-intervall (felkod 151037 eller 151072)

För att Site Recovery-replikering ska fungera krävs utgående anslutning till specifika URL:er från den virtuella datorn. Om den virtuella datorn ligger bakom en brandvägg eller använder regler för nätverkssäkerhetsgrupp (NSG) för att styra utgående anslutning kan du stöta på något av dessa problem. Även om vi fortsätter att stödja utgående åtkomst via URL:er stöds inte längre en lista över tillåtna IP-intervall.

Möjliga orsaker

• Det går inte att upprätta en anslutning till Site Recovery-slutpunkter på grund av ett DNS-matchningsfel (Domain Name System).
• Det här problemet är vanligare vid återaktivering av skyddet när du har redväxlar över den virtuella datorn, men DNS-servern inte kan nås från haveriberedskapsregionen.

Åtgärda problemet

Om du använder anpassad DNS kontrollerar du att DNS-servern är tillgänglig från haveriberedskapsregionen.

Så här kontrollerar du om den virtuella datorn använder en anpassad DNS-inställning:

1. Öppna Virtuella datorer och välj den virtuella datorn.
2. Gå till inställningarna för de virtuella datorerna och välj Nätverk.
3. I Virtuellt nätverk/undernät väljer du länken för att öppna det virtuella nätverkets resurssida.
4. Gå till Inställningar och välj DNS-servrar.

Försök att komma åt DNS-servern från den virtuella datorn. Om DNS-servern inte är tillgänglig kan du göra den tillgänglig genom att antingen växla över DNS-servern eller skapa platsraden mellan DR-nätverket och DNS.

Problem 2: Site Recovery-konfigurationen misslyckades (151196)

Möjlig orsak

Det går inte att upprätta en anslutning till Microsoft 365-autentiserings- och identitets-IP4-slutpunkter.

Åtgärda problemet

Azure Site Recovery krävde åtkomst till Microsoft 365 IP-intervall för autentisering. Om du använder regler/brandväggsproxy för Azure Network Security Group (NSG) för att styra utgående nätverksanslutningar på den virtuella datorn kontrollerar du att du använder Microsoft Entra-tjänsttaggbaserad NSG-regel för att tillåta åtkomst till Microsoft Entra-ID. Vi stöder inte längre IP-adressbaserade NSG-regler.

Problem 3: Site Recovery-konfigurationen misslyckades (151197)

Möjlig orsak

Det går inte att upprätta en anslutning till Azure Site Recovery-tjänstslutpunkter.

Åtgärda problemet

Om du använder regler/brandväggsproxy för Azure Network Security Group (NSG) för att styra utgående nätverksanslutningar på den virtuella datorn kontrollerar du att du använder tjänsttaggar. Vi stöder inte längre användning av en lista över tillåtna IP-adresser via NSG:er för Azure Site Recovery.

Problem 4: Replikeringen misslyckas när nätverkstrafiken använder en lokal proxyserver (151072)

Möjlig orsak

De anpassade proxyinställningarna är ogiltiga och tjänsten Mobility agenten har inte identifiera proxyinställningarna automatiskt från Internet Explorer.

Åtgärda problemet

1. Tjänsten Mobility-agenten identifierar proxyinställningarna från Internet Explorer i Windows och /etc/environment i Linux.

2. Om du föredrar att endast ange proxy för tjänsten Mobility kan du ange proxyinformationen i ProxyInfo.conf på:

   • Linux: /usr/local/InMage/config/
   • Windows: C:\ProgramData\Microsoft Azure Site Recovery\Config

3. ProxyInfo.conf bör ha proxyinställningarna i följande INI-format.

   [proxy]
   Address=http://1.2.3.4
   Port=567
   

Mer information

Om du vill ange nödvändiga URL:er eller nödvändiga IP-intervall följer du riktlinjerna i Om nätverk i Azure till Azure-replikering.

Det gick inte att hitta disken i den virtuella datorn (felkod 150039)

En ny disk som är ansluten till den virtuella datorn måste initieras. Om disken inte hittas visas följande meddelande:

Azure data disk <DiskName> <DiskURI> with logical unit number <LUN> <LUNValue> was not mapped to a corresponding disk being reported from within the VM that has the same LUN value.

Möjliga orsaker

• En ny datadisk kopplades till den virtuella datorn men initierades inte.
• Datadisken i den virtuella datorn rapporterar inte korrekt lun-värdet (logical unit number) som disken var ansluten till den virtuella datorn till.

Åtgärda problemet

Kontrollera att datadiskarna har initierats och försök sedan utföra åtgärden igen.

• Windows: Anslut och initiera en ny disk.
• Linux: Initiera en ny datadisk i Linux.

Kontakta supporten om problemet kvarstår.

Flera diskar som är tillgängliga för skydd (felkod 153039)

Möjliga orsaker

• En eller flera diskar har nyligen lagts till på den virtuella datorn efter skydd.
• En eller flera diskar initierades efter skydd av den virtuella datorn.

Åtgärda problemet

Om du vill göra replikeringsstatusen för den virtuella datorn felfri igen kan du välja att antingen skydda diskarna eller stänga varningen.

Skydda diskarna

1. Gå till Replikerade objekt>VM-namn>Diskar.

2. Välj den oskyddade disken och välj sedan Aktivera replikering:

   

Så här stänger du varningen

1. Gå till Namnet på den virtuella datorn för replikerade objekt>.

2. Välj varningen i avsnittet Översikt och välj sedan OK.

   

Den virtuella datorn som tagits bort från valvet har slutförts med information (felkod 150225)

När Site Recovery skyddar den virtuella datorn skapar den länkar på den virtuella källdatorn. När du tar bort skyddet eller inaktiverar replikering tar Site Recovery bort dessa länkar som en del av rensningsjobbet. Om den virtuella datorn har ett resurslås slutförs rensningsjobbet med informationen. Informationen säger att den virtuella datorn har tagits bort från Recovery Services-valvet, men att vissa av de inaktuella länkarna inte kunde rensas på källdatorn.

Du kan ignorera den här varningen om du aldrig tänker skydda den här virtuella datorn igen. Men om du måste skydda den här virtuella datorn senare följer du stegen i det här avsnittet för att rensa länkarna.

Åtgärda problemet

1. Ta bort låset från resursgruppen för den virtuella datorn eller den virtuella datorn. I följande bild måste till exempel resurslåset på den virtuella datorn med namnet MoveDemo tas bort:

   

2. Ladda ned skriptet för att ta bort en inaktuell Site Recovery-konfiguration.

3. Kör skriptet Cleanup-stale-asr-config-Azure-VM.ps1. Ange prenumerations-ID, VM-resursgrupp och VM-namn som parametrar.

4. Om du uppmanas att ange autentiseringsuppgifter för Azure anger du dem. Kontrollera sedan att skriptet körs utan fel.

Replikeringen är inte aktiverad på den virtuella datorn med inaktuella resurser (felkod 150226)

Möjliga orsaker

Den virtuella datorn har en inaktuell konfiguration från tidigare Site Recovery-skydd.

En inaktuell konfiguration kan inträffa på en virtuell Azure-dator om du har aktiverat replikering för den virtuella Azure-datorn med hjälp av Site Recovery och sedan:

• Du har inaktiverat replikering, men den virtuella källdatorn hade ett resurslås.
• Du har tagit bort Site Recovery-valvet utan att uttryckligen inaktivera replikeringen på den virtuella datorn.
• Du har tagit bort resursgruppen som innehåller Site Recovery-valvet utan att uttryckligen inaktivera replikeringen på den virtuella datorn.

Åtgärda problemet

1. Ta bort låset från resursgruppen för den virtuella datorn eller den virtuella datorn. I följande bild måste till exempel resurslåset på den virtuella datorn med namnet MoveDemo tas bort:

   

2. Ladda ned skriptet för att ta bort en inaktuell Site Recovery-konfiguration.

3. Kör skriptet Cleanup-stale-asr-config-Azure-VM.ps1. Ange prenumerations-ID, VM-resursgrupp och VM-namn som parametrar.

4. Om du uppmanas att ange autentiseringsuppgifter för Azure anger du dem. Kontrollera sedan att skriptet körs utan fel.

Det går inte att välja virtuell dator eller resursgrupp i aktivera replikeringsjobb

Problem 1: Resursgruppen och den virtuella källdatorn finns på olika platser

Site Recovery kräver för närvarande att källregionens resursgrupp och virtuella datorer finns på samma plats. Om de inte är det kan du inte hitta den virtuella datorn eller resursgruppen när du försöker använda skydd.

Som en lösning kan du aktivera replikering från den virtuella datorn i stället för Recovery Services-valvet. Gå till Haveriberedskap för vm-källegenskaper>>och aktivera replikeringen.

Problem 2: Resursgruppen ingår inte i den valda prenumerationen

Du kanske inte kan hitta resursgruppen vid tidpunkten för skyddet om resursgruppen inte ingår i den valda prenumerationen. Kontrollera att resursgruppen tillhör den prenumeration som du använder.

Problem 3: Inaktuell konfiguration

Du kanske inte ser den virtuella dator som du vill aktivera för replikering om det finns en inaktuell Site Recovery-konfiguration på den virtuella Azure-datorn. Det här villkoret kan inträffa om du har aktiverat replikering för den virtuella Azure-datorn med hjälp av Site Recovery och sedan:

• Du har tagit bort Site Recovery-valvet utan att uttryckligen inaktivera replikeringen på den virtuella datorn.
• Du har tagit bort resursgruppen som innehåller Site Recovery-valvet utan att uttryckligen inaktivera replikeringen på den virtuella datorn.
• Du har inaktiverat replikering, men den virtuella källdatorn hade ett resurslås.

Åtgärda problemet

1. Ta bort låset, om det finns något, från resursgruppen för den virtuella datorn eller den virtuella datorn. I följande bild måste till exempel resurslåset på den virtuella datorn med namnet MoveDemo tas bort:

   

2. Ladda ned skriptet för att ta bort en inaktuell Site Recovery-konfiguration.

3. Kör skriptet Cleanup-stale-asr-config-Azure-VM.ps1. Ange prenumerations-ID, VM-resursgrupp och VM-namn som parametrar.

4. Om du uppmanas att ange autentiseringsuppgifter för Azure anger du dem. Kontrollera sedan att skriptet körs utan fel.

Det går inte att välja en virtuell dator som skydd

Möjlig orsak

Den virtuella datorn har ett tillägg installerat i ett feltillstånd eller inte svarar

Åtgärda problemet

Gå till Tillägg för inställningar>för virtuella datorer>och sök efter tillägg i ett feltillstånd. Avinstallera eventuella misslyckade tillägg och försök sedan igen för att skydda den virtuella datorn.

Etableringstillståndet för virtuella datorer är inte giltigt (felkod 150019)

Om du vill aktivera replikering på den virtuella datorn måste etableringstillståndet vara Lyckades. Utför följande steg för att kontrollera etableringstillståndet:

1. I Azure Portal väljer du Resursutforskaren från Alla tjänster.
2. Expandera listan Prenumerationer och välj din prenumeration.
3. Expandera listan ResourceGroups och välj resursgruppen för den virtuella datorn.
4. Expandera listan Resurser och välj den virtuella datorn.
5. Kontrollera fältet provisioningState i instansvyn till höger.

Åtgärda problemet

• Om provisioningState misslyckas kontaktar du supporten med information för att felsöka.
• Om provisioningState uppdateras kan ett annat tillägg distribueras. Kontrollera om det finns några pågående åtgärder på den virtuella datorn, vänta tills de har slutförts och försök sedan igen med det misslyckade Site Recovery-jobbet för att aktivera replikering.

Det går inte att välja den virtuella måldatorn

Problem 1: Den virtuella datorn är ansluten till ett nätverk som redan har mappats till ett målnätverk

Om den virtuella källdatorn är en del av ett virtuellt nätverk och en annan virtuell dator från samma virtuella nätverk redan har mappats med ett nätverk i målresursgruppen under haveriberedskapskonfigurationen är listrutan för nätverksval inte tillgänglig (visas nedtonad) som standard.

Problem 2: Du har tidigare skyddat den virtuella datorn och sedan inaktiverat replikeringen

Om du inaktiverar replikering av en virtuell dator tas inte nätverksmappningen bort. Mappningen måste tas bort från Recovery Services-valvet där den virtuella datorn skyddades. Välj Recovery Services-valvet och gå till Hantera>Site Recovery-infrastruktur>för nätverksmappning för virtuella Azure-datorer.>

Målnätverket som konfigurerades under installationen av haveriberedskap kan ändras efter den första installationen och efter att den virtuella datorn har skyddats. Om du vill ändra nätverksmappning väljer du nätverksnamnet:

COM+ eller VSS (felkod 151025)

När felet COM+ eller Volume Shadow Copy Service (VSS) inträffar visas följande meddelande:

Site Recovery extension failed to install.

Möjliga orsaker

• COM+ System Application-tjänsten är inaktiverad.
• Tjänsten Volume Shadow Copy är inaktiverad.

Åtgärda problemet

Ange COM+ System Application och Volume Shadow Copy Service till automatiskt eller manuellt startläge.

1. Öppna tjänstkonsolen i Windows.

2. Kontrollera att COM+ System Application och Volume Shadow Copy Service inte är inställda på Inaktiverad som starttyp.

   

Hanterad diskstorlek som inte stöds (felkod 150172)

När det här felet inträffar visas följande meddelande:

Protection couldn't be enabled for the virtual machine as it has <DiskName> with size <DiskSize> that is lesser than the minimum supported size 1024 MB.

Möjlig orsak

Disken är mindre än storleken på 1 024 MB som stöds.

Åtgärda problemet

Kontrollera att diskstorleken ligger inom storleksintervallet som stöds och försök sedan utföra åtgärden igen.

Skydd är inte aktiverat när GRUB använder enhetsnamn (felkod 151126)

Möjliga orsaker

Konfigurationsfilerna för Linux Grand Unified Bootloader (GRUB) (/boot/grub/menu.lst, /boot/grub/grub.cfg, /boot/grub2/grub.cfg eller /etc/default/grub) kan ange de faktiska enhetsnamnen i stället för UUID-värden (UniversalLy Unique Identifier) för parametrarna root och resume . Site Recovery kräver UUID eftersom enhetsnamn kan ändras. Vid omstart kanske en virtuell dator inte har samma namn vid redundansväxling, vilket resulterar i problem.

Följande exempel är rader från GRUB-filer där enhetsnamn visas i stället för nödvändiga UUID:er:

• Fil /boot/grub2/grub.cfg:

  linux /boot/vmlinuz-3.12.49-11-default root=/dev/sda2 ${extra_cmdline} resume=/dev/sda1 splash=silent quiet showopts

• Fil: /boot/grub/menu.lst

  kernel /boot/vmlinuz-3.0.101-63-default root=/dev/sda2 resume=/dev/sda1 splash=silent crashkernel=256M-:128M showopts vga=0x314

Åtgärda problemet

Ersätt varje enhetsnamn med motsvarande UUID:

1. Hitta enhetens UUID genom att köra kommandot blkid <device name>. Till exempel:

   blkid /dev/sda1
   /dev/sda1: UUID="6f614b44-433b-431b-9ca1-4dd2f6f74f6b" TYPE="swap"
   blkid /dev/sda2
   /dev/sda2: UUID="62927e85-f7ba-40bc-9993-cc1feeb191e4" TYPE="ext3"
   

2. Ersätt enhetsnamnet med dess UUID i formaten root=UUID=<UUID> och resume=UUID=<UUID>. Efter ersättningen skulle till exempel raden från /boot/grub/menu.lst se ut som följande rad:

   kernel /boot/vmlinuz-3.0.101-63-default root=UUID=62927e85-f7ba-40bc-9993-cc1feeb191e4 resume=UUID=6f614b44-433b-431b-9ca1-4dd2f6f74f6b splash=silent crashkernel=256M-:128M showopts vga=0x314

3. Försök att skydda igen.

Skyddet misslyckades eftersom GRUB-enheten inte finns (felkod 151124)

Möjlig orsak

GRUB-konfigurationsfilerna (/boot/grub/menu.lst, /boot/grub/grub.cfg, /boot/grub2/grub.cfg eller /etc/default/grub) kan innehålla parametrarna rd.lvm.lv eller rd_LVM_LV. Dessa parametrar identifierar de LVM-enheter (Logical Volume Manager) som ska identifieras vid start. Om dessa LVM-enheter inte finns startar inte själva det skyddade systemet och fastnar i startprocessen. Samma problem visas också med den virtuella redundansdatorn. Här är några exempel:

• Fil: /boot/grub2/grub.cfg på RHEL7:

  linux16 /vmlinuz-3.10.0-957.el7.x86_64 root=/dev/mapper/rhel_mup--rhel7u6-root ro crashkernel=128M\@64M rd.lvm.lv=rootvg/root rd.lvm.lv=rootvg/swap rhgb quiet LANG=en_US.UTF-8

• Fil: /etc/default/grub på RHEL7:

  GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=rootvg/root rd.lvm.lv=rootvg/swap rhgb quiet

• Fil: /boot/grub/menu.lst på RHEL6:

  kernel /vmlinuz-2.6.32-754.el6.x86_64 ro root=UUID=36dd8b45-e90d-40d6-81ac-ad0d0725d69e rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_LVM_LV=rootvg/lv_root KEYBOARDTYPE=pc KEYTABLE=us rd_LVM_LV=rootvg/lv_swap rd_NO_DM rhgb quiet

I varje exempel måste GRUB identifiera två LVM-enheter med namnen root och swap från volymgruppen rootvg.

Åtgärda problemet

Om LVM-enheten inte finns skapar du den eller tar bort motsvarande parametrar från GRUB-konfigurationsfilerna. Försök sedan igen för att aktivera skydd.

tjänsten Mobility uppdateringen har slutförts med varningar (felkod 151083)

Site Recovery-tjänsten Mobility har många komponenter, varav en kallas filterdrivrutin. Filterdrivrutinen läses bara in i systemminnet under omstarten av systemet. När en tjänsten Mobility uppdatering innehåller filterdrivrutinsändringar uppdateras datorn, men du ser fortfarande en varning om att vissa korrigeringar kräver en omstart. Varningen visas eftersom filterdrivrutinskorrigeringarna endast kan börja gälla när den nya filterdrivrutinen läses in, vilket endast sker under en omstart.

Skydd är inte aktiverat om det finns en hanterad replikdisk

Det här felet uppstår när den replikhanterade disken redan finns, utan förväntade taggar, i målresursgruppen.

Möjlig orsak

Det här problemet kan inträffa om den virtuella datorn tidigare skyddades och replikdisken inte togs bort när replikeringen inaktiverades.

Åtgärda problemet

Ta bort replikdisken som identifierades i felmeddelandet och försök igen med det misslyckade skyddsjobbet.

Det gick inte att aktivera skyddet eftersom installationsprogrammet inte kan hitta rotdisken (felkod 151137)

Det här felet uppstår för Linux-datorer där OS-disken krypteras med hjälp av Azure Disk Encryption (ADE). Det här är ett giltigt problem endast i agentversion 9.35.

Möjliga orsaker

Installationsprogrammet kan inte hitta rotdisken som är värd för rotfilsystemet.

Åtgärda problemet

Utför följande steg för att åtgärda problemet.

1. Hitta agentbitarna under katalogen /var/lib/waagent på RHEL-datorer med hjälp av kommandot nedan:
   

   # find /var/lib/ -name Micro\*.gz

   Förväntad utdata:

   /var/lib/waagent/Microsoft.Azure.RecoveryServices.SiteRecovery.LinuxRHEL7-1.0.0.9139/UnifiedAgent/Microsoft-ASR_UA_9.35.0.0_RHEL7-64_GA_30Jun2020_release.tar.gz

2. Skapa en ny katalog och ändra katalogen till den nya katalogen.

3. Extrahera agentfilen som finns i det första steget här med hjälp av kommandot nedan:

   tar -xf <Tar Ball File>

4. Öppna filen prereq_check_installer.json och ta bort följande rader. Spara filen efter det.

      {
         "CheckName": "SystemDiskAvailable",
         "CheckType": "MobilityService"
      },
   

5. Anropa installationsprogrammet med kommandot :
   

   ./install -d /usr/local/ASR -r MS -q -v Azure

6. Om installationsprogrammet lyckas försöker du aktivera replikeringsjobbet igen.

Felsöka och hantera tidsändringar på replikerade servrar

Det här felet uppstår när källdatorns tid flyttas framåt och sedan flyttas tillbaka på kort tid för att korrigera ändringen. Du kanske inte märker ändringen eftersom tiden korrigeras mycket snabbt.

Så här åtgärdar du: Lös problemet genom att vänta tills systemtiden överskrider den skeva framtida tiden. Ett annat alternativ är att inaktivera och aktivera replikering igen, vilket endast är möjligt för vidarebefordrad replikering (data som replikeras från den primära till den sekundära regionen) och inte gäller för omvänd replikering (data som replikeras från sekundär till primär region).

Nästa steg

Replikera virtuella Azure-datorer till en annan Azure-region.