Řešení chyb replikace virtuálních počítačů Azure do Azure

Tento článek popisuje, jak řešit běžné chyby ve službě Azure Site Recovery během replikace a obnovení virtuálních počítačů Azure z jedné oblasti do druhé. Další informace o podporovaných konfiguracích najdete v matici podpory pro replikaci virtuálních počítačů Azure.

Problémy s kvótou prostředků Azure (kód chyby 150097)

Ujistěte se, že je vaše předplatné povolené k vytvoření virtuálních počítačů Azure v cílové oblasti, kterou plánujete použít jako oblast zotavení po havárii (DR). Vaše předplatné potřebuje dostatečnou kvótu pro vytvoření virtuálních počítačů s potřebnými velikostmi. Site Recovery ve výchozím nastavení vybere stejnou velikost cílového virtuálního počítače, jako je velikost zdrojového virtuálního počítače. Pokud odpovídající velikost není k dispozici, Site Recovery automaticky zvolí nejbližší dostupnou velikost.

Pokud neexistuje žádná velikost, která podporuje konfiguraci zdrojového virtuálního počítače, zobrazí se následující zpráva:

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

Možné příčiny

• Vaše ID předplatného nemá povolené vytváření virtuálních počítačů v cílové oblasti.
• Vaše ID předplatného nemá povolené vytváření virtuálních počítačů určité velikosti v cílové oblasti nebo k tomu nemá dostatečnou kvótu.
• Pro dané ID předplatného se v cílové oblasti nenašla žádná vhodná velikost cílového virtuálního počítače, která by odpovídala počtu síťových karet zdrojového virtuálního počítače (2).

Oprava problému

Pokud chcete, aby vaše předplatné vytvořilo virtuální počítače s požadovanými velikostmi v cílovém umístění, obraťte se na podporu fakturace Azure. Pak zkuste neúspěšnou operaci zopakovat.

Pokud pro cílové umístění platí omezení kapacity, zakažte replikaci do tohoto umístění. Pak povolte replikaci do jiného umístění, ve kterém má vaše předplatné dostatečnou kvótu k vytvoření virtuálních počítačů požadované velikosti.

Důvěryhodné kořenové certifikáty (kód chyby 151066)

Pokud na virtuálním počítači nejsou k dispozici všechny nejnovější důvěryhodné kořenové certifikáty, může vaše úloha povolit replikaci pro Site Recovery selhat. Ověřování a autorizace volání služby Site Recovery z virtuálního počítače selžou bez těchto certifikátů.

Pokud se úloha povolení replikace nezdaří, zobrazí se následující zpráva:

Site Recovery configuration failed.

Možná příčina

Na virtuálním počítači nejsou k dispozici důvěryhodné kořenové certifikáty požadované pro autorizaci a ověřování.

Oprava problému

Windows

Pro virtuální počítač s operačním systémem Windows nainstalujte nejnovější aktualizace Windows, aby byly na virtuálním počítači přítomny všechny důvěryhodné kořenové certifikáty. Pokud chcete získat nejnovější kořenové certifikáty a aktualizovaný seznam odvolaných certifikátů na virtuálních počítačích, postupujte podle typického procesu správy aktualizací windows nebo správy aktualizací certifikátů ve vaší organizaci.

• Pokud jste v odpojeném prostředí, získejte certifikáty podle standardního procesu aktualizace Windows ve vaší organizaci.
• Pokud na virtuálním počítači nejsou k dispozici požadované certifikáty, volání služby Site Recovery z bezpečnostních důvodů selžou.

Pokud chcete ověřit, že se problém vyřešil, přejděte z login.microsoftonline.com prohlížeče na virtuálním počítači.

Další informace naleznete v tématu Konfigurace důvěryhodných kořenových certifikátů a nepovolené certifikáty.

Linux

Pokud chcete získat nejnovější důvěryhodné kořenové certifikáty a nejnovější seznam odvolaných certifikátů na virtuálním počítači, postupujte podle pokynů distributora vaší verze operačního systému Linux.

Vzhledem k tomu, že SUSE Linux používá symbolické odkazy nebo symlinky, udržuje seznam certifikátů, postupujte takto:

1. Přihlaste se jako uživatel root . Symbol hash (#) je výchozí příkazový řádek.

2. Pokud chcete změnit adresář, spusťte tento příkaz:

   cd /etc/ssl/certs

3. Zkontrolujte, jestli je k dispozici kořenový certifikát certifikační autority Symantec:

   ls VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem

   • Pokud se certifikát kořenové certifikační autority Symantec nenajde, stáhněte soubor spuštěním následujícího příkazu. Zkontrolujte případné chyby a postupujte podle doporučených akcí pro selhání sítě.

     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. Zkontrolujte, jestli je k dispozici kořenový certifikát certifikační autority Baltimore:

   ls Baltimore_CyberTrust_Root.pem

   • Pokud se certifikát kořenové certifikační autority Baltimore nenajde, stáhněte certifikát spuštěním tohoto příkazu:

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

5. Zkontrolujte, jestli je k dispozici certifikát DigiCert_Global_Root_CA:

   ls DigiCert_Global_Root_CA.pem

   • Pokud se DigiCert_Global_Root_CA nenajde, stáhněte certifikát spuštěním následujících příkazů:

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

6. Pokud chcete aktualizovat hodnoty hash subjektu certifikátu pro nově stažené certifikáty, spusťte skript rehash:

   c_rehash

7. Pokud chcete zkontrolovat, jestli se pro certifikáty vytvořily hodnoty hash subjektu jako symlinky, spusťte tyto příkazy:

   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. Vytvořte kopii souboru VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem s názvem souboru b204d74a.0:

   cp VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem b204d74a.0

9. Vytvořte kopii souboru Baltimore_CyberTrust_Root.pem s názvem souboru 653b494a.0:

   cp Baltimore_CyberTrust_Root.pem 653b494a.0

10. Vytvořte kopii souboru DigiCert_Global_Root_CA.pem s názvem souboru 3513523f.0:

    cp DigiCert_Global_Root_CA.pem 3513523f.0

11. Zkontrolujte, jestli jsou soubory k dispozici:

    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
    

Odchozí adresy URL nebo rozsahy IP adres (kód chyby 151037 nebo 151072)

Aby replikace Site Recovery fungovala, vyžaduje se odchozí připojení ke konkrétním adresám URL z virtuálního počítače. Pokud je váš virtuální počítač za bránou firewall nebo používá pravidla skupiny zabezpečení sítě (NSG) k řízení odchozího připojení, může dojít k některému z těchto problémů. I když nadále podporujeme odchozí přístup prostřednictvím adres URL, použití seznamu povolených rozsahů IP adres se už nepodporuje.

Možné příčiny

• Kvůli selhání překladu DNS (Domain Name System) nejde navázat připojení ke koncovým bodům Site Recovery.
• Tento problém je častější při opětovném zapnutí ochrany, pokud jste virtuální počítač převzali při selhání, ale server DNS není dostupný z oblasti zotavení po havárii (DR).

Oprava problému

Pokud používáte vlastní DNS, ujistěte se, že je server DNS přístupný z oblasti zotavení po havárii.

Pokud chcete zkontrolovat, jestli virtuální počítač používá vlastní nastavení DNS:

1. Otevřete virtuální počítače a vyberte virtuální počítač.
2. Přejděte do nastavení virtuálních počítačů a vyberte Sítě.
3. Ve virtuální síti nebo podsíti vyberte odkaz a otevřete stránku prostředků virtuální sítě.
4. Přejděte na Nastavení a vyberte servery DNS.

Pokuste se získat přístup k serveru DNS z virtuálního počítače. Pokud server DNS není přístupný, zpřístupnit ho převzetím služeb při selhání serveru DNS nebo vytvořením řádku lokality mezi sítí zotavení po havárii a DNS.

Problém 2: Konfigurace Site Recovery selhala (151196)

Možná příčina

Připojení není možné navázat ke koncovým bodům Microsoft 365 Authentication and Identity IP4.

Oprava problému

Azure Site Recovery vyžaduje přístup k rozsahům IP adres Microsoftu 365 pro ověřování. Pokud k řízení odchozího síťového připojení na virtuálním počítači používáte pravidla nebo proxy server brány firewall (NSG) skupiny zabezpečení sítě (NSG) Azure, ujistěte se, že používáte pravidlo NSG založené na značce služby Microsoft Entra pro povolení přístupu k MICROSOFT Entra ID. Pravidla NSG založená na IP adresách už nepodporujeme.

Problém 3: Konfigurace Site Recovery selhala (151197)

Možná příčina

Připojení nelze navázat ke koncovým bodům služby Azure Site Recovery.

Oprava problému

Pokud k řízení odchozího síťového připojení na virtuálním počítači používáte pravidla skupiny zabezpečení sítě (NSG) Azure, ujistěte se, že používáte značky služeb. Už nepodporujeme použití seznamu povolených IP adres prostřednictvím skupin zabezpečení sítě pro Azure Site Recovery.

Problém 4: Replikace selže, když síťový provoz používá místní proxy server (151072)

Možná příčina

Vlastní nastavení proxy serveru je neplatné a agent Mobility automaticky nerozdetekoval nastavení proxy serveru z Internet Exploreru.

Oprava problému

1. Agent Mobility zjistí nastavení proxy serveru z Internet Exploreru ve Windows a /etc/environment v Linuxu.

2. Pokud chcete proxy server nastavit jenom pro Mobility, můžete zadat podrobnosti o proxy serveru v souboru ProxyInfo.conf, který se nachází na adrese:

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

3. ProxyInfo.conf by měl mít nastavení proxy v následujícím formátu INI.

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

Více informací

Pokud chcete zadat požadované adresy URL nebo požadované rozsahy IP adres, postupujte podle pokynů v tématu O sítích v Azure do replikace Do Azure.

Disk se ve virtuálním počítači nenašel (kód chyby 150039)

Je nutné inicializovat nový disk připojený k virtuálnímu počítači. Pokud se disk nenajde, zobrazí se následující zpráva:

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.

Možné příčiny

• K virtuálnímu počítači byl připojen nový datový disk, ale nebyl inicializován.
• Datový disk uvnitř virtuálního počítače nehlásí správně hodnotu logické jednotky (LUN), na které byl disk připojený k virtuálnímu počítači.

Oprava problému

Ujistěte se, že jsou datové disky inicializovány, a zkuste operaci zopakovat.

• Windows: Připojte a inicializujete nový disk.
• Linux: Inicializace nového datového disku v Linuxu

Pokud problém přetrvává, obraťte se na podporu.

K dispozici je více disků pro ochranu (kód chyby 153039)

Možné příčiny

• Jeden nebo více disků bylo nedávno přidáno do virtuálního počítače po ochraně.
• Po ochraně virtuálního počítače se inicializoval jeden nebo více disků.

Oprava problému

Pokud chcete, aby byl stav replikace virtuálního počítače znovu v pořádku, můžete zvolit ochranu disků nebo zavřít upozornění.

Ochrana disků

1. Přejděte na Disky s názvem>replikovaných položek>virtuálního počítače.

2. Vyberte nechráněný disk a pak vyberte Povolit replikaci:

   

Zavření upozornění

1. Přejděte na název virtuálního počítače replikovaných položek>.

2. V části Přehled vyberte upozornění a pak vyberte OK.

   

Odebraný virtuální počítač z trezoru se dokončil s informacemi (kód chyby 150225)

Když Site Recovery chrání virtuální počítač, vytvoří propojení na zdrojovém virtuálním počítači. Když odeberete ochranu nebo zakážete replikaci, Site Recovery odebere tyto odkazy jako součást úlohy vyčištění. Pokud má virtuální počítač zámek prostředku, úloha vyčištění se dokončí s informacemi. Informace o tom, že virtuální počítač byl odebrán z trezoru služby Recovery Services, ale některé zastaralé odkazy se na zdrojovém počítači nedají vyčistit.

Toto upozornění můžete ignorovat, pokud tento virtuální počítač nikdy nebudete chtít znovu chránit. Pokud ale budete muset tento virtuální počítač později chránit, vyčistíte propojení podle kroků v této části.

Oprava problému

1. Odeberte zámek z virtuálního počítače nebo skupiny prostředků virtuálního počítače. Například na následujícím obrázku musí být odstraněn zámek prostředku na pojmenovaném MoveDemo virtuálním počítači:

   

2. Stáhněte skript, který odebere zastaralou konfiguraci Site Recovery.

3. Spusťte skript, Cleanup-stale-asr-config-Azure-VM.ps1. Jako parametry zadejte ID předplatného, skupinu prostředků virtuálního počítače a název virtuálního počítače.

4. Pokud se zobrazí výzva k zadání přihlašovacích údajů Azure, zadejte je. Pak ověřte, že se skript spustí bez jakýchkoli selhání.

Replikace není na virtuálním počítači povolená se zastaralými prostředky (kód chyby 150226)

Možné příčiny

Virtuální počítač má zastaralou konfiguraci z předchozí ochrany Site Recovery.

Na virtuálním počítači Azure může dojít k zastaralé konfiguraci, pokud jste povolili replikaci virtuálního počítače Azure pomocí Site Recovery a pak:

• Zakázali jste replikaci, ale zdrojový virtuální počítač měl zámek prostředku.
• Trezor Site Recovery jste odstranili bez explicitního zakázání replikace na virtuálním počítači.
• Odstranili jste skupinu prostředků obsahující trezor Site Recovery bez explicitního zakázání replikace na virtuálním počítači.

Oprava problému

1. Odeberte zámek z virtuálního počítače nebo skupiny prostředků virtuálního počítače. Například na následujícím obrázku musí být odstraněn zámek prostředku na pojmenovaném MoveDemo virtuálním počítači:

   

2. Stáhněte skript, který odebere zastaralou konfiguraci Site Recovery.

3. Spusťte skript, Cleanup-stale-asr-config-Azure-VM.ps1. Jako parametry zadejte ID předplatného, skupinu prostředků virtuálního počítače a název virtuálního počítače.

4. Pokud se zobrazí výzva k zadání přihlašovacích údajů Azure, zadejte je. Pak ověřte, že se skript spustí bez jakýchkoli selhání.

Nejde vybrat virtuální počítač nebo skupinu prostředků v povolení úlohy replikace

Problém 1: Skupina prostředků a zdrojový virtuální počítač jsou v různých umístěních

Site Recovery v současné době vyžaduje, aby skupina prostředků zdrojové oblasti a virtuální počítače byly ve stejném umístění. Pokud ne, nebudete moct při pokusu o použití ochrany najít virtuální počítač ani skupinu prostředků.

Alternativním řešením je povolit replikaci z virtuálního počítače místo trezoru služby Recovery Services. Přejděte do části Vlastnosti>zdrojového virtuálního>počítače Zotavení po havárii a povolte replikaci.

Problém 2: Skupina prostředků není součástí vybraného předplatného

Pokud skupina prostředků není součástí vybraného předplatného, možná nebudete moct v době ochrany najít skupinu prostředků. Ujistěte se, že skupina prostředků patří do předplatného, které používáte.

Problém 3: Zastaralá konfigurace

Virtuální počítač, který chcete povolit pro replikaci, se nemusí zobrazit, pokud na virtuálním počítači Azure existuje zastaralá konfigurace Site Recovery. K této podmínce může dojít, pokud jste povolili replikaci pro virtuální počítač Azure pomocí Site Recovery a pak:

• Trezor Site Recovery jste odstranili bez explicitního zakázání replikace na virtuálním počítači.
• Odstranili jste skupinu prostředků obsahující trezor Site Recovery bez explicitního zakázání replikace na virtuálním počítači.
• Zakázali jste replikaci, ale zdrojový virtuální počítač měl zámek prostředku.

Oprava problému

1. Zámek (pokud existuje) odeberte ze skupiny prostředků virtuálního počítače nebo virtuálního počítače. Například na následujícím obrázku musí být odstraněn zámek prostředku na pojmenovaném MoveDemo virtuálním počítači:

   

2. Stáhněte skript, který odebere zastaralou konfiguraci Site Recovery.

3. Spusťte skript, Cleanup-stale-asr-config-Azure-VM.ps1. Jako parametry zadejte ID předplatného, skupinu prostředků virtuálního počítače a název virtuálního počítače.

4. Pokud se zobrazí výzva k zadání přihlašovacích údajů Azure, zadejte je. Pak ověřte, že se skript spustí bez jakýchkoli selhání.

Nejde vybrat virtuální počítač pro ochranu

Možná příčina

Virtuální počítač má nainstalované rozšíření v neúspěšném nebo nereagujícím stavu.

Oprava problému

Přejděte na Rozšíření nastavení>virtuálních počítačů>a zkontrolujte všechna rozšíření ve stavu selhání. Odinstalujte jakékoli neúspěšné rozšíření a zkuste virtuální počítač ochránit znovu.

Stav zřizování virtuálního počítače není platný (kód chyby 150019)

Pokud chcete na virtuálním počítači povolit replikaci, musí být jeho stav zřizování úspěšný. Pokud chcete zkontrolovat stav zřizování, proveďte následující kroky:

1. Na webu Azure Portal vyberte Průzkumníka prostředků ze všech služeb.
2. Rozbalte seznam Předplatná a vyberte své předplatné.
3. Rozbalte seznam ResourceGroups a vyberte skupinu prostředků virtuálního počítače.
4. Rozbalte seznam Prostředky a vyberte virtuální počítač.
5. Zkontrolujte pole provisioningState v zobrazení instance na pravé straně.

Oprava problému

• Pokud je stav zřizování neúspěšný, obraťte se na podporu s podrobnostmi o řešení potíží.
• Pokud je provisioningState aktualizace, může být nasazené další rozšíření. Zkontrolujte, jestli na virtuálním počítači nedochází k nějakým probíhajícím operacím, počkejte, až se dokončí, a pak zkuste neúspěšnou úlohu Site Recovery zopakovat, aby se povolila replikace.

Nejde vybrat cílový virtuální počítač

Problém 1: Virtuální počítač je připojený k síti, která je už namapovaná na cílovou síť

Pokud je zdrojový virtuální počítač součástí virtuální sítě a jiný virtuální počítač ze stejné virtuální sítě je už namapovaný na síť v cílové skupině prostředků, rozevírací seznam pro výběr sítě není ve výchozím nastavení dostupný (zobrazuje se šedě).

Problém 2: Dříve jste virtuální počítač ochránili a pak jste zakázali replikaci.

Zakázání replikace virtuálního počítače neodstraní mapování sítě. Mapování musí být odstraněno z trezoru služby Recovery Services, ve kterém byl virtuální počítač chráněný. Vyberte trezor služby Recovery Services a přejděte do části Správa>infrastruktury>Site Recovery pro mapování sítě virtuálních počítačů>Azure.

Cílovou síť nakonfigurovanou během instalace zotavení po havárii je možné změnit po počátečním nastavení a po uzamčení virtuálního počítače. Chcete-li změnit mapování sítě, vyberte název sítě:

COM+ nebo VSS (kód chyby 151025)

Když dojde k chybě modelu COM+ nebo Služba stínové kopie svazku (VSS), zobrazí se následující zpráva:

Site Recovery extension failed to install.

Možné příčiny

• Služba systémových aplikací modelu COM+ je zakázaná.
• Služba Stínová kopie svazku je zakázaná.

Oprava problému

Nastavte systémovou aplikaci MODELU COM+ a službu Stínová kopie svazku na automatický nebo ruční režim spouštění.

1. Otevřete konzolu Služby ve Windows.

2. Ujistěte se, že systémová aplikace MODELU COM+ a služba stínové kopie svazku nejsou nastaveny na Zakázáno jako typ spuštění.

   

Nepodporovaná velikost spravovaného disku (kód chyby 150172)

Pokud dojde k této chybě, zobrazí se následující zpráva:

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.

Možná příčina

Disk je menší než podporovaná velikost 1024 MB.

Oprava problému

Ujistěte se, že je velikost disku v podporovaném rozsahu velikostí, a pak operaci opakujte.

Ochrana není povolená, když GRUB používá název zařízení (kód chyby 151126)

Možné příčiny

Konfigurační soubory Linuxu Grand Unified Bootloader (GRUB) (/boot/grub/menu.lst, /boot/grub/grub.cfg, /boot/grub2/grub.cfg nebo /etc/default/grub) můžou místo hodnoty univerzálního jedinečného identifikátoru (UUID) zadat root resume skutečné názvy zařízení. Site Recovery vyžaduje identifikátory UUID, protože se můžou změnit názvy zařízení. Po restartování nemusí virtuální počítač přijít se stejným názvem při převzetí služeb při selhání, což vede k problémům.

Následující příklady jsou řádky ze souborů GRUB, kde se místo požadovaných identifikátorů UUID zobrazují názvy zařízení:

• Soubor /boot/grub2/grub.cfg:

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

• Soubor: /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

Oprava problému

Nahraďte každý název zařízení odpovídajícím UUID:

1. Vyhledejte UUID zařízení spuštěním příkazu blkid <device name>. Příklad:

   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. Nahraďte název zařízení jeho UUID ve formátech root=UUID=<UUID> a resume=UUID=<UUID>. Například po nahrazení by řádek z /boot/grub/menu.lst vypadal takto:

   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. Zkuste ochranu zopakovat.

Ochrana selhala, protože zařízení GRUB neexistuje (kód chyby 151124)

Možná příčina

Konfigurační soubory GRUB (/boot/grub/menu.lst, /boot/grub/grub.cfg, /boot/grub2/grub.cfg nebo /etc/default/grub) můžou obsahovat parametry rd.lvm.lv nebo rd_LVM_LV. Tyto parametry identifikují zařízení LvM (Logical Volume Manager), která se mají zjistit při spuštění. Pokud tato zařízení LVM neexistují, chráněný systém se sám nespustí a zablokuje se v procesu spouštění. Stejný problém se také zobrazí u virtuálního počítače s podporou převzetí služeb při selhání. Tady je pár příkladů:

• Soubor: /boot/grub2/grub.cfg na 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

• Soubor: /etc/default/grub na RHEL7:

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

• Soubor: /boot/grub/menu.lst v 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

V každém příkladu grub musí zjistit dvě zařízení LVM s názvy root a swap ze skupiny rootvgsvazků .

Oprava problému

Pokud zařízení LVM neexistuje, vytvořte ho nebo odeberte odpovídající parametry z konfiguračních souborů GRUB. Potom zkuste ochranu povolit znovu.

Mobility aktualizace skončila s upozorněními (kód chyby 151083)

Mobility Site Recovery má mnoho komponent, z nichž jeden se nazývá ovladač filtru. Ovladač filtru se načte do systémové paměti pouze během restartování systému. Pokaždé, když aktualizace Mobility obsahuje změny ovladače filtru, počítač se aktualizuje, ale přesto se zobrazí upozornění, že některé opravy vyžadují restartování. Zobrazí se upozornění, protože opravy ovladačů filtru se můžou projevit pouze v případě, že je načten nový ovladač filtru, ke kterému dochází pouze během restartování.

Ochrana není povolená, pokud existuje spravovaný disk repliky.

K této chybě dochází v případě, že spravovaný disk repliky již existuje bez očekávaných značek v cílové skupině prostředků.

Možná příčina

K tomuto problému může dojít, pokud byl virtuální počítač dříve chráněný a když byla replikace zakázaná, disk repliky se neodebral.

Oprava problému

Odstraňte disk repliky identifikovaný v chybové zprávě a zkuste úlohu ochrany, která selhala.

Povolení ochrany selhalo, protože instalační program nemůže najít kořenový disk (kód chyby 151137)

K této chybě dochází u počítačů s Linuxem, kde je disk s operačním systémem šifrovaný pomocí služby Azure Disk Encryption (ADE). Toto je platný problém jenom v agentu verze 9.35.

Možné příčiny

Instalační program nemůže najít kořenový disk, který je hostitelem kořenového systému souborů.

Oprava problému

Pokud chcete tento problém vyřešit, proveďte následující kroky.

1. V adresáři /var/lib/waagent na počítačích RHEL najděte bity agenta pomocí následujícího příkazu:
   

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

   Očekávaný výstup:

   /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. Vytvořte nový adresář a změňte adresář na tento nový adresář.

3. Pomocí následujícího příkazu extrahujte soubor agenta nalezený v prvním kroku:

   tar -xf <Tar Ball File>

4. Otevřete soubor prereq_check_installer.json a odstraňte následující řádky. Potom soubor uložte.

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

5. Pomocí příkazu vyvolejte instalační program:
   

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

6. Pokud instalační program proběhne úspěšně, zkuste znovu povolit úlohu replikace.

Řešení potíží a zpracování změn času na replikovaných serverech

K této chybě dochází, když se čas zdrojového počítače posune dopředu a pak se přesune zpět za krátkou dobu, aby se změna opravil. Změnu si nemusíte všimnout, protože čas se opravuje velmi rychle.

Postup: Pokud chcete tento problém vyřešit, počkejte, až systémový čas překročí nerovnoměrnou budoucí dobu. Další možností je zakázat a znovu povolit replikaci, což je možné pouze pro přesměrovanou replikaci (data replikovaná z primární do sekundární oblasti) a není použitelná pro zpětnou replikaci (data replikovaná ze sekundární do primární oblasti).

Další kroky

Replikace virtuálních počítačů Azure do jiné oblasti Azure