Azure Migrate: Validation failed durante la discovery di un cluster Hyper-V
Troubleshooting di un errore Access is denied durante la discovery Azure Migrate su cluster Hyper-V e risoluzione tramite configurazione WSMan MaxEnvelopeSizeKb.
Ultimo aggiornamento il
Scenario
Il cliente possiede un cluster Hyper-V a due nodi basato su Windows Server 2019, con storage condiviso di tipo SAN.
Il cluster risultava aggiornato all’ultimo update disponibile e non erano presenti errori significativi nei log del cluster.
L’attività prevedeva l’installazione di Azure Migrate per eseguire la discovery dell’intero ambiente Hyper-V, con l’obiettivo di valutare una possibile migrazione verso Microsoft Azure.
Figura 1: schema funzionale di Azure Migrate Discovery.
Tutti i prerequisiti necessari alla funzionalità di discovery sono stati verificati e soddisfatti secondo la documentazione ufficiale Microsoft.
Sul sito ICT Power è disponibile diverso materiale che spiega nel dettaglio il funzionamento di Azure Migrate. In questo articolo mi concentrerò sul problema riscontrato e sulla soluzione messa in campo.
Configurazione dell’appliance Azure Migrate
Abbiamo importato l’appliance di Azure Migrate all’interno di un host Hyper-V, senza renderla parte del cluster.
Dopo esserci connessi tramite RDP alla macchina virtuale, abbiamo avviato il processo di discovery utilizzando la Web Application fornita dall’appliance, partendo dallo Step 1, dove vengono verificati alcuni prerequisiti essenziali, tra cui:
- connettività verso Azure;
- sincronizzazione dell’orario;
- registrazione dell’appliance;
- aggiornamento della Web App.
Figura 2: verifica dei prerequisiti dello Step 1 di Azure Migrate.
Come si può vedere dalla figura, l’intero primo step è andato a buon fine.
Durante il secondo step abbiamo aggiunto un set di credenziali valido per la connessione al cluster Hyper-V, denominato CRED01.
Sono state inoltre aperte tutte le porte di rete necessarie alla comunicazione tra Azure Migrate e il cluster Hyper-V.
Successivamente, seguendo l’ordine di inserimento proposto dall’appliance, abbiamo aggiunto il nome FQDN del cluster Hyper-V e associato il set di credenziali specificato.
A questo punto il wizard ha restituito un generico errore Validation failed nella colonna Status.
Figura 3: errore presentato durante l’aggiunta del cluster Hyper-V.
Abbiamo provato anche ad aggiungere singolarmente i nodi del cluster, ma il comportamento non è cambiato.
Figura 4: dettaglio dell’errore restituito in fase di discovery da Azure Migrate.
Il dettaglio dell’errore era poco esplicativo:
Access is denied.Questa situazione ha richiesto un approfondimento sul sistema con cui Azure Migrate genera i log e sul percorso in cui vengono conservati.
Analisi dei log
Abbiamo verificato i log all’interno del seguente percorso presente nella VM dedicata ad Azure Migrate:
C:\ProgramData\Microsoft Azure\Logs\ConfigManagerAll’interno della cartella abbiamo aperto il file:
ApplianceOnboarding-Portal-<Current Date>Nel file di log abbiamo individuato l’errore riportato di seguito.
Figura 5: dettaglio dell’errore presente nel log di Azure Migrate.
Il messaggio rilevante era il seguente:
"Message": "Hit issue while fetching host instances.
Query: SELECT * FROM Win32_ComputerSystem
Exception details:
Microsoft.Management.Infrastructure.CimException:
The WS-Management service cannot process the request because the XML is invalid."Prima di procedere con ulteriori tentativi abbiamo verificato alcuni aspetti di base.
Verifiche preliminari
Verifica porte WinRM
Abbiamo verificato l’apertura delle porte WinRM, in particolare la porta TCP 5985, dalla VM Azure Migrate verso gli host Hyper-V.
Figura 6: verifica apertura porte WinRM dalla VM Azure Migrate verso gli host Hyper-V.
Verifica collegamento WinRM
Abbiamo verificato anche la connessione WinRM dalla VM Azure Migrate ai nodi del cluster Hyper-V.
Figura 7: verifica collegamento WinRM dalla VM Azure Migrate ai nodi del cluster Hyper-V.
Verifica DNS
Infine, abbiamo verificato la corretta risoluzione DNS dalla VM Azure Migrate.
Figura 8: verifica risoluzione DNS dalla VM Azure Migrate.
A seguito di queste verifiche abbiamo aperto un ticket e iniziato una ricerca più approfondita per comprendere la causa del problema.
Soluzione
Dopo il tempo necessario a un corretto troubleshooting, insieme a Sami Hasine, abbiamo recuperato una soluzione già utilizzata in passato su Hyper-V per correggere un problema relativo a WinRM.
La modifica consiste nell’aumentare il valore del parametro WS-Management envelope size su tutti i nodi del cluster Hyper-V.
Il comando PowerShell utilizzato è il seguente:
Set-Item -Path WSMan:\localhost\MaxEnvelopeSizeKb -Value 4096Il valore di default era 500, come mostrato nella figura seguente.
Figura 9: comando eseguito su entrambi gli host Hyper-V per modificare il valore WSMan MaxEnvelopeSizeKb.
Dopo aver applicato la modifica su entrambi gli host Hyper-V, abbiamo lanciato nuovamente la discovery.
Figura 10: verifica dell’avvenuta risoluzione della problematica a seguito della modifica del parametro WSMan.
La discovery è stata completata correttamente.
Conclusioni
A seguito di questa modifica siamo stati in grado di eseguire la discovery di tutti i server parte del cluster Hyper-V oggetto dell’attività.
Ho segnalato l’accaduto a Microsoft, con l’auspicio che questa casistica venga aggiunta in futuro tra le FAQ o nella documentazione di troubleshooting.
L’obiettivo di questa guida, in pieno spirito ICT Power, è condividere esperienza dal campo e ridurre il tempo necessario alla risoluzione di problemi simili.
Chi lavora su progetti reali sa bene che non sempre tutto procede come da manuale: documentare questi casi può fare la differenza.