Risolvere gli errori durante il failover di un computer fisico o di una macchina virtuale VMware in Azure

Attenzione

Questo articolo fa riferimento a CentOS, una distribuzione Linux vicina allo stato end of life (EOL). Prendere in considerazione l'uso e la pianificazione di conseguenza. Per altre informazioni, vedere le linee guida per la fine della vita di CentOS.

Durante il failover di una macchina virtuale in Azure è possibile che l'utente riceva uno dei seguenti errori. Per risolvere i problemi, usare i passaggi descritti per ogni condizione di errore.

Il failover non è riuscito con errore ID 28031

Site Recovery non è riuscito a creare una macchina virtuale di cui è stato eseguito il failover in Azure. Questo può verificarsi a causa di uno dei motivi seguenti:

  • Non è disponibile una quota sufficiente per creare la macchina virtuale: è possibile controllare la quota disponibile passando a Sottoscrizione -> Utilizzo e quote. È possibile aprire una nuova richiesta di supporto per aumentare la quota.

  • Si sta tentando di eseguire il failover di macchine virtuali di famiglie di dimensioni diverse nello stesso set di disponibilità. Assicurarsi di aver scelto la stessa famiglia di dimensioni per tutte le macchine virtuali nello stesso set di disponibilità. Modificare le dimensioni passando a Impostazioni di calcolo della macchina virtuale e quindi ripetere il failover.

  • Esiste un criterio per la sottoscrizione che impedisce la creazione di una macchina virtuale. Modificare i criteri per consentire la creazione di una macchina virtuale, quindi ripetere il failover.

Il failover non è riuscito con errore ID 28092

Site Recovery non è riuscito a creare un'interfaccia di rete per la macchina virtuale di cui è stato eseguito il failover. Assicurarsi di disporre di una quota sufficiente per creare interfacce di rete nella sottoscrizione. È possibile controllare la quota disponibile passando a Sottoscrizione -> Utilizzo e quote. È possibile aprire una nuova richiesta di supporto per aumentare la quota. Se si dispone di una quota sufficiente, potrebbe trattarsi di un problema intermittente, riprovare. Se il problema persiste anche dopo vari tentativi, lasciare un commento alla fine di questo documento.

Il failover non è riuscito con errore ID 70038

Site Recovery non è riuscito a creare una macchina virtuale classica di cui è stato eseguito il failover in Azure. Questo può verificarsi perché:

  • Non esiste una delle risorse, ad esempio una rete virtuale necessaria per la macchina virtuale da creare. Creare la rete virtuale come specificato in Impostazioni di rete della macchina virtuale o modificare l'impostazione in una rete virtuale già esistente e quindi ripetere il failover.

Il failover non è riuscito con errore ID 170010

Site Recovery non è riuscito a creare una macchina virtuale di cui è stato eseguito il failover in Azure. Questa condizione potrebbe essersi verificata perché un'attività di idratazione interna non è riuscita per la macchina virtuale locale.

Per visualizzare tutte le macchine in Azure, l'ambiente Azure richiede che alcuni driver siano in stato di esecuzione avvio e che servizi come DHCP siano nello stato di avvio automatico. Di conseguenza, l'attività di idratazione, al momento del failover, converte il tipo di driver atapi, intelide, storflt, vmbus, e storvsc in esecuzione avvio. Converte anche il tipo di avvio di alcuni servizi, ad esempio DHCP in avvio automatico. Questa attività può non essere eseguita correttamente a causa di problemi specifici nell'ambiente.

Per modificare manualmente il tipo di avvio dei driver per il sistema operativo guest Windows, seguire la procedura seguente:

  1. Scaricare lo script no-hydration ed eseguirlo nel modo seguente. Questo script verifica se è necessario eseguire l'idratazione della macchina virtuale.

    .\Script-no-hydration.ps1

    Se è necessaria, genera il risultato seguente:

    REGISTRY::HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\storvsc           start =  3 expected value =  0
    
    This system doesn't meet no-hydration requirement.
    

    Nel caso in cui la macchina virtuale soddisfi i requisiti di assenza di idratazione, lo script restituisce il risultato "Questo sistema soddisfa i requisiti di assenza di idratazione". In questo caso, tutti i driver e i servizi si trovano nello stato richiesto da Azure e l'idratazione nella macchina virtuale non è necessaria.

  2. Eseguire lo script no-hydration-set come indicato di seguito se la macchina virtuale non soddisfa i requisiti di nessuna idratazione.

    .\Script-no-hydration.ps1 -set

    In questo modo viene convertito il tipo di avvio dei driver e il risultato sarà simile al seguente:

    REGISTRY::HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\storvsc           start =  3 expected value =  0
    
    Updating registry:  REGISTRY::HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\storvsc   start =  0
    
    This system is now no-hydration compatible.
    

Failover non riuscito con un errore che indica che gli indirizzi IP di replica per la scheda di rete della macchina virtuale non sono validi

Il failover di test o l'operazione di failover può non riuscire per un computer con l'errore "Uno o più indirizzi IP di replica per la scheda di rete della macchina virtuale non è valido", se non è stata eseguita una corretta pulizia di un'operazione di failover di test precedente. A causa di questo, il computer di test potrebbe essere ancora presente nell'ambiente Azure e potrebbe usare lo stesso indirizzo IP. Fa sì che la configurazione di destinazione della macchina virtuale diventi critica.

Per risolvere questo problema, assicurarsi che sia stata eseguita una pulizia completa del failover di test, in modo che l'operazione di failover o di failover di test abbia esito positivo.

Impossibile connettersi o stabilire una connessione RDP/SSH alla macchina virtuale con failover perché il pulsante di connessione è disabilitato nella macchina virtuale

Per istruzioni dettagliate sulla risoluzione dei problemi relativi a RDP, vedere la documentazione qui.

Per istruzioni dettagliate sulla risoluzione dei problemi relativi a SSH, vedere la documentazione qui.

Se il pulsante Connessione nella macchina virtuale di cui è stato eseguito il failover in Azure è disattivato e non si è connessi ad Azure tramite una connessione ExpressRoute o VPN da sito a sito,

  1. Andare a Macchina virtuale>Rete e fare clic sul nome dell'interfaccia di rete richiesta. Screenshot che mostra la pagina Rete per una macchina virtuale con il nome dell'interfaccia di rete selezionato.
  2. Passare a Configurazioni IP, quindi selezionare nel campo nome della configurazione IP richiesta. Screenshot che mostra la pagina configurazioni I P per l'interfaccia di rete con il nome di configurazione I P selezionato.
  3. Per abilitare l'indirizzo IP pubblico, selezionare Abilita. Abilita IP
  4. Fare clic su Configurare le impostazioni necessarie>Crea nuovo.   Crea nuovo
  5. Immettere il nome dell'indirizzo pubblico, scegliere le opzioni predefinite per SKU e assegnazione, quindi selezionare OK.
  6. A questo momento, per salvare le modifiche apportate, selezionare Salva.
  7. Chiudere i pannelli e passare alla sezione Panoramica della macchina virtuale per connettersi o stabilire la connessione RDP.

Non è possibile connettersi/RDP/SSH - Pulsante vm Connessione disponibile

Se su una macchina virtuale in cui è stato eseguito il failover, il pulsante Connetti risulta disponibile (non disabilitato) controllare la Diagnostica di avvio nella macchina virtuale e verificare la presenza di errori come indicato in questo articolo.

  1. Se la macchina virtuale non è stata avviata, provare a eseguire il failover in un punto di ripristino meno recente.

  2. Se l'applicazione all'interno della macchina virtuale non è in esecuzione, provare a eseguire il failover in un punto di ripristino coerente con l'app.

  3. Se la macchina virtuale è aggiunta a un dominio, verificare che il controller di dominio funzioni accuratamente. Questa operazione può essere eseguita seguendo la procedura indicata di seguito:

    a. Creare una nuova macchina virtuale nella stessa rete.

    b. Assicurarsi che sia in grado di aggiungere allo stesso dominio in cui verrà eseguito il failover della macchina virtuale.

    c. Se il controller di dominio non funziona accuratamente, provare ad accedere alla macchina virtuale con failover usando un account amministratore locale.

  4. Se si usa un server DNS personalizzato, assicurarsi che sia raggiungibile. Questa operazione può essere eseguita seguendo la procedura indicata di seguito:

    a. Creare una nuova macchina virtuale nella stessa rete e

    b. Verificare se la macchina virtuale è in grado di procedere alla risoluzione dei nomi tramite il server DNS personalizzato

Nota

Per l'abilitazione di qualsiasi altra impostazione che non sia Diagnostica di avvio è necessario installare l'agente di macchine virtuali di Azure nella macchina virtuale prima del failover.

Non è possibile aprire la console seriale dopo il failover di un computer basato su UEFI in Azure

Se è possibile connettersi al computer usando RDP ma non è possibile aprire la console seriale, seguire questa procedura:

  • Se il sistema operativo del computer è Red Hat o Oracle Linux 7.*/8.0, eseguire il comando seguente nella macchina virtuale di Azure di failover con le autorizzazioni radice. Riavviare la macchina virtuale dopo l'esecuzione del comando.

    grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
    
  • Se il sistema operativo del computer è CentOS 7.*, eseguire il comando seguente nella macchina virtuale di Azure di failover con le autorizzazioni radice. Riavviare la macchina virtuale dopo l'esecuzione del comando.

    grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg
    

Messaggio di arresto imprevisto (ID evento 6008)

Quando si avvia una macchina virtuale Windows dopo il failover, se viene visualizzato un messaggio di arresto imprevisto nella macchina virtuale ripristinata, indica che lo stato di arresto della macchina virtuale non è stato acquisito nel punto di ripristino usato per il failover. Ciò si verifica quando si esegue il ripristino a un punto in cui la macchina virtuale non era stata completamente arrestata.

In genere, non è motivo di preoccupazione e può essere ignorato per i failover non pianificati. In caso di failover pianificato, assicurarsi che la macchina virtuale sia stata arrestata correttamente prima del failover e lasciare un intervallo di tempo sufficiente per consentire l'invio dei dati di replica in sospeso ad Azure. Usare l'opzione Più recente nella schermata Failover in modo che tutti i dati in sospeso in Azure siano elaborati in un punto di recupero, che viene quindi usato per il failover della macchina virtuale.

Non è possibile selezionare l'archivio dati

Questo problema è indicato quando non è possibile visualizzare l'archivio dati nel portale di Azure quando si tenta di riproteggere la macchina virtuale che ha riscontrato un failover. Ciò è dovuto al fatto che la destinazione master non viene riconosciuta come macchina virtuale in vCenters aggiunta ad Azure Site Recovery.

Per altre informazioni sulla riprotezione di una macchina virtuale, vedere Riproteggere ed eseguire il failback di computer in un sito locale dopo il failover in Azure.

Per risolvere il problema:

Creare manualmente la destinazione master nel server vCenter che gestisce il computer di origine. L'archivio dati sarà disponibile dopo le successive operazioni di individuazione e aggiornamento dell'infrastruttura di vCenter.

Nota

Per completare le operazioni di individuazione e aggiornamento dell'infrastruttura possono essere necessari fino a 30 minuti.

La registrazione della destinazione master Linux con CS restituisce un errore TLS 35

La registrazione della destinazione master di Azure Site Recovery con il server di configurazione non riesce a causa dell'abilitazione del proxy autenticato nella destinazione master.

Questo errore è indicato dalle stringhe seguenti nel log di installazione:

RegisterHostStaticInfo encountered exception config/talwrapper.cpp(107)[post] CurlWrapper Post failed : server : 10.38.229.221, port : 443, phpUrl : request_handler.php, secure : true, ignoreCurlPartialError : false with error: [at curlwrapperlib/curlwrapper.cpp:processCurlResponse:231]   failed to post request: (35) - SSL connect error. 

Per risolvere il problema:

  1. Nella macchina virtuale del server di configurazione aprire un prompt dei comandi e verificare le impostazioni del proxy usando i comandi seguenti:

    cat /etc/environment echo $http_proxy echo $https_proxy

  2. Se l'output dei comandi precedenti mostra che le impostazioni di http_proxy o https_proxy sono definite, usare uno dei metodi seguenti per sbloccare le comunicazioni della destinazione master con il server di configurazione:

    • Scaricare lo strumento PsExec.

    • Usare lo strumento per accedere al contesto utente del sistema e determinare se è configurato l'indirizzo del proxy.

    • Se il proxy è configurato, aprire Internet Explorer in un contesto utente di sistema con lo strumento PsExec.

      psexec -s -i "%programfiles%\Internet Explorer\iexplore.exe"

    • Per assicurarsi che il server di destinazione master sia in grado di comunicare con il server di configurazione:

      • Modificare le impostazioni del proxy in Internet Explorer in modo da ignorare l'indirizzo IP del server di destinazione master attraverso il proxy.
        O
      • Disabilitare il proxy nel server di destinazione master.

Passaggi successivi

Per ottenere ulteriore assistenza, pubblicare una query nella pagina delle domande di Domande e risposte Microsoft relativa a Site Recovery oppure lasciare un commento alla fine di questo documento. È disponibile una community attiva in grado di offrire supporto.