• Cloud
• 7 Settembre 2025

Nell’ultimo periodo mi è capitato spesso di utilizzare Azure Migrate per la discovery e migrazione di workload dal mondo On-premises verso il Cloud Microsoft.
Il prodotto è basato su piattaforma Azure e possiede due caratteristiche fondamentali, la componente di Discovery in grado di analizzare infrastruttura Hyper-v e Vmware, fornendo dettagli fondamentali per valutare le isole applicative presenti e capire quale scenario di migrazione sia il migliore e naturalmente la parte di migrazione, attraverso lo stesso motore che muove Azure Site Recovery, consentendo di replicare la macchine in Cloud per poi completare la migrazione quando si è veramente pronti.

Proprio per un cliente qualche settimana fa, io e il mio collega Sami Hasine, abbiamo installato l’appliance Azure Migrate per eseguire la Discovery del suo ambiente basato su Cluster Hyper-v.
Come vedremo nei prossima paragrafi, vi racconterò cosa è andato storto e cosa abbiamo scoperto durante le nostre prove, arrivando ad una soluzione che ad oggi, mentre vi scriviamo, Microsoft non ha ancora inserito nella documentazione del prodotto.

Scenario

Il cliente possiede un cluster Hyper-v a due nodi basato su Windows Server 2019 con storage condiviso di tipo SAN.
Il cluster risulta aggiornato all’ultimo update disponibile e non sono presenti errori di alcun genere nei log del Cluster.

La nostra attività prevedeva di installare Azure Migrate per eseguire la discovery dell’intero ambiente Hyper-v, al fine di valutare la 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 trovate 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.

Cosa è successo

Abbiamo importato l’appliance di Azure Migrate all’interno di un Host Hyper-v senza renderla parte del Cluster.
Ci siamo connessi tramite RDP alla macchina virtuale e abbiamo iniziato il processo di Discovery utilizzando la Web Application fornita, partendo dallo step 1, dove vengono verificati parte dei prerequisiti necessari, come la connettività verso Azure, la sincronizzazione dell’orario e la registrazione con conseguente aggiornamento della Web App.

Figura 2: verifica dei prerequisiti dello Step 1 di Azure Migrate

Come potete vedere dalla Figura 2, 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 aperte tutte le porte di rete necessarie alla comunicazione tra Azure migrate ed il cluster Hyper-v.

Successivamente, seguendo l’ordine di inserimento proposto dall’appliance, abbiamo aggiunto il nome tramite FQDN del cluster Hyper-v e associato il set di credenziali specificato sopra.
A questo punto il wizard ci restituisce un generico “Validation failed” nella colonna status di figura 3

Figura 3: errore presentato durante l’aggiunta del cluster Hyper-v

Come è possibile verificare, sempre dalla figura 3, abbiamo provato ad aggiungere singolarmente i nodi del cluster, ma nulla è cambiato.

Figura 4: dettaglio dell’errore restituito in fase di Discovery da Azure Migrate

Si può notare da figura 4 che l’errore non è molto parlante, anzi.
Questa situazione ha richiesto un grande approfondimento sul sistema con il quale Azure Migrate genera i log e dove questi vengono conservati.

Abbiamo verificato i log all’interno del seguente percorso presente nella VM dedicata ad Azure Migrate: “C:\ProgramData\Microsoft Azure\Logs\ConfigManager” .

Atterrati sulla cartella, abbiamo aperto il file: “ApplianceOnboarding-Portal-<Current Date>”.

All’interno del file di log abbiamo notato l’errore riportato in figura 5:

Figura 5: Dettaglio dell’errore presente nel log di Azure Migrate

“”Message”: “Hit issue while fetching host instances.Query: SELECT * FROM Win32_ComputerSystemException details:\nMicrosoft.Management.Infrastructure.CimException: The WS-Management service cannot process the request because the XML is invalid.”

Prima di procedere con ulteriori tentativi abbiamo verificato le cose più banali, di cui riporto per brevità un elenco:

Verifica apertura porte WinRm (TCP 5985) dalla VM; Azure Migrate verso gli Host Hyper-v:

Figura 6: Verifica apertura porte WinRm (TCP 5985) dalla VM Azure Migrate verso gli Host Hyper-v

Verifica collegamento 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 risoluzione DNS sempre dalla VM Azure Migrate:

Figura 8: Verifica risoluzione DNS dalla VM Azure Migrate

A seguito di questo abbimo aperto un ticket e iniziato una lunga ricerca online, per capire quale potesse essere il problema.

Soluzione

Dopo aver speso il tempo necessario ad un corretto troubleshooting, io e il buon Sami Hasine, tramite il confronto franco e sincero, sale di ogni buona relazione lavorativa, abbiamo trovato una soluzione che qualche tempo a dietro mi era tornata utile, sempre su Hyper-v, per correggere un problema relativo al WinRM sempre su Hyper-v.

Abbiamo combiato, attraverso un comando Powershell il “WS-Management envelope size” su tutti i nodi del cluster Hyper-v.

Set-Item -Path WSMan:\localhost\MaxEnvelopeSizeKb -Value 4096

Il valore di default, come potete vedere da figura 9 è 500:

Figura 9: comando lanciato su entrambi gli Host Hyper-v per modificare il WSman Max Envelop Size

A seguito di questa modifica abbiamo lanciato nuovamente la discovery verificando l’effettiva risoluzione della problematica:

Figura 10: Verifica dell’avvenuta risoluzione della problematica a seguito della modifica del WsMan

Conclusioni

A seguito di queste modifiche siamo stati in grado di eseguire la discovery di tutti i server parte del cluster Hyper-v oggetto dell’attività.
Mi sono premurato di segnalare l’accaduto a Microsoft, che spero provveda quanto prima ad aggiungere tra le FAQ anche questa casistica.

L’idea di questa guida, in pieno spirito ICT Power, è quella di evitarvi pomeriggi spesi dietro alla risoluzione di problemi, fornendovi la nostra esperienza dal campo, dove chi è del mestiere sa benissimo che non va mai niente come da manuale.

Spero che questo format sia piaciuto e vi invito a condividerlo al più possibile.

Vi lascio qualche link utile per approfondire il tema Di Azure Migrate: Guide ICT Power su Azure Migrate