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

Attenzione

Questo articolo fa riferimento a CentOS, una distribuzione Linux prossima allo stato EOL (End of Life, fine del ciclo di vita). Prendere in considerazione l'uso e il piano di conseguenza. Per altre informazioni, vedere le linee guida per la fine della vita di CentOS.

Questo articolo descrive come risolvere gli errori comuni in Azure Site Recovery durante la replica e il ripristino di macchine virtuali 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 creare macchine virtuali di Azure nell'area di destinazione che si prevede di usare come area di ripristino di emergenza. La sottoscrizione necessita di una quota sufficiente per creare macchine virtuali 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 macchina virtuale 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 supporto per la fatturazione di Azure per abilitare la sottoscrizione per creare macchine virtuali delle dimensioni necessarie nel percorso di destinazione. Ripetere 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 non tutti i certificati radice attendibili più recenti sono presenti nella macchina virtuale, il processo per abilitare la replica per Site Recovery potrebbe non riuscire. L'autenticazione e l'autorizzazione delle chiamate al servizio Site Recovery dalla macchina virtuale hanno esito negativo senza questi certificati.

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 per l'autorizzazione e l'autenticazione non sono presenti nella macchina virtuale.

Risolvere il problema

Windows

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

  • 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 macchina virtuale.

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

Linux

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

Poiché SU edizione Standard Linux usa collegamenti simbolici o collegamenti simbolici, per mantenere un elenco di certificati, seguire questa procedura:

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

  2. Per modificare la directory, eseguire questo comando:

    cd /etc/ssl/certs

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

    ls VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem

    • Se il certificato CA radice Symantec non viene trovato, 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 CA radice baltimora è presente:

    ls Baltimore_CyberTrust_Root.pem

    • Se il certificato CA radice Baltimore non viene trovato, 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 DigiCert_Global_Root_CA non viene trovato, 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 gli hash dell'oggetto del certificato per i certificati appena scaricati, eseguire lo script rehash:

    c_rehash

  7. Per verificare se gli hash dell'oggetto come collegamenti simbolici 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 corretto funzionamento della replica di Site Recovery, è necessaria la connettività in uscita a URL specifici dalla macchina virtuale. 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 si continua a supportare l'accesso in uscita tramite URL, l'uso di un elenco di intervalli IP consentiti 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 quando è stato eseguito il failover della macchina virtuale, ma il server DNS non è raggiungibile dall'area di ripristino di emergenza.This problem is more common during reprotection when you have failover over the virtual machine but the DNS server is't reachable from the disaster recovery (DR) region.

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 macchina virtuale usa un'impostazione DNS personalizzata:

  1. Aprire Macchine virtuali e selezionare la macchina virtuale.
  2. Passare alla Impostazioni delle macchine virtuali 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 eseguendo il failover del server DNS o creando la riga di sito tra rete di ripristino di emergenza e DNS.

Nota

Se si usano endpoint privati, assicurarsi che le macchine virtuali possano risolvere i record DNS privati.

com-error.

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

Possibile causa

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

Risolvere il problema

Azure Site Recovery ha richiesto l'accesso agli intervalli IP di Microsoft 365 per l'autenticazione. Se si usano regole/proxy del firewall del gruppo di sicurezza di rete di Azure per controllare la connettività di rete in uscita nella macchina virtuale, assicurarsi di usare la regola del gruppo di sicurezza di rete basata su tag del servizio Microsoft Entra per consentire l'accesso a Microsoft Entra ID. Le regole del gruppo di sicurezza di rete basate sugli indirizzi IP non sono più supportate.

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

Possibile causa

Non è possibile stabilire una connessione agli endpoint di servizio di Azure Site Recovery.

Risolvere il problema

Se si usano regole/proxy del firewall del gruppo di sicurezza di rete di Azure per controllare la connettività di rete in uscita nella macchina virtuale, assicurarsi di usare i tag del servizio. Non è più supportato l'uso di un elenco di indirizzi IP consentiti tramite gruppi di sicurezza di rete per Azure Site Recovery.

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 servizio di mobilità non ha rilevato automaticamente le impostazioni proxy da Internet Explorer (Internet Explorer).

Risolvere il problema

  1. L'agente 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 specificare i dettagli del proxy in ProxyInfo.conf all'indirizzo:

    • Linux: /usr/local/InMage/config/
    • Windows: C:\ProgramData\Microsoft Azure Site Recovery\Config
  3. ProxyInfo.conf deve avere le impostazioni proxy nel formato INI seguente.

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

Nota

L'agente servizio di mobilità supporta solo proxy non autenticati.

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 macchina virtuale (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

  • Un nuovo disco dati è stato collegato alla macchina virtuale ma non è stato inizializzato.
  • Il disco dati all'interno della macchina virtuale non segnala correttamente il valore lun (Logical Unit Number) in corrispondenza del quale il disco è stato collegato alla macchina virtuale.

Risolvere il problema

Assicurarsi che i dischi dati siano inizializzati e quindi ripetere l'operazione.

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 macchina virtuale, è possibile scegliere di proteggere i dischi o di ignorare l'avviso.

Per proteggere i dischi

  1. Passare a Elementi>replicati Nome>macchina virtuale Dischi.

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

    Abilitare la replica nei dischi delle macchine virtuali.

Per ignorare l'avviso

  1. Passare a Nome macchina virtuale elementi>replicati.

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

    Ignorare l'avviso del nuovo disco.

Macchina virtuale rimossa 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. Le informazioni dicono che la macchina virtuale è stata rimossa dall'insieme di credenziali di Servizi di ripristino, ma che alcuni dei collegamenti non aggiornati non sono stati puliti 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.

Avviso

Se non si esegue la pulizia:

  • Quando si abilita la replica tramite l'insieme di credenziali di Servizi di ripristino, la macchina virtuale non verrà elencata.
  • Se si tenta di proteggere la macchina virtuale usando la macchina> virtuale Impostazioni> Disaster Recovery, l'operazione avrà esito negativo con il messaggio Replica non può essere abilitata a causa dei collegamenti di risorse non aggiornati esistenti nella macchina virtuale.

Risolvere il problema

Nota

Site Recovery non elimina la macchina virtuale di origine né la influisce in alcun modo durante l'esecuzione di questi passaggi.

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

    Rimuovere il blocco dalla macchina virtuale.

  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 macchina virtuale e il nome della macchina virtuale come parametri.

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

Replica non abilitata nella macchina virtuale con risorse non aggiornati (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 macchina virtuale di Azure se è stata abilitata la replica per la macchina virtuale di Azure usando Site Recovery e quindi:

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

Risolvere il problema

Nota

Site Recovery non elimina la macchina virtuale di origine né la influisce in alcun modo durante l'esecuzione di questi passaggi.

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

    Rimuovere il blocco dalla macchina virtuale.

  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 macchina virtuale e il nome della macchina virtuale come parametri.

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

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

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

Site Recovery richiede attualmente che il gruppo di risorse e le macchine virtuali dell'area di origine si trovano 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 macchina virtuale anziché dall'insieme di credenziali di Servizi di ripristino. Passare a Proprietà>macchina virtuale>di origine 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 al momento della 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

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

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

Risolvere il problema

Nota

Assicurarsi di aggiornare il AzureRM.Resources modulo prima di usare lo script indicato in questa sezione. Site Recovery non elimina la macchina virtuale di origine né la influisce in alcun modo durante l'esecuzione di questi passaggi.

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

    Rimuovere il blocco dalla macchina virtuale.

  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 macchina virtuale e il nome della macchina virtuale come parametri.

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

Impossibile selezionare una macchina virtuale per la protezione

Possibile causa

La macchina virtuale ha un'estensione installata in uno stato non riuscito o non risponde

Risolvere il problema

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

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

Per abilitare la replica nella macchina virtuale, lo stato di provisioning deve essere Completato. Per controllare lo stato di provisioning, seguire questa procedura:

  1. Nella 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 macchina virtuale.
  5. Controllare il campo provisioningState nella visualizzazione dell'istanza sul lato destro.

Risolvere il problema

  • Se provisioningState non è riuscito, contattare il supporto tecnico con i dettagli per la risoluzione dei problemi.
  • Se provisioningState sta aggiornando, potrebbe essere distribuita un'altra estensione. Verificare se sono presenti operazioni in corso nella macchina virtuale, attendere il completamento e quindi ripetere il processo di Site Recovery non riuscito per abilitare la replica.

Impossibile selezionare la macchina virtuale di destinazione

Problema 1: la macchina virtuale è collegata a una rete già mappata a una rete di destinazione

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

Elenco di selezione della rete non disponibile.

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

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

Eliminare il mapping di rete.

La rete di destinazione configurata durante l'installazione del ripristino di emergenza può essere modificata dopo la configurazione iniziale e dopo la protezione della macchina virtuale. Per modificare il mapping di rete, selezionare il nome di rete:

Modificare il mapping di rete.

COM+ o VSS (codice di errore 151025)

Quando si verifica l'errore COM+ o Volume Shadow Copy Service (VSS), 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 l'applicazione di sistema COM+ e il servizio Copia Shadow del volume su modalità di avvio automatica o manuale.

  1. Aprire la console Servizi in Windows.

  2. Assicurarsi che l'applicazione di sistema COM+ e il servizio Copia Shadow del volume non siano impostati su Disabilitato come tipo di avvio.

    Controllare il tipo di avvio di COM più Applicazione di sistema e Servizio Copia Shadow del volume.

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

Il disco è inferiore alle dimensioni supportate di 1024 MB.

Risolvere il problema

Assicurarsi che le dimensioni del disco siano incluse nell'intervallo di dimensioni supportate 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 di Linux Grand Unified Bootloader (GRUB) (/boot/grub/menu.lst, /boot/grub/grub.cfg, /boot/grub2/grub.cfg o /etc/default/grub) potrebbero specificare i nomi effettivi dei dispositivi invece dei valori UUID (Universally Unique Identifier) per i root parametri e resume . Site Recovery richiede UUID perché i nomi dei dispositivi possono cambiare. Al riavvio, una macchina virtuale 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. Trovare 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 da /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. Ripetere 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) possono contenere i rd.lvm.lv parametri 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 macchina virtuale 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 rootvgdi volumi .

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.

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

Il servizio di mobilità di Site Recovery include molti componenti, uno dei quali è denominato driver di filtro. Il driver di filtro viene caricato nella memoria di sistema solo durante il riavvio del sistema. Ogni volta che un aggiornamento 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 essere applicate solo quando viene caricato il nuovo driver di filtro, che si verifica solo durante un riavvio.

Nota

Questo è solo un avviso. La replica esistente continua a funzionare anche dopo l'aggiornamento del nuovo agente. È possibile scegliere di riavviare ogni volta che si desiderano i vantaggi del nuovo driver di filtro, ma il driver di filtro precedente continua a funzionare se non si riavvia.

Oltre al driver di filtro, i vantaggi di eventuali altri miglioramenti e correzioni nell'aggiornamento servizio di mobilità hanno effetto senza richiedere 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 tag previsti, nel gruppo di risorse di destinazione.

Possibile causa

Questo problema può verificarsi se la macchina virtuale è stata protetta in precedenza 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 usando Crittografia dischi di Azure (ADE). Si tratta di un problema valido solo nella versione 9.35 di Agent.

Possibili cause

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

Risolvere il problema

Per risolvere il problema, seguire questa procedura.

  1. Trovare i bit dell'agente nella directory /var/lib/waagent nei computer RHEL e CentOS 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 questa nuova directory.

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

    tar -xf <Tar Ball File>

  4. Aprire il file prereq_check_installer.json ed eliminare le righe seguenti. Salvare il file dopo.

       {
          "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, riprovare a abilitare il processo di replica.

Risolvere i problemi e gestire le modifiche temporali nei server replicati

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

Procedura: per risolvere questo problema, attendere che il tempo di sistema attraversi l'ora futura asimmetrica. Un'altra opzione consiste nel disabilitare e abilitare di nuovo la replica, che è fattibile 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 all'area primaria).

Passaggi successivi

Replicare macchine virtuali di Azure in un'altra area di Azure.