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.

Il failover non è riuscito con errore ID 28031

Site Recovery non è riuscito a creare un'operazione di failover sulla macchina virtuale 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 effettuare il failover delle macchine virtuali delle 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 passando alle impostazioni Calcolo e rete della macchina virtuale e ritentando il failover.

  • Nella sottoscrizione esiste 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.

Il failover non è riuscito con errore ID 28092

Site Recovery non è riuscito a creare un'interfaccia di rete per il failover della macchina virtuale. 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.

Il failover non è riuscito con errore ID 70038

Site Recovery non è riuscito a creare un'operazione di failover sulla macchina virtuale classica 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 Calcolo e rete della macchina virtuale o modificare l'impostazione per una rete virtuale che esiste già, quindi riprovare a eseguire il failover.

Il failover non è riuscito con errore ID 170010

Site Recovery non è riuscito a creare un'operazione di failover sulla macchina virtuale 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 non idratazione, lo script genererà il risultato indicante che questo sistema soddisfa il requisito di non attivazione. In questo caso, tutti i driver e i servizi hanno lo stato richiesto da Azure e l'idratazione della macchina virtuale non è necessaria.

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

    .\Script-no-hydration.ps1 -set

    In questo modo si convertirà il tipo di avvio automatico dei driver e si otterrà 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.
    

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 su una macchina virtuale in cui è stato eseguito il failover, il pulsante Connetti risulta disabilitato e non si è connessi ad Azure tramite una connessione di Ciclo di lavorazione espresso o VPN da sito a sito, allora:

  1. Andare a Macchina virtuale > Rete e fare clic sul nome dell'interfaccia di rete richiesta. Screenshot mostra la pagina rete per una macchina virtuale con il nome dell'interfaccia di rete selezionato.
  2. Passare a Configurazioni IP e quindi fare clic sul campo del nome della configurazione IP richiesta. Screenshot mostra la pagina configurazioni I P per l'interfaccia di rete con il nome configurazione i P selezionato.
  3. Per abilitare l'indirizzo IP pubblico, fare clic su 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 e quindi fare clic su OK.
  6. Per salvare le modifiche apportate, fare clic su Salva.
  7. Chiudere i pannelli e passare alla sezione Panoramica della macchina virtuale per connettersi o stabilire la connessione RDP.

La connessione a RDP/SSH non è riuscita - Pulsante di connessione alla macchina virtuale 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 effettuare il failover a un punto di ripristino meno recente.

  2. Se l'applicazione all'interno della macchina virtuale non si avvia, provare a effettuare il failover a 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 possa essere aggiunta allo stesso dominio in cui è previsto che la macchina virtuale con failover venga avviata.

    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 tramite RDP ma non è possibile 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
    
  • 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 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 ad 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 riproteggere 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 server 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.

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.
        Oppure
      • 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.