• Guide, Sistemi Operativi
• 1 Giugno 2026

In alcuni scenari può essere necessario spostare una o più macchine virtuali Hyper-V da un cluster a un altro senza interrompere i servizi erogati. Pensiamo, ad esempio, ad attività di consolidamento dell’infrastruttura, sostituzione dell’hardware, migrazione verso un nuovo datacenter, separazione di ambienti aziendali oppure integrazione tra infrastrutture appartenenti a foreste Active Directory diverse.

La Live Migration consente di trasferire una macchina virtuale da un host Hyper-V a un altro mantenendola accesa, riducendo al minimo l’impatto sugli utenti e sulle applicazioni. Quando però i due host appartengono a cluster differenti e, soprattutto, a foreste diverse, la configurazione richiede qualche attenzione in più.

In questa guida vi mostrerò come preparare l’ambiente, configurare correttamente i prerequisiti e migrare le VM tra due cluster Hyper-V distinti, mantenendo il controllo su autenticazione, rete, permessi e continuità operativa.

Figura 1: Diagramma dell’ambiente utilizzato

Configurazione della risoluzione dei nomi tra le foreste

Prima di creare il trust tra le due foreste Active Directory è necessario verificare che i domain controller siano in grado di risolvere correttamente i nomi DNS della foresta remota.

Nel mio laboratorio utilizzerò due foreste:

• Virtual.lab, che rappresenta la foresta di partenza
• Azienda.local, che rappresenta la foresta di destinazione

La Live Migration tra cluster appartenenti a foreste diverse richiede che l’autenticazione tra i due ambienti funzioni correttamente. Per questo motivo, prima ancora di configurare il trust, dovrete assicurarvi che ogni foresta sia in grado di raggiungere e risolvere i nomi DNS dell’altra.

Nel DNS Manager del domain controller della foresta Azienda.local ho configurato un Conditional Forwarder verso la zona DNS virtual.lab, indicando l’indirizzo IP del DNS server della foresta di partenza.

Allo stesso modo, nel DNS Manager del domain controller della foresta virtual.lab ho configurato un Conditional Forwarder verso la zona DNS azienda.local, indicando l’indirizzo IP del DNS server della foresta di destinazione.

In questo modo, quando un server della foresta Azienda.local deve risolvere un nome appartenente alla foresta virtual.lab, la richiesta DNS viene inoltrata al DNS server corretto, e viceversa.

Figura 2: Nel DNS Manager del domain controller DC1 della foresta virtual.lab è stato configurato il Conditional Forwarder per la zona azienda.local, che punta al DNS server 172.16.0.100 della foresta di destinazione

Figura 3: Nel DNS Manager del domain controller DC1-AZ della foresta Azienda.local è stato configurato il Conditional Forwarder per la zona virtual.lab, che punta al DNS server 10.10.10.10 della foresta di partenza

Completata questa configurazione, vi consiglio di verificare la risoluzione dei nomi da entrambi i lati, utilizzando strumenti come nslookup o Resolve-DnsName. Solo dopo aver confermato che i nomi DNS vengono risolti correttamente potrete procedere con la creazione del trust tra le foreste.

Creazione del Forest Trust

Dopo aver configurato e verificato la risoluzione DNS tra le due foreste, possiamo procedere con la creazione del Forest Trust.

Nel mio scenario ho scelto di configurare un Forest Trust perché l’External Trust non ha permesso di completare correttamente la configurazione necessaria per la migrazione tra i due ambienti. Quando lavorate con due foreste Active Directory diverse, il Forest Trust è generalmente la scelta più adatta perché consente di stabilire una relazione di trust tra le foreste e non solo tra singoli domini.

La configurazione verrà eseguita tra:

virtual.lab, foresta di partenza, dove si trovano inizialmente le macchine virtuali
azienda.local, foresta di destinazione, verso cui verranno migrate le VM

Per creare il trust, aprite Active Directory Domains and Trusts dal domain controller della foresta di destinazione oppure da una macchina amministrativa con gli strumenti RSAT installati.

Fate clic con il tasto destro sul dominio virtual.lab, selezionate Properties e spostatevi nella scheda Trusts. Da qui avviate il wizard con il pulsante New Trust.

Quando vi viene richiesto il nome del dominio o della foresta remota, inserite azienda.local. Nella schermata successiva selezionate Forest trust.

Figura 4: Avvio del New Trust Wizard dalla console Active Directory Domains and Trusts

Nella schermata Trust Type selezionate Forest trust.

Figura 5: Nel New Trust Wizard viene selezionata l’opzione Forest trust, necessaria per stabilire una relazione di trust tra le foreste virtual.lab e azienda.local

Nella schermata Direction of Trust selezionate Two-way.

Con questa configurazione consentite l’autenticazione reciproca tra le due foreste: gli oggetti della foresta virtual.lab potranno autenticarsi verso azienda.local e, allo stesso modo, gli oggetti di azienda.local potranno autenticarsi verso virtual.lab.

Per lo scenario di Live Migration tra cluster Hyper-V in foreste diverse, questa scelta è utile perché permette di gestire in modo più lineare le autorizzazioni richieste durante le fasi successive, soprattutto quando dovrete configurare permessi, deleghe e accesso alle risorse tra i due ambienti.

In alternativa al trust bidirezionale, potete configurare anche un trust unidirezionale, ma dovete scegliere correttamente la direzione del trust.

Nel nostro scenario le macchine virtuali partono dalla foresta virtual.lab e vengono migrate verso la foresta azienda.local. Se l’obiettivo è consentire agli account e agli host della foresta di partenza di accedere alle risorse presenti nella foresta di destinazione, dovrete creare un trust in cui azienda.local si fida di virtual.lab.

In termini pratici, dalla foresta virtual.lab questo corrisponde a un trust One-way: outgoing verso azienda.local. Significa che gli utenti e i computer della foresta virtual.lab potranno essere autenticati nella foresta azienda.local.

Se invece configuraste un trust One-way: incoming dalla foresta virtual.lab, otterreste il comportamento opposto: sarebbero gli utenti e i computer di azienda.local a potersi autenticare verso virtual.lab. Questa scelta avrebbe senso solo se le risorse da raggiungere fossero nella foresta di partenza.

Per evitare ambiguità e semplificare la configurazione della Live Migration tra cluster Hyper-V, in questa guida utilizzerò un trust Two-way. In ambienti di produzione, però, potete scegliere un trust unidirezionale quando volete applicare il principio del minimo privilegio e consentire l’autenticazione solo nel verso strettamente necessario.

Figura 6: Nel New Trust Wizard viene selezionata l’opzione Two-way, così da creare un trust bidirezionale tra le foreste virtual.lab e azienda.local

Outgoing Trust Authentication Level – Local Forest dovete scegliere il livello di autenticazione da applicare agli utenti della foresta remota.

Per questa guida ho selezionato Forest-wide authentication. In questo modo gli utenti e i computer della foresta azienda.local potranno essere autenticati sulle risorse della foresta locale virtual.lab, senza dover autorizzare manualmente ogni singolo server o servizio.

L’alternativa è Selective authentication, più restrittiva e indicata quando le due foreste appartengono a organizzazioni diverse o quando volete concedere l’accesso solo a specifiche risorse. In questo scenario, però, renderebbe più complessa la configurazione della Live Migration, perché dovreste assegnare esplicitamente i permessi di autenticazione sugli host e sulle risorse interessate.

Per semplificare la procedura e concentrarci sulla migrazione tra i due cluster Hyper-V procediamo quindi con Forest-wide authentication.

Figura 7: Scelta dell’opzione Forest-wide authentication, che consente l’autenticazione degli oggetti della foresta remota sulle risorse della foresta locale

Nella schermata Trust Selections Complete viene mostrato il riepilogo delle impostazioni scelte per il nuovo trust.

Prima di proseguire controllate con attenzione che il dominio locale sia virtual.lab, che il dominio specificato sia azienda.local, che la direzione sia Two-way e che il tipo di trust sia Forest trust.

Questa verifica è importante perché, una volta creato il trust, eventuali errori nella direzione o nel tipo di trust potrebbero impedire la corretta autenticazione tra le due foreste e complicare le fasi successive della Live Migration.

Se le impostazioni sono corrette, fate clic su Next per creare il trust.

Figura 8: Riepilogo della configurazione: trust Two-way di tipo Forest trust tra virtual.lab e azienda.local

Nella schermata Confirm Outgoing Trust il wizard vi chiede se volete confermare subito il trust in uscita.

Se avete creato il trust da entrambi i lati e la comunicazione tra le foreste è corretta, selezionate Yes, confirm the outgoing trust. In questo modo viene verificato immediatamente che la relazione di trust verso la foresta remota sia funzionante.

Questa conferma è un controllo importante: vi permette di individuare subito eventuali problemi di DNS, connettività, credenziali o configurazione del trust, prima di passare alla configurazione di Hyper-V e della Live Migration.

Figura 9: Conferma del trust in uscita. Selezionando Yes, confirm the outgoing trust viene verificata subito la relazione di trust verso la foresta remota

Nella schermata Confirm Incoming Trust il wizard vi chiede se volete confermare anche il trust in ingresso.

Se la relazione è stata creata correttamente da entrambi i lati, selezionate Yes, confirm the incoming trust. In questo modo verificate che anche la parte in ingresso del trust sia valida e che la foresta remota possa autenticarsi correttamente verso la foresta locale.

Questa verifica completa il controllo della relazione Two-way: prima abbiamo confermato il trust in uscita, ora confermiamo quello in ingresso. Se entrambe le verifiche terminano correttamente, potete considerare funzionante il Forest Trust tra virtual.lab e azienda.local.

Figura 10: Conferma del trust in ingresso per verificare anche la seconda direzione del trust bidirezionale

Al termine della procedura viene mostrata la schermata Completing the New Trust Wizard.

Il messaggio conferma che la relazione di trust è stata creata e validata correttamente. Nel riepilogo vengono indicati anche i suffissi DNS instradati verso la foresta specificata, in questo caso azienda.local, e verso la foresta locale, cioè virtual.lab.

A questo punto potete fare clic su Finish per chiudere il wizard.

Figura 11: Conferma della creazione e della validazione del Forest Trust tra virtual.lab e azienda.local

Dopo aver completato il wizard, tornate nella scheda Trusts delle proprietà del dominio virtual.lab.

A questo punto il trust verso azienda.local deve comparire sia nella sezione Domains trusted by this domain, sia nella sezione Domains that trust this domain. La presenza del trust in entrambe le sezioni conferma che la relazione è stata configurata come Two-way.

Verificate anche che il Trust Type sia Forest e che il valore Transitive sia impostato su Yes. Questo indica che il trust è stato creato a livello di foresta ed è transitivo tra i domini appartenenti alle due foreste.

Figura 12: Nella scheda Trusts del dominio virtual.lab è visibile il trust Two-way verso azienda.local, configurato come Forest Trust e con transitività abilitata

Verifica del Forest Trust

Dopo aver creato il Forest Trust, prima di procedere con la configurazione di Hyper-V, è importante verificarne il corretto funzionamento da entrambi i lati.

Assicuratevi prima che tutti i Domain Controller delle due foreste abbiano completato la replica Active Directory. Se il trust è stato appena creato, attendete il tempo necessario alla replica oppure forzatela manualmente, soprattutto se avete più controller di dominio o più siti Active Directory.

Sul domain controller DC1.virtual.lab ho eseguito il seguente comando:

Il comando verifica la relazione di trust tra la foresta locale virtual.lab e la foresta remota azienda.local, richiedendo le credenziali amministrative di entrambe le foreste.

I parametri principali sono:

/verify controlla che il trust sia valido e funzionante
/userO indica l’utente amministrativo della foresta di origine
/userD indica l’utente amministrativo della foresta di destinazione
/passwordO:* e /passwordD:* permettono di inserire le password in modo interattivo, senza scriverle in chiaro nel comando

Figura 13: Da DC1.virtual.lab viene eseguito il comando netdom trust per verificare il Forest Trust verso azienda.local. Il messaggio finale conferma che il trust è stato verificato correttamente

Ripetete la verifica anche nell’altra foresta, eseguendo il comando da un Domain Controller della foresta azienda.local.

Nel mio caso ho utilizzato DC1-AZ ed ho eseguito:

Anche in questo caso vengono richieste in modo interattivo le password degli account amministrativi indicati nel comando.

Figura 14: Da DC1-AZ, nella foresta azienda.local, viene eseguito il comando netdom trust per verificare il Forest Trust verso virtual.lab. Il risultato conferma che il trust è stato verificato correttamente anche dal lato della foresta di destinazione

A questo punto avete verificato il Forest Trust da entrambi i lati. Prima di procedere, assicuratevi che tutti i Domain Controller delle due foreste siano correttamente replicati e che la risoluzione DNS continui a funzionare in entrambe le direzioni.

Configurazione della Kerberos Constrained Delegation tramite PowerShell

Dopo aver creato e verificato il Forest Trust, possiamo configurare la Kerberos Constrained Delegation sui nodi Hyper-V.

Questa configurazione serve per consentire agli host Hyper-V di origine di delegare, in modo controllato, le credenziali verso i servizi necessari sugli host Hyper-V di destinazione. In pratica, quando avviate una Live Migration da remoto, l’host sorgente deve poter autenticarsi verso l’host di destinazione per eseguire la migrazione della macchina virtuale e, se necessario, accedere ai percorsi usati per lo spostamento dello storage.

Per Hyper-V Live Migration i servizi da delegare sono:

• cifs, necessario per l’accesso ai percorsi file e allo storage
• Microsoft Virtual System Migration Service, necessario per la migrazione della macchina virtuale

Per semplificare la configurazione ho preferito utilizzare PowerShell, evitando di modificare manualmente gli oggetti computer dalla console Active Directory Users and Computers.

Nel mio scenario i nodi Hyper-V di partenza sono:

HV1.virtual.lab
HV2.virtual.lab

I nodi Hyper-V di destinazione sono invece:

HVCONV1-az.azienda.local
HVCONV2-az.azienda.local

Lo script costruisce automaticamente la lista degli SPN da configurare, usando sia il nome breve sia il nome FQDN dei nodi di destinazione. Successivamente aggiorna l’attributo msDS-AllowedToDelegateTo sugli oggetti computer dei nodi sorgente e abilita la delega tramite Set-ADAccountControl.

Questo significa che i nodi HV1 e HV2 saranno autorizzati a delegare verso i servizi cifs e Microsoft Virtual System Migration Service presenti sui nodi HVCONV1-az e HVCONV2-az.

Prima di eseguire lo script, assicuratevi che:

il Forest Trust sia funzionante,
la risoluzione DNS tra le foreste sia corretta,
gli SPN dei nodi Hyper-V siano registrati correttamente,
gli host Hyper-V utilizzino Kerberos come protocollo di autenticazione per la Live Migration,
la replica Active Directory sia completata.

Lo script richiede credenziali amministrative della foresta virtual.lab, perché la delega viene configurata sugli oggetti computer dei nodi sorgente presenti in quella foresta.

 

Lo script è riutilizzabile: se dovete aggiungere altri nodi sorgente o destinazione, vi basta aggiornare gli array $SourceNodes e $TargetNodes.

Al termine dell’esecuzione, attendete la replica dei Domain Controller e verificate che sugli oggetti computer dei nodi sorgente siano presenti le deleghe verso i servizi dei nodi di destinazione.

Figura 15: Durante l’esecuzione dello script viene richiesta la credenziale amministrativa della foresta virtual.lab, necessaria per modificare gli oggetti computer dei nodi Hyper-V sorgente

Lo script genera automaticamente la lista degli SPN da configurare per i nodi di destinazione HVCONV1-az.azienda.local e HVCONV2-az.azienda.local.

Al termine dell’esecuzione, potete verificare il risultato aprendo le proprietà dei nodi sorgente in Active Directory Users and Computers. Nella scheda Delegation deve essere selezionata l’opzione Trust this computer for delegation to specified services only con Use any authentication protocol.

Figura 16: Al termine dello script, nella scheda Delegation del nodo HV1 sono visibili i servizi cifs e Microsoft Virtual System Migration Service configurati verso i nodi Hyper-V di destinazione

Per verificare la configurazione della Kerberos Constrained Delegation, ho utilizzato uno script PowerShell che legge direttamente gli attributi degli oggetti computer dei nodi sorgente.

Lo script controlla i nodi HV1 e HV2 nella foresta virtual.lab e mostra il valore delle proprietà TrustedToAuthForDelegation, TrustedForDelegation e msDS-AllowedToDelegateTo.

Nel risultato dovete verificare che TrustedToAuthForDelegation sia impostato su True. Questo conferma che il computer è configurato per la delega ai servizi specificati usando qualsiasi protocollo di autenticazione.

Il valore TrustedForDelegation deve invece rimanere False, perché non vogliamo abilitare la delega non vincolata. La configurazione deve restare limitata agli SPN presenti nell’attributo msDS-AllowedToDelegateTo.

Ricordatevi di attendere la replica tra i Domain Controller prima di eseguire i test di migrazione. In caso contrario, potreste visualizzare una configurazione non ancora aggiornata su tutti i controller di dominio.

Figura 17: Verifica della configurazione della Kerberos Constrained Delegation sui nodi HV1 e HV2

Se l’output mostra gli stessi valori su entrambi i nodi sorgente, potete considerare correttamente configurata la delegation virtual.lab → azienda.local.

In altre parole, i nodi HV1 e HV2 della foresta virtual.lab sono ora autorizzati a delegare verso i servizi necessari presenti sui nodi Hyper-V della foresta azienda.local.

Dopo ogni modifica agli attributi di Active Directory, vi consiglio di eliminare i ticket Kerberos già presenti nella cache degli host Hyper-V coinvolti. In questo modo forzate i server a richiedere nuovi ticket aggiornati, evitando che vengano utilizzate informazioni precedenti alla configurazione della delegation.

Eseguite quindi, su tutti i nodi Hyper-V coinvolti, il comando:

Il comando deve essere eseguito sia sui nodi sorgente sia sui nodi di destinazione.

Configurazione dei permessi per la gestione remota degli host Hyper-V

Dopo aver configurato la Kerberos Constrained Delegation, ho provato a connettermi agli host Hyper-V della foresta azienda.local utilizzando Hyper-V Manager dal nodo HV1.virtual.lab.

L’obiettivo è gestire da un’unica console tutti i nodi coinvolti nella migrazione:

HV1.virtual.lab
HV2.virtual.lab
HVCONV1-az.azienda.local
HVCONV2-az.azienda.local

È importante chiarire un punto: la Kerberos Constrained Delegation e i permessi di gestione remota non sono la stessa cosa.

La delegation Kerberos serve alla Live Migration tra gli host Hyper-V, perché consente agli host sorgente di delegare le credenziali verso i servizi necessari sugli host di destinazione.

La membership nei gruppi locali, invece, serve a consentire all’utente amministrativo di connettersi e amministrare gli host remoti tramite Hyper-V Manager, PowerShell, Failover Cluster Manager e gli altri strumenti di gestione.

Per poter gestire da HV1.virtual.lab gli host Hyper-V del dominio azienda.local, l’account utilizzato deve quindi avere privilegi amministrativi sui nodi di destinazione:

HVCONV1-az.azienda.local
HVCONV2-az.azienda.local

Per la sola gestione Hyper-V potete aggiungere l’utente o il gruppo al gruppo locale Hyper-V Administrators dei nodi di destinazione:

Questa configurazione consente la gestione delle risorse Hyper-V, ma può non essere sufficiente per tutte le attività operative legate alla migrazione, come configurazioni di rete, troubleshooting, gestione firewall, WinRM, cluster o storage.

Per una fase di migrazione e test, ho quindi preferito usare temporaneamente il gruppo locale Administrators:

Questa configurazione assegna privilegi amministrativi completi sul nodo Hyper-V di destinazione e semplifica le verifiche iniziali. Terminata la migrazione, vi consiglio di rimuovere i privilegi non più necessari e applicare il principio del minimo privilegio.

Dopo aver aggiunto l’account o il gruppo ai nodi di destinazione, potete aprire Hyper-V Manager, selezionare Connect to Server e inserire il nome FQDN del nodo remoto, ad esempio HVCONV1-az.azienda.local

Se la risoluzione DNS, il trust e i permessi locali sono corretti, il nodo remoto verrà aggiunto alla console e potrà essere amministrato centralmente.

Figura 18: Da Hyper-V Manager sul nodo HV1.virtual.lab viene avviata la connessione al server remoto HVCONV1-az.azienda.local, così da gestire gli host Hyper-V delle due foreste da un’unica console

Figura 19: Da Hyper-V Manager su HV1.virtual.lab viene gestito correttamente il nodo remoto HVCONV1-az.azienda.local

Abilitazione della Live Migration sui nodi Hyper-V

Prima di avviare lo spostamento delle macchine virtuali dovete verificare che la Live Migration sia abilitata su tutti i nodi Hyper-V coinvolti.

Nel mio scenario i nodi sono quattro:

HV1.virtual.lab
HV2.virtual.lab
HVCONV1-AZ.azienda.local
HVCONV2-AZ.azienda.local

La configurazione può essere eseguita dalla console grafica di Hyper-V, ma per velocizzare l’attività ho preferito usare PowerShell, applicando le stesse impostazioni a tutti i nodi.

Lo script abilita la Live Migration, imposta Kerberos come metodo di autenticazione e configura Compression come opzione di performance per il trasferimento.

All’avvio verranno richieste le credenziali di un account con privilegi amministrativi locali su tutti i nodi Hyper-V coinvolti.

Nel mio caso ho utilizzato l’account VIRTUAL\Administrator, già autorizzato anche sui nodi della foresta azienda.local.

Lo script abilita la Live Migration sui quattro nodi, imposta Kerberos come metodo di autenticazione e configura Compression come opzione di performance. Al termine, per ogni nodo viene mostrato il riepilogo della configurazione applicata.

Dall’output dovete verificare che i valori siano i seguenti:

VirtualMachineMigrationEnabled: True
VirtualMachineMigrationAuthenticationType: Kerberos
VirtualMachineMigrationPerformanceOption: Compression

Se tutti i nodi restituiscono questi valori, la configurazione della Live Migration è corretta e coerente con la Kerberos Constrained Delegation configurata in precedenza.

Figura 20: Durante l’esecuzione dello script viene richiesta una credenziale amministrativa valida sui nodi Hyper-V

Figura 21: Lo script conferma la configurazione della Live Migration sui nodi Hyper-V

Potete verificare la configurazione anche dalla console grafica di Hyper-V Manager.

Selezionate il nodo Hyper-V da controllare, aprite Hyper-V Settings e spostatevi nella sezione Live Migrations. Qui dovete verificare che sia selezionata l’opzione Enable incoming and outgoing live migrations.

Nella sezione Incoming live migrations potete scegliere se permettere la migrazione da qualsiasi rete disponibile oppure limitarla a specifici indirizzi IP. Nel mio caso la configurazione è gestita dal cluster e viene utilizzata la rete 172.16.0.0/23 per il traffico di Live Migration.

Il messaggio visualizzato nella parte inferiore indica infatti che alcune impostazioni della rete di migrazione non possono essere modificate o rimosse da Hyper-V Manager perché sono in uso da un cluster. In uno scenario clusterizzato è normale: la gestione della rete di Live Migration deve essere coerente con la configurazione del Failover Cluster.

Figura 22: In Hyper-V Settings, nella sezione Live Migrations, viene verificato che la Live Migration sia abilitata sul nodo HVCONV2-AZ.azienda.local e che il traffico venga limitato alla rete configurata per la migrazione

Nota
Scegliete con attenzione la rete di Live Migration da utilizzare. Durante lo spostamento di una VM, soprattutto se ha molta memoria assegnata o dischi di grandi dimensioni, il traffico generato può essere significativo.

Per evitare impatti sulla produzione, vi consiglio di utilizzare una rete dedicata oppure una rete separata da quella usata dai client, dallo storage o dal traffico applicativo. In questo modo la Live Migration non andrà a saturare le interfacce di rete utilizzate dai servizi in esercizio.

Verifica dei virtual switch sui nodi Hyper-V

Prima di procedere con la Live Migration, assicuratevi che i virtual switch siano presenti e configurati in modo coerente su tutti i nodi Hyper-V coinvolti.

Questo passaggio è fondamentale perché le macchine virtuali mantengono nella propria configurazione il nome del virtual switch a cui sono collegate. Se una VM è collegata allo switch Production sul cluster di partenza, anche i nodi del cluster di destinazione devono avere un virtual switch con lo stesso nome.

Nel mio scenario ho verificato la presenza dello switch Production sui nodi:

HV1.virtual.lab
HV2.virtual.lab
HVCONV1-AZ.azienda.local
HVCONV2-AZ.azienda.local

Per semplificare il controllo ho utilizzato questo script PowerShell:

Lo script restituisce l’elenco dei virtual switch presenti su ogni host e indica se il nome corrisponde a quello atteso. Nel nostro caso dobbiamo verificare che su tutti i nodi sia presente uno switch chiamato Production.

I virtual switch possono anche avere nomi diversi tra cluster differenti, ma per una Live Migration lineare è consigliabile mantenere lo stesso nome dello switch su tutti i nodi. Se il nome dello switch non esiste sul nodo di destinazione, la VM potrebbe non essere migrata correttamente oppure potrebbe essere necessario intervenire manualmente sulla configurazione della scheda di rete virtuale.

Oltre al nome, verificate anche che lo switch sia collegato alla rete corretta. Avere uno switch chiamato Production non è sufficiente se poi è associato a una scheda fisica, VLAN o rete diversa da quella prevista.

Quindi, prima di migrare, controllate che sui nodi di destinazione siano presenti:

lo stesso nome del virtual switch usato dalla VM,
lo stesso tipo di switch, normalmente External,
la corretta connettività verso la rete di produzione,
le eventuali VLAN richieste dalla macchina virtuale.

Questo controllo evita errori durante la migrazione e riduce il rischio che la VM arrivi sul cluster di destinazione senza connettività di rete.

Figura 23: Lo script PowerShell verifica la presenza del virtual switch Production su tutti i nodi Hyper-V

Rimozione della VM dal cluster sorgente

Prima di avviare la migrazione verso il nuovo cluster dobbiamo rimuovere la macchina virtuale dal cluster sorgente.

Nel mio caso la VM si chiama VM01 ed è attualmente in esecuzione sul nodo HV1 del cluster CLUSTER-HV.virtual.lab.

Da Failover Cluster Manager, selezionate la VM nella sezione Roles, fate clic con il tasto destro e scegliete Remove.

Questa operazione rimuove la VM dalle risorse clusterizzate, ma non spegne la macchina virtuale e non elimina i file della VM. La macchina resta accesa sull’host Hyper-V che ne è proprietario in quel momento.

È importante non confondere questa operazione con l’eliminazione della macchina virtuale. Stiamo semplicemente togliendo la VM dal controllo del cluster sorgente, in modo da poterla gestire direttamente dall’host Hyper-V e procedere con la migrazione verso il cluster di destinazione.

Prima di confermare, assicuratevi che la VM sia in stato Running e annotate il nodo proprietario, nel mio caso HV1. La Live Migration partirà proprio da questo host.

Figura 24: La VM viene rimossa dal cluster sorgente, ma resta accesa sull’host Hyper-V proprietario

Questo passaggio è necessario perché la Live Migration tra due cluster diversi non viene avviata direttamente come spostamento di una risorsa cluster dal cluster sorgente al cluster di destinazione.

Il cluster può spostare una VM solo tra i nodi che appartengono allo stesso cluster. Nel nostro scenario, invece, vogliamo spostare una VM da CLUSTER-HV.virtual.lab verso un cluster differente nella foresta azienda.local. Per questo motivo dobbiamo prima rimuovere la VM dal cluster sorgente e lasciarla in esecuzione sull’host Hyper-V che la sta attualmente ospitando.

Dopo la rimozione dal cluster, la VM continua a funzionare su HV1 come normale macchina virtuale Hyper-V non clusterizzata. A questo punto possiamo gestirla direttamente da Hyper-V Manager o da PowerShell ed eseguire la Live Migration dall’host Hyper-V sorgente verso uno degli host Hyper-V del cluster di destinazione.

Il cluster sorgente viene usato fino a quando la VM è una risorsa clusterizzata. Per la migrazione verso un altro cluster, invece, dobbiamo passare dalla gestione cluster alla gestione Hyper-V dell’host proprietario.

Figura 25: Dopo la rimozione dal cluster, la VM VM01 è visibile in Hyper-V Manager sul nodo HV1. La macchina è ancora accesa, ma non risulta più clusterizzata, quindi può essere gestita direttamente dall’host Hyper-V sorgente

Avvio della Live Migration verso il nodo di destinazione

A questo punto siamo pronti a spostare la VM verso il cluster di destinazione.

Da Hyper-V Manager selezionate il nodo sorgente HV1, fate clic con il tasto destro sulla macchina virtuale VM01 e scegliete Move.

Ricordate che la VM non è più clusterizzata nel cluster sorgente; quindi, l’operazione viene eseguita direttamente dall’host Hyper-V proprietario. La macchina resta accesa durante la procedura e verrà spostata verso uno dei nodi Hyper-V del nuovo cluster.

Figura 26: Da Hyper-V Manager viene selezionata la VM VM01 sul nodo sorgente HV1 e viene avviato il wizard con l’opzione Move

Nel wizard selezionate Move the virtual machine. Questa opzione consente di spostare la macchina virtuale ed eventualmente anche il relativo storage verso un altro host Hyper-V.

Figura 27: Nel Move Wizard viene scelta l’opzione Move the virtual machine, necessaria per migrare la VM verso un altro host Hyper-V

Nella schermata Specify Destination Computer inserite il nome FQDN del nodo Hyper-V di destinazione. Nel mio caso ho indicato HVCONV1-az.azienda.local

Figura 28: Nel wizard viene specificato il nodo Hyper-V di destinazione HVCONV1-az.azienda.local, appartenente alla foresta azienda.local

Nella schermata Choose Move Options selezionate Move the virtual machine’s data to a single location.

Questa scelta consente di spostare configurazione, dischi virtuali, checkpoint e smart paging in un unico percorso sul nodo di destinazione. È l’opzione più semplice quando volete trasferire completamente la VM dal vecchio ambiente al nuovo.

Figura 29: Selezione dell’opzione per spostare tutti i dati della macchina virtuale in un’unica posizione sul nodo di destinazione

Indicate quindi il percorso di destinazione in cui salvare i file della VM. Nel mio esempio ho utilizzato C:\ClusterStorage\vol2\

Il percorso scelto deve essere raggiungibile dal nodo Hyper-V di destinazione e deve disporre di spazio sufficiente per contenere tutti i file della macchina virtuale.

Figura 30: Nel wizard viene indicato il percorso C:\ClusterStorage\vol2\ come destinazione per i file della VM sul nuovo ambiente

Nella schermata finale controllate il riepilogo prima di avviare la migrazione. Verificate in particolare il nome della VM, il nodo di destinazione, il percorso dei file e il metodo di migrazione.

Figura 31: Schermata di riepilogo del wizard di spostamento

Durante il primo tentativo di spostamento, la procedura è fallita con un errore di risoluzione del percorso di rete.

L’errore mostrato dal wizard è il seguente:

There was an error during move operation.
Virtual machine migration operation failed at migration source.
Failed to create folder.
Virtual machine migration operation for ‘VM01’ failed at migration source ‘HV1’. (Virtual machine ID C7E33D20-D7F6-4326-90AD-A39403F4D3C)
Migration did not succeed. Failed to create folder ‘\\HVCONV1-AZ\HV1.210319798$\{5d855-80b-4…\Virtual Hard Disks’: The network path was not found. (0x80070035).

Anche se nel wizard era stato indicato il nome FQDN del nodo di destinazione, durante l’operazione Hyper-V ha provato ad accedere al nodo usando il nome corto
\\HVCONV1-AZ\…

Figura 32: Il primo tentativo di spostamento della VM VM01 fallisce perché Hyper-V prova a creare una cartella usando il nome corto HVCONV1-AZ. L’errore The network path was not found (0x80070035) indica un problema di risoluzione o raggiungibilità del percorso di rete

Il problema dipendeva quindi dalla mancata risoluzione del nome corto del nodo di destinazione. Per correggerlo ho aggiunto i suffissi DNS delle due foreste nella Suffix Search List del client DNS.

Eseguite il comando sui nodi Hyper-V di partenza coinvolti:

Dopo questa modifica, il nome corto HVCONV1-AZ viene risolto correttamente tramite il suffisso DNS azienda.local e la procedura di spostamento può essere rilanciata.

Questo controllo è importante negli scenari multi-foresta: anche quando inserite il nome completo del server, alcuni passaggi della migrazione possono utilizzare il NetBIOS name o il nome host breve. Per questo motivo, oltre alla risoluzione FQDN, dovete assicurarvi che sia funzionante anche la risoluzione dei nomi corti tra le due foreste.

Dopo aver corretto la risoluzione dei nomi brevi aggiungendo i suffissi DNS delle due foreste, ho rilanciato il wizard di spostamento della VM.

Questa volta la Live Migration è partita correttamente. In Hyper-V Manager potete seguire l’avanzamento direttamente nella colonna Status, dove viene mostrato lo stato Moving Virtual Machine and Storage con la percentuale di completamento.

Durante questa fase la macchina virtuale resta accesa e continua a funzionare. Il traffico di migrazione viene gestito attraverso la rete configurata per la Live Migration, mentre i file della VM vengono copiati nel percorso scelto sul nodo di destinazione.

Figura 33: Dopo la correzione della risoluzione DNS, il wizard di spostamento viene rilanciato e la VM VM01 entra nello stato Moving Virtual Machine and Storage

Al termine della procedura, la VM VM01 risulta in esecuzione sul nodo HVCONV1-AZ.azienda.local. La macchina è ancora accesa, ma non è ancora una risorsa clusterizzata nel cluster di destinazione: nella console Hyper-V viene infatti indicato Clustered: No.

Questo è il comportamento atteso. La Live Migration ha spostato correttamente la VM sull’host Hyper-V di destinazione, ma ora dobbiamo aggiungerla al Failover Cluster della foresta azienda.local, in modo che venga gestita come risorsa ad alta disponibilità.

Figura 34: La VM VM01 è stata spostata correttamente su HVCONV1-AZ.azienda.local ed è ancora in stato Running

Aggiunta della VM al cluster di destinazione

Dopo aver completato la Live Migration, la macchina virtuale VM01 si trova sul nodo HVCONV1-AZ.azienda.local, ma non è ancora gestita dal Failover Cluster di destinazione.

Per renderla nuovamente una VM ad alta disponibilità, aprite Failover Cluster Manager sul cluster CLUSTERCONV.azienda.local, selezionate Roles e scegliete Configure Role.

Nel wizard selezionate il ruolo Virtual Machine e proseguite con Next.

Figura 35: Nel High Availability Wizard viene selezionato il ruolo Virtual Machine, necessario per aggiungere al cluster una VM già presente su uno dei nodi Hyper-V

Nella schermata successiva viene mostrato l’elenco delle macchine virtuali disponibili sul nodo del cluster. Selezionate VM01, che risulta in stato Running sul nodo HVCONV1-AZ.azienda.local.

Questa operazione non sposta nuovamente la VM: la registra semplicemente come risorsa clusterizzata nel cluster di destinazione.

Figura 36: Il wizard rileva la VM VM01 in esecuzione su HVCONV1-AZ.azienda.local. Selezionandola, la macchina verrà configurata come risorsa ad alta disponibilità nel cluster di destinazione

Al termine della procedura, il wizard conferma che la configurazione dell’alta disponibilità è stata completata correttamente. La VM VM01 compare ora tra i Roles del cluster CLUSTERCONV.azienda.local con stato Running.

Da questo momento la macchina virtuale è nuovamente gestita dal cluster e può essere spostata tra i nodi del cluster di destinazione utilizzando le normali funzionalità di Failover Cluster Manager.

Figura 37: L’High Availability Wizard conferma che la VM VM01 è stata aggiunta correttamente al cluster di destinazione. La macchina è ora una risorsa clusterizzata

Conclusioni

In questa guida vi ho mostrato come effettuare la Live Migration di una macchina virtuale Hyper-V tra due cluster differenti, appartenenti a foreste Active Directory diverse.

La parte più importante del lavoro non è il wizard di migrazione, ma la preparazione dell’ambiente: DNS,Forest Trust, Kerberos Constrained Delegation, permessi amministrativi sugli host, configurazione della Live Migration e coerenza dei virtual switch devono essere verificati prima di spostare la VM.

Nel mio caso ho rimosso la VM dal cluster sorgente lasciandola accesa sull’host proprietario, ho eseguito la migrazione direttamente da Hyper-V Manager verso il nodo del cluster di destinazione e, al termine, ho aggiunto nuovamente la VM al Failover Cluster per renderla ad alta disponibilità.

Prestate particolare attenzione alla risoluzione dei nomi, anche dei nomi brevi, perché in scenari multi-foresta può essere la causa di errori non immediatamente evidenti. Una volta completate tutte le verifiche, la procedura consente di migrare le macchine virtuali riducendo al minimo l’impatto sui servizi.