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

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.

Errori di failover

Il failover è fallito con i seguenti errori:

ID errore 28031

Site Recovery non è riuscito a creare una macchina virtuale sottoposta a 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 in Sottoscrizione -> Utilizzo e quote. È possibile aprire una nuova richiesta di supporto per aumentare la quota.

• Si sta tentando di eseguire il failover delle 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à. È possibile modificare le dimensioni andando alle impostazioni Calcolo della macchina virtuale e ritentando il failover.

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

ID errore 28092

Site Recovery non è riuscito a creare un'interfaccia di rete per la macchina virtuale sottoposta a failover. Assicurarsi di disporre di una quota sufficiente per creare interfacce di rete nella sottoscrizione. È possibile controllare la quota disponibile in 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.

ID errore 70038

Site Recovery non è riuscito a creare una macchina virtuale classica sottoposta a 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 nelle impostazioni di rete della macchina virtuale o modificare l'impostazione su una rete virtuale che esiste già, quindi riprovare il failover.

ID errore 170010

Site Recovery non è riuscito a creare una macchina virtuale sottoposta a 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 il requisito di no-hydration, lo script restituirà il risultato "Questo sistema soddisfa questo requisito". In questo caso, tutti i driver e i servizi hanno lo stato richiesto da Azure e non è necessaria l'attivazione della macchina virtuale.

2. Eseguire lo script no-hydration-set come indicato di seguito se la macchina virtuale non soddisfa il requisito di no-hydration.

   .\Script-no-hydration.ps1 -set

   In questo modo si converte il tipo di avvio automatico dei driver e si ottiene un risultato 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 indicante che gli indirizzi IP di replica per la scheda di rete della macchina virtuale non sono validi

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 sono validi", se non è stata eseguita una corretta pulizia di un'operazione di failover di test precedente. Di conseguenza, il computer di test potrebbe essere ancora presente nell'ambiente Azure e usare lo stesso indirizzo IP. Per questo, la configurazione di destinazione della macchina virtuale diventa 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.

Non è possibile connettersi/RDP/SSH

Impossibile connettersi/RDP/SSH a causa degli errori seguenti:

Il pulsante Connetti non è attivo sulla 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 Connetti è disabilitato su una macchina virtuale in cui è stato eseguito il failover e non si è connessi ad Azure tramite una connessione VPN da sito a sito o Express Route, allora:

1. Andare a Macchina virtuale>Rete e fare clic sul nome dell'interfaccia di rete richiesta.
2. Passare a Configurazioni IP e quindi fare clic sul campo del nome della configurazione IP richiesta.
3. Per abilitare l'indirizzo IP pubblico, selezionare Abilita.
4. Fare clic su Configurare le impostazioni necessarie>Crea nuovo.
5. Immettere il nome dell'indirizzo pubblico, scegliere le opzioni predefinite per SKU e assegnazione e quindi fare clic su OK.
6. 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.

Pulsante VMConnect 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 si è avviata, provare a eseguire il failover a un punto di ripristino meno recente.

2. Se l'applicazione all'interno della macchina virtuale non si avvia, provare a eseguire il failover a un punto di ripristino coerente con le 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 possibile l'aggiunta allo stesso dominio in cui è previsto l'avvio della macchina virtuale con failover.

   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

Note

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 tramite RDP ma non aprire la console seriale, attenersi alla procedura seguente:

• 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
  

Messaggio di arresto imprevisto (ID evento 6008)

Quando si esegue l'avvio di una macchina virtuale Windows dopo il failover e si riceve un messaggio di arresto imprevisto nella macchina virtuale ripristinata, significa che non è stato acquisito uno stato di arresto della macchina virtuale nel punto di ripristino usato per il failover. Questo accade quando si effettua il ripristino a un punto in cui la macchina virtuale non è 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 viene segnalato quando non è possibile visualizzare l'archivio dati nel portale di Azure durante il tentativo di proteggere nuovamente la macchina virtuale in cui si è verificato un failover. Questo inconveniente è dovuto al fatto che la destinazione master non viene riconosciuta come macchina virtuale nei vCenter aggiunti 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.

Note

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.
       Oppure
     • Disabilitare il proxy nel server di destinazione master.

Passaggi successivi

• Risoluzione problemi di connessione RDP a una macchina virtuale Windows
• Risoluzione problemi di connessione SSH a una macchina virtuale Linux

Per maggiore assistenza, pubblicare una query nella pagina 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.