Correggere gli errori di replica delle macchine virtuali da Azure ad Azure

Questo articolo descrive come risolvere gli errori comuni in Azure Site Recovery durante la replica e il ripristino di macchine virtuali (VM) di Azure da un'area a un'altra. Per altre informazioni sulle configurazioni supportate, vedere la matrice di supporto per la replica delle VM di Azure.

Problemi di quota delle risorse di Azure (codice errore 150097)

Assicurarsi che la sottoscrizione sia abilitata per la creazione di VM di Azure nell'area di destinazione che si prevede di usare come area per il ripristino di emergenza. La sottoscrizione necessita di una quota sufficiente per creare VM delle dimensioni necessarie. Per impostazione predefinita, Site Recovery sceglie per la macchina virtuale di destinazione una dimensione uguale a quella della macchina virtuale di origine. Se la dimensione corrispondente non è disponibile, Site Recovery sceglie automaticamente la dimensione più vicina disponibile.

Se non sono presenti dimensioni che supportano la configurazione della VM di origine, viene visualizzato il messaggio seguente:

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

Possibili cause

• L'ID sottoscrizione non è abilitato per la creazione di macchine virtuali nella posizione dell'area di destinazione.
• L'ID sottoscrizione non è abilitato o non ha una quota sufficiente per la creazione di macchine virtuali di dimensioni specifiche nella posizione dell'area di destinazione.
• Non è stata trovata nessuna macchina virtuale di destinazione adatta con un numero (2) di schede di interfaccia di rete corrispondente alla macchina virtuale di origine per l'ID sottoscrizione nella posizione dell'area di destinazione.

Risolvere il problema

Contattare il servizio di supporto per la fatturazione di Azure per abilitare la sottoscrizione per la creazione di VM delle dimensioni richieste nella posizione di destinazione. Riprovare quindi l'operazione non riuscita.

Se la posizione di destinazione ha un vincolo di capacità, disabilitare la replica in tale posizione. Abilitare quindi la replica in una posizione diversa dove la sottoscrizione ha una quota sufficiente per creare macchine virtuali delle dimensioni necessarie.

Certificati radice attendibili (codice errore 151066)

Se nella VM non sono presenti tutti i certificati radice attendibili più recenti, il processo per abilitare la replica per Site Recovery potrebbe non riuscire. Senza questi certificati, le chiamate di autenticazione e autorizzazione del servizio Site Recovery dalla VM non riescono.

Se il processo di abilitazione della replica ha esito negativo, viene visualizzato il messaggio seguente:

Site Recovery configuration failed.

Possibile causa

I certificati radice attendibili necessari usati per l'autorizzazione e l'autenticazione non sono presenti nella macchina virtuale.

Risolvere il problema

Finestre

Per una VM che esegue il sistema operativo Windows, installare gli aggiornamenti di Windows più recenti in modo che tutti i certificati radice attendibili siano presenti nella VM. Seguire il processo tipico di gestione degli aggiornamenti di Windows o dei certificati in uso nell'organizzazione per ottenere i certificati radice più recenti e l'elenco di revoche di certificati aggiornato nelle VM.

• Se si lavora in un ambiente non connesso, seguire il processo di aggiornamento di Windows standard dell'organizzazione per ottenere i certificati.
• Se i certificati richiesti non sono presenti nella VM, le chiamate al servizio Site Recovery non riescono per motivi di sicurezza.

Per verificare che il problema sia stato risolto, passare a login.microsoftonline.com da un browser nella VM.

Per altre informazioni, vedere Configurare radici attendibili e certificati non consentiti.

Linux

Seguire le indicazioni fornite dal distributore della versione del sistema operativo Linux per ottenere i certificati radice attendibili più recenti e l'elenco di revoche di certificati più recente nella VM.

Poiché SUSE Linux usa i collegamenti simbolici, o symlink, per gestire un elenco di certificati, eseguire questa procedura:

1. Accedere come utente root. Il simbolo hash (#) è il prompt dei comandi predefinito.

2. Eseguire questo comando per cambiare la directory:

   cd /etc/ssl/certs

3. Controllare se il certificato della CA radice Symantec è presente:

   ls VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem

   • Se il certificato della CA radice Symantec non è reperibile, eseguire il comando seguente per scaricare il file. Verificare la presenza di eventuali errori e seguire le azioni consigliate per gli errori di rete.

     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. Controllare se il certificato della CA radice Baltimore è presente:

   ls Baltimore_CyberTrust_Root.pem

   • Se il certificato della CA radice Baltimore non è reperibile, eseguire questo comando per scaricare il certificato:

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

5. Controllare se il certificato DigiCert_Global_Root_CA è presente:

   ls DigiCert_Global_Root_CA.pem

   • Se il certificato DigiCert_Global_Root_CA non è reperibile, eseguire i comandi seguenti per scaricare il certificato:

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

6. Per aggiornare i codici hash dell'oggetto per i certificati appena scaricati, eseguire lo script rehash:

   c_rehash

7. Per verificare se i codici hash dell'oggetto come symlink sono stati creati per i certificati, eseguire questi comandi:

   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. Creare una copia del file VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem con nome file b204d74a.0:

   cp VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem b204d74a.0

9. Creare una copia del file Baltimore_CyberTrust_Root.pem con nome file 653b494a.0:

   cp Baltimore_CyberTrust_Root.pem 653b494a.0

10. Creare una copia del file DigiCert_Global_Root_CA.pem con nome file 3513523f.0:

    cp DigiCert_Global_Root_CA.pem 3513523f.0

11. Verificare che i file siano presenti:

    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
    

URL o intervalli IP in uscita (codice di errore 151037 o 151072)

Per il funzionamento della replica di Site Recovery, è necessaria la connettività in uscita dalla VM a URL specifici. Se la macchina virtuale è protetta da un firewall o usa regole di gruppi di sicurezza di rete (NGS) per controllare la connettività in uscita, potrebbe verificarsi uno di questi problemi. Anche se rimane disponibile il supporto all'accesso in uscita tramite URL, l'uso di un elenco di intervalli IP autorizzati non è più supportato.

Possibili cause

• Non è possibile stabilire una connessione agli endpoint di Site Recovery a causa di un errore di risoluzione DNS (Domain Name System).
• Questo problema è più comune durante la riprotezione dopo il failover della macchina virtuale, quando il server DNS non è raggiungibile dall'area di ripristino di emergenza.

Risolvere il problema

Se si usa un DNS personalizzato, assicurarsi che il server DNS sia accessibile dall'area di ripristino di emergenza.

Per verificare se la VM usa un'impostazione DNS personalizzata:

1. Aprire Macchine virtuali e selezionare la VM.
2. Passare alle Impostazioni delle VM e selezionare Rete.
3. In Rete virtuale/subnet selezionare il collegamento per aprire la pagina delle risorse della rete virtuale.
4. Passare a Impostazioni e selezionare Server DNS.

Provare ad accedere al server DNS dalla macchina virtuale. Se il server DNS non è accessibile, renderlo accessibile effettuando il failover del server DNS o creando la linea del sito tra la rete di ripristino di emergenza e il DNS.

Problema 2: La configurazione di Site Recovery non è riuscita (151196)

Possibile causa

Non è possibile stabilire una connessione agli endpoint IP4 di identità e autenticazione di Microsoft 365.

Risolvere il problema

Azure Site Recovery deve accedere agli intervalli IP di Microsoft 365 per l'autenticazione. Se si usano regole del gruppo di sicurezza di rete (NSG) di Azure o un proxy firewall per controllare la connettività di rete in uscita nella VM, assicurarsi di usare la regola NSG basata sul tag del servizio Microsoft Entra per consentire l'accesso a Microsoft Entra ID. Le regole NSG basate sugli indirizzi IP non sono più supportate.

Problema 3: La configurazione di Site Recovery non è riuscita (151197)

Possibile causa

Non è possibile stabilire la connessione agli endpoint del servizio Azure Site Recovery.

Risolvere il problema

Se si usano regole del gruppo di sicurezza di rete (NSG) di Azure o un proxy firewall per controllare la connettività di rete in uscita nella VM, assicurarsi di usare i tag del servizio. L'uso di un elenco di indirizzi IP autorizzati tramite NSG per Azure Site Recovery non è più supportato.

Problema 4: La replica non riesce quando il traffico di rete usa il server proxy locale (151072)

Possibile causa

Le impostazioni proxy personalizzate non sono valide e l'agente del servizio di mobilità non ha rilevato automaticamente le impostazioni proxy da Internet Explorer.

Risolvere il problema

1. L'agente del servizio di mobilità rileva le impostazioni proxy da Internet Explorer in Windows e /etc/environment in Linux.

2. Se si preferisce impostare il proxy solo per il servizio di mobilità, è possibile fornire i dettagli del proxy in ProxyInfo.conf, disponibile in:

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

3. Il file ProxyInfo.conf deve includere le impostazioni proxy nel formato INI seguente.

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

Ulteriori informazioni

Per specificare gli URL necessari o gli intervalli IP necessari, seguire le indicazioni riportate in Informazioni sulla rete in Azure per la replica di Azure.

Disco non trovato nella VM (codice di errore 150039)

È necessario inizializzare un nuovo disco collegato alla VM. Se il disco non viene trovato, viene visualizzato il messaggio seguente:

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.

Possibili cause

• Alla VM è stato collegato un nuovo disco dati che però non è stato inizializzato.
• Il disco dati all'interno della VM non segnala il valore LUN (numero di unità logica) corretto con il quale il disco è stato collegato alla VM.

Risolvere il problema

Assicurarsi che i dischi dati siano inizializzati e quindi provare a eseguire di nuovo l'operazione.

• Windows: Collegare e inizializzare un nuovo disco.
• Linux: Inizializzare un nuovo disco dati in Linux.

Se il problema persiste, contattare il supporto tecnico.

Più dischi disponibili per la protezione (codice di errore 153039)

Possibili cause

• Uno o più dischi sono stati aggiunti di recente alla macchina virtuale dopo la protezione.
• Uno o più dischi sono stati inizializzati dopo la protezione della macchina virtuale.

Risolvere il problema

Per rendere di nuovo integro lo stato di replica della VM, è possibile scegliere di proteggere i dischi o di ignorare l'avviso.

Per proteggere i dischi

1. Passare a Elementi replicati>Nome della VM>Dischi.

2. Selezionare il disco non protetto e quindi selezionare Abilita replica:

   

Per ignorare l'avviso

1. Passare a Elementi replicati>Nome della VM.

2. Selezionare l'avviso nella sezione Panoramica e quindi selezionare OK.

   

Rimozione della VM dall'insieme di credenziali completata con informazioni (codice di errore 150225)

Quando Site Recovery protegge la macchina virtuale, crea collegamenti nella macchina virtuale di origine. Quando si rimuove la protezione o si disabilita la replica, Site Recovery rimuove questi collegamenti come parte del processo di pulizia. Se la macchina virtuale ha un blocco delle risorse, il processo di pulizia viene completato con le informazioni. Secondo le informazioni, la macchina virtuale è stata rimossa dall'insieme di credenziali di Servizi di ripristino, ma non è stato possibile pulire alcuni collegamenti non aggiornati nel computer di origine.

È possibile ignorare questo avviso se non si intende più proteggere questa macchina virtuale. Tuttavia, se è necessario proteggere questa macchina virtuale in un secondo momento, seguire la procedura descritta in questa sezione per pulire i collegamenti.

Risolvere il problema

1. Rimuovere il blocco dalla VM o dal gruppo di risorse della VM. Nell'immagine seguente, ad esempio, il blocco delle risorse nella VM denominata MoveDemo deve essere eliminato:

   

2. Scaricare lo script per rimuovere una configurazione di Site Recovery non aggiornata.

3. Eseguire lo script Cleanup-stale-asr-config-Azure-VM.ps1. Specificare l'ID sottoscrizione, il Gruppo di risorse della VM e il Nome della VM come parametri.

4. Se vengono richieste le credenziali di Azure, specificarle. Verificare quindi che lo script venga eseguito senza errori.

Replica non abilitata nella VM con risorse non aggiornate (codice di errore 150226)

Possibili cause

La macchina virtuale ha una configurazione non aggiornata rispetto alla protezione di Site Recovery precedente.

Una configurazione non aggiornata può verificarsi in una VM di Azure se è stata abilitata la replica per la VM di Azure usando Site Recovery, e quindi:

• La replica è stata disabilitata, ma la VM di origine ha un blocco delle risorse.
• È stato eliminato l'insieme di credenziali di Site Recovery senza disabilitare in modo esplicito la replica nella VM.
• È stato eliminato il gruppo di risorse contenente l'insieme di credenziali di Site Recovery senza disabilitare in modo esplicito la replica nella VM.

Risolvere il problema

1. Rimuovere il blocco dalla VM o dal gruppo di risorse della VM. Nell'immagine seguente, ad esempio, il blocco delle risorse nella VM denominata MoveDemo deve essere eliminato:

   

2. Scaricare lo script per rimuovere una configurazione di Site Recovery non aggiornata.

3. Eseguire lo script Cleanup-stale-asr-config-Azure-VM.ps1. Specificare l'ID sottoscrizione, il Gruppo di risorse della VM e il Nome della VM come parametri.

4. Se vengono richieste le credenziali di Azure, specificarle. Verificare quindi che lo script venga eseguito senza errori.

Non è possibile selezionare una VM o un gruppo di risorse nel processo di abilitazione della replica

Problema 1: Il gruppo di risorse e la VM di origine si trovano in posizioni diverse

Attualmente, Site Recovery richiede che il gruppo di risorse dell'area di origine e le macchine virtuali si trovino nella stessa posizione. In caso contrario, non sarà possibile trovare la macchina virtuale o il gruppo di risorse quando si tenta di applicare la protezione.

Come soluzione alternativa, è possibile abilitare la replica dalla VM anziché dall'insieme di credenziali di Servizi di ripristino. Passare a VM di origine>Proprietà>Ripristino di emergenza e abilitare la replica.

Problema 2: Il gruppo di risorse non fa parte della sottoscrizione selezionata

Potrebbe non essere possibile trovare il gruppo di risorse durante il periodo di protezione se il gruppo di risorse non fa parte della sottoscrizione selezionata. Assicurarsi che il gruppo di risorse appartenga alla sottoscrizione in uso.

Problema 3: Configurazione non aggiornata

Se nella VM che si vuole abilitare per la replica esiste una configurazione di Site Recovery non aggiornata, la VM di Azure potrebbe non essere visualizzata. Questa condizione può verificarsi se è stata abilitata la replica per la VM di Azure usando Site Recovery, e quindi:

• È stato eliminato l'insieme di credenziali di Site Recovery senza disabilitare in modo esplicito la replica nella VM.
• È stato eliminato il gruppo di risorse contenente l'insieme di credenziali di Site Recovery senza disabilitare in modo esplicito la replica nella VM.
• La replica è stata disabilitata, ma la VM di origine ha un blocco delle risorse.

Risolvere il problema

1. Rimuovere il blocco, se presente, dalla VM o dal gruppo di risorse della VM. Nell'immagine seguente, ad esempio, il blocco delle risorse nella VM denominata MoveDemo deve essere eliminato:

   

2. Scaricare lo script per rimuovere una configurazione di Site Recovery non aggiornata.

3. Eseguire lo script Cleanup-stale-asr-config-Azure-VM.ps1. Specificare l'ID sottoscrizione, il Gruppo di risorse della VM e il Nome della VM come parametri.

4. Se vengono richieste le credenziali di Azure, specificarle. Verificare quindi che lo script venga eseguito senza errori.

Impossibile selezionare una VM per la protezione

Possibile causa

Un'estensione installata nella macchina virtuale si trova in stato non riuscito o non risponde

Risolvere il problema

Passare a Macchine virtuali>Impostazioni>Estensioni e verificare la presenza di estensioni in uno stato non riuscito. Disinstallare qualsiasi estensione non riuscita e riprovare a proteggere la macchina virtuale.

Lo stato di provisioning della VM non è valido (codice di errore 150019)

Per abilitare la replica nella VM, lo stato di provisioning deve essere Riuscito. Per controllare lo stato di provisioning, seguire questa procedura:

1. Nel portale di Azure selezionare Esplora risorse da Tutti i servizi.
2. Espandere l'elenco Sottoscrizioni e selezionare la sottoscrizione.
3. Espandere l'elenco Gruppi di risorse e selezionare il gruppo di risorse della VM.
4. Espandere l'elenco Risorse e selezionare la VM.
5. Controllare il campo provisioningState nella visualizzazione dell'istanza sul lato destro.

Risolvere il problema

• Se provisioningState è Non riuscito, contattare il supporto specificando i dettagli necessari per risolvere il problema.
• Se provisioningState è In aggiornamento, potrebbe essere in corso la distribuzione di un'altra estensione. Verificare se sono presenti operazioni in corso nella VM, attenderne il completamento e quindi provare a eseguire di nuovo il processo di Site Recovery non riuscito per abilitare la replica.

Impossibile selezionare la VM di destinazione

Problema 1: La VM è collegata a una rete che è già mappata a una rete di destinazione

Durante la configurazione del ripristino di emergenza, se la VM di origine fa parte di una rete virtuale e un'altra VM della stessa rete virtuale è già mappata con una rete nel gruppo di risorse di destinazione, l'elenco a discesa della selezione di rete non è disponibile (viene visualizzata in grigio) per impostazione predefinita.

Problema 2: La VM è stata protetta in precedenza e quindi è stata disabilitata la replica

La disabilitazione della replica di una VM non elimina il mapping di rete. Il mapping deve essere eliminato dall'insieme di credenziali di Servizi di ripristino in cui è stata protetta la VM. Selezionare l'insieme di credenziali di Servizi di ripristino e passare a Gestisci>Infrastruttura di Site Recovery>Per macchine virtuali di Azure>Mapping di rete.

La rete di destinazione che è stata impostata durante la configurazione del ripristino di emergenza può essere modificata dopo la configurazione iniziale, in seguito alla protezione della VM. Per Modificare il mapping di rete, selezionare il nome di rete:

COM+ o Servizio Copia Shadow del volume (codice di errore 151025)

Quando si verifica l'errore COM+ o Servizio Copia Shadow del volume, viene visualizzato il messaggio seguente:

Site Recovery extension failed to install.

Possibili cause

• Il servizio Applicazione di sistema COM+ è disabilitato.
• Il Servizio Copia Shadow del volume è disabilitato.

Risolvere il problema

Impostare Applicazione di sistema COM+ e Servizio Copia Shadow del volume sulla modalità di avvio automatico o manuale.

1. Aprire la console dei servizi in Windows.

2. Assicurarsi che Applicazione di sistema COM+ e Servizio Copia Shadow del volume non siano impostati su Disabilitato come Tipo di avvio.

   

Dimensioni del disco gestito non supportate (codice di errore 150172)

Quando si verifica questo errore, viene visualizzato il messaggio seguente:

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.

Possibile causa

Le dimensioni del disco sono inferiori a quelle supportate, ovvero 1024 MB.

Risolvere il problema

Assicurarsi che le dimensioni del disco siano comprese nell'intervallo di dimensioni supportato e quindi ripetere l'operazione.

Protezione non abilitata quando GRUB usa il nome del dispositivo (codice di errore 151126)

Possibili cause

I file di configurazione Grand Unified Bootloader (GRUB) di Linux (/boot/grub/menu.lst, /boot/grub/grub.cfg, /boot/grub2/grub.cfg o /etc/default/grub) potrebbero specificare i nomi effettivi dei dispositivi anziché i relativi valori UUID (identificatore univoco universale) per i parametri root e resume. Site Recovery richiede gli UUID perché i nomi dei dispositivi possono cambiare. Al riavvio, una VM potrebbe non avere lo stesso nome in caso di failover, causando problemi.

Gli esempi seguenti sono righe di file GRUB in cui vengono visualizzati i nomi dei dispositivi anziché gli UUID richiesti:

• File /boot/grub2/grub.cfg:

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

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

Risolvere il problema

Sostituire ogni nome del dispositivo con l'UUID corrispondente:

1. Individuare l'UUID del dispositivo eseguendo il comando blkid <device name>. Ad esempio:

   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. Sostituire il nome del dispositivo con il relativo UUID nei formati root=UUID=<UUID> e resume=UUID=<UUID>. Ad esempio, dopo la sostituzione, la riga di /boot/grub/menu.lst sarà simile alla riga seguente:

   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. Riprovare ad abilitare la protezione.

Protezione non riuscita perché il dispositivo GRUB non esiste (codice di errore 151124)

Possibile causa

I file di configurazione GRUB (/boot/grub/menu.lst, /boot/grub/grub.cfg, /boot/grub2/grub.cfg o /etc/default/grub) potrebbero contenere i parametri rd.lvm.lv o rd_LVM_LV. Questi parametri identificano i dispositivi LVM (Logical Volume Manager) da individuare in fase di avvio. Se questi dispositivi LVM non esistono, il sistema protetto stesso non verrà avviato e verrà bloccato nel processo di avvio. Lo stesso problema verrà visualizzato anche con la VM di failover. Di seguito sono riportati alcuni esempi:

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

• File: /etc/default/grub in RHEL7:

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

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

In ogni esempio GRUB deve rilevare due dispositivi LVM con i nomi root e swap dal gruppo di volumi rootvg.

Risolvere il problema

Se il dispositivo LVM non esiste, crearlo o rimuovere i parametri corrispondenti dai file di configurazione GRUB. Riprovare quindi ad abilitare la protezione.

Aggiornamento del servizio di mobilità completato con avvisi (codice di errore 151083)

Il servizio di mobilità di Site Recovery ha molti componenti, uno dei quali è denominato driver di filtro. Il driver di filtro viene caricato nella memoria di sistema solo durante un riavvio del sistema. Ogni volta che un aggiornamento del servizio di mobilità include modifiche al driver di filtro, il computer viene aggiornato, ma viene comunque visualizzato un avviso che indica che alcune correzioni richiedono un riavvio. Viene visualizzato l'avviso perché le correzioni del driver di filtro possono avere effetto solo quando viene caricato il nuovo driver di filtro, il che si verifica solo durante un riavvio.

Protezione non abilitata se esiste un disco gestito di replica

Questo errore si verifica quando il disco gestito di replica esiste già, senza i tag previsti, nel gruppo di risorse di destinazione.

Possibile causa

Questo problema può verificarsi se la macchina virtuale è stata precedentemente protetta e, quando la replica è stata disabilitata, il disco di replica non è stato rimosso.

Risolvere il problema

Eliminare il disco di replica identificato nel messaggio di errore e ripetere il processo di protezione non riuscito.

L'abilitazione della protezione non è riuscita perché il programma di installazione non riesce a trovare il disco radice (codice di errore 151137)

Questo errore si verifica per i computer Linux in cui il disco del sistema operativo viene crittografato con Crittografia dischi di Azure. Si tratta di un problema valido solo nella versione 9.35 di Agente.

Possibili cause

Il programma di installazione non riesce a trovare il disco radice che ospita il file system radice.

Risolvere il problema

Eseguire la procedura seguente per risolvere il problema.

1. Trovare i bit dell'agente nella directory /var/lib/waagent nei computer RHEL usando il comando seguente:
   

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

   Output previsto:

   /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. Creare una nuova directory e modificare la directory in quella appena creata.

3. Estrarre qui il file di Agente trovato nel primo passaggio, usando il comando seguente:

   tar -xf <Tar Ball File>

4. Aprire il file prereq_check_installer.json ed eliminare le righe seguenti. Dopodiché salvare il file.

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

5. Richiamare il programma di installazione usando il comando:
   

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

6. Se il programma di installazione ha esito positivo, ripetere il processo di abilitazione della replica.

Risolvere i problemi e gestire le modifiche temporali nei server replicati

Questo errore si verifica quando l'orario del computer di origine si sposta in avanti e poi torna indietro in breve tempo per correggere la modifica. È possibile che non si noti la modifica perché l'orario viene corretto molto rapidamente.

Procedura di correzione: per risolvere questo problema, attendere che l'orario del sistema attraversi l'orario futuro asimmetrico. Un'altra opzione consiste nel disabilitare e abilitare di nuovo la replica, il che è possibile solo per la replica in avanti (dati replicati dall'area primaria a quella secondaria) e non è applicabile per la replica inversa (dati replicati dall'area secondaria a quella primaria).

Passaggi successivi

Replica delle macchine virtuali di Azure in un'altra area di Azure.