Condividi la tua opinione sull'esperienza di download del PDF.

Hyper-V documentazione
Hyper-V in Windows Server consente di eseguire macchine virtuali Windows e Linux su larga
scala, offrendo flessibilità e massimizzazione delle risorse.

Hyper-V su Windows

ｅ PANORAMICA

panoramica di Hyper-V in Windows

ｂ INTRODUZIONE

Installare Hyper-V.

Creare una macchina virtuale

Hyper-V in Windows Server

ｅ PANORAMICA

Panoramica di Hyper-V

Requisiti di sistema per Hyper-V

Sistemi operativi guest Windows supportati

ｂ INTRODUZIONE

Installare il ruolo Hyper-V

commutatore virtuale Hyper-V

Creare una macchina virtuale

Gestione avanzata

ｅ PANORAMICA

Modalità di virtualizzazione di Windows Admin Center

ｈ NOVITÀ
Introduzione alla modalità di virtualizzazione di Windows Admin Center

Usare un'infrastruttura sorvegliata per fornire un ambiente sicuro per le

macchine virtuali

ｅ PANORAMICA

Infrastruttura sorvegliata e macchine virtuali schermate

Hyper-V virtualizzazione in Windows
Server e Windows
13/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Hyper-V è la tecnologia hypervisor di livello aziendale di Microsoft integrata in Windows Server

e Windows. Offre funzionalità di virtualizzazione hardware che consentono alle organizzazioni
di creare, gestire ed eseguire macchine virtuali su larga scala. Come hypervisor di tipo 1, Hyper-
V viene eseguito direttamente sull'hardware di elaborazione, offrendo prestazioni quasi native
e isolamento affidabile per i carichi di lavoro virtualizzati.

La virtualizzazione dei carichi di lavoro con Hyper-V consente di ottimizzare l'utilizzo

dell'hardware, semplificare le operazioni IT e migliorare la continuità aziendale. Supporta
un'ampia gamma di sistemi operativi per le macchine virtuali guest, tra cui molte versioni di
Windows, Linux e FreeBSD, rendendola una soluzione versatile per diversi ambienti IT.

Sia che si stia consolidando server, che si estendono su provider cloud locali e iperscalabili o si
consentano ambienti di sviluppo e test flessibili, Hyper-V offre soluzioni scalabili per esigenze
IT moderne.

Hyper-V in Windows Server e Windows hanno funzionalità e funzionalità diverse, ma entrambi

offrono una solida base per la virtualizzazione. Hyper-V in Windows Server è progettato per le
distribuzioni aziendali con funzionalità avanzate come la migrazione in tempo reale, la
disponibilità elevata e il ripristino di emergenza. Hyper-V in Windows offre ai professionisti IT e
agli sviluppatori una soluzione leggera adatta per scenari di sviluppo e test.

Questa panoramica illustra i vantaggi, le funzionalità principali e i casi d'uso comuni di Hyper-V
e fornisce indicazioni su come iniziare.

Vantaggi di Hyper-V
Hyper-V offre vantaggi aziendali significativi in molte aree, tra cui:

Ottimizzazione dei costi: ridurre i costi di acquisizione e manutenzione hardware tramite

il consolidamento dei server, riducendo al contempo lo spazio dei data center,
l'alimentazione e i requisiti di raffreddamento. Le organizzazioni possono ottenere
rapporti di consolidamento elevati, riducendo drasticamente il costo totale di proprietà.
Hyper-V è incluso in Windows Server e Windows, eliminando i costi aggiuntivi delle
licenze degli hypervisor.
 Efficienza operativa: semplificare le operazioni IT con gestione centralizzata, provisioning
automatizzato e processi di backup e ripristino di emergenza semplificati. I modelli di
macchina virtuale e l'automazione di PowerShell riducono i tempi di distribuzione da ore
a minuti.

Agilità aziendale: effettuare rapidamente il provisioning di nuovi ambienti per supportare

iniziative aziendali, aumentare o ridurre le risorse in base alla domanda e adattarsi
rapidamente alle condizioni di mercato mutevoli senza cicli di approvvigionamento
hardware lunghi.

Sicurezza avanzata: implementare un isolamento sicuro del carico di lavoro, usare

macchine virtuali schermate per i dati sensibili e mantenere ambienti sicuri con
funzionalità come l'avvio protetto e il supporto TPM 2.0.

Miglioramento della resilienza: ridurre al minimo i tempi di inattività tramite funzionalità

di disponibilità elevata, implementare strategie di ripristino di emergenza complete con
replica Hyper-V e garantire la continuità aziendale con le funzionalità di migrazione in
tempo reale.

Accelerazione dello sviluppo: consente di creare rapidamente ambienti di sviluppo e test,

supportare le procedure DevOps con un'infrastruttura coerente e ridurre il time-to-
market per le nuove applicazioni e servizi.

Conformità semplificata: soddisfare i requisiti normativi più facilmente tramite

configurazioni coerenti, monitoraggio centralizzato e audit trail completi in ambienti
virtualizzati.

Funzionalità tecniche di Hyper-V

Ecco un video che offre una panoramica tecnica completa di Hyper-V, che illustra l'architettura
dell'hypervisor, le caratteristiche delle prestazioni e le funzionalità di scalabilità. Illustra come
Hyper-V offre funzionalità di virtualizzazione di livello aziendale, illustra funzionalità di
disponibilità elevata e clustering e presenta scenari di distribuzione reali per le organizzazioni
che cercano di implementare soluzioni di virtualizzazione.

[Link]

Le sezioni seguenti forniscono una panoramica di alcune delle principali funzionalità di livello
aziendale disponibili in Hyper-V che rispondono ai requisiti aziendali critici per la sicurezza, la
disponibilità, la gestione e l'ottimizzazione dei costi.

Estendibilità e integrazione
Un aspetto importante di Hyper-V è l'estendibilità e l'integrazione con altre funzionalità di
Windows Server e altri prodotti e servizi Microsoft e di terze parti per creare una soluzione di
virtualizzazione completa pronta per le distribuzioni aziendali.

Ad esempio, Hyper-V funziona perfettamente con Windows Server Failover Clustering per
offrire disponibilità elevata, si connette a una gamma di provider di archiviazione per opzioni di
archiviazione flessibili, supporta l'integrazione di Azure per scenari cloud ibridi e si integra con
Windows Admin Center o System Center Virtual Machine Manager per la gestione avanzata.

Hyper-V è anche un componente chiave di Azure Local , che consente alle organizzazioni di
eseguire servizi di Azure in locale con esperienze di gestione e sviluppo coerenti. Questa
integrazione consente scenari cloud ibridi in cui i carichi di lavoro possono essere spostati
senza problemi tra ambienti locali e Azure, offrendo flessibilità e scalabilità.

Sicurezza e isolamento
Le funzionalità di sicurezza affidabili consentono di proteggere le macchine virtuali e i relativi
dati, assicurandosi che i carichi di lavoro vengano eseguiti in ambienti isolati:

Le macchine virtuali schermate offrono una protezione completa per i carichi di lavoro
sensibili tramite la crittografia BitLocker, la verifica dell'avvio protetto e l'attestazione TPM
2.0. Il servizio Sorveglianza host (HGS) garantisce che solo gli host autorizzati possano
eseguire macchine virtuali schermate, proteggendo da amministratori compromessi e
utenti malintenzionati.

Le macchine virtuali di seconda generazione offrono sicurezza avanzata con firmware

UEFI, funzionalità di avvio protetto e resistenza al malware migliorata. Il supporto di TPM
virtuale 2.0 abilita la crittografia BitLocker all'interno dei sistemi operativi guest e
supporta l'autenticazione di Windows Hello for Business.

L'isolamento della rete tramite reti LAN virtuali (VLAN), commutatori virtuali privati e
SDN (Software-Defined Networking) crea segmenti di rete sicuri che impediscono lo
spostamento laterale non autorizzato tra i carichi di lavoro.

Flessibilità di archiviazione
Le opzioni di archiviazione flessibili soddisfano requisiti organizzativi diversi, dai dischi locali
alle soluzioni iperconvergenti convenienti alle distribuzioni SAN esistenti:

Spazi di archiviazione diretta crea un'infrastruttura iperconvergente raggruppando

l'archiviazione locale tra i nodi del cluster in un unico spazio dei nomi di archiviazione a
disponibilità elevata. Questa soluzione di archiviazione software-defined elimina i requisiti
SAN tradizionali offrendo funzionalità di livello aziendale, tra cui la tolleranza di errore, il
 ripristino automatico e l'ottimizzazione delle prestazioni. Le organizzazioni ottengono
costi di archiviazione inferiori rispetto alle soluzioni SAN tradizionali, ottenendo al
contempo una gestione semplificata e prestazioni migliorate tramite NVMe e il supporto
della memoria persistente.

Spazi di archiviazione consente architetture di archiviazione disaggregate tramite il

pooling di enclosure Just a Bunch of Disks (JBOD) in pool di archiviazione resilienti con
livelli di ridondanza configurabili. Questo approccio offre flessibilità per ridimensionare
l'archiviazione in modo indipendente dalle risorse di calcolo mantenendo la disponibilità
elevata tramite configurazioni mirror, parità o doppia parità.

Le opzioni di archiviazione locale supportano vari scenari di distribuzione dagli ambienti

di sviluppo usando unità singole ai carichi di lavoro di produzione con matrici NVMe.
L'archiviazione collegata diretta offre prestazioni ottimali per le applicazioni a elevato
utilizzo di I/O, riducendo al contempo la complessità per distribuzioni più piccole o
scenari di elaborazione perimetrale.

La connettività SAN supporta protocolli iSCSI e Fibre Channel per l'integrazione con
l'infrastruttura di archiviazione aziendale esistente. L'I/O multipath (MPIO) garantisce
disponibilità elevata e bilanciamento del carico tra più percorsi di archiviazione, mentre il
supporto per SMB 3.0 e NFS consente scenari di archiviazione basati su file con
funzionalità come il clustering di file server di scalabilità orizzontale e failover trasparente.

Disponibilità elevata e continuità aziendale

Le funzionalità complete di disponibilità elevata e continuità aziendale consentono di garantire
che i carichi di lavoro cruciali rimangano operativi:

Il clustering di failover con volumi condivisi cluster (CSV) consente il failover automatico
delle macchine virtuali tra nodi del cluster, fornendo tempo di attività prezioso per le
applicazioni cruciali. La migrazione in tempo reale consente la manutenzione pianificata
senza interruzioni del servizio. La cache CSV migliora le prestazioni memorizzando nella
cache i dati a cui si accede di frequente in memoria, mentre la cache a blocchi CSV usa la
memoria di sistema nei nodi avanzati di archiviazione per accelerare le operazioni di
lettura.

Hyper-V Replica offre un ripristino di emergenza conveniente replicando in modo

asincrono le macchine virtuali in siti secondari su connessioni di rete standard, eliminando
i costosi requisiti di replica SAN. Gli obiettivi del punto di ripristino (RPO) possono essere
fino a 30 secondi per garantire una perdita minima di dati.

La migrazione in tempo reale non consente lo spostamento di macchine virtuali tra host
senza archiviazione condivisa, consentendo l'allocazione flessibile delle risorse e il
 bilanciamento del carico nel cluster. Questa funzionalità supporta scenari in cui gli host
hanno configurazioni di archiviazione diverse o durante la migrazione di carichi di lavoro
tra siti distribuiti geograficamente.

La migrazione dell'archiviazione consente di spostare l'archiviazione di macchine virtuali

tra array di archiviazione diversi senza tempi di inattività, semplificando gli aggiornamenti
dell'archiviazione e il bilanciamento del carico nell'infrastruttura.

Azure Site Recovery estende Hyper-V funzionalità di ripristino di emergenza nel cloud,
offrendo replica, failover e failback automatizzati per le macchine virtuali. Questa
integrazione consente alle organizzazioni di usare Azure come sito secondario per il
ripristino di emergenza senza configurazioni complesse o hardware aggiuntivo.

Prestazioni e scalabilità
Prestazioni elevate e scalabilità consentono di soddisfare carichi di lavoro aziendali esigenti:

La memoria dinamica regola automaticamente l'allocazione di memoria in base alle

richieste effettive del carico di lavoro, ottimizzando l'utilizzo dell'host mantenendo al
tempo stesso le prestazioni. I rapporti di paging intelligente e overcommit della memoria
consentono rapporti di consolidamento più elevati.

il supporto diSR-IOV e RDMA offre prestazioni di rete quasi native ignorando

l'hypervisor per scenari di rete a larghezza di banda elevata e a bassa latenza.

Il partizionamento GPU (GPU-P) consente a più macchine virtuali di condividere risorse

GPU per carichi di lavoro di intelligenza artificiale e grafica.

L'integrazione della memoria persistente offre accesso all'archiviazione a bassa latenza

per i database e gli scenari di elaborazione in memoria.

Funzionalità di gestione avanzate

Una gamma di strumenti di gestione e funzionalità di automazione semplificano le operazioni
e migliorano la produttività:

Windows Admin Center offre una gestione moderna basata sul Web con monitoraggio
dell'infrastruttura iperconvergente, analisi delle prestazioni e flussi di lavoro semplificati
per la risoluzione dei problemi accessibili da qualsiasi dispositivo.

Hyper-V Manager offre una gestione grafica intuitiva per le operazioni quotidiane,
mentre il modulo Hyper-V per Windows PowerShell consente scenari avanzati di scripting
e automazione.
 System Center Virtual Machine Manager offre una gestione su scala aziendale con
provisioning automatizzato, monitoraggio della conformità, pianificazione della capacità e
portali self-service per l'amministrazione delegata.

PowerShell Direct consente la gestione sicura delle macchine virtuali senza connettività di
rete, semplificando l'automazione e la risoluzione dei problemi. La libreria di cmdlet di
PowerShell completa supporta le procedure relative all'infrastruttura come codice.

Integrazione facile di Active Directory come Hyper-V usa l'infrastruttura di

autenticazione di Windows esistente senza configurazione aggiuntiva. Gli host aggiunti a
un dominio ereditano automaticamente le impostazioni di Criteri di gruppo e le
configurazioni di sicurezza esistenti.

Funzionalità di ottimizzazione dei costi

Ottimizzare i costi associati alla virtualizzazione:

Le licenze esistenti di Windows Server consentono di eseguire macchine virtuali senza

costi aggiuntivi per le licenze degli hypervisor. Hyper-V è incluso in Windows Server e
Windows, con l'edizione Datacenter di Windows Server che offre diritti illimitati per le
macchine virtuali, ovvero è possibile eseguire macchine virtuali Windows Server senza
costi aggiuntivi. Questo approccio semplifica i calcoli delle licenze e riduce i costi
complessivi.

La deduplicazione e la compressione riducono notevolmente i requisiti di archiviazione

in scenari quali l'infrastruttura VDI (Virtual Desktop Infrastructure) e il backup dei dati.

La virtualizzazione annidata consente l'esecuzione di hypervisor all'interno di macchine

virtuali, il supporto di scenari di sviluppo e ambienti cloud multi-tenant senza hardware
aggiuntivo.

Vantaggi per sviluppatori e professionisti IT

Hyper-V sia in Windows Server che in Windows Server offre agli sviluppatori e ai professionisti
IT potenti funzionalità di virtualizzazione che accelerano i flussi di lavoro di sviluppo e
semplificano le operazioni IT per ambienti Windows e Linux. Gli sviluppatori possono creare
rapidamente ambienti di sviluppo e test isolati che rispecchiano le configurazioni di
produzione, consentendo loro di testare le applicazioni in più sistemi operativi e versioni senza
richiedere hardware dedicato. I professionisti IT traggono vantaggio dalla possibilità di
effettuare rapidamente il provisioning degli ambienti sandbox per testare patch, aggiornamenti
e nuove configurazioni prima della distribuzione nei sistemi di produzione.
La possibilità di creare snapshot delle macchine virtuali prima di apportare modifiche fornisce
una rete di sicurezza per scenari di sperimentazione e rollback, mentre i modelli di macchina
virtuale e l'automazione di PowerShell consentono il provisioning coerente dell'ambiente in
pochi minuti anziché in ore. Questa funzionalità è utile sia per i team di sviluppo che per la
creazione di ambienti di compilazione standardizzati e per i team IT che mantengono
configurazioni coerenti dell'infrastruttura.

Per gli utenti di Windows 11, Hyper-V offre creazione rapida per la configurazione semplificata
delle macchine virtuali, semplificando lo spin up degli ambienti di sviluppo per progetti diversi
o creando ambienti di test isolati per gli scenari di valutazione IT. L'integrazione con Visual
Studio e gli strumenti di sviluppo, combinati con funzionalità come la virtualizzazione annidata,
consente agli sviluppatori di creare applicazioni complesse multilivello e testare i carichi di
lavoro in contenitori in locale, mentre i professionisti IT possono valutare nuove tecnologie e
soluzioni in ambienti isolati.

Introduzione a Hyper-V
Hyper-V è facilmente disponibile come ruolo del server in tutte le edizioni di Windows Server
2025, con più opzioni di installazione per soddisfare esigenze organizzative diverse. Le
organizzazioni possono scegliere tra Server con Esperienza desktop per la gestione completa
dell'interfaccia utente grafica o Server Core per ridurre la superficie di attacco e l'utilizzo delle
risorse.

Per Windows 11, Hyper-V è incluso nelle edizioni Pro, Enterprise ed Education, consentendo
agli sviluppatori e ai professionisti IT di usare le funzionalità di virtualizzazione direttamente nei
desktop.

Installare Hyper-V

Contenuti correlati
Ecco alcune risorse aggiuntive che consentono di ottenere altre informazioni su Hyper-V e sulle
relative funzionalità:

Requisiti hardware per Hyper-V.

Pianificare la rete di Hyper-V.
Architetture di archiviazione per Hyper-V.
Generazioni di macchine virtuali.
Sistemi operativi di macchine virtuali Windows supportati.
Sistemi operativi di macchine virtuali Linux e FreeBSD supportati.
） Nota: L'autore ha creato questo articolo con l’assistenza dell'intelligenza artificiale. Ulteriori informazioni
Hyper-V funzionalità e terminologia
14/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Hyper-V include molte funzionalità e termini specifici per la virtualizzazione. Questo articolo
offre una panoramica delle funzionalità e della terminologia di Hyper-V più comuni, che
consentono di comprendere e ottimizzare l'ambiente di virtualizzazione e migliorare le
prestazioni. Le caratteristiche e i termini sono raggruppati in categorie per un riferimento più
semplice.

Generazioni di macchine virtuali

Hyper-V supporta due generazioni di macchine virtuali che determinano le funzionalità
disponibili e l'hardware virtuale:

Le macchine virtuali di seconda generazione usano firmware BIOS legacy e offrono

compatibilità con applicazioni legacy che richiedono supporto hardware meno recente,
inclusi sistemi a 32 bit e emulazione hardware legacy, ad esempio controller IDE e file di
dischi floppy virtuali.

Le macchine virtuali di seconda generazione usano firmware UEFI moderno e offrono

funzionalità di sicurezza avanzate, ad esempio Avvio protetto e vTPM, prestazioni
migliorate, supporto di avvio SCSI e funzionalità di aggiunta/rimozione ad accesso
frequente per schede di rete e memoria. La maggior parte dei carichi di lavoro è
consigliata per la maggior parte delle macchine virtuali di seconda generazione.

Non è possibile modificare la generazione di una macchina virtuale dopo la creazione, quindi
scegliere attentamente in base alle esigenze. Per altre informazioni, vedere Generazioni di
macchine virtuali.

Processore/CPU
Hyper-V supporta diverse funzionalità e funzionalità del processore per ottimizzare le
prestazioni e la compatibilità delle macchine virtuali, descritte nelle sezioni seguenti.

Compatibilità del processore

Per impostazione predefinita, i set di istruzioni del processore passano alle macchine virtuali
dall'host Hyper-V. La modalità di compatibilità del processore consente alle macchine virtuali di
essere eseguite in host Hyper-V con generazioni di processori diverse mascherando le
funzionalità e le istruzioni più recenti della CPU, fornendo una commonalità fissa. Con Hyper-V
host che eseguono Windows Server, è possibile usare la migrazione in tempo reale per
spostare le macchine virtuali tra host con modelli di processore diversi all'interno della stessa
famiglia di fornitori. Le macchine virtuali rimangono portabili nell'infrastruttura Hyper-V anche
quando l'hardware varia, ad esempio la migrazione di macchine virtuali a un nuovo cluster o la
sostituzione dell'hardware.

La compatibilità del processore dinamico, introdotta in Windows Server 2025, calcola in modo
dinamico il set comune di funzionalità del processore in tutti i nodi, consentendo alle macchine
virtuali di sfruttare le funzionalità massime disponibili nel cluster.

Per altre informazioni, vedere Modalità di compatibilità del processore.

Controllo delle risorse

Il controllo delle risorse in Hyper-V consente di gestire e allocare risorse della CPU per le
macchine virtuali. È possibile impostare limiti, riserve e pesi per l'utilizzo della CPU,
assicurandosi che i carichi di lavoro critici ricevano le risorse necessarie impedendo al tempo
stesso la contesa delle risorse tra le macchine virtuali.

NUMA
L'accesso non uniforme alla memoria (NUMA) è un'architettura di memoria che consente a più
processori di accedere alla memoria in modo da ottimizzare le prestazioni. Hyper-V supporta le
configurazioni NUMA, consentendo alle macchine virtuali di sfruttare la topologia NUMA
dell'hardware sottostante per migliorare l'accesso alla memoria e le prestazioni.

Lo spanning NUMA è una funzionalità che consente alle macchine virtuali di usare la memoria
da più nodi NUMA, che possono essere utili per i carichi di lavoro che richiedono grandi
quantità di memoria o hanno requisiti elevati di larghezza di banda della memoria. Questa
funzionalità è utile negli scenari in cui le macchine virtuali devono accedere a più memoria o
processori virtuali rispetto a quelli disponibili in un singolo nodo NUMA. NUMA virtuale
presenta la topologia NUMA dell'host al sistema operativo della macchina virtuale.

Memoria
Hyper-V offre diverse funzionalità di gestione della memoria per ottimizzare l'utilizzo delle
risorse e le prestazioni per le macchine virtuali, descritte nelle sezioni seguenti.

Memoria dinamica
Hyper-V gli host possono regolare dinamicamente la quantità di memoria allocata a una
macchina virtuale in base al carico di lavoro corrente mentre è in funzione, in base ai valori
massimi, minimi e di avvio. L'aumento dinamico o la riduzione dell'allocazione di memoria in
base alle esigenze consente di ottimizzare l'utilizzo delle risorse assicurando che le macchine
virtuali abbiano la giusta quantità di memoria per i carichi di lavoro senza sprecare risorse.

Il sistema operativo della macchina virtuale deve supportare la memoria dinamica e deve
essere abilitato nelle impostazioni della macchina virtuale. Tutti i sistemi operativi Windows
Server e Windows supportati supportano la memoria dinamica, come molte distribuzioni Linux.

File di paging intelligente

Il paging intelligente offre un sollievo temporaneo della memoria quando la domanda di
memoria di una macchina virtuale supera la memoria fisica disponibile durante l'avvio. Hyper-V
crea un file di paging intelligente su disco che funge da buffer di memoria temporaneo,
consentendo alla macchina virtuale di avviarsi correttamente anche in condizioni con vincoli di
memoria. Questa funzionalità è utile negli ambienti in cui le macchine virtuali potrebbero
richiedere temporaneamente più memoria di quanto inizialmente allocato, consentendo di
evitare errori di avvio mantenendo la stabilità del sistema.

Peso della memoria

Il peso della memoria può classificare in ordine di priorità l'allocazione di memoria per le
macchine virtuali in base all'importanza o ai requisiti del carico di lavoro. Assegnando pesi di
memoria diversi alle macchine virtuali, è possibile controllare il modo in cui le risorse di
memoria vengono distribuite tra di esse, assicurandosi che i carichi di lavoro critici ricevano la
memoria necessaria impedendo al tempo stesso la contesa delle risorse.

Supporto del kernel dell'estensione dell'indirizzo fisico

La tecnologia PAE (Physical Address Extension) consente a un kernel Linux a 32 bit di accedere
a uno spazio indirizzi fisico maggiore di 4 GB. Distribuzioni di Linux precedenti, ad esempio
RHEL 5. x utilizzato per fornire un kernel separato che è stato PAE attivata. Le distribuzioni più
recenti includono il supporto PAE predefinito.

Sicurezza
Hyper-V fornisce diverse funzionalità di sicurezza per proteggere le macchine virtuali e i relativi
dati, illustrati nelle sezioni seguenti. Queste funzionalità consentono di garantire l'integrità, la
riservatezza e la disponibilità dei carichi di lavoro virtualizzati.
Avvio protetto
L'avvio protetto consente di proteggere le macchine virtuali dall'esecuzione di codice non
autorizzato durante il processo di avvio. Garantisce che vengano caricati solo componenti di
avvio attendibili e firmati, impedendo al malware o al software non autorizzato di
compromettere l'integrità della macchina virtuale. L'avvio protetto è disponibile per le
macchine virtuali di seconda generazione con sistemi operativi Windows e Linux ed è abilitato
per impostazione predefinita.

Per altre informazioni, vedere Avvio protetto.

Supporto della crittografia

La crittografia per le macchine virtuali consente di proteggere i dati inattivi e in transito.
Questo supporto include opzioni per un TPM (Trusted Platform Module), lo stato salvato della
macchina virtuale e il traffico di rete della migrazione in tempo reale.

Il TPM virtuale è disponibile per le macchine virtuali di seconda generazione e consente al

sistema operativo delle macchine virtuali di usare funzioni di sicurezza basate su hardware
simili a quelle disponibili nei computer fisici. Un TPM è utile per scenari che richiedono una
sicurezza avanzata, ad esempio l'esecuzione della crittografia delle unità Windows 11 o
BitLocker, che richiedono un TPM.

Sia le macchine virtuali di prima generazione che le macchine virtuali di seconda generazione
possono crittografare lo stato salvato della macchina virtuale e il traffico di rete della
migrazione in tempo reale con una protezione con chiave. Per altre informazioni, vedere Unità
di archiviazione chiavi

Macchine virtuali schermate

Le macchine virtuali schermate forniscono un ambiente sicuro per carichi di lavoro sensibili con
un ulteriore livello di sicurezza proteggendo le macchine virtuali da accessi non autorizzati e
manomissioni, ad esempio da un host compromesso. Queste macchine virtuali funzionano con
l'infrastruttura sorvegliata in modo che possano essere eseguite solo su host integri e
approvati nell'infrastruttura e usano la crittografia, l'avvio protetto e un TPM virtuale per
garantire che solo il codice attendibile venga eseguito all'interno della macchina virtuale. La
schermatura è disponibile per le macchine virtuali di seconda generazione.

Un caso d'uso di esempio per le macchine virtuali schermate e l'infrastruttura sorvegliata

consente ai provider di servizi cloud di fornire un ambiente più sicuro per le macchine virtuali
tenant.
Per ulteriori informazioni, consultare l'argomento Panoramica sulle infrastrutture protette e le
macchine virtuali schermate.

Immagazzinamento
Hyper-V offre varie funzionalità di archiviazione per gestire i dischi delle macchine virtuali e
ottimizzare le prestazioni di archiviazione, descritte nelle sezioni seguenti.

Architetture di archiviazione
Hyper-V supporta un'ampia gamma di architetture di archiviazione per soddisfare diversi
requisiti di archiviazione e esigenze di prestazioni. Puoi usare:

Reti di archiviazione (SAN) per soluzioni di archiviazione ad alte prestazioni che

forniscono l'accesso a livello di blocco ai file delle macchine virtuali.

Spazi di archiviazione diretta per la creazione di soluzioni di archiviazione a disponibilità

elevata e scalabilità usando dischi locali in più server. Spazi di archiviazione diretta fa
parte di Windows Server e consente di creare una soluzione di archiviazione software-
defined che offre ridondanza, prestazioni e scalabilità, con architetture di archiviazione
iperconvergente o disaggregate.

Archiviazione nas (Network Attached Storage) per l'archiviazione condivisa tra più host
Hyper-V, abilitando la disponibilità elevata e il clustering di failover.

Archiviazione locale, con NVMe, SSD o HDD, per l'accesso rapido ai file delle macchine
virtuali.

È possibile usare una combinazione di queste architetture di archiviazione per soddisfare i

requisiti specifici. Per altre informazioni, vedere Architetture di archiviazione per Hyper-V.

Dischi rigidi virtuali

I dischi rigidi virtuali sono file che rappresentano il disco rigido di una macchina virtuale.
Hyper-V supporta due tipi di formati di disco rigido virtuale:

VHD: il formato originale, che supporta fino a 2 TB di spazio di archiviazione.

VHDX: il formato più recente, che supporta fino a 64 TB di spazio di archiviazione. VHDX
offre diversi vantaggi, tra cui prestazioni migliori, protezione avanzata del
danneggiamento dei dati, ridimensionamento online, supporto per dimensioni di settore
logiche maggiori (4 KB) e allineamento automatico dei dati e taglio per un migliore
utilizzo dello spazio di archiviazione.
I dischi rigidi virtuali offrono un modo flessibile ed efficiente per gestire l'archiviazione delle
macchine virtuali con funzionalità come:

Dischi differenze: creare un nuovo disco in base a un disco padre esistente. Le modifiche
apportate al disco differenze non influiscono sul disco padre, consentendo di mantenere
un'immagine di base pulita, consentendo al tempo stesso di apportare modifiche al disco
differenze. I dischi differenze sono utili per scenari quali test, sviluppo o creazione di
snapshot di macchine virtuali.

Dischi pass-through: dischi fisici collegati direttamente a una macchina virtuale,

ignorando il livello del disco rigido virtuale. La macchina virtuale può accedere
direttamente al disco fisico, offrendo prestazioni migliori per determinati carichi di lavoro
che richiedono l'accesso a disco di basso livello. I dischi pass-through vengono in genere
usati per applicazioni ad alte prestazioni o scenari in cui è necessario l'accesso diretto al
disco fisico.

Unità condivise: più macchine virtuali possono accedere contemporaneamente allo

stesso disco rigido virtuale per le macchine virtuali di seconda generazione. Le unità
condivise sono utili per scenari come il clustering o la disponibilità elevata, in cui più
macchine virtuali devono condividere dati o risorse.

Qualità del servizio di archiviazione: gestire e controllare le prestazioni dell'archiviazione

delle macchine virtuali impostando limiti minimo e massimo di operazioni di input/output
al secondo (IOPS) per i dischi rigidi virtuali. I carichi di lavoro critici ricevono le prestazioni
di archiviazione necessarie impedendo al tempo stesso la contesa delle risorse tra le
macchine virtuali.

Fibre Channel virtuale

Il supporto per le schede Fibre Channel virtuali consente alle macchine virtuali di connettersi
direttamente alle reti di archiviazione Fibre Channel , consentendo loro di accedere alle risorse
SAN come se fossero server fisici. Questa funzionalità è utile per gli scenari in cui è necessario
l'accesso alle risorse di archiviazione ad alte prestazioni, ad esempio in ambienti aziendali con
database di grandi dimensioni o applicazioni cruciali.

La rete SAN Fibre Channel virtuale aggrega più dispositivi di archiviazione fisica in un singolo
pool di archiviazione logico. È possibile aggiungere una scheda Fibre Channel virtuale a una
macchina virtuale per connetterla alla san Fibre Channel virtuale.

Rete
Hyper-V fornisce varie funzionalità di rete per gestire la connettività delle macchine virtuali e
ottimizzare le prestazioni di rete, descritte nelle sezioni seguenti. Per altre informazioni sulla
rete Hyper-V, vedere Pianificare Hyper-V rete.

Commutatore virtuale
Un commutatore virtuale è un commutatore di rete basato su software che consente alle
macchine virtuali di comunicare tra loro e con la rete esterna. Hyper-V supporta tre tipi di
commutatori virtuali:

Esterno: connette le macchine virtuali alla rete fisica, consentendo loro di comunicare con
dispositivi e servizi esterni.

Interno: consente la comunicazione tra macchine virtuali nello stesso host e con il sistema
operativo host, ma non con la rete esterna.

Privato: consente la comunicazione solo tra macchine virtuali nello stesso host, senza
connettività al sistema operativo host o alla rete esterna.

Scheda di rete virtuale

Le schede di rete virtuali sono schede di interfaccia di rete virtualizzate che consentono alle
macchine virtuali di connettersi ai commutatori virtuali e comunicare con altre macchine virtuali
o reti esterne. Per impostazione predefinita, le schede di rete virtuale sono ad alte prestazioni e
usano driver sintetici, che offrono prestazioni migliori e un sovraccarico inferiore della CPU
rispetto alle schede di rete legacy.

Sono disponibili anche schede di rete legacy che offrono compatibilità con sistemi operativi o
applicazioni meno recenti che non supportano schede sintetiche.

Le schede di rete virtuali possono essere configurate con varie impostazioni, ad esempio:

Indirizzi MAC statici o dinamici: assegnare un indirizzo MAC statico a una scheda di rete
virtuale o consentire Hyper-V di assegnarne uno in modo dinamico.

Spoofing degli indirizzi MAC: consente alle macchine virtuali di modificare gli indirizzi
MAC, che possono essere utili per scenari come test di rete o analisi della sicurezza.

Supporto VLAN: le schede di rete virtuale possono essere configurate per l'uso di VLAN
(reti locali virtuali) per la segmentazione e l'isolamento della rete.

Gestione della larghezza di banda: impostare i limiti di larghezza di banda per le schede
di rete virtuali per controllare il traffico di rete e garantire un'allocazione equa delle
risorse tra le macchine virtuali.
Virtualizzazione di rete: creare reti virtuali isolate che possono coesistere nella stessa
infrastruttura fisica. La virtualizzazione di rete è utile per scenari come ambienti multi-
tenant o test di configurazioni di rete diverse senza influire sulla rete fisica.

Offload delle attività IPsec: le macchine virtuali possono eseguire l'offload

dell'elaborazione IPsec nella scheda di rete dell'host, migliorando le prestazioni e
riducendo il sovraccarico della CPU per la comunicazione di rete sicura.

Protezione DHCP: impedisce alle macchine virtuali di fungere da server DHCP,

assicurandosi che solo i server DHCP autorizzati possano fornire indirizzi IP alle macchine
virtuali nella rete.

Protezione degli annunci router: impedisce alle macchine virtuali di inviare annunci
router, assicurandosi che solo i router autorizzati possano annunciare la loro presenza
sulla rete.

Rete protetta: creare un ambiente di rete sicuro per le macchine virtuali, assicurandosi
che solo le macchine virtuali autorizzate possano comunicare tra loro e con la rete
esterna.

Mirroring delle porte: monitorare il traffico di rete eseguendo il mirroring del traffico di
una scheda di rete virtuale a un'altra scheda di rete virtuale o a una scheda di rete fisica. Il
mirroring delle porte è utile per scenari come la risoluzione dei problemi di rete, il
monitoraggio delle prestazioni o l'analisi della sicurezza.

Gruppo NIC: combinare più schede di rete fisiche in una singola scheda logica per
migliorare le prestazioni e la ridondanza. Questa funzionalità è utile per gli scenari in cui è
necessaria una velocità effettiva di rete elevata o una tolleranza di errore.

Denominazione dei dispositivi della scheda di interfaccia di rete: assegnare nomi

personalizzati alle schede di rete virtuali, semplificando l'identificazione e la gestione nelle
Hyper-V Manager o PowerShell. Disponibile solo per le macchine virtuali di seconda
generazione.

Gruppo NIC nel guest: configurare il raggruppamento NIC all'interno della macchina
virtuale stessa, consentendo alla macchina virtuale di sfruttare più schede di rete per
migliorare le prestazioni e la ridondanza.

Inserimento ip statico per il failover di replica Hyper-V: inserire indirizzi IP statici nelle
macchine virtuali durante il failover di replica Hyper-V, assicurandosi che le macchine
virtuali possano mantenere la connettività di rete dopo il failover. Supporta sia gli indirizzi
IPv4 che IPv6.
 Coda di macchine virtuali (VMQ): le macchine virtuali possono eseguire l'offload
dell'elaborazione di rete alla scheda di rete dell'host, migliorando le prestazioni di rete e
riducendo il sovraccarico della CPU per i carichi di lavoro a elevato utilizzo di rete.

Single Root I/O Virtualization (SR-IOV): le macchine virtuali possono accedere

direttamente all'hardware di rete fisico, offrendo prestazioni migliorate e una latenza
ridotta per i carichi di lavoro a elevato utilizzo di rete. SR-IOV è utile per gli scenari in cui
l'accesso alla rete a bassa latenza è fondamentale, ad esempio nelle applicazioni di
trading ad alta frequenza o elaborazione dati in tempo reale.

Controller e porte
Hyper-V supporta vari controller e porte per gestire l'hardware e la connettività delle macchine
virtuali.

Controller SCSI: connettere dischi rigidi virtuali e unità DVD a una macchina virtuale come
dispositivi SCSI. Offre prestazioni e flessibilità migliori rispetto ai controller IDE, in
particolare per le macchine virtuali di seconda generazione.

Controller IDE: connettere dischi rigidi virtuali e unità DVD a una macchina virtuale come
dispositivi IDE. I controller IDE sono disponibili solo per le macchine virtuali di prima
generazione.

Porte COM: connettere dispositivi seriali o applicazioni tramite una named pipe su un
host o un computer remoto. Le porte COM sono disponibili solo per le macchine virtuali
di prima generazione.

Scheda Fibre Channel: connettere le macchine virtuali alle reti di archiviazione Fibre
Channel per l'accesso alle risorse di archiviazione ad alte prestazioni, ad esempio in
ambienti aziendali con database di grandi dimensioni o applicazioni cruciali.

Unità disco: connettere i file del disco floppy virtuale ( .vfd ) alle macchine virtuali di
prima generazione. I dischi floppy virtuali vengono usati per l'avvio da immagini disco
floppy o per applicazioni legacy che richiedono il supporto del disco floppy.

Servizi di Integrazione
Integration Services in Hyper-V è un set di servizi e driver che migliorano le prestazioni e le
funzionalità delle macchine virtuali. Per altre informazioni su Integration Services, vedere
Hyper-V Integration Services.
 Arresto del sistema operativo: l'host può arrestare normalmente una macchina virtuale
quando l'host stesso viene arrestato o quando la macchina virtuale viene arrestata. Il
sistema operativo guest può eseguire un arresto pulito, impedendo la perdita o il
danneggiamento dei dati.

Sincronizzazione dell'ora: sincronizzare l'orologio del sistema operativo guest con

l'orologio dell'host, assicurando un tempo accurato all'interno della macchina virtuale. La
sincronizzazione dell'ora è importante per le applicazioni che si basano su timestamp
accurati o operazioni sensibili al tempo. Hyper-V beneficia dei miglioramenti
dell'accuratezza dell'ora, introdotti per la prima volta in Windows Server 2016, che offre
una sincronizzazione dell'ora più accurata tra i sistemi operativi host e guest. Per altre
informazioni, vedere Miglioramenti dell'accuratezza del tempo per Windows Server 2016.

Scambio di dati: un meccanismo per lo scambio di dati tra l'host e il sistema operativo
guest, consentendo all'host di recuperare informazioni sulla macchina virtuale, ad
esempio il nome, l'indirizzo IP e altri dettagli di configurazione.

Heartbeat: meccanismo di heartbeat che consente all'host di monitorare l'integrità e lo

stato della macchina virtuale. L'host può rilevare se il sistema operativo guest è reattivo o
non risponde, abilitando la gestione proattiva e la risoluzione dei problemi.

Backup (copia shadow del volume): usa il servizio Copia Shadow del volume per creare
backup coerenti con l'applicazione delle macchine virtuali, assicurandosi che i dati siano
in uno stato coerente durante le operazioni di backup.

Servizi guest: fornisce un'interfaccia per l'host Hyper-V per copiare i file in modo
bidirezionale da o verso la macchina virtuale. I servizi guest non sono abilitati per
impostazione predefinita.

Punti di controllo
I checkpoint consentono di acquisire lo stato di una macchina virtuale in un momento
specifico. È possibile usare il checkpoint per eseguire il rollback a tale punto, che può essere
utile a scopo di test, sviluppo o ripristino. Esistono due tipi di checkpoint:

Checkpoint di produzione: questi checkpoint usano il servizio Copia Shadow del volume
per creare snapshot coerenti con l'applicazione della macchina virtuale. Sono adatti per
gli ambienti di produzione e assicurano che i dati della macchina virtuale siano in uno
stato coerente.

Checkpoint standard: acquisisce lo stato della macchina virtuale (in esecuzione o spento),
inclusi gli stati di memoria, disco e dispositivo. Sono adatti per scenari di test e sviluppo,
ma non sono coerenti con l'applicazione.
I checkpoint automatici facoltativi creano automaticamente un checkpoint all'avvio e al merge
di una macchina virtuale quando la macchina virtuale viene arrestata, consentendo di
ripristinare rapidamente uno stato valido noto se si dimentica di creare manualmente un
checkpoint.

Per altre informazioni sui checkpoint, vedere Hyper-V checkpoint.

Migrazione e replica
La migrazione e la replica sono funzionalità essenziali per mantenere la disponibilità elevata e
la flessibilità negli ambienti Hyper-V, illustrati nelle sezioni seguenti.

Migrazione Live
La migrazione in tempo reale consente di spostare una macchina virtuale in esecuzione da un
host Hyper-V a un altro senza tempi di inattività. La migrazione di macchine virtuali è utile per
scenari di bilanciamento del carico, manutenzione hardware o ripristino di emergenza. La
migrazione in tempo reale può essere eseguita su una rete usando una rete dedicata SMB o
TCP/IP e può anche usare RDMA (Remote Direct Memory Access) per trasferimenti più veloci.
La migrazione in tempo reale è disponibile solo per Hyper-V in Windows Server.

È possibile eseguire la migrazione di macchine virtuali tra host nello stesso cluster o tra host
autonomi. In un cluster è possibile configurare il bilanciamento automatico per eseguire
automaticamente la migrazione delle macchine virtuali in base all'utilizzo delle risorse host,
garantendo prestazioni ottimali e allocazione delle risorse.

Per altre informazioni sulla migrazione in tempo reale, vedere Panoramica di Live Migration.

Migrazione dell'archiviazione
La migrazione dell'archiviazione consente di spostare i file di archiviazione di una macchina
virtuale (ad esempio i dischi rigidi virtuali) da una posizione a un'altra senza tempi di inattività.
La migrazione dell'archiviazione è utile per scenari come lo spostamento di macchine virtuali in
dispositivi di archiviazione diversi, l'ottimizzazione delle prestazioni di archiviazione o la
riorganizzazione delle risorse di archiviazione. La migrazione dell'archiviazione è disponibile
solo per Hyper-V in Windows Server.

Duplicazione
Hyper-V Replica consente di replicare le macchine virtuali in modo asincrono da un host
Hyper-V a un altro per mantenere una copia secondaria di una macchina virtuale in un host
diverso a scopo di ripristino di emergenza. Hyper-V Replica è disponibile solo per Hyper-V in
Windows Server.

La replica può essere configurata per replicare le macchine virtuali tra host nello stesso cluster
o tra host autonomi. Supporta la replica completa e incrementale, consentendo di scegliere il
livello di replica in base alle esigenze.

La replica può essere configurata con varie opzioni, ad esempio:

Frequenza di replica: configurare la frequenza di replica, ad esempio ogni 30 secondi, 5

minuti o 15 minuti, per bilanciare le prestazioni e la coerenza dei dati.

Autenticazione: supporta l'autenticazione kerberos e basata su certificati per la replica

sicura.

Compressione: comprimere i dati durante il trasferimento per ridurre l'utilizzo della

larghezza di banda.

Punti di ripristino: specificare il numero di punti di ripristino da conservare per ogni

macchina virtuale replicata, consentendo di eseguire il ripristino in un momento specifico.

Snapshot vss: Hyper-V replica usa il servizio Copia Shadow del volume per creare
snapshot coerenti con l'applicazione delle macchine virtuali durante la replica. Vss
garantisce che i dati replicati siano in uno stato coerente, anche per le applicazioni in
esecuzione all'interno della macchina virtuale.

Esclusione dei dischi dalla replica: è possibile escludere dischi rigidi virtuali specifici dalla
replica, consentendo di controllare quali dischi vengono replicati e quali non sono.

Per altre informazioni su Hyper-V Replica, vedere Configurare Hyper-V Replica.

Grafica
Le GPU possono essere usate per migliorare le funzionalità grafiche delle macchine virtuali in
ambienti Hyper-V, abilitando scenari che richiedono rendering grafico ad alte prestazioni, ad
esempio giochi, modellazione 3D o modifica video.

Hyper-V supporta due opzioni per l'utilizzo della GPU nelle macchine virtuali:

Assegnazione di dispositivi discreti: assegnare una GPU fisica direttamente a una

macchina virtuale, fornendo l'accesso esclusivo alle risorse della GPU. L'assegnazione di
dispositivi discreti è adatta agli scenari in cui è necessaria l'elaborazione grafica ad alte
prestazioni, ad esempio l'esecuzione di applicazioni o giochi a elevato utilizzo di grafica
all'interno della macchina virtuale.
 Partizionamento GPU: allocare una parte delle risorse di una GPU fisica a più macchine
virtuali, consentendo loro di condividere la GPU per l'elaborazione grafica. Il
partizionamento GPU è utile per scenari in cui più macchine virtuali devono accedere alle
funzionalità grafiche senza richiedere GPU dedicate per ognuna di esse.

Per altre informazioni sull'accelerazione GPU in Hyper-V, vedere Pianificare l'accelerazione GPU.

Virtualizzazione annidata
La virtualizzazione annidata consente di eseguire Hyper-V all'interno di una macchina virtuale
per eseguire più macchine virtuali, abilitando scenari come test, sviluppo o training senza
richiedere hardware fisico. Questa funzionalità è utile per gli scenari in cui si desidera creare e
gestire macchine virtuali all'interno di un ambiente virtualizzato, ad esempio l'esecuzione di
Hyper-V in un computer portatile o desktop.

La virtualizzazione annidata è disponibile per le macchine virtuali di seconda generazione. Per

altre informazioni sulla virtualizzazione annidata, vedere Informazioni sulla virtualizzazione
annidata.

Gestione
Per gestire Hyper-V ambienti e macchine virtuali, è possibile usare vari strumenti e interfacce:

Hyper-V Manager: uno strumento interfaccia utente grafica (GUI) predefinito per la
gestione di host e macchine virtuali Hyper-V. Offre un modo semplice per creare,
configurare e gestire le macchine virtuali. Per altre informazioni su Hyper-V Manager,
vedere Gestire in remoto gli host Hyper-V con Hyper-V Manager.

Windows Admin Center: uno strumento di gestione basato sul Web che fornisce
un'interfaccia centralizzata per la gestione di host e macchine virtuali Hyper-V, insieme ad
altre funzionalità di Windows Server. Per altre informazioni sull'uso di Windows Admin
Center per la gestione di Hyper-V, vedere Gestire le macchine virtuali tramite Windows
Admin Center.

PowerShell: un'interfaccia della riga di comando potente che consente di automatizzare e

creare script Hyper-V attività di gestione. PowerShell offre un set completo di cmdlet per
la gestione di macchine virtuali, host e altre funzionalità di Hyper-V. Per altre informazioni
sull'uso di PowerShell per la gestione di Hyper-V, vedere Uso di Hyper-V e Windows
PowerShell.

System Center Virtual Machine Manager: una soluzione di gestione completa per
ambienti di Hyper-V su larga scala. Virtual Machine Manager offre funzionalità avanzate
 per la gestione di macchine virtuali, host, archiviazione e rete, oltre al supporto per
ambienti multi-hypervisor. Per altre informazioni su Virtual Machine Manager, vedere
Informazioni su Virtual Machine Manager.

Accesso alla console

L'accesso alla console consente di interagire con le macchine virtuali tramite un'interfaccia
utente grafica (GUI) o un'interfaccia della riga di comando. Hyper-V supporta diversi metodi
per l'accesso alla console:

Connessione macchina virtuale: uno strumento predefinito in Hyper-V Manager che

fornisce l'accesso alla console per la connessione e la gestione delle macchine virtuali.
Consente di interagire con il desktop della macchina virtuale, eseguire attività
amministrative e risolvere i problemi. Viene anche definito VMConnect. Per altre
informazioni sulla connessione alla macchina virtuale, vedere Hyper-V Connessione
macchina virtuale.

Modalità sessione avanzata: parte della connessione alla macchina virtuale, connettersi a
una macchina virtuale usando Remote Desktop Protocol (RDP) tramite una connessione
diretta tramite l'host Hyper-V. Poiché usa RDP, supporta anche RemoteFX che offre
funzionalità aggiuntive, ad esempio la condivisione degli Appunti, il reindirizzamento
delle unità e il reindirizzamento della stampante. La modalità sessione avanzata è
disponibile per le macchine virtuali di seconda generazione e richiede il supporto del
sistema operativo della macchina virtuale. Per altre informazioni sulla modalità sessione
avanzata, vedere Usare le risorse locali in Hyper-V macchina virtuale con VMConnect.

PowerShell Direct: eseguire comandi di PowerShell direttamente in una macchina virtuale

dall'host Hyper-V senza richiedere la connettività di rete. Offre un modo sicuro per gestire
le macchine virtuali senza esporle alla rete. Per altre informazioni su PowerShell Direct,
vedere Gestire macchine virtuali Windows con PowerShell Direct.

Risparmio energia
Hyper-V consente di controllare l'avvio e l'arresto delle macchine virtuali in un host:

Azione di avvio automatico: specifica l'azione da eseguire all'avvio del servizio Hyper-V e
la macchina virtuale era in esecuzione quando il servizio è stato arrestato. Le opzioni
includono Nothing, Avvia automaticamente se era in esecuzione quando il servizio è
stato arrestato, Avvia sempre automaticamente questa macchina virtuale e Ritardo
automatico di avvio (in secondi).
 Azione di arresto automatico: specifica l'azione da eseguire quando il servizio Hyper-V si
arresta. Le opzioni includono Salva lo stato della macchina virtuale, Disattiva la
macchina virtuale e Arresta il sistema operativo guest.

Contenuti correlati
Ecco alcune altre risorse che consentono di ottenere altre informazioni su Hyper-V e sulle
relative funzionalità:

Requisiti hardware per Hyper-V.

Pianificare la rete di Hyper-V.
Architetture di archiviazione per Hyper-V.
Generazioni di macchine virtuali.
Sistemi operativi di macchine virtuali Windows supportati.
Sistemi operativi di macchine virtuali Linux e FreeBSD supportati.

） Nota: L'autore ha creato questo articolo con l’assistenza dell'intelligenza artificiale. Ulteriori informazioni
Architettura Hyper-V
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Hyper-V è una tecnologia di virtualizzazione basata su hypervisor per determinate versioni x64
di Windows. L'hypervisor è fondamentale per la virtualizzazione. Si tratta della piattaforma di
virtualizzazione specifica del processore che consente a più sistemi operativi isolati di
condividere una singola piattaforma hardware.

Hyper-V richiede un processore che include la virtualizzazione assistita dall'hardware, ad

esempio viene fornito con la tecnologia Intel VT o AMD Virtualization (AMD-V).

Il diagramma seguente offre una panoramica generale dell'architettura di un ambiente Hyper-

V.

Partizioni radice e figlio

Hyper-V supporta l'isolamento in termini di partizione. Una partizione è un'unità logica di
isolamento, supportata dall'hypervisor, in cui vengono eseguiti i sistemi operativi. L'hypervisor
Microsoft deve avere almeno un elemento padre, o radice, partizione, che esegue Windows. Lo
stack di gestione della virtualizzazione viene eseguito nella partizione padre e ha accesso
diretto ai dispositivi hardware. La partizione radice crea quindi le partizioni figlio che ospitano i
sistemi operativi guest. Una partizione radice crea partizioni figlio usando l'API (Application
Programming Interface) hypercall.

Le partizioni secondarie non hanno accesso diretto ad altre risorse hardware e ricevono una
vista virtualizzata delle risorse, come dispositivi virtuali (VDevs). Le richieste ai dispositivi virtuali
vengono reindirizzate tramite VMBus o l'hypervisor ai dispositivi nella partizione padre, che
gestisce le richieste.

Gestione di interrupt e memoria

Le partizioni non hanno accesso al processore fisico, né gestiscono gli interrupt del processore.
Hanno invece una visualizzazione virtuale del processore ed eseguite in un'area di indirizzi di
memoria virtuale privata per ogni partizione guest. L'hypervisor gestisce gli interrupt al
processore e li reindirizza alla rispettiva partizione.

Hyper-V può anche accelerare la conversione degli indirizzi tra vari spazi di indirizzi virtuali
guest usando un'unità IOMMU (Input Output Memory Management Unit) che opera
indipendentemente dall'hardware di gestione della memoria usato dalla CPU. Un IOMMU viene
usato per eseguire il mapping degli indirizzi di memoria fisica agli indirizzi usati dalle partizioni
figlio.

７ Nota

SLAT (Second Level Address Translation) è necessario per Hyper-V in Windows Server 2016
e versioni successive.

VMBus, VSP e VSC

VMBus è un canale di comunicazione tra partizioni logiche. La partizione padre ospita i
provider di servizi di virtualizzazione (VSP) che comunicano tramite VMBus per gestire le
richieste di accesso ai dispositivi dalle partizioni figlio. Le partizioni figlio ospitano i consumer
del servizio di virtualizzazione (VSC) che reindirizzano le richieste dei dispositivi ai vsp nella
partizione padre tramite VMBus. Questo intero processo è trasparente per il sistema operativo
guest.

Servizi di I/O e integrazione illuminati

I dispositivi virtuali possono anche sfruttare una funzionalità di virtualizzazione di Windows
Server, denominata "Enlightened I/O", per archiviazione, rete, grafica e sottosistemi di input.
L'I/O con riconoscimento dei dati aziendali è un'implementazione specializzata in grado di
supportare la virtualizzazione di protocolli di comunicazione di alto livello (ad esempio SCSI)
che usano direttamente vmBus, ignorando qualsiasi livello di emulazione del dispositivo. In
questo modo la comunicazione risulta più efficiente, ma richiede un guest con riconoscimento
dei dati con riconoscimento dei dati di hypervisor e VMBus.

Hyper-V I/O ottimizzato e un kernel consapevole dell'hypervisor vengono forniti tramite i

servizi di integrazione Hyper-V. I componenti di integrazione, che includono i driver di Virtual
Server Client (VSC), sono disponibili anche per altri sistemi operativi client.

Glossario
APIC – Advanced Programmable Interrupt Controller – Un dispositivo che consente di
assegnare i livelli di priorità agli output di interrupt.
Partizione figlio: partizione che ospita un sistema operativo guest: tutti gli accessi alla
memoria fisica e ai dispositivi da una partizione figlio vengono forniti tramite il bus di
macchina virtuale (VMBus) o l'hypervisor.
Hypercall : interfaccia per la comunicazione con l'hypervisor: l'interfaccia hypercall
supporta l'accesso alle ottimizzazioni fornite dall'hypervisor.
Hypervisor : un livello di software che si trova tra l'hardware e uno o più sistemi operativi.
Il processo principale consiste nel fornire ambienti di esecuzione isolati denominati
partizioni. L'hypervisor controlla e arbitra l'accesso all'hardware sottostante.
IC : componente di integrazione: componente che consente alle partizioni figlio di
comunicare con altre partizioni e l'hypervisor.
IOMMU: unità di gestione della memoria di input/output – una unità di gestione della
memoria che connette un bus di I/O capace di accesso diretto alla memoria alla memoria
principale, rimappando gli indirizzi fisici agli indirizzi fisici guest per l'isolamento del
dispositivo.
Stack di I/O - Stack di input/output
MSR – Model-Specific Registri. Utilizzato per i valori di stato e controllo.
Partizione radice : talvolta denominata partizione padre. Gestisce funzioni a livello di
computer, ad esempio driver di dispositivo, risparmio energia e aggiunta/rimozione dei
dispositivi ad accesso frequente. La partizione radice (o padre) è l'unica partizione che ha
accesso diretto a memoria fisica e dispositivi.
VDev – dispositivo virtuale – rappresentazione virtualizzata di un dispositivo hardware
presentato alle partizioni figlio. VDevs astrae l'hardware fisico, consentendo ai sistemi
operativi guest di interagire con i dispositivi tramite il VMBus o l'hypervisor.
VID - Driver dell'infrastruttura di virtualizzazione: fornisce servizi di gestione delle
partizioni, servizi di gestione del processore virtuale e servizi di gestione della memoria
per le partizioni.
VMBus : meccanismo di comunicazione basato sul canale usato per la comunicazione tra
partizioni e l'enumerazione dei dispositivi nei sistemi con più partizioni virtualizzate attive.
 VmBus viene installato con Hyper-V Integration Services.
VMMS - Servizio Gestione macchine virtuali : responsabile della gestione dello stato di
tutte le macchine virtuali nelle partizioni figlio.
VMWP - Processo di lavoro di macchine virtuali: componente in modalità utente dello
stack di virtualizzazione. Il processo di lavoro fornisce servizi di gestione delle macchine
virtuali dall'istanza di Windows Server 2008 nella partizione padre ai sistemi operativi
guest nelle partizioni figlio. Il servizio Virtual Machine Management genera un processo
di lavoro separato per ogni macchina virtuale in esecuzione.
VSC - Virtualization Service Client: istanza di dispositivo sintetico che risiede in una
partizione figlio. Le schede di confronto usano risorse hardware fornite dai provider di
servizi di virtualizzazione (VSP) nella partizione padre. Comunicano con i vsp
corrispondenti nella partizione padre su VMBus per soddisfare le richieste di I/O dei
dispositivi delle partizioni figlio.
VSP : provider di servizi di virtualizzazione: risiede nella partizione radice e fornisce il
supporto del dispositivo sintetico alle partizioni figlio sul bus di macchine virtuali
(VMBus).
WinHv - Libreria dell'interfaccia di Windows Hypervisor - WinHv è essenzialmente un
ponte tra i driver di un sistema operativo partizionato e l'hypervisor che consente ai driver
di chiamare l'hypervisor usando convenzioni di chiamata standard di Windows
WMI : il servizio Gestione macchine virtuali espone un set di API basate su
Strumentazione gestione Windows (WMI) per la gestione e il controllo delle macchine
virtuali.

Last updated on 22/01/2026

Hyper-V limiti massimi di scalabilità in
Windows Server
17/10/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Azure Local 2311.2 and later

Hyper-V può scalare per fornire ai carichi di lavoro le risorse di cui hanno bisogno. Questo
articolo illustra in dettaglio i limiti di scalabilità di Hyper-V nelle versioni supportate di
Windows Server per macchine virtuali (VM) e host, inclusi processori virtuali, memoria,
archiviazione e checkpoint. Usare questi valori massimi per pianificare la capacità e supportare
carichi di lavoro impegnativi.

Durante la pianificazione della distribuzione, prendere in considerazione questi valori massimi

che si applicano a ogni macchina virtuale e host. I massimi continuano a crescere nelle versioni
di Windows Server, in risposta alle richieste di supporto di scenari più recenti, ad esempio
Machine Learning e analisi dei dati.

Numero massimo di macchine virtuali Hyper-V

Questi valori massimi si applicano a ogni macchina virtuale per la versione di Windows Server
in esecuzione in un host Hyper-V. Alcuni componenti hanno valori massimi diversi a seconda
che la macchina virtuale sia di prima o seconda generazione. Per un confronto tra le
generazioni, vedere Creare una macchina virtuale di prima o 2 generazione in Hyper-V?.

） Importante

Il sistema operativo guest eseguito nella macchina virtuale potrebbe supportare meno del
massimo di Hyper-V. Rivolgersi al fornitore del sistema operativo per i limiti supportati e
scegliere la generazione di macchine virtuali appropriata prima di eseguire la distribuzione
su larga scala. I limiti dei fornitori possono cambiare; verificare gli aggiornamenti correnti.

Selezionare la scheda pertinente per visualizzare i valori massimi per ogni versione supportata
di Windows Server.

Windows Server 2025 Host

Ecco i limiti per le macchine virtuali in un host Hyper-V che esegue Windows Server 2025:

ﾉ Espandi la tabella
 Componente Limite Massimo

Processori virtuali 2.048 (generazione 2, ad esempio: 64 socket con 32 processori

virtuali per nodo NUMA, solo PowerShell); 64 (generazione 1).

Memoria 240 TB (generazione 2); 1 TB (generazione 1).

Capacità del disco rigido 64 TB (VHDX); 2.040 GB (VHD).

virtuale

Dischi rigidi virtuali 256 (SCSI); 4 (solo IDE, generazione 1).

Pass-through del disco fisico Il sistema operativo determina le dimensioni massime per la
macchina virtuale.

Schede di rete virtuali 64 standard (generazione 2); 8 standard + 4 eredità (generazione 1).

Controller SCSI virtuali 4

Dispositivi SCSI virtuali 256. Ogni controller SCSI supporta fino a 64 dischi rigidi virtuali e/o
unità DVD.

Controller IDE virtuali (solo 2. Ogni controller IDE supporta fino a 2 dispositivi IDE (dischi rigidi
generazione 1) e/o unità DVD) per controller.

Dispositivi IDE virtuali (solo 4. Per le macchine virtuali di prima generazione, il disco di
generazione 1) avvio/avvio deve essere collegato a uno dei dispositivi IDE.

Unità DVD virtuali 256 (SCSI); 4 (solo IDE, generazione 1).

Schede Fibre Channel virtuali 4. È consigliabile connettere ogni scheda Fibre Channel virtuale a
una san virtuale diversa.

Porte seriali (COM) (solo 2

generazione 1)

Dispositivi floppy virtuali 1

(solo generazione 1)

Punti di controllo 50, a seconda della quantità di spazio di archiviazione disponibile.

Numero massimo per gli host Hyper-V

Questi valori massimi si applicano a ogni host Hyper-V che esegue Windows Server.
Selezionare la scheda pertinente per visualizzare i valori massimi per ogni versione supportata
di Windows Server.

Windows Server 2025

 Ecco i limiti per un host Hyper-V che esegue Windows Server 2025:

ﾉ Espandi la tabella

Componente Limite Massimo

Macchine virtuali in esecuzione per 1,024

server

Processori logici 2,048

Processori virtuali disponibili per l'host 2.048. Questo limite viene applicato al sistema operativo
host usando la Hyper-V partizione radice.

Processori virtuali per processore Nessun rapporto imposto da Hyper-V

logico

Processori virtuali in uso per host 2,048

Memoria 4 PB (paging a 5 livelli); 256 TB (paging a 4 livelli).

Schede di rete fisiche Nessun limite imposto da Hyper-V

Raggruppamento delle schede di Nessun limite imposto da Hyper-V

interfaccia di rete

Porte di commutatori di rete virtuali Nessun limite imposto da Hyper-V Il limite effettivo
per server dipende dalle risorse di elaborazione disponibili.

Commutatori virtuali Nessun limite imposto da Hyper-V Il limite effettivo

dipende dalle risorse di elaborazione disponibili.

Storage Nessun limite imposto da Hyper-V

Reti di archiviazione (SAN, Storage Nessun limite imposto da Hyper-V

Area Network) virtuali

Numero massimo per il cluster di failover con host

Hyper-V
Questi valori massimi si applicano in un cluster di failover con host Hyper-V per tutte le
versioni supportate di Windows Server. È importante eseguire la pianificazione della capacità
per assicurarsi che le risorse hardware siano sufficienti per eseguire tutte le macchine virtuali in
un ambiente cluster.
 ﾉ Espandi la tabella

Componente Limite Massimo

Nodi per cluster 64

Esecuzione di macchine virtuali per ogni cluster 8,000

） Nota: L'autore ha creato questo articolo con l’assistenza dell'intelligenza artificiale. Ulteriori informazioni
Requisiti di sistema per Hyper-V in
Windows e Windows Server
16/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Hyper-V ha requisiti hardware specifici e alcune funzionalità di Hyper-V hanno altri requisiti.
Utilizzare i dettagli in questo articolo per stabilire i requisiti che il sistema deve soddisfare in
modo è possibile utilizzare il modo in cui di che si prevede Hyper-V.

Requisiti per il sistema operativo

Hyper-V può essere abilitato in queste versioni di Windows:

Windows 10 Professional o Enterprise

Windows 11 Professional o Enterprise

Requisiti generali
Indipendentemente dalle funzionalità di Hyper-V da usare, è necessario:

Un processore a 64 bit con la traduzione da indirizzo di secondo livello (SLAT). Per

installare i componenti di virtualizzazione Hyper-V, ad esempio Windows hypervisor, il
processore deve disporre SLAT. Tuttavia, non è necessario per installare strumenti di
gestione di Hyper-V come Virtual Machine Connection (VMConnect), gestione di Hyper-V
e i cmdlet di Hyper-V per Windows PowerShell. Vedere How to check for Hyper-V
requirements to find out if your processor has SLAT (Come verificare se il processore ha
SLAT).

Estensioni della modalità monitoraggio macchina virtuale.

Memoria sufficiente. Pianificare almeno 4 GB di RAM. Quantità di memoria è migliore. È

necessaria memoria sufficiente per l'host e tutte le macchine virtuali da eseguire
contemporaneamente.

Supporto per la virtualizzazione attivato nel BIOS o UEFI:

Virtualizzazione assistita dall'hardware. Questa opzione è disponibile nei processori

che includono un'opzione di virtualizzazione: in particolare processori con tecnologia
Intel Virtualization (Intel VT) o AMD Virtualization (AMD-V).
 La Protezione esecuzione programmi (DEP) applicata a livello hardware deve essere
disponibile e abilitata. Per i sistemi Intel, si tratta dell'XD bit, detto "bit di
disabilitazione dell'esecuzione". Per i sistemi AMD, questo è il bit NX (no execute bit).

Come verificare la presenza di requisiti di Hyper-V

Aprire Windows PowerShell o un prompt dei comandi e digitare:

Prompt dei comandi di Windows

[Link]

Scorrere fino alla sezione Requisiti di Hyper-V per esaminare il report. Se tutti i requisiti Hyper-
V elencati hanno un valore Sì, il sistema può eseguire il ruolo di Hyper-V. Se un elemento
restituisce No, controllare i requisiti elencati in questo documento e apportare modifiche dove
possibile.

Requisiti per funzionalità specifiche

Questa sezione elenca i requisiti per l'assegnazione di dispositivi discreti e le macchine virtuali
schermate.

Assegnazione di dispositivi discreti

I requisiti dell'host sono simili ai requisiti esistenti per la funzionalità di SR-IOV in Hyper-V.
 Il processore deve disporre Extended pagina tabella (Accetta di entrambi Intel) o annidati
pagina tabella (TNP AMD).

Il chipset necessario:

Interrupt remapping - Intel VT-d con la funzionalità di mapping di Interrupt (VT-d2) o

qualsiasi versione di unità di gestione di AMD i/o memoria (MMU dei / o).

Modifica del mapping DMA - Intel VT-d con le convalide in coda o qualsiasi MMU dei /
o AMD.

Servizi di controllo di accesso (ACS) sulle porte radice PCI Express.

Le tabelle del firmware devono esporre il / o MMU nell'hypervisor di Windows. Questa

funzionalità potrebbe essere disattivata nel BIOS o UEFI. Per istruzioni, vedere la
documentazione dell'hardware o contattare il produttore dell'hardware.

I dispositivi necessitano di GPU o memoria non volatile express (NVMe). Per GPU, solo
determinati dispositivi supportano l'assegnazione di dispositivo discreti. Per verificare, vedere la
documentazione dell'hardware o contattare il produttore dell'hardware. Per informazioni
dettagliate su questa funzionalità, tra cui come usarla e considerazioni, vedere Assegnazione di
dispositivi discreti- Descrizione e informazioni di base nel blog sulla virtualizzazione.

Controllo finale
Se vengono soddisfatti tutti i requisiti di sistema operativo, hardware e compatibilità, viene
visualizzato Hyper-V nel Pannello di controllo: Attivare o disattivare le funzionalità di
Windows e include due opzioni:

piattaforma Hyper-V
Strumenti di gestione Hyper-V

７ Nota

Se viene visualizzata la piattaforma Hypervisor di Windows anziché Hyper-V nel Pannello

di controllo: attivare o >disattivare le funzionalità di Windows, il sistema potrebbe non
essere compatibile con Hyper-V. Controllare i requisiti precedenti. Se si esegue systeminfo
in un host di Hyper-V esistente, la sezione requisiti Hyper-V legge:

Hyper-V Requirements: A hypervisor has been detected. Features required for

Hyper-V will not be displayed.
Compatibilità con la funzionalità di Hyper-
V per la generazione e guest
28/10/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Le tabelle in questo articolo mostrano le generazioni e sistemi operativi compatibili con alcune
delle funzionalità di Hyper-V, raggruppate per categorie. In generale, si otterrà la migliore
disponibilità di funzionalità con una macchina virtuale di generazione 2 che esegue il sistema
operativo più recente.

Tenere presente che alcune funzionalità si basano su hardware o un'altra infrastruttura. Per
dettagli sull'hardware, vedere Requisiti di sistema per Hyper-V in Windows Server. In alcuni
casi, una funzionalità è utilizzabile con qualsiasi sistema operativo guest supportato. Per
informazioni dettagliate in cui sono supportati i sistemi operativi, vedere:

Macchine virtuali Linux e FreeBSD supportate

Sistemi operativi guest di Windows supportati

Backup e disponibilità
ﾉ Espandi la tabella

Feature Generation Sistema operativo guest

Checkpoints 1e2 Qualsiasi guest supportati

Clustering dei 1e2 Utenti guest che eseguono applicazioni compatibili con i cluster e che
guest sia installato software di destinazione iSCSI

Replication 1e2 Qualsiasi guest supportati

Controller di 1e2 Qualsiasi sistema operativo guest di Windows Server supportato che usi
dominio solo checkpoint di produzione. Vedere Sistemi operativi guest di
Windows Server supportati

Compute
ﾉ Espandi la tabella
Feature Generation Sistema operativo guest

Memoria dinamica 1e2 Versioni specifiche di guest supportati. Vedere Panoramica

della memoria dinamica di Hyper-V.

Hot aggiunta/rimozione di 1e2 Windows Server 2016, Windows 10

memoria

NUMA virtuale 1e2 Qualsiasi guest supportati

Sviluppo e test
ﾉ Espandi la tabella

Feature Generation Sistema operativo guest

Porte COM/seriali 1e2 Qualsiasi guest supportati

７ Nota

Per le porte COM/seriali di seconda generazione, usare Windows PowerShell per

configurare. Per dettagli, vedere Aggiungere una porta COM per il debug del kernel.

Mobility
ﾉ Espandi la tabella

Feature Generation Sistema operativo guest

Migrazione Live 1e2 Qualsiasi guest supportati

Import/export 1e2 Qualsiasi guest supportati

Networking
ﾉ Espandi la tabella

Feature Generation Sistema operativo guest

Hot aggiunta/rimozione della scheda 2 Qualsiasi guest supportati

di rete virtuale
Feature Generation Sistema operativo guest

Scheda di rete legacy virtuale 1 Qualsiasi guest supportati

Virtualizzazione di input/output 1e2 utenti guest di Windows a 64 bit, a partire da

radice (SR-IOV) Windows Server 2012 e Windows 8.

Coda di più macchine virtuali (VMMQ) 1e2 Qualsiasi guest supportati

Esperienza di connessione remota

ﾉ Espandi la tabella

Feature Generation Sistema operativo guest

Assegnazione di 1e2 Windows Server 2012 e versioni successive, Windows 10 e

dispositivi discreti (DDA) Windows 11

Modalità sessione 1e2 Windows Server 2012 R2 e versioni successive e Windows 8.1 e
avanzata versioni successive, con Servizi Desktop remoto abilitato.

RemoteFx 1e2 Generazione 1 in versioni di Windows a 32 bit e a 64 bit a partire

da Windows 8; Generazione 2 nelle versioni di Windows 10 e
Windows 11 a 64 bit

７ Nota

Potrebbe essere necessario configurare anche l'host per la modalità sessione avanzata. Per
informazioni dettagliate, vedere utilizzare le risorse locali nella macchina virtuale Hyper-
V con VMConnect.

Security
ﾉ Espandi la tabella

Feature Generation Sistema operativo guest

Avvio 2 Linux: Ubuntu 14.04 e versioni successive, SUSE Linux Enterprise Server 12
protetto e versioni successive, Red Hat Enterprise Linux 7.0 e versioni successive e
CentOS 7.0 e versioni successive; Windows: tutte le versioni supportate
che possono essere eseguite in una macchina virtuale di seconda
generazione
Feature Generation Sistema operativo guest

Macchine 2 Windows: tutte le versioni supportate che possono essere eseguite in una
virtuali macchina virtuale di seconda generazione
schermate

Storage
ﾉ Espandi la tabella

Feature Generation Sistema operativo guest

Dischi rigidi virtuali condivisi (VHDX solo) 1e2 Windows Server 2012 e versioni successive

SMB3 1e2 Tutto ciò che supportano SMB3

Spazi di archiviazione diretti 2 Windows Server 2016 e versioni successive

Fibre Channel virtuale 1e2 Windows Server 2012 e versioni successive

Formato VHDX 1e2 Qualsiasi guest supportati

Supportabilità del sistema operativo guest
e delle applicazioni su Hyper-V
16/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Hyper-V è un hypervisor ampiamente usato in molti prodotti server Microsoft, tra cui la
famiglia Windows Server (Datacenter, Standard ed Essentials) e Azure Local. Hyper-V offre una
piattaforma con ampio supporto e compatibilità con l'ecosistema. Questo articolo chiarisce a
quali versioni di Windows Server o Azure Locale corrispondono i numeri di build Hyper-V. Ciò
consente di comprendere gli scenari supportati in cui è stato convalidato un sistema operativo
guest o un'applicazione per Hyper-V.

Anche se i diversi prodotti che includono Hyper-V potrebbero contenere variazioni nelle
funzionalità, la codebase comune fornisce una piattaforma coerente per i sistemi operativi
guest e le applicazioni in esecuzione all'interno di una macchina virtuale per l'esecuzione su
prodotti compatibili che condividono lo stesso numero di build Hyper-V. Ciò significa che tutte
le istruzioni di supporto o compatibilità per un sistema operativo guest o un'applicazione
certificata per build specifiche di Hyper-V sono compatibili con tutti i prodotti che condividono
lo stesso numero di build per Hyper-V.

La tabella seguente mostra quali numeri di versione Hyper-V sono disponibili nei prodotti
compatibili:

ﾉ Espandi la tabella

Hyper-V compilazione Prodotti compatibili

20348 Windows Server 2022 Datacenter

Windows Server 2022 Standard
Windows Server 2022 Essentials
Azure Stack HCI versione 21H2
Azure Stack HCI versione 22H2

17763 e 17784 Windows Server 2019 Datacenter

Windows Server 2019 Standard
Windows Server 2019 Essentials
Hyper-V Server 2019
Azure Stack HCI versione 20H2

14393 Windows Server 2016 Datacenter

Windows Server 2016 Standard
 Hyper-V compilazione Prodotti compatibili

Nozioni di base su Windows Server 2016

Hyper-V Server 2016

Per altre informazioni, vedere:

Informazioni sulla versione di Windows Server

Sistemi operativi guest Windows supportati su Hyper-V
Sistemi operativi guest Linux e FreeBSD compatibili in Hyper-V
Sistemi operativi guest Windows
supportati per Hyper-V in Windows,
Windows Server e Azure Locale
28/10/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Hyper-V supporta diverse versioni di distribuzioni di Windows Server, Windows e Linux per
l'esecuzione in macchine virtuali come sistemi operativi guest. Questo articolo copre i sistemi
operativi supportati Windows Server e i sistemi operativi guest Windows. Per le distribuzioni di
Linux e FreeBSD, vedere Macchine virtuali supportate per Linux e FreeBSD su Hyper-V in
Windows.

Alcuni sistemi operativi hanno i servizi di integrazione incorporati. Altri richiedono di installare
o aggiornare i servizi di integrazione come passaggio separato, dopo aver configurato il
sistema operativo nella macchina virtuale. Per maggiori informazioni, consultare le sezioni
seguenti e Servizi di integrazione.

I componenti configurabili dei sistemi operativi guest sono limitati in base al sistema operativo
host. Per maggiori informazioni sui componenti configurabili massimi in Hyper-V, consultare la
sezione Pianificare la scalabilità di Hyper-V in Windows Server.

Sistemi operativi guest di Windows Server

supportati
Di seguito sono riportate le versioni di Windows Server supportate come sistemi operativi
guest per Hyper-V in Windows Server.

Windows Server 2025

Numero massimo di processori virtuali:
2.048 per la generazione 2
64 per la prima generazione
2.048 disponibili per il sistema operativo host (partizione radice)
Integration Services: predefinito
Sistemi operativi host:
Windows Server 2022 e versioni successive
 Sistema operativo locale di Azure, versione 23H2 e successive con la sottoscrizione di
Windows Server.
Notes:
Il numero massimo di processori virtuali dipende dal sistema operativo host. Ad
esempio, Windows Server 2025 può fornire fino a 2.048 processori virtuali.

Windows Server 2022

Numero massimo di processori virtuali:
1,024 per generazione 2
64 per la prima generazione
1.024 disponibili per il sistema operativo host (partizione radice)
Integration Services: predefinito
Sistemi operativi host:
Windows Server 2019 e versioni successive
Sistema operativo locale di Azure, versione 23H2 e successive.

Windows Server 2019

Numero massimo di processori virtuali:
240 per generazione 2
64 per la prima generazione
320 disponibili per il sistema operativo host (partizione radice)
Integration Services: predefinito

Windows Server 2016

Numero massimo di processori virtuali:
240 per generazione 2
64 per la prima generazione
320 disponibili per il sistema operativo host (partizione radice)
Integration Services: predefinito

Windows Server 2012 R2

Numero massimo di processori virtuali: 64
Integration Services: predefinito

Windows Server 2012

 Numero massimo di processori virtuali: 64
Integration Services: predefinito

Windows Server 2008 R2 con Service Pack 1 (SP1)

Numero massimo di processori virtuali: 64
Integration Services: installare tutti gli aggiornamenti critici di Windows dopo aver
configurato il sistema operativo guest.
Note: Edizioni Datacenter, Enterprise, Standard e Web.

Windows Server 2008 con Service Pack 2 (SP2)

Numero massimo di processori virtuali: 8
Integration Services: installare tutti gli aggiornamenti critici di Windows dopo aver
configurato il sistema operativo guest.
Note: Edizioni Datacenter, Enterprise, Standard e Web (32 bit e 64 bit).

Sistemi operativi guest per client Windows

supportati
Di seguito sono riportate le versioni del client Windows supportate come sistemi operativi
guest per Hyper-V in Windows Server.

Windows 11
Numero massimo di processori virtuali: 32
Integration Services: predefinito
Sistemi operativi host:
Macchina virtuale di seconda generazione ospitata in Windows Server 2019 e versioni
successive
Macchina virtuale di seconda generazione ospitata nel sistema operativo locale di
Azure, versione 23H2 e successive
Notes:
Windows 11 richiede un'istruzione cpu maggiore per l'installazione e l'avvio (POPCNT
e SSE4.2). Per soddisfare questi requisiti in Hyper-V:
Su Windows 11, Windows Server 2022 (host autonomi o in cluster), o su host
autonomi di Windows Server 2025, disabilita la compatibilità del processore per
abilitare queste funzionalità. La disabilitazione della compatibilità del processore
 limita la migrazione in tempo reale agli host con le stesse funzionalità del
processore.
Nei cluster Windows Server 2025 con CPU che supportano POPCNT e SSE4.2,
abilitare la compatibilità dinamica del processore per garantire che queste
funzionalità siano disponibili mantenendo al tempo stesso le funzionalità di
migrazione in tempo reale all'interno del cluster. Per altre informazioni sulla
compatibilità del processore dinamico, vedere Compatibilità del processore per
Hyper-V macchine virtuali.

Windows 10
Numero massimo di processori virtuali: 32
Integration Services: predefinito

Windows 8.1
Numero massimo di processori virtuali: 32
Integration Services: predefinito

Windows 7 con Service Pack 1 (SP1)

Numero massimo di processori virtuali: 4
Integration Services: aggiornare i servizi di integrazione dopo aver configurato il sistema
operativo guest.
Note: Edizioni Ultimate, Enterprise e Professional (32 bit e 64 bit).

Linux e FreeBSD supportati

ﾉ Espandi la tabella

Sistema operativo guest

CentOS e Red Hat Enterprise Linux

macchine virtuali Debian in Hyper-V

SUSE

Oracle Linux

Ubuntu

FreeBSD
Come Microsoft fornisce il supporto per i sistemi
operativi guest
Microsoft fornisce supporto per i sistemi operativi guest secondo le modalità seguenti:

I problemi riscontrati nei sistemi operativi Microsoft e nei servizi di integrazione sono
supportati direttamente da Microsoft.

Per i problemi riscontrati in altri sistemi operativi certificati dal relativo fornitore per
l'esecuzione in Hyper-V, il supporto è garantito dal fornitore.

Per i problemi riscontrati in altri sistemi operativi, Microsoft sottopone il problema alla
community di supporto di più fornitori, TSANet .

Per essere supportato, tutti i sistemi operativi (guest e host) devono essere up-to-date.
Controllare Windows Update per gli aggiornamenti critici.
Le macchine virtuali Linux e FreeBSD
supportate per Hyper-V in Windows Server
e Windows
19/06/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Hyper-V supporta dispositivi emulati e specifici di Hyper-V per le macchine virtuali Linux e
FreeBSD. Quando si esegue con dispositivi emulati, è necessario installare alcun software
aggiuntivo. Dispositivi emulati tuttavia non forniscono prestazioni elevate e non possono
sfruttare l'infrastruttura di gestione di macchina virtuale avanzato che offre la tecnologia
Hyper-V. Per poter utilizzare completamente tutti i vantaggi che offre la tecnologia Hyper-V, si
consiglia di utilizzare i dispositivi specifici di Hyper-V per Linux e FreeBSD. L'insieme di driver
che sono necessari per eseguire i dispositivi specifici di Hyper-V sono noti come Linux
Integration Services (LIS) o FreeBSD Integration Services (BIS).

LIS è stato aggiunto il kernel Linux e viene aggiornato per le nuove versioni. Ma le distribuzioni
di Linux basate su kernel precedenti potrebbero non disporre di miglioramenti o correzioni più
recenti. Microsoft fornisce un download contenente i driver LIS installabili per alcune
installazioni di Linux su questi kernel precedenti. Poiché i fornitori di distribuzione includono le
versioni di Linux Integration Services, è consigliabile installare l'ultima versione scaricabile di
LIS, se applicabile, per l'installazione.

Per altre distribuzioni di Linux LIS modifiche regolarmente sono integrate nel kernel del sistema
operativo e applicazioni quindi non è necessaria alcuna installazione o un download separato.

Per le versioni precedenti di FreeBSD (prima 10.0), Microsoft fornisce porte che contengono i
driver installabili BIS e daemon corrispondente per le macchine virtuali FreeBSD. Per le versioni
più recenti FreeBSD BIS incorporato nel sistema operativo FreeBSD e alcun download separato
o l'installazione non è necessario ad eccezione di un download di porte di coppia chiave-
VALORE che è necessaria per FreeBSD 10.0.

 Suggerimento

Scaricare Windows Server dall'Evaluation Center.

L'obiettivo di questo contenuto è fornire informazioni che agevolano la distribuzione di Linux o

FreeBSD in Hyper-V. Dettagli specifici includono:
 Versioni di FreeBSD che richiedono il download e installazione dei driver LIS o BIS o
distribuzioni di Linux.

Versioni di FreeBSD che contengono i driver LIS o BIS incorporati o distribuzioni di Linux.

Mappe di distribuzione di funzionalità che indicano le caratteristiche di maggior parte

delle distribuzioni di Linux o rilascia FreeBSD.

Problemi noti e soluzioni alternative per ogni distribuzione o rilascio.

Descrizione delle funzionalità per ogni funzionalità LIS o BIS.

Contenuto della sezione

Macchine virtuali CentOS e Red Hat Enterprise Linux supportate in Hyper-V

Macchine virtuali Debian supportate in Hyper-V

Macchine virtuali Oracle Linux supportate in Hyper-V

Macchine virtuali SUSE supportate in Hyper-V

Macchine virtuali Ubuntu supportate in Hyper-V

Macchine virtuali FreeBSD supportate in Hyper-V

Descrizioni delle funzionalità per macchine virtuali Linux e FreeBSD in Hyper-V

Procedure consigliate per l'esecuzione di Linux in Hyper-V

Procedure consigliate per l'esecuzione di FreeBSD in Hyper-V

CentOS è supportato e Red Hat Enterprise Linux
macchine virtuali in Hyper-V
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016, ✅ Windows 11, ✅ Windows
10, ✅ Azure Local 2311.2 and later

Le mappe di distribuzione di funzionalità seguenti indicano le funzionalità che sono presenti nelle versioni incorporate e scaricabili
di Linux Integration Services. Dopo le tabelle sono elencate i problemi noti e soluzioni alternative per ogni distribuzione.

I driver predefiniti di Red Hat Enterprise Linux Integration Services per Hyper-V sono sufficienti per consentire ai guest Red Hat
Enterprise Linux di funzionare usando i dispositivi sintetici ad alte prestazioni sui server Hyper-V. Questi driver predefiniti sono
certificati da Red Hat per questo utilizzo. Le configurazioni certificate possono essere visualizzate nel catalogo di certificazione Red
Hat .

Non è necessario scaricare e installare i pacchetti Linux Integration Services dall'Area download Microsoft, poiché farlo potrebbe
limitare il supporto di Red Hat, come descritto in Red Hat Knowledgebase 1067 .

A causa di potenziali conflitti tra il supporto LIS predefinito e il supporto LIS scaricabile quando si aggiorna il kernel, disabilitare gli
aggiornamenti automatici, disinstallare i pacchetti scaricabili LIS, aggiornare il kernel, riavviare il computer e quindi installare LIS più
recenti di rilascio e riavviare nuovamente.

Contenuto della sezione:

Serie RHEL/CentOS 9.x

Serie RHEL/CentOS 8.x

Notes

Legenda tabella
Predefinito : LIS è incluso come parte di questa distribuzione linux. I numeri di versione del modulo kernel per il LIS predefinito
(come illustrato da lsmod, ad esempio) sono diversi dal numero di versione nel pacchetto di download LIS fornito da
Microsoft. Una mancata corrispondenza non indica che il LIS predefinito non è aggiornato.

✔ - Funzionalità disponibile

(vuoto) - Funzionalità non disponibile

Serie RHEL/CentOS 9.x

ﾉ Espandi la tabella

Feature Sistema operativo host 9.x

Disponibilità LIS Installato

Core Windows Server 2025, 2022, 2019, 2016 ✔

Azure Stack HCI

Ora esatta di Windows Server 2016 Windows Server 2025, 2022, 2019, 2016 ✔
Azure Stack HCI

>256 vCPU ✔

Networking

Jumbo frame Windows Server 2025, 2022, 2019, 2016 ✔

Azure Stack HCI
Feature Sistema operativo host 9.x

Assegnazione di tag e trunking VLAN Windows Server 2025, 2022, 2019, 2016 ✔
Azure Stack HCI

Migrazione in Tempo Reale Windows Server 2025, 2022, 2019, 2016 ✔

Azure Stack HCI

Inserimento di IP statico Windows Server 2025, 2022, 2019, 2016 ✔ Nota 2

Azure Stack HCI

vRSS Windows Server 2025, 2022, 2019, 2016 ✔

Azure Stack HCI

Segmentazione TCP e offload checksum Windows Server 2025, 2022, 2019, 2016 ✔
Azure Stack HCI

SR-IOV Windows Server 2025, 2022, 2019, 2016 ✔

Azure Stack HCI

Storage

Ridimensionamento VHDX Windows Server 2025, 2022, 2019, 2016 ✔

Azure Stack HCI

Fibre Channel virtuale Windows Server 2025, 2022, 2019, 2016 ✔ Nota 3
Azure Stack HCI

Backup delle macchine virtuali attive Windows Server 2025, 2022, 2019, 2016 ✔ Nota 5
Azure Stack HCI

Supporto TRIM Windows Server 2025, 2022, 2019, 2016 ✔

Azure Stack HCI

SCSI WWN Windows Server 2025, 2022, 2019, 2016 ✔

Azure Stack HCI

Memory

Supporto del kernel PAE Windows Server 2025, 2022, 2019, 2016
Azure Stack HCI

Configurazione del gap MMIO Windows Server 2025, 2022, 2019, 2016 ✔
Azure Stack HCI

Memoria dinamica - aggiunta a caldo Windows Server 2025, 2022, 2019, 2016 ✔ Nota 9, 10
Azure Stack HCI

Memoria dinamica - Ballooning Windows Server 2025, 2022, 2019, 2016 ✔ Nota 9,10
Azure Stack HCI

Ridimensionamento della memoria di runtime Windows Server 2025, 2022, 2019, 2016 ✔
Azure Stack HCI

Video

Dispositivo video specifico Hyper-V Windows Server 2025, 2022, 2019, 2016 ✔
Azure Stack HCI

Miscellaneous

coppia Key-Value Windows Server 2025, 2022, 2019, 2016 ✔

Azure Stack HCI

Interrupt non mascherabile Windows Server 2025, 2022, 2019, 2016 ✔

Azure Stack HCI

Copia di file dall'host al guest Windows Server 2025, 2022, 2019, 2016 ✔
Azure Stack HCI

Comando lsvmbus Windows Server 2025, 2022, 2019, 2016 ✔

Azure Stack HCI
Feature Sistema operativo host 9.x

socket Hyper-V Windows Server 2025, 2022, 2019, 2016 ✔

Azure Stack HCI

Passthrough PCI/DDA Windows Server 2025, 2022, 2019, 2016 ✔

Azure Stack HCI

Macchine virtuali di seconda generazione

Avvio con UEFI Windows Server 2025, 2022, 2019, 2016 ✔ Nota 14, 17
Azure Stack HCI

Avvio protetto Windows Server 2025, 2022, 2019, 2016 ✔

Azure Stack HCI

Serie RHEL/CentOS 8.x

ﾉ Espandi la tabella

Feature Sistema operativo host 8.1-8.6+ 8.0

Disponibilità LIS Installato Installato

Core Windows Server 2025, 2022, 2019, 2016 ✔ ✔

Azure Stack HCI

Ora esatta di Windows Server 2016 Windows Server 2025, 2022, 2019, 2016 ✔ ✔
Azure Stack HCI

>256 vCPU ✔

Networking

Jumbo frame Windows Server 2025, 2022, 2019, 2016 ✔ ✔

Azure Stack HCI

Assegnazione di tag e trunking VLAN Windows Server 2025, 2022, 2019, 2016 ✔ ✔
Azure Stack HCI

Migrazione in Tempo Reale Windows Server 2025, 2022, 2019, 2016 ✔ ✔

Azure Stack HCI

Inserimento di IP statico Windows Server 2025, 2022, 2019, 2016 ✔ Nota 2 ✔ Nota 2
Azure Stack HCI

vRSS Windows Server 2025, 2022, 2019, 2016 ✔ ✔

Azure Stack HCI

Segmentazione TCP e offload checksum Windows Server 2025, 2022, 2019, 2016 ✔ ✔
Azure Stack HCI

SR-IOV Windows Server 2025, 2022, 2019, 2016 ✔ ✔

Azure Stack HCI

Storage

Ridimensionamento VHDX Windows Server 2025, 2022, 2019, 2016 ✔ ✔

Azure Stack HCI

Fibre Channel virtuale Windows Server 2025, 2022, 2019, 2016 ✔ Nota 3 ✔ Nota 3
Azure Stack HCI

Backup delle macchine virtuali attive Windows Server 2025, 2022, 2019, 2016 ✔ Nota 5 ✔ Nota 5
Azure Stack HCI

Supporto TRIM Windows Server 2025, 2022, 2019, 2016 ✔ ✔

Azure Stack HCI
 Feature Sistema operativo host 8.1-8.6+ 8.0

SCSI WWN Windows Server 2025, 2022, 2019, 2016 ✔ ✔

Azure Stack HCI

Memory

Supporto del kernel PAE Windows Server 2025, 2022, 2019, 2016 N/A N/A
Azure Stack HCI

Configurazione del gap MMIO Windows Server 2025, 2022, 2019, 2016 ✔ ✔
Azure Stack HCI

Memoria dinamica - aggiunta a caldo Windows Server 2025, 2022, 2019, 2016 ✔ Nota 9, 10 ✔ Nota 9, 10
Azure Stack HCI

Memoria dinamica - Ballooning Windows Server 2025, 2022, 2019, 2016 ✔ Nota 9, 10 ✔ Nota 9, 10
Azure Stack HCI

Ridimensionamento della memoria di runtime Windows Server 2025, 2022, 2019, 2016 ✔ ✔
Azure Stack HCI

Video

Dispositivo video specifico Hyper-V Windows Server 2025, 2022, 2019, 2016 ✔ ✔
Azure Stack HCI

Miscellaneous

coppia Key-Value Windows Server 2025, 2022, 2019, 2016 ✔ ✔

Azure Stack HCI

Interrupt non mascherabile Windows Server 2025, 2022, 2019, 2016 ✔ ✔

Azure Stack HCI

Copia di file dall'host al guest Windows Server 2025, 2022, 2019, 2016 ✔ ✔
Azure Stack HCI

Comando lsvmbus Windows Server 2025, 2022, 2019, 2016 ✔ ✔

Azure Stack HCI

socket Hyper-V Windows Server 2025, 2022, 2019, 2016 ✔ ✔

Azure Stack HCI

Passthrough PCI/DDA Windows Server 2025, 2022, 2019, 2016 ✔ ✔

Azure Stack HCI

Macchine virtuali di seconda generazione

Avvio con UEFI Windows Server 2025, 2022, 2019, 2016 ✔ Nota 14, 17 ✔ Nota 14
Azure Stack HCI

Avvio protetto Windows Server 2025, 2022, 2019, 2016 ✔ ✔

Azure Stack HCI

Serie RHEL/CentOS 7.x

Questa serie dispone solo di kernel a 64 bit.

ﾉ Espandi la tabella

Feature Sistema 7.5- 7.3- 7.0- 7.6-7.9 7.5 7.4 7.3 7.2 7.1 7.0
operativo 7.7 7.4 7.2
host

Disponibilità LIS LIS 4.3 LIS LIS Predefinito Predefinito Predefinito Predefinito Predefinito Predefinito Predefinito
4.3 4.3
Feature Sistema 7.5- 7.3- 7.0- 7.6-7.9 7.5 7.4 7.3 7.2 7.1 7.0
operativo 7.7 7.4 7.2
host

Core Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
Server
2025,
2022,
2019,
2016
Azure
Stack HCI

Ora esatta di Windows ✔ ✔ ✔ ✔ ✔

Windows Server Server
2016 2025,
2022,
2019,
2016
Azure
Stack HCI

>256 vCPU ✔ Nota 16

Networking

Jumbo frame Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

Server
2025,
2022,
2019,
2016
Azure
Stack HCI

Assegnazione di Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
tag e trunking Server
VLAN 2025,
2022,
2019,
2016
Azure
Stack HCI

Migrazione in Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
Tempo Reale Server
2025,
2022,
2019,
2016
Azure
Stack HCI

Inserimento di IP Windows ✔ ✔ ✔ ✔ Nota 2 ✔ Nota 2 ✔ Nota 2 ✔ Nota 2 ✔ Nota 2 ✔ Nota 2 ✔ Nota 2

statico Server Nota Nota Nota
2025, 2 2 2
2022,
2019,
2016
Azure
Stack HCI

vRSS Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
Server
2025,
2022,
2019,
2016
Feature Sistema 7.5- 7.3- 7.0- 7.6-7.9 7.5 7.4 7.3 7.2 7.1 7.0
operativo 7.7 7.4 7.2
host

Azure
Stack HCI

Segmentazione TCP Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

e offload checksum Server
2025,
2022,
2019,
2016
Azure
Stack HCI

SR-IOV Windows ✔ ✔ ✔ ✔ ✔
Server
2025,
2022,
2019,
2016
Azure
Stack HCI

Storage

Ridimensionamento Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
VHDX Server
2025,
2022,
2019,
2016
Azure
Stack HCI

Fibre Channel Windows ✔ ✔ ✔ ✔ Nota 3 ✔ Nota 3 ✔ Nota 3 ✔ Nota 3 ✔ Nota 3 ✔ Nota 3 ✔ Nota 3
virtuale Server Nota Nota Nota
2025, 3 3 3
2022,
2019,
2016
Azure
Stack HCI

Backup delle Windows ✔ ✔ ✔ ✔ Nota 4,5 ✔ Nota 4,5 ✔ Nota 4, ✔ Nota 4, ✔ Nota 4, ✔ Nota 4, ✔ Nota 4,
macchine virtuali Server Nota Nota Nota 5 5 5 5 5
attive 2025, 5 5 5
2022,
2019,
2016
Azure
Stack HCI

Supporto TRIM Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

Server
2025,
2022,
2019,
2016
Azure
Stack HCI

SCSI WWN Windows ✔ ✔ ✔ ✔

Server
2025,
2022,
2019,
2016
Feature Sistema 7.5- 7.3- 7.0- 7.6-7.9 7.5 7.4 7.3 7.2 7.1 7.0
operativo 7.7 7.4 7.2
host

Azure
Stack HCI

Memory

Supporto del kernel Windows N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
PAE Server
2025,
2022,
2019,
2016
Azure
Stack HCI

Configurazione del Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

gap MMIO Server
2025,
2022,
2019,
2016
Azure
Stack HCI

Memoria dinamica Windows ✔ ✔ ✔ ✔ Nota 8, ✔ Nota 9, ✔ Nota 9, ✔ Nota 9, ✔ Nota 9, ✔ Nota 9, ✔ Nota 8,
- aggiunta a caldo Server Galaxy Nota Nota 9, 10 10 10 10 10 10 9, 10
2025, Note 8, 9, 8, 9,
2022, 8, 9, 10 10
2019, 10
2016
Azure
Stack HCI

Memoria dinamica Windows ✔ ✔ ✔ ✔ Nota 9, ✔ Nota 9, ✔ Nota 9, ✔ Nota 9, ✔ Nota 9, ✔ Nota 9, ✔ Nota 9,
- Ballooning Server Nota Nota Nota 10 10 10 10 10 10 10
2025, 9, 10 9, 10 9, 10
2022,
2019,
2016
Azure
Stack HCI

Ridimensionamento Windows ✔ ✔ ✔
della memoria di Server
runtime 2025,
2022,
2019,
2016
Azure
Stack HCI

Video

Dispositivo video Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

specifico Hyper-V Server
2025,
2022,
2019,
2016
Azure
Stack HCI

Miscellaneous

coppia Key-Value Windows ✔ ✔ ✔ ✔ Nota 4 ✔ Nota 4 ✔ Nota 4 ✔ Nota 4 ✔ Nota 4 ✔ Nota 4 ✔ Nota 4
Server
2025,
Feature Sistema 7.5- 7.3- 7.0- 7.6-7.9 7.5 7.4 7.3 7.2 7.1 7.0
operativo 7.7 7.4 7.2
host

2022,
2019,
2016
Azure
Stack HCI

Interrupt non Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

mascherabile Server
2025,
2022,
2019,
2016
Azure
Stack HCI

Copia di file Windows ✔ ✔ ✔ ✔ Nota 4 ✔ Nota 4 ✔ Nota 4 ✔ Nota 4 ✔ Nota 4 ✔ Nota 4

dall'host al guest Server
2025,
2022,
2019,
2016
Azure
Stack HCI

Comando lsvmbus Windows ✔ ✔ ✔

Server
2025,
2022,
2019,
2016
Azure
Stack HCI

socket Hyper-V Windows ✔ ✔ ✔

Server
2025,
2022,
2019,
2016

Passthrough Windows ✔ ✔ ✔ ✔ ✔ ✔
PCI/DDA Server
2025,
2022,
2019,
2016
Azure
Stack HCI

Macchine virtuali di
seconda
generazione

Avvio con UEFI Windows ✔ ✔ ✔ ✔ Nota 14 ✔ Nota 14 ✔ Nota 14 ✔ Nota 14 ✔ Nota 14 ✔ Nota 14 ✔ Nota 14
Server Nota Nota Nota
2025, 14 14 14
2022,
2019,
2016
Azure
Stack HCI

Avvio protetto Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

Server
2025,
Feature Sistema 7.5- 7.3- 7.0- 7.6-7.9 7.5 7.4 7.3 7.2 7.1 7.0
operativo 7.7 7.4 7.2
host

2022,
2019,
2016
Azure
Stack HCI

Notes
1. Per questa versione RHEL/CentOS, l'assegnazione di tag VLAN funziona ma il trunking VLAN non funziona.

2. Inserimento di IP statico potrebbe non funzionare se Gestione di rete è stata configurata per una scheda di rete sintetiche sulla
macchina virtuale. Per un corretto funzionamento dell'inserimento ip statico, assicurarsi che Network Manager sia disattivato
completamente o sia stato disattivato per una scheda di rete specifica tramite il relativo file ifcfg-ethX.

3. Quando si utilizzano dispositivi Fibre Channel virtuali, assicurarsi che il numero di unità logica 0 (LUN 0) sia stato configurato.
Se lun 0 non è stato popolato, una macchina virtuale Linux potrebbe non essere in grado di montare i dispositivi Fibre Channel
in modo nativo.

4. Per i LIS predefiniti, è necessario installare il pacchetto "hyperv-daemons" per questa funzionalità.

5. Se sono presenti handle di file aperti durante un'operazione di backup di macchina virtuale, quindi in alcuni casi estremi, i
dischi rigidi virtuali backup potrebbero essere necessario essere sottoposto a un controllo di coerenza di sistema di file (fsck)
su ripristino. Operazioni di backup Live possano un esito negativo se la macchina virtuale dispone di un dispositivo iSCSI
collegati o DAS (noto anche come disco pass-through).

6. (intenzionalmente omesso per la coerenza numerazione)

7. Supporto della memoria dinamica è disponibile solo nelle macchine virtuali a 64 bit.

8. Il supporto Hot-Add non è abilitato per impostazione predefinita in questa distribuzione. Per abilitare il supporto aggiunto a
caldo che è necessario aggiungere una regola di udev in /etc/udev/rules.d/ come indicato di seguito:
a. Creare un file /etc/udev/rules.d/[Link]. È possibile utilizzare qualsiasi altro nome per il file desiderato.
b. Aggiungere il seguente contenuto nel file: SUBSYSTEM=="memory", ACTION=="add", ATTR{state}="online"
c. Riavviare il sistema per consentire l'aggiunta a caldo.

Durante il download di Linux Integration Services crea questa regola su installazione, la regola è rimossi anche quando LIS
viene disinstallato, la regola deve essere ricreato se è necessaria una quantità di memoria dinamica dopo la disinstallazione.

9. Operazioni di memoria dinamica possono non riuscire se il sistema operativo guest è troppo memoria insufficiente. Di seguito
sono le procedure consigliate:

Memoria di avvio e di memoria minimo deve essere uguale o maggiore rispetto alla quantità di memoria in cui si
consiglia il fornitore.
Le applicazioni che tendono a consumare l'intera memoria disponibile in un sistema sono limitate all'utilizzo di fino a 80%
della RAM disponibile.

10. Se si usa la memoria dinamica in Windows Server, specificare i parametri Memoria di avvio, Memoria minima e Memoria
massima in multipli di 128 megabyte (MB). In caso contrario, può comportare errori a caldo e non sarà possibile visualizzare
qualsiasi memoria aumenta in un sistema operativo guest.

11. (intenzionalmente omesso per la coerenza numerazione)

12. Per abilitare l'infrastruttura (coppia chiave-VALORE) di coppia chiave/valore, installare il pacchetto rpm hypervkvpd o Hyper-v-
daemon dall'ISO di RHEL. In alternativa il pacchetto può essere installato direttamente dal repository RHEL.

13. L'infrastruttura (coppia chiave-VALORE) di coppia chiave/valore potrebbe non funzionare correttamente senza un
aggiornamento software Linux. Contattare il fornitore di distribuzione per ottenere l'aggiornamento software nel caso in cui
 noterete problemi con questa funzionalità.

14. Per impostazione predefinita, le macchine virtuali Windows Server Generation 2 hanno l'avvio protetto e alcune macchine
virtuali Linux non verranno avviati a meno che l'opzione di avvio protetto non sia disabilitata. È possibile disabilitare l'avvio
protetto nella sezione Firmware delle impostazioni per la macchina virtuale in Hyper-V Manager oppure disabilitarlo usando
PowerShell:

PowerShell

Set-VMFirmware -VMName "VMname" -EnableSecureBoot Off

Il download di Linux Integration Services può essere applicato alle macchine virtuali di seconda generazione esistenti, ma non
offre funzionalità di seconda generazione.

15. RHEL 8.5 richiede Windows Server 2019 o versione successiva o Azure Locale 20H2 o versione successiva.

Contenuti correlati
Set-VMFirmware

Macchine virtuali Debian supportate in Hyper-V

Macchine virtuali Oracle Linux supportate in Hyper-V

Macchine virtuali SUSE supportate in Hyper-V

Macchine virtuali Ubuntu supportate in Hyper-V

Macchine virtuali FreeBSD supportate in Hyper-V

Descrizioni delle funzionalità per macchine virtuali Linux e FreeBSD in Hyper-V

Procedure consigliate per l'esecuzione di Linux in Hyper-V

Certificazione Hardware di Red Hat

Last updated on 27/11/2025

Macchine virtuali Debian supportate in
Hyper-V
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Questo articolo descrive il supporto offerto per le macchine virtuali (VM) Debian in Hyper-V.

Legenda tabella
La mappa di distribuzione di funzionalità seguente indica le funzionalità presenti in ogni
versione di Windows Server. Dopo la tabella sono elencate i problemi noti e soluzioni
alternative per ogni distribuzione.

I LIS predefiniti - Linux Integration Services (LIS) sono inclusi nell'ambito di questa
distribuzione linux. Il pacchetto di download di LIS fornito da Microsoft non funziona per
questa distribuzione. Non installare il pacchetto Microsoft. I numeri di versione del
modulo kernel per il LIS predefinito (come illustrato da lsmod, ad esempio) sono diversi
dal numero di versione nel pacchetto di download LIS fornito da Microsoft. La mancata
corrispondenza non indica che la versione incorporata di LIS è scaduta.

✔ - Funzionalità disponibile

(vuoto) - Funzionalità non disponibile

ﾉ Espandi la tabella

Feature Versione di Windows 12 11 10 (Buster)

Server Hyper-V (lombrico) (Bullseye)

Availability LIS LIS LIS

integrato integrato integrato

Core 2025, 2022, 2019, 2016, ✔ ✔ ✔

2012 R2

Ora esatta di Windows Server 2025, 2022, 2019, 2016 ✔ Nota 4 ✔ Nota 4 ✔ Nota 4
2016

Networking

Jumbo frame 2025, 2022, 2019, 2016, ✔ ✔ ✔

2012 R2
Feature Versione di Windows 12 11 10 (Buster)
Server Hyper-V (lombrico) (Bullseye)

Assegnazione di tag e trunking 2025, 2022, 2019, 2016, ✔ ✔ ✔

VLAN 2012 R2

Migrazione in Tempo Reale 2025, 2022, 2019, 2016, ✔ ✔ ✔

2012 R2

Inserimento di IP statico 2025, 2022, 2019, 2016,

2012 R2

vRSS 2025, 2022, 2019, 2016, ✔ Nota 4 ✔ Nota 4 ✔ Nota 4

2012 R2

Offload checksum e 2025, 2022, 2019, 2016, ✔ Nota 4 ✔ Nota 4 ✔ Nota 4

segmentazione TCP 2012 R2

SR-IOV 2025, 2022, 2019, 2016 ✔ Nota 4 ✔ Nota 4 ✔ Nota 4

Storage

Ridimensionamento VHDX 2025, 2022, 2019, 2016, ✔ Nota 1 ✔ Nota 1 ✔ Nota 1

2012 R2

Fibre Channel virtuale 2025, 2022, 2019, 2016,

2012 R2

Backup delle macchine virtuali 2025, 2022, 2019, 2016, ✔ Nota 2 ✔ Nota 2 ✔ Nota 2
attive 2012 R2

Supporto TRIM 2025, 2022, 2019, 2016, ✔ Nota 4 ✔ Nota 4 ✔ Nota 4

2012 R2

SCSI WWN 2025, 2022, 2019, 2016, ✔ Nota 4 ✔ Nota 4 ✔ Nota 4

2012 R2

Memory

Supporto del kernel PAE 2025, 2022, 2019, 2016, ✔ ✔ ✔

2012 R2

Configurazione del gap MMIO 2025, 2022, 2019, 2016, ✔ ✔ ✔

2012 R2

Memoria dinamica - aggiunta a 2025, 2022, 2019, 2016, ✔ Nota 4 ✔ Nota 4 ✔ Nota 4
caldo 2012 R2

Memoria dinamica - Ballooning 2025, 2022, 2019, 2016, ✔ Nota 4 ✔ Nota 4 ✔ Nota 4
2012 R2

Ridimensionamento della 2025, 2022, 2019, 2016 ✔ Nota 4 ✔ Nota 4 ✔ Nota 4

Feature Versione di Windows 12 11 10 (Buster)
Server Hyper-V (lombrico) (Bullseye)

memoria di runtime

Video

Dispositivo video specifico Hyper- 2025, 2022, 2019, 2016, ✔ ✔ ✔

V 2012 R2

Miscellaneous

coppia Key-Value 2025, 2022, 2019, 2016, ✔ Nota 2 ✔ Nota 2 ✔ Nota 2

2012 R2

Interrupt non mascherabile 2025, 2022, 2019, 2016, ✔ ✔ ✔

2012 R2

Copia di file dall'host al guest 2025, 2022, 2019, 2016, ✔ Nota 2 ✔ Nota 2 ✔ Nota 2
2012 R2

Comando lsvmbus 2025, 2022, 2019, 2016,

2012 R2

socket Hyper-V 2025, 2022, 2019, 2016 ✔ Nota 4 ✔ Nota 4 ✔ Nota 4

Passthrough PCI/DDA 2025, 2022, 2019, 2016 ✔ Nota 4 ✔ Nota 4 ✔ Nota 4

Macchine virtuali di seconda

generazione

Avvio con UEFI 2025, 2022, 2019, 2016, ✔ Nota 3 ✔ Nota 3 ✔ Nota 3
2012 R2

Avvio protetto 2025, 2022, 2019, 2016 ✔ ✔ ✔

Notes
1. La creazione di file system in dischi rigidi virtuali di dimensioni superiori a 2 TB non è
supportata.

2. A partire da Debian 8.3, il pacchetto Debian installato manualmente "hyperv-daemons"

contiene i daemon per la coppia chiave-valore, fcopy e VSS. In Debian 7.x e 8.0-8.2 il
pacchetto hyperv-daemons deve provenire dai backport Debian .

3. In Windows Server 2012 R2 l'avvio protetto delle macchine virtuali di seconda

generazione è abilitato per impostazione predefinita e alcune macchine virtuali Linux non
si avviano a meno che l'opzione di avvio protetto non venga disabilitata. È possibile
 disabilitare l'avvio protetto nella sezione Firmware delle impostazioni per la macchina
virtuale in Hyper-V Manager oppure disabilitarlo usando PowerShell:

PowerShell
Set-VMFirmware -VMName "VMname" -EnableSecureBoot Off

4. Le funzionalità più recenti del kernel upstream sono disponibili solo usando i kernel
disponibili nel repository backport Debian .

Vedere anche
Macchine virtuali CentOS e Red Hat Enterprise Linux supportate in Hyper-V

Macchine virtuali Oracle Linux supportate in Hyper-V

Macchine virtuali SUSE Linux Enterprise Server (SLES) supportate in Hyper-V

Macchine virtuali Ubuntu supportate in Hyper-V

Macchine virtuali FreeBSD supportate in Hyper-V

Descrizioni delle funzionalità per macchine virtuali Linux e FreeBSD in Hyper-V

Procedure consigliate per l'esecuzione di Linux in Hyper-V

Last updated on 22/01/2026

Macchine virtuali Oracle Linux supportate
in Hyper-V
16/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

La mappa di distribuzione di funzionalità seguente indica le funzionalità presenti in ogni

versione. Dopo la tabella sono elencate i problemi noti e soluzioni alternative per ogni
distribuzione.

Contenuto della sezione:

Serie Oracle Linux 9.x

Serie Oracle Linux 8.x

Legenda tabella
Predefinito : LIS è incluso come parte di questa distribuzione linux. I numeri di versione
del modulo kernel per il LIS predefinito (come illustrato da lsmod, ad esempio) sono
diversi dal numero di versione nel pacchetto di download LIS fornito da Microsoft. Una
mancata corrispondenza non indica che incorporato LIS è scaduto.

✔ - Funzionalità disponibile

(vuoto) - Funzionalità non disponibile

RHCK - Kernel compatibile con Red Hat

Serie Oracle Linux 9.x

ﾉ Espandi la tabella

Feature Versione di Windows Server 9.0 (RHCK)

Availability

Core 2025, 2022, 2019, 2016, 2012 R2 ✔

Ora esatta di Windows Server 2016 2025, 2022, 2019, 2016 ✔

Networking

Jumbo frame 2025, 2022, 2019, 2016, 2012 R2 ✔

Feature Versione di Windows Server 9.0 (RHCK)

Assegnazione di tag e trunking VLAN 2025, 2022, 2019, 2016, 2012 R2 ✔

Migrazione in Tempo Reale 2025, 2022, 2019, 2016, 2012 R2 ✔

Inserimento di IP statico 2025, 2022, 2019, 2016, 2012 R2 ✔ Nota 1

vRSS 2025, 2022, 2019, 2016, 2012 R2 ✔

Segmentazione TCP e offload checksum 2025, 2022, 2019, 2016, 2012 R2 ✔

SR-IOV 2025, 2022, 2019, 2016 ✔

Storage

Ridimensionamento VHDX 2025, 2022, 2019, 2016, 2012 R2 ✔

Fibre Channel virtuale 2025, 2022, 2019, 2016, 2012 R2 ✔ Nota 2

Backup delle macchine virtuali attive 2025, 2022, 2019, 2016, 2012 R2 ✔ Nota 3

Supporto TRIM 2025, 2022, 2019, 2016, 2012 R2 ✔

SCSI WWN 2025, 2022, 2019, 2016, 2012 R2 ✔

Memory

Supporto del kernel PAE 2025, 2022, 2019, 2016, 2012 R2 N/A

Configurazione del gap MMIO 2025, 2022, 2019, 2016, 2012 R2 ✔

Memoria dinamica - aggiunta a caldo 2025, 2022, 2019, 2016, 2012 R2 ✔ Nota 4, 5, 6

Memoria dinamica - Ballooning 2025, 2022, 2019, 2016, 2012 R2 ✔ Nota 4, 5, 6

Ridimensionamento della memoria di runtime 2025, 2022, 2019, 2016 ✔

Video

Dispositivo video specifico Hyper-V 2025, 2022, 2019, 2016, 2012 R2 ✔

Miscellaneous

coppia Key-Value 2025, 2022, 2019, 2016, 2012 R2 ✔

Interrupt non mascherabile 2025, 2022, 2019, 2016, 2012 R2 ✔

Copia di file dall'host al guest 2025, 2022, 2019, 2016, 2012 R2 ✔

Comando lsvmbus 2025, 2022, 2019, 2016, 2012 R2 ✔

socket Hyper-V 2025, 2022, 2019, 2016 ✔

Feature Versione di Windows Server 9.0 (RHCK)

Passthrough PCI/DDA 2025, 2022, 2019, 2016 ✔

Macchine virtuali di seconda generazione

Avvio con UEFI 2025, 2022, 2019, 2016, 2012 R2 ✔ Nota 7

Avvio protetto 2025, 2022, 2019, 2016 ✔

Serie Oracle Linux 8.x

ﾉ Espandi la tabella

Feature Versione di Windows Server 8.0-8.5 (RHCK)

Availability

Core 2025, 2022, 2019, 2016, 2012 R2 ✔

Ora esatta di Windows Server 2016 2025, 2022, 2019, 2016 ✔

Networking

Jumbo frame 2025, 2022, 2019, 2016, 2012 R2 ✔

Assegnazione di tag e trunking VLAN 2025, 2022, 2019, 2016, 2012 R2 ✔

Migrazione in Tempo Reale 2025, 2022, 2019, 2016, 2012 R2 ✔

Inserimento di IP statico 2025, 2022, 2019, 2016, 2012 R2 ✔ Nota 1

vRSS 2025, 2022, 2019, 2016, 2012 R2 ✔

Segmentazione TCP e offload checksum 2025, 2022, 2019, 2016, 2012 R2 ✔

SR-IOV 2025, 2022, 2019, 2016 ✔

Storage

Ridimensionamento VHDX 2025, 2022, 2019, 2016, 2012 R2 ✔

Fibre Channel virtuale 2025, 2022, 2019, 2016, 2012 R2 ✔ Nota 2

Backup delle macchine virtuali attive 2025, 2022, 2019, 2016, 2012 R2 ✔ Nota 3

Supporto TRIM 2025, 2022, 2019, 2016, 2012 R2 ✔

SCSI WWN 2025, 2022, 2019, 2016, 2012 R2 ✔

Memory
Feature Versione di Windows Server 8.0-8.5 (RHCK)

Supporto del kernel PAE 2025, 2022, 2019, 2016, 2012 R2 N/A

Configurazione del gap MMIO 2025, 2022, 2019, 2016, 2012 R2 ✔

Memoria dinamica - aggiunta a caldo 2025, 2022, 2019, 2016, 2012 R2 ✔ Nota 4, 5, 6

Memoria dinamica - Ballooning 2025, 2022, 2019, 2016, 2012 R2 ✔ Nota 4, 5, 6

Ridimensionamento della memoria di runtime 2025, 2022, 2019, 2016 ✔

Video

Dispositivo video specifico Hyper-V 2025, 2022, 2019, 2016, 2012 R2 ✔

Miscellaneous

coppia Key-Value 2025, 2022, 2019, 2016, 2012 R2 ✔

Interrupt non mascherabile 2025, 2022, 2019, 2016, 2012 R2 ✔

Copia di file dall'host al guest 2025, 2022, 2019, 2016, 2012 R2 ✔

Comando lsvmbus 2025, 2022, 2019, 2016, 2012 R2 ✔

socket Hyper-V 2025, 2022, 2019, 2016 ✔

Passthrough PCI/DDA 2025, 2022, 2019, 2016 ✔

Macchine virtuali di seconda generazione

Avvio con UEFI 2025, 2022, 2019, 2016, 2012 R2 ✔ Nota 7

Avvio protetto 2025, 2022, 2019, 2016 ✔

Notes
1. Inserimento di IP statico potrebbe non funzionare se Gestione di rete è stata configurata
per una scheda di rete sintetiche sulla macchina virtuale. Per garantire il corretto
funzionamento di IP statico injection assicurarsi che l'amministratore di sistema è spento
completamente o è stato disattivato per una scheda di rete specifico tramite il file ifcfg-
ethX.

2. In Windows Server 2012 R2 durante l'utilizzo di dispositivi di virtuale fibre channel,

assicurarsi che il numero di unità logica (LUN 0) 0 è stato popolato. Se non è stato
popolato LUN 0, una macchina virtuale potrebbe non essere in grado di installare
dispositivi di fibre channel in modo nativo.
3. Se sono presenti handle di file aperti durante un'operazione di backup di macchina
virtuale, quindi in alcuni casi estremi, i dischi rigidi virtuali backup potrebbero essere
necessario essere sottoposto a un controllo di coerenza di sistema di file (fsck) su
ripristino. Operazioni di backup Live possano un esito negativo se la macchina virtuale
dispone di un dispositivo iSCSI collegati o DAS (noto anche come disco pass-through).

4. Aggiunta a caldo Supporto non è abilitato per impostazione predefinita in questa

distribuzione. Per abilitare il supporto aggiunto a caldo che è necessario aggiungere una
regola di udev in /etc/udev/rules.d/ come indicato di seguito:

a. Creare un file /etc/udev/rules.d/[Link]. È possibile utilizzare qualsiasi altro

nome per il file desiderato.

b. Aggiungere il seguente contenuto nel file: SUBSYSTEM=="memory", ACTION=="add",

ATTR{state}="online"

c. Riavviare il sistema per consentire l'aggiunta a caldo.

Durante il download di Linux Integration Services crea questa regola su installazione, la

regola è rimossi anche quando LIS viene disinstallato, la regola deve essere ricreato se è
necessaria una quantità di memoria dinamica dopo la disinstallazione.

5. Operazioni di memoria dinamica possono non riuscire se il sistema operativo guest è

troppo memoria insufficiente. Di seguito sono le procedure consigliate:

Memoria di avvio e di memoria minimo deve essere uguale o maggiore rispetto alla
quantità di memoria in cui si consiglia il fornitore.

Le applicazioni che tendono a consumare l'intera memoria disponibile in un sistema

sono limitate all'utilizzo di fino a 80% della RAM disponibile.

6. Se si usa la memoria dinamica in un sistema operativo Windows Server 2016 o Windows

Server 2012 R2, specificare i parametri Memoria di avvio, Memoria minima e Memoria
massima in multipli di 128 megabyte (MB). In caso contrario, può comportare errori a
caldo e non sarà possibile visualizzare qualsiasi memoria aumenta in un sistema operativo
guest.

7. Windows Server 2012 R2 generazione 2 macchine virtuali presentano avvio protetto

abilitato per impostazione predefinita e le macchine virtuali Linux non verranno avviate se
l'opzione di avvio protetto è disabilitata. È possibile disabilitare l'avvio protetto nella
sezione Firmware delle impostazioni per la macchina virtuale in Hyper-V Manager
oppure disabilitarlo usando PowerShell:

Powershell
 Set-VMFirmware -VMName "VMname" -EnableSecureBoot Off

Il download di Linux Integration Services può essere applicato alle macchine virtuali di 2
generazione esistente ma non applicare la funzionalità di generazione 2.

Contenuti correlati
Set-VMFirmware

Macchine virtuali CentOS e Red Hat Enterprise Linux supportate in Hyper-V

Macchine virtuali Debian supportate in Hyper-V

Macchine virtuali SUSE supportate in Hyper-V

Macchine virtuali Ubuntu supportate in Hyper-V

Macchine virtuali FreeBSD supportate in Hyper-V

Descrizioni delle funzionalità per macchine virtuali Linux e FreeBSD in Hyper-V

Procedure consigliate per l'esecuzione di Linux in Hyper-V

Macchine virtuali SUSE Linux Enterprise
Server (SLES) supportate in Hyper-V
16/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server
2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

SUSE Linux Enterprise Server (SLES) è supportato come sistema operativo guest in Hyper-V. Questo
articolo offre una panoramica dettagliata dei servizi di integrazione e delle funzionalità disponibili per
ogni versione SLES supportata. Usare la matrice di funzionalità inclusa per confrontare il supporto tra
versioni ed esaminare le note per dettagli importanti, problemi noti e soluzioni alternative consigliate.
Queste informazioni consentono di pianificare, distribuire e gestire macchine virtuali SLES in Hyper-V
con sicurezza.

Il driver di SUSE Linux Enterprise Service incorporati per Hyper-V sono certificati SUSE. Un esempio di
configurazione può essere visualizzato in questo bollettino Microsoft sulla sicurezza: SUSE SÌ
certificazione bollettino .

Legenda della tabella per le funzionalità della

macchina virtuale SLES
Predefinito : LIS è incluso come parte di questa distribuzione linux. Il pacchetto di download LIS
fornito da Microsoft non funziona per questa distribuzione, quindi non installarlo. I numeri di
versione del modulo kernel per il LIS predefinito (come illustrato da lsmod, ad esempio) sono
diversi dal numero di versione nel pacchetto di download LIS fornito da Microsoft. Una mancata
corrispondenza non indica che il LIS predefinito non è aggiornato.

✔ - Funzionalità disponibile

(vuoto) - Funzionalità non disponibile

SLES12+ è solo a 64 bit.

ﾉ Espandi la tabella

Feature Versione del sistema SLES SLES SLES SLES 12 SLES SLES SLES
operativo 15 15 12 SP2 12 SP1 11 SP4 11 SP3
SP1- SP3-
SP4 SP5

Availability Built- Built- Built- Installato Built- Built- Built-

in in in in in in

Core WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔
2025,2022,2019,2016,2012
Feature Versione del sistema SLES SLES SLES SLES 12 SLES SLES SLES
operativo 15 15 12 SP2 12 SP1 11 SP4 11 SP3
SP1- SP3-
SP4 SP5

Azure Stack HCI

Ora esatta di WS/Hyper-V ✔ ✔ ✔ ✔

Windows Server 2025,2022,2019,2016
2016

Networking

Jumbo frame WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔

2025,2022,2019,2016,2012
Azure Stack HCI

Assegnazione di WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔
tag e trunking 2025,2022,2019,2016,2012
VLAN Azure Stack HCI

Migrazione Live WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔

2025,2022,2019,2016,2012
Azure Stack HCI

Inserimento di IP WS/Hyper-V ✔Nota ✔Nota ✔Nota ✔Nota 1 ✔Nota ✔Nota ✔Nota

statico 2025,2022,2019,2016,2012 1 1 1 1 1 1
Azure Stack HCI

vRSS WS/Hyper-V ✔ ✔ ✔ ✔ ✔
2025,2022,2019,2016,2012
Azure Stack HCI

Segmentazione TCP WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔

e offload checksum 2025,2022,2019,2016,2012
Azure Stack HCI

SR-IOV WS/Hyper-V ✔ ✔ ✔ ✔
2025,2022,2019,2016,2012
Azure Stack HCI

Storage

Ridimensionamento WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔
VHDX 2025,2022,2019,2016,2012
Azure Stack HCI

Fibre Channel WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔

virtuale 2025,2022,2019,2016,2012
Azure Stack HCI

Backup delle WS/Hyper-V ✔ ✔Nota ✔ ✔ Nota ✔ ✔ ✔

macchine virtuali 2025,2022,2019,2016,2012 Nota 2,3,8 Nota 2,3,8 Nota Nota Nota
attive Azure Stack HCI 2,3,8 2,3,8 2,3,8 2,3,8 2,3,8
Feature Versione del sistema SLES SLES SLES SLES 12 SLES SLES SLES
operativo 15 15 12 SP2 12 SP1 11 SP4 11 SP3
SP1- SP3-
SP4 SP5

Supporto TRIM WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔

2025,2022,2019,2016,2012
Azure Stack HCI

SCSI WWN WS/Hyper-V ✔ ✔ ✔ ✔

2025,2022,2019,2016,2012
Azure Stack HCI

Memory

Supporto del kernel WS/Hyper-V N/A N/A N/A N/A N/A ✔ ✔

PAE 2025,2022,2019,2016,2012
Azure Stack HCI

Configurazione del WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔

gap MMIO 2025,2022,2019,2016,2012
Azure Stack HCI

Memoria dinamica WS/Hyper-V ✔ ✔Nota ✔ ✔ Nota ✔ ✔ ✔

- aggiunta a caldo 2025,2022,2019,2016,2012 Nota 6 Nota 6 Nota Nota Nota
Azure Stack HCI 6 6 6 4,5,6 4,5,6

Memoria dinamica WS/Hyper-V ✔ ✔ ✔ ✔ Nota ✔ ✔ ✔

- Ballooning 2025,2022,2019,2016,2012 Nota Nota Nota 6 Nota Nota Nota
Azure Stack HCI 6 6 6 6 4,5,6 4,5,6

Ridimensionamento WS/Hyper-V ✔ ✔ ✔ ✔ Nota

della memoria di 2025,2022,2019,2016 Nota Nota Nota 6
runtime 6 6 6

Video

Dispositivo video WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔

specifico Hyper-V 2025,2022,2019,2016,2012
Azure Stack HCI

Miscellaneous

Coppia WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔
chiave/valore 2025,2022,2019,2016,2012 Nota Nota
Azure Stack HCI 7 7

Interrupt non WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔

mascherabile 2025,2022,2019,2016,2012
Azure Stack HCI

Copia di file WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔

dall'host al guest 2025,2022,2019,2016,2012
Azure Stack HCI
Feature Versione del sistema SLES SLES SLES SLES 12 SLES SLES SLES
operativo 15 15 12 SP2 12 SP1 11 SP4 11 SP3
SP1- SP3-
SP4 SP5

Comando lsvmbus WS/Hyper-V ✔ ✔ ✔ ✔

2025,2022,2019,2016,2012
Azure Stack HCI

socket Hyper-V WS/Hyper-V ✔ ✔ ✔

2025,2022,2019,2016

Passthrough WS/Hyper-V ✔ ✔ ✔ ✔ ✔
PCI/DDA 2025,2022,2019,2016

Macchine virtuali
di seconda
generazione

Avvio con UEFI WS/Hyper-V ✔ ✔ ✔ ✔ Nota ✔ ✔

2025,2022,2019,2016,2012 Nota Nota Nota 9 Nota Nota
Azure Stack HCI 9 9 9 9 9

Avvio protetto WS/Hyper-V ✔ ✔ ✔ ✔ ✔

2025,2022,2019,2016

Notes
1. L'inserimento ip statico potrebbe non funzionare se NetworkManager è configurato per una
determinata scheda di rete specifica di Hyper-V nella macchina virtuale perché può eseguire
l'override delle impostazioni IP statiche configurate manualmente. Per garantire il corretto
funzionamento dell'inserimento ip statico, assicurarsi che Network Manager sia disattivato
completamente o sia disattivato per una scheda di rete specifica tramite il relativo file ifcfg-ethX
.

2. Se sono presenti handle di file aperti durante un'operazione di backup di macchina virtuale,
quindi in alcuni casi estremi, i dischi rigidi virtuali backup potrebbero essere necessario essere
sottoposto a un controllo di coerenza di sistema di file (fsck) su ripristino.

3. Operazioni di backup Live possano un esito negativo se la macchina virtuale dispone di un

dispositivo iSCSI collegati o DAS (noto anche come disco pass-through).

4. Operazioni di memoria dinamica possono non riuscire se il sistema operativo guest è troppo
memoria insufficiente. Di seguito sono le procedure consigliate:

Memoria di avvio e di memoria minimo deve essere uguale o maggiore rispetto alla
quantità di memoria in cui si consiglia il fornitore.
 Le applicazioni che tendono a consumare l'intera memoria disponibile in un sistema sono
limitate all'utilizzo di fino a 80% della RAM disponibile.

5. Supporto della memoria dinamica è disponibile solo nelle macchine virtuali a 64 bit.

6. Se si usa la memoria dinamica nei sistemi operativi Windows Server 2016 o Windows Server
2012, specificare i parametri Memoria di avvio, Memoria minima e Memoria massima in
multipli di 128 megabyte (MB). In caso contrario, può causare errori aggiunta a caldo di, e non
sarà possibile visualizzare qualsiasi memoria aumenta in un sistema operativo guest.

7. In Windows Server 2016 o Windows Server 2012 R2, l'infrastruttura di coppia chiave/valore
potrebbe non funzionare correttamente senza un aggiornamento software Linux. Contattare il
fornitore di distribuzione per ottenere l'aggiornamento software nel caso in cui noterete
problemi con questa funzionalità.

8. Il backup vss ha esito negativo se una singola partizione viene montata più volte.

9. In Windows Server 2012 R2 le macchine virtuali di seconda generazione hanno l'avvio protetto
abilitato per impostazione predefinita e le macchine virtuali Linux di seconda generazione non si
avviano a meno che l'opzione di avvio protetto non sia disabilitata. È possibile disabilitare
l'avvio protetto nella sezione Firmware delle impostazioni per la macchina virtuale in Hyper-V
Manager oppure disabilitarlo usando PowerShell:

Powershell

Set-VMFirmware -VMName "VMname" -EnableSecureBoot Off

Vedere anche
Set-VMFirmware

Macchine virtuali CentOS e Red Hat Enterprise Linux supportate in Hyper-V

Macchine virtuali Debian supportate in Hyper-V

Macchine virtuali Oracle Linux supportate in Hyper-V

Macchine virtuali Ubuntu supportate in Hyper-V

Macchine virtuali FreeBSD supportate in Hyper-V

Descrizioni delle funzionalità per macchine virtuali Linux e FreeBSD in Hyper-V

Procedure consigliate per l'esecuzione di Linux in Hyper-V

Macchine virtuali Ubuntu supportate in
Hyper-V
16/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

La mappa di distribuzione di funzionalità seguente indica le funzionalità di ogni versione. Dopo

la tabella sono elencate i problemi noti e soluzioni alternative per ogni distribuzione.

Legenda tabella
Built in - Linux Integration Services (LIS) è incluso come parte di questa distribuzione
linux. Il pacchetto di download LIS fornito da Microsoft non funziona per questa
distribuzione, quindi non installarlo. I numeri di versione del modulo kernel per il LIS
predefinito (come illustrato da lsmod, ad esempio) sono diversi dal numero di versione
nel pacchetto di download LIS fornito da Microsoft. Una mancata corrispondenza non
indica che il LIS integrato sia obsoleto.

✔ - Funzionalità disponibile

(vuoto) - Funzionalità non disponibile

ﾉ Espandi la tabella

Feature Versione del 24.04 22.04 20.04 18.04 16.04

sistema operativo LTS LTS LTS LTS LTS
Windows Server

Availability Built-in Built-in Built-in Built-in Built-in

Core 2025, 2022, 2019, ✔ ✔ ✔ ✔ ✔

2016

Ora esatta di Windows Server 2025, 2022, 2019, ✔ ✔ ✔ ✔ ✔

2016 2016

Networking

Jumbo frame 2025, 2022, 2019, ✔ ✔ ✔ ✔ ✔

2016

Assegnazione di tag VLAN e 2025, 2022, 2019, ✔ ✔ ✔ ✔ ✔

trunking delle VLAN 2016
Feature Versione del 24.04 22.04 20.04 18.04 16.04
sistema operativo LTS LTS LTS LTS LTS
Windows Server

Migrazione Live 2025, 2022, 2019, ✔ ✔ ✔ ✔ ✔

2016

Iniezione di IP statico 2025, 2022, 2019, ✔ Nota ✔ Nota ✔ Nota ✔ Nota ✔ Nota
2016 1 1 1 1 1

vRSS 2025, 2022, 2019, ✔ ✔ ✔ ✔ ✔

2016

Segmentazione e offload della 2025, 2022, 2019, ✔ ✔ ✔ ✔ ✔

checksum TCP 2016

SR-IOV 2025, 2022, 2019, ✔ ✔ ✔ ✔ ✔

2016

Storage

Ridimensionamento VHDX 2025, 2022, 2019, ✔ ✔ ✔ ✔ ✔

2016

Fibre Channel virtuale 2025, 2022, 2019, ✔ Nota ✔ Nota ✔ Nota ✔ Nota ✔ Nota
2016 2 2 2 2 2

Backup delle macchine virtuali 2025, 2022, 2019, ✔ Nota ✔ Nota ✔ Nota ✔ Nota ✔ Nota
attive 2016 3, 4, 5 3, 4, 5 3, 4, 5 3, 4, 5 3, 4, 5

Supporto TRIM 2025, 2022, 2019, ✔ ✔ ✔ ✔ ✔

2016

SCSI WWN 2025, 2022, 2019, ✔ ✔ ✔ ✔ ✔

2016

Memory

Supporto del kernel PAE 2025, 2022, 2019, ✔ ✔ ✔ ✔ ✔

2016

Configurazione del gap MMIO 2025, 2022, 2019, ✔ ✔ ✔ ✔ ✔

2016

Memoria dinamica - aggiunta 2025, 2022, 2019, ✔ Nota ✔ Nota ✔ Nota ✔ Nota ✔ Nota
a caldo 2016 6, 7, 8 6, 7, 8 6, 7, 8 6, 7, 8 6, 7, 8

Memoria Dinamica - Gestione 2025, 2022, 2019, ✔ Nota ✔ Nota ✔ Nota ✔ Nota ✔ Nota
della memoria con Ballooning 2016 6, 7, 8 6, 7, 8 6, 7, 8 6, 7, 8 6, 7, 8

Ridimensionamento della 2025, 2022, 2019, ✔ ✔ ✔ ✔ ✔

memoria di runtime 2016
Feature Versione del 24.04 22.04 20.04 18.04 16.04
sistema operativo LTS LTS LTS LTS LTS
Windows Server

Video

Dispositivo video specifico 2025, 2022, 2019, ✔ ✔ ✔ ✔ ✔

Hyper-V 2016

Miscellaneous

Coppia chiave/valore 2025, 2022, 2019, ✔ Nota ✔ Nota ✔ Nota ✔ Nota ✔ Nota
2016 5, 9 5, 9 5, 9 5, 9 5, 9

Interrupt non mascherabile 2025, 2022, 2019, ✔ ✔ ✔ ✔ ✔

2016

Copia di file dall'host al guest 2025, 2022, 2019, ✔ ✔ ✔ ✔ ✔

2016

Comando lsvmbus 2025, 2022, 2019, ✔ ✔ ✔ ✔ ✔

2016

socket Hyper-V 2025, 2022, 2019, ✔ ✔ ✔ ✔ ✔

2016

Passthrough PCI/DDA 2025, 2022, 2019, ✔ ✔ ✔ ✔ ✔

2016

Macchine virtuali di seconda

generazione

Avvio con UEFI 2025, 2022, 2019, ✔ ✔ ✔ Nota ✔ Nota ✔ Nota

2016 10, 11 10, 11 10, 11

Avvio protetto 2025, 2022, 2019, ✔ ✔ ✔ ✔ ✔

2016

Notes
1. L'inserimento ip statico potrebbe non funzionare se NetworkManager è stato configurato
per una determinata scheda di rete specifica di Hyper-V nella macchina virtuale perché
può eseguire l'override delle impostazioni IP statiche configurate manualmente. Per
garantire il corretto funzionamento dell'inserimento ip statico, assicurarsi che Network
Manager sia disattivato completamente o sia stato disattivato per una scheda di rete
specifica tramite il relativo file ifcfg-ethX .
2. Quando si utilizzano dispositivi di canale in fibra virtuale, assicurarsi che il numero di unità
logica 0 (LUN 0) sia stato popolato. Se lun 0 non è stato popolato, una macchina virtuale
Linux potrebbe non essere in grado di montare i dispositivi fibre channel in modo nativo.

3. Se vi sono handle dei file aperti durante un'operazione di backup di una macchina
virtuale, allora in alcuni casi estremi, i dischi rigidi virtuali sottoposti a backup potrebbero
dover eseguire una verifica di coerenza del file system ( fsck ) durante il ripristino.

4. Le operazioni di backup live possono fallire silenziosamente se la macchina virtuale ha un

dispositivo iSCSI collegato o un'archiviazione a collegamento diretto (noto anche come
disco pass-through).

5. Nelle versioni di supporto a lungo termine (LTS) utilizzare l'ultimo kernel di abilitazione
hardware (HWE) virtuale per i più aggiornati Linux Integration Services.

Per installare il kernel ottimizzato di Azure in Ubuntu, eseguire i comandi seguenti come
utente root (o sudo):

Bash

# apt-get update
# apt-get install linux-azure

6. Supporto della memoria dinamica è disponibile solo nelle macchine virtuali a 64 bit.

7. Le operazioni di memoria dinamica possono non riuscire se il sistema operativo guest

dispone di poca memoria. Di seguito sono le procedure consigliate:

La memoria di avvio e la memoria minima devono essere pari o superiori alla

quantità di memoria che il fornitore della distribuzione consiglia.

Le applicazioni che tendono a consumare l'intera memoria disponibile in un sistema

sono limitate all'utilizzo di fino a 80% della RAM disponibile.

8. Se si usa la memoria dinamica in Windows Server, specificare i parametri Memoria di

avvio, Memoria minima e Memoria massima in multipli di 128 megabyte (MB).
L'omissione di farlo può causare errori nell'aggiunta a caldo e potresti non vedere alcun
aumento della memoria in un sistema operativo guest.

9. In Windows Server 2019 e Windows Server 2016, l'infrastruttura della coppia

chiave/valore potrebbe non funzionare correttamente senza un aggiornamento software
Linux. Contattare il fornitore di distribuzione per ottenere l'aggiornamento software nel
caso in cui noterete problemi con questa funzionalità.
10. Le macchine virtuali di seconda generazione hanno l'avvio protetto abilitato per
impostazione predefinita e alcune macchine virtuali Linux non verranno avviati a meno
che l'opzione di avvio protetto non sia disabilitata. È possibile disabilitare l'avvio protetto
nella sezione Firmware delle impostazioni per la macchina virtuale in Hyper-V Manager
oppure disabilitarlo usando PowerShell:

Powershell

Set-VMFirmware -VMName "VMname" -EnableSecureBoot Off

11. Prima di tentare di copiare il disco rigido Virtuale di una macchina virtuale di generazione
2 VHD esistente per creare nuove macchine virtuali di generazione 2, seguire questi
passaggi:

a. Accedere alla macchina virtuale esistente di Generazione 2.

b. Cambiare directory nella directory di avvio EFI:

Bash

# cd /boot/efi/EFI

c. Copiare la directory ubuntu in una nuova directory denominata boot.

Bash

# sudo cp -r ubuntu/ boot

d. Passare alla directory di avvio appena creata.

Bash

# cd boot

e. Rinominare il file [Link]:

Bash

# sudo mv [Link] [Link]

12. Per eseguire migrazioni in tempo reale per le macchine virtuali configurate di seconda
generazione, l'opzione Esegui la migrazione a un computer fisico con una versione del
processore diversa deve essere abilitata in Compatibilità processore>nelle impostazioni
 della macchina virtuale. Per altre informazioni, vedere Modalità di compatibilità del
processore in Hyper-V.

Vedere anche
Macchine virtuali CentOS e Red Hat Enterprise Linux supportate in Hyper-V

Macchine virtuali Debian compatibili con Hyper-V

Macchine virtuali Oracle Linux supportate su Hyper-V

Macchine virtuali SUSE supportate su Hyper-V

Descrizioni delle funzionalità per macchine virtuali Linux e FreeBSD in Hyper-V

Procedure consigliate per l'esecuzione di Linux in Hyper-V

Set-VMFirmware

Ubuntu 14.04 in una macchina virtuale di seconda generazione - Blog di virtualizzazione

di Ben Armstrong
Macchine virtuali FreeBSD supportate in
Hyper-V
16/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

La mappa di distribuzione di funzionalità seguente indica le funzionalità di ogni versione. Dopo

la tabella sono elencate i problemi noti e soluzioni alternative per ogni distribuzione.

Legenda tabella
Built in - BIS (FreeBSD Integration Service) sono inclusi nell'ambito di questa versione di
FreeBSD.

✔ - Funzionalità disponibile

(vuoto) - Funzionalità non disponibile

ﾉ Espandi la tabella

Feature Versione del sistema operativo 13.0-13.5 12.0-12.4 11.0-11.4

Windows Server

Availability Installato Installato Installato

Core 2025, 2022, 2019, 2016, 2012 R2 ✔ ✔ ✔

Ora esatta di Windows Server 2016 2025, 2022, 2019, 2016 ✔ ✔ ✔

Networking

Jumbo frame 2025, 2022, 2019, 2016, 2012 R2 ✔ Nota ✔ Nota ✔ Nota
2 2 2

Assegnazione di tag e trunking 2025, 2022, 2019, 2016, 2012 R2 ✔ ✔ ✔

VLAN

Migrazione Live 2025, 2022, 2019, 2016, 2012 R2 ✔ ✔ ✔

Inserimento di IP statico 2025, 2022, 2019, 2016, 2012 R2 ✔ Nota ✔ Nota ✔ Nota
3 3 3

vRSS 2025, 2022, 2019, 2016, 2012 R2 ✔ ✔ ✔

Segmentazione TCP e offload 2025, 2022, 2019, 2016, 2012 R2 ✔ ✔ ✔

checksum
Feature Versione del sistema operativo 13.0-13.5 12.0-12.4 11.0-11.4
Windows Server

Grandi ricezione Offload (e) 2025, 2022, 2019, 2016, 2012 R2 ✔ ✔ ✔

SR-IOV 2025, 2022, 2019, 2016 ✔ ✔ ✔

Storage Nota 1 Note1 Nota 1

Ridimensionamento VHDX 2025, 2022, 2019, 2016, 2012 R2 ✔ Nota ✔ Nota ✔ Nota
6 6 6

Fibre Channel virtuale 2025, 2022, 2019, 2016, 2012 R2

Backup delle macchine virtuali 2025, 2022, 2019, 2016, 2012 R2 ✔ ✔ ✔

attive

Supporto TRIM 2025, 2022, 2019, 2016, 2012 R2 ✔ ✔ ✔

SCSI WWN 2025, 2022, 2019, 2016, 2012 R2

Memory

Supporto del kernel PAE 2025, 2022, 2019, 2016, 2012 R2

Configurazione del gap MMIO 2025, 2022, 2019, 2016, 2012 R2 ✔ ✔ ✔

Memoria dinamica - aggiunta a 2025, 2022, 2019, 2016, 2012 R2

caldo

Memoria dinamica - Ballooning 2025, 2022, 2019, 2016, 2012 R2

Ridimensionamento della memoria 2025, 2022, 2019, 2016

di runtime

Video

Dispositivo video specifico Hyper- 2025, 2022, 2019, 2016, 2012 R2

V

Miscellaneous

Coppia chiave/valore 2025, 2022, 2019, 2016, 2012 R2 ✔ ✔ ✔

Interrupt non mascherabile 2025, 2022, 2019, 2016, 2012 R2 ✔ ✔ ✔

Copia di file dall'host al guest 2025, 2022, 2019, 2016, 2012 R2

Comando lsvmbus 2025, 2022, 2019, 2016, 2012 R2

socket Hyper-V 2025, 2022, 2019, 2016

Passthrough PCI/DDA 2025, 2022, 2019, 2016 ✔ ✔ ✔

Feature Versione del sistema operativo 13.0-13.5 12.0-12.4 11.0-11.4
Windows Server

Macchine virtuali di seconda

generazione

Avvio con UEFI 2025, 2022, 2019, 2016, 2012 R2 ✔ ✔ ✔

Avvio protetto 2025, 2022, 2019, 2016

Notes
1. Suggerire di etichettare i dispositivi disco per evitare l'ERRORE DI MONTAGGIO RADICE
durante l'avvio.

2. 9126 è la dimensione MTU massima supportata.

3. In uno scenario di failover, è possibile impostare un indirizzo IPv6 statico nel server di
replica. Utilizzare un indirizzo IPv4.

Contenuti correlati
Descrizioni delle funzionalità per macchine virtuali Linux e FreeBSD in Hyper-V
Procedure consigliate per l'esecuzione di FreeBSD in Hyper-V
Procedure consigliate per l'esecuzione di
Linux in Hyper-V
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Questo articolo include un elenco di raccomandazioni per l'esecuzione di macchine virtuali

Linux in Hyper-V.

Ottimizzazione di file system Linux in file VHDX

dinamici
Alcuni file system Linux possono usare quantità significative di spazio su disco reale anche
quando il file system è per lo più vuoto. Per ridurre la quantità di spazio su disco reale dei file
VHDX dinamici, prendere in considerazione le raccomandazioni seguenti:

Quando si crea VHDX, usare 1 MB BlockSizeBytes (dal valore predefinito 32 MB) in

PowerShell, ad esempio:

Powershell

PS > New-VHD -Path C:\MyVHDs\[Link] -SizeBytes 127GB -Dynamic -BlockSizeBytes 1MB

Il formato ext4 è preferibile a ext3 perché ext4 è più efficiente dello spazio ext3 quando
viene usato con file VHDX dinamici.

Quando si crea il file system, specificare il numero di gruppi da 4096, ad esempio:

Bash
# mkfs.ext4 -G 4096 /dev/sdX1

Timeout del menu Grub nelle macchine virtuali

Generation 2
Poiché l'hardware legacy è stato rimosso dall'emulazione nelle macchine virtuali di seconda
generazione, il timer del menu grub conta alla rovescia troppo rapidamente per mostrare il
menu grub, caricando immediatamente la voce predefinita. Fino a quando grub non viene
corretto per usare il timer supportato da EFI, modificare /boot/grub/[Link],
/etc/default/grub o equivale a avere "timeout=100000" anziché il valore predefinito
"timeout=5".

Avvio PxE in macchine virtuali Generation 2

Poiché il timer PIT non è presente nelle macchine virtuali di seconda generazione, le
connessioni di rete al server TFTP PxE vengono terminate e impediscono al bootloader di
leggere la configurazione grub e caricare un kernel dal server.

In RHEL 6.x è possibile usare il bootloader EFI grub v0.97 legacy anziché grub2 come descritto
di seguito:
[Link]
[Link]

Nelle distribuzioni Linux diverse da RHEL 6.x è possibile seguire passaggi simili per configurare
grub v0.97 per caricare kernel Linux da un server PxE.

Inoltre, su RHEL/CentOS 6.6 l'input di tastiera e mouse non funziona con il kernel preinstallato,
il che impedisce di specificare le opzioni di installazione nel menu. Per consentire la scelta delle
opzioni di installazione, è necessario configurare una console seriale.

Nel file efidefault nel server PxE aggiungere il parametro kernel seguente
"console=ttyS1"

Nella macchina virtuale in Hyper-V configurare una porta COM usando questo cmdlet di
PowerShell:

Powershell

Set-VMComPort -VMName <Name> -Number 2 -Path \\.\pipe\dbg1

Se si specifica un file kickstart nel kernel, si evita anche la necessità di input da tastiera e mouse
durante l'installazione.

Usare indirizzi MAC statici con clustering di failover

Le macchine virtuali Linux distribuite con il clustering di failover devono essere configurate con
un indirizzo MAC (Media Access Control) statico per ogni scheda di rete virtuale. In alcune
versioni di Linux, la configurazione di rete potrebbe andare persa dopo il failover perché viene
assegnato un nuovo indirizzo MAC alla scheda di rete virtuale. Per evitare di perdere la
configurazione di rete, assicurarsi che ogni scheda di rete virtuale abbia un indirizzo MAC
statico. È possibile configurare l'indirizzo MAC modificando le impostazioni della macchina
virtuale in Gestione Hyper-V o Gestione cluster di failover.

Usare schede di rete specifiche di Hyper-V, non la

scheda di rete legacy
Configurare e usare la scheda Ethernet virtuale, ovvero una scheda di rete specifica di Hyper-V
con prestazioni migliorate. Se entrambe le schede di rete legacy e specifiche di Hyper-V sono
collegate a una macchina virtuale, i nomi di rete nell'output di ifconfig -a potrebbero mostrare
valori casuali, ad esempio _tmp12000801310. Per evitare questo problema, rimuovere tutte le
schede di rete legacy quando si usano schede di rete specifiche di Hyper-V in una macchina
virtuale Linux.

） Importante

Hyper-V supporta fino a 64 schede Ethernet virtuali per ciascuna macchina virtuale.
Tuttavia, quando più di 2 vCPU vengono assegnate a un guest Linux, la macchina virtuale
potrebbe non visualizzare il massimo di 64 schede Ethernet virtuali. Per altre informazioni
sui limiti di scalabilità Hyper-V, vedere Hyper-V limiti massimi di scalabilità in Windows
Server.

Usare l'utilità di pianificazione I/O noop/none per

migliorare le prestazioni di I/O su disco
Il kernel Linux offre due set di utilità di pianificazione di I/O su disco per riordinare le richieste.
Un set riguarda il sottosistema "blk" precedente e un set è per il sottosistema "blk-mq" più
recente. In entrambi i casi, con i dischi a stato solido di oggi è consigliabile usare un'utilità di
pianificazione che passa le decisioni di pianificazione all'hypervisor Hyper-V sottostante. Per i
kernel Linux che usano il sottosistema "blk", si tratta dell'utilità di pianificazione "noop". Per i
kernel Linux che usano il sottosistema "blk-mq", si tratta dello schedulatore "none".

Per un disco specifico, le utilità di pianificazione disponibili possono essere visualizzate nel
seguente percorso del file system: /sys/class/block/ <diskname> queue/scheduler, con l'utilità di
pianificazione attualmente selezionata tra parentesi quadre. È possibile modificare l'utilità di
pianificazione scrivendo in questo percorso del file system. La modifica deve essere aggiunta a
uno script di inizializzazione per rendere persistente i riavvii. Per informazioni dettagliate,
consultare la documentazione della distribuzione linux.
NUMA
I kernel Linux con versione precedente a 2.6.37 non supportano NUMA in Hyper-V con
macchine virtuali di dimensioni maggiori. Questo problema incide principalmente sulle
distribuzioni precedenti che usano il kernel upstream Red Hat 2.6.32. Il problema è stato risolto
in Red Hat Enterprise Linux (RHEL) 6.6 (kernel-2.6.32-504). I sistemi che eseguono kernel
personalizzati con versione precedente a 2.6.37 o kernel basati su RHEL con versione
precedente a 2.6.32-504 devono impostare il parametro di avvio numa=off nella riga di
comando del kernel in [Link]. Per altre informazioni, vedere l'articolo KB 436883 di Red
Hat.

Riservare più memoria per kdump

Nel caso in cui il kernel di acquisizione dump finisca con un panico all'avvio, riservare più
memoria per il kernel. Ad esempio, modificare il parametro crashkernel=384M-:128M in
crashkernel=384M-:256M nel file di configurazione di Ubuntu grub.

La compattazione di VHDX o l'espansione di file

VHDX e VHDX possono comportare tabelle di
partizione GPT errate
Hyper-V consente la compattazione dei file VHDX senza considerare le strutture di dati di
partizione, volume o file system che possono essere presenti sul disco. Se il VHDX viene ridotto
fino a un punto che precede la fine di una partizione, i dati vengono persi, la partizione può
diventare corrotta oppure possono essere restituiti dati non validi quando si legge la
partizione.

Dopo il ridimensionamento di un disco rigido virtuale o VHDX, gli amministratori devono usare
un'utilità come fdisk o parted per aggiornare le strutture di partizione, volume e file system in
modo da riflettere la modifica delle dimensioni del disco. La compattazione o l'espansione
delle dimensioni di un disco rigido virtuale o VHDX con una tabella di partizione GUID (GPT)
genera un avviso quando viene usato uno strumento di gestione delle partizioni per controllare
il layout della partizione e l'amministratore viene avvisato di correggere le intestazioni GPT
prime e secondarie. Questo passaggio manuale è sicuro da eseguire senza perdita di dati.

Contenuti correlati
Linux e FreeBSD macchine virtuali supportate per Hyper-V in Windows
 Procedure consigliate per l'esecuzione di FreeBSD in Hyper-V

Creare immagini Linux per Azure

Ottimizzare la macchina virtuale Linux su Azure

Last updated on 03/12/2025

Procedure consigliate per l'esecuzione di
FreeBSD in Hyper-V
14/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Questo argomento contiene un elenco di raccomandazioni per l'esecuzione di FreeBSD come

sistema operativo guest in una macchina virtuale Hyper-V.

Abilitare CARP in FreeBSD 10.2 in Hyper-V

Il protocollo CARP (Common Address Redundancy Protocol) consente a più host di condividere
lo stesso indirizzo IP e lo stesso ID host virtuale (VHID) per offrire disponibilità elevata per uno
o più servizi. Se uno o più host hanno esito negativo, gli altri host assumono il controllo in
modo trasparente in modo che gli utenti non notino un errore del servizio. Per usare CARP in
FreeBSD 10.2, seguire le istruzioni nel manuale di FreeBSD ed eseguire le operazioni seguenti
in Hyper-V Manager.

Verificare che alla macchina virtuale sia associata una scheda di rete e che sia assegnata a
un commutatore virtuale. Selezionare la macchina virtuale e selezionare
Azioni>Impostazioni.

Screenshot delle impostazioni della macchina virtuale con la scheda di rete selezionata

Abilitare lo spoofing degli indirizzi MAC. A tale scopo, seguire questa procedura:

1. Selezionare la macchina virtuale e selezionare Azioni>Impostazioni.

2. Espandere Scheda di rete e selezionare Funzionalità avanzate.

3. Selezionare Attivare spoofing indirizzi MAC.

Creare etichette per i dispositivi disco

Durante l'avvio, i nodi del dispositivo vengono creati quando vengono individuati nuovi
dispositivi. Ciò può significare che i nomi dei dispositivi possono cambiare quando vengono
aggiunti dei nuovi dispositivi. Se si riceve un ERRORE DI MONTAGGIO RADICE durante l'avvio, è
necessario creare etichette per ogni partizione IDE per evitare conflitti e modifiche. Per
informazioni su come, vedere Etichettatura dei dispositivi disco . Di seguito sono riportati
alcuni esempi.
） Importante

Eseguire una copia di backup del file fstab prima di apportare modifiche.

1. Riavviare il sistema in modalità utente singolo. A tale scopo, selezionare l'opzione di

menu di avvio 2 per FreeBSD 10.3+ (opzione 4 per FreeBSD 8.x) o eseguire un 'boot -s'
dal prompt di avvio.

2. In modalità utente singolo creare etichette GEOM per ognuna delle partizioni del disco
IDE elencate nel file fstab (radice e swap). Di seguito è riportato un esempio di FreeBSD
10.3.

Bash

# cat /etc/fstab
# Device Mountpoint FStype Options Dump Pass#
/dev/da0p2 / ufs rw 1 1
/dev/da0p3 none swap sw 0 0

# glabel label rootfs /dev/da0p2

# glabel label swap /dev/da0p3
# exit

Altre informazioni sulle etichette GEOM sono disponibili in: Etichettatura dei dispositivi
disco .

3. Il sistema continuerà con l'avvio multiutente. Al termine dell'avvio, modificare /etc/fstab e

sostituire i nomi dei dispositivi convenzionali con le rispettive etichette. Il file /etc/fstab
finale sarà simile al seguente:

# Device Mountpoint FStype Options Dump Pass#

/dev/label/rootfs / ufs rw 1 1
/dev/label/swap none swap sw 0 0

4. Il sistema può ora essere riavviato. Se tutto è andato bene, verrà visualizzato
normalmente e il montaggio mostrerà:

# mount
/dev/label/rootfs on / (ufs, local, journaled soft-updates)
devfs on /dev (devfs, local, mutilabel)
Usare una scheda di rete wireless come
commutatore virtuale
Se il commutatore virtuale nell'host è basato sulla scheda di rete wireless, ridurre la scadenza
ARP a 60 secondi con il comando seguente. In caso contrario, la rete della macchina virtuale
potrebbe smettere di funzionare dopo un po'.

# sysctl [Link].max_age=60

Vedere anche

Macchine virtuali supportate FreeBSD su Hyper-V

È necessario creare una macchina virtuale
di generazione 1 o 2 in Hyper-V?
16/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

La creazione di una macchina virtuale di prima o seconda generazione dipende dal sistema
operativo guest da installare e dal metodo di avvio da usare per distribuire la macchina
virtuale. È consigliabile creare macchine virtuali di seconda generazione per sfruttare le
funzionalità come l'avvio protetto, a meno che una delle istruzioni seguenti non sia vera:

Si sta usando un disco rigido virtuale esistente predefinito (file VHD o VHDX), che non è
compatibile con UEFI.
La generazione 2 non supporta il sistema operativo che si vuole eseguire nella macchina
virtuale.
La generazione 2 non supporta il metodo di avvio che si vuole usare.

Per altre informazioni sulle funzionalità disponibili con le macchine virtuali di seconda
generazione, vedere Hyper-V compatibilità delle funzionalità per generazione e guest.

Non è possibile modificare la generazione di una macchina virtuale dopo la creazione. È

consigliabile esaminare le considerazioni qui e scegliere il sistema operativo, il metodo di avvio
e le funzionalità da usare prima di scegliere una generazione.

Quali sono i vantaggi dell'uso di macchine virtuali

di seconda generazione?
Ecco alcuni dei vantaggi che si ottengono quando si usa una macchina virtuale di seconda
generazione:

Avvio protetto

Usare l'avvio protetto per impedire l'esecuzione di firmware, sistemi operativi o driver
UEFI non autorizzati in fase di avvio. L'avvio protetto verifica che il caricatore di avvio sia
firmato da un'autorità attendibile nel database UEFI. L'avvio protetto è abilitato per
impostazione predefinita per le macchine virtuali di seconda generazione. Se è necessario
eseguire un sistema operativo guest che l'avvio protetto non supporta, è possibile
disabilitarlo dopo aver creato la macchina virtuale. Per altre informazioni, vedere Avvio
protetto.
 Per proteggere le macchine virtuali Linux di seconda generazione, è necessario scegliere il
modello di avvio protetto della CA UEFI quando si crea la macchina virtuale.

Volume di avvio più grande Il volume di avvio massimo per le macchine virtuali di
seconda generazione è 64 TB. Questo volume di avvio massimo è la dimensione massima
del disco supportata da una .VHDX macchina virtuale di prima generazione, il volume di
avvio massimo è di 2 TB per un .VHDX e 2040 GB per un .VHD per per altre informazioni,
vedere Hyper-V Panoramica del formato disco rigido virtuale.

È anche possibile notare un lieve miglioramento dei tempi di avvio e installazione delle
macchine virtuali con macchine virtuali di seconda generazione.

Quali sistemi operativi guest sono supportati?

Le macchine virtuali di prima generazione supportano la maggior parte dei sistemi operativi
guest. Le macchine virtuali di seconda generazione supportano la maggior parte delle versioni
a 64 bit di Windows e altre versioni correnti dei sistemi operativi Linux e FreeBSD. Usare le
sezioni seguenti per vedere quale generazione di macchina virtuale supporta il sistema
operativo guest da installare.

Supporto del sistema operativo guest Windows

Supporto del sistema operativo guest CentOS e Red Hat Enterprise Linux

Supporto del sistema operativo guest Debian

Supporto del sistema operativo guest FreeBSD

Supporto del sistema operativo guest Oracle Linux

Supporto del sistema operativo guest SUSE

Supporto del sistema operativo guest Ubuntu

Supporto del sistema operativo guest Windows

La tabella seguente illustra le versioni a 64 bit di Windows che è possibile usare come sistema
operativo guest per le macchine virtuali di prima e seconda generazione.

ﾉ Espandi la tabella

Versioni a 64 bit di Windows Generazione 1 Generazione 2

Windows Server 2025 ✔ ✔

 Versioni a 64 bit di Windows Generazione 1 Generazione 2

Windows Server 2022 ✔ ✔

Windows Server 2019 ✔ ✔

Windows Server 2016 ✔ ✔

Windows Server 2012 R2 ✔ ✔

Windows Server 2012 ✔ ✔

Windows 11 ✖ ✔

Windows 10 ✔ ✔

La tabella seguente illustra le versioni a 32 bit di Windows che è possibile usare come sistema
operativo guest per le macchine virtuali di prima e seconda generazione.

ﾉ Espandi la tabella

Versioni a 32 bit di Windows Generazione 1 Generazione 2

Windows 10 ✔ ✖

Supporto del sistema operativo guest CentOS e Red Hat

Enterprise Linux
La tabella seguente illustra le versioni di Red Hat Enterprise Linux (RHEL) e CentOS che è
possibile usare come sistema operativo guest per le macchine virtuali di prima e seconda
generazione.

ﾉ Espandi la tabella

Versioni del sistema operativo Generazione 1 Generazione 2

Serie RHEL/CentOS 10.x ✔ ✔

Serie RHEL/CentOS 9.x ✔ ✔

Serie RHEL/CentOS 8. x ✔ ✔

Per altre informazioni, vedere Macchine virtuali CentOS e Red Hat Enterprise Linux in Hyper-V.

Supporto del sistema operativo guest Debian

La tabella seguente illustra le versioni di Debian che è possibile usare come sistema operativo
guest per le macchine virtuali di prima e seconda generazione.

ﾉ Espandi la tabella

Versioni del sistema operativo Generazione 1 Generazione 2

Serie Debian 12.x (Bookworm) ✔ ✔

Serie Debian 11.x (Bullseye) ✔ ✔

Serie Debian 10.x (Buster) ✔ ✔

Per altre informazioni, vedere Macchine virtuali Debian in Hyper-V.

Supporto del sistema operativo guest FreeBSD

La tabella seguente illustra le versioni di FreeBSD che è possibile usare come sistema operativo
guest per le macchine virtuali di prima e seconda generazione.

ﾉ Espandi la tabella

Versioni del sistema operativo Generazione 1 Generazione 2

FreeBSD da 13.0 a 13.5 ✔ ✔

Da FreeBSD 12.0 a 12.4 ✔ ✔

FreeBSD da 11.0 a 11.4 ✔ ✔

Per altre informazioni, vedere Macchine virtuali FreeBSD in Hyper-V.

Supporto del sistema operativo guest Oracle Linux

La tabella seguente illustra le versioni di Red Hat Compatible Kernel Series che è possibile
usare come sistema operativo guest per le macchine virtuali di prima e seconda generazione.

ﾉ Espandi la tabella

Versioni della serie kernel compatibile con Red Hat Generazione 1 Generazione 2

Serie Oracle Linux 9.x ✔ ✔

Serie Oracle Linux 8.x ✔ ✔

La tabella seguente illustra le versioni di Unbreakable Enterprise Kernel che è possibile usare
come sistema operativo guest per le macchine virtuali di prima e seconda generazione.

ﾉ Espandi la tabella

Versioni di Unbreakable Enterprise Kernel (UEK) Generazione 1 Generazione 2

Oracle Linux UEK R3 QU3 ✔ ✖

Oracle Linux UEK R3 QU2 ✔ ✖

Oracle Linux UEK R3 QU1 ✔ ✖

Per altre informazioni, vedere Macchine virtuali Oracle Linux in Hyper-V.

Supporto del sistema operativo guest SUSE

La tabella seguente illustra le versioni di SUSE che è possibile usare come sistema operativo
guest per le macchine virtuali di prima e seconda generazione.

ﾉ Espandi la tabella

Versioni del sistema operativo Generazione 1 Generazione 2

Serie SUSE Linux Enterprise Server 15 ✔ ✔

Serie SUSE Linux Enterprise Server 12 ✔ ✔

Serie SUSE Linux Enterprise Server 11 ✔ ✖

Aprire SUSE 12.3 + ✔ ✖

Per altre informazioni, vedere Macchine virtuali SUSE in Hyper-V.

Supporto del sistema operativo guest Ubuntu

La tabella seguente illustra le versioni di Ubuntu che è possibile usare come sistema operativo
guest per le macchine virtuali di prima e seconda generazione.

ﾉ Espandi la tabella

Versioni del sistema operativo Generazione 1 Generazione 2

Ubuntu 24.04 ✔ ✔

Ubuntu 22.04 ✔ ✔
 Versioni del sistema operativo Generazione 1 Generazione 2

Ubuntu 20.04 ✔ ✔

Ubuntu 18.04 ✔ ✔

Ubuntu 16.04 ✔ ✔

Ubuntu 14.04 ✔ ✔

Per altre informazioni, vedere Macchine virtuali Ubuntu in Hyper-V.

Come è possibile avviare la macchina virtuale?

Le macchine virtuali di prima e seconda generazione supportano metodi di avvio diversi, questi
metodi sono illustrati nella tabella seguente.

ﾉ Espandi la tabella

Metodo di avvio Generazione Generazione

1 2

Avvio PXE tramite una scheda di rete standard ✖ ✔

Avvio PXE tramite una scheda di rete legacy ✔ ✖

Eseguire l'avvio da un disco rigido virtuale SCSI ( .VHDX) o da un DVD ✖ ✔

virtuale (. ISO)

Avvio da disco rigido virtuale del controller IDE ( .VHD) , DVD virtuale ✔ ✖
( .ISO) o un'unità CD/DVD fisica

Avvio da floppy virtuale ( .VFD) ✔ ✖

Qual è la differenza nel supporto dei dispositivi?

Nella tabella seguente vengono confrontati i dispositivi disponibili tra le macchine virtuali di
prima e seconda generazione.

ﾉ Espandi la tabella
Dispositivo di prima Sostituzione con la Miglioramenti della seconda generazione
generazione seconda
generazione

Controller IDE Controller SCSI Avvio da .VHDX (dimensioni massime di 64 TB

virtuale e funzionalità di ridimensionamento online)

CD-ROM IDE CD-ROM SCSI Supporto di 64 dispositivi DVD SCSI per ogni
virtuale controller SCSI.

Legacy BIOS Firmware UEFI Avvio protetto

Scheda di rete legacy Scheda di rete Avvio di rete con IPv4 e IPv6
sintetica

Controller floppy e controller Nessun supporto per N/A

DMA il controller floppy

Universal Asynchronous UART facoltativo per Più veloce e affidabile

Receiver/Transmitter (UART) per il debug
porte COM

Controller tastiera i8042 Input basato su Usa meno risorse perché non sono previste
software emulazioni. Inoltre riduce la superficie di
attacco dal sistema operativo guest.

Tastiera PS/2 Tastiera basata su Usa meno risorse perché non sono previste
software emulazioni. Inoltre riduce la superficie di
attacco dal sistema operativo guest.

PS/2 mouse Mouse basato su Usa meno risorse perché non sono previste
software emulazioni. Inoltre riduce la superficie di
attacco dal sistema operativo guest.

Video S3 Video basato su Usa meno risorse perché non sono previste
software emulazioni. Inoltre riduce la superficie di
attacco dal sistema operativo guest.

Bus PCI Non più necessario N/A

Programmable Interrupt Non più necessario N/A

Controller (PIC)

Programmable Interval Timer Non più necessario N/A

(PIT)

Dispositivo Super I/O Non più necessario N/A

Considerazioni sull'uso di macchine virtuali di
prima e seconda generazione
Ecco altri suggerimenti sull'uso delle diverse generazioni di macchine virtuali.

Creare macchine virtuali con più di 64 CPU logiche

La console di gestione di Hyper-V potrebbe non riuscire a creare una nuova macchina virtuale
di prima generazione in un sistema con più di 64 CPU logiche. La console di gestione di Hyper-
V non consente di specificare il numero di processori virtuali in fase di creazione della
macchina virtuale. Per gli host con più di 64 processori logici, specificare il numero di
processori virtuali durante la creazione di macchine virtuali tramite Windows Admin Center,
PowerShell o un altro strumento.

Caricare un disco rigido virtuale in Azure

I dischi rigidi virtuali creati nelle macchine virtuali di prima e seconda generazione possono
essere caricati in Azure, purché usino il formato di file VHD. Il disco rigido virtuale deve avere
un disco con dimensioni fisse (non a espansione dinamica). Per altre informazioni sulle
funzionalità di seconda generazione supportate in Azure, vedere Vm di seconda generazione in
Azure . Per altre informazioni sul caricamento di un disco rigido virtuale Windows o VHDX,
vedere Preparare un disco rigido virtuale Windows o VHDX da caricare in Azure.

Collegare o aggiungere un'unità DVD

Non è possibile collegare un'unità CD o DVD fisica a una macchina virtuale di seconda
generazione. L'unità DVD virtuale nelle macchine virtuali di seconda generazione
supporta solo file di immagine ISO. Per creare un file di immagine ISO di un ambiente
Windows, è possibile usare lo strumento da riga di comando OScdimg . Per altre
informazioni, vedere Opzioni di Command-Line Oscdimg.
Quando si crea una nuova macchina virtuale con il cmdlet di Windows PowerShell New-VM ,
la macchina virtuale di seconda generazione non dispone di un'unità DVD. È possibile
aggiungere un'unità DVD mentre la macchina virtuale è in esecuzione.

Usare il firmware UEFI

L'avvio protetto o il firmware UEFI non è necessario nell'host Hyper-V fisico. Per le
macchine virtuali di seconda generazione, Hyper-V fornisce il firmware virtuale alle
macchine virtuali indipendenti da ciò che si trova nell'host Hyper-V.
 Il firmware UEFI in una macchina virtuale di seconda generazione non supporta la
modalità di installazione per l'avvio protetto.
Non è supportata l'esecuzione di una shell UEFI o di altre applicazioni UEFI in una
macchina virtuale di seconda generazione. L'uso di una shell UEFI o di applicazioni UEFI
non Microsoft è tecnicamente possibile se vengono compilate direttamente dalle origini.
Se queste applicazioni non sono firmate digitalmente correttamente, è necessario
disabilitare l'avvio protetto per la macchina virtuale.

Usare i file VHDX

È possibile ridimensionare un file VHDX contenente il volume di avvio per una macchina
virtuale di seconda generazione mentre la macchina virtuale è in esecuzione.
Non è supportato né si consiglia di creare un singolo disco virtuale (file VHD o VHDX) che
sia avviabile in macchine virtuali di prima e seconda generazione. Creare invece file VHDX
di avvio destinati solo alle macchine virtuali di prima o seconda generazione.
La generazione è una proprietà della macchina virtuale e non del disco rigido virtuale.
Non è possibile stabilire se un file VHDX è stato creato come macchina virtuale di prima o
seconda generazione.
Un file VHDX creato con una macchina virtuale di seconda generazione può essere
collegato al controller IDE o al controller SCSI di una macchina virtuale di prima
generazione. Tuttavia, se il disco rigido virtuale è un file VHDX di avvio, l'avvio della
macchina virtuale di prima generazione non riesce.

Usare IPv6 anziché IPv4

Quando si esegue l'avvio dalla rete con PXE, le macchine virtuali di seconda generazione usano
IPv4 per impostazione predefinita. Per usare invece IPv6, eseguire il cmdlet Set-VMFirmware di
Windows PowerShell. Ad esempio, il comando seguente imposta il protocollo preferito su IPv6
per una macchina virtuale denominata TestVM:

PowerShell

Set-VMFirmware -VMName 'TestVM' -IPProtocolPreference IPv6

Aggiungere una porta COM per il debug del kernel

Le porte COM non sono disponibili nelle macchine virtuali di seconda generazione finché non
vengono aggiunte. È possibile aggiungere porte COM con Windows PowerShell o
Strumentazione gestione Windows (WMI). Questi passaggi illustrano come eseguire questa
operazione con Windows PowerShell.
Per aggiungere una porta COM:

1. Disabilitare l'avvio protetto. Il debug del kernel non è compatibile con l'avvio protetto.
Assicurarsi che la macchina virtuale sia in stato Off e quindi usare il cmdlet Set-
VMFirmware . Il comando seguente, ad esempio, disabilita l'avvio protetto nella macchina
virtuale TestVM:

PowerShell

Set-VMFirmware -VMName 'TestVM' -EnableSecureBoot Off

2. Aggiungere una porta COM. Usare il cmdlet Set-VMComPort per aggiungere una porta
COM. Il comando seguente, ad esempio, configura la prima porta COM nella macchina
virtuale, TestVM, per la connessione alla named pipe, TestPipe, sul computer locale:

PowerShell

Set-VMComPort -VMName 'TestVM' -Number 1 -Path '\\.\pipe\TestPipe'

７ Nota

Le porte COM configurate non sono elencate nelle impostazioni di una macchina virtuale
nella console di gestione di Hyper-V.

Contenuti correlati
Macchine virtuali Linux e FreeBSD in Hyper-V
Usare le risorse locali su la macchina virtuale Hyper-V con VMConnect
Pianificare la scalabilità Hyper-V in Windows Server 2016
Impostazioni di sicurezza di generazione 1
macchina virtuale
02/07/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Utilizzare le impostazioni di sicurezza di generazione 1 macchina virtuale in Hyper-V Manager

per proteggere i dati e lo stato di una macchina virtuale.

Impostazioni di supporto della crittografia nella

console di gestione di Hyper-V
È possibile proteggere i dati e lo stato della macchina virtuale selezionando l'opzione di
supporto di crittografia seguenti.

Crittografare il traffico di migrazione dello stato e la macchina virtuale -consente di

crittografare lo stato della macchina virtuale salvata quando viene scritta su disco e il
traffico di migrazione in tempo reale.

Per abilitare questa opzione, è necessario aggiungere un'unità di archiviazione chiavi per la
macchina virtuale.

Unità di archiviazione delle chiavi nella gestione di

Hyper-V
Un'unità di archiviazione chiavi fornisce un'unità di piccole dimensioni per la macchina virtuale
per una chiave di BitLocker da archiviare. In questo modo la macchina virtuale crittografare il
disco del sistema operativo senza richiedere un chip Trusted Platform Module (TPM)
virtualizzate. Il contenuto dell'unità di archiviazione chiavi crittografato con una protezione con
chiave. L'host di protezione con chiave authories Hyper-V per eseguire la macchina virtuale. Sia
il contenuto dell'unità di archiviazione delle chiavi e la protezione con chiave viene archiviato
come parte dello stato di runtime della macchina virtuale.

Per decrittografare il contenuto dell'unità di archiviazione delle chiavi e avviare la macchina

virtuale, l'host Hyper-V deve essere:

Parte di un'infrastruttura protetta autorizzata per questa macchina virtuale, o

Dispone della chiave privata da uno dei tutori della macchina virtuale.
Per ulteriori informazioni sulle infrastrutture protetta, vedere la sezione Introduzione a
macchine virtuali schermati sicurezza e Assurance.

È possibile aggiungere un'unità di archiviazione delle chiavi in uno slot vuoto in uno dei
controller IDE della macchina virtuale. A tale scopo, fare clic su aggiungere unità di
archiviazione chiave per aggiungere un'unità di archiviazione chiavi per il primo slot di
controller IDE gratuito di questa macchina virtuale.

Riferimenti aggiuntivi
Impostazioni di sicurezza di macchine virtuali di seconda generazione nella console di
gestione di Hyper-V
Sicurezza e controllo
funzionalità di sicurezza delle macchine
virtuali di generazione 2 Hyper-V
02/07/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Hyper-V macchine virtuali di seconda generazione offrono funzionalità di sicurezza affidabili

progettate per proteggere i dati sensibili e impedire accessi non autorizzati o manomissioni.
Questo articolo illustra le impostazioni di sicurezza disponibili in Hyper-V Manager per le
macchine virtuali di seconda generazione e illustra come configurarle. Informazioni su come
queste funzionalità consentono di proteggere le macchine virtuali dalle minacce e garantire la
conformità alle procedure consigliate per la sicurezza.

Le funzionalità di sicurezza disponibili per le macchine virtuali di seconda generazione in

Hyper-V includono:

Secure Boot
Supporto della crittografia per Trusted Platform Module (TPM), migrazione in tempo reale
e stato salvato.
Macchine virtuali schermate.
Servizio di Protezione Host (HGS)

Queste funzionalità di sicurezza sono progettate per proteggere i dati e lo stato di una
macchina virtuale. È possibile proteggere le macchine virtuali dall'ispezione, dal furto e dalla
manomissione da malware che potrebbero essere eseguiti nell'host e dagli amministratori del
data center. Il livello di sicurezza che si ottiene dipende dall'hardware host eseguito, dalla
generazione della macchina virtuale e dal fatto che si configuri il servizio Sorveglianza host
complementare (HGS), che autorizza gli host ad avviare le macchine virtuali schermate.

Il servizio Sorveglianza host è stato introdotto per la prima volta in Windows Server 2016.
Identifica gli host Hyper-V legittimi e consente di eseguire un set di macchine virtuali
schermate. È in genere possibile abilitare il servizio Sorveglianza host per un data center, ma è
anche possibile creare una macchina virtuale schermata per eseguirla in locale senza
configurare il servizio Sorveglianza host. In un secondo momento è possibile distribuire la
macchina virtuale schermata all'Host Guardian Service.

Per informazioni su come rendere le macchine virtuali più sicure con il Servizio di Guardian
dell'Host, vedere Infrastruttura Sorvegliata e VM Schermate e Rafforzare l'Infrastruttura:
Protezione dei Segreti del Tenant in Hyper-V (video Ignite).
Avvio protetto
L'avvio protetto è una funzionalità disponibile con macchine virtuali di seconda generazione
che consente di impedire l'esecuzione di firmware non autorizzato, sistemi operativi o driver
UEFI (Unified Extensible Firmware Interface) (noti anche come ROm di opzione) in esecuzione
in fase di avvio. Avvio protetto è abilitato per impostazione predefinita. È possibile usare l'avvio
protetto con macchine virtuali di seconda generazione che eseguono sistemi operativi di
distribuzione Windows o Linux.

Sono disponibili tre modelli diversi, a seconda del sistema operativo e della configurazione
della macchina virtuale. La tabella seguente elenca ognuno di questi modelli e fa riferimento ai
certificati necessari per verificare l'integrità del processo di avvio:

ﾉ Espandi la tabella

Nome modello Compatibilità

Microsoft Windows Sistemi operativi Windows.

Autorità di certificazione Microsoft UEFI Sistemi operativi di distribuzione Linux.

VM protetta open source Macchine virtuali schermate basate su Linux.

Supporto crittografia
Hyper-V macchine virtuali di seconda generazione offrono funzionalità di crittografia affidabili
che offrono più livelli di protezione per l'infrastruttura virtualizzata. Il supporto della crittografia
comprende tre aree critiche: la funzionalità TPM (Trusted Platform Module), il traffico di rete
della migrazione in tempo reale e i dati sullo stato salvati. Queste funzionalità di sicurezza
interagiscono per creare una difesa completa contro accessi non autorizzati e violazioni dei
dati, assicurando che le informazioni riservate rimangano protette sia inattive che in transito.

La funzionalità TPM (vTPM) virtualizzata rappresenta un progresso significativo nell'architettura

di sicurezza delle macchine virtuali. Aggiungendo una vTPM alla macchina virtuale di seconda
generazione, è possibile abilitare il sistema operativo guest per usare funzioni di sicurezza
basate su hardware simili a quelle disponibili nei computer fisici. Questo chip di sicurezza
virtualizzato consente al sistema operativo guest di crittografare l'intero disco della macchina
virtuale usando crittografia unità BitLocker, creando un ulteriore livello di protezione da accessi
non autorizzati. VTPM può supportare anche altre tecnologie di sicurezza che richiedono un
TPM, rendendolo un componente essenziale per gli ambienti aziendali che richiedono una
rigorosa conformità agli standard e alle normative di sicurezza.
È possibile eseguire la migrazione di una macchina virtuale con TPM virtuale abilitato a
qualsiasi host che esegue una versione supportata di Windows Server o Windows. Se si esegue
la migrazione a un altro host, potrebbe non essere possibile avviarlo. È necessario aggiornare
la protezione con chiave per la macchina virtuale per autorizzare il nuovo host per eseguire la
macchina virtuale. Per ulteriori informazioni, vedere infrastruttura protetta e macchine virtuali
schermati e Requisiti di sistema per Hyper-V in Windows Server 2016.

Criteri di sicurezza nella gestione di Hyper-V

Le macchine virtuali schermate rappresentano il livello più elevato di sicurezza disponibile per
le macchine virtuali di Hyper-V generazione 2, offrendo una protezione completa contro
minacce esterne e attacchi di accesso con privilegi. Quando si abilita la schermatura in una
macchina virtuale, si crea un ambiente con protezione avanzata che crittografa lo stato e il
traffico di migrazione della macchina virtuale, limitando al tempo stesso l'accesso
amministrativo alle funzioni critiche della macchina virtuale. Questa protezione si estende oltre
le tradizionali misure di sicurezza impedendo anche agli amministratori del data center e al
malware a livello di host di accedere alla memoria della macchina virtuale, allo stato salvato o
al traffico di rete durante le operazioni di migrazione in tempo reale.

La funzionalità di schermatura applica automaticamente diversi requisiti di sicurezza, tra cui

l'avvio protetto, l'abilitazione TPM e la crittografia del traffico di stato e migrazione salvato.
Inoltre, le macchine virtuali schermate disabilitano determinate funzionalità di gestione, ad
esempio connessioni alla console, PowerShell Direct e componenti di integrazione specifici che
gli utenti malintenzionati potrebbero potenzialmente sfruttare. Questo approccio crea un
modello di sicurezza approfondito in cui la macchina virtuale diventa effettivamente opaca per
il sistema host, assicurando che i carichi di lavoro sensibili rimangano protetti anche in
ambienti di hosting compromessi. Le organizzazioni possono distribuire macchine virtuali
schermate con il servizio Sorveglianza host per le implementazioni su scala aziendale o
eseguirle localmente per una maggiore sicurezza nelle distribuzioni più piccole.

È possibile eseguire localmente la macchina virtuale schermata senza configurare il servizio

sorveglianza Host. Se si esegue la migrazione a un altro host, potrebbe non essere possibile
avviarlo. È necessario aggiornare la protezione con chiave per la macchina virtuale per
autorizzare il nuovo host per eseguire la macchina virtuale. Per ulteriori informazioni, vedere
Guarded Fabric e Shielded VMs.

Contenuti correlati
Per altre informazioni, vedere gli articoli seguenti:

Sicurezza e garanzia in Windows Server.

 È necessario creare una macchina virtuale di generazione 1 o 2 in Hyper-V?
Macchine virtuali Linux e FreeBSD in Hyper-V

） Nota: L'autore ha creato questo articolo con l’assistenza dell'intelligenza artificiale. Ulteriori informazioni
Pianificare la rete Hyper-V in Windows
Server
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Questo articolo illustra le funzionalità necessarie per la rete di base in Hyper-V, incluse le
considerazioni relative alla migrazione in tempo reale e ad altre funzionalità del server.

Rete di base di Hyper-V

Hyper-V rete usa un commutatore virtuale e una scheda di rete virtuale. Il commutatore
virtuale si connette a una rete basata su Ethernet e la scheda di rete virtuale si connette a una
porta sul commutatore virtuale, consentendo a una macchina virtuale di usare la rete. Quando
si crea una macchina virtuale e si connette la macchina virtuale a un commutatore virtuale,
viene aggiunta automaticamente una scheda di rete virtuale. Tutti i commutatori virtuali fanno
parte dell'host Hyper-V, ma ogni scheda di rete virtuale appartiene a una sola macchina
virtuale. Per istruzioni, vedere Creare un commutatore virtuale per le macchine virtuali Hyper-V.

Il commutatore virtuale è un commutatore di rete Ethernet di livello 2 basato su software. Il

commutatore virtuale offre funzionalità predefinite per il monitoraggio, il controllo e la
segmentazione del traffico, nonché la sicurezza e la diagnostica. È possibile aggiungere al set
di funzionalità predefinite installando plug-in, detti anche estensioni. Le estensioni sono
disponibili dai fornitori di software indipendenti. Per altre informazioni sul commutatore e sulle
estensioni, vedere Commutatore virtuale Hyper-V.

Scelte di commutatori e schede di rete

Hyper-V offre tre tipi di commutatori virtuali e due tipi di schede di rete virtuali. Si sceglie il
tipo quando si crea l'interruttore o l'adattatore. È possibile usare la console di gestione di
Hyper-V o il modulo Hyper-V per Windows PowerShell per creare e gestire commutatori
virtuali e schede di rete virtuali. Alcune funzionalità di rete avanzate, ad esempio elenchi di
controllo di accesso (ACL) estesi per le porte, possono essere gestite solo usando i cmdlet nel
modulo Hyper-V.

È possibile modificare un commutatore virtuale esistente in un tipo diverso dopo la creazione,

ma la modifica del tipo di commutatore virtuale influisce sulle funzionalità di rete di tutte le
macchine virtuali connesse. È possibile connettere una scheda di rete virtuale a un
commutatore virtuale diverso, ma non è possibile modificare una scheda di rete virtuale da un
tipo a un altro; Aggiungere invece un'altra scheda di rete virtuale e scegliere il tipo appropriato.
I tipi di commutatore virtuale sono:

Commutatore virtuale esterno: si connette a una rete fisica cablata tramite l'associazione
a una scheda di rete fisica.

Commutatore virtuale interno: si connette a una rete che può essere usata solo dalle
macchine virtuali in esecuzione nell'host con il commutatore virtuale e tra l'host e le
macchine virtuali.

Commutatore virtuale privato: si connette a una rete che può essere usata solo dalle
macchine virtuali in esecuzione nell'host con il commutatore virtuale, ma non fornisce una
rete tra l'host e le macchine virtuali.

Opzioni del commutatore virtuale:

ﾉ Espandi la tabella

Nome della Description

impostazione

Consenti condivisione Consente all'host Hyper-V di condividere l'utilizzo del commutatore virtuale e
della scheda di rete da delle scheda di interfaccia di rete o del groppo NIC con la macchina virtuale.
parte del sistema Con questa impostazione attivata, l'host può utilizzare le impostazioni
operativo di gestione configurate per il commutatore virtuale come le impostazioni di qualità del
servizio (QoS), le impostazioni di sicurezza o altre funzionalità del
commutatore virtuale Hyper-V.

Abilita single-root i/o Consente al traffico della macchina virtuale di ignorare il commutatore della
virtualization (SR-IOV) macchina virtuale e passare direttamente alla scheda di interfaccia di rete
fisica. SR-IOV è disponibile solo per le macchine virtuali che eseguono un
guest di Windows Server supportato. Per altre informazioni, vedere Single-
Root I/O Virtualization.

Tipi di scheda di rete virtuale:

ﾉ Espandi la tabella

Tipo di adattatore Vincoli di chiave e quando usare

Scheda di rete Disponibile per le macchine virtuali di prima e seconda generazione. Richiede un
(Hyper-V scheda di driver incluso nei servizi di integrazione Hyper-V, fornito solo per i sistemi operativi
rete specifica) guest supportati. Prestazioni più veloci; consigliato a meno che non sia necessario
l'avvio di rete o che esegua un sistema operativo guest non supportato.

Scheda di rete Solo macchine virtuali di prima generazione; non disponibile per le macchine
legacy virtuali di seconda generazione. Emula un adattatore PCI Fast Ethernet basato su
 Tipo di adattatore Vincoli di chiave e quando usare

Intel 21140. Usare quando è necessario avviare una rete per installare un sistema
operativo, ad esempio tramite Servizi di distribuzione Windows.

Rete Hyper-V e tecnologie correlate

Alcune funzionalità si basano su configurazioni di rete specifiche o offrono prestazioni migliori
in determinate configurazioni.

Clustering di failover: è consigliabile isolare il traffico del cluster e usare la Quality of Service
(QoS) di Hyper-V sullo switch virtuale.

Migrazione in tempo reale : usare le opzioni per le prestazioni per ridurre l'utilizzo della rete e
della CPU e il tempo necessario per completare una migrazione in tempo reale. Per istruzioni,
vedere Configura gli host per la migrazione in tempo reale senza Clustering di failover.

Spazi di archiviazione diretta - Spazi di archiviazione diretta si basa sul protocollo di rete
SMB3.0 e RDMA. Per informazioni dettagliate, vedere Panoramica di Spazi di Archiviazione
Diretta.

Last updated on 22/01/2026

Raccomandazioni di rete per Hyper-V in un
cluster di failover
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Quando si distribuisce una soluzione di Hyper-V a disponibilità elevata, è necessario prendere

in considerazione e pianificare diversi tipi di traffico di rete. Progettare la configurazione di rete
tenendo presenti gli obiettivi seguenti:

Garantire la qualità del servizio di rete

Fornire ridondanza di rete
Isolare il traffico verso reti definite
Se applicabile, sfruttare i vantaggi di SMB (Server Message Block) multicanale

In questo argomento vengono fornite indicazioni sulla configurazione di rete specifiche di un

cluster Hyper-V che esegue Windows Server. Include una panoramica dei diversi tipi di traffico
di rete, consigli su come isolare il traffico, consigli per funzionalità come gruppo NIC, qualità
del servizio (QoS) e coda di macchine virtuali (VMQ) e uno script di Windows PowerShell che
mostra un esempio di rete convergente, in cui il traffico di rete in un cluster Hyper-V instrada
attraverso un commutatore virtuale esterno.

Windows Server supporta il concetto di rete convergente, in cui diversi tipi di traffico di rete
condividono la stessa infrastruttura di rete Ethernet. Funzionalità come Hyper-V QoS e la
possibilità di aggiungere schede di rete virtuali al sistema operativo di gestione consentono di
consolidare il traffico di rete in meno schede fisiche. In combinazione con metodi di isolamento
del traffico come VLAN, è possibile isolare e controllare il traffico di rete.

７ Nota

Se si usa System Center Virtual Machine Manager (VMM) per creare o gestire cluster
Hyper-V, è necessario usare VMM per configurare le impostazioni di rete descritte in
questo argomento.

Panoramica dei diversi tipi di traffico di rete

Quando si distribuisce un cluster Hyper-V, è necessario pianificare diversi tipi di traffico di rete.
La tabella seguente riepiloga i diversi tipi di traffico.

ﾉ Espandi la tabella
 Tipo di traffico di Description
rete

Gestione Fornisce la connettività tra il server che esegue Hyper-V e la funzionalità di

infrastruttura di base. Usarlo per gestire il sistema operativo e le macchine virtuali di
gestione Hyper-V.

Cluster Utilizzarlo per la comunicazione tra i nodi del cluster, come il battito del cluster e il
reindirizzamento dei volumi condivisi del cluster (CSV).

Migrazione Live Usarlo per la migrazione in tempo reale delle macchine virtuali.

Storage Usarlo per il traffico SMB o per il traffico iSCSI.

Traffico di replica Usarlo per la replica di macchine virtuali tramite la funzionalità replica Hyper-V.

Accesso alle Usarlo per la connettività delle macchine virtuali. In genere richiede la connettività di
macchine virtuali rete esterna alle richieste client del servizio.

Le sezioni seguenti forniscono informazioni più dettagliate su ogni tipo di traffico di rete.

Traffico di gestione
Una rete di gestione fornisce connettività tra il sistema operativo dell'host fisico Hyper-V (noto
anche come sistema operativo di gestione) e le funzionalità di infrastruttura di base, ad esempio
Active Directory Domain Services (AD DS), Domain Name System (DNS) e Windows Server
Update Services (WSUS). Gestisce anche il server che esegue Hyper-V e le macchine virtuali.

La rete di gestione deve avere connettività tra tutte le infrastrutture necessarie e a qualsiasi
posizione da cui si vuole gestire il server.

Traffico del cluster

Un cluster di failover monitora e comunica lo stato del cluster tra tutti i membri del cluster.
Questa comunicazione è molto importante per mantenere l'integrità del cluster. Se un nodo
del cluster non comunica una verifica regolare di integrità (nota come heartbeat del cluster), il
cluster considera il nodo non operativo e rimuove il nodo dall'appartenenza al cluster. Il cluster
trasferisce quindi il carico di lavoro a un altro nodo del cluster.

La comunicazione tra nodi del cluster include anche il traffico associato a CSV. Per CSV, in cui
tutti i nodi di un cluster possono accedere contemporaneamente all'archiviazione condivisa a
livello di blocco, i nodi nel cluster devono comunicare per orchestrare le attività correlate
all'archiviazione. Inoltre, se un nodo del cluster perde la connessione diretta all'archiviazione
CSV sottostante, csv ha funzionalità di resilienza che reindirizzano l'I/O di archiviazione in rete a
un altro nodo del cluster che può accedere all'archiviazione.
Traffico di migrazione in tempo reale
La migrazione in tempo reale consente lo spostamento trasparente delle macchine virtuali in
esecuzione da un host Hyper-V a un altro senza una connessione di rete eliminata o tempi di
inattività percepiti.

Usare una rete dedicata o una VLAN per il traffico di migrazione in tempo reale per garantire la
qualità del servizio e per l'isolamento e la sicurezza del traffico. Il traffico di migrazione in
tempo reale può saturare i collegamenti di rete. Questa saturazione può causare un aumento
della latenza per gli altri traffici. Il tempo necessario per eseguire la migrazione completa di
una o più macchine virtuali dipende dalla velocità effettiva della rete di migrazione in tempo
reale. Pertanto, è necessario assicurarsi di configurare la qualità del servizio appropriata per
questo traffico. Per garantire prestazioni ottimali, il traffico di migrazione in tempo reale non
viene crittografato.

È possibile designare più reti come reti di migrazione in tempo reale in un elenco con priorità.
Ad esempio, potrebbe essere presente una rete di migrazione per i nodi del cluster nello stesso
cluster veloce (10 GB) e una seconda rete di migrazione per le migrazioni tra cluster più lente
(1 GB).

Tutti gli host Hyper-V che possono avviare o ricevere una migrazione in tempo reale devono
avere connettività a una rete configurata per consentire le migrazioni in tempo reale. Poiché la
migrazione in tempo reale può verificarsi tra nodi nello stesso cluster, tra nodi in cluster diversi
e tra un cluster e un host Hyper-V autonomo, assicurarsi che tutti questi server possano
accedere a una rete abilitata per la migrazione in tempo reale.

Traffico di archiviazione
Affinché una macchina virtuale sia a disponibilità elevata, tutti i membri del cluster Hyper-V
devono accedere allo stato della macchina virtuale. Questo stato include lo stato di
configurazione e i dischi rigidi virtuali. Per soddisfare questo requisito, è necessario disporre di
una risorsa di archiviazione condivisa.

In Windows Server è possibile fornire l'archiviazione condivisa in due modi:

Archiviazione a blocchi condivisi. Le opzioni di archiviazione a blocchi condivisi

includono Fibre Channel, Fibre Channel over Ethernet (FCoE), iSCSI e Serial Attached SCSI
(SAS) condiviso.
Archiviazione basata su file. L'archiviazione remota basata su file viene fornita tramite
SMB 3.0.

SMB 3.0 include nuove funzionalità note come SMB multicanale. SMB multicanale rileva e usa
automaticamente più interfacce di rete per offrire prestazioni elevate e connettività di
archiviazione altamente affidabile.

Per impostazione predefinita, SMB multicanale è abilitato e non richiede alcuna configurazione
aggiuntiva. Usare almeno due schede di rete dello stesso tipo e velocità in modo che SMB
Multicanale sia attivo. Le schede di rete che supportano RDMA (Accesso diretto alla memoria
remota) sono consigliate ma non necessarie.

SMB 3.0 individua automaticamente e sfrutta anche gli offload hardware disponibili, ad
esempio RDMA. Una funzionalità nota come SMB Direct supporta l'uso di schede di rete dotate
di funzionalità RDMA. SMB diretto offre le migliori prestazioni possibili, riducendo al contempo
il sovraccarico del file server e del client.

７ Nota

La funzionalità Gruppo NIC non è compatibile con le schede di rete con supporto per
RDMA. Pertanto, se si intende usare le funzionalità RDMA della scheda di rete, non
raggruppare tali schede.

Sia iSCSI che SMB usano la rete per connettere l'archiviazione ai membri del cluster. Poiché la
connettività e le prestazioni di archiviazione affidabili sono molto importanti per Hyper-V
macchine virtuali, usare più reti (fisiche o logiche) per garantire che questi requisiti siano
soddisfatti.

Per altre informazioni su SMB diretto e SMB multicanale, vedere Migliorare le prestazioni di un
file server con SMB diretto.

Traffico di replica
Hyper-V Replica fornisce la replica asincrona di macchine virtuali Hyper-V tra due server di
hosting o cluster Hyper-V. Il traffico di replica avviene tra il sito primario e quello di replica.

Hyper-V Replica individua e usa automaticamente le interfacce di rete disponibili per

trasmettere il traffico di replica. Per limitare e controllare la larghezza di banda del traffico di
replica, definire i criteri QoS con peso minimo della larghezza di banda.

Se si usa l'autenticazione basata su certificati, Hyper-V Replica crittografa il traffico. Se si usa

l'autenticazione basata su Kerberos, il traffico non viene crittografato.

Traffico di accesso alle macchine virtuali

La maggior parte delle macchine virtuali richiede una forma di rete o connettività Internet. Ad
esempio, i carichi di lavoro eseguiti nelle macchine virtuali richiedono in genere la connettività
di rete esterna alle richieste client di servizio. Questa connettività può includere l'accesso al
tenant in un'implementazione cloud ospitata. Poiché esistono più sottoclassi di traffico, ad
esempio il traffico interno al data center e il traffico esterno (ad esempio, a un computer
esterno al data center o a Internet), queste macchine virtuali necessitano di una o più reti per
comunicare.

Per separare il traffico delle macchine virtuali dal sistema operativo di gestione, usare VLAN
che non sono esposte al sistema operativo di gestione.

Come isolare il traffico di rete in un cluster Hyper-V

Per garantire prestazioni e funzionalità più coerenti e per migliorare la sicurezza di rete, isolare
i diversi tipi di traffico di rete.

７ Nota

Se si vuole avere una rete fisica o logica dedicata a un tipo di traffico specifico, è
necessario assegnare ogni scheda di rete fisica o virtuale a una subnet univoca. Per ogni
nodo del cluster, Failover Clustering riconosce un solo indirizzo IP per subnet.

Isolare il traffico nella rete di gestione

Usare una crittografia firewall o IPsec o entrambi per isolare il traffico di gestione. Inoltre, usare
il controllo per garantire che solo le comunicazioni definite e consentite vengano trasmesse
tramite la rete di gestione.

Isolare il traffico nella rete del cluster

Per isolare il traffico del cluster tra nodi, configurare una rete per consentire o meno la
comunicazione di rete del cluster. Per una rete che consente la comunicazione di rete del
cluster, è anche possibile configurare se consentire ai client di connettersi tramite la rete.
Questa configurazione include l'accesso al sistema operativo client e di gestione.

Un cluster di failover può usare qualsiasi rete che consenta la comunicazione di rete del cluster
per il monitoraggio del cluster, la comunicazione di stato e per le comunicazioni correlate a
CSV.

Per configurare una rete per consentire o vietare la comunicazione di rete del cluster, usare
Gestione Cluster di Failover o Windows PowerShell. Per utilizzare il Gestore del cluster di
failover, selezionare Reti nella struttura di navigazione. Nel riquadro Reti fare clic con il
pulsante destro del mouse su una rete e quindi scegliere Proprietà.
L'esempio di Windows PowerShell seguente configura una rete denominata Rete di gestione
per consentire la connettività del cluster e del client.

PowerShell
(Get-ClusterNetwork -Name "Management Network").Role = 3

La proprietà Role ha i valori possibili seguenti.

ﾉ Espandi la tabella

Value Impostazione di rete

0 Non consentire la comunicazione di rete del cluster

1 Consenti solo la comunicazione di rete del cluster

3 Consentire la comunicazione di rete del cluster e la connettività dei client

La tabella seguente illustra le impostazioni consigliate per ogni tipo di traffico di rete. Il traffico
di accesso alle macchine virtuali non è elencato perché è necessario isolare queste reti dal
sistema operativo di gestione usando VLAN che non sono esposte all'host. Di conseguenza, le
reti di macchine virtuali non devono essere visualizzate in Gestione cluster di failover come reti
cluster.

ﾉ Espandi la tabella

Tipo di rete Impostazione consigliata

Gestione Entrambe le opzioni seguenti: - Consentire la comunicazione di rete del cluster in questa
rete- Consentire ai client di connettersi tramite questa rete

Cluster Consenti la comunicazione di rete del cluster in questa rete Nota: deselezionare la
casella di controllo Consenti ai client di connettersi tramite questa rete .

Migrazione Consenti la comunicazione di rete del cluster in questa rete Nota: deselezionare la
Live casella di controllo Consenti ai client di connettersi tramite questa rete .

Storage Non consentire la comunicazione di rete del cluster in questa rete

Traffico di Entrambe le opzioni seguenti: - Consentire la comunicazione di rete del cluster in questa
replica rete- Consentire ai client di connettersi tramite questa rete

Isolare il traffico nella rete di migrazione in tempo reale

Per impostazione predefinita, il traffico di migrazione in tempo reale usa la topologia di rete
del cluster per individuare le reti disponibili e stabilire la priorità. Tuttavia, è possibile
configurare manualmente le preferenze di migrazione in tempo reale per isolare il traffico di
migrazione in tempo reale solo alle reti definite. A tale scopo, è possibile usare Gestione cluster
di failover o Windows PowerShell. Per usare Gestione cluster di failover, nell'albero di
navigazione fare clic con il pulsante destro del mouse su Reti e quindi scegliere Impostazioni
migrazione in tempo reale.

Una schermata della finestra di dialogo delle Impostazioni di Live Migration nel Failover Cluster
Manager che elenca le reti del cluster disponibili e il loro ordine di priorità.

L'esempio di Windows PowerShell seguente abilita il traffico di migrazione in tempo reale solo
in una rete denominata Migration_Network.

PowerShell
Get-ClusterResourceType -Name "Virtual Machine" | Set-ClusterParameter -Name
MigrationExcludeNetworks -Value ([String]::Join(";",(Get-ClusterNetwork | Where-
Object {$_.Name -ne "Migration_Network"}).ID))

Isolare il traffico nella rete di archiviazione

Per isolare il traffico di archiviazione SMB, usare Windows PowerShell per impostare vincoli
SMB multicanale. I vincoli SMB multicanale limitano la comunicazione SMB tra un determinato
file server e l'host Hyper-V a una o più interfacce di rete definite.

Ad esempio, il comando di Windows PowerShell seguente imposta un vincolo per il traffico

SMB dal file server FileServer1 alle interfacce di rete SMB1, SMB2, SMB3 e SMB4 nell'host Hyper-
V da cui si esegue questo comando.

PowerShell
New-SmbMultichannelConstraint -ServerName "FileServer1" -InterfaceAlias "SMB1",
"SMB2", "SMB3", "SMB4"

７ Nota

È necessario eseguire questo comando in ogni nodo del cluster Hyper-V.

Per trovare il nome dell'interfaccia, usare il cmdlet Get-NetAdapter .

Per altre informazioni, vedere New-SmbMultichannelConstraint.

Per isolare il traffico iSCSI, configurare la destinazione iSCSI con interfacce in una rete dedicata
(logica o fisica). Usare le interfacce corrispondenti nei nodi del cluster quando si configura
l'iniziatore iSCSI.

Isolare il traffico per la replica

Per isolare il traffico di Hyper-V Replica, usare una subnet diversa per il sito primario e il sito di
replica.

Se si vuole isolare il traffico di replica a una scheda di rete specifica, definire una route statica
persistente che reindirizza il traffico di rete alla scheda di rete definita. Per specificare una route
statica, usare il comando seguente:

route add <destination> mask <subnet mask and gateway> if <interface> -p

Ad esempio, per aggiungere una route statica alla rete [Link] (rete di esempio del sito di
replica) che usa una subnet mask [Link], un gateway [Link] (indirizzo IP di esempio
del sito primario), dove il numero di interfaccia per la scheda da dedicare al traffico di replica è
8, eseguire il comando seguente:

route add [Link] mask [Link] [Link] if 8 -p

NIC Teaming (LBFO) Linee guida
Unisci le schede di rete fisiche nel sistema operativo di gestione. Questa configurazione
fornisce l'aggregazione della larghezza di banda e il failover del traffico di rete se si verifica un
errore o un'interruzione dell'hardware di rete.

La funzionalità Gruppo NIC, nota anche come bilanciamento del carico e failover (LBFO),
fornisce due set di algoritmi di base per il raggruppamento.

Modalità dipendenti dal commutatore. Richiede il passaggio per partecipare al processo

di raggruppamento. In genere, tutte le schede di rete del team devono essere connesse
allo stesso commutatore.
Modalità indipendenti dal commutatore. Non richiede il passaggio per partecipare al
processo di raggruppamento. Anche se non richiesto, le schede di rete del team possono
essere connesse a commutatori diversi.

Entrambe le modalità forniscono l'aggregazione della banda e il meccanismo di failover del

traffico se si verifica un errore della scheda di rete o una disconnessione di rete. Nella maggior
parte dei casi, solo l'aggregazione indipendente dal commutatore fornisce il failover del traffico
in caso di guasto del commutatore.

Il gruppo NIC fornisce anche un algoritmo di distribuzione del traffico ottimizzato per i carichi
di lavoro Hyper-V. Questo algoritmo è indicato come la modalità di bilanciamento del carico
della porta Hyper-V. Questa modalità distribuisce il traffico in base all'indirizzo MAC delle
schede di rete virtuale. L'algoritmo usa round robin come meccanismo di bilanciamento del
carico. Ad esempio, in un server con due schede di rete fisiche con gruppo e quattro schede di
rete virtuale, la prima e la terza scheda di rete virtuale usano la prima scheda fisica e la seconda
e la quarta scheda di rete virtuale usano la seconda scheda fisica. La modalità porta di Hyper-V
consente inoltre l'uso di offload hardware come la coda di macchine virtuali (VMQ), che riduce
il carico della CPU per le operazioni di rete.

Raccomandazioni per il raggruppamento NIC

Per una distribuzione di Hyper-V in cluster, usare le impostazioni seguenti quando si
configurano le proprietà aggiuntive di un team.

ﾉ Espandi la tabella

Nome della proprietà Impostazione consigliata

Modalità di raggruppamento Switch Independent (impostazione predefinita)

Modalità di bilanciamento del carico porta Hyper-V

 ７ Nota

Il raggruppamento NIC disabilita la funzionalità RDMA delle schede di rete. Per usare SMB
diretto e la funzionalità RDMA delle schede di rete, non usare gruppo NIC.

Per altre informazioni sulle modalità gruppo NIC e su come configurare le impostazioni del
gruppo NIC, vedere Hyper-V commutatore virtuale.

Consigli sulla qualità del servizio (QoS)

Usare le tecnologie QoS disponibili in Windows Server per soddisfare i requisiti di servizio di un
carico di lavoro o di un'applicazione. QoS offre le funzionalità seguenti:

Misura la larghezza di banda di rete, rileva la modifica delle condizioni di rete (ad
esempio congestione o disponibilità della larghezza di banda) e assegna la priorità o
limita il traffico di rete.
Consente di convergere più tipi di traffico di rete su una singola scheda.
Include una funzionalità di larghezza di banda minima che garantisce una determinata
quantità di larghezza di banda a un determinato tipo di traffico.

Configurare Hyper-V QoS appropriato nel commutatore virtuale per assicurarsi che i requisiti di
rete siano soddisfatti per tutti i tipi appropriati di traffico di rete nel cluster Hyper-V.

７ Nota

È possibile usare QoS per controllare il traffico in uscita, ma non il traffico in ingresso. Ad
esempio, con Hyper-V Replica, è possibile usare QoS per controllare il traffico in uscita (dal
server primario), ma non il traffico in ingresso (dal server di replica).

Raccomandazioni QoS
Per un cluster Hyper-V, configurare Hyper-V QoS applicabile al commutatore virtuale. Quando
si configura QoS, completare la procedura seguente:

Configurare la larghezza di banda minima in modalità peso anziché in bit al secondo.

La larghezza di banda minima specificata per peso è più flessibile ed è compatibile con
altre funzionalità, ad esempio la migrazione in tempo reale e il gruppo NIC. Per altre
informazioni, vedere il parametro MinimumBandwidthMode in New-VMSwitch.
Abilitare e configurare QoS per tutte le schede di rete virtuali. Assegnare un peso a tutti
gli adattatori virtuali. Per altre informazioni, vedere Set-VMNetworkAdapter. Per
 assicurarsi che tutti gli adattatori virtuali abbiano un peso, configurare il parametro
DefaultFlowMinimumBandwidthWeight sul commutatore virtuale su un valore
ragionevole. Per altre informazioni, vedere Set-VMSwitch.

La tabella seguente consiglia alcuni valori di peso generici. È possibile assegnare un valore
compreso tra 1 e 100. Per indicazioni da considerare quando si assegnano valori di peso,
vedere Procedure consigliate per la larghezza di banda minima QoS.

ﾉ Espandi la tabella

Classificazione di rete Weight

Peso predefinito 0

Accesso alle macchine virtuali 1, 3 o 5 (macchine virtuali con velocità effettiva bassa, media e elevata)

Cluster 10

Gestione 10

Traffico di replica 10

Migrazione Live 40

Storage 40

Raccomandazioni per la coda di macchine virtuali

(VMQ)
La coda di macchine virtuali (VMQ) è una funzionalità disponibile per i computer con hardware
di rete che supporta VMQ. VMQ usa il filtro dei pacchetti hardware per distribuire i dati dei
pacchetti da una rete virtuale esterna direttamente alle schede di rete virtuali. Questa
funzionalità riduce il sovraccarico dei pacchetti di routing. Quando si abilita VMQ, viene
stabilita una coda dedicata nella scheda di rete fisica per ogni scheda di rete virtuale che
richiede una coda.

Non tutte le schede di rete fisiche supportano VMQ. Quelli che supportano VMQ hanno un
numero fisso di code disponibili e il numero di code può variare. Per determinare se una
scheda di rete supporta VMQ e il numero di code supportate, usare il cmdlet Get-
NetAdapterVmq .

È possibile assegnare code di macchine virtuali a qualsiasi scheda di rete virtuale. Questa
funzionalità include schede di rete virtuali che vengono esposte al sistema operativo di
gestione. Assegnare le code in base a un valore di peso, in base all’ordine di arrivo. Per
impostazione predefinita, tutti gli adattatori virtuali hanno un peso pari a 100.

Raccomandazioni per VMQ

Aumentare il peso VMQ per le interfacce con traffico in ingresso elevato, ad esempio le reti di
archiviazione e migrazione in tempo reale. A tale scopo, usare il cmdlet Set-
VMNetworkAdapter di Windows PowerShell.

Esempio di rete convergente: routing del traffico

attraverso un commutatore virtuale Hyper-V
Lo script di Windows PowerShell seguente illustra un esempio di come instradare il traffico in
un cluster Hyper-V tramite un commutatore virtuale esterno Hyper-V. Nell'esempio vengono
usate due schede di rete fisiche da 10 GB di cui viene eseguito il raggruppamento usando la
funzionalità Gruppo NIC. Lo script configura un nodo del cluster Hyper-V con un'interfaccia di
gestione, un'interfaccia di migrazione in tempo reale, un'interfaccia cluster e quattro interfacce
SMB. Dopo lo script, sono disponibili altre informazioni su come aggiungere un'interfaccia per
il traffico di replica Hyper-V. Il diagramma seguente illustra la configurazione di rete di
esempio.
L'esempio configura anche l'isolamento di rete che limita il traffico del cluster dall'interfaccia di
gestione, limita il traffico SMB alle interfacce SMB e limita il traffico di migrazione in tempo
reale all'interfaccia di migrazione in tempo reale.

PowerShell
# Create a network team using switch independent teaming and Hyper-V port mode
New-NetLbfoTeam "PhysicalTeam" –TeamMembers "10GBPort1", "10GBPort2" –TeamNicName
"PhysicalTeam" -TeamingMode SwitchIndependent -LoadBalancingAlgorithm HyperVPort

# Create a Hyper-V virtual switch connected to the network team

# Enable QoS in Weight mode
New-VMSwitch "TeamSwitch" –NetAdapterName "PhysicalTeam" –MinimumBandwidthMode
Weight –AllowManagementOS $false

# Configure the default bandwidth weight for the switch

# Ensures all virtual NICs have a weight
Set-VMSwitch -Name "TeamSwitch" -DefaultFlowMinimumBandwidthWeight 0

# Create virtual network adapters on the management operating system

# Connect the adapters to the virtual switch
# Set the VLAN associated with the adapter
# Configure the VMQ weight and minimum bandwidth weight
Add-VMNetworkAdapter –ManagementOS –Name "Management" –SwitchName "TeamSwitch"
Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "Management" -Access -
VlanId 10
Set-VMNetworkAdapter -ManagementOS -Name "Management" -VmqWeight 80 -
MinimumBandwidthWeight 10

Add-VMNetworkAdapter –ManagementOS –Name "Cluster" –SwitchName "TeamSwitch"

Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "Cluster" -Access -
VlanId 11
Set-VMNetworkAdapter -ManagementOS -Name "Cluster" -VmqWeight 80 -
MinimumBandwidthWeight 10

Add-VMNetworkAdapter –ManagementOS –Name "Migration" –SwitchName "TeamSwitch"

Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "Migration" -Access -
VlanId 12
Set-VMNetworkAdapter -ManagementOS -Name "Migration" -VmqWeight 90 -
MinimumBandwidthWeight 40

Add-VMNetworkAdapter –ManagementOS –Name "SMB1" –SwitchName "TeamSwitch"

Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "SMB1" -Access -VlanId
13
Set-VMNetworkAdapter -ManagementOS -Name "SMB1" -VmqWeight 100 -
MinimumBandwidthWeight 40

Add-VMNetworkAdapter –ManagementOS –Name "SMB2" –SwitchName "TeamSwitch"

Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "SMB2" -Access -VlanId
14
Set-VMNetworkAdapter -ManagementOS -Name "SMB2" -VmqWeight 100 -
MinimumBandwidthWeight 40

Add-VMNetworkAdapter –ManagementOS –Name "SMB3" –SwitchName "TeamSwitch"

Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "SMB3" -Access -VlanId
15
Set-VMNetworkAdapter -ManagementOS -Name "SMB3" -VmqWeight 100 -
MinimumBandwidthWeight 40

Add-VMNetworkAdapter –ManagementOS –Name "SMB4" –SwitchName "TeamSwitch"

Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "SMB4" -Access -VlanId
16
Set-VMNetworkAdapter -ManagementOS -Name "SMB4" -VmqWeight 100 -
MinimumBandwidthWeight 40

# Rename the cluster networks if desired

(Get-ClusterNetwork | Where-Object {$_.Address -eq "[Link]"}).Name =
"Management_Network"
(Get-ClusterNetwork | Where-Object {$_.Address -eq "[Link]"}).Name =
"Cluster_Network"
(Get-ClusterNetwork | Where-Object {$_.Address -eq "[Link]"}).Name =
"Migration_Network"
(Get-ClusterNetwork | Where-Object {$_.Address -eq "[Link]"}).Name =
"SMB_Network1"
(Get-ClusterNetwork | Where-Object {$_.Address -eq "[Link]"}).Name =
"SMB_Network2"
(Get-ClusterNetwork | Where-Object {$_.Address -eq "[Link]"}).Name =
"SMB_Network3"
 (Get-ClusterNetwork | Where-Object {$_.Address -eq "[Link]"}).Name =
"SMB_Network4"

# Configure the cluster network roles

(Get-ClusterNetwork -Name "Management_Network").Role = 3
(Get-ClusterNetwork -Name "Cluster_Network").Role = 1
(Get-ClusterNetwork -Name "Migration_Network").Role = 1
(Get-ClusterNetwork -Name "SMB_Network1").Role = 0
(Get-ClusterNetwork -Name "SMB_Network2").Role = 0
(Get-ClusterNetwork -Name "SMB_Network3").Role = 0
(Get-ClusterNetwork -Name "SMB_Network4").Role = 0

# Configure an SMB Multichannel constraint

# This ensures that SMB traffic from the named server only uses SMB interfaces
New-SmbMultichannelConstraint -ServerName "FileServer1" -InterfaceAlias "vEthernet
(SMB1)", "vEthernet (SMB2)", "vEthernet (SMB3)", "vEthernet (SMB4)"

# Configure the live migration network

Get-ClusterResourceType -Name "Virtual Machine" | Set-ClusterParameter -Name
MigrationExcludeNetworks -Value ([String]::Join(";",(Get-ClusterNetwork | Where-
Object {$_.Name -ne "Migration_Network"}).ID))

Considerazioni sulla replica Hyper-V

Se si usa anche Hyper-V Replica nell'ambiente, è possibile aggiungere un'altra scheda di rete
virtuale al sistema operativo di gestione per il traffico di replica. Per esempio:

PowerShell
Add-VMNetworkAdapter –ManagementOS –Name "Replica" –SwitchName "TeamSwitch"
Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "Replica" –Access –
VlanId 17
Set-VMNetworkAdapter -ManagementOS -Name "Replica" -VmqWeight 80 -
MinimumBandwidthWeight 10

# If the host is clustered – configure the cluster name and role

(Get-ClusterNetwork | Where-Object {$_.Address -eq "[Link]"}).Name = "Replica"
(Get-ClusterNetwork -Name "Replica").Role = 3

７ Nota

Se invece si usa QoS basato su criteri, in cui è possibile limitare il traffico in uscita
indipendentemente dall'interfaccia su cui viene inviato, è possibile usare uno dei metodi
seguenti per limitare il traffico di replica Hyper-V: Creare un criterio QoS basato sulla porta
di destinazione. Nell'esempio seguente il listener di rete nel server di replica o nel cluster è
configurato per l'uso della porta 8080 per ricevere il traffico di replica.
Appendice: Crittografia

Crittografia del traffico del cluster

Per impostazione predefinita, la comunicazione del cluster non è crittografata. Se si vuole, è
possibile abilitare la crittografia. Tuttavia, la crittografia comporta un sovraccarico delle
prestazioni. Per abilitare la crittografia, usare il comando di Windows PowerShell seguente per
impostare il livello di sicurezza per il cluster.

PowerShell
(Get-Cluster). SecurityLevel = 2

Nella tabella seguente vengono illustrati i diversi valori del livello di sicurezza.

ﾉ Espandi la tabella

Descrizione della sicurezza Value

Testo non crittografato 0

Firmato (impostazione predefinita) 1

Crittografato 2

Crittografia del traffico di migrazione in tempo reale

Il traffico di migrazione in tempo reale non è crittografato. È possibile abilitare IPsec o altre
tecnologie di crittografia a livello di rete, se necessario. Tuttavia, le tecnologie di crittografia
influiscono in genere sulle prestazioni.

Traffico SMB
Per impostazione predefinita, il traffico SMB non è crittografato. Pertanto, usare una rete
dedicata (fisica o logica) o usare la crittografia. Per il traffico SMB, è possibile usare la
crittografia SMB, la crittografia di livello 2 o di livello 3. La crittografia SMB è il metodo
preferito.

Crittografia del traffico di replica

Se si usa l'autenticazione basata su Kerberos, il traffico di replica Hyper-V non viene
crittografato. Crittografare il traffico di replica che transita le reti pubbliche tramite la rete WAN
o Internet. Usare la crittografia SSL (Secure Sockets Layer) come metodo di crittografia. È anche
possibile usare IPsec. Tuttavia, l'uso di IPsec potrebbe influire significativamente sulle
prestazioni.

Last updated on 28/10/2025

commutatore virtuale Hyper-V
14/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Questo argomento offre una panoramica del commutatore virtuale Hyper-V, che offre la
possibilità di connettere macchine virtuali (VM) a reti esterne all'host Hyper-V, inclusa la
Intranet dell'organizzazione e Internet.

È anche possibile connettersi alle reti virtuali nel server che esegue Hyper-V quando si
distribuisce SDN (Software Defined Networking).

７ Nota

Oltre a questo argomento, è disponibile la documentazione seguente sul commutatore

virtuale Hyper-V.

Accesso diretto a memoria remota (RDMA) e Switch Embedded Teaming (SET)

Cmdlet per il gruppo di commutatori di rete in Windows PowerShell
Novità di VMM 2016
Configurare l'infrastruttura di rete VMM
forum diHyper-V
Hyper-V: Abilitare l'estensione del commutatore virtuale Piattaforma filtro
Windows se richiesto da estensioni di terze parti

Per altre informazioni su altre tecnologie di rete, vedere Rete in Windows Server 2016.

Il commutatore virtuale Hyper-V è un commutatore di rete Ethernet di livello 2 basato sul

software, disponibile nella console di gestione di Hyper-V quando si installa il ruolo del server
Hyper-V.

Il commutatore virtuale Hyper-V include funzionalità gestite ed estendibili a livello di codice

per connettere le macchine virtuali alle reti virtuali e alla rete fisica. Il commutatore virtuale
Hyper-V supporta inoltre l'imposizione di criteri per sicurezza, l'isolamento e i livelli di servizio.

７ Nota

Il commutatore virtuale Hyper-V supporta solo Ethernet e non supporta altre tecnologie di
rete locale cablata (LAN), ad esempio Infiniband e Fibre Channel.
Il commutatore virtuale Hyper-V include funzionalità di isolamento del tenant, modellazione
del traffico, protezione da macchine virtuali dannose e risoluzione dei problemi semplificata.

Con il supporto incorporato per i driver di filtro NDIS (Network Device Interface Specification) e
i driver callout di Piattaforma filtro Windows, il commutatore virtuale Hyper-V permette ai
fornitori di software indipendenti (ISV) di creare plug-in estendibili, noti come estensioni del
commutatore virtuale, in grado di fornire funzionalità di rete e di sicurezza avanzate. Le
estensioni del commutatore virtuale aggiunte al commutatore virtuale Hyper-V sono elencate
nell'area Gestione commutatori virtuali della console di gestione di Hyper-V.

Nella figura seguente, una macchina virtuale include una scheda di interfaccia di rete virtuale
collegata al commutatore virtuale Hyper-V tramite una porta del commutatore.

Le funzionalità del commutatore virtuale Hyper-V offrono altre opzioni per applicare
l'isolamento del tenant, la modellazione e il controllo del traffico di rete e l'uso di misure di
protezione contro le macchine virtuali dannose.

７ Nota

In Windows Server 2016 una macchina virtuale con una scheda di interfaccia di rete
virtuale visualizza accuratamente la velocità effettiva massima per la scheda di interfaccia
di rete virtuale. Per visualizzare la velocità della scheda di interfaccia di rete virtuale in
Connessioni di rete, fare clic con il pulsante destro del mouse sull'icona della scheda di
interfaccia di rete virtuale desiderata e quindi scegliere Stato. Si apre la finestra di dialogo
Stato della scheda di interfaccia di rete virtuale. In Connessione il valore di Velocità
corrisponde alla velocità della scheda di interfaccia di rete fisica installata nel server.

Usi per il commutatore virtuale Hyper-V

Di seguito sono riportati alcuni scenari di caso d'uso per il commutatore virtuale Hyper-V.
Visualizzazione delle statistiche: uno sviluppatore di un fornitore di servizi cloud ospitato
implementa un pacchetto di gestione che visualizza lo stato corrente del commutatore virtuale
Hyper-V. Utilizzando WMI, il pacchetto di gestione è in grado di recuperare informazioni su
funzionalità correnti dell'intero commutatore, impostazioni di configurazione e statistiche di
rete per le singole porte. Mostra quindi lo stato del commutatore per fornire agli
amministratori una visualizzazione rapida dello stato del commutatore.

Rilevamento delle risorse: una società di hosting vende i servizi di hosting a prezzi in base al
livello di appartenenza. Ai vari livelli di abbonamento corrispondono livelli diversi di prestazioni
della rete. L'amministratore alloca le risorse in base agli SLA, in maniera tale da bilanciare la
disponibilità della rete. A livello di programmazione, l'amministratore registra informazioni
come l'uso corrente della larghezza di banda assegnata e il numero di macchina virtuale,
ovvero la coda di macchine virtuali o i canali IOV assegnati. Lo stesso programma
periodicamente registra anche le risorse in uso, oltre alle risorse assegnate per macchina
virtuale, per effettuare un controllo incrociato delle risorse.

Gestione dell'ordine delle estensioni del commutatore: un'azienda ha installato nel proprio
host Hyper-V estensioni che consentono di monitorare il traffico e segnalare le intrusioni
rilevate. Durante la manutenzione alcune estensioni potrebbero essere aggiornate,
determinando un cambiamento dell'ordine. Viene eseguito un semplice programma script per
riordinare le estensioni dopo gli aggiornamenti.

Estensione di inoltro per la gestione degli ID delle VLAN: un'importante società di switch sta
realizzando un'estensione di inoltro che applica tutti i criteri per le funzionalità di rete. Gli
elementi gestiti includono gli ID delle reti locali virtuali (VLAN, Virtual Local Area Network). Il
commutatore virtuale cede il controllo della VLAN a un'estensione di inoltro. L'installazione
della società di commutatori chiama a livello di programmazione un'API di Strumentazione
gestione Windows che attiva la trasparenza, indicando al commutatore virtuale Hyper-V di
passare i tag VLAN senza eseguire alcuna operazione.

Funzionalità del commutatore virtuale Hyper-V

Le principali funzionalità incluse in commutatore virtuale Hyper-V sono:

Protezione da poisoning (spoofing) ARP/ND: protegge il sistema da una macchina

virtuale dannosa che utilizza lo spoofing ARP per rubare indirizzi IP da altre macchine
virtuali. Protegge il sistema dai potenziali attacchi a IPv6 tramite spoofing ND.

Controllo DHCP: protegge il sistema da una macchina virtuale dannosa che si identifica
come server DHCP (Dynamic Host Configuration Protocol) per gli attacchi man-in-the-
middle.
 ACL di porta: fornisce il filtraggio del traffico basato su indirizzi o intervalli MAC (Media
Access Control) o IP (Internet Protocol), permettendo la configurazione dell'isolamento
della rete virtuale.

Modalità trunk per una macchina virtuale: consente agli amministratori di configurare
una macchina virtuale specifica come appliance virtuale e quindi indirizzare il traffico di
varie VLAN a tale macchina virtuale.

Monitoraggio del traffico di rete: consente agli amministratori di esaminare il traffico che
attraversa il commutatore di rete.

VLAN isolate (private) : consente agli amministratori di separare il traffico su più VLAN,
per creare più facilmente community tenant isolate.

Di seguito sono elencate le funzionalità che migliorano le possibilità di utilizzo del

commutatore virtuale Hyper-V:

Supporto di limiti per la larghezza di banda e burst: la larghezza di banda minima

garantisce la quantità di larghezza di banda riservata. La larghezza di banda massima
pone un limite alla quantità di larghezza di banda utilizzabile da una macchina virtuale.

Supporto dei contrassegni ECN (Explicit Congestion Notification): i contrassegni ECN, o

DCTCP (Data Center TCP), consentono al commutatore fisico e al sistema operativo di
regolare il flusso del traffico in modo da evitare il sovraccarico delle risorse di buffer del
commutatore, determinando un aumento della velocità effettiva del traffico.

Diagnostica: la diagnostica consente di eseguire facilmente la traccia e il monitoraggio di

eventi e pacchetti tramite il commutatore virtuale.
Requisiti di rete host per Azure Locale
Si applica a: Azure Local 2311.2 e versioni successive

Questo argomento illustra le considerazioni e i requisiti relativi alla rete host per Azure Locale. Per
informazioni sulle architetture dei data center e sulle connessioni fisiche tra computer, vedere
Requisiti di rete fisici.

Per informazioni su come semplificare la rete host tramite Network ATC, vedere Semplificare la rete
host con Network ATC.

Tipi di traffico di rete

Il traffico di rete locale di Azure può essere classificato in base allo scopo previsto:

Traffico di gestione: Traffico da o verso l'esterno del sistema locale. Ad esempio, il traffico usato
dall'amministratore per la gestione del sistema, ad esempio Desktop remoto, Windows Admin
Center, Active Directory e così via.
Traffico di calcolo: Traffico proveniente da o destinato a una macchina virtuale .Traffic from or
destined to a virtual machine (VM).
Traffico di archiviazione: Traffico tramite SMB (Server Message Block), ad esempio spazi di
archiviazione diretta o migrazione in tempo reale basata su SMB. Questo traffico è di livello 2 e
non è instradabile.

Selezionare una scheda di rete

Le schede di rete sono qualificate in base ai tipi di traffico di rete (vedere sopra) per cui sono
supportate. Quando si esamina il catalogo di Windows Server , la certificazione di Windows Server
2022 indica ora uno o più dei ruoli seguenti. Prima di acquistare un computer per l'ambiente locale di
Azure, è necessario avere almeno una scheda qualificata per la gestione, il calcolo e l'archiviazione,
perché tutti e tre i tipi di traffico sono necessari in Locale di Azure. È quindi possibile usare Network
ATC per configurare le schede di rete per i tipi di traffico appropriati.

Per ulteriori informazioni su questa qualifica della scheda di interfaccia di rete basata su ruoli, vedere
questo articolo sul blog di Windows Server .

） Importante

L'uso di un adattatore all'esterno del tipo di traffico qualificato non è supportato.

ﾉ Espandi la tabella
 Livello Ruolo di gestione Ruolo di calcolo Ruolo di archiviazione

Distinzione basata sui ruoli Gestione Standard di Calcolo Standard di Archiviazione

Premio massimo Non applicabile Calcolo Premium Archiviazione Premium

７ Nota

La qualifica più elevata per qualsiasi adattatore nell'ecosistema conterrà le qualifiche

Management, Compute Premium e Storage Premium .

Requisiti per gli autisti

I driver posta in arrivo non sono supportati per l'uso con Azure Local. Per identificare se l'adattatore
utilizza un driver predefinito, eseguire il cmdlet seguente. Un adattatore utilizza un driver predefinito
se la proprietà DriverProvider è Microsoft.

Powershell

Get-NetAdapter -Name <AdapterName> | Select *Driver*

Se viene usato il driver posta in arrivo, scaricare e installare il driver più recente dal sito Web del
partner OEM.

Panoramica delle funzionalità chiave delle schede di

rete
Le funzionalità importanti della scheda di rete usate da Azure Local includono:

Dynamic Virtual Machine Multi-Queue (Dynamic VMMQ o [Link])

RDMA (Remote Direct Memory Access)
Guest RDMA
Raggruppamento Integrato di Switch (SET)

VMMQ dinamico
Tutte le schede di rete con certificazione Computazione (Premium) supportano Dynamic VMMQ.
VMMQ dinamico richiede l'uso di Switch Embedded Teaming.

Tipi di traffico applicabili: calcolo

Certificazioni necessarie: Calcolo (Premium)

VMMQ dinamico è una tecnologia per la ricezione intelligente. Si basa sui predecessori di Virtual
Machine Queue (VMQ), Virtual Receive Side Scaling (vRSS) e VMMQ, per offrire tre miglioramenti
principali:

Ottimizza l'efficienza dell'host usando meno core CPU.

Ottimizzazione automatica dell'elaborazione del traffico di rete verso core CPU, consentendo
così alle macchine virtuali di soddisfare e mantenere la velocità effettiva prevista.
Consente ai carichi di lavoro impulsivi di ricevere il volume previsto di traffico.

Per altre informazioni su Dynamic VMMQ, vedere il post di blog Accelerazioni sintetiche .

RDMA
RDMA è un trasferimento del carico di elaborazione dello stack di rete alla scheda di rete. Consente al
traffico di archiviazione SMB di ignorare il sistema operativo per l'elaborazione.

RDMA consente una rete a bassa latenza e velocità effettiva elevata, usando risorse cpu host minime.
Queste risorse della CPU host possono quindi essere usate per eseguire macchine virtuali o
contenitori aggiuntivi.

Tipi di traffico applicabili: archiviazione host

Certificazioni necessarie: Archiviazione (Standard)

Tutti gli adattatori con qualificazione Archiviazione (Standard) o Archiviazione (Premium) supportano
RDMA lato host. Per ulteriori informazioni sull'uso di RDMA con carichi di lavoro guest, vedere la
sezione "Guest RDMA" nella parte successiva di questo articolo.

Azure Local supporta RDMA con le implementazioni dei protocolli Internet Wide Area RDMA Protocol
(iWARP) o RDMA over Converged Ethernet (RoCE).

） Importante

Le schede RDMA funzionano solo con altre schede RDMA che implementano lo stesso protocollo
RDMA (iWARP o RoCE).

Non tutte le schede di rete dei produttori supportano RDMA. Nella tabella seguente sono elencati i
fornitori (in ordine alfabetico) che offrono adattatori RDMA certificati. Tuttavia, ci sono fornitori di
hardware non inclusi in questo elenco che supportano anche RDMA. Vedi il Catalogo di Windows
Server per trovare adattatori con la qualifica di Archiviazione (Standard) o Archiviazione (Premium)
che richiedono il supporto RDMA.

７ Nota

InfiniBand (IB) non è supportato con Azure Local.

ﾉ Espandi la tabella

Fornitore di NIC iWARP Rendimento del Capitale Investito (RoCE)

Broadcom NO Sì

Intel Sì Sì (alcuni modelli)

Marvell (Qlogic) Sì Sì

Nvidia NO Sì

Per altre informazioni sulla distribuzione di RDMA per l'host, è consigliabile usare Network ATC. Per
informazioni sulla distribuzione manuale, vedere il repository GitHub SDN .

iWARP
iWARP usa il protocollo TCP (Transmission Control Protocol) e può essere facoltativamente migliorato
con il controllo del flusso basato su priorità (PFC) e il servizio di trasmissione avanzato (ETS).

Utilizzare iWARP se:

Non si ha esperienza nella gestione delle reti RDMA.

Non gestisci o ti senti a disagio nel gestire i commutatori Top-of-Rack (ToR).
Non gestirai la soluzione dopo la distribuzione.
Sono già disponibili distribuzioni che usano iWARP.
Non si è certi dell'opzione da scegliere.

Rendimento del Capitale Investito (RoCE)

RoCE usa il protocollo UDP (User Datagram Protocol) e richiede PFC e ETS per garantire l'affidabilità.

Utilizza RoCE se:

Hai già distribuzioni con RoCE nel tuo data center.

Hai familiarità con la gestione dei requisiti di rete DCB.

Guest RDMA
Il guest RDMA non è supportato su Azure Local.

Raggruppamento Integrato di Switch (SET)

SET è una tecnologia di teaming basata su software inclusa nel sistema operativo Windows Server a
partire da Windows Server 2016. SET è l'unica tecnologia di raggruppamento supportata da Azure
Local e funziona bene con il traffico di calcolo, archiviazione e gestione. SET supporta fino a otto
schede in un singolo team. Altri metodi di raggruppamento della scheda di interfaccia di rete, ad
esempio bilanciamento del carico/failover (LBFO) non sono supportati.

In Azure Local ATC configura automaticamente set e vSwitch. Non è consigliabile distribuire
manualmente SET usando PowerShell, ad esempio con il cmdlet New-VMSwitch . Anche se questo
comando abilita il teaming incorporato per impostazione predefinita quando sono elencate più
schede, l'approccio consigliato consiste nell'usare Network ATC con finalità.

Tipi di traffico applicabili: calcolo, archiviazione e gestione

Certificazioni necessarie: Calcolo (Standard) o calcolo (Premium)

SET è importante per l'ambiente locale di Azure perché è l'unica tecnologia di raggruppamento che
consente:

Raggruppamento di schede RDMA (se necessario).

RDMA guest.
VMMQ dinamico.
Altre funzionalità principali locali di Azure (vedere Raggruppamento in Locale di Azure ).

SET richiede l'uso di adattatori simmetrici (identici). Le schede di rete simmetriche sono quelle con gli
stessi attributi di:

Marca (fornitore)
Modello (versione)
Velocità (capacità di trasmissione)
configurazione

In 22H2, Network ATC rileverà automaticamente e ti informerà se le schede di rete che hai scelto sono
asimmetriche. Il modo più semplice per identificare manualmente se gli adattatori sono simmetrici è
se le descrizioni delle velocità e delle interfacce corrispondono esattamente . Possono deviare solo
nel numero elencato nella descrizione. Usare il Get-NetAdapterAdvancedProperty cmdlet per
assicurarsi che la configurazione segnalata elenchi gli stessi valori delle proprietà.

Vedere la tabella seguente per un esempio delle descrizioni dell'interfaccia che deviano solo in base al
numero (#):

ﾉ Espandi la tabella
 Nome Descrizione dell'interfaccia Velocità di collegamento

NIC 1 Scheda di rete numero 1 25 Gbps

Scheda di interfaccia di rete 2 Scheda di rete numero 2 25 Gbps

NIC3 (Scheda di interfaccia di rete 3) Scheda di rete numero 3 25 Gbps

NIC 4 (Scheda di interfaccia di rete 4) Scheda di rete numero 4 25 Gbps

７ Nota

SET supporta solo la configurazione indipendente dal commutatore usando algoritmi di

bilanciamento del carico delle porte dinamiche o Hyper-V. Per prestazioni ottimali, è consigliabile
usare la porta Hyper-V in tutte le schede di interfaccia di rete che operano a 10 o più Gbps.
Network ATC rende tutte le configurazioni necessarie per SET.

Considerazioni sul traffico RDMA

Se si implementa DCB, è necessario assicurarsi che la configurazione PFC e ETS sia implementata
correttamente in ogni porta di rete, inclusi i commutatori di rete. DCB è obbligatorio per RoCE e
facoltativo per iWARP.

Per informazioni dettagliate su come distribuire RDMA, scaricare il documento dal repository GitHub
SDN .

Le implementazioni locali di Azure basate su RoCE richiedono la configurazione di tre classi di traffico
PFC, inclusa la classe di traffico predefinita, nell'infrastruttura e in tutti gli host.

Classe di traffico di sistema

Questa classe di traffico garantisce una larghezza di banda sufficiente riservata agli heartbeat di
sistema:

Richiesto: sì
PFC attivato: No
Priorità consigliata per il traffico: Priorità 7
Prenotazione della larghezza di banda consigliata:
Reti RDMA da 10 GbE o capacità inferiore = 2%
25 GbE o reti RDMA superiori = 1%

Classe di traffico RDMA

Questa classe di traffico garantisce una larghezza di banda sufficiente riservata alle comunicazioni
RDMA senza perdita usando SMB diretto:
 Richiesto: sì
Abilitazione PFC: Sì
Priorità del traffico consigliata: priorità 3 o 4
Prenotazione della larghezza di banda consigliata: 50%

Classe di traffico predefinita

Questa classe di traffico trasporta tutto l'altro traffico non definito nelle classi di traffico di sistema o
RDMA, incluso il traffico della macchina virtuale e il traffico di gestione:

Obbligatorio: per impostazione predefinita (nessuna configurazione necessaria nell'host)

Controllo del flusso (PFC) abilitato: No
Classe di traffico consigliata: per impostazione predefinita (Priorità 0)
Prenotazione della larghezza di banda consigliata: per impostazione predefinita (nessuna
configurazione host richiesta)

Modelli di traffico di archiviazione

SMB offre molti vantaggi come il protocollo di archiviazione per Azure Locale, incluso SMB
multicanale. SMB Multicanale non è trattato in questo articolo, ma è importante comprendere che il
traffico viene multiplexato attraverso ogni possibile collegamento che SMB Multicanale può utilizzare.

７ Nota

È consigliabile usare più subnet e VLAN per separare il traffico di archiviazione in Locale di Azure.

Si consideri l'esempio seguente di un sistema a quattro nodi. Ogni computer ha due porte di
archiviazione (lato sinistro e destro). Poiché ogni scheda si trova nella stessa subnet e nella stessa
VLAN, SMB Multicanale distribuirà le connessioni tra tutti i collegamenti disponibili. Di conseguenza,
la porta sul lato sinistro del primo computer ([Link]) effettuerà una connessione alla porta a
sinistra sul secondo computer ([Link]). La porta sul lato destro del primo computer
([Link]) si connetterà alla porta sul lato destro del secondo computer. Vengono stabilite
connessioni simili per la terza e la quarta macchina.

In questo modo, tuttavia, vengono create connessioni non necessarie e si verifica una congestione
all'interlink (gruppo di aggregazioni di collegamenti a più chassis o MC-LAG) che connette i
commutatori ToR (contrassegnati con Xs). Vedere il diagramma seguente:
 

L'approccio consigliato consiste nell'usare delle subnet e VLAN separate per ogni set di adattatori. Nel
diagramma seguente le porte di destra usano ora la subnet 192.168.2.x /24 e VLAN2. Ciò consente al
traffico sulle porte sul lato sinistro di rimanere su TOR1 e il traffico sulle porte sul lato destro per
rimanere su TOR2.
 

Allocazione della larghezza di banda del traffico

La tabella seguente illustra allocazioni di larghezza di banda di esempio per vari tipi di traffico, usando
le velocità comuni degli adattatori, in Azure Local. Si noti che si tratta di un esempio di soluzione
convergente, in cui tutti i tipi di traffico (calcolo, archiviazione e gestione) vengono eseguiti sulle stesse
schede fisiche e vengono raggruppati usando SET.

Poiché questo caso d'uso rappresenta la maggior parte dei vincoli, rappresenta una linea di base
valida. Tuttavia, considerando le permutazioni per il numero di adattatori e velocità, questo deve
essere considerato un esempio e non un requisito di supporto.

Per questo esempio vengono effettuati i presupposti seguenti:

Sono disponibili due adattatori per ogni team.

Traffico SBL (Storage Bus Layer), Volumi condivisi cluster (CSV) e Hyper-V (Live Migration):
Usare gli stessi adattatori fisici.
Usare SMB.
 A SMB viene assegnata un'allocazione della larghezza di banda del 50% tramite DCB.
SBL/CSV è il traffico con priorità più alta e riceve il 70% della prenotazione della larghezza di
banda SMB.
Live Migration (LM) è limitato tramite il Set-SMBBandwidthLimit cmdlet e riceve il 29% della
larghezza di banda rimanente.

Se la larghezza di banda disponibile per Live Migration è >= 5 Gbps e le schede di rete
sono compatibili con RDMA. Usare il cmdlet seguente per eseguire questa operazione:

Powershell

Set-VMHost -VirtualMachineMigrationPerformanceOption SMB

Se la larghezza di banda disponibile per Live Migration è < di 5 Gbps, usare la

compressione per ridurre i tempi di black-out. Usare il cmdlet seguente per eseguire
questa operazione:

Powershell

Set-VMHost -VirtualMachineMigrationPerformanceOption Compression

Se si usa RDMA per il traffico live Migration, assicurarsi che il traffico di Live Migration non possa
utilizzare l'intera larghezza di banda allocata alla classe di traffico RDMA usando un limite di
larghezza di banda SMB. Prestare attenzione, perché questo cmdlet accetta dati in byte al
secondo (Bps), mentre le schede di rete sono elencate in bit al secondo (bps). Usare il cmdlet
seguente per impostare un limite di larghezza di banda di 6 Gbps, ad esempio:

Powershell

Set-SMBBandwidthLimit -Category LiveMigration -BytesPerSecond 750MB

７ Nota

750 MBps in questo esempio equivale a 6 Gbps.

Ecco la tabella di allocazione della larghezza di banda di esempio:

ﾉ Espandi la tabella

Velocità Larghezza Prenotazione % Larghezza % Larghezza Battito Larghezza

della di banda della SBL/CSV di banda migrazione di banda cardiaco di banda
scheda aggregata larghezza di SBL/CSV in tempo massima % impulso
di rete banda reale Migrazione
SMB** live

10 Gbps 20 Gbps 10 Gbps 70% 7 Gbps * 200 Mbps

 Velocità Larghezza Prenotazione % Larghezza % Larghezza Battito Larghezza
della di banda della SBL/CSV di banda migrazione di banda cardiaco di banda
scheda aggregata larghezza di SBL/CSV in tempo massima % impulso
di rete banda reale Migrazione
SMB** live

25 Gbps 50 Gbps 25 Gbps 70% 17,5 Gbps 29% 7,25 Gbps 1% 250 Mbps

40 Gbps 80 Gbps 40 Gbps 70% 28 Gbps 29% 11,6 Gbps 1% 400 Mbps

50 Gbps 100 Gbps 50 Gbps 70% 35 Gbps 29% 14,5 Gbps 1% 500 Mbps

100 200 Gbps 100 Gbps 70% 70 Gbps 29% 29 Gbps 1% 1 Gbps
Gbps

200 400 Gbps 200 Gbps 70% 140 Gbps 29% 58 Gbps 1% 2 Gbps
Gbps

* Usare la compressione anziché RDMA, perché l'allocazione della larghezza di banda per il traffico di
Live Migration è <di 5 Gbps.

** Il 50% è una prenotazione di larghezza di banda di esempio.

Clustering compatibile con rack

Il clustering compatibile con rack migliora la tolleranza di errore e la distribuzione dei dati in
un'istanza locale di Azure. Questa architettura consente di raggruppare nodi posizionati in modo
strategico su due rack fisici in stanze o edifici separati, connessi tramite larghezza di banda elevata e
rete a bassa latenza. Per una panoramica di questa funzionalità, vedere Panoramica del clustering
compatibile con rack locale di Azure.

Per i requisiti di rete e l'architettura, vedere Architettura di riferimento del cluster compatibile con rack
locale di Azure.

Passaggi successivi
Informazioni sul commutatore di rete e sui requisiti di rete fisici. Vedere Requisiti di rete fisici.
Informazioni su come semplificare la rete host usando Network ATC. Vedere Semplificare la rete
host con Network ATC.
Rinfresca i concetti di base sul clustering di failover e sulla rete.
Vedere Distribuire con il portale di Azure.
Vedere Distribuire usando il modello di Azure Resource Manager.

Last updated on 17/03/2026

Procedure consigliate per la larghezza di
banda minima QoS di rete per Hyper-V
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Usare queste procedure consigliate per configurare la larghezza di banda minima della rete
Hyper-V (QoS) in Windows Server. Le indicazioni consentono di scegliere la modalità
appropriata (peso o bit al secondo), assegnare pesi efficaci ed evitare problemi di
configurazione con il NIC Teaming e il Data Center Bridging (DCB).

L'articolo illustra: strategia di assegnazione del peso, quando preferire il peso rispetto alla
larghezza di banda assoluta, l'interazione con algoritmi di raggruppamento, considerazioni
sulla coesistenza per QoS e DCB e tecniche di mitigazione per la distribuzione della larghezza
di banda non uniforme.

Linee guida per l'uso della larghezza di banda

minima
Di seguito sono riportate le linee guida per la configurazione della larghezza di banda minima.

1. Mantenere la somma dei pesi vicino o inferiore a 100. Maggiore è il valore del peso,
maggiore è l'errore di arrotondamento o di quantizzazione che si verifica quando lo
schedulatore di pacchetti QoS partiziona la larghezza di banda tra i vari carichi di lavoro.
Ad esempio, se sono presenti 20 macchine virtuali che si desidera condividere la
larghezza di banda di rete, anziché assegnare un peso pari a 10 a ognuno di essi (somma
sarebbe 200), assegnare a ogni macchina virtuale un peso pari a 1.
2. Assegnare un peso relativamente elevato ai carichi di lavoro critici anche se non
richiedono tale percentuale di larghezza di banda. Ad esempio, il traffico di gestione e
heartbeat del cluster in un computer che esegue Hyper-V raramente richiede più di 1-2%
di larghezza di banda su una NIC da 10 GbE, ma sono fondamentali. Invece di assegnare
un peso pari a 1 o 2, assegnare a ciascuno un peso di 5 o più.
3. Colmare l'assegnazione del peso per differenziare i livelli di servizio. Non usare numeri
consecutivi (1,2,3). Ad esempio, se sono presenti macchine virtuali denominate Gold,
Silver e Bronze nello stesso commutatore virtuale Hyper-V, assegnare pesi 5 (Gold), 3
(Silver), 1 (Bronze) anziché 3,2,1.
4. Contabilizzare il traffico non filtrato/catch-all. Ad esempio, se Archiviazione, Live
Migration e Cluster vengono filtrati con filtri specifici per carichi di lavoro, raggruppare il
resto del traffico di rete tramite un filtro wildcard, come un singolo flusso dotato di
assegnazione di peso.
Modalità di larghezza di banda minima
Quando si crea un commutatore virtuale Hyper-V con PowerShell, scegliere una delle due
modalità di configurazione Larghezza di banda minima. Queste modalità determinano come
quantificare la larghezza di banda minima per un carico di lavoro:

Peso (intero 1-100)

Bit al secondo (BPS)

 Suggerimento

Configurare la larghezza di banda minima per peso anziché BPS. Il peso è più flessibile e
compatibile con funzionalità come Live Migration e NIC Teaming.

Scenario di esempio: una macchina virtuale configurata con una larghezza di banda minima di
500 Mbps potrebbe non riuscire nella Migrazione Live verso un host di destinazione che non
può garantire una larghezza di banda di riserva di 500 Mbps. Se si specifica Larghezza di banda
minima per peso (ad esempio, 3), la somma dei pesi aumenta semplicemente di 3 e la
migrazione ha esito positivo (presupponendo che non siano presenti altri vincoli).

Se è necessario specificare la larghezza di banda minima in un numero assoluto (BPS), usare

queste linee guida:

L'unità minima è 1% di capacità di collegamento. In una scheda di interfaccia di rete da 10

GbE la larghezza di banda minima allocabile per scheda di rete virtuale è di 100 Mbps.
I valori vengono arrotondati al punto percentuale più vicino. Ad esempio, 234 Mbps
arrotonda fino a 200 Mbps (2% di un collegamento da 10 GbE).

Usare il -MinimumBandwidthMode parametro di New-VMSwitch per specificare la modalità:

PowerShell
New-VMSwitch "QoS Switch by Weight" -NetAdapterName "External NIC" -
MinimumBandwidthMode Weight

PowerShell
New-VMSwitch "QoS Switch by BPS" -NetAdapterName "External NIC" -
MinimumBandwidthMode Absolute

Per altre informazioni, vedere l'argomento New-VMSwitch di riferimento di PowerShell.

Larghezza di banda minima e Data Center Bridging
(DCB)
La larghezza di banda minima QoS (applicata dall'Utilità di pianificazione pacchetti QoS in
Windows) e il Data Center Bridging (DCB, applicato da una scheda di interfaccia di rete in
grado di supportare) garantiscono che un carico di lavoro riceva la propria equa quota di
larghezza di banda in caso di congestione. Non sono progettati per lavorare insieme per lo
stesso stack di rete o scheda di interfaccia di rete.

） Importante

Non abilitare sia Larghezza di banda minima che DCB per carichi di lavoro che
condividono lo stesso stack di rete o scheda di interfaccia di rete.

È possibile abilitare sia Larghezza di banda minima che DCB in un server solo quando si
applicano a stack di rete separati o schede di interfaccia di rete separate.

Configurazione del gruppo QoS e NIC

Gruppo NIC fornisce:

Aggregazione della larghezza di banda (distribuzione tra membri del team)

Failover del traffico (mantiene la connettività durante un guasto del componente)

Algoritmi di distribuzione gruppo NIC:

Hyper-V porta del commutatore virtuale (hash basato sulla porta dello switch di una
macchina virtuale o della scheda NIC virtuale del sistema operativo di gestione)
Hash degli indirizzi (hash basato su campi MAC, IP e porta di trasporto)

Interazione QoS con gruppo NIC:

Classificazione e assegnazione di tag : funziona senza problemi; il traffico viene

contrassegnato prima dell'hashing.
Controllo del flusso (PFC) basato sulla priorità : funziona senza problemi; garantire
un'abilitazione coerente tra tutti i membri del team.
Gestione della larghezza di banda : dettagli nella sezione seguente.

Larghezza di banda massima

Funziona senza problemi: L'Utilità di pianificazione pacchetti QoS limita i flussi prima che il NIC
Teaming li assegni ai membri del team.

Larghezza minima di banda (modalità peso)

L'utilità di pianificazione pacchetti QoS partiziona la larghezza di banda tra i flussi in base ai
pesi assegnati prima dell'hashing. Un problema può verificarsi quando l'algoritmo di NIC
Teaming è configurato sulla porta dello switch Hyper-V: ogni macchina virtuale (singola scheda
di interfaccia di rete virtuale) diventa un singolo flusso. Il sistema di raggruppamento potrebbe
assegnare macchine virtuali di peso elevato a un membro e macchine virtuali di peso basso a
un altro, con conseguente quota effettiva uguale anziché proporzionale.

Questo problema è meno pronunciato quando:

Molte macchine virtuali condividono il commutatore virtuale

L'algoritmo NIC Teaming è Address hashing (flussi più granulari, ad esempio ogni
connessione TCP)

Mitigazione: eseguire lo script dell'ordine di avvio della macchina virtuale in modo che i gruppi
di macchine virtuali con lo stesso peso vengano riuniti. Il NIC Teaming distribuisce le schede di
interfaccia di rete virtuali con un algoritmo round-robin; il raggruppamento preserva una
distribuzione del carico più uniforme.

Larghezza di banda minima applicata dall'hardware

Lo stesso problema di distribuzione non uniforme può verificarsi con più schede di interfaccia
di rete che supportano DCB se l'hashing è asimmetrico.

Larghezza di banda minima assoluta (BPS) con aggregazione

NIC
Se un commutatore Hyper-V è associato a un gruppo di schede di interfaccia di rete di 1 GB
(aggregazione 2 Gb), non è possibile allocare in modo sicuro più di 1 Gb a una macchina
virtuale. In caso di errore di una singola scheda di interfaccia di rete, rimangono solo 1 Gb. La
modalità peso evita questa complessità, poiché la larghezza di banda rimanente viene
ripartizionata proporzionalmente.

 Suggerimento

Preferire la modalità peso per la maggior parte delle distribuzioni; gestisce con facilità
scenari di migrazione, raggruppamento e errore.
Riepilogo: Gruppo QoS e NIC
ﾉ Espandi la tabella

Funzionalità QoS Funzionalità con gruppo NIC

Larghezza di banda massima Funziona senza problemi

Larghezza di banda minima (peso) Potenziale applicazione irregolare se l'algoritmo porta-di-switch

distorce la distribuzione

Larghezza di banda minima applicata Potenziale imposizione irregolare se la distribuzione del traffico
dall'hardware è asimmetrica

Classificazione e assegnazione di tag Funziona senza problemi

Controllo del flusso basato su priorità Funziona senza problemi

Vedere anche
Hyper-V panoramica di QoS (versioni più recenti) (aggiungi collegamento quando
disponibile)
New-VMSwitch Informazioni di riferimento su PowerShell

Panoramica del gruppo NIC

Last updated on 28/10/2025

Pianificare la sicurezza di Hyper-V in
Windows Server
Articolo • 02/11/2024 •
Si ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
applica Windows Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Stack HCI, versions
a: 23H2 and 22H2

Proteggere il sistema operativo host Hyper-V, le macchine virtuali, i file di

configurazione e i dati delle macchine virtuali. Usare l'elenco seguente di procedure
consigliate come elenco di controllo per proteggere l'ambiente Hyper-V.

Proteggere l'host Hyper-V

Mantenere il sistema operativo host sicuro.
Ridurre al minimo la superficie di attacco usando l'opzione di installazione
minima di Windows Server necessaria per la gestione del sistema operativo. Per
ulteriori informazioni, vedere la sezione Opzioni di installazione della raccolta di
contenuti tecnici di Windows Server. Non è consigliabile eseguire carichi di
lavoro di produzione su Hyper-V in Windows 10.
Mantenere aggiornato il sistema operativo host Hyper-V, il firmware e i driver di
dispositivo con gli aggiornamenti della sicurezza più recenti. Controllare le
raccomandazioni del fornitore per aggiornare firmware e driver.
Non usare l'host Hyper-V come workstation o installare software non
necessario.
Gestire da remoto l'host Hyper-V. Se è necessario gestire l'host Hyper-V
localmente, usare Credential Guard. Per altre informazioni, vedere Proteggere le
credenziali di dominio derivate con Credential Guard.
Abilitare i criteri di integrità del codice. Usare i servizi di integrità del codice
protetti dalla sicurezza basata sulla virtualizzazione. Per ulteriori informazioni,
vedere la Guida alla distribuzione di Device Guard.

Usare una rete sicura.

Usare una rete separata con una scheda di rete dedicata per il computer Hyper-
V fisico.
Usare una rete privata o sicura per accedere alle configurazioni delle macchine
virtuali e ai file dell’hard disk virtuale.
Usare una rete privata/dedicata per il traffico di migrazione in tempo reale.
Valutare la possibilità di abilitare IPSec su questa rete per usare la crittografia e
 proteggere i dati della macchina virtuale che passano nella rete durante la
migrazione. Per ulteriori informazioni, vedere Configurare gli host per la
migrazione in tempo reale senza Clustering di failover.

Proteggere il traffico di migrazione dell'archiviazione.

Usare SMB 3.0 per la crittografia end-to-end dei dati SMB e la protezione dei dati
da manomissione o intercettazione su reti non affidabili. Usare una rete privata per
accedere al contenuto della condivisione SMB ed evitare attacchi man-in-the-
middle. Per ulteriori informazioni, vedere Miglioramenti della sicurezza SMB.

Configurare gli host come parte di un'infrastruttura sorvegliata.

Per ulteriori informazioni, vedere Infrastruttura sorvegliata.

Proteggere i dispositivi.

Proteggere i dispositivi di archiviazione in cui si conservano i file di risorse della

macchina virtuale.

Proteggere il disco rigido.

Usare Crittografia unità BitLocker per proteggere le risorse.

Rafforzare la protezione avanzata del sistema operativo host Hyper-V.

Applicare le raccomandazioni relative alle impostazioni di sicurezza di base

descritte nella baseline di sicurezza di Windows Server.

Concedere le autorizzazioni appropriate.

Aggiungere utenti che hanno bisogno di gestire l'host Hyper-V al gruppo di
amministratori di Hyper-V.
Non concedere agli amministratori delle macchine virtuali le autorizzazioni per il
sistema operativo host Hyper-V.

Configurare le esclusioni e le opzioni antivirus per Hyper-V.

Windows Defender dispone già di esclusioni automatiche configurate. Per ulteriori

informazioni sulle esclusioni, vedere Esclusioni antivirus consigliate per gli host
Hyper-V .

Non installare hard disk virtuali sconosciuti. Ciò può esporre l'host ad attacchi a
livello di file system.

Non abilitare l'annidamento nel proprio ambiente di produzione, a meno che

non sia necessario.
 Se si abilita l'annidamento, non eseguire hypervisor non supportati su una
macchina virtuale.

Per ambienti più sicuri:

Usare l'hardware con un chip TPM (Trusted Platform Module) 2.0 per
configurare un'infrastruttura sorvegliata.

Per ulteriori informazioni, vedere Requisiti di sistema per Hyper-V in Windows

Server 2016.

Proteggere le macchine virtuali

Creare macchine virtuali di seconda generazione per i sistemi operativi guest
supportati.

Per ulteriori informazioni, vedere Impostazioni di sicurezza di seconda generazione.

Abilitare l'avvio protetto.

Per ulteriori informazioni, vedere Impostazioni di sicurezza di seconda generazione.

Mantenere il sistema operativo guest sicuro.

Installare gli aggiornamenti della sicurezza più recenti prima di attivare una
macchina virtuale in un ambiente di produzione.
Installare i servizi di integrazione per i sistemi operativi guest supportati che lo
richiedono e mantenerli aggiornati. Gli aggiornamenti del servizio di
integrazione per gli utenti guest che eseguono versioni di Windows supportate
sono disponibili tramite Windows Update.
Rafforzare il sistema operativo in esecuzione in ogni macchina virtuale in base al
ruolo eseguito. Usare le raccomandazioni relative alle impostazioni di sicurezza
di base descritte nella baseline di Windows Security.

Usare una rete sicura.

Accertarsi che le schede di rete virtuale si connettano al commutatore virtuale

corretto e che siano applicate le impostazioni e i limiti di sicurezza appropriati.

Archiviare hard disk virtuali e file di snapshot in un luogo sicuro.

Proteggere i dispositivi.

Configurare solo i dispositivi necessari per una macchina virtuale. Non abilitare
l'assegnazione di dispositivi discreti nel proprio ambiente di produzione, a meno
 che non sia necessaria per uno scenario specifico. Se lo si abilita, accertarsi di
esporre solo i dispositivi di fornitori attendibili.

Configurare software antivirus, firewall e di rilevamento intrusioni all'interno

delle macchine virtuali in base al ruolo della macchina virtuale.

Abilitare la sicurezza basata sulla virtualizzazione per gli utenti guest che
eseguono Windows 10, Windows Server 2016 o versione successiva.

Per ulteriori informazioni, vedere la Guida alla distribuzione di Device Guard.

Abilitare l'assegnazione di dispositivi discreti solo se necessario per un carico di

lavoro specifico.

A causa della natura del passaggio per un dispositivo fisico, collaborare con il
produttore del dispositivo per capire se deve essere usato in un ambiente sicuro.

Per ambienti più sicuri:

Distribuire macchine virtuali con schermatura abilitata e distribuirle in

un'infrastruttura sorvegliata.

Per ulteriori informazioni, vedere Impostazioni di sicurezza di seconda generazione

e Infrastruttura sorvegliata.

Commenti e suggerimenti
Questa pagina è stata utile?  Sì  No
Pianificare l'accelerazione GPU in Windows
Server
14/07/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Azure Local 2311.2 and later

Questo articolo presenta le funzionalità di virtualizzazione grafica disponibili in Windows

Server.

Quando usare l'accelerazione GPU

A seconda del carico di lavoro, è possibile prendere in considerazione l'accelerazione GPU.
Ecco cosa considerare prima di scegliere l'accelerazione GPU:

Comunicazione remota di app e desktop (VDI/DaaS): se si crea un servizio di

comunicazione remota di app o desktop con Windows Server, prendere in considerazione
il catalogo delle app che ci si aspetta vengano eseguite dagli utenti. Alcuni tipi di app, ad
esempio app CAD/CAM, app di simulazione, giochi e app di rendering/visualizzazione, si
basano principalmente sul rendering 3D per offrire interattività fluide e reattive. La
maggior parte dei clienti considera le GPU una necessità per un'esperienza utente
ragionevole con questi tipi di app.
Rendering remoto, codifica e carichi di lavoro di visualizzazione: questi carichi di lavoro
orientati alla grafica tendono a basarsi principalmente sulle funzionalità specializzate di
una GPU, ad esempio il rendering 3D efficiente e la codifica/decodifica dei frame, per
ottenere obiettivi di efficienza e velocità effettiva. Per questo tipo di carico di lavoro, una
singola macchina virtuale (VM) abilitata per GPU potrebbe essere in grado di
corrispondere alla velocità effettiva di molte VM solo CPU.
Carichi di lavoro HPC e ML: per carichi di lavoro computazionali altamente paralleli ai
dati, ad esempio il calcolo ad alte prestazioni e il training o l'inferenza del modello di
Machine Learning, le GPU possono ridurre notevolmente il tempo di risultato, il tempo di
inferenza e il tempo di training. In alternativa, potrebbero offrire una migliore
convenienza rispetto a un'architettura solo CPU a un livello di prestazioni confrontabile.
Molti framework HPC (High Performance Compute) e di apprendimento automatico
possono usare l'accelerazione GPU; valutare se l'accelerazione GPU potrebbe
avvantaggiare il carico di lavoro specifico.

Virtualizzazione GPU in Windows Server

Le tecnologie di virtualizzazione GPU consentono l'accelerazione GPU in un ambiente
virtualizzato, in genere all'interno delle macchine virtuali. Se il carico di lavoro è virtualizzato
con Hyper-V, è necessario utilizzare la virtualizzazione grafica per fornire l'accelerazione GPU
dalla GPU fisica alle app o ai servizi virtualizzati. Tuttavia, se il carico di lavoro viene eseguito
direttamente su host fisici di Windows Server, non è necessario eseguire la virtualizzazione
della grafica; le app e i servizi hanno già accesso alle funzionalità e alle API GPU supportate in
modo nativo in Windows Server.

Le tecnologie di virtualizzazione grafica seguenti sono disponibili per le macchine virtuali

Hyper-V in Windows Server:

Assegnazione di dispositivi discreti (DDA)

Partizionamento GPU (GPU-P)

Oltre ai carichi di lavoro delle macchine virtuali, Windows Server supporta anche l'accelerazione
GPU dei carichi di lavoro in contenitori di Windows. Per altre informazioni, vedere
Accelerazione GPU nei contenitori di Windows.

Assegnazione di dispositivi discreti (DDA)

La funzionalità DDA (Discrete Device Assignment) consente di dedicare una o più GPU fisiche a
una macchina virtuale. In una distribuzione DDA, i carichi di lavoro virtualizzati vengono
eseguiti nel driver nativo e in genere hanno accesso completo alle funzionalità della GPU. DDA
offre il massimo livello di compatibilità delle app e potenziali prestazioni. DDA può anche
fornire l'accelerazione GPU alle macchine virtuali Linux, a seconda del supporto.

Una distribuzione DDA può accelerare solo un numero limitato di macchine virtuali, poiché
ogni GPU fisica può fornire accelerazione al massimo a una macchina virtuale. Se si sta
sviluppando un servizio la cui architettura supporta macchine virtuali condivise, prendere in
considerazione l'hosting di più carichi di lavoro accelerati per macchina virtuale. Ad esempio,
se si sta compilando una soluzione Servizi Desktop remoto, è possibile migliorare la scalabilità
degli utenti usando le funzionalità multisessione di Windows Server per ospitare più desktop
utente in ogni VM. Questi utenti condividono i vantaggi dell'accelerazione GPU.

Vedi questi articoli per ulteriori informazioni:

Pianificare la distribuzione utilizzando l'assegnazione di dispositivi discreta

Distribuire dispositivi di grafica usando l'assegnazione di dispositivi discreta

Partizionamento GPU (GPU-P)

A partire da Windows Server 2025, il partizionamento GPU consente di condividere un
dispositivo GPU fisico con più macchine virtuali (VM). Con il partizionamento o la
virtualizzazione della GPU, ogni macchina virtuale ottiene una frazione dedicata della GPU
anziché l'intera GPU.

Il partizionamento GPU usa l'interfaccia Single Root IO Virtualization (SR-IOV), che fornisce un
limite di sicurezza supportato dall'hardware con prestazioni prevedibili per ogni VM. Ogni
macchina virtuale può accedere solo alle risorse GPU a essa dedicate e il partizionamento
hardware sicuro impedisce l'accesso non autorizzato da altre macchine virtuali.

Per altre informazioni sul partizionamento GPU, vedere questi articoli:

GPU partitioning
Partizionare e assegnare GPU a una macchina virtuale

Confronto tra DDA e partizionamento GPU

Quando si pianifica la distribuzione, considerare le funzionalità seguenti e le differenze di
supporto tra le tecnologie di virtualizzazione grafica:

ﾉ Espandi la tabella

Description Assegnazione di dispositivi discreti GPU Partitioning

Modello di Dedicated only Partitioned

risorsa GPU

VM density Basso (una o più GPU per una macchina Elevato (una o più GPU per molte
virtuale) macchine virtuali)

App Tutte le funzionalità della GPU offerte dal Tutte le funzionalità della GPU offerte
compatibility fornitore (DX 12, OpenGL, CUDA) dal fornitore (DX 12, OpenGL, CUDA)

AVC444 Disponibile tramite Criteri di gruppo Disponibile tramite Criteri di gruppo

GPU VRAM Fino a livello di VRAM supportata dalla Fino a livello di VRAM supportata dalla
GPU GPU per partizione

Driver GPU nel Driver della GPU del fornitore (NVIDIA, Driver della GPU del fornitore (NVIDIA,
guest AMD, Intel) AMD, Intel)
Che cos'è la virtualizzazione annidata?
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

La virtualizzazione annidata è una funzionalità che consente di eseguire Hyper-V all'interno di

una macchina virtuale Hyper-V. Questo articolo illustra il funzionamento della virtualizzazione
annidata, i relativi vantaggi e quando usarla nell'ambiente in uso. Ad esempio, la
virtualizzazione annidata può essere utile per:

Esecuzione di applicazioni o emulatori in una VM nidificata

Test delle versioni software nelle macchine virtuali
Riduzione dei tempi di distribuzione per gli ambienti di training
Uso dell'isolamento Hyper-V per i contenitori

I processori moderni includono funzionalità hardware che rendono la virtualizzazione più

veloce e più sicura. Hyper-V si basa su queste estensioni del processore per eseguire macchine
virtuali, ad esempio Intel VT-x e AMD-V. La virtualizzazione annidata rende disponibile questo
supporto hardware per le macchine virtuali guest.

Il diagramma seguente mostra Hyper-V senza annidamento. L'hypervisor Hyper-V assume il

controllo completo delle funzionalità di virtualizzazione hardware (freccia arancione) e non le
espone al sistema operativo guest.

Il diagramma seguente mostra invece Hyper-V con la virtualizzazione annidata abilitata. In

questo caso, Hyper-V espone le estensioni di virtualizzazione hardware alle macchine virtuali.
Con l'annidamento abilitato, una macchina virtuale guest può installare il proprio hypervisor ed
eseguire le proprie macchine virtuali guest.

Ridimensionamento della memoria dinamica e

della memoria di runtime
Quando Hyper-V è in esecuzione all'interno di una macchina virtuale, la macchina virtuale deve
essere disattivata per regolarne la memoria. Ciò significa che anche se la memoria dinamica è
abilitata, la quantità di memoria non varia. L'abilitazione della virtualizzazione annidata non ha
alcun effetto sul ridimensionamento della memoria dinamica o della memoria di runtime.

Per le macchine virtuali senza memoria dinamica abilitata, il tentativo di regolare la quantità di
memoria durante l'esecuzione non riesce. L'incompatibilità si verifica solo quando Hyper-V è in
esecuzione nella macchina virtuale.

App di virtualizzazione non Microsoft

Le applicazioni di virtualizzazione diverse da Hyper-V non sono supportate nelle macchine
virtuali Hyper-V e potrebbero non riuscire. Le applicazioni di virtualizzazione includono
qualsiasi software che richiede estensioni di virtualizzazione hardware.

Scenari supportati
L'uso di una macchina virtuale Hyper-V annidata nell'ambiente di produzione è supportato per
Azure e in locale negli scenari seguenti. È anche consigliabile assicurarsi che siano supportati
anche i servizi e le applicazioni.

La virtualizzazione annidata non è adatta per Il clustering di failover di Windows Server e le

applicazioni sensibili alle prestazioni. È consigliabile valutare completamente i servizi e le
applicazioni.

Macchine virtuali Hyper-V in macchine virtuali Hyper-V

L'esecuzione di macchine virtuali Hyper-V annidate nelle macchine virtuali Hyper-V è ideale per
i lab di test e gli ambienti di valutazione. In particolare quando le configurazioni possono
essere modificate facilmente e gli stati salvati possono essere usati per ripristinare
configurazioni specifiche. I lab di test in genere non richiedono lo stesso contratto di servizio
degli ambienti di produzione.

Sono supportati gli ambienti di produzione che eseguono macchine virtuali Hyper-V in
esecuzione in macchine virtuali Hyper-V. Assicurarsi che siano supportati anche i servizi e le
applicazioni. Se si usa una macchina virtuale Hyper-V annidata nell'ambiente di produzione,
assicurarsi di valutare completamente se i servizi o le applicazioni forniscono il comportamento
previsto.

Per altre informazioni sulla configurazione della virtualizzazione annidata in Azure, vedere il
blog della community tecnica Come configurare la virtualizzazione annidata per vm/disco
rigido virtuale di Azure.

Virtualizzazione non Microsoft nella virtualizzazione Hyper-V

Anche se potrebbe essere possibile che la virtualizzazione non Microsoft venga eseguita in
Hyper-V, Microsoft non testa questo scenario. La virtualizzazione non Microsoft su piattaforma
di virtualizzazione Hyper-V non è supportata. Verificare che il fornitore dell'hypervisor supporti
questo scenario.

Hyper-V virtualizzazione su piattaforme di virtualizzazione

non Microsoft
Anche se potrebbe essere possibile eseguire Hyper-V virtualizzazione in una virtualizzazione
non Microsoft, Microsoft non testa questo scenario. Hyper-V virtualizzazione su piattaforme
non Microsoft non è supportata. Verificare che il fornitore dell'hypervisor supporti questo
scenario.
Annidato locale di Azure in macchine virtuali Hyper-V
Azure Local è progettato e testato per l'esecuzione su hardware fisico convalidato. Azure Local
può essere eseguito annidato in una macchina virtuale per la valutazione, ma gli ambienti di
produzione in una configurazione annidata non sono supportati.

Per ulteriori informazioni sulla virtualizzazione annidata locale nelle macchine virtuali Hyper-V
di Azure, vedere Virtualizzazione annidata in Azure Locale.

Contenitori isolati hyper-V in esecuzione annidati in Hyper-V

Microsoft offre l'isolamento Hyper-V per i contenitori. Questa modalità di isolamento offre
sicurezza avanzata e compatibilità più ampia tra le versioni dell'host e del contenitore. Con
l'isolamento Hyper-V, più istanze del contenitore vengono eseguite simultaneamente in un
host. Ogni contenitore viene eseguito all'interno di una macchina virtuale altamente
ottimizzata e ottiene in modo efficace il proprio kernel. Poiché un contenitore isolato Hyper-V
offre isolamento tramite un livello hypervisor tra se stesso e l'host contenitore, quando l'host
contenitore è una macchina virtuale basata su Hyper-V, si verifica un sovraccarico delle
prestazioni. Il sovraccarico delle prestazioni associato si verifica in termini di tempo di avvio del
contenitore, archiviazione, rete e operazioni della CPU.

Quando un contenitore isolato Hyper-V viene eseguito in una macchina virtuale Hyper-V, viene
eseguito annidato. L'uso di una macchina virtuale Hyper-V apre molti scenari utili, ma aumenta
anche la latenza, poiché esistono due livelli di hypervisor in esecuzione sopra l'host fisico.

L'esecuzione di contenitori isolati Hyper-V annidati in Hyper-V è supportata. Un livello di

virtualizzazione annidata è supportato nell'ambiente di produzione, che consente distribuzioni
di contenitori isolati.

Per altre informazioni sui contenitori Hyper-V annidati, vedere Ottimizzazione delle prestazioni
dei contenitori di Windows Server.

Esegui WSL2 in una macchina virtuale Hyper-V che viene

eseguita in modalità annidata su Hyper-V
sottosistema Windows per Linux (WSL) è una funzionalità del sistema operativo Windows che
consente di eseguire un file system Linux, insieme agli strumenti da riga di comando linux e
alle app GUI, direttamente in Windows.

L'esecuzione di WSL2 in una macchina virtuale Hyper-V in esecuzione annidata in Hyper-V è

supportata.
Per altre informazioni su come abilitare L'esecuzione di WSL 2 in una macchina virtuale, vedere
Domande frequenti sulle sottosistema Windows per Linux.

Contenuti correlati
Eseguire Hyper-V in una macchina virtuale con virtualizzazione annidata

Last updated on 25/07/2025

Hyper-V Fibre Channel virtuale
Articolo • 30/04/2025 •
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Azure Local 2311.2 and later

Hyper-V fornisce porte Fibre Channel all'interno di sistemi operativi guest che consentono di
connettersi a Fibre Channel direttamente dalle macchine virtuali. Questa funzionalità consente
di virtualizzare i carichi di lavoro che usano l'accesso diretto all'archiviazione Fibre Channel, ai
guest del cluster tramite Fibre Channel e offre più opzioni di archiviazione per i server ospitati
nell'infrastruttura di virtualizzazione. Questo articolo offre una breve panoramica di Fibre
Channel su Hyper-V per comprendere come implementare Il Fibre Channel virtuale nella
pianificazione Hyper-V.

Prerequisiti
Per usare Fibre Channel virtuale in Hyper-V, la distribuzione deve avere quanto segue:

Una o più installazioni di Windows Server 2012 o versioni successive con il ruolo Hyper-V
installato.

Un dispositivo dotato di una o più schede host bus Fibre Channel (HBA) e un driver HBA
aggiornato che supporta la virtualizzazione Fibre Channel.

Le porte HBA devono inoltre avere una topografia Fibre Channel in grado di
supportare N_Port ID Virtualization (NPIV), una dimensione massima di trasferimento
di almeno 0,5 MB e trasferimenti di dati di almeno 128 pagine fisiche.

La lunghezza massima del trasferimento dell'adattatore determina il limite LUN. Ad

esempio, una lunghezza massima di trasferimento di 512k consente circa 2.250 LUN. È
necessario configurare i LUN e i percorsi di archiviazione multipla per mantenere
questi limiti.

Una rete SAN (Rete di Archiviazione) con supporto NPIV.

Le macchine virtuali che usano Windows Server 2012 o versione successiva come sistema
operativo guest e possono supportare schede Fibre Channel virtuali.

L'archiviazione accessibile tramite Fibre Channel virtuale supporta i dispositivi che

presentano unità logiche. Le unità logiche Fibre Channel virtuali non possono essere
usate come supporti di avvio.

Come funziona il Fibre Channel virtuale

Fibre Channel virtuale per Hyper-V fornisce al sistema operativo guest l'accesso diretto a una
SAN tramite un World Wide Name (WWN) standard associato a una macchina virtuale. Hyper-
V gli utenti possono usare reti SAN Fibre Channel per virtualizzare i carichi di lavoro che
richiedono l'accesso diretto ai numeri di unità logica SAN (LUN). Le reti SAN Fibre Channel
consentono anche di operare in nuovi scenari, ad esempio l'esecuzione del clustering di
failover all'interno del sistema operativo guest di una macchina virtuale connessa
all'archiviazione Fibre Channel condivisa.

Le distribuzioni fisiche usano la funzionalità di archiviazione avanzata di array di archiviazione

di fascia media e high-end per eseguire l'offload di determinate attività di gestione dagli host
allo stack di dischi rigidi virtuali del software Windows. Nelle distribuzioni virtualizzate, Fibre
Channel Virtuale svolge un ruolo simile, consentendo di usare la funzionalità SAN direttamente
dalle macchine virtuali Hyper-V per scaricare le funzionalità. Ad esempio, quando si usa Hyper-
V per creare uno snapshot di un LUN, è possibile trasferire le funzionalità di archiviazione
nell'hardware SAN usando un provider del Servizio Copia Shadow del volume hardware (VSS)
dall'interno di una macchina virtuale Hyper-V.

Le sezioni seguenti spiegano quali funzionalità di Fibre Channel virtuale aiutano ad alleggerire
il carico delle attività di gestione e archiviazione.

Supporto NPIV
Virtual Fibre Channel per i guest Hyper-V utilizza lo standard esistente N_Port ID Virtualization
(NPIV) T11 per mappare più ID N_Port virtuali su un singolo N_port Fibre Channel fisico. Viene
creata una nuova porta NPIV nell'host ogni volta che si avvia una macchina virtuale configurata
con un HBA virtuale. Quando la VM smette di funzionare sull'host, il sistema rimuove la porta
NPIV. È consigliabile configurare tutte le porte HBA usate per Fibre Channel virtuale in una
topologia Fibre Channel che supporta NPIV e la rete SAN deve supportare anche le porte NPIV.

Supporto per SAN virtuale

Una SAN virtuale definisce un gruppo denominato di porte Fibre Channel fisiche connesse alla
stessa SAN fisica. Hyper-V consente di definire reti SAN virtuali nell'host in scenari in cui si
connette un singolo host Hyper-V a diverse reti SAN tramite molte porte Fibre Channel.

Ad esempio, se un host Hyper-V è connesso a una SAN di produzione e a una SAN di prova,
l'host viene connesso a ogni SAN tramite due porte Fibre Channel fisiche. In questo scenario è
possibile configurare due SAN virtuali. La rete SAN di produzione virtuale ha le due porte Fibre
Channel fisiche connesse alla SAN di produzione fisica. La SAN di test virtuale ha due porte
Fibre Channel fisiche connesse alla SAN di test. È possibile usare la stessa tecnica per assegnare
un nome a due percorsi diversi alla stessa destinazione di archiviazione.
È possibile configurare fino a quattro schede Fibre Channel virtuali in una macchina virtuale e
associarne ognuna a una SAN virtuale. Ogni scheda Fibre Channel virtuale si connette con un
indirizzo WWN ed è possibile impostare ogni indirizzo WWN automaticamente o
manualmente. Negli scenari di migrazione in tempo reale, tuttavia, due indirizzi WWN vengono
assegnati a ogni adattatore.

Migrazione Live
Per supportare la migrazione in tempo reale delle macchine virtuali tra gli host Hyper-V
mantenendo la connettività Fibre Channel, sono configurati due wwn per ogni scheda Fibre
Channel virtuale, come illustrato nel diagramma seguente. Hyper-V alterna automaticamente
gli indirizzi WWN set A e Set B durante una migrazione in tempo reale. Ciò garantisce che tutti
i LUN siano disponibili nell'host di destinazione prima della migrazione e che non si verifichino
tempi di inattività durante la migrazione.

Supporto per la libreria di nastri

Windows Server supporta solo librerie di nastri virtuali configurate con schede Fibre Channel
virtuali quando si usa System Center Data Protection Manager 2012 R2 U3 o versione
successiva con hardware certificato. È possibile verificare se l'adattatore Fibre Channel virtuale
supporta una libreria di nastri contattando il fornitore dell'hardware della libreria di nastri. È
anche possibile controllare la compatibilità eseguendo lo strumento di test di compatibilità
della libreria di nastri DPM (Data Protection Management) nella libreria di nastri virtuali in una
macchina virtuale guest. Per altre informazioni sul test di compatibilità della libreria di nastri
DPM, vedere Verificare la compatibilità della libreria di nastri.

Funzionalità MPIO
Hyper-V in Windows Server può usare la funzionalità di I/O multipath (MPIO) per garantire la
connettività continua all'archiviazione Fibre Channel dall'interno di una macchina virtuale. È
possibile usare la funzionalità MPIO con Fibre Channel nei modi seguenti:

Usare MPIO per l'accesso all'host. Per usare questa funzionalità, installare più porte Fibre
Channel nell'host, quindi usare MPIO per fornire connettività a disponibilità elevata ai
LUN a cui l'host può accedere.

Virtualizzare i carichi di lavoro che usano MPIO. Per usare questa funzionalità, configurare
più schede Fibre Channel virtuali all'interno di una macchina virtuale, quindi usare una
copia separata di MPIO all'interno del sistema operativo della macchina virtuale per
connettersi ai LUN a cui può accedere la macchina virtuale. Questa configurazione può
coesistere con un'installazione MPIO host.

Usare moduli specifici del dispositivo diversi per l'host o ogni macchina virtuale. Questo
approccio consente la migrazione in tempo reale della configurazione della macchina
virtuale, tra cui DSM, connettività tra host e compatibilità con le configurazioni del server
e i DSM esistenti.

７ Nota

Gli scenari di migrazione in tempo reale in cui la macchina virtuale guest usa MPIO non
supportano l'assegnazione di unità logiche asimmetriche (ALUA).

Contenuti correlati
Pianificare Hyper-V in Windows Server

Pianificare la scalabilità Hyper-V in Windows Server

Infrastruttura sorvegliata e macchine
virtuali schermate
14/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016

Uno degli obiettivi più importanti nell'ambito della fornitura di un ambiente ospitato è
garantire la sicurezza delle macchine virtuali in esecuzione nell'ambiente. L'infrastruttura
sorvegliata consente ai provider di servizi cloud o agli amministratori del cloud privato
aziendale di offrire un ambiente più sicuro per le macchine virtuali. Un'infrastruttura sorvegliata
è costituita da un servizio Sorveglianza host (Host Guardian Service - HGS), in genere un cluster
di tre nodi, nonché da uno o più host sorvegliati e un set di macchine virtuali schermate.

） Importante

Assicurarsi di aver installato tutti gli aggiornamenti disponibili prima di distribuire le

macchine virtuali schermate nell'ambiente di produzione.

Video, blog e panoramica sulle infrastrutture

sorvegliate e sulle macchine virtuali schermate
Video: Come proteggere l'infrastruttura di virtualizzazione dalle minacce interne con
Windows Server 2019
Video: Introduzione alle macchine virtuali schermate di Windows Server 2016
Video: Approfondimenti sulle macchine virtuali schermate con Windows Server 2016
Hyper-V
Video: Distribuzione di macchine virtuali schermate e infrastrutture sorvegliate con
Windows Server 2016
Blog: Sicurezza dei centri dati e dei cloud privati
Panoramica: Infrastrutture sorvegliate e macchine virtuali schermate

Argomenti relativi alla pianificazione

Guida alla pianificazione per gli host
Guida alla pianificazione per i tenant

Argomenti relativi alla distribuzione

 Guida alla distribuzione
Avvio rapido
Distribuire HGS
Distribuire host protetti
Configurazione del DNS dell'infrastruttura per gli host che diventeranno host
sorvegliati
Distribuire un host sorvegliato usando la modalità AD
Distribuire un host sorvegliato usando la modalità TPM
Confermare che gli host sorvegliati possono fornire attestazioni
Macchine virtuali schermate - Provider di servizi di hosting distribuisce gli host
sorvegliati in VMM
Distribuire macchine virtuali schermate
Creare un modello di macchina virtuale schermata
Preparare un VHD helper di schermatura della macchina virtuale
Configurare Windows Azure Pack
Creare un file di dati di schermatura
Distribuire una macchina virtuale schermata usando Windows Azure Pack
Distribuire una macchina virtuale schermata usando Virtual Machine Manager

Argomento relativo alle operazioni e alla gestione

Gestire il servizio Sorveglianza host
approcci di backup Hyper-V
15/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Hyper-V consente di eseguire il backup di macchine virtuali dal sistema operativo host, senza la
necessità di eseguire software di backup personalizzato all'interno della macchina virtuale.
Sono disponibili diversi approcci che gli sviluppatori possono usare in base alle proprie
esigenze.

È possibile eseguire un backup di vm o un backup di sola dati:

Backup delle macchine virtuali: questo approccio esegue il backup dell'intera macchina
virtuale, inclusa la configurazione e tutti i dati. È utile quando si vuole ripristinare l'intera
macchina virtuale a uno stato precedente. Ogni backup della macchina virtuale (completo
o incrementale) deve essere copiato in tutti i file di configurazione e stato della macchina
virtuale associati, inclusi la configurazione della macchina virtuale ( .VMCX ), lo stato guest
della macchina virtuale ( .VMGS ) e i file dello stato di runtime della macchina virtuale
( .VMRS ). Se non si copiano tutti questi file, lo stato della macchina virtuale non viene
acquisito completamente.

Backup solo dati: questo approccio esegue il backup solo dei dati archiviati nei dischi
rigidi virtuali della macchina virtuale. Per ripristinare un backup solo dati, creare una
nuova macchina virtuale e ripristinare i dati.

Hyper-V VSS Writer

Hyper-V implementa un writer del servizio Copia Shadow del volume in tutte le versioni di
Windows Server in cui Hyper-V è supportato. Questo writer VSS consente agli sviluppatori di
usare l'infrastruttura VSS esistente per eseguire il backup delle macchine virtuali. Tuttavia, è
progettato per operazioni di backup su scala ridotta in cui viene eseguito il backup simultaneo
di tutte le macchine virtuali in un server.

Hyper-V backup basato su WMI

A partire da Windows Server 2016, Hyper-V supporta Hyper-V il backup tramite l'API WMI
(Windows Management Instrumentation). Questo approccio usa ancora VSS all'interno della
macchina virtuale a scopo di backup, ma non usa più Vss nel sistema operativo host. Viene
invece usata una combinazione di punti di riferimento e rilevamento delle modifiche resilienti
(RCT) per consentire agli sviluppatori di accedere alle informazioni relative alle macchine
virtuali di cui è stato eseguito il backup in modo efficiente. Questo approccio è più scalabile
rispetto all'uso di VSS nell'host, ma è disponibile solo in Windows Server 2016 e versioni
successive.

Per altre informazioni, vedere le informazioni di riferimento sul provider WMIHyper-V.

Metodi per la lettura dei backup dal backup basato

su WMI
Quando si creano backup di macchine virtuali usando Hyper-V WMI, sono disponibili tre
metodi per leggere i dati effettivi dal backup. Ognuno presenta vantaggi e svantaggi unici.

Esportazione WMI
Gli sviluppatori possono esportare i dati di backup tramite le interfacce WMI Hyper-V (come
usato nell'esempio precedente). Hyper-V compila le modifiche in un disco rigido virtuale e
copia il file nel percorso richiesto. Questo metodo è facile da usare, funziona per tutti gli
scenari e funziona in modalità remota. Tuttavia, il disco rigido virtuale generato spesso crea
una grande quantità di dati da trasferire in rete.

API Win32
Gli sviluppatori possono usare le SetVirtualDiskInformation API , GetVirtualDiskInformation e
QueryChangesVirtualDisk nel set di API Win32 del disco rigido virtuale come documentato

nelle informazioni di riferimento su Disco rigido virtuale Win32. Per usare queste API, è
comunque necessario usare Hyper-V WMI per creare punti di riferimento nelle macchine
virtuali associate. Queste API Win32 consentono quindi l'accesso efficiente ai dati della
macchina virtuale di cui è stato eseguito il backup. Le API Win32 presentano diverse limitazioni:

È possibile accedervi solo in locale

Non supportano la lettura dei dati dai file del disco rigido virtuale condiviso
Restituiscono indirizzi di dati relativi alla struttura interna del disco rigido virtuale

Remote Shared Virtual Disk Protocol

Infine, se uno sviluppatore deve accedere in modo efficiente alle informazioni sui dati di
backup da un file di disco rigido virtuale condiviso, deve usare remote shared virtual disk
Protocol. Questo protocollo è documentato nelle informazioni di riferimento su Remote Shared
Virtual Disk Protocol.
Installare Hyper-V.
14/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Questo articolo illustra come installare Hyper-V in Windows e Windows Server. Segui il set di
istruzioni che soddisfano le tue esigenze.

Abilitare Hyper-V per creare macchine virtuali in Windows. Hyper-V possono essere abilitati in
molti modi, tra cui l'uso del pannello di controllo di Windows, PowerShell o lo strumento
DiSM (Deployment Imaging Servicing and Management Tool). Questo articolo illustra ogni
opzione.

７ Nota

Hyper-V è integrato in Windows come funzionalità facoltativa. Non è disponibile alcun

download Hyper-V.

Verificare i requisiti per Windows

Windows 10 (Pro o Enterprise) o Windows 11 (Pro o Enterprise)
Processore a 64 bit con SLAT (Second Level Address Translation).
Supporto della CPU per l'estensione della modalità monitoraggio VM (VT-c nelle CPU
Intel).
Memoria minima di 4 GB.

７ Nota

Il ruolo Hyper-V non può essere installato in Windows 10 Home o Windows 11 Home.

Per altre informazioni e risoluzione dei problemi, vedere Requisiti di sistema di Windows
Hyper-V.

Abilitare Hyper-V
PowerShell

Per abilitare Hyper-V in Windows tramite PowerShell:

 1. Sul desktop di Windows selezionare il pulsante Start e digitare qualsiasi parte del
nome Windows PowerShell.

2. Fare doppio clic su Windows PowerShell e selezionare Esegui come amministratore.

） Importante

È necessario eseguire PowerShell come amministratore oppure i comandi hanno

esito negativo.

3. Eseguire il comando seguente:

PowerShell

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All

4. Immettere Y per fare in modo che il computer venga riavviato per completare
l'installazione.

Per abilitare il ruolo Hyper-V in Windows tramite DISM:

Lo strumento DISM (Deployment Image Servicing and Management Tool) consente di

configurare Windows e le immagini di Windows. Tra le numerose applicazioni di DISM, è
possibile abilitare le funzionalità di Windows mentre il sistema operativo è in funzione.

1. Sul desktop di Windows selezionare il pulsante Start e digitare qualsiasi parte del
nome Windows PowerShell.

2. Fare doppio clic su Windows PowerShell e selezionare Esegui come amministratore.

3. Digitare il comando seguente:

PowerShell

DISM /Online /Enable-Feature /All /FeatureName:Microsoft-Hyper-V

 4. Si noterà che la funzionalità è abilitata e che l'operazione è stata completata
correttamente.

Per ulteriori informazioni su DISM, vedere il Riferimento tecnico di DISM.

Passo successivo
Creare una macchina virtuale in Hyper-V
Creare e configurare un commutatore
virtuale con Hyper-V
16/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Questo articolo illustra come creare e configurare il commutatore virtuale usando la console di
gestione di Hyper-V o PowerShell. Un commutatore virtuale consente alle macchine virtuali
create negli host Hyper-V per comunicare con altri computer.

Prerequisites
Prima di poter creare e configurare il commutatore virtuale, il computer deve soddisfare i
prerequisiti seguenti:

Hyper-V deve essere abilitato

I tipi di commutatore virtuale sono: esterno, interno. e privato. Determinare il tipo di

commutatore virtuale da creare.
Identificare la rete a cui si connette il computer. Per ulteriori informazioni, vedere l'articolo
Pianificazione di una rete core.
Disporre di diritti di amministrazione.

Creare un commutatore virtuale

Dopo aver completato i prerequisiti, è possibile creare il commutatore virtuale. In questa
sezione viene creato un commutatore virtuale di base seguendo questa procedura.

Hyper-V Manager

Ecco come creare un commutatore virtuale utilizzando Hyper-V Manager.

1. Aprire la console di gestione di Hyper-V.

2. Nel riquadro Azioni selezionare Gestione commutatori virtuali.

3. Scegliere il tipo di commutatore virtuale, quindi selezionare Crea commutatore

virtuale.

4. Immettere un nome per il commutatore virtuale, quindi eseguire uno dei passaggi
seguenti.
 a. Se è stata selezionata l'opzione esterna, scegliere la scheda di rete (NIC) da usare,
quindi selezionare OK.

Viene visualizzato un avviso che indica che la modifica potrebbe compromettere la

connettività di rete; selezionare Sì se si desidera continuare.

b. Se è stata selezionata l'opzione interna o privata, selezionare OK.

Condivisione del sistema operativo di gestione

Un commutatore virtuale esterno consente alle macchine virtuali di connettersi a una rete
esterna. È anche possibile consentire al sistema operativo di gestione di condividere la stessa
scheda di rete selezionata. Per iniziare, eseguire la procedura seguente.

Hyper-V Manager

Ecco come consentire al sistema operativo di gestione di condividere la stessa scheda di

rete selezionata usando la console di gestione di Hyper-V.

1. Aprire la console di gestione di Hyper-V.

2. Nel riquadro Azioni selezionare Gestione commutatori virtuali.

3. Selezionare il commutatore virtuale da configurare, verificare Consenti condivisione

della scheda di rete da parte del sistema operativo di gestione e selezionare OK.

Verrà visualizzato un avviso che indica che la modifica potrebbe interrompere la

connettività di rete; selezionare Sì se si è soddisfatti di continuare.

Identificazione LAN virtuale (VLAN)

È possibile specificare l'identificazione VLAN (ID) usata dalle schede di rete delle macchine
virtuali e dai commutatori virtuali. Per i commutatori virtuali connessi a una rete esterna o
interna, è possibile specificare l'ID (VLAN). Il numero ID VLAN viene usato dal sistema operativo
di gestione e dalle macchine virtuali che comunicano tramite questo commutatore virtuale.

È anche possibile configurare il commutatore virtuale con altre opzioni VLAN, ad esempio la
modalità porta e l'ID VLAN nativo. Per queste opzioni, è necessario usare PowerShell e
assicurarsi che la configurazione sia compatibile con la configurazione delle reti.
Per configurare l'identificazione VLAN per il commutatore, eseguire la procedura seguente.

Hyper-V Manager

Ecco come specificare l'ID VLAN usando la console di gestione di Hyper-V.

1. Aprire la console di gestione di Hyper-V.

2. Nel riquadro Azioni selezionare Gestione commutatori virtuali.

3. Selezionare il commutatore virtuale da configurare, selezionare Abilita

identificazione LAN virtuale per il sistema operativo di gestione.

a. È possibile immettere qualsiasi numero ID VLAN o lasciare il valore predefinito,

quindi selezionare OK.

Ti viene notificato che la modifica potrebbe compromettere la connettività di rete.

Seleziona Sì se desideri continuare.

Gli identificatori VLAN devono essere coerenti con la rete per garantire la compatibilità tra
computer, macchine virtuali e altri dispositivi di rete.

Rete NAT
Network Address Translation (NAT) consente a una macchina virtuale di accedere alla rete del
computer combinando l'indirizzo IP del computer host con una porta tramite un commutatore
virtuale Hyper-V interno.

Questa ha alcune proprietà utili:

1. NAT conserva gli indirizzi IP eseguendo il mapping di un indirizzo IP esterno e di una

porta di rete a un set molto più ampio di indirizzi IP interni.
2. NAT consente a più macchine virtuali di ospitare applicazioni che richiedono porte di
comunicazione identiche (interne) mappandole su porte esterne univoche.
3. NAT usa un commutatore interno: la creazione di un commutatore interno non causa
l'uso della connessione di rete e tende a interferire meno con la rete di un computer.

Per configurare una rete NAT e connetterla a una macchina virtuale, seguire la guida dell'utente
di rete NAT .

Contenuti correlati
Dopo aver configurato un commutatore virtuale, ecco altri articoli che consentono di
continuare con Hyper-V.

Altre informazioni su Switch Embedded Teaming (SET).

Informazioni su come creare una macchina virtuale in Hyper-V.
Informazioni su altre opzioni di configurazione negli articoli di riferimento di PowerShell
Set-VMSwitch e Set-VMNetworkAdapterVlan .
Creare una macchina virtuale in Hyper-V
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Informazioni su come creare una macchina virtuale utilizzando Hyper-V Manager in modo che
Windows PowerShell e le opzioni quando si crea una macchina virtuale in Hyper-V Manager.

Prerequisiti
Prima di creare una macchina virtuale, assicurarsi di disporre dei prerequisiti seguenti:

Un computer che esegue Windows Server o client Windows con Hyper-V abilitato. Per
altre informazioni, vedere Installare il ruolo Hyper-V in Windows Server.
Appartenenza al gruppo Administrators locale o al gruppo administratorsHyper-V .
Memoria fisica sufficiente nell'host da allocare alla macchina virtuale.
Spazio su disco sufficiente per i file di configurazione della macchina virtuale e i dischi
rigidi virtuali.
(Facoltativo) Un commutatore virtuale configurato se si vuole la connettività di rete per la
macchina virtuale. Vedere creare un commutatore virtuale per le macchine virtuali Hyper-
V.
(Facoltativo) Un supporto di installazione del sistema operativo (file .iso) o un disco rigido
virtuale esistente (con estensione vhd o vhdx) se si vuole installare un sistema operativo.

Creare una macchina virtuale

Per creare una macchina virtuale, usare Hyper-V Manager o Windows PowerShell. Selezionare il
metodo preferito:

Hyper-V Manager

Per creare una macchina virtuale in Hyper-V Manager, seguire questa procedura:

1. Selezionare il pulsante Start , digitare Hyper-V Manager e quindi selezionarlo

dall'elenco.

７ Nota
 Se Hyper-V Manager non viene visualizzato, assicurarsi che sia installato il ruolo
Hyper-V. Per altre informazioni, vedere Installare il ruolo Hyper-V in Windows
Server.

2. Nel riquadro sinistro, in Hyper-V Manager selezionare il server.

3. Nel riquadro Azioni selezionare Nuovo, quindi selezionare Macchina virtuale.

4. Nella Creazione guidata macchina virtualeselezionare Avanti.

5. Per la pagina Specifica nome e percorso immettere un nome per la macchina

virtuale e scegliere un percorso in cui archiviare i file di configurazione della
macchina virtuale. Seleziona Avanti.

(Facoltativamente) Per archiviare i file di configurazione della macchina virtuale in un

percorso diverso, selezionare la casella di controllo Archivia la macchina virtuale in
un percorso diverso e quindi passare alla cartella in cui archiviare i file.

6. Nella pagina Specifica generazione selezionare la generazione della macchina

virtuale. Per altre informazioni, vedi È necessario creare una macchina virtuale di
generazione 1 o 2 in Hyper-V? Creare una macchina virtuale di seconda generazione,
a meno che non si disponga di un motivo specifico per creare una macchina virtuale
di prima generazione. Seleziona Avanti.

7. Per la pagina Assegna memoria immettere la quantità di memoria da allocare alla

macchina virtuale all'avvio. È anche possibile scegliere di abilitare la memoria
dinamica. Per ulteriori informazioni, vedere Panoramica della memoria dinamica di
Hyper-V. Seleziona Avanti.

７ Nota

La quantità minima di memoria che è possibile assegnare è 32 MB e il massimo

è 5.902 MB.

8. Per la pagina Configura rete selezionare un commutatore virtuale per connettere la

macchina virtuale alla rete. Se non è stato creato un commutatore virtuale, è
possibile ignorare questo passaggio e configurare la rete in un secondo momento.
Seleziona Avanti.

9. Nella pagina Connetti disco rigido virtuale scegliere una delle opzioni seguenti,
quindi selezionare Avanti:
 Creare un disco rigido virtuale : immettere un nome per il disco rigido virtuale,
scegliere un percorso in cui archiviarlo e specificarne le dimensioni.

Usare un disco rigido virtuale esistente : passare al percorso di un disco rigido

virtuale esistente ( .vhd o .vhdx ).

Collegare un disco rigido virtuale in un secondo momento : è possibile

collegare un disco rigido virtuale in un secondo momento.

10. Per la pagina Opzioni di installazione scegliere come installare il sistema operativo
nella macchina virtuale. È possibile scegliere una delle opzioni seguenti, quindi
selezionare Avanti:

Installare un sistema operativo in un secondo momento

Installare un sistema operativo da un file immagine avviabile - Navigare fino

alla posizione di un .iso file contenente il supporto di installazione del sistema
operativo.

Installare un sistema operativo da un disco floppy di avvio : selezionare

un'unità disco floppy contenente il supporto di installazione del sistema
operativo.

Installare un sistema operativo da un server di installazione basato sulla rete :

questa opzione prevede l'uso di Servizi di distribuzione Windows (WDS) o di un
altro servizio di installazione basato sulla rete.

11. Dopo aver verificato le scelte nella pagina Riepilogo , selezionare Fine.

Avviare e connettersi alla macchina virtuale

Dopo aver creato la macchina virtuale, è possibile avviarla e connettersi. È possibile usare
Hyper-V Manager o Windows PowerShell. Selezionare il metodo preferito:

Hyper-V Manager

Per avviare e connettersi alla macchina virtuale in Hyper-V Manager, seguire questa
procedura:

1. In Hyper-V Manager fare clic con il pulsante destro del mouse sulla macchina virtuale
e scegliere Connetti.
 2. Nella finestra Connessione macchina virtuale selezionareAvvio>.

Contenuti correlati
New-VM

Versioni di configurazione supportate della macchina virtuale

È necessario creare una macchina virtuale di generazione 1 o 2 in Hyper-V?

Creare un commutatore virtuale per le macchine virtuali Hyper-V

Last updated on 28/11/2025

Configurare le reti locali virtuali per Hyper-
V
20/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Le reti VLAN (Virtual Local Area Network) consentono di isolare il traffico di rete. Le reti VLAN
sono configurate in commutatori e router che supportano lo standard 802.1Q. Se si
configurano più VLAN e si vuole che si verifichino comunicazioni tra di esse, è necessario
configurare i dispositivi di rete per consentire tale operazione.

Per configurare le VLAN, assicurarsi di disporre di:

Scheda di rete fisica e driver che supportano il tag VLAN 802.1Q.

Commutatore di rete fisico che supporta il tag VLAN 802.1Q.

Configura sull'host il commutatore virtuale per consentire al traffico di rete di passare

attraverso la porta del commutatore fisico per gli ID VLAN utilizzati con le macchine virtuali.
Configurare quindi la macchina virtuale per specificare la VLAN usata per tutte le
comunicazioni di rete.

Consentire a un commutatore virtuale di usare una

VLAN
1. In Console di gestione di Hyper-V selezionare Gestione commutatori virtuali nel riquadro
Azioni a destra.

2. In Gestione commutatori virtuali, in Commutatori virtuali a sinistra, selezionare un

commutatore virtuale connesso a una scheda di rete fisica che supporta le VLAN.

3. In ID VLAN nel riquadro destro selezionare Abilita identificazione LAN virtuale per il
sistema operativo di gestione e quindi digitare un numero per l'ID VLAN.

4. Seleziona OK.

Tutto il traffico che attraversa la scheda di rete fisica connessa al commutatore virtuale viene
contrassegnato con l'ID VLAN impostato nel commutatore virtuale e nelle macchine virtuali.

Consentire a una macchina virtuale di usare una

VLAN
 1. In Hyper-V Manager, in Macchine virtuali fare clic con il pulsante destro del mouse sulla
macchina virtuale appropriata e selezionare Impostazioni. In alternativa, selezionare il
computer e quindi selezionare Impostazioni sotto il nome del computer nel riquadro
destro.

2. Nella schermata Impostazioni, in Hardware, nel riquadro sinistro, selezionare una scheda
di rete che ha un commutatore virtuale impostato con una VLAN.

3. In ID VLAN nel riquadro destro selezionare Abilita identificazione LAN virtuale e quindi
digitare lo stesso ID VLAN specificato per il commutatore virtuale.

4. Seleziona OK.

Se la macchina virtuale deve usare più reti VLAN, eseguire una delle operazioni seguenti:

Collegare più schede di rete virtuale ai commutatori virtuali appropriati e assegnare gli ID
VLAN. Assicurarsi di configurare correttamente gli indirizzi IP e che il traffico che si vuole
instradare attraverso la VLAN usi anche l'indirizzo IP corretto.

Configurare la scheda di rete virtuale in modalità trunk usando il cmdlet Set-

VMNetworkAdapterVlan .

Contenuti correlati
commutatore virtuale Hyper-V
Configurare una rete NAT
15/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Windows 10 e Windows 11 Hyper-V consente nat (Network Address Translation) nativo per una
rete virtuale.

Questa guida illustra le procedure seguenti:

Creare una rete NAT

Connettere una macchina virtuale esistente alla nuova rete
Verificare che la macchina virtuale sia connessa correttamente

Requisiti:

Aggiornamento dell'anniversario di Windows 10 o versione successiva

Hyper-V è abilitato. Seguire le istruzioni per abilitare Hyper-V

７ Nota

Attualmente, si è limitati a una rete NAT per ogni host. Per altri dettagli
sull'implementazione, le funzionalità e le limitazioni di NAT Windows (WinNAT), vedere il
blog sulle funzionalità e sulle limitazioni di WinNAT

Panoramica di NAT
NAT consente a una macchina virtuale di accedere alle risorse di rete usando l'indirizzo IP del
computer host e una porta tramite un commutatore virtuale Hyper-V interno.

Network Address Translation (NAT) è una modalità di rete progettata per risparmiare indirizzi IP
eseguendo il mapping di un indirizzo IP esterno e di una porta a un set molto più ampio di
indirizzi IP interni. Fondamentalmente, un NAT usa una tabella di flusso per instradare il traffico
da un indirizzo IP esterno (host) e un numero di porta all'indirizzo IP interno corretto associato
a un endpoint nella rete (macchina virtuale, computer, contenitore e così via).

NAT consente inoltre a più macchine virtuali di ospitare applicazioni che richiedono porte di
comunicazione identiche (interne) eseguendo il mapping a porte esterne univoche.

Per tutti questi motivi, la rete NAT è molto comune per la tecnologia dei contenitori (vedere
Rete dei contenitori).
Creare una rete virtuale NAT
Verrà ora illustrata la configurazione di una nuova rete NAT.

1. Aprire una console di PowerShell come amministratore.

2. Creare un commutatore interno.

PowerShell

New-VMSwitch -SwitchName "SwitchName" -SwitchType Internal

3. Trovare l'indice dell'interfaccia del commutatore virtuale appena creato.

Console

PS C:\> Get-NetAdapter

Name InterfaceDescription ifIndex Status

MacAddress LinkSpeed
---- -------------------- ------- ------
---------- ---------
vEthernet (intSwitch) Hyper-V Virtual Ethernet Adapter 24 Up
00-15-5D-00-6A-01 10 Gbps
Wi-Fi Marvell AVASTAR Wireless-AC Net... 18 Up
98-5F-D3-34-0C-D3 300 Mbps
Bluetooth Network ... Bluetooth Device ... 21 Disconnected
98-5F-D3-34-0C-D4 3 Mbps

L'opzione interna ha un nome simile vEthernet (SwitchName) a e una descrizione

dell'interfaccia di Hyper-V Virtual Ethernet Adapter . Prendere nota della proprietà
ifIndex da usare nel passaggio successivo.

4. Configurare il gateway NAT usando New-NetIPAddress.

Ecco il comando generico:

PowerShell

New-NetIPAddress -IPAddress <NAT Gateway IP> -PrefixLength <NAT Subnet Prefix

Length> -InterfaceIndex <ifIndex>

Per configurare il gateway, sono necessarie alcune informazioni sulla rete:

IPAddress - IP del gateway NAT specifica l'indirizzo IPv4 o IPv6 da usare come IP del
gateway NAT.
 Il formato generico è a.b.c.1 (ad esempio [Link]). Anche se la posizione finale non
deve essere .1, in genere è (in base alla lunghezza del prefisso). Questo indirizzo IP è
compreso nell'intervallo di indirizzi usati dalle macchine virtuali guest. Ad esempio, se le
macchine virtuali guest usano l'intervallo IP [Link], è possibile usare un indirizzo IP
[Link] come gateway NAT. Un indirizzo IP del gateway comune è [Link]

PrefixLength - Lunghezza prefisso subnet NAT definisce le dimensioni della subnet

locale NAT (subnet mask). La lunghezza del prefisso della subnet è un valore intero
compreso tra 0 e 32.

0 eseguirà il mapping dell'intera internet, 32 consentirebbe solo un indirizzo IP

mappato. I valori comuni sono compresi tra 24 e 12 a seconda del numero di
indirizzi IP da collegare al nat.

Un prefisso comune è 24. Si tratta di una subnet mask [Link].0

InterfaceIndex: ifIndex è l'indice dell'interfaccia del commutatore virtuale,

determinato nel passaggio precedente.

Eseguire quanto segue per creare il gateway NAT:

PowerShell

New-NetIPAddress -IPAddress [Link] -PrefixLength 24 -InterfaceIndex 24

5. Configurare la rete NAT usando New-NetNat.

Ecco il comando generico:

PowerShell

New-NetNat -Name <NATOutsideName> -InternalIPInterfaceAddressPrefix <NAT

subnet prefix>

Per configurare il gateway, è necessario fornire informazioni sulla rete e sul gateway NAT:

Name - NATOutsideName descrive il nome della rete NAT. Verrà usato per
rimuovere la rete NAT.

InternalIPInterfaceAddressPrefix - Il prefisso della subnet NAT descrive sia il

prefisso IP del gateway NAT che la lunghezza del prefisso della subnet NAT.

Il formato generico è a.b.c.0/NAT Subnet Prefix Length

Per questo esempio si userà [Link]/24

 Eseguire quanto segue per configurare la rete NAT:

PowerShell

New-NetNat -Name MyNATnetwork -InternalIPInterfaceAddressPrefix

[Link]/24

Felicitazioni! È ora disponibile una rete NAT virtuale.

Connettere una macchina virtuale

Per connettere una macchina virtuale alla nuova rete NAT, connettere il commutatore interno
creato nel primo passaggio di questo articolo alla macchina virtuale usando il menu
Impostazioni macchina virtuale.

Poiché WinNAT per sé non alloca e assegna indirizzi IP a un endpoint (ad esempio, macchina
virtuale), è necessario eseguire questa operazione manualmente dall'interno della macchina
virtuale stessa, ovvero impostare l'indirizzo IP all'interno dell'intervallo di prefisso interno NAT,
impostare l'indirizzo IP del gateway predefinito, impostare le informazioni sul server DNS.
L'unico avviso è quando l'endpoint è collegato a un contenitore. In questo caso, il servizio di
rete host (HNS) alloca e usa il servizio di calcolo host (HCS) per assegnare direttamente
l'indirizzo IP, l'IP del gateway e le informazioni DNS al contenitore.

Esempio di configurazione: Collegamento di

macchine virtuali e contenitori a una rete NAT
Se è necessario collegare più macchine virtuali e contenitori a un singolo NAT, è necessario
assicurarsi che il prefisso della subnet interna NAT sia sufficientemente grande da includere gli
intervalli IP assegnati da applicazioni o servizi diversi , ad esempio Docker per Windows e
Contenitore Windows - HNS. Ciò richiede l'assegnazione a livello di applicazione di indirizzi IP e
configurazione di rete o la configurazione manuale che deve essere eseguita da un
amministratore e garantisce di non riutilizzare le assegnazioni IP esistenti nello stesso host.

Docker per windows (VM Linux) e contenitori Windows

Seguire questa sezione per consentire a Docker per Windows, (vm Linux che eseguono
contenitori Linux) e contenitori Windows di condividere la stessa istanza winNAT usando
vSwitches interne separate. La connettività tra contenitori Linux e Windows funziona.

L'utente ha connesso macchine virtuali a una rete NAT tramite un vSwitch interno denominato
"VMNAT" e ora vuole installare la funzionalità Contenitore Windows con il motore Docker:
 Output

PS C:\> Get-NetNat “VMNAT”| Remove-NetNat (this removes the NAT but keep the
internal vSwitch).
Install Windows Container Feature
DO NOT START Docker Service (daemon)
Edit the arguments passed to the docker daemon (dockerd) by adding –fixed-cidr=
<container prefix> parameter. This tells docker to create a default nat network
with the IP subnet <container prefix> (e.g. [Link]/24) so that HNS can
allocate IPs from this prefix.
PS C:\> Start-Service Docker; Stop-Service Docker
PS C:\> Get-NetNat | Remove-NetNAT (again, this removes the NAT but keep the
internal vSwitch)
PS C:\> New-NetNat -Name SharedNAT -InternalIPInterfaceAddressPrefix <shared
prefix>
PS C:\> Start-Service docker

Docker/HNS assegna indirizzi IP ai contenitori di Windows e Admin assegna indirizzi IP alle

macchine virtuali dal set di differenze dei due.

L'utente ha installato la funzionalità Contenitore Windows con il motore Docker in esecuzione

e ora vuole connettere le macchine virtuali alla rete NAT:

Output

PS C:\> Stop-Service docker

PS C:\> Get-ContainerNetwork | Remove-ContainerNetwork -force
PS C:\> Get-NetNat | Remove-NetNat (this will remove the NAT but keep the internal
vSwitch)
Edit the arguments passed to the docker daemon (dockerd) by adding -b “none”
option to the end of docker daemon (dockerd) command to tell docker not to create
a default NAT network.
PS C:\> New-ContainerNetwork –name nat –Mode NAT –subnetprefix <container prefix>
(create a new NAT and internal vSwitch – HNS will allocate IPs to container
endpoints attached to this network from the <container prefix>)
PS C:\> Get-Netnat | Remove-NetNAT (again, this will remove the NAT but keep the
internal vSwitch)
PS C:\> New-NetNat -Name SharedNAT -InternalIPInterfaceAddressPrefix <shared
prefix>
PS C:\> New-VirtualSwitch -Type internal (attach VMs to this new vSwitch)
PS C:\> Start-Service docker

Docker/HNS assegna indirizzi IP ai contenitori di Windows e Admin assegna indirizzi IP alle

macchine virtuali dal set di differenze dei due.

Alla fine, si avranno due commutatori di macchina virtuale interni e uno NetNat condiviso tra di
essi.
Più applicazioni che usano lo stesso NAT
Alcuni scenari richiedono che più applicazioni o servizi usino lo stesso NAT. In questo caso, è
necessario seguire il flusso di lavoro seguente in modo che più applicazioni/servizi possano
usare un prefisso di subnet interno NAT più grande

Verranno descritti in dettaglio la macchina virtuale Docker 4 Windows - Docker Beta - Linux
co-esistente con la funzionalità Contenitore Windows nello stesso host di un esempio. Questo
flusso di lavoro è soggetto a modifiche

1. PowerShell

net stop docker

2. PowerShell

Stop Docker4Windows MobyLinux VM

3. PowerShell

Get-ContainerNetwork | Remove-ContainerNetwork -force

4. Rimuovere tutte le reti di contenitori esistenti in precedenza( ad esempio, elimina vSwitch,

elimina NetNat, pulisce).

PowerShell

Get-NetNat | Remove-NetNat

5. Creare un vSwitch interno denominato nat e una rete NAT con prefisso IP [Link]/24.

PowerShell

New-ContainerNetwork -Name nat -Mode NAT –subnetprefix [Link]/24

6. Rimuovere sia le reti DockerNAT che nat NAT (mantiene i vSwitches interni).

PowerShell

Remove-NetNAT
 7. Creare una rete NAT denominata DockerNAT con prefisso più grande [Link]/17 sia per
D4W che per i contenitori da condividere.

PowerShell

New-NetNat -Name DockerNAT -InternalIPInterfaceAddressPrefix [Link]/17

8. Eseguire Docker4Windows (MobyLinux.ps1)

9. Usare la rete NAT definita dall'utente come impostazione predefinita per connettere i
contenitori di Windows.

PowerShell

Net start docker

Alla fine, si hanno due vSwitches interne, una denominata DockerNAT e l'altra denominata nat.
È disponibile una sola rete NAT ([Link]/17) confermata eseguendo Get-NetNat. Gli indirizzi IP
per i contenitori di Windows vengono assegnati dal servizio di rete host Windows (HNS) dalla
subnet [Link]/24. In base allo script di MobyLinux.ps1 esistente, gli indirizzi IP per Windows
Docker 4 vengono assegnati dalla subnet [Link]/24.

Risoluzione dei problemi

Più reti NAT non sono supportate

Questa guida presuppone che nell'host non siano presenti altre nat. Tuttavia, le applicazioni o i
servizi richiedono l'uso di un NAT e possono crearne uno come parte della configurazione.
Poiché Windows (WinNAT) supporta solo un prefisso di subnet NAT interno, il tentativo di
creare più NAT posiziona il sistema in uno stato sconosciuto.

Per verificare se questo può essere il problema, assicurarsi di avere un solo NAT:

PowerShell

Get-NetNat

Se esiste già un NAT, eliminarlo:

PowerShell

Get-NetNat | Remove-NetNat
Assicurarsi di avere un solo vmSwitch "interno" per l'applicazione o la funzionalità ,ad esempio
i contenitori di Windows. Registrare il nome del vSwitch:

PowerShell

Get-VMSwitch

Controllare se sono presenti indirizzi IP privati ,ad esempio indirizzo IP predefinito NAT, in
genere x.y. z.1) dal vecchio NAT ancora assegnato a una scheda:

PowerShell

Get-NetIPAddress -InterfaceAlias "vEthernet (<name of vSwitch>)"

Se è in uso un indirizzo IP privato precedente, eliminarlo:

PowerShell

Remove-NetIPAddress -InterfaceAlias "vEthernet (<name of vSwitch>)" -IPAddress

<IPAddress>

Rimozione di più NAT Sono stati visualizzati report di più reti NAT create inavvertitamente. Se
vengono visualizzate più reti NAT, dopo l'esecuzione di docker network ls o Get-
ContainerNetwork, eseguire le operazioni seguenti da powerShell con privilegi elevati:

PowerShell

$keys = Get-ChildItem
"HKLM:\SYSTEM\CurrentControlSet\Services\vmsmp\parameters\SwitchList"
foreach($key in $keys)
{
if ($[Link]("FriendlyName") -eq 'nat')
{
$newKeyPath = $KeyPath+"\"+$[Link]
Remove-Item -Path $newKeyPath -Recurse
}
}
Remove-NetNat -Confirm:$false
Get-ContainerNetwork | Remove-ContainerNetwork
Get-VmSwitch -Name nat | Remove-VmSwitch # failure is expected
Stop-Service docker
Set-Service docker -StartupType Disabled

Riavviare il sistema operativo prima di eseguire i comandi successivi ( Restart-Computer )

PowerShell
Get-NetNat | Remove-NetNat
Set-Service docker -StartupType Automatic
Start-Service docker
Importare ed esportare macchine virtuali
14/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Questo articolo illustra come esportare e importare una macchina virtuale, ovvero una
soluzione rapida per spostare o copiare le macchine virtuali. Questo articolo illustra anche
alcune delle scelte da effettuare quando si esegue un'esportazione o un'importazione.

Esportare una macchina virtuale

Un'esportazione raccoglie tutti i file necessari in una unità: file del disco rigido virtuale, file di
configurazione della macchina virtuale ed eventuali file di checkpoint. È possibile eseguire
questo processo in una macchina virtuale nello stato avviato o arrestato.

Hyper-V Manager

Per creare l'esportazione di una macchina virtuale:

1. In Hyper-V Manager fare clic con il pulsante destro del mouse sulla macchina virtuale
e scegliere Esporta.

2. Scegliere dove archiviare i file esportati e fare clic su Esporta.

Al termine dell'esportazione, nel percorso di esportazione saranno visualizzati tutti i file

esportati.

Importare una macchina virtuale

L'importazione di una macchina virtuale esegue la registrazione della macchina virtuale con
l'host di Hyper-V. È possibile importarla nuovamente nell'host o in un nuovo host. Se si esegue
l'importazione nello stesso host, non è necessario esportare prima la macchina virtuale, perché
Hyper-V tenta di ricreare la macchina virtuale dai file disponibili. Durante l'importazione di una
macchina virtuale questa viene registrata affinché sia possibile usarla nell'host Hyper-V.

） Importante

Le configurazioni delle macchine virtuali Hyper-V hanno un numero di versione specifico.

È possibile importare una macchina virtuale solo se l'host Hyper-V supporta tale versione
di configurazione specifica. In genere, ciò significa che è possibile importare una macchina
 virtuale in un host Hyper-V che esegue una versione più recente di Hyper-V, ma non è
possibile importare una macchina virtuale creata in una versione più recente di Hyper-V a
una versione precedente di Hyper-V. Per ulteriori informazioni, vedere configurazione
macchina virtuale supportate.

La procedura guidata Importa macchina virtuale consente anche di correggere le

incompatibilità che possono presentarsi durante lo spostamento da un host a un altro. Si tratta
in genere di differenze nell'hardware fisico, ad esempio memoria, commutatori virtuali e
processori virtuali.

Hyper-V Manager

Per importare una macchina virtuale:

1. Dal menu Azioni in Hyper-V Manager selezionare Importa macchina virtuale.

2. Fare clic su Avanti.

3. Selezionare la cartella contenente i file esportati e selezionare Avanti.

4. Selezionare la macchina virtuale da importare.

5. Scegliere il tipo di importazione e selezionare Avanti. Per le descrizioni, vedere Tipi di

importazione.

6. Selezionare Fine.

Tipi di importazione
In Hyper-V sono disponibili tre tipi di importazione:

Registra sul posto : il tipo di registro sul posto presuppone che i file di esportazione si
trovino nel percorso in cui archiviare ed eseguire la macchina virtuale. La macchina
virtuale importata ha lo stesso ID che aveva al momento dell'esportazione. Per questo
motivo, se la macchina virtuale è già registrata con Hyper-V deve essere eliminata prima
di eseguire l'importazione. Al termine dell'importazione, i file di esportazione diventano i
file di stato di esecuzione e non possono essere rimossi.

Ripristina macchina virtuale: consente di ripristinare la macchina virtuale in un percorso

scelto oppure usare l'impostazione predefinita per Hyper-V. Questo tipo di importazione
crea una copia dei file esportati e li sposta nel percorso selezionato. Quando viene
importata, la macchina virtuale ha lo stesso ID che aveva al momento dell'esportazione.
Per questo motivo, se la macchina virtuale è già in esecuzione in Hyper-V deve essere
eliminata prima dell'importazione. Al termine dell'importazione, i file esportati rimangono
invariati e possono essere rimossi o importati nuovamente.

Copiare la macchina virtuale : il tipo di copia è simile al tipo di ripristino in cui si

seleziona un percorso per i file. La differenza sta nel fatto che la macchina virtuale
importata ha un nuovo ID univoco ed è quindi possibile importarla nello stesso host più
volte.
Configurare gli host per live migration
senza Clustering di Failover
16/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Azure Local 2311.2 and later

La migrazione in tempo reale consente di spostare le macchine virtuali in esecuzione tra server
con tempi di inattività minimi. Questo articolo illustra come configurare gli host non cluster per
la migrazione in tempo reale in Hyper-V, incluse le opzioni di autenticazione, la configurazione
di rete e le procedure consigliate per la sicurezza. Usare questi passaggi se non è stata
configurata la migrazione in tempo reale durante l'installazione di Hyper-V o se è necessario
aggiornare le impostazioni.

Requisiti per configurare la funzionalità live

migration
Per configurare host non cluster per la migrazione in tempo reale, è necessario:

L'appartenenza al gruppo Administrators locale Hyper-V o al gruppo Administrators nei

computer di origine e di destinazione soddisfa questo requisito, a meno che non si stia
configurando la delega vincolata. Per configurare la delega vincolata, è necessaria
l'appartenenza al gruppo Domain Administrators.

Ruolo Hyper-V in Windows Server installato nei server di origine e di destinazione. È

possibile eseguire una migrazione in tempo reale tra host che eseguono Windows Server
2012 R2 e versioni successive. Per istruzioni sull'installazione, vedere Installare il ruolo
Hyper-V in Windows Server.

Computer di origine e di destinazione che appartengono allo stesso dominio di Active

Directory o ai domini che si considerano attendibili tra loro.

Gli strumenti di gestione Hyper-V installati in un computer che esegue almeno Windows
Server 2016 o Windows 10, a meno che gli strumenti non siano installati nel server di
origine o di destinazione ed eseguano gli strumenti dal server.

Prendere in considerazione le opzioni per

l'autenticazione e di rete
Decidere come configurare le opzioni di autenticazione, prestazioni e rete.
 Autenticazione: quale protocollo si usa per autenticare il traffico di migrazione in tempo
reale tra il server di origine e quello di destinazione? Il protocollo scelto determina se è
necessario accedere al server di origine prima di avviare una migrazione in tempo reale:

Kerberos consente di evitare l'accesso al server, ma richiede di configurare la delega

vincolata. Per istruzioni, vedere i dettagli seguenti.

CredSSP consente di evitare di configurare la delega vincolata, ma richiede l'accesso al

server di origine. È possibile farlo tramite una sessione di console locale, una sessione
Desktop remoto o una sessione remota di Windows PowerShell.

CredSSP richiede di accedere per le situazioni che non sono sempre ovvie. Ad esempio,
se si accede a TestServer01 per spostare una macchina virtuale in TestServer02 e quindi
si vuole spostare di nuovo la macchina virtuale in TestServer01, è necessario accedere a
TestServer02 prima di provare a spostare nuovamente la macchina virtuale in
TestServer01. In caso contrario, il tentativo di autenticazione non riesce, si verifica un
errore e viene visualizzato il messaggio seguente:

"Operazione di migrazione di macchina virtuale non riuscita all'origine della

migrazione. Impossibile stabilire una connessione con il nome del computer host:
nessuna credenziale è disponibile nel pacchetto di sicurezza 0x8009030E."

Prestazioni: è necessario configurare le opzioni di prestazioni? Queste opzioni possono

ridurre l'utilizzo della rete e della CPU e velocizzare le migrazioni in tempo reale.
Controllare i requisiti e l'infrastruttura e testare configurazioni diverse per decidere. Le
opzioni sono descritte alla fine del passaggio 2.

Preferenze di rete: si consente il traffico di migrazione in tempo reale attraverso una rete
disponibile o si isola il traffico verso reti specifiche? Come procedura consigliata per la
sicurezza, isolare il traffico su reti private attendibili perché il traffico di migrazione in
tempo reale non viene crittografato quando inviato in rete. È possibile isolare la rete
usando una rete fisicamente isolata o un'altra tecnologia di rete attendibile, ad esempio
VLAN.

Aggiornamento a Windows Server 2025

A partire da Windows Server 2025, Credential Guard è abilitato per impostazione predefinita in
tutti i server aggiunti a un dominio che non sono controller di dominio. Per questo motivo, non
è possibile usare la migrazione in tempo reale basata su CredSSP con Hyper-V dopo
l'aggiornamento a Windows Server 2025. La delega basata su CredSSP è l'impostazione
predefinita per Windows Server 2022 e versioni precedenti per la migrazione in tempo reale.
Usare invece la delega vincolata Kerberos, come descritto nella sezione seguente. Per altre
informazioni, vedere Live Migration with Hyper-V break when upgrade to Windows Server
2025 (Migrazione in tempo reale con interruzioni di Hyper-V durante l'aggiornamento a
Windows Server 2025).

Passaggio 1: Configurare (facoltativa) per la delega

vincolata
Se si decide di usare Kerberos per autenticare il traffico di migrazione in tempo reale,
configurare la delega vincolata usando un account membro del gruppo Domain
Administrators.

Usare lo snap-in Utenti e computer per configurare la delega

vincolata
1. Aprire lo snap-in Utenti e computer di Active Directory. In Server Manager selezionare il
server, quindi selezionare Strumenti>Utenti e computer di Active Directory.

2. Nel riquadro di spostamento in Utenti e computer di Active Directory selezionare il

dominio e quindi fare doppio clic sulla cartella Computer .

3. Nella cartella Computer fare clic con il pulsante destro del mouse sull'account computer
del server di origine e quindi scegliere Proprietà.

4. In Proprietà selezionare la scheda Delega .

5. Nella scheda Delega selezionare Considera attendibile il computer per la delega solo ai
servizi specificati e quindi selezionare Usa qualsiasi protocollo di autenticazione.

6. Seleziona Aggiungi.

7. In Aggiungi servizi selezionare Utenti o computer.

8. Da Seleziona utenti o computer, digitare il nome del server di destinazione. Selezionare

Controlla nomi per verificarlo e quindi selezionare OK.

9. In Aggiungi servizi, nell'elenco dei servizi disponibili, eseguire le operazioni seguenti e

quindi selezionare OK:

Per spostare l'archiviazione delle macchine virtuali, selezionare cifs. Questa

operazione è necessaria se si vuole spostare lo spazio di archiviazione insieme alla
macchina virtuale e se si vuole spostare solo lo spazio di archiviazione di una
macchina virtuale. Se il server è configurato per l'utilizzo dello spazio di
archiviazione SMB per Hyper-V, questa opzione è già selezionata.
 Per spostare macchine virtuali, selezionare Servizio di migrazione sistema virtuale.

10. Nella scheda Delega della finestra di dialogo Proprietà selezionare che i servizi selezionati
nel passaggio precedente siano elencati come servizi a cui il computer di destinazione
può presentare credenziali delegate. Seleziona OK.

11. Nella cartella Computer selezionare l'account computer del server di destinazione e
ripetere il processo. Nella finestra di dialogo Seleziona utenti o computer assicurarsi di
specificare il nome del server di origine.

Le modifiche alla configurazione diventano effettive dopo:

Le modifiche vengono replicate nei controller di dominio a cui vengono connessi i server
che eseguono Hyper-V.
Il controller di dominio rilascia un nuovo ticket Kerberos.

Passaggio 2: Configurare i computer di origine e

destinazione per live migration
Questo passaggio illustra le opzioni per l'autenticazione e la rete. Per una maggiore sicurezza,
selezionare reti specifiche per il traffico di migrazione in tempo reale, come illustrato in
precedenza. In questo passaggio si sceglie anche un'opzione per le prestazioni.

Gestione di Hyper-V consente di configurare i computer di

origine e destinazione per live migration
1. Aprire la console di gestione di Hyper-V. In Server Manager selezionare
Strumenti>Hyper-V Manager.

2. Nel riquadro di spostamento selezionare un server. Se non è elencato, fare clic con il
pulsante destro del mouse su Hyper-V Manager, scegliere Connetti al server, immettere
il nome del server e scegliere OK. Ripetere per aggiungere altri server.

3. Nel riquadro Azione selezionare Hyper-V Impostazioni>migrazioni in tempo reale.

4. Nel riquadro Migrazioni in tempo reale selezionare Abilita migrazioni in tempo reale in
ingresso e in uscita.

5. In Migrazioni in tempo reale simultanee immettere un numero diverso se non si vuole

usare il valore predefinito 2.

6. In Migrazioni in tempo reale in ingresso, se si vogliono usare connessioni di rete

specifiche per accettare il traffico di migrazione in tempo reale, selezionare Aggiungi per
 digitare l'indirizzo IP addr1. Per impostare le opzioni Kerberos e prestazioni, espandere
Migrazioni in tempo reale e selezionare Funzionalità avanzate.

Se si configura la delega vincolata, in Protocollo di autenticazione selezionare

Kerberos.
In Opzioni prestazioni esaminare i dettagli e selezionare un'opzione diversa se si
adatta all'[Link]**, esaminare i dettagli e scegliere un'opzione diversa se è
appropriata per l'ambiente in uso.

7. Seleziona OK.

8. Selezionare l'altro server in Hyper-V Manager e ripetere questi passaggi.

Utilizzare Windows PowerShell per configurare il computer di

origine e destinazione per live migration
È possibile usare tre cmdlet per configurare la migrazione in tempo reale in host non cluster:
Enable-VMMigration, Set-VMMigrationNetwork e Set-VMHost. Questo esempio usa tutti e tre
per:

Configurare la migrazione in tempo reale nell'host locale

Consentire il traffico di migrazione in ingresso solo in una rete specifica
Scegliere Kerberos come protocollo di autenticazione

Ogni riga è un comando separato.

PowerShell

PS C:\> Enable-VMMigration

PS C:\> Set-VMMigrationNetwork [Link]

PS C:\> Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos

Set-VMHost consente anche di scegliere un'opzione di prestazioni e altre impostazioni host. Ad

esempio, per scegliere SMB, ma mantenere il protocollo di autenticazione impostato sul valore
predefinito credSSP, immettere:

PowerShell

PS C:\> Set-VMHost -VirtualMachineMigrationPerformanceOption SMB

La tabella seguente descrive come utilizzare le opzioni di prestazioni.

 ﾉ Espandi la tabella

Option Description

TCP/IP Copia la memoria della macchina virtuale nel server di destinazione tramite una
connessione TCP/IP.

Compression Comprime il contenuto della memoria della macchina virtuale prima della copia nel server
di destinazione tramite una connessione TCP/IP. La compressione è l'impostazione
predefinita .

SMB Copia la memoria della macchina virtuale nel server di destinazione tramite una
connessione SMB 3.0.
- SMB diretto viene usato quando le schede di rete nei server di origine e di destinazione
dispongono dell'accesso remoto diretto alla memoria (RDMA) abilitato.
- SMB multicanale rileva e usa automaticamente più connessioni quando viene
configurata una configurazione SMB multicanale appropriata.
Per altre informazioni, vedere Improve Performance of a File Server with SMB Direct.

Passaggi successivi
Dopo aver configurato gli host, si è pronti per eseguire una migrazione in tempo reale. Per
istruzioni, vedere utilizzare live migration senza Clustering di Failover per spostare una
macchina virtuale.
Aggiornare la versione della macchina
virtuale in Hyper-V in Windows o Windows
Server
16/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Rendere disponibili le funzionalità di Hyper-V più recenti nelle macchine virtuali aggiornando la
versione di configurazione. Non eseguire questa operazione fino a quando:

Aggiornare gli host Hyper-V per la versione più recente di Windows o Windows Server.
Tu aggiorni il livello funzionale del cluster.
Si è certi che non sarà necessario spostare nuovamente la macchina virtuale in un host
Hyper-V che esegue una versione precedente di Windows o Windows Server.

Per ulteriori informazioni, vedere Aggiornamento a rotazione del sistema operativo del cluster
e Eseguire un aggiornamento a rotazione di un cluster host Hyper-V in VMM.

Passaggio 1: Verificare le versioni di configurazione

macchina virtuale
1. Sul desktop di Windows selezionare il pulsante Start e digitare qualsiasi parte del nome
Windows PowerShell.
2. Fare clic con il pulsante destro del mouse su Windows PowerShell e scegliere Esegui
come amministratore.
3. Usare il cmdlet Get-VM. Eseguire il comando seguente per ottenere le versioni delle
macchine virtuali.

PowerShell

Get-VM * | Format-Table Name, Version

È anche possibile visualizzare la versione di configurazione in Hyper-V Manager selezionando

la macchina virtuale e esaminando la scheda Riepilogo .

Passaggio 2: Aggiornare la versione di

configurazione macchina virtuale
 1. Spegnere la macchina virtuale in Hyper-V Manager.
2. Selezionare Azione > Aggiorna versione di configurazione. Se questa opzione non è
disponibile per la macchina virtuale, allora è già alla versione di configurazione più
elevata supportata dall'host Hyper-V.

Per aggiornare la versione di configurazione della macchina virtuale tramite Windows

PowerShell, usare il cmdlet Update-VMVersion . Eseguire il comando seguente dove vmname è
il nome della macchina virtuale.

PowerShell

Update-VMVersion <vmname>

Versioni di configurazione supportate della

macchina virtuale
Usando il cmdlet di PowerShell Get-VMHostSupportedVersion è possibile visualizzare le
versioni di configurazione della macchina virtuale supportate dall'host Hyper-V. Quando si crea
una macchina virtuale, essa è creata con la versione di configurazione predefinita. Per vedere le
versioni di configurazione macchina virtuale supportate dall'host Hyper-V e qual è la versione
predefinita, eseguire il comando seguente.

PowerShell

Get-VMHostSupportedVersion

Se è necessario creare una macchina virtuale che è possibile spostare in un host Hyper-V che
esegue una versione precedente di Windows, usare il cmdlet New-VM con il -Version
parametro . Ad esempio, per creare una macchina virtuale denominata "WindowsCV5" con la
versione di configurazione 5.0, eseguire il comando seguente:

PowerShell

New-VM -Name "WindowsCV5" -Version 5.0

７ Nota

È possibile importare una macchina virtuale solo se l'host Hyper-V supporta tale versione
di configurazione specifica. In genere, questo significa che è possibile importare una
macchina virtuale in un host Hyper-V che esegue una versione più recente di Hyper-V, ma
 non è possibile importare una macchina virtuale creata in una versione più recente di
Hyper-V in una versione precedente di Hyper-V.

Se la versione di configurazione della macchina virtuale non è elencata come supportata

per il sistema operativo dell'host Hyper-V nella tabella seguente, è necessario aggiornare
la versione di configurazione della macchina virtuale a una versione più recente o creare
una nuova macchina virtuale della stessa generazione usando i dischi rigidi virtuali
esistenti prima di poter avviare la macchina virtuale.

Versioni di configurazione delle macchine virtuali supportate

per gli host con Long-Term Servicing.
La tabella seguente elenca le versioni di configurazione delle macchine virtuali per gli host che
eseguono una versione con canale di manutenzione a lungo termine (Long-Term Servicing) di
Windows.

ﾉ Espandi la tabella

Versione di 12.0 11.0 10.0 9.3 9.2 9.1 9.0 8.3 8.2 8.1 8.0 7.1 7.0 6.2 5.0
Windows
dell'host
Hyper-V

Windows ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ❌ ❌ ❌ ❌
Server 2025

Windows 11, ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ❌ ❌ ❌ ❌
versione 24H2

Windows 11, ❌ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ❌ ❌ ❌ ❌
versione 22H2
& 23H2

Windows ❌ ❌ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ❌ ❌ ❌ ❌
Server 2022

Windows 10 ❌ ❌ ❌ ❌ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ❌ ❌ ❌ ❌
Enterprise
LTSC 2021

Windows ❌ ❌ ❌ ❌ ❌ ❌ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Server 2019

Windows 10 ❌ ❌ ❌ ❌ ❌ ❌ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Enterprise
LTSC 2019
 Versione di 12.0 11.0 10.0 9.3 9.2 9.1 9.0 8.3 8.2 8.1 8.0 7.1 7.0 6.2 5.0
Windows
dell'host
Hyper-V

Windows ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ✅ ✅ ✅ ✅ ✅
Server 2016

Windows 10 ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ✅ ✅ ✅ ✅ ✅
Enterprise
2016 LTSB

Windows 10 ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ✅ ✅
Enterprise
2015 LTSB

Windows ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ✅
Server 2012
R2

Windows 8.1 ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ✅

Versioni di configurazione delle macchine virtuali supportate

per gli host con canale semestrale
La tabella seguente elenca le versioni di configurazione delle macchine virtuali per gli host che
eseguono una versione Canale semestrale di Windows. Per altre informazioni sulle versioni del
Semi-Annual Channel di Windows, visitare le pagine seguenti per Windows Server e Windows.

） Importante

Le versioni di Windows Server Semi-Annual Channel sono state ritirate. Per altre
informazioni sulle versioni correnti, vedere Informazioni sulla versione di Windows
Server.

ﾉ Espandi la tabella

Versione di Windows 10.0 9.3 9.2 9.1 9.0 8.3 8.2 8.1 8.0 7.1 7.0 6.2 5.0
dell'host Hyper-V

Windows 11 (versione 21H2) ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ❌ ❌ ❌ ❌

Aggiornamento di Windows ❌ ❌ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ❌ ❌ ❌ ❌
10 - Novembre 2021
(versione 21H2)
Versione di Windows 10.0 9.3 9.2 9.1 9.0 8.3 8.2 8.1 8.0 7.1 7.0 6.2 5.0
dell'host Hyper-V

Aggiornamento di Windows ❌ ❌ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ❌ ❌ ❌ ❌
10 - Maggio 2021 (versione
21H1)

Windows Server, versione ❌ ❌ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ❌ ❌ ❌ ❌

20H2

Aggiornamento di Windows ❌ ❌ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ❌ ❌ ❌ ❌
10 - Ottobre 2020 (versione
20H2)

Windows Server, versione ❌ ❌ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ❌ ❌ ❌ ❌

2004

Aggiornamento di Windows ❌ ❌ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ❌ ❌ ❌ ❌
10 - Maggio 2020 (versione
2004)

Windows Server, versione ❌ ❌ ❌ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅

1909

Aggiornamento di Windows ❌ ❌ ❌ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
10 - Novembre 2019
(versione 1909)

Windows Server, versione ❌ ❌ ❌ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅

1903

Aggiornamento di Windows ❌ ❌ ❌ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
10 - Maggio 2019 (versione
1903)

Windows Server, versione ❌ ❌ ❌ ❌ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅

1809

Aggiornamento di Windows ❌ ❌ ❌ ❌ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
10 di ottobre 2018 (versione
1809)

Windows Server, versione ❌ ❌ ❌ ❌ ❌ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅

1803

Aggiornamento di Windows ❌ ❌ ❌ ❌ ❌ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
10 di aprile 2018 (versione
1803)

Windows 10 Fall Creators ❌ ❌ ❌ ❌ ❌ ❌ ✅ ✅ ✅ ✅ ✅ ✅ ✅

Update (versione 1709)
 Versione di Windows 10.0 9.3 9.2 9.1 9.0 8.3 8.2 8.1 8.0 7.1 7.0 6.2 5.0
dell'host Hyper-V

Windows 10 Creators ❌ ❌ ❌ ❌ ❌ ❌ ❌ ✅ ✅ ✅ ✅ ✅ ✅
Update (versione 1703)

Aggiornamento ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ✅ ✅ ✅ ✅ ✅
dell'anniversario di Windows
10 (versione 1607)

Perché è necessario aggiornare la versione di

configurazione macchina virtuale?
Quando si sposta o si importa una macchina virtuale in un computer che esegue Hyper-V in
Windows Server 2019, Windows Server 2016 o Windows 10, la configurazione della macchina
virtuale non viene aggiornato automaticamente. Ciò significa che è possibile riportare la
macchina virtuale in un host Hyper-V che esegue una versione precedente di Windows o
Windows Server. Tuttavia, ciò significa anche che non è possibile utilizzare alcune delle nuove
funzionalità di macchina virtuale finché non si aggiorna manualmente la versione di
configurazione.

） Importante

Non è possibile effettuare il downgrade di una versione di configurazione macchina

virtuale dopo averla aggiornata.

La versione di configurazione della macchina virtuale rappresenta la compatibilità della

configurazione della macchina virtuale, lo stato salvato e dei file snapshot con la versione di
Hyper-V. Quando si aggiorna la versione di configurazione, si modifica la struttura dei file che
viene utilizzata per archiviare la configurazione di macchine virtuali e i file del checkpoint. È
inoltre possibile aggiornare la versione di configurazione per la versione più recente supportata
dall'host Hyper-V. Le macchine virtuali aggiornate usano un nuovo formato di file di
configurazione progettato per aumentare l'efficienza di lettura e scrittura dei dati di
configurazione della macchina virtuale. L'aggiornamento riduce inoltre il rischio di
danneggiamento dei dati in caso di errore di memoria.

Nella tabella seguente sono elencate le descrizioni delle estensioni dei nomi di file e i percorsi
predefiniti per ogni tipo di file usato per le macchine virtuali nuove o aggiornate.

ﾉ Espandi la tabella
 Tipi di file di Description
macchina virtuale

Configuration Informazioni sulla configurazione di macchina virtuale archiviata in formato

binario.
Estensione del nome file: .vmcx
Percorso predefinito: C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual
Machines

Stato di runtime Informazioni sullo stato di runtime della macchina virtuale archiviate in formato
binario.
Estensione del nome file: .vmrs e .vmgs
Percorso predefinito: C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual
Machines

Disco rigido virtuale Archivia i dischi rigidi virtuali per la macchina virtuale.
Estensione del nome file: .vhd o .vhdx
Percorso predefinito: C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Hard
Disks

Disco rigido virtuale Differenze file su disco utilizzati per i checkpoint della macchina virtuale.
automatico Estensione del nome file: .avhdx
Percorso predefinito: C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Hard
Disks

Checkpoint I checkpoint vengono archiviati in più file di checkpoint. Ogni checkpoint crea un
file di configurazione e file di stato di runtime.
Estensioni di file: .vmrs e .vmcx
Percorso predefinito: C:\ProgramData\Microsoft\Windows\Snapshots

Cosa accade se non aggiornare la versione di

configurazione macchina virtuale?
Se sono presenti macchine virtuali create con una versione precedente di Hyper-V, alcune
funzionalità disponibili nel sistema operativo host più recente potrebbero non funzionare con
tali macchine virtuali finché non si aggiorna la versione di configurazione.

Come indicazioni generali, è consigliabile aggiornare la versione di configurazione dopo aver

aggiornato correttamente gli host di virtualizzazione a una versione più recente di Windows e
assicurarsi di non dover eseguire il rollback. Quando usi la funzionalità di aggiornamento in
sequenza del sistema operativo del cluster , questo avviene tipicamente dopo aver aggiornato
il livello funzionale del cluster. In questo modo, si trarranno vantaggio anche dalle nuove
funzionalità e dalle modifiche interne e dalle ottimizzazioni.

７ Nota
 Una volta aggiornata la versione di configurazione della macchina virtuale, la macchina
virtuale non potrà essere avviata negli host che non supportano la versione di
configurazione aggiornata.

La tabella seguente mostra la versione di configurazione minima della macchina virtuale

richiesta per usare alcune nuove funzionalità di Hyper-V.

ﾉ Espandi la tabella

Feature Versione minima di

configurazione macchina
Virtuale

Partizionamento GPU 12.0

Supporto per ARM64 in Windows 11 11.0

Modalità di compatibilità del processore dinamico 10.0

Virtualizzazione annidata per processori AMD 9.3

Miglioramenti della topologia vNUMA 9.2

Miglioramenti della topologia AMD 9.1

Possibilità di usare funzionalità aggiuntive del processore per PerfMon 9.0

Esporre automaticamente la configurazione di Simultaneous 9.0

Multithreading per le macchine virtuali che operano su host usando il
Core Scheduler

Supporto per l'ibernazione 9.0

Aumentare il numero massimo predefinito per i dispositivi virtuali a 64 8.3

per dispositivo (ad esempio, rete e dispositivi assegnati)

Supporto della sicurezza basata sulla virtualizzazione (VBS) per guest 8.0

Unità di archiviazione delle chiavi 8.0

Macchine virtuali di grandi quantità di memoria 8.0

Virtualizzazione annidata 8.0

Numero di processori virtuali 8.0

Supporto per XSAVE 8.0

Code multiple delle macchine virtuali (Virtual Machine Multi Queues - 7.1
VMMQ)
 Feature Versione minima di
configurazione macchina
Virtuale

Modulo Virtual Trusted Platform (vTPM) 7.0

Aggiunta o rimozione di memoria a caldo 6.2

PowerShell Direct 6.2

Punti di Controllo della Produzione 6.2

Avvio protetto per le macchine virtuali Linux 6.2

Raggruppamento di macchine virtuali 6.2

Per altre informazioni su queste funzionalità, vedere Novità di Hyper-V in Windows Server.
Partizionamento GPU
16/08/2025Si applica a: ✅ Windows Server 2025

Il partizionamento GPU consente di condividere un dispositivo GPU fisico con più macchine
virtuali. Con il partizionamento o la virtualizzazione della GPU, ogni macchina virtuale ottiene
una frazione dedicata della GPU anziché l'intera GPU.

La funzionalità di partizionamento GPU usa l'interfaccia SR-IOV (Single Root IO Virtualization),

che fornisce un limite di sicurezza supportato da hardware con prestazioni prevedibili per ogni
macchina virtuale. Ogni macchina virtuale può accedere solo alle risorse GPU a essa dedicate e
il partizionamento hardware sicuro impedisce l'accesso non autorizzato da altre macchine
virtuali.

A partire da Windows Server 2025, la migrazione in tempo reale è supportata con il

partizionamento GPU, consentendo una maggiore flessibilità per la gestione delle macchine
virtuali. Per usare la migrazione in tempo reale con il partizionamento GPU, assicurarsi che la
configurazione soddisfi i requisiti descritti in questo articolo. La migrazione in tempo reale
consente di spostare macchine virtuali tra host senza tempi di inattività, essenziali per la
manutenzione e il bilanciamento del carico in un ambiente di produzione.

Questa funzionalità consente migrazioni di macchine virtuali pianificate mantenendo

l'allocazione delle risorse GPU, garantendo tempi di inattività minimi e prestazioni coerenti.

Il partizionamento della GPU è progettato per i server autonomi. È possibile eseguire la

migrazione in tempo reale di macchine virtuali tra nodi autonomi per tempi di inattività
pianificati; tuttavia, i clienti che richiedono il clustering per tempi di inattività non pianificati
devono usare Windows Server 2025 Datacenter.

Quando usare il partizionamento GPU

Alcuni carichi di lavoro, ad esempio l'infrastruttura VDI (Virtual Desktop Infrastructure),
l'intelligenza artificiale e l'inferenza con Machine Learning (ML) richiedono l'accelerazione GPU
e il partizionamento GPU può contribuire a ridurre il costo totale di proprietà per
l'infrastruttura nel suo complesso.

Per esempio:

Applicazioni VDI: i clienti su perimetro distribuito eseguono app di produttività di base,

ad esempio Microsoft Office e carichi di lavoro di visualizzazione con uso intensivo di
grafica negli ambienti VDI, che richiedono accelerazione GPU. Per questi carichi di lavoro,
è possibile ottenere l'accelerazione GPU necessaria tramite il partizionamento DDA o
GPU. Con il partizionamento GPU è possibile creare più partizioni e assegnare ogni
 partizione a una macchina virtuale che ospita un ambiente VDI. Il partizionamento GPU
consente di ottenere la densità desiderata e di ridimensionare il numero di utenti
supportati in base a un ordine di grandezza.

Inferenza con Machine Learning: i clienti nei punti vendita al dettaglio e negli stabilimenti
di produzione possono eseguire l'inferenza a livello perimetrale, che richiede il supporto
GPU per i server. Usando la GPU nei server, è possibile eseguire modelli di Machine
Learning per ottenere risultati rapidi su cui è possibile agire prima che i dati vengano
inviati al cloud. Il set di dati completo può essere facoltativamente trasferito per
continuare a ripetere il training dei modelli di Machine Learning e migliorarli. Oltre a DDA,
in cui si dedica un'intera GPU fisica a una macchina virtuale, il partizionamento GPU
consente di eseguire più applicazioni di inferenza contemporaneamente sulla stessa GPU,
ma in partizioni hardware separate, ottimizzando l'utilizzo della GPU.

Requirements
Per usare il partizionamento GPU con la migrazione in tempo reale, è necessario avere una
CPU, un sistema operativo e una GPU supportati. Le sezioni seguenti descrivono i requisiti.

Requisiti della CPU

Gli host del cluster devono essere dotati di processori capaci di rilevare i bit DMA tramite
l'unità di gestione della memoria input/output (IOMMU). Ad esempio, i processori che
supportano Intel VT-D o AMD-Vi. Se si usa Windows Server e la migrazione in tempo reale
senza processori abilitati per IOMMU, le VM vengono riavviate automaticamente in posizioni in
cui sono disponibili le risorse GPU.

Esempi di processori che supportano il rilevamento dei bit IOMMU DMA includono:

AMD EPYC 7002 e versioni successive (Milano)

4a generazione Intel Xeon SP (Zaffiro Rapids)

Sistemi operativi guest supportati

Il partizionamento della GPU in Windows Server 2025 e versioni successive supporta i seguenti
sistemi operativi guest:

Windows 10 o versione successiva

Windows 10 Enterprise multisessione o versioni successive
Windows Server 2019 o versione successiva
Linux Ubuntu 18.04 LTS, Linux Ubuntu 20.04 LTS, Linux Ubuntu 22.04 LTS
GPU supportate
Le GPU seguenti supportano il partizionamento GPU:

NVIDIA A2
NVIDIA A10
NVIDIA A16
NVIDIA A40
NVIDIA L2
NVIDIA L4
NVIDIA L40
NVIDIA L40S

Per usare la migrazione in tempo reale con il partizionamento GPU, è necessario usare il driver
incluso nel software NVIDIA vGPU v18.x o versione successiva. Il driver NVIDIA fornisce il
supporto necessario per il partizionamento gpu e le funzionalità di migrazione in tempo reale.

È consigliabile collaborare con i partner OEM (Original Equipment Manufacturer) per pianificare
e ordinare i sistemi personalizzati per i carichi di lavoro. Consultare anche i fornitori di
hardware indipendenti dalla GPU (IHD) per assicurarsi di disporre delle configurazioni
appropriate e del software necessario per la configurazione. Tuttavia, supportiamo altre GPU se
si vuole usare l'accelerazione GPU tramite DDA (Discrete Device Assignment). Contattare i
partner OEM e i fornitori di hardware indipendenti per ottenere un elenco delle GPU che
supportano DDA. Per altre informazioni sull'uso dell'accelerazione GPU tramite DDA, vedere
Discrete Device Assignment (DDA).

Per ottenere prestazioni ottimali, è consigliabile creare una configurazione omogenea per le
GPU in tutti i server del cluster. Una configurazione omogenea consiste nell'installare GPU di
marca e modello identici e nel configurare lo stesso numero di partizioni nelle GPU in tutti i
server del cluster. Ad esempio, in un cluster di due server con una o più GPU installate, tutte le
GPU devono essere di marca, modello e dimensioni identici. Anche il numero di partizioni in
ogni GPU deve corrispondere.

Limitations
Quando si usa la funzionalità di partizionamento GPU, considerare le limitazioni seguenti:

Il partizionamento GPU non è supportato se la configurazione non è omogenea. Di

seguito sono riportati alcuni esempi di configurazioni non supportate:

Combinazione di GPU di fornitori diversi nello stesso cluster.

 Uso di modelli di GPU diversi di famiglie di prodotti diverse dello stesso fornitore nello
stesso cluster.

Non è possibile assegnare una GPU fisica come GPU partizionabile o DDA (Discrete
Device Assignment). È possibile assegnarla come DDA o come GPU partizionabile, ma non
come tutte e due.

Se si assegnano più partizioni GPU a una macchina virtuale, ogni partizione viene
visualizzata come un'altra GPU.

Le partizioni vengono assegnate automaticamente alle VM. Non è possibile scegliere una
partizione specifica per una macchina virtuale specifica.

È possibile partizionare la GPU usando Windows Admin Center o PowerShell. È

consigliabile usare Windows Admin Center per configurare e assegnare partizioni GPU.
Windows Admin Center convalida automaticamente una configurazione omogenea delle
GPU in tutti i server del cluster. Fornisce avvisi ed errori appropriati per eseguire le azioni
correttive necessarie.

Se si usa PowerShell per abilitare il partizionamento GPU, è necessario eseguire gli stessi
passaggi di configurazione in ogni server del cluster. È necessario assicurarsi
manualmente che la configurazione omogenea venga mantenuta per le GPU in tutti i
server del cluster.

Quando si esegue la migrazione in tempo reale di una macchina virtuale con una
partizione GPU assegnata, la migrazione in tempo reale di Hyper-V passa
automaticamente all'uso di TCP/IP con compressione. La migrazione di una macchina
virtuale ha come effetto potenziale l'aumento dell'uso della CPU di un host. Inoltre, le
migrazioni in tempo reale potrebbero richiedere più tempo rispetto alle macchine virtuali
senza partizioni GPU collegate.

Contenuti correlati
Per altre informazioni sull'uso di GPU con le macchine virtuali e il partizionamento GPU, vedere:

Partizionare e assegnare GPU a una macchina virtuale

Usare GPU con macchine virtuali cluster
Partizionare e assegnare GPU a una
macchina virtuale
14/08/2025Si applica a: ✅ Windows Server 2025

Questo articolo descrive come configurare le partizioni delle unità di elaborazione grafica
(GPU) e come assegnare una partizione a una macchina virtuale. Fornisce istruzioni su come
configurare il numero di partizioni GPU, assegnare partizioni GPU e annullare l'assegnazione di
partizioni GPU tramite Windows Admin Center e PowerShell.

Per eseguire il provisioning della funzionalità di partizionamento GPU, occorre completare i

passaggi seguenti:

Completare tutti i prerequisiti.

Verificare l'installazione del driver GPU.
Configurare il numero di partizioni.
Assegnare la partizione GPU a una macchina virtuale.
Se necessario, annullare l'assegnazione di una partizione GPU da una macchina virtuale.

Prerequisites
Prima di iniziare a usare la funzionalità di partizionamento GPU, è necessario tenere conto di
diversi aspetti e requisiti:

Prerequisiti per il server host

È necessario disporre di Windows Server 2025 installato nel server host. Se il clustering è
obbligatorio durante la migrazione in tempo reale di un host di macchine virtuali, è
necessario installare Windows Server 2025 Datacenter.

Ruolo Hyper-V installato e configurato sul server. Vedere Installare il ruolo Hyper-V in
Windows Server per scoprire come iniziare.

Installare il dispositivo GPU fisico di marca, modello e dimensioni identici in ogni server
del cluster. Fare riferimento alla documentazione fornita dal partner OEM per installare il
dispositivo GPU nei server fisici del cluster.

Installare i driver GPU in ogni server del cluster seguendo le istruzioni fornite dai fornitori
di hardware indipendenti di GPU. Per i driver GPU NVIDIA, vedere la documentazione di
vGPU NVIDIA .
 Assicurarsi che il supporto della virtualizzazione e SR-IOV siano abilitati nel BIOS di ogni
server del cluster. Contattare il fornitore del sistema se non si è in grado di identificare
l'impostazione corretta nel BIOS.

Gli host del cluster devono disporre di processori in grado di supportare il tracciamento
dei bit DMA dell'unità di gestione della memoria di input/output (IOMMU). Ad esempio, i
processori che supportano Intel VT-D o AMD-Vi.

７ Nota

Quando si esegue la migrazione in tempo reale di una macchina virtuale con una
partizione GPU assegnata, la migrazione in tempo reale di Hyper-V passerà
automaticamente all'uso di TCP/IP con compressione. Questo ha il potenziale effetto di
aumentare l'utilizzo della CPU di un host. Inoltre, le migrazioni in tempo reale potrebbero
richiedere più tempo rispetto alle macchine virtuali senza partizioni GPU collegate.

Prerequisiti per le macchine virtuali

Distribuire una macchina virtuale usando un sistema operativo guest dall'elenco Sistemi
operativi guest supportati.

Installare i driver GPU nella macchina virtuale seguendo le istruzioni dei fornitori di
hardware indipendenti di GPU. Per i driver GPU NVIDIA, vedere la documentazione di
vGPU NVIDIA .

Prerequisiti per Windows Admin Center

Se si usa Windows Admin Center per eseguire il provisioning del partizionamento GPU, è
necessario installare la versione più recente di Windows Admin Center con l'estensione GPU,
versione 2.8.0 o successive. Per istruzioni su come installare le estensioni GPU in Windows
Admin Center, vedi Installazione di un'estensione.

Dopo aver installato l'estensione, viene visualizzata nella scheda Estensioni installate , come
illustrato nello screenshot seguente. Assicurarsi che la versione dell'estensione GPU sia 2.8.0 o
successiva.
 

Prerequisiti per PowerShell

Se si usa PowerShell per eseguire il provisioning del partizionamento GPU, è necessario
eseguire tutti i comandi di PowerShell come utente amministratore.

Per informazioni dettagliate su come usare i comandi di PowerShell per il partizionamento

GPU, vedere la documentazione di riferimento add-VMGpuPartitionAdapter, Get-
VMGpuPartitionAdapter e Remove-VMGpuPartitionAdapter .

Verificare l'installazione del driver GPU

Dopo aver completato tutti i prerequisiti, è necessario verificare se il driver GPU è installato e
partizionabile.

Windows Admin Center

Seguire questa procedura per verificare se il driver GPU è installato e partizionabile usando
Windows Admin Center:

1. Avviare Windows Admin Center e assicurarsi che l'estensione GPU sia già installata.

2. Selezionare Cluster Manager dal menu a discesa in alto e connettersi al cluster.

3. Dal menu Impostazioni selezionareGPU>.

La scheda GPU nella pagina GPU visualizza l'inventario di tutti i server e le GPU
fisiche installate in ogni server.
 4. Controllare la colonna Stato assegnato per ogni GPU per tutti i server. La colonna
Stato assegnato può avere uno di questi stati:

Pronto per l'assegnazione DDA. Indica che la GPU è disponibile per

l'assegnazione DDA. Non è possibile usarlo per il partizionamento GPU.

Partitioned. Indica che la GPU è partizionabile.

Paravirtualization. Indica che la GPU dispone della funzionalità del driver

partizionato installata, ma SR-IOV nel server non è abilitato.

Non assegnabile. Indica che la GPU non è assegnabile perché è un dispositivo

di tipo PCI o una porta switch datata.

5. Continuare ulteriormente nel flusso di lavoro di partizionamento GPU solo se la

colonna Stato assegnato mostra Partizionato per le GPU in tutti i server del cluster.

Configurare il numero di partizioni GPU

Ogni GPU partizionabile include un set di numeri di partizioni validi predefiniti dal partner
OEM. Non è possibile definire il numero di partizioni che può avere una GPU. Tuttavia, è
possibile configurare il numero di partizioni su uno qualsiasi dei numeri validi dall'interno del
set supportato.

Windows Admin Center

Seguire questa procedura per configurare il numero di partizioni tramite Windows Admin
Center:
1. Selezionare la scheda Partizioni GPU per configurare i conteggi delle partizioni. È
anche possibile assegnare la partizione alle macchine virtuali e annullare
l'assegnazione delle partizioni dalle macchine virtuali usando questa scheda.

７ Nota

Se nel cluster non sono disponibili GPU partizionabili o se il driver di

partizionamento GPU corretto non è installato, la scheda Partizioni GPU mostra
il messaggio seguente:

Non sono state trovate GPU partizionabili. Assicurarsi di disporre di una GPU con
il driver GPU-P corretto per continuare.

2. Selezionare una GPU o una partizione GPU per mostrarne i dettagli nella sezione
inferiore della pagina, in Dettagli elemento selezionato. Ad esempio, se si seleziona
una GPU, vengono visualizzati il nome della GPU, l'ID GPU, il codificatore e il
decodificatore disponibili, la VRAM disponibile, il numero di partizioni valido e il
numero di partizioni corrente. Se si seleziona una partizione GPU, vengono
visualizzati l'ID partizione, l'ID macchina virtuale, il percorso dell'istanza, la VRAM
della partizione, il codificatore e il decodificatore della partizione.

3. Selezionare Configurare il numero di partizioni.

Viene visualizzata la pagina Configurare il numero di partizioni nelle GPU. Per ogni
server vengono visualizzati i dispositivi GPU installati su di essi.

4. Selezionare un set di GPU omogenee. Un set di GPU omogenee è quello con GPU di
dimensioni, produttore, numero di modello e numero di partizioni identici. Per
impostazione predefinita, Windows Admin Center seleziona automaticamente un set
di GPU omogenee se ne rileva uno, come illustrato nello screenshot seguente:

È possibile che venga visualizzato un avviso o un errore, a seconda delle selezioni

effettuate:

Warning. Se si deseleziona una o più GPU dal set omogeneo di GPU, Windows
Admin Center visualizza un avviso, ma non impedisce di procedere. Il testo
dell'avviso indica che non si stanno selezionando tutte le GPU e che il numero
di partizioni potrebbe essere diverso (non consigliabile).

Warning. Se non tutte le GPU in tutti i server hanno la stessa configurazione,

Windows Admin Center genera un avviso. È necessario selezionare
manualmente le GPU con la stessa configurazione per continuare.


 Error. Se si selezionano GPU con configurazioni diverse, Windows Admin Center
restituisce un errore e non consente di procedere.

Error. Se si seleziona una partizione GPU già assegnata a una macchina virtuale,
Windows Admin Center restituisce un errore e non consente di procedere.
Prima di continuare, è necessario annullare l'assegnazione della partizione dalla
macchina virtuale. Vedere Annullare l'assegnazione di una partizione da una
macchina virtuale.

5. Dopo aver selezionato un set omogeneo di GPU, selezionare il numero di partizioni

dall'elenco a discesa Numero di partizioni. Questo elenco popola automaticamente i
numeri di partizioni configurati dal produttore di GPU. I numeri visualizzati
nell'elenco possono variare a seconda del tipo di GPU selezionato.

Non appena si seleziona un numero di partizioni diverso, viene visualizzata una

descrizione comando sotto l'elenco a discesa, che visualizza in modo dinamico le
dimensioni della VRAM che ottiene ogni partizione. Ad esempio, se la VRAM totale è
di 16 GB per 16 partizioni nella GPU, la modifica del numero di partizioni da 16 a 8
assegna a ogni partizione 1,85 GB di VRAM.

6. Selezionare Configurare il numero di partizioni.

Dopo aver configurato il numero di partizioni, Windows Admin Center notifica che il
conteggio delle partizioni è stato configurato correttamente e visualizza nuovamente
 la scheda partizioni GPU . È possibile visualizzare il nuovo numero di partizioni per la
partizione GPU nella colonna Conteggio partizioni .

Assegnare la partizione GPU a una macchina

virtuale
Salvare i carichi di lavoro prima di assegnare la partizione alla macchina virtuale.

７ Nota

Attualmente, è possibile assegnare una sola partizione GPU a una macchina virtuale. Sia la
macchina virtuale sia la partizione GPU devono trovarsi nello stesso computer host. È
consigliabile pianificare in anticipo e determinare le dimensioni della partizione GPU in
base ai requisiti di prestazioni del carico di lavoro.

Windows Admin Center

È necessario salvare i carichi di lavoro prima di assegnare le partizioni. Se la macchina

virtuale è attualmente attivata o in esecuzione, Windows Admin Center la disattiva
automaticamente, assegna la partizione, quindi la riattiva automaticamente.

1. Nella scheda Partizioni GPU selezionare + Assegna partizione.

Viene visualizzata la pagina Assegna partizione GPU alla macchina virtuale.

2. Nell'elenco Scegliere il server selezionare il server in cui risiede la macchina virtuale.
Questo elenco mostra tutti i server nel cluster.

3. Cercare e selezionare la macchina virtuale a cui assegnare la partizione GPU. L'elenco

popola automaticamente le macchine virtuali che risiedono nel server selezionato nel
passaggio 2.

Se una partizione GPU è già assegnata a una macchina virtuale, quella macchina
virtuale non è selezionabile.

Selezionare tutte le macchine virtuali contemporaneamente selezionando la

casella di controllo Seleziona tutto .

4. Selezionare le opzioni VRAM disponibili. Il valore in questo campo deve

corrispondere al numero di partizioni configurato.

5. (Facoltativo, ma consigliato) Selezionare la casella di controllo Configura azione

offline per forzare l'arresto se si vuole che la macchina virtuale sia altamente
disponibile ed esegua il failover se il server host è inattivo.

6. Selezionare Assegna partizione. La partizione delle dimensioni VRAM selezionate

viene assegnata alla macchina virtuale selezionata nel server host selezionato.

Dopo l'assegnazione della partizione, Windows Admin Center notifica che la

partizione è stata assegnata correttamente e visualizza nuovamente la scheda
partizioni GPU . Nella scheda Partizioni GPU la macchina virtuale viene visualizzata
nella riga della partizione GPU nel server in cui è installato.
Annullare l'assegnazione di una partizione da una
macchina virtuale
È possibile annullare l'assegnazione di una partizione GPU dalla macchina virtuale se non è più
necessaria per eseguire i carichi di lavoro. L'annullamento della partizione consente di liberare
la risorsa di partizione GPU, che sarà possibile riassegnare in seguito a un'altra macchina
virtuale.

È necessario salvare i carichi di lavoro prima di annullare l'assegnazione di partizioni.

Windows Admin Center

Se la macchina virtuale è attivata o in esecuzione, Windows Admin Center la disattiva

automaticamente, annulla l'assegnazione della partizione, quindi la riattiva
automaticamente.

Seguire questa procedura per annullare l'assegnazione di una partizione da una macchina
virtuale:

1. Nella scheda Partizioni GPU selezionare la partizione GPU da annullare.

2. Selezionare - Annulla assegnazione partizione.

Viene visualizzata la pagina Annulla assegnazione partizione GPU dalla macchina

virtuale.

3. Nell'elenco Scegliere il server selezionare il server con la partizione GPU di cui si

desidera annullare l'assegnazione.
4. Nell'elenco Scegliere la macchina virtuale da cui annullare l'assegnazione della
partizione cercare o selezionare la VM da cui annullare l'assegnazione della
partizione.

5. Selezionare Annulla assegnazione partizione.

Dopo che la partizione non è stata assegnata, Windows Admin Center notifica che la
partizione non è stata assegnata correttamente e visualizza nuovamente la scheda
partizioni GPU . Nella scheda Partizioni GPU la macchina virtuale da cui la partizione
non viene più assegnata non viene più visualizzata nella riga della partizione GPU.
Distribuire dispositivi grafici usando
l'assegnazione di dispositivi discreti
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Azure Local 2311.2 and later

Informazioni su come usare l'assegnazione di dispositivi discreti (DDA) con PowerShell per
passare un intero dispositivo PCIe in una macchina virtuale (VM) su host standalone Hyper-V
(non cluster). In questo modo è possibile accedere ad alte prestazioni ai dispositivi come
l'archiviazione NVMe o le schede grafiche dall'interno di una macchina virtuale, pur essendo in
grado di applicare i driver nativi del dispositivo. Per altre informazioni sui dispositivi che
funzionano e sulle possibili implicazioni per la sicurezza, vedere Pianificare la distribuzione di
dispositivi tramite l'assegnazione di dispositivi discreti.

Questo articolo illustra i passaggi per usare un dispositivo con DDA:

1. Configurare la macchina virtuale per DDA

2. Smontare il dispositivo dalla partizione host
3. Assegnare il dispositivo alla macchina virtuale guest

） Importante

Distribuzione di dispositivi grafici in macchine virtuali in cluster Informazioni sull'uso di

DDA con pool di GPU in ambienti in cluster. Vedere Usare GPU con l'assegnazione di
dispositivi discreti nelle macchine virtuali in cluster.

Prerequisites
Prima di poter usare DDA per distribuire i dispositivi grafici, è necessario disporre degli
elementi seguenti.

Host Hyper-V che esegue Windows Server 2016 o versione successiva.

Una macchina virtuale che esegue uno dei sistemi operativi seguenti:

Windows Server 2016 o versione successiva.

Windows 10 o versione successiva.

Consultare Piano di distribuzione dei dispositivi usando l'assegnazione di dispositivi

discreti per verificare che l'hardware sia compatibile con DDA.
 Eseguire il SurveyDDA.ps1. Script di PowerShell per identificare se il server è
configurato correttamente. Lo script visualizza anche i dispositivi che possono essere
passati tramite l'assegnazione di dispositivi discreti.

Diritti amministrativi per l'host Hyper-V.

(Facoltativo) Anche se non è necessario, se la virtualizzazione I/O radice singola (SR-IOV)

non è abilitata o supportata, è possibile che si verifichino problemi quando si usa DDA
per distribuire i dispositivi grafici.

Configurare la macchina virtuale per la DDA

Il primo passaggio della soluzione consiste nell'affrontare le restrizioni di DDA per le macchine
virtuali.

1. Effettua l'accesso all'host Hyper-V come amministratore.

2. Aprire un prompt di PowerShell con privilegi elevati.

3. Configurare Automatic Stop Action di una macchina virtuale per consentire TurnOff con il
cmdlet PowerShell seguente:

PowerShell
Set-VM -Name VMName -AutomaticStopAction TurnOff

Preparazione delle macchine virtuali per i dispositivi grafici

Alcuni hardware offrono prestazioni migliori se la macchina virtuale è configurata in un certo
modo. Per informazioni dettagliate sul fatto che siano necessarie le configurazioni seguenti per
l'hardware, contattare il fornitore dell'hardware. Per altre informazioni, vedere Pianificare la
distribuzione di dispositivi usando l'assegnazione di dispositivi discreti e in questo post di
blog .

1. Abilitare Write-Combining nella CPU usando il cmdlet seguente:

PowerShell

Set-VM -GuestControlledCacheTypes $true -VMName VMName

2. Configurare lo spazio I/O (MMIO) di memoria a 32 bit utilizzando il seguente comando:

PowerShell
 Set-VM -LowMemoryMappedIoSpace 3Gb -VMName VMName

3. Configurare uno spazio MMIO maggiore di 32 bit usando il cmdlet seguente:

PowerShell
Set-VM -HighMemoryMappedIoSpace 33280Mb -VMName VMName

 Suggerimento

I valori dello spazio MMIO visualizzati sono valori ragionevoli da impostare per
l'esperimento con una singola GPU. Se dopo l'avvio della macchina virtuale il
dispositivo segnala un errore relativo a risorse non sufficienti, sarà probabilmente
necessario modificare questi valori. Per altre informazioni su come calcolare con
precisione i requisiti di MMIO, vedere Pianificare la distribuzione di dispositivi
tramite l'assegnazione di dispositivi discreti.

Smontare il dispositivo dalla partizione host

Seguire le istruzioni riportate in questa sezione per smontare il dispositivo dalla partizione
host.

Installare il driver di partizionamento (facoltativo)

DDA offre ai fornitori di hardware la possibilità di fornire un driver di mitigazione della
sicurezza con i propri dispositivi. Questo driver non corrisponde al driver di dispositivo
installato nella macchina virtuale guest. Spetta alla discrezione del fornitore di hardware fornire
questo driver. Tuttavia, se forniscono un driver, installarlo prima di smontare il dispositivo dalla
partizione host. Contattare il fornitore dell'hardware per verificare se ha un driver di
mitigazione.

Se non viene fornito alcun driver di partizionamento, durante lo smontaggio è necessario usare
l'opzione -Force per ignorare l'avviso di sicurezza. Per altre informazioni sulle implicazioni
relative alla sicurezza, vedere Pianificare la distribuzione di dispositivi tramite l'assegnazione di
dispositivi discreti.

Individuare il percorso del dispositivo

Il percorso della posizione PCI è necessario per smontare e montare il dispositivo dal host. Un
percorso di esempio è simile al seguente:
PCIROOT(20)#PCI(0300)#PCI(0000)#PCI(0800)#PCI(0000) . Per altre informazioni

sull'individuazione del percorso, vedere Pianificare la distribuzione di dispositivi tramite

l'assegnazione di dispositivi discreti.

Disabilitare il dispositivo
Usare Gestione dispositivi o PowerShell per assicurarsi che il dispositivo sia Disabilitato.

Smontare il dispositivo
A seconda che il fornitore abbia fornito un driver di mitigazione, è necessario usare o meno
l'opzione -Force , come illustrato di seguito:

Se è stato installato un driver di mitigazione, usare il cmdlet seguente:

PowerShell
Dismount-VMHostAssignableDevice -LocationPath $locationPath

Se non è stato installato un driver di mitigazione, usare il cmdlet seguente:

PowerShell
Dismount-VMHostAssignableDevice -Force -LocationPath $locationPath

Assegnare il dispositivo alla macchina virtuale

guest
Il passaggio finale consiste nell'indicare a Hyper-V che una macchina virtuale deve avere
accesso al dispositivo. Specificare il percorso e il nome della macchina virtuale.

PowerShell
Add-VMAssignableDevice -LocationPath $locationPath -VMName VMName

Completare le attività nella macchina virtuale

Dopo che un dispositivo è stato montato correttamente in una macchina virtuale, è ora
possibile avviare la macchina virtuale e interagire con il dispositivo come se fosse in esecuzione
in un sistema bare metal. È ora possibile installare i driver del fornitore di hardware nella
macchina virtuale e le applicazioni sono in grado di visualizzare l'hardware. È possibile
verificarlo aprendo Gestione dispositivi nella macchina virtuale guest e verificando che
l'hardware sia disponibile.

Rimuovere un dispositivo e restituirlo all'host

Se si vuole ripristinare lo stato originale del dispositivo, è necessario arrestare la macchina
virtuale ed eseguire questo comando:

PowerShell

# Remove the device from the VM

Remove-VMAssignableDevice -LocationPath $locationPath -VMName VMName

# Mount the device back in the host

Mount-VMHostAssignableDevice -LocationPath $locationPath

È quindi possibile riabilitare il dispositivo in Gestione dispositivi e il sistema operativo host è in

grado di interagire di nuovo con il dispositivo.

Esempio: montare una GPU in una macchina

virtuale
Questo esempio usa PowerShell per configurare una macchina virtuale denominata ddatest1
per prendere la prima GPU disponibile dal produttore NVIDIA e assegnarla alla macchina
virtuale.

PowerShell
# Configure the VM for a Discrete Device Assignment
$vm = "ddatest1"
# Set automatic stop action to TurnOff
Set-VM -Name $vm -AutomaticStopAction TurnOff
# Enable Write-Combining on the CPU
Set-VM -GuestControlledCacheTypes $true -VMName $vm
# Configure 32 bit MMIO space
Set-VM -LowMemoryMappedIoSpace 3Gb -VMName $vm
# Configure Greater than 32 bit MMIO space
Set-VM -HighMemoryMappedIoSpace 33280Mb -VMName $vm

# Find the Location Path and disable the Device

# Enumerate all PNP Devices on the system
$pnpdevs = Get-PnpDevice -presentOnly
# Select only those devices that are Display devices manufactured by NVIDIA
$gpudevs = $pnpdevs | Where-Object {$_.Class -like "Display" -and $_.Manufacturer -
like "NVIDIA"}
# Select the location path of the first device that's available to be dismounted by
 the host.
$locationPath = ($gpudevs | Get-PnpDeviceProperty
DEVPKEY_Device_LocationPaths).data[0]
# Disable the PNP Device
Disable-PnpDevice -InstanceId $gpudevs[0].InstanceId

# Dismount the Device from the Host

Dismount-VMHostAssignableDevice -Force -LocationPath $locationPath

# Assign the device to the guest VM.

Add-VMAssignableDevice -LocationPath $locationPath -VMName $vm

Risolvere i problemi relativi al montaggio di una GPU

Se passi una GPU in una macchina virtuale ma Servizi Desktop Remoto o un'applicazione non
riconosce la GPU, verifica i seguenti problemi comuni.

Assicurarsi di installare la versione più recente del driver supportato dal fornitore della
GPU e che il driver non segnali errori. È possibile farlo controllando lo stato del
dispositivo in Gestione dispositivi.

Assicurarsi che il dispositivo disponga di spazio MMIO sufficiente allocato all'interno della
macchina virtuale. Per altre informazioni, vedere SPAZIO MMIO.

Assicurarsi di usare una GPU supportata dal fornitore in questa configurazione. Ad

esempio, alcuni fornitori impediscono il funzionamento delle schede consumer quando
vengono passate a una macchina virtuale.

Assicurarsi che l'applicazione supporti l'esecuzione all'interno di una macchina virtuale e

che l'applicazione supporti sia la GPU che i driver associati. Alcune applicazioni hanno
elenchi consentiti di GPU e ambienti.

Se si usa il ruolo Host sessione Desktop remoto o Servizi Multipoint Windows nel guest, è
necessario assicurarsi che sia impostata una voce di Criteri di gruppo specifica per
consentire l'uso della GPU predefinita. Utilizzare un oggetto Criteri di gruppo applicato
all'ospite (o all'Editor Criteri di gruppo locali sull'ospite). Passare all'elemento Criteri di
gruppo seguente:

Configurazione computer\Modelli amministratore\Componenti di Windows\Servizi

Desktop remoto\Host sessione Desktop remoto\Ambiente sessione remota\Usa schede
grafiche hardware per tutte le sessioni di Servizi Desktop remoto.

Impostare il valore di Criteri di gruppo su Abilitato, quindi riavviare la macchina virtuale

dopo aver applicato i criteri.
Last updated on 30/01/2026
Distribuire dispositivi di archiviazione
NVMe usando l'assegnazione di dispositivi
discreti
Articolo • 30/04/2025 •
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Azure Local 2311.2 and later

A partire da Windows Server 2016, è possibile usare l'assegnazione di dispositivi discreti o DDA
per passare un intero dispositivo PCIe in una macchina virtuale. Questo renderà possibile
l'accesso con prestazioni elevate ai dispositivi come l'archiviazione NVMe o le schede grafiche
dall'interno di una macchina virtuale, pur essendo in grado di sfruttare i driver nativi dei
dispositivi. Per altre informazioni su quali dispositivi funzionano, quali sono le possibili
implicazioni per la sicurezza e così via, visitare il piano per la distribuzione di dispositivi usando
l'assegnazione di dispositivi discreti . L'uso di un dispositivo con DDA prevede tre passaggi:

Configurare la macchina virtuale per la DDA

Smontare il dispositivo dalla partizione host
Assegnare il dispositivo alla macchina virtuale guest

Tutti i comandi possono essere eseguiti dall'host in una console di Windows PowerShell come
amministratore.

Configurare la macchina virtuale per la DDA

L'assegnazione di dispositivi discreta impone alcune restrizioni alle macchine virtuali e occorre
eseguire il passaggio seguente.

1. Configurare l'azione di arresto automatico di una macchina virtuale su TurnOff

eseguendo

Set-VM -Name VMName -AutomaticStopAction TurnOff

Smontare il dispositivo dalla partizione host

Individuare il percorso del dispositivo

Il percorso PCI è necessario per smontare e montare il dispositivo dall'host. Un percorso di
esempio è simile al seguente: "PCIROOT(20)#PCI(0300)#PCI(0000)#PCI(0800)#PCI(0000)" .
Ulteriori dettagli sulla localizzazione del percorso di posizione sono disponibili qui: Piano per la
distribuzione di dispositivi utilizzando l'assegnazione di dispositivi discreti.

Disattivare il dispositivo
Usando Gestione dispositivi o PowerShell, assicurarsi che il dispositivo sia disabilitato.

Smontare il dispositivo

Dismount-VMHostAssignableDevice -LocationPath $locationPath

Assegnare il dispositivo alla macchina virtuale

guest
Il passaggio finale consiste nell'indicare a Hyper-V che una macchina virtuale deve avere
accesso al dispositivo. Oltre al percorso trovato in precedenza, è necessario conoscere il nome
della macchina virtuale.

Add-VMAssignableDevice -LocationPath $locationPath -VMName VMName

E adesso
Dopo che un dispositivo è stato montato correttamente in una macchina virtuale, è possibile
avviare la macchina virtuale e interagire con il dispositivo come normalmente si farebbe se
fosse in esecuzione in un sistema bare metal. È possibile verificarlo aprendo Gestione
dispositivi nella macchina virtuale guest e verificando che l'hardware sia ora visualizzato.

Rimuovere un dispositivo e restituirlo all'host

Se si vuole ripristinare lo stato originale del dispositivo, è necessario arrestare la macchina
virtuale e usare i comandi seguenti:
 #Remove the device from the VM
Remove-VMAssignableDevice -LocationPath $locationPath -VMName VMName
#Mount the device back in the host
Mount-VMHostAssignableDevice -LocationPath $locationPath

È quindi possibile abilitare di nuovo il dispositivo in Gestione dispositivi e il sistema operativo

host sarà in grado di interagire di nuovo con il dispositivo.
Eseguire Hyper-V in una macchina virtuale
con virtualizzazione annidata
25/07/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

La virtualizzazione annidata consente di eseguire Hyper-V all'interno di una macchina virtuale,

consentendo di emulare ambienti complessi senza bisogno di più host fisici. Questo articolo
illustra come configurare e usare la virtualizzazione annidata nelle piattaforme Windows
supportate, inclusi i prerequisiti, i passaggi di installazione e le opzioni di rete. Usare questo
articolo per testare scenari, eseguire emulatori o sviluppare soluzioni che richiedono più livelli
di virtualizzazione.

Per altre informazioni sulla virtualizzazione annidata e sugli scenari supportati, vedere Che
cos'è la virtualizzazione annidata per Hyper-V?.

Prerequisites

Processore Intel con tecnologia VT-x ed EPT

L'host Hyper-V deve essere Windows Server 2016 o versione successiva o Windows 10 o
versione successiva.
Configurazione della macchina virtuale versione 8.0 o successiva.

Processore AMD EPYC/Ryzen o versione successiva

L'host Hyper-V deve essere Windows Server 2022 o versione successiva o Windows 11 o
versione successiva.
Configurazione della macchina virtuale versione 9.3 o successiva.

７ Nota

Il guest può essere qualsiasi sistema operativo guest supportato da Windows. Alcune
versioni più recenti di Windows possono usare funzionalità cpu aggiuntive che migliorano
le prestazioni. Per abilitare la virtualizzazione annidata in una macchina virtuale di Azure,
assicurarsi di impostare Il tipo di sicurezza come "Standard".
Abilitare la virtualizzazione annidata
Per abilitare la virtualizzazione annidata, seguire questa procedura:

1. Creare una macchina virtuale. Vedere i prerequisiti per le versioni del sistema operativo e
della macchina virtuale necessarie.

2. Mentre la macchina virtuale è nello stato OFF, eseguire il comando seguente nell'host
fisico Hyper-V per abilitare la virtualizzazione annidata per la macchina virtuale.

PowerShell

Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true

3. Avviare la macchina virtuale.

4. Installare Hyper-V all'interno della macchina virtuale, proprio come per un server fisico.
Per altre informazioni sull'installazione di Hyper-V, vedere Installare Hyper-V.

７ Nota

Con Windows Server 2019 e versioni precedenti come macchina virtuale di primo livello, il
numero di vCPU deve essere pari o inferiore a 225. Per altre informazioni sui limiti delle
macchine virtuali, vedere Numero massimo per le macchine virtuali.

Disabilitare la virtualizzazione annidata

È possibile disabilitare la virtualizzazione annidata per una macchina virtuale arrestata usando il
comando di PowerShell seguente:

PowerShell

Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $false

Networking options
Esistono due opzioni per la rete con macchine virtuali annidate:

1. Spoofing degli indirizzi MAC

2. NAT networking
Spoofing degli indirizzi MAC
Affinché i pacchetti di rete vengano instradati tramite due commutatori virtuali, lo spoofing
degli indirizzi MAC deve essere abilitato nel primo livello (L1) del commutatore virtuale. Per
abilitare lo spoofing degli indirizzi MAC, eseguire il comando di PowerShell seguente.

PowerShell

Get-VMNetworkAdapter -VMName <VMName> | Set-VMNetworkAdapter -MacAddressSpoofing

On

Network Address Translation (NAT)

La seconda opzione si basa su NAT (Network Address Translation). Questo approccio è più
adatto per i casi in cui lo spoofing degli indirizzi MAC non è possibile, ad esempio in un
ambiente cloud pubblico.

Prima di tutto, è necessario creare un commutatore NAT virtuale nella macchina virtuale host
(la macchina virtuale "centrale"). Nell'esempio seguente viene creato un nuovo commutatore
interno denominato VmNAT e viene creato un oggetto NAT per tutti gli indirizzi IP nella subnet
[Link]/24 .

PowerShell

New-VMSwitch -Name VmNAT -SwitchType Internal

New-NetNat –Name LocalNAT –InternalIPInterfaceAddressPrefix “[Link]/24”

Assegnare quindi un indirizzo IP all'adattatore net:

PowerShell

Get-NetAdapter "vEthernet (VmNat)" | New-NetIPAddress -IPAddress [Link] -

AddressFamily IPv4 -PrefixLength 24

A ogni macchina virtuale annidata deve essere assegnato un indirizzo IP e un gateway.

L'indirizzo IP del gateway deve puntare alla scheda NAT del passaggio precedente. È anche
possibile assegnare un server DNS:

PowerShell

Get-NetAdapter "vEthernet (VmNat)" | New-NetIPAddress -IPAddress [Link] -

DefaultGateway [Link] -AddressFamily IPv4 -PrefixLength 24
Netsh interface ip add dnsserver “vEthernet (VmNat)” address=<my DNS server>
Next steps
gestire in remoto gli host Hyper-V con Hyper-V Manager
Hyper-V architetture di archiviazione in
Windows Server
Articolo • 15/01/2025 •
Si ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
applica Windows Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local, versions 23H2
a: and 22H2

Informazioni su come usare Windows Server con SAN, NAS, fiber channel, iSCSI,
archiviazione SMB per Hyper-V. Windows Server Hyper-V è una piattaforma hypervisor
matura che supporta un'ampia gamma di architetture di archiviazione fisica, dai sistemi
autonomi senza resilienza ai sistemi in cluster con requisiti di resilienza complessi.
Verranno inoltre fornite informazioni sulle configurazioni comuni che usano architetture
di archiviazione iperconvergente e disaggregate.

７ Nota

Questo articolo non descrive tutte le possibili configurazioni dell'architettura di

archiviazione. Non descrive anche tipi meno comuni di configurazione o casi
perimetrali.

Hyper-V indipendente con dischi locali

Hyper-V supporta diverse configurazioni non cluster o autonome in cui è possibile
installare Hyper-V in un server autonomo e usare l'archiviazione locale.

Quando si usa questa configurazione:

Il Hyper-V autonomo con dischi locali non supporta il failover automatico dei
carichi di lavoro delle macchine virtuali (VM) a causa della mancanza di
archiviazione condivisa e dei sistemi di calcolo (elaborazione e memoria delle VM)
non clusterizzati. Ad esempio, se l'host fisico perde l'alimentazione, le macchine
virtuali in esecuzione vengono riavviate quando si attiva l'host fisico. È anche
possibile eseguire la migrazione in tempo reale di macchine virtuali ad altri nodi o
cluster usando migrazione di non condiviso.

Facoltativamente, è possibile configurare la resilienza del disco locale per le unità

locali usando soluzioni RAID hardware o software. Se sono necessarie altre
informazioni, è consigliabile contattare il fornitore di archiviazione.
Hyper-V con archiviazione SAN o NAS
In questa configurazione disaggregata si installa Hyper-V in un cluster con macchine
virtuali che accedono alla risorsa di archiviazione tramite la rete da un fornitore di
archiviazione SAN o NAS.

Quando si usa questa configurazione:

Le macchine virtuali sono altamente disponibili per qualsiasi nodo nello stesso
cluster di calcolo.

I sistemi SAN e NAS offrono le proprie garanzie di disponibilità.

In questo modello, il calcolo e l'archiviazione vengono ridimensionati in modo

indipendente l'uno dall'altro. Ad esempio, se sono necessarie più risorse di elaborazione
o memoria per ospitare le macchine virtuali (CPU o RAM), è possibile aggiungere più
nodi di calcolo o cluster senza aggiungere altre risorse di archiviazione. Ogni cluster di
calcolo può contenere tra 1 e 64 nodi.

È possibile ridimensionare l'archiviazione in modo indipendente dal cluster di calcolo. Il

ridimensionamento del cluster di archiviazione dipende dal fornitore. Contattare i
fornitori per capire il modo in cui la soluzione di archiviazione offerta possa scalare.

Hyper-V iperconvergenti e Spazi di

archiviazione diretta
In questa configurazione si installano Hyper-V e Storage Spaces Direct in ogni nodo di
un cluster. Ogni nodo contiene dischi locali con dati replicati in altri nodi nello stesso
cluster.
Quando si usa questa configurazione:

È possibile spostare le macchine virtuali in qualsiasi nodo del cluster usando Live
Migrate o riavviare automaticamente dopo un errore (failover).

I dati vengono replicati in altri nodi del cluster per aumentare la resilienza
dell'archiviazione. Storage Spaces Direct supporta diversi modelli di resilienza dello
storage. Per altre informazioni, vedere Tolleranza di errore ed efficienza di
archiviazione nei cluster locali di Azure e Windows Server.

In questo modello ogni host fisico contiene risorse di archiviazione e calcolo. Di

conseguenza, tali risorse fisiche si scalano in modo simmetrico. Ogni nuovo host
aggiunge automaticamente sia risorse di calcolo che di archiviazione. Ogni cluster
può contenere tra 1 e 16 nodi.

Hyper-V con Spazi di Archiviazione Diretta

disaggregati
In questa configurazione si installano Hyper-V e Spazi di archiviazione diretta in cluster
separati e si accede alla configurazione e all'archiviazione delle macchine virtuali in rete.

Quando si usa questa configurazione:

Le macchine virtuali sono altamente disponibili per qualsiasi nodo nello stesso
cluster computazionale.

I dati vengono replicati in altri nodi nel cluster di archiviazione per aumentare la
resilienza dell'archiviazione. Storage Spaces Direct supporta diversi modelli di
resilienza dell'archiviazione. Per altre informazioni, vedere Tolleranza di errore ed
efficienza di archiviazione nei cluster locali di Azure e Windows Server.

In questo modello, l'elaborazione e l'archiviazione si scalano in maniera indipendente tra

loro. Questa architettura è ideale per scenari in cui i requisiti di archiviazione e calcolo
aumentano a velocità diverse. Ad esempio, se sono necessarie più risorse di CPU o
memoria per ospitare le macchine virtuali, è possibile aggiungere nodi del cluster
aggiuntivi senza aggiungere altre risorse di archiviazione. Se si dispone di macchine
virtuali che usano molte risorse di archiviazione, ma non utilizzano molte risorse cpu, è
possibile aggiungere un altro nodo di archiviazione o cluster senza aggiungere altre
risorse di calcolo.

Ogni cluster di calcolo può contenere tra 1 e 64 nodi.

Ogni cluster di archiviazione può contenere tra 1 e 16 nodi.

Il diagramma seguente illustra una semplice distribuzione di esempio con un cluster di

calcolo e un cluster di archiviazione.

Quando si aggiungono altre risorse di calcolo per eseguire le macchine virtuali, è

possibile aggiungere un nuovo nodo al cluster di calcolo esistente o aggiungere un
nuovo cluster. Il diagramma seguente illustra cosa accade alla distribuzione semplice se
si aggiunge un nuovo cluster senza aggiungere altre risorse di archiviazione.

Quando si aggiungono altre risorse di archiviazione per l'hosting di dati senza

aggiungere altre risorse di calcolo, è possibile aggiungere un nuovo nodo al cluster di
archiviazione esistente o aggiungere un nuovo cluster. Il diagramma seguente illustra
l'aspetto della distribuzione semplice quando si aggiunge un nuovo cluster senza
aggiungere risorse di calcolo come CPU o RAM.

Supporto dell'architettura mista

Hyper-V supporta la combinazione delle architetture seguenti nello stesso cluster di
calcolo:

Hyper-V con Spazi di archiviazione non aggregati diretti

Disaggregati Hyper-V con SAN

Hyper-V disaggregati con NAS

Il diagramma seguente illustra un esempio di distribuzione con un cluster di calcolo

contenente una combinazione di archiviazione SAN e NAS disaggregate.

Protocolli di archiviazione di rete

Windows Server supporta i protocolli di archiviazione file di rete seguenti:

SMB su TCP

SMB su QUIC

SMB su RDMA (SMB diretto)

Windows Server supporta anche i protocolli di archiviazione a blocchi di rete seguenti:

iSCSI

Fibre Channel

InfiniBand

７ Nota

Le specifiche di configurazione determinano in definitiva se la distribuzione può

supportare questi protocolli. Ad esempio, le distribuzioni che usano il commutatore
virtuale Hyper-V non supportano InfiniBand. Tuttavia, possono supportare i
dispositivi InfiniBand quando non sono associati al commutatore virtuale.

Microsoft offre anche un iniziatore iSCSI basato su software integrato per l'archiviazione
a blocchi di rete.

È anche possibile usare un client del fornitore di archiviazione per qualsiasi dispositivo
disponibile nel catalogo di Windows Server.

Commenti e suggerimenti
Questa pagina è stata utile?  Sì  No
Usare GPU con assegnazione di dispositivi
discreti nelle macchine virtuali in cluster
Si applica a: ✅ Windows Server 2025, ✅ Azure Local 2311.2 and later

È possibile includere unità di elaborazione grafica (GPU) nei cluster per fornire accelerazione
GPU ai carichi di lavoro in esecuzione nelle macchine virtuali in cluster. L'accelerazione GPU
può essere fornita tramite l'assegnazione di dispositivi discreti (DDA), che consente di dedicare
una o più GPU fisiche a una macchina virtuale o tramite il partizionamento GPU. Le macchine
virtuali in cluster possono sfruttare l'accelerazione GPU e le funzionalità di clustering, ad
esempio la disponibilità elevata tramite failover.

In questo articolo si apprenderà come usare GPU con macchine virtuali in cluster per fornire
accelerazione GPU ai carichi di lavoro usando l'assegnazione di dispositivi discreti. Questo
articolo illustra come preparare il cluster, assegnare una GPU a una macchina virtuale del
cluster ed eseguire il failover di tale macchina virtuale usando Windows Admin Center e
PowerShell.

 Suggerimento

La migrazione in tempo reale di macchine virtuali (VM) che usano GPU fornite da DDA non
è attualmente supportata, ma le macchine virtuali possono essere riavviate
automaticamente e posizionate in cui sono disponibili risorse GPU in caso di errore. Si
vuole usare Live Migration nelle macchine virtuali in cluster? Prendere in considerazione
l'uso del partizionamento GPU. Il partizionamento GPU consente di condividere una
frazione della GPU anziché l'intera GPU. Per altre informazioni su quando usare la
partizione GPU e il supporto per la migrazione in tempo reale, vedere Partizione e
assegnazione di GPU a una macchina virtuale.

Prerequisites
Prima di iniziare a usare GPU con macchine virtuali in cluster, è necessario tenere presenti
diversi requisiti e aspetti da considerare:

È necessario un cluster di failover di Windows Server che esegue Windows Server 2025 o
versione successiva.

Windows Server 2025 Datacenter Edition è necessario per l'uso di DDA con pool GPU
nelle macchine virtuali in cluster.

È necessario avere familiarità con il clustering di failover e Hyper-V.

 È necessario installare la stessa creazione e il modello delle GPU in tutti i server del
cluster.

Esaminare e seguire le istruzioni del produttore della GPU per installare i driver e il
software necessari in ogni server del cluster.

A seconda del fornitore dell'hardware, potrebbe essere necessario configurare anche

eventuali requisiti di licenza GPU.

È necessario un computer con Windows Admin Center installato. Questo computer

potrebbe essere uno dei nodi del cluster.

Creare una macchina virtuale a cui assegnare la GPU. Preparare la macchina virtuale per
DDA impostando il comportamento della cache, l'azione di arresto e le proprietà di I/O
mappate alla memoria (MMIO) in base alle istruzioni riportate in Distribuire dispositivi
grafici usando l'assegnazione di dispositivi discreti.

Preparare le GPU in ogni server installando driver di mitigazione della sicurezza in ogni
server, disabilitando le GPU e smontandole dall'host. Per altre informazioni su questo
processo, vedere Distribuire dispositivi grafici usando l'assegnazione di dispositivi discreti.

Preparare il cluster
Al termine dei prerequisiti , è possibile preparare il cluster per l'uso di GPU con macchine
virtuali in cluster.

La preparazione del cluster comporta la creazione di un pool di risorse contenente le GPU

disponibili per l'assegnazione alle macchine virtuali. Il cluster usa questo pool per determinare
il posizionamento delle macchine virtuali per le macchine virtuali avviate o spostate assegnate
al pool di risorse GPU.

Windows Admin Center

Usando Windows Admin Center, seguire questa procedura per preparare il cluster per
l'uso di GPU con macchine virtuali in cluster.

Per preparare il cluster e assegnare una macchina virtuale a un pool di risorse GPU:

1. Avviare Windows Admin Center e assicurarsi che l'estensione GPU sia già installata.

2. Selezionare Cluster Manager dal menu a discesa in alto e connettersi al cluster.

3. Dal menu Impostazioni selezionareGPU>.

4. Nel menu Strumenti , in Estensioni, selezionare GPU per aprire lo strumento.

5. Nella pagina principale dello strumento selezionare la scheda Pool DI GPU e quindi
selezionare Crea pool GPU.

6. Nella pagina Nuovo pool di GPU specificare quanto segue e quindi selezionare
Salva:
a. Nome server
b. Nome pool GPU
c. GPU da aggiungere al pool
 

Al termine del processo, si riceverà una richiesta di conferma dell'esito positivo che
mostra il nome del nuovo pool GPU e del server host.

Assegnare una macchina virtuale a un pool di

risorse GPU
È ora possibile assegnare una macchina virtuale a un pool di risorse GPU. È possibile assegnare
una o più macchine virtuali a un pool di risorse GPU in cluster e rimuovere una macchina
virtuale da un pool di risorse GPU in cluster.

Windows Admin Center

Seguire questa procedura per assegnare una macchina virtuale esistente a un pool di
risorse GPU usando Windows Admin Center.

７ Nota

È anche necessario installare i driver dal produttore della GPU all'interno della
macchina virtuale in modo che le app nella macchina virtuale possano sfruttare i
vantaggi della GPU assegnata.

1. Nella pagina Assegna macchina virtuale al pool GPU specificare quanto segue,
quindi selezionare Assegna:
a. Nome server
b. Nome pool GPU
c. Macchina virtuale a cui si vuole assegnare la GPU dal pool di GPU.
 È anche possibile definire valori di impostazione avanzati per gli spazi di I/O mappati
alla memoria (MMIO) per determinare i requisiti delle risorse per una singola GPU.

Al termine del processo, si riceverà una richiesta di conferma che indica che la GPU è
stata assegnata correttamente dal pool di risorse GPU alla macchina virtuale, che
viene visualizzata in Macchine virtuali assegnate.

Per annullare l'assegnazione di una macchina virtuale da un pool di risorse GPU:

1. Nella scheda Pool di GPU selezionare la GPU che si vuole annullare l'assegnazione e
quindi selezionare Annulla assegnazione macchina virtuale.

2. Nella pagina Annullare l'assegnazione della macchina virtuale dal pool di GPU, nella
casella di riepilogo Macchine virtuali specificare il nome della macchina virtuale e
quindi selezionare Annulla assegnazione.
 

Al termine del processo, viene visualizzato un messaggio di conferma dell'esito

positivo che la macchina virtuale non è stata assegnata dal pool di GPU e in Stato
assegnazione la GPU mostra Disponibile (non assegnato) .

Quando si avvia la macchina virtuale, il cluster garantisce che la macchina virtuale venga
inserita in un server con risorse GPU disponibili da questo pool a livello di cluster. Il cluster
assegna anche la GPU alla macchina virtuale tramite DDA, che consente l'accesso alla GPU dai
carichi di lavoro all'interno della macchina virtuale.

Eseguire il failover di una macchina virtuale con

una GPU assegnata
Per testare la capacità del cluster di eseguire il failover del carico di lavoro GPU, eseguire
un'operazione di svuotamento sul server in cui la macchina virtuale è in esecuzione con una
GPU assegnata. L'esecuzione di un'operazione di svuotamento sul server fa sì che il cluster
riavvii la macchina virtuale in un altro server del cluster, purché un altro server disponga di
risorse disponibili sufficienti nel pool creato.

Per svuotare il server, seguire le istruzioni riportate in Procedure di manutenzione del cluster di
failover. Il cluster riavvia la macchina virtuale in un altro server del cluster, purché un altro
server disponga di risorse GPU disponibili sufficienti nel pool creato.

Contenuti correlati
Per altre informazioni sull'uso di GPU con le macchine virtuali in cluster, vedere:

Gestire macchine virtuali con Windows Admin Center

 Pianificare la distribuzione dei dispositivi usando l'assegnazione di dispositivi discreti

Last updated on 30/01/2026

Distribuire i dispositivi usando
l'assegnazione di dispositivi discreti
25/07/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Azure Local 2311.2 and later

L'assegnazione di dispositivi discreti consente all'hardware fisico PCIe (Peripheral Component

Interconnect Express) di essere direttamente accessibile da una macchina virtuale (VM). In
questo articolo vengono descritti i tipi di dispositivi che possono essere utilizzati, i requisiti del
sistema host, le limitazioni imposte alle macchine virtuali e le implicazioni sulla sicurezza.

Per l'assegnazione di dispositivi discreti, Microsoft supporta due classi di dispositivi: schede
grafiche e dispositivi di archiviazione NVMe. È probabile che altri dispositivi funzionino e che i
fornitori di hardware possano offrire dichiarazioni di supporto per tali dispositivi. Per altri
dispositivi, contattare i fornitori di hardware specifici per ottenere assistenza.

Per informazioni su altri metodi di virtualizzazione della GPU, vedere Pianificare l'accelerazione
della GPU in Windows Server. Per provare l'assegnazione di dispositivi discreti, vedere
Distribuire dispositivi grafici utilizzando l'assegnazione di dispositivi discreti o Distribuire
dispositivi di archiviazione NVMe utilizzando l'assegnazione di dispositivi discreti.

Macchine virtuali supportate e sistemi operativi

guest
L'assegnazione di dispositivi discreti è supportata per le macchine virtuali di prima o seconda
generazione. I guest supportati includono:

Windows 10 o versione successiva

Windows Server 2016 o versione successiva

Per altre informazioni, vedere Macchine virtuali Linux e FreeBSD supportate per Hyper-V in
Windows Server e Windows.

System requirements
Il sistema deve soddisfare i requisiti hardware per Windows Server e i requisiti di sistema per
Hyper-V in Windows Server. L'assegnazione di dispositivi discreti richiede anche un hardware
di classe server in grado di garantire al sistema operativo il controllo della configurazione
dell’infrastruttura PCIe (Native PCI Express Control). Inoltre, il complesso radice PCIe deve
supportare i servizi di controllo degli accessi (ACS), che consentono a Hyper-V di forzare tutto il
traffico PCIe attraverso l'unità di gestione della memoria di input-output.

Queste funzionalità di solito non sono esposte direttamente nel BIOS del server e sono spesso
nascoste dietro altre impostazioni. Se le stesse funzionalità sono richieste per il supporto SR-
IOV e nel BIOS, potrebbe essere necessario impostare "Abilita SR-IOV". Contattare il fornitore
del sistema se non è possibile identificare l'impostazione corretta nel BIOS.

Per garantire che l'hardware possa eseguire l'assegnazione di dispositivi discreti, è possibile
eseguire lo script del profilo del computer in un host abilitato per Hyper-V. Lo script verifica se
il server è configurato correttamente e quali dispositivi possono eseguire l'assegnazione di
dispositivi discreti.

Device requirements
Non tutti i dispositivi PCIe possono essere utilizzati con l'assegnazione di dispositivi discreti. I
dispositivi meno recenti che utilizzano PCI Interrupts legacy (INTx) non sono supportati. Per
altre informazioni, vedere Assegnazione di dispositivi discreti - Macchine e dispositivi . Inoltre,
è possibile eseguire lo script del profilo del computer per visualizzare quali dispositivi possono
essere utilizzati per l'assegnazione di dispositivi discreti.

I produttori di dispositivi possono contattare il proprio rappresentante Microsoft per ulteriori

dettagli.

Device driver
L'assegnazione di dispositivi discreti passa l'intero dispositivo PCIe nella macchia virtuale guest.
Non è necessario installare un driver host prima di montare il dispositivo all'interno della
macchia virtuale. L'unico requisito per l'host è la possibilità di determinare il percorso di
posizione PCIe del dispositivo. Il driver del dispositivo può essere installato per facilitare
l'identificazione. Una GPU senza il driver di periferica installato nell'host potrebbe essere
visualizzata come una periferica di rendering di base di Microsoft. Se il driver del dispositivo è
installato, è probabile che vengano visualizzati il produttore e il modello.

Quando il dispositivo è montato all'interno del guest, il driver del dispositivo del produttore
può essere installato normalmente all'interno della macchina virtuale ospite.

VM limitations
A causa della natura dell'implementazione dell'assegnazione di dispositivi discreti, alcune
funzionalità di una macchina virtuale sono limitate quando è collegato un dispositivo. Le
seguenti funzionalità non sono disponibili:

VM Save/Restore
Migrazione in tempo reale di una macchina virtuale
L'uso della memoria dinamica
Aggiunta della macchina virtuale a un cluster a disponibilità elevata

Security
L'assegnazione di dispositivi discreti passa l'intero dispositivo nella macchia virtuale. Questo
passaggio indica che tutte le funzionalità di quel dispositivo sono accessibili dal sistema
operativo guest. Alcune funzionalità, come l'aggiornamento del firmware, potrebbero influire
negativamente sulla stabilità del sistema. Quando si smonta il dispositivo dall'host,
l'amministratore riceve numerosi avvisi. È consigliabile utilizzare l'assegnazione di dispositivi
discreti solo se i tenant delle macchine virtuali sono attendibili.

Se l'amministratore vuole utilizzare un dispositivo con un tenant non attendibile, i produttori di

dispositivi possono creare un driver di mitigazione del dispositivo che può essere installato
nell'host. Contattare il produttore del dispositivo per i dettagli sulla fornitura di un driver di
mitigazione del dispositivo.

Per ignorare i controlli di sicurezza per un dispositivo che non dispone di un driver di
mitigazione, è necessario passare il parametro -Force al cmdlet Dismount-
VMHostAssignableDevice . Quando si effettua questo passaggio, viene modificato il profilo di

sicurezza del sistema. È consigliabile apportare questa modifica solo durante la creazione di
prototipi o in ambienti attendibili.

Percorso posizione PCIe

Il percorso di posizione PCIe è necessario per smontare e montare il dispositivo dall'host. Un
percorso di posizione di esempio è PCIROOT(20)#PCI(0300)#PCI(0000)#PCI(0800)#PCI(0000) . Lo
script del profilo del computer restituisce anche il percorso di posizione del dispositivo PCIe.

Ottenere il percorso della posizione utilizzando Gestione

dispositivi
 1. Aprire Gestione dispositivi e individuare il dispositivo.
2. Fare clic con il pulsante destro del mouse sul dispositivo e scegliere Proprietà.
3. Nella scheda Dettagli espandere il menu a discesa Proprietà e selezionare Percorsi
percorso.
4. Fare clic con il pulsante destro del mouse sulla voce che inizia con PCIROOT e selezionare
Copia per ottenere il percorso del dispositivo.

MMIO space
Alcuni dispositivi, in particolare le GPU, richiedono più spazio MMIO da allocare alla macchina
virtuale affinché la memoria di quel dispositivo sia accessibile. Per impostazione predefinita,
ogni macchina virtuale inizia con 128 MB di spazio MMIO basso e 512 MB di spazio MMIO alto
allocato. Tuttavia, un dispositivo potrebbe richiedere più spazio MMIO o più dispositivi
potrebbero assegnati in modo tale che i requisiti combinati superino questi valori. La modifica
dello spazio MMIO è semplice e può essere eseguita in PowerShell utilizzando i seguenti
comandi:

PowerShell
 Set-VM -LowMemoryMappedIoSpace 3Gb -VMName $vm
Set-VM -HighMemoryMappedIoSpace 33280Mb -VMName $vm

Il modo più semplice per determinare la quantità di spazio MMIO da allocare è utilizzare lo
script del profilo del compute. Per scaricare ed eseguire lo script del profilo del computer,
eseguire i seguenti comandi in una console PowerShell:

PowerShell

curl -o SurveyDDA.ps1
[Link]
Documentation/live/hyperv-tools/DiscreteDeviceAssignment/SurveyDDA.ps1
.\SurveyDDA.ps1

Per i dispositivi che possono essere assegnati, lo script mostra i requisiti MMIO di un
determinato dispositivo. Il seguente script di output è un esempio:

PowerShell

NVIDIA GRID K520

Express Endpoint -- more secure.
...
And it requires at least: 176 MB of MMIO gap space
...

Lo spazio MMIO basso viene utilizzato solo da sistemi operativi e dispositivi a 32 bit che
utilizzano indirizzi a 32 bit. Nella maggior parte delle circostanze, è sufficiente impostare lo
spazio MMIO alto di una VM poiché le configurazioni a 32 bit non sono comuni.

） Importante

Quando si assegna spazio MMIO a una macchina virtuale, è necessario specificare uno
spazio MMIO sufficiente. Lo spazio MMIO deve essere la somma dello spazio MMIO
richiesto per tutti i dispositivi assegnati, più un buffer per altri dispositivi virtuali che
richiedono alcuni MB di spazio MMIO. Utilizzare i valori MMIO predefiniti
precedentemente descritti come buffer per MMIO basso e alto (rispettivamente 128 MB e
512 MB).

Consideriamo l'esempio precedente. Se si assegna una singola GPU K520, impostare lo spazio
MMIO della macchina virtuale sul valore emesso dallo script del profilo del computer più un
buffer: 176 MB + 512 MB. Se si assegnano tre GPU K520, impostare lo spazio MMIO a tre volte
la quantità di base di 176 MB più un buffer, o 528 MB + 512 MB.
Per dettagli sullo spazio MMIO, vedere Assegnazione di dispositivi discreti - GPU sul blog
della Tech Community.

Script del profilo del computer

Per identificare se il server è configurato correttamente e quali dispositivi possono essere
passati tramite l'assegnazione di dispositivi discreti, eseguire il SurveyDDA.ps1. Script di
PowerShell.

Prima di utilizzare lo script, assicurarsi di avere installato il ruolo Hyper-V e di eseguire lo script
da una finestra di comando di PowerShell con privilegi di amministratore.

Se il sistema non è configurato correttamente per supportare l'assegnazione di dispositivi

discreti, lo strumento mostra un messaggio di errore con i dettagli sul problema. Se il sistema è
configurato correttamente, lo strumento elenca tutti i dispositivi nel bus PCIe.

Per ogni dispositivo trovato, lo strumento mostra se è possibile utilizzarlo con l'assegnazione di
dispositivi discreti. Se un dispositivo viene identificato come incompatibile con l'assegnazione
di dispositivi discreti, lo script fornisce un motivo. Quando un dispositivo viene identificato
come compatibile, viene visualizzato il percorso di posizione del dispositivo. Inoltre, se tale
dispositivo richiede spazio MMIO, viene visualizzato anche.
Ottimizzazione delle prestazioni dei server
Hyper-V
15/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10

Hyper-V è il ruolo del server di virtualizzazione in Windows Server e Azure Local. I server di
virtualizzazione possono ospitare più macchine virtuali isolate tra loro, ma condividere le
risorse hardware sottostanti virtualizzando i processori, la memoria e i dispositivi di I/O.
Consolidando i server in un singolo computer, la virtualizzazione può migliorare l'utilizzo delle
risorse e l'efficienza energetica e ridurre i costi operativi e di manutenzione dei server. Inoltre,
le macchine virtuali e le API di gestione offrono maggiore flessibilità per la gestione delle
risorse, il bilanciamento del carico e il provisioning dei sistemi.

Riferimenti aggiuntivi
Hyper-V terminologia

ArchitetturaHyper-V

Hyper-V configurazione del server

Hyper-V prestazioni del processore

Hyper-V prestazioni di memoria

Hyper-V prestazioni di I/O di archiviazione

Hyper-V prestazioni di I/O di rete

Rilevamento di colli di bottiglia in un ambiente virtualizzato

Macchine Virtuali Linux

Creare criteri di sicurezza con elenchi di
controllo di accesso estesi per le porte
14/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

In questo argomento vengono fornite informazioni estesa porta controllo elenchi di accesso
(ACL) in Windows Server 2016. È possibile configurare ACL estesi nel commutatore virtuale
Hyper-V in modo da consentire e bloccare il traffico di rete indirizzato e proveniente dalle
macchine virtuali connesse al commutatore tramite schede di rete virtuali.

Questo argomento contiene le sezioni seguenti.

Regole ACL dettagliate

Regole ACL con stato

Regole ACL dettagliate

Commutatore virtuale Hyper-V gli ACL estesi consente di creare regole dettagliate che è
possibile applicare alle singole schede di rete VM connesse al commutatore virtuale Hyper-V.
La possibilità di creare regole dettagliate consente alle aziende e provider di servizi Cloud (CSP)
per affrontare le minacce di protezione di rete in un ambiente server condiviso multi-tenant.

Con gli ACL estesi è ora possibile bloccare o consentire il traffico di rete di singoli protocolli in
esecuzione nelle macchine virtuali, anziché creare regole più vaste che bloccano o consentono
il traffico di tutti i protocolli diretto o proveniente da una macchina virtuale. È possibile creare
regole ACL estese in Windows Server 2016 che includono il set di parametri 5 tuple seguente:
indirizzo IP, indirizzo IP di destinazione, protocollo, porta di origine e porta di destinazione di
origine. Ogni regola inoltre può specificare la direzione del traffico di rete (in entrata o in
uscita) e l'azione supportata dalla regola (blocco o abilitazione del traffico).

È ad esempio possibile configurare gli ACL delle porte in modo che una macchina virtuale
consenta tutto il traffico HTTP e HTTPS in entrata e in uscita sulla porta 80, bloccando invece il
traffico di rete di tutti gli altri protocolli su tutte le porte.

La possibilità di designare il traffico dei protocolli che può o non può essere ricevuto da
macchine virtuali tenant garantisce flessibilità nella configurazione dei criteri di sicurezza.

Configurazione di regole ACL con Windows PowerShell

Per configurare un elenco di controllo di accesso esteso, è necessario usare il comando di
Windows PowerShell Add-VMNetworkAdapterExtendedAcl. Questo comando supporta
quattro sintassi diverse, con un utilizzo specifico per ogni sintassi:

1. Aggiungere un ACL esteso a tutte le schede di rete di una macchina Virtuale denominata
- specificata dal primo parametro, - Name. Syntax:

７ Nota

Se si desidera aggiungere un ACL esteso a una scheda di rete anziché a tutti, è

possibile specificare la scheda di rete con il parametro - VMNetworkAdapterName.

Add-VMNetworkAdapterExtendedAcl [-VMName] <string[]> [-Action]

<VMNetworkAdapterExtendedAclAction> {Allow | Deny}
[-Direction] <VMNetworkAdapterExtendedAclDirection> {Inbound | Outbound}
[[-LocalIPAddress] <string>]
[[-RemoteIPAddress] <string>] [[-LocalPort] <string>] [[-RemotePort]
<string>] [[-Protocol] <string>] [-Weight]
<int> [-Stateful <bool>] [-IdleSessionTimeout <int>] [-IsolationID <int>]
[-Passthru] [-VMNetworkAdapterName
<string>] [-ComputerName <string[]>] [-WhatIf] [-Confirm]
[<CommonParameters>]

2. Aggiungere un ACL esteso a una scheda di rete virtuale specifica in una macchina virtuale.
Syntax:

Add-VMNetworkAdapterExtendedAcl [-VMNetworkAdapter] <VMNetworkAdapterBase[]>

[-Action]
<VMNetworkAdapterExtendedAclAction> {Allow | Deny} [-Direction]
<VMNetworkAdapterExtendedAclDirection> {Inbound |
Outbound} [[-LocalIPAddress] <string>] [[-RemoteIPAddress] <string>] [[-
LocalPort] <string>] [[-RemotePort]
<string>] [[-Protocol] <string>] [-Weight] <int> [-Stateful <bool>] [-
IdleSessionTimeout <int>] [-IsolationID
<int>] [-Passthru] [-WhatIf] [-Confirm] [<CommonParameters>]

3. Aggiungere un ACL esteso a tutte le schede di rete virtuali riservate per l'utilizzo da parte
del sistema operativo di gestione host Hyper-V.

７ Nota
 Se si desidera aggiungere un ACL esteso a una scheda di rete anziché a tutti, è
possibile specificare la scheda di rete con il parametro - VMNetworkAdapterName.

Add-VMNetworkAdapterExtendedAcl [-Action] <VMNetworkAdapterExtendedAclAction>

{Allow | Deny} [-Direction]
<VMNetworkAdapterExtendedAclDirection> {Inbound | Outbound} [[-
LocalIPAddress] <string>] [[-RemoteIPAddress]
<string>] [[-LocalPort] <string>] [[-RemotePort] <string>] [[-Protocol]
<string>] [-Weight] <int> -ManagementOS
[-Stateful <bool>] [-IdleSessionTimeout <int>] [-IsolationID <int>] [-
Passthru] [-VMNetworkAdapterName <string>]
[-ComputerName <string[]>] [-WhatIf] [-Confirm] [<CommonParameters>]

4. Aggiungere un ACL esteso a un oggetto macchina Virtuale che è stato creato in Windows
PowerShell, ad esempio $vm = get-vm "macchina_virtuale". Nella riga di codice
successiva è possibile eseguire questo comando per creare un ACL esteso con la sintassi
seguente:

Add-VMNetworkAdapterExtendedAcl [-VM] <VirtualMachine[]> [-Action]

<VMNetworkAdapterExtendedAclAction> {Allow |
Deny} [-Direction] <VMNetworkAdapterExtendedAclDirection> {Inbound |
Outbound} [[-LocalIPAddress] <string>]
[[-RemoteIPAddress] <string>] [[-LocalPort] <string>] [[-RemotePort]
<string>] [[-Protocol] <string>] [-Weight]
<int> [-Stateful <bool>] [-IdleSessionTimeout <int>] [-IsolationID <int>]
[-Passthru] [-VMNetworkAdapterName
<string>] [-WhatIf] [-Confirm] [<CommonParameters>]

Esempi di regole ACL dettagliate

Di seguito sono riportati diversi esempi di come usare il comando Add-
VMNetworkAdapterExtendedAcl per configurare gli ACL delle porte estese e per creare criteri
di sicurezza per le macchine virtuali.

Implementare la sicurezza a livello di applicazione

Implementare la sicurezza sia a livello di utente che a livello di applicazione

Fornire supporto di sicurezza a un'applicazione non TCP/UDP

７ Nota
 I valori per il parametro della regola Direction nelle tabelle seguenti si basano sul flusso
del traffico verso o dalla macchina virtuale per cui si sta creando la regola. Se la macchina
virtuale riceve traffico, il traffico è in entrata. Se invece invia traffico, il traffico è in uscita.
Se ad esempio si applica a una macchina virtuale una regola che blocca il traffico in
entrata, la direzione del traffico in entrata sarà dalle risorse esterne verso la macchina
virtuale. Se si applica una regola che blocca il traffico in uscita, la direzione del traffico in
uscita sarà dalla macchina virtuale locale verso le risorse esterne.

Implementare la sicurezza a livello di applicazione

Poiché in molti server applicazioni vengono utilizzate porte TCP/UDP standardizzate per
comunicare con i computer client, è facile creare regole che bloccano o consentono l'accesso a
un server applicazioni filtrando il traffico diretto e proveniente dalla porta designata per
l'applicazione.

È ad esempio possibile consentire a un utente di eseguire l'accesso a un server applicazioni nel

centro dati utilizzando Connessione Desktop remoto (RDP). Poiché il protocollo RDP utilizza la
porta TCP 3389, è possibile configurare rapidamente la regola seguente:

ﾉ Espandi la tabella

IP di IP di Protocol Porta di Porta di Direction Action

origine destinazione origine destinazione

* * TCP * 3389 In Allow

Vengono riportati di seguito due esempi di creazione di regole con i comandi di Windows
PowerShell. La prima regola di esempio blocca tutto il traffico alla macchina Virtuale
denominata "ApplicationServer". La seconda regola di esempio, viene applicata alla scheda di
rete della macchina Virtuale denominata "ApplicationServer", consente solo il traffico RDP in
ingresso alla macchina Virtuale.

７ Nota

Quando si creano regole, è possibile usare il parametro -Weight per determinare l'ordine
in cui il commutatore virtuale Hyper-V elabora le regole. I valori per -Weight sono espressi
come numeri interi; le regole con un numero intero superiore vengono elaborate prima
delle regole con numeri interi inferiori. Se ad esempio sono state applicate due regole a
una scheda di rete di macchina virtuale, una con parametro -weight impostato su 1 e
un'altra con parametro -Weight impostato su 10, verrà applicata per prima la regola il cui
parametro -Weight è impostato su 10.
 Add-VMNetworkAdapterExtendedAcl -VMName "ApplicationServer" -Action "Deny" -
Direction "Inbound" -Weight 1
Add-VMNetworkAdapterExtendedAcl -VMName "ApplicationServer" -Action "Allow" -
Direction "Inbound" -LocalPort 3389 -Protocol "TCP" -Weight 10

Implementare la sicurezza sia a livello di utente che a livello di

applicazione
Poiché può soddisfare un pacchetto IP di 5 tuple (IP origine, IP di destinazione, Protocollo,
Porta di origine e Porta di destinazione), una regola consente di applicare criteri di sicurezza
più dettagliati rispetto a un ACL delle porte.

Ad esempio, se si desidera fornire il servizio DHCP a un numero limitato di client computer

utilizzando un set specifico di server DHCP, è possibile configurare le regole seguenti nel
computer Windows Server 2016 che esegue Hyper-V, in cui sono ospitate le macchine virtuali
utente:

ﾉ Espandi la tabella

IP di origine IP di Protocol Porta di Porta di Direction Action

destinazione origine destinazione

* [Link] UDP * 67 Out Allow

* [Link]/25 UDP * 67 Out Allow

[Link]/25 * UDP * 68 In Allow

Vengono riportati di seguito esempi di creazione di queste regole con i comandi di Windows
PowerShell.

Add-VMNetworkAdapterExtendedAcl -VMName "ServerName" -Action "Deny" -Direction

"Outbound" -Weight 1
Add-VMNetworkAdapterExtendedAcl -VMName "ServerName" -Action "Allow" -Direction
"Outbound" -RemoteIPAddress [Link] -RemotePort 67 -Protocol "UDP"-Weight
10
Add-VMNetworkAdapterExtendedAcl -VMName "ServerName" -Action "Allow" -Direction
"Outbound" -RemoteIPAddress [Link]/25 -RemotePort 67 -Protocol "UDP"-Weight
20
Add-VMNetworkAdapterExtendedAcl -VMName "ServerName" -Action "Allow" -Direction
"Inbound" -RemoteIPAddress [Link]/25 -RemotePort 68 -Protocol "UDP"-Weight
20
Fornire supporto di sicurezza a un'applicazione non TCP/UDP
Mentre la maggior parte del traffico di rete in un centro dati è basato sui protocolli TCP e UDP,
esiste comunque una parte di traffico basata su altri protocolli. Se ad esempio si desidera
consentire a un gruppo di server di eseguire un'applicazione multicast IP basata sul protocollo
IGMP (Internet Group Management Protocol), è possibile creare la regola seguente.

７ Nota

Il numero di protocollo IP designato per IGMP è 0x02.

ﾉ Espandi la tabella

IP di IP di Protocol Porta di Porta di Direction Action

origine destinazione origine destinazione

* * 0x02 * * In Allow

* * 0x02 * * Out Allow

Viene riportato di seguito un esempio di creazione di queste regole con i comandi di Windows
PowerShell.

Add-VMNetworkAdapterExtendedAcl -VMName "ServerName" -Action "Allow" -Direction

"Inbound" -Protocol 2 -Weight 20
Add-VMNetworkAdapterExtendedAcl -VMName "ServerName" -Action "Allow" -Direction
"Outbound" -Protocol 2 -Weight 20

Regole ACL con stato

Un'altra nuova funzionalità degli ACL estesi consente di configurare regole con stato. Una
regola con stato Filtra i pacchetti in base a cinque attributi in un pacchetto - IP di origine, IP di
destinazione, protocollo, porta di origine e porta di destinazione.

Le regole con stato offrono le funzionalità seguenti:

Consentono sempre il traffico e non vengono utilizzate per bloccare il traffico.

Se si specifica che il valore per il parametro Direction è in ingresso e il traffico

corrisponde alla regola, Hyper-V Commutatore virtuale crea dinamicamente una regola
 corrispondente che consente alla macchina virtuale di inviare il traffico in uscita in
risposta alla risorsa esterna.

Se si specifica che il valore per il parametro Direction è in uscita e il traffico corrisponde

alla regola, Hyper-V commutatore virtuale crea dinamicamente una regola
corrispondente che consente la ricezione del traffico in ingresso della risorsa esterna dalla
macchina virtuale.

Includono un attributo di timeout misurato in secondi. Quando un pacchetto di rete che

raggiunge il commutatore soddisfa una regola con stato, il commutatore virtuale Hyper-V
crea uno stato in modo da consentire tutti i pacchetti successivi in entrambe le direzioni
dello stesso flusso. Lo stato scade in assenza di traffico in una delle due direzioni nel
periodo di tempo specificato dal valore di timeout.

Viene riportato di seguito un esempio di utilizzo delle regole con stato.

Consentire il traffico in entrata del server remoto solo dopo

che è stato contattato dal server locale
In alcuni casi è necessario utilizzare una regola con stato perché è l'unica soluzione in grado di
tenere traccia di una connessione stabilita nota e di distinguere la connessione da altre
connessioni.

Se ad esempio si desidera consentire a un server applicazioni con macchina virtuale di avviare

connessioni sulla porta 80 con servizi Web su Internet, e si desidera che i server Web remoti
siano in grado di rispondere al traffico della macchina virtuale, è possibile configurare una
regola con stato che consenta il traffico in uscita iniziale dalla macchina virtuale verso i servizi
Web. Poiché viene utilizzata una regola con stato, è consentito anche il traffico di ritorno verso
la macchina virtuale proveniente dai server Web. Per motivi di sicurezza, è possibile bloccare
tutto il restante traffico di rete in entrata verso la macchina virtuale.

Per definire questa configurazione di regola, è possibile utilizzare le impostazioni elencate nella
tabella riportata di seguito.

７ Nota

Per le restrizioni di formattazione e la quantità di informazioni contenute nella tabella

seguente, i dati vengono visualizzati in modo diverso rispetto alle tabelle precedenti di
questo documento.

ﾉ Espandi la tabella
 Parameter Regola 1 Regola 2 Regola 3

IP di origine * * *

IP di destinazione * * *

Protocol * * TCP

Porta di origine * * *

Porta di destinazione * * 80

Direction In Out Out

Action Deny Deny Allow

Stateful No No Yes

Timeout (in secondi) N/A N/A 3600

La regola con stato consente al server applicazioni con macchina virtuale di connettersi a un
server Web remoto. Quando viene inviato il primo pacchetto, il commutatore virtuale Hyper-V
crea due stati di flusso per consentire tutti i pacchetti inviati al server Web remoto e tutti i
pacchetti di ritorno. Quando il flusso di pacchetti tra i server si arresta, viene applicato il
timeout degli stati di flusso secondo il valore designato di 3.600 secondi, ovvero di un'ora.

Viene riportato di seguito un esempio di creazione di queste regole con i comandi di Windows
PowerShell.

Add-VMNetworkAdapterExtendedAcl -VMName "ApplicationServer" -Action "Deny" -

Direction "Inbound" -Weight 1
Add-VMNetworkAdapterExtendedAcl -VMName "ApplicationServer" -Action "Deny" -
Direction "Outbound" -Weight 1
Add-VMNetworkAdapterExtendedAcl -VMName "ApplicationServer" -Action "Allow" -
Direction "Outbound" 80 "TCP" -Weight 100 -Stateful -Timeout 3600
Informazioni sulla crittografia del dump
16/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

La crittografia del dump può essere usata per proteggere i dump di sistema generati da arresti
anomali e i dump in tempo reale generati per un sistema. I dump vengono crittografati usando
una chiave di crittografia simmetrica generata per ogni dump. Questa chiave viene quindi
crittografata utilizzando la chiave pubblica specificata dall'amministratore fidato dell'host
(protezione della chiave di crittografia del crash dump). Ciò garantisce che solo un utente con
la chiave privata corrispondente possa decrittografare e quindi accedere al contenuto del
dump. Questa funzionalità viene utilizzata in un'infrastruttura protetta. Nota: Se si configura la
crittografia del dump, è necessario disabilitare anche la Segnalazione errori di Windows. WeR
non è in grado di leggere i dump di arresto anomalo crittografati.

Configurazione della crittografia del dump

Configurazione manuale
Per attivare la crittografia del dump usando il Registro di sistema, configurare i valori del
Registro di sistema seguenti in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl

ﾉ Espandi la tabella

Nome del valore Type Value

DumpEncryptionEnabled DWORD 1 per abilitare la crittografia dump, 0 per

disabilitare la crittografia del dump

EncryptionCertificates\Certificate.1::PublicKey Binary Chiave pubblica (RSA, 2048 bit) che deve

essere usata per crittografare i dump. Deve
essere formattato come
BCRYPT_RSAKEY_BLOB.

EncryptionCertificates\Certificate.1::Thumbprint String Impronta digitale del certificato per

consentire la ricerca automatica della chiave
privata nell'archivio certificati locale durante
la decrittografia di un crash dump.

Configurazione tramite script

Per semplificare la configurazione, è disponibile uno script di esempio per abilitare la
crittografia dump basata su una chiave pubblica da un certificato.

1. In un ambiente attendibile: creare un certificato con una chiave RSA a 2048 bit ed
esportare il certificato pubblico
2. Negli host di destinazione: importare il certificato pubblico nell'archivio certificati locale
3. Eseguire lo script di configurazione di esempio

.\Set-DumpEncryptionConfiguration.ps1 -Certificate
(Cert:\CurrentUser\My\093568AB328DF385544FAFD57EE53D73EFAAF519) -Force

Decrittografia di dump crittografati

Per decrittografare un file di dump crittografato esistente, è necessario scaricare e installare gli
strumenti di debug per Windows. Questo set di strumenti contiene [Link]
che può essere usato per decrittografare un file di dump crittografato. Se il certificato che
include la chiave privata è presente nell'archivio certificati dell'utente corrente, il file dump può
essere decrittografato chiamando

[Link] [Link] memory_decr.dmp

Dopo la decrittografia, gli strumenti come WinDbg possono aprire il file di dump
decrittografato.

Risoluzione dei problemi relativi alla crittografia

dei dump
Se la crittografia del dump è abilitata in un sistema ma non vengono generati dump,
controllare il registro eventi del sistema per l'evento [Link] dump encryption is enabled on a
system but no dumps are generated, please check the system's System event log for Kernel-IO
event 1207. Quando non è possibile inizializzare la crittografia del dump, questo evento viene
creato e i dump sono disabilitati.

ﾉ Espandi la tabella
 Messaggi di errore Passaggi per attenuare i rischi
dettagliati

Chiave pubblica o registro Controllare se entrambi i valori del Registro di sistema sono presenti nel
impronta digitale mancante percorso previsto

Chiave pubblica non valida Assicurarsi che la chiave pubblica archiviata nel valore del Registro di
sistema PublicKey sia archiviata come BCRYPT_RSAKEY_BLOB.

Dimensione della chiave Attualmente sono supportate solo chiavi RSA a 2048 bit. Configurare
pubblica non supportata una chiave che soddisfi questo requisito

Controllare anche se il valore GuardedHost in

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl\ForceDumpsDisabled è

impostato su un valore diverso da 0. In questo modo vengono disabilitati completamente i

dump di arresto anomalo. In questo caso, impostarlo su 0.
Cmdlet della configurazione di dispositivi
di memoria persistente per macchine
virtuali Hyper-V
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Azure Local 2311.2 and later

Questo articolo fornisce agli amministratori di sistema e ai professionisti IT informazioni sulla

configurazione di macchine virtuali Hyper-V con memoria persistente (nota anche come
memoria della classe di archiviazione o NVDIMM). I dispositivi di memoria persistente conformi
a JEDEC NVDIMM-N sono supportati in Windows Server 2016 e Windows 10 e forniscono
l'accesso a livello di byte a dispositivi non volatile a bassa latenza. I dispositivi di memoria
persistente della macchina virtuale sono supportati in Windows Server 2019.

Creare un dispositivo di memoria persistente per

una macchina virtuale
Usare il cmdlet New-VHD per creare un dispositivo di memoria persistente per una macchina
virtuale. Il dispositivo deve essere creato in un volume DAX NTFS esistente. La nuova
estensione del nome file (.vhdpmem) viene usata per specificare che si tratta di un dispositivo
di memoria persistente. È supportato solo il formato di file VHD fisso.

Esempio: New-VHD D:\[Link] -Fixed -SizeBytes 4GB

Creare una macchina virtuale con un controller di

memoria persistente
Usare il cmdletNew-VM per creare una macchina virtuale di seconda generazione con
dimensioni di memoria e percorso specificati per un'immagine VHDX. Usare quindi Add-
VMPmemController per aggiungere un controller di memoria persistente a una macchina
virtuale.

Example:

PowerShell
New-VM -Name "ProductionVM1" -MemoryStartupBytes 1GB -VHDPath c:\vhd\[Link]

Add-VMPmemController -VMName "ProductionVM1"

Allegare un dispositivo di memoria persistente per
una macchina virtuale
Usare Add-VMHardDiskDrive per collegare un dispositivo di memoria persistente a una
macchina virtuale

Esempio: Add-VMHardDiskDrive -VMName "ProductionVM1" -ControllerType PMEM -

ControllerLocation 1 -Path D:\[Link]

I dispositivi di memoria persistente all'interno di una macchina virtuale Hyper-V vengono

visualizzati dispositivi da usare e gestire dal sistema operativo guest. I sistemi operativi guest
possono usare il dispositivo come blocco o volume DAX. Quando i dispositivi di memoria
persistente all'interno di una macchina virtuale vengono usati come volume DAX, traggono
vantaggio dalla capacità di indirizzamento a livello di byte a bassa latenza del dispositivo host
(nessuna virtualizzazione di I/O nel percorso del codice).

７ Nota

La memoria persistente è supportata solo per le macchine virtuali Hyper-V di seconda

generazione. La migrazione in tempo reale e la migrazione di archiviazione non sono
supportate per le macchine virtuali con memoria persistente. I checkpoint di produzione
delle macchine virtuali non comprendono lo stato di memoria persistente.

Last updated on 22/01/2026

Uso di checkpoint per ripristinare uno stato
precedente delle macchine virtuali
15/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Uno dei vantaggi principali della virtualizzazione è la possibilità di salvare facilmente lo stato di
una macchina virtuale. In Hyper-V questa operazione viene eseguita tramite l'uso di checkpoint
delle macchine virtuali. È possibile creare un checkpoint della macchina virtuale prima di
apportare modifiche alla configurazione software, applicare un aggiornamento software o
installare un nuovo software. Se una modifica del sistema causava un problema, la macchina
virtuale può essere ripristinata allo stato in cui si trovava al momento dell'esecuzione del
checkpoint.

Windows 10 e 11 Hyper-V include due tipi di checkpoint:

Checkpoint standard: crea uno snapshot della macchina virtuale e dello stato di memoria
della macchina virtuale al momento dell'avvio del checkpoint. Uno snapshot non è un
backup completo e può causare problemi di coerenza dei dati con i sistemi che replicano
dati tra nodi diversi, ad esempio Active Directory. Hyper-V offre solo checkpoint standard
(in precedenza denominati snapshot) prima di Windows 10.

Checkpoint di produzione: usa il servizio Copia Shadow del volume o il blocco del file
system in una macchina virtuale Linux per creare un backup coerente con i dati della
macchina virtuale. Non viene creato alcun snapshot dello stato di memoria della
macchina virtuale.

I checkpoint di produzione vengono selezionati per impostazione predefinita, tuttavia è

possibile modificarli usando Hyper-V manager o PowerShell.

７ Nota

Il modulo di PowerShell Hyper-V ha diversi alias in modo che sia possibile usare
checkpoint e snapshot in modo intercambiabile.
Questo documento usa il checkpoint, ma è possibile che vengano visualizzati comandi
simili usando il termine snapshot.

Modifica del tipo di checkpoint

 Hyper-V manager

1. Aprire Hyper-V Manager.

2. Fare clic con il pulsante destro del mouse su una macchina virtuale e selezionare le
impostazioni.

3. In Gestione selezionare Checkpoint.

4. Selezionare il tipo di checkpoint desiderato.

Creazione di checkpoint
Crea un checkpoint del tipo configurato per la macchina virtuale. Vedere la sezione
Configurazione del tipo di checkpoint più indietro in questo documento per istruzioni su come
modificare questo tipo.
 Hyper-V manager

Per creare un checkpoint:

1. In Hyper-V Manager selezionare la macchina virtuale.

2. Fare clic con il pulsante destro del mouse sul nome della macchina virtuale e quindi
scegliere Checkpoint.

3. Al termine del processo, il checkpoint verrà visualizzato in Checkpoint nel Hyper-V

Manager.

Applicazione di checkpoint
Se si vuole ripristinare una macchina virtuale a un punto nel tempo precedente, è possibile
applicare un checkpoint esistente.

Hyper-V manager

1. In Hyper-V Manager, in Macchine virtuali selezionare la macchina virtuale.

2. Nella sezione Checkpoint fare clic con il pulsante destro del mouse sul checkpoint
che si desidera usare e scegliere Applica.

3. Viene visualizzata una finestra di dialogo con le opzioni seguenti:

Crea checkpoint e applica: crea un nuovo checkpoint della macchina virtuale

prima di applicare il checkpoint precedente.
Applica: applica solo il checkpoint scelto. Non è possibile annullare questa
azione.
Annulla: chiude la finestra di dialogo senza eseguire alcuna operazione.

Selezionare l'opzione Applica per creare il checkpoint.

Ridenominazione dei checkpoint

Molti checkpoint vengono creati in un punto specifico. Assegnando loro un nome identificabile
è più semplice ricordare i dettagli sullo stato del sistema al momento della creazione del
checkpoint.
Per impostazione predefinita, il nome di un checkpoint è il nome della macchina virtuale
combinata con la data e l'ora di esecuzione del checkpoint. Questo è il formato standard:

Output

virtual_machine_name (MM/DD/YYY -hh:mm:ss AM\PM)

I nomi sono limitati a 100 caratteri e il nome non può essere vuoto.

Hyper-V manager

1. In Hyper-V Manager selezionare la macchina virtuale.

2. Fare clic con il pulsante destro del mouse sul checkpoint e quindi scegliere Rinomina.

3. Immettere il nuovo nome per il checkpoint. Deve essere minore di 100 caratteri e il
campo non può essere vuoto.

4. Al termine, selezionare INVIO .

Eliminazione di checkpoint
L'eliminazione dei checkpoint consente di creare spazio nell'host Hyper-V.

In background, i checkpoint vengono archiviati come file avhdx nella stessa posizione dei file
con estensione vhdx per la macchina virtuale. Quando si elimina un checkpoint, Hyper-V unisce
i file con estensione avhdx e vhdx. Al termine, il file avhdx del checkpoint verrà eliminato dal
file system.

Non eliminare direttamente i file avhdx.

Hyper-V manager

Per eliminare in modo pulito un checkpoint:

1. In Hyper-V Manager selezionare la macchina virtuale.

2. Nella sezione Checkpoint fare clic con il pulsante destro del mouse sul checkpoint da
eliminare e scegliere Elimina. È anche possibile eliminare un checkpoint e tutti i
checkpoint successivi. A tale scopo, fare clic con il pulsante destro del mouse sul
checkpoint meno recente da eliminare e quindi scegliere Elimina sottoalbero
checkpoint.
 3. Potrebbe essere richiesto di verificare di voler eliminare il checkpoint. Verificare che
sia il checkpoint corretto e quindi selezionare Elimina.

Esportazione di checkpoint
L'esportazione raggruppa il checkpoint come macchina virtuale in modo che il checkpoint
possa essere spostato in una nuova posizione. Dopo l'importazione, il checkpoint viene
ripristinato come macchina virtuale. I checkpoint esportati possono essere usati per il backup.

Hyper-V manager

Per esportare un checkpoint:

1. In Hyper-V Manager selezionare la macchina virtuale.

2. Nella sezione Checkpoint fare clic con il pulsante destro del mouse sul checkpoint da
esportare e selezionare Esporta.

3. Immettere il percorso in cui si vuole salvare il checkpoint esportato e quindi

selezionare Esporta.

Il processo di esportazione può richiedere del tempo, a seconda delle dimensioni del
checkpoint. Controllare lo stato nella colonna Stato nella Hyper-V Manager per la
macchina virtuale.

Abilitare o disabilitare i checkpoint

1. In Hyper-V Manager fare clic con il pulsante destro del mouse sul nome della macchina
virtuale e scegliere Impostazioni.

2. Nella sezione Gestione selezionare Checkpoint.

3. Per consentire la disattivazione dei checkpoint da questa macchina virtuale, assicurarsi

che l'opzione Abilita checkpoint sia selezionata. Si tratta del comportamento predefinito.
Per disabilitare i checkpoint, deselezionare la casella di controllo Abilita checkpoint .

4. Selezionare Applica per applicare le modifiche. Al termine, selezionare OK per chiudere la

finestra di dialogo.

Configurare il percorso del checkpoint

Se la macchina virtuale non dispone di checkpoint, è possibile modificare la posizione in cui
vengono archiviati i file di stato salvati e la configurazione del checkpoint.

1. In Hyper-V Manager fare clic con il pulsante destro del mouse sul nome della macchina
virtuale e scegliere Impostazioni.

2. Nella sezione Gestione selezionare Checkpoint o Percorso file di checkpoint.

3. In Percorso file checkpoint immettere il percorso della cartella in cui archiviare i file.

4. Selezionare Applica per applicare le modifiche. Al termine, selezionare OK per chiudere la

finestra di dialogo.

Il percorso predefinito per l'archiviazione dei file di configurazione del checkpoint è:

%systemroot%\ProgramData\Microsoft\Windows\Hyper-V\Snapshots .

Uso di checkpoint standard

Questo esercizio illustra la creazione e l'applicazione di un checkpoint standard rispetto a un
checkpoint di produzione. Per questo esempio si apporta una semplice modifica alla macchina
virtuale e si osserverà il diverso comportamento.

Creare un checkpoint standard

1. Accedere alla macchina virtuale e creare un file di testo sul desktop.

2. Aprire il file con Blocco note e immettere il testo 'This is a Standard Checkpoint'. Non
salvare il file o chiudere il Blocco note.

3. Modificare il checkpoint in standard. Seguire le istruzioni per modificare i checkpoint.

4. Creare un nuovo checkpoint.

Applicare il checkpoint standard con Hyper-V Manager
Ora che esiste un checkpoint, apportare una modifica alla macchina virtuale e quindi applicare
il checkpoint per ripristinare lo stato salvato della macchina virtuale.

1. Chiudere il file di testo se è ancora aperto ed eliminarlo dal desktop della macchina
virtuale.

2. Aprire Hyper-V Manager, fare clic con il pulsante destro del mouse sul checkpoint
standard e scegliere Applica.

3. Selezionare Applica nella finestra Applica notifica checkpoint.

Dopo aver applicato il checkpoint, si noti che non solo è presente il file di testo, ma il sistema è
nello stato esatto in cui si trovava al momento della creazione del checkpoint. In questo caso Il
Blocco note è aperto e il file di testo caricato.

Uso dei checkpoint di produzione

Esaminiamo ora i checkpoint di produzione. Questo processo è quasi identico all'uso di un
checkpoint standard, ma avrà risultati leggermente diversi. Prima di iniziare, assicurarsi di avere
una macchina virtuale e di avere modificato il tipo di checkpoint in Checkpoint di produzione.
Modificare la macchina virtuale e creare un checkpoint di
produzione
1. Accedere alla macchina virtuale e creare un nuovo file di testo. Se è stato seguito
l'esercizio precedente, è possibile usare il file di testo esistente.

2. Immettere "This is a Production Checkpoint". nel file di testo, salvare il file ma non
chiudere blocco note.

3. Aprire Hyper-V Manager, fare clic con il pulsante destro del mouse sulla macchina virtuale
e selezionare Checkpoint.

4. Selezionare OK nella finestra Checkpoint di produzione creata.

Applicare il checkpoint di produzione con Hyper-V Manager

Ora che esiste un checkpoint apportare una modifica al sistema e quindi applicare il checkpoint
per ripristinare lo stato salvato della macchina virtuale.

1. Chiudere il file di testo se è ancora aperto ed eliminarlo dal desktop della macchina
virtuale.

2. Aprire Hyper-V Manager, fare clic con il pulsante destro del mouse sul checkpoint di
produzione e selezionare Applica.

3. Selezionare Applica nella finestra Applica notifica checkpoint.

Dopo aver applicato il checkpoint di produzione, si è notato che la macchina virtuale è

disattivata.

1. Avviare e accedere alla macchina virtuale.

2. Si noti che il file di testo è stato ripristinato. A differenza del checkpoint standard, il
Blocco note non è aperto.
Creare Hyper-V file del set di dischi rigidi
virtuali
16/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

I file VHD Set sono un nuovo modello di disco virtuale condiviso per cluster guest in Windows
Server 2016. I file del set di dischi rigidi virtuali supportano il ridimensionamento online dei
dischi virtuali condivisi, supportano la replica Hyper-V e possono essere inclusi nei checkpoint
consistenti con l'applicazione.

I file VHD Set usano un nuovo tipo di file VHD, .VHDS. I file del VHD Set archiviano le
informazioni sui checkpoint del disco virtuale di gruppo usato nei cluster guest, sotto forma di
metadati.

Hyper-V gestisce tutti gli aspetti della gestione delle catene di checkpoint e della fusione del
set VHD condiviso. Il software di gestione può eseguire operazioni su disco, come il
ridimensionamento online dei file VHD Set, nello stesso modo in cui vengono gestiti i file
.VHDX. Ciò significa che il software di gestione non deve conoscere il formato di file VHD Set.

７ Nota

È importante valutare l'impatto dei file VHD Set prima dell'implementazione in

produzione. Assicurarsi che non vi sia alcuna riduzione delle prestazioni o delle
funzionalità nell'ambiente, ad esempio la latenza del disco.

Creare un file di set di VHD da Hyper-V gestore

1. Aprire la console di gestione di Hyper-V. Fare clic su Start, scegliere Strumenti di
amministrazione e quindi fare clic su Hyper-V Manager.
2. Nel riquadro Azione fare clic su Nuovo e quindi su Disco rigido.
3. Nella pagina Scegli formato disco, selezionare Set VHD come formato del disco rigido
virtuale.
4. Continuare attraverso le pagine della procedura guidata per personalizzare il disco rigido
virtuale. È possibile fare clic su Avanti per spostarsi in ogni pagina della procedura
guidata oppure fare clic sul nome di una pagina nel riquadro sinistro per passare
direttamente a tale pagina.
5. Dopo aver completato la configurazione del disco rigido virtuale, fare clic su Fine.
Creare un file Set VHD utilizzando Windows
PowerShell
Usare il cmdlet New-VHD con il tipo di file . VHDS nel percorso del file. Questo esempio crea
un file VHD Set denominato [Link] con una dimensione di 10 Gigabyte.

PowerShell

PS c:\>New-VHD -Path c:\[Link] -SizeBytes 10GB

Migrare un file VHDX condiviso a un file VHD Set

La migrazione di un VHDX condiviso esistente a un VHDS richiede lo spegnimento della
macchina virtuale. Questo è il processo consigliato con Windows PowerShell:

1. Rimuovere il VHDX dalla macchina virtuale. Ad esempio, eseguire:

PowerShell

PS c:\>Remove-VMHardDiskDrive [Link]

2. Convertire il VHDX in un VHDS. Ad esempio, eseguire:

PowerShell

PS c:\>Convert-VHD [Link] [Link]

3. Aggiungere il VHDS alla macchina virtuale. Ad esempio, eseguire:

PowerShell

PS c:\>Add-VMHardDiskDrive [Link]
Gestire in remoto gli host Hyper-V con la
console di gestione di Hyper-V
25/07/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Questo articolo elenca le combinazioni supportate delle versioni degli host Hyper-V e della
console di gestione di Hyper-V e descrive come connettersi a host Hyper-V remoti e locali per
gestirli.

La console di gestione di Hyper-V consente di gestire un numero ridotto di host Hyper-V, sia
remoti che locali. Viene installata quando si installano gli strumenti di gestione di Hyper-V, o
tramite un'installazione completa di Hyper-V o tramite un'installazione di soli strumenti. Se si
esegue un'installazione di solo strumenti, è possibile usare gli strumenti nei computer che non
soddisfano i requisiti hardware per ospitare Hyper-V. Per informazioni dettagliate sull'hardware
per gli host Hyper-V, vedere Requisiti di sistema. Se Hyper-V Manager non è installato, seguire
le istruzioni riportate in Installare Hyper-V Manager.

Connettersi a un host Hyper-V

Per connettersi a un host Hyper-V da Hyper-V Manager, fare clic con il pulsante destro del
mouse suHyper-V Manager nel riquadro sinistro e quindi scegliere Connetti al server.

Gestire Hyper-V in un computer locale

La console di gestione di Hyper-V non elenca i computer che ospitano Hyper-V fino a quando
non si aggiunge il computer, incluso un computer locale. Per eseguire questa operazione:

1. Nel riquadro sinistro fare clic con il pulsante destro del mouse suHyper-V Manager.
2. Selezionare Connetti al server.
3. Da Seleziona computer, selezionare Computer locale e quindi selezionare OK.

La connessione non è riuscita?

È possibile che siano installati solo gli strumenti Hyper-V. Per verificare se è installata
Hyper-V piattaforma, cercare il servizio Virtual Machine Management. A tale scopo, aprire
l'app desktop Servizi: selezionare Start, selezionare la casella Avvia ricerca , digitare
[Link] e quindi premere INVIO. Se il servizio Gestione macchine virtuali non è
elencato, installare la piattaforma Hyper-V seguendo le istruzioni in Installare Hyper-V.
Controllare se l'hardware soddisfa i requisiti. Vedere Requisiti di sistema.
 Assicurarsi che l'account utente appartenga al gruppo Administrators o al gruppo
Administrators Hyper-V.

Gestire gli host Hyper-V in modalità remota

Per gestire gli host Hyper-V remoti, abilitare la gestione remota sia nel computer locale che
nell'host remoto.

Su Windows Server, aprire >server locale>gestione remota e quindi selezionare Consenti

connessioni remote a questo computer.

In alternativa, dal sistema operativo aprire Windows PowerShell come amministratore ed

eseguire:

PowerShell

Enable-PSRemoting

Connettersi agli host nello stesso dominio

Per aggiungere un host Hyper-V remoto a Hyper-V Manager, selezionare Un altro computer
nella finestra di dialogo Seleziona computer e immettere il nome host dell'host remoto, il
nome NetBIOS o il nome di dominio completo (FQDN).

Hyper-V Manager offre più tipi di connessioni remote, descritte nelle sezioni seguenti.

Connettersi a un host remoto come utente diverso

Questa procedura consente di connettersi all'host Hyper-V quando non si è in esecuzione nel
computer locale come utente membro del gruppo Amministratori Hyper-V o del gruppo
Administrators nell'host Hyper-V. Per eseguire questa operazione:

1. Nel riquadro sinistro fare clic con il pulsante destro del mouse suHyper-V Manager.
2. Selezionare Connetti al server.
3. Selezionare Connetti come altro utente nella finestra di dialogo Seleziona computer .
4. Selezionare Imposta utente.

Connettersi a un host remoto usando un indirizzo IP

Per eseguire questa operazione:

1. Nel riquadro sinistro fare clic con il pulsante destro del mouse suHyper-V Manager.
 2. Selezionare Connetti al server.
3. Immettere l'indirizzo IP nella casella Altro computer .

Connettersi a un host remoto al di fuori del tuo dominio o

senza dominio
Per eseguire questa operazione:

1. Nell'host Hyper-V da gestire aprire una sessione di Windows PowerShell come

amministratore.

2. Creare le regole firewall necessarie per le zone di rete private:

PowerShell

Enable-PSRemoting

3. Per consentire l'accesso remoto nelle zone pubbliche, abilitare le regole del firewall per
CredSSP e WinRM:

PowerShell

Enable-WSManCredSSP -Role server

Per informazioni dettagliate, vedere Enable-PSRemoting e Enable-WSManCredSSP.

Configurare quindi il computer che verrà usato per gestire l'host Hyper-V.

1. Aprire una sessione di Windows PowerShell come amministratore.

2. Eseguire i comandi seguenti:

PowerShell

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "fqdn-of-hyper-v-host"

PowerShell

Enable-WSManCredSSP -Role client -DelegateComputer "fqdn-of-hyper-v-host"

3. Potrebbe anche essere necessario configurare i criteri di gruppo seguenti:

Configurazione> computer>Modelli amministrativiSistema>Delega> delle

credenzialiConsentire la delega di credenziali aggiornate con l'autenticazione
 server solo NTLM
Selezionare Abilita e aggiungi wsman/fqdn-of-hyper-v-host.

4. Aprire la console di gestione di Hyper-V.

5. Nel riquadro sinistro fare clic con il pulsante destro del mouse suHyper-V Manager.

6. Selezionare Connetti al server.

Per informazioni dettagliate sui cmdlet, vedere Set-Item e Enable-WSManCredSSP.

Installare la console di gestione di Hyper-V

Per usare uno strumento dell'interfaccia utente, scegliere quello appropriato per il sistema
operativo nel computer in cui si eseguirà Hyper-V Manager:

In Windows Server aprire Server Manager >Gestisci>ruoli e funzionalità. Passare alla pagina
Funzionalità ed espandere Strumenti di amministrazione remota del> serverStrumenti> di
amministrazione ruoloHyper-V strumenti di gestione.

In Windows, la console di gestione di Hyper-V è disponibile in qualsiasi sistema operativo

Windows che include Hyper-V.

1. Sul desktop di Windows selezionare il pulsante Start e iniziare a digitare Programmi e

funzionalità.
2. Nei risultati della ricerca selezionare Programmi e funzionalità.
3. Nel riquadro sinistro selezionare Attiva o disattiva le funzionalità di Windows.
4. Espandere la cartella Hyper-V e selezionare Hyper-V Strumenti di gestione.
5. Per installare Hyper-V Manager, selezionare Hyper-V Strumenti di gestione. Se si vuole
installare anche il modulo Hyper-V, selezionare questa opzione.

Per usare Windows PowerShell, eseguire il comando seguente come amministratore:

PowerShell

add-windowsfeature rsat-hyper-v-tools

Related content
Install Hyper-V
Hyper-V Gestione delle Risorse della CPU
dell'Host
14/07/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Hyper-V controlli delle risorse della CPU host introdotti in Windows Server 2016 o versioni
successive consentono agli amministratori di Hyper-V di gestire e allocare meglio le risorse
della CPU del server host tra la "radice", la partizione di gestione e le macchine virtuali guest.
Usando questi controlli, gli amministratori possono dedicare un subset dei processori di un
sistema host alla partizione radice. In questo modo è possibile separare il lavoro svolto in un
host Hyper-V dai carichi di lavoro in esecuzione nelle macchine virtuali guest eseguendoli in
subset separati dei processori di sistema.

Per informazioni dettagliate sull'hardware per gli host Hyper-V, vedere Requisiti di sistema di
Windows 10 Hyper-V.

Background
Prima di impostare i controlli per Hyper-V risorse della CPU host, è utile esaminare le nozioni di
base dell'architettura Hyper-V. You can find a general summary in the Hyper-V Architecture
section. Questi sono concetti importanti per questo articolo:

Hyper-V crea e gestisce le partizioni di macchine virtuali, in cui le risorse di calcolo

vengono allocate e condivise, sotto il controllo dell'hypervisor. Le partizioni forniscono
limiti di isolamento sicuri tra tutte le macchine virtuali guest e tra le macchine virtuali
guest e la partizione radice.

La partizione radice è una partizione di macchina virtuale, anche se dispone di proprietà

univoce e privilegi molto maggiori rispetto alle macchine virtuali guest. La partizione
radice fornisce i servizi di gestione che controllano tutte le macchine virtuali guest,
fornisce supporto per i dispositivi virtuali virtuali per gli utenti guest e gestisce tutte le
operazioni di I/O del dispositivo per le macchine virtuali guest. Microsoft consiglia
vivamente di non eseguire carichi di lavoro di applicazioni in una partizione host.

Ogni processore virtuale (VP) della partizione radice è mappato 1:1 a un processore
logico sottostante (LP). Un VP host verrà sempre eseguito sullo stesso LP sottostante. Non
esiste alcuna migrazione dei VP della partizione radice.

Per impostazione predefinita, i processori logici (LP) su cui vengono eseguiti i VP dell'host
possono anche eseguire i VP ospite.
 Un VP guest può essere pianificato dall'hypervisor per l'esecuzione su qualsiasi
processore logico disponibile. Anche se il gestore di pianificazione dell'hypervisor si
occupa di prendere in considerazione la localizzazione temporale della cache, la
topologia NUMA e molti altri fattori durante la pianificazione di una VP guest, alla fine il
VP può essere assegnato a qualsiasi LP dell'host.

Configurazione minima radice o "Minroot"

Le versioni precedenti di Hyper-V avevano un limite massimo di architettura di 64 VP per
partizione. Questa operazione viene applicata sia alle partizioni radice che a quella guest.
Poiché i sistemi con più di 64 processori logici sono apparsi su server di fascia alta, Hyper-V
hanno anche evoluto i limiti di scalabilità host per supportare questi sistemi di dimensioni
maggiori, a un certo punto supportando un host con un massimo di 320 LP. Tuttavia, superare
il limite di 64 VP per partizione a quel tempo ha presentato diverse sfide e ha introdotto
complessità che hanno reso impossibile il supporto di più di 64 VP per ogni partizione. Per
risolvere questo problema, Hyper-V limitato il numero di VP assegnati alla partizione radice a
64, anche se il computer sottostante aveva molti più processori logici disponibili. L'hypervisor
continuerebbe a utilizzare tutti i processori logici disponibili per eseguire VP guest, ma
limiterebbe artificialmente la partizione radice a 64. Questa configurazione è diventata nota
come configurazione "radice minima" o "minroot". I test delle prestazioni hanno confermato
che, anche in sistemi su larga scala con più di 64 LP, non è necessario utilizzare più di 64 VP
radice per supportare adeguatamente un numero elevato di macchine virtuali guest e VP
guest. In realtà, spesso molto meno di 64 VP radice è sufficiente, a seconda del numero e delle
dimensioni delle macchine virtuali guest, dei carichi di lavoro specifici in esecuzione e così via.

Questo concetto di "minroot" continua a essere utilizzato oggi. Infatti, anche se Windows
Server 2016 Hyper-V ha aumentato il limite massimo di supporto dell'architettura per gli LP
host a 512, la partizione radice sarà comunque limitata a un massimo di 320 LP.

Uso di Minroot per vincolare e isolare le risorse di

calcolo host
Con la soglia predefinita elevata di 320 LP in Windows Server 2016 Hyper-V, la configurazione
minroot verrà usata solo nei sistemi server molto più grandi. Tuttavia, questa funzionalità può
essere configurata su una soglia molto inferiore dall'amministratore host Hyper-V e quindi
sfruttata per limitare notevolmente la quantità di risorse della CPU host disponibili per la
partizione radice. Il numero specifico di indirizzi IP radice da usare deve naturalmente essere
scelto con attenzione per supportare le richieste massime delle macchine virtuali e dei carichi
di lavoro allocati all'host. Tuttavia, i valori ragionevoli per il numero di LP host possono essere
determinati tramite un'attenta valutazione e monitoraggio dei carichi di lavoro di produzione e
convalidati in ambienti non di produzione prima della distribuzione generale.

Abilitazione e configurazione di Minroot

La configurazione minroot viene controllata tramite le voci BCD dell'hypervisor. Per abilitare
minroot, da un prompt dei comandi con privilegi di amministratore:

bcdedit /set hypervisorrootproc n

Dove n è il numero di VP radice.

Il sistema deve essere riavviato e il nuovo numero di processori radice verrà mantenuto per
tutta la durata dell'avvio del sistema operativo. La configurazione minroot non può essere
modificata in modo dinamico in fase di esecuzione.

Se sono presenti più nodi NUMA, ogni nodo otterrà n/NumaNodeCount processori.

Si noti che con più nodi NUMA, è necessario assicurarsi che la topologia della VM sia tale che
siano presenti sufficienti LP liberi (ad esempio, LP senza VP di root) per ogni nodo NUMA per
eseguire i VP del nodo NUMA della relativa VM.

Verifica della configurazione minroot

È possibile verificare la configurazione minroot dell'host usando Gestione attività, come
illustrato di seguito.
Quando Minroot è attivo, Gestione attività visualizzerà il numero di processori logici
attualmente assegnati all'host, oltre al numero totale di processori logici nel sistema.
Controlli delle risorse della macchina
virtuale
Articolo • 02/11/2024 •
Si ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
applica Windows Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Stack HCI, versions
a: 23H2 and 22H2

Questo articolo descrive i controlli delle risorse e dell'isolamento di Hyper-V per le

macchine virtuali. Queste funzionalità, a cui ci si riferirà come gruppi di CPU di macchine
virtuali, o semplicemente "gruppi di CPU", sono state introdotte in Windows Server
2016. I gruppi di CPU consentono agli amministratori di Hyper-V di gestire e allocare
meglio le risorse CPU dell'host tra le macchine virtuali guest. Usando i gruppi di CPU, gli
amministratori di Hyper-V possono:

Creare gruppi di macchine virtuali, con ogni gruppo che con allocazioni diverse
delle risorse CPU totali dell'host di virtualizzazione, condivise dall'intero gruppo. In
questo modo l'amministratore host può implementare classi di servizio per diversi
tipi di macchine virtuali.

Impostare i limiti delle risorse della CPU a gruppi specifici. Il "limite di gruppo"
stabilisce il limite massimo di risorse della CPU host che l'intero gruppo può usare,
applicando in modo efficace la classe di servizio desiderata per quel gruppo.

Vincola un gruppo di CPU per l’esecuzione in un solo set specifico di processori del
sistema host. Ciò può essere usato per isolare tra loro le macchine virtuali
appartenenti a gruppi di CPU diversi.

Gestione dei gruppi di CPU

I gruppi di CPU vengono gestiti tramite il servizio di calcolo host Hyper-V o HCS.
Un'ottima descrizione dell'HCS, la sua genesi, i collegamenti alle API HCS e altro ancora
sono disponibili sul blog del team di virtualizzazione Microsoft nel post Introduzione al
servizio HCS (Host Compute Service) .

７ Nota
 Solo il servizio HCS può essere usato per creare e gestire i gruppi di CPU. L’applet
Hyper-V Manager, le interfacce di gestione WMI e PowerShell non supportano i
gruppi di CPU.

Microsoft fornisce un'utilità a riga di comando, [Link], nell’Area download

Microsoft che usa l'interfaccia HCS per gestire i gruppi di CPU. Questa utility può
anche visualizzare la topologia della CPU di un host.

Funzionamento dei gruppi di CPU

L'allocazione delle risorse di calcolo host tra i gruppi di CPU viene applicata
dall'hypervisor Hyper-V, usando un limite massimo calcolato per i gruppi di CPU. Il
limite massimo del gruppo di CPU è una frazione della capacità totale della CPU per un
gruppo di CPU. Il valore del limite di gruppo dipende dalla classe di gruppo o dal livello
di priorità assegnato. Il limite di gruppo calcolato può essere considerato come "un
certo numero di tempo della CPU degli LP". Il budget del gruppo è condiviso, quindi se
una sola macchina virtuale fosse attiva, potrebbe usare l'intera allocazione del CPU del
gruppo per se stessa.

Il limite di gruppo della CPU viene calcolato come G = n x C, dove:

G è la quantità di LP host da assegnare al gruppo

n è il numero totale di processori logici (LP) nel gruppo
C è l'allocazione massima della CPU, ovvero la classe di servizio desiderata per il
gruppo, espressa come percentuale della capacità di calcolo totale del sistema

Ad esempio, si consideri un gruppo di CPU configurato con 4 processori logici (LP) e un

limite del 50%.

G=n*C
G = 4 * 50%
G = 2 LP di tempo della CPU per l'intero gruppo

In questo esempio, al gruppo di CPU G vengono assegnati 2 LP di tempo della CPU.

Si noti che il limite del gruppo si applica indipendentemente dal numero di macchine
virtuali o di processori virtuali associati al gruppo e dallo stato (ad esempio, arrestato o
avviato) delle macchine virtuali assegnate al gruppo di CPU. Pertanto, ogni macchina
virtuale associata allo stesso gruppo di CPU riceverà una frazione dell'allocazione totale
della CPU del gruppo, che cambierà con il numero di macchine virtuali associate al
gruppo di CPU. Pertanto, man mano che le macchine virtuali vengono associate o non
associate da un gruppo di CPU, il limite complessivo del gruppo di CPU deve essere
riadattato e impostato per mantenere il limite massimo per macchina virtuale
desiderata. L'amministratore host della macchina virtuale o il livello del software di
gestione della virtualizzazione è responsabile della gestione dei limiti di gruppo, in base
alle esigenze di ottenere l'allocazione desiderata delle risorse CPU per macchina virtuale.

Esempi di classi di servizio

Vediamo alcuni semplici esempi. Per iniziare, si supponga che l'amministratore host
Hyper-V voglia supportare due livelli di servizio per le macchine virtuali guest:

1. Un livello "C" di fascia bassa. A questo livello verrà assegnato il 10% delle risorse di
calcolo dell'intero host.

2. Un livello "B" di media grandezza. A questo livello viene assegnato il 50% delle
risorse di calcolo dell'intero host.

A questo punto dell’esempio si asserisce che non sono in uso altri controlli sulle risorse
della CPU, come ad esempio i limiti, i pesi e le riserve delle singole macchine virtuali.
Tuttavia, i limiti delle singole macchine virtuali sono importanti, come si vedrà più avanti.

Per semplicità, si supponga che ogni macchina virtuale abbia 1 VP e che l’host abbia 8
LP. Si inizierà con un host vuoto.

Per creare il livello "B", l'amministratore host imposta il limite del gruppo al 50%:

G=n*C
G = 8 * 50%
G = 4 LP di tempo della CPU per l'intero gruppo

L'amministratore host aggiunge una singola macchina virtuale di livello "B". A questo
punto, la macchina virtuale di livello "B" può usare al massimo il 50% della CPU dell'host,
ovvero l'equivalente di 4 LP nel sistema di esempio.

A questo punto, l'amministratore aggiunge una seconda macchina virtuale di "Livello B".
L'allocazione del gruppo di CPU viene suddivisa in modo uniforme tra tutte le macchine
virtuali. Nel gruppo B sono presenti un totale di 2 macchine virtuali, quindi ogni
macchina virtuale ora ottiene la metà del 50% del totale del gruppo B, il 25% ciascuno, o
l'equivalente di 2 LP di tempo di calcolo.

Impostazione dei limiti di CPU in singole

macchine virtuali
Oltre al limite di gruppo, ogni macchina virtuale può avere un "limite di macchina
virtuale" individuale. I controlli delle risorse CPU per macchina virtuale, inclusi il limite
massimo, il peso e la riserva della CPU, fanno parte di Hyper-V fin dalla sua
introduzione. Se combinato con un limite di gruppo, un limite di macchina virtuale
specifica la quantità massima di CPU che ogni VP può ottenere, anche se il gruppo ha
risorse CPU disponibili.

Ad esempio, l'amministratore host potrebbe voler inserire un limite del 10% alle
macchine virtuali "C". In questo modo, anche se la maggior parte dei VP "C" sono
inattivi, ogni VP non potrebbe mai ottenere più del 10%. Senza un limite per le
macchine virtuali, le macchine virtuali "C" potrebbero ottenere opportunisticamente
prestazioni superiori ai livelli consentiti dal loro livello.

Isolamento dei gruppi di macchine virtuali su

processori host specifici
Gli amministratori host Hyper-V potrebbero anche voler dedicare risorse di calcolo a
una macchina virtuale. Ad esempio, si supponga che l'amministratore voglia offrire una
macchina virtuale premium "A" con un limite di classe del 100%. Queste macchine
virtuali premium richiedono anche una latenza di pianificazione e il jitter più bassi
possibili; ovvero, non possono essere depianificato da nessun'altra macchina virtuale.
Per ottenere questa separazione, un gruppo di CPU può anche essere configurato con
un mapping di affinità LP specifico.

Ad esempio, per inserire una macchina virtuale "A" nell'host del nostro esempio,
l'amministratore dovrebbe creare un nuovo gruppo di CPU e impostare l'affinità del
processore del gruppo su un subset degli LP dell'host. I gruppi B e C verrebbero
raggruppati con i restanti LP. L'amministratore potrebbe creare una singola macchina
virtuale nel gruppo A, che avrebbe accesso esclusivo a tutti gli LP del gruppo A, mentre i
gruppi B e C, presumibilmente di livello inferiore, condividerebbero gli LP rimanenti.

Separazione di VP radice da VP guest

Per impostazione predefinita, Hyper-V creerà una VP radice in ogni LP fisico sottostante.
Questi VP radice sono rigorosamente mappati 1:1 con gli LP del sistema e non
eseguono la migrazione, ovvero ogni VP radice verrà sempre eseguito sullo stesso LP
fisico. I VP guest possono essere eseguiti in qualsiasi LP disponibile e condividono
l'esecuzione con i VP radice.

Tuttavia, potrebbe essere consigliabile separare completamente l'attività VP radice da

quella VP guest. Si prenda in considerazione l'esempio precedente, in cui viene
implementata una macchina virtuale di livello premium "A". Per garantire che i VP della
macchina virtuale "A" abbiano la latenza e il "jitter" più bassi possibili, o variazione di
schedulazione, è consigliabile eseguirli in un set dedicato di LP e assicurarsi che la radice
non venga eseguita in questi LP.

Ciò può essere ottenuto usando una combinazione di configurazione "minroot", che
limita l'esecuzione della partizione del sistema operativo host su un subset dei
processori logici totali del sistema, insieme a uno o più gruppi di CPU affini.

L'host di virtualizzazione può essere configurato in modo da limitare la partizione

dell'host a LP specifici, con uno o più gruppi di CPU affini agli LP rimanenti. In questo
modo, le partizioni radice e guest possono essere eseguite su risorse CPU dedicate e
completamente isolate, senza condividere la CPU.

Per altre informazioni sulla configurazione "minroot", vedere Gestione delle risorse CPU
host Hyper-V.

Uso dello strumento CpuGroups

Ecco alcuni esempi di utilizzo dello strumento CpuGroups.

７ Nota

I parametri della riga di comando per lo strumento CpuGroups vengono passati

usando solo gli spazi come delimitatori. Nessun carattere "/" o "-" deve precedere il
passaggio della riga di comando desiderata.

Individuare la topologia della CPU

L'esecuzione di CpuGroups con GetCpuTopology restituisce informazioni sul sistema
corrente, come illustrato di seguito, tra cui l'indice LP, il nodo NUMA a cui appartiene
l'LP, gli ID pacchetto e core e l'indice ROOT VP.

L'esempio seguente mostra un sistema con 2 socket CPU e nodi NUMA, un totale di 32
LP, multithreading abilitato e configurato per abilitare Minroot con 8 VP root, 4 da ogni
nodo NUMA. Gli LP che hanno VP radice hanno un RootVpIndex >= 0; gli LP con un
RootVpIndex pari a -1 non sono disponibili per la partizione radice, ma sono comunque
gestiti dall'hypervisor ed eseguiranno VP guest come consentito da altre impostazioni di
configurazione.

Console
 C:\vm\tools>[Link] GetCpuTopology

LpIndex NodeNumber PackageId CoreId RootVpIndex

------- ---------- --------- ------ -----------
0 0 0 0 0
1 0 0 0 1
2 0 0 1 2
3 0 0 1 3
4 0 0 2 -1
5 0 0 2 -1
6 0 0 3 -1
7 0 0 3 -1
8 0 0 4 -1
9 0 0 4 -1
10 0 0 5 -1
11 0 0 5 -1
12 0 0 6 -1
13 0 0 6 -1
14 0 0 7 -1
15 0 0 7 -1
16 1 1 16 4
17 1 1 16 5
18 1 1 17 6
19 1 1 17 7
20 1 1 18 -1
21 1 1 18 -1
22 1 1 19 -1
23 1 1 19 -1
24 1 1 20 -1
25 1 1 20 -1
26 1 1 21 -1
27 1 1 21 -1
28 1 1 22 -1
29 1 1 22 -1
30 1 1 23 -1
31 1 1 23 -1

Esempio 2 - Stampare tutti i gruppi di CPU nell'host

Qui vengono elencati tutti i gruppi di CPU nell'host corrente, il relativo GroupId, il tetto
di CPU del gruppo e gli indici degli LP assegnati a quel gruppo.

Si noti che i valori validi del limite di CPU sono compresi nell'intervallo [0, 65536] e che
questi valori esprimono il limite di gruppo in percentuale (ad esempio, 32768 = 50%).

Console

C:\vm\tools>[Link] GetGroups

CpuGroupId CpuCap LpIndexes

 ------------------------------------ ------ --------
36AB08CB-3A76-4B38-992E-000000000002 32768 4,5,6,7,8,9,10,11,20,21,22,23
36AB08CB-3A76-4B38-992E-000000000003 65536 12,13,14,15
36AB08CB-3A76-4B38-992E-000000000004 65536 24,25,26,27,28,29,30,31

Esempio 3 - Stampare un singolo gruppo di CPU

In questo esempio, verrà eseguita una query su un singolo gruppo di CPU usando il
GroupId come filtro.

Console

C:\vm\tools>[Link] GetGroups /GroupId:36AB08CB-3A76-4B38-992E-

000000000003
CpuGroupId CpuCap LpIndexes
------------------------------------ ------ ----------
36AB08CB-3A76-4B38-992E-000000000003 65536 12,13,14,15

Esempio 4 - Creare un nuovo gruppo di CPU

In questo caso verrà creato un nuovo gruppo di CPU, specificando l'ID del gruppo e il
set di LP da assegnare al gruppo.

Console

C:\vm\tools>[Link] CreateGroup /GroupId:36AB08CB-3A76-4B38-992E-

000000000001 /GroupAffinity:0,1,16,17

Ora verrà visualizzato il gruppo appena aggiunto.

Console

C:\vm\tools>[Link] GetGroups
CpuGroupId CpuCap LpIndexes
------------------------------------ ------ ---------
36AB08CB-3A76-4B38-992E-000000000001 65536 0,1,16,17
36AB08CB-3A76-4B38-992E-000000000002 32768 4,5,6,7,8,9,10,11,20,21,22,23
36AB08CB-3A76-4B38-992E-000000000003 65536 12,13,14,15
36AB08CB-3A76-4B38-992E-000000000004 65536 24,25,26,27,28,29,30,31

Esempio 5 - Impostare il limite massimo del gruppo CPU

al 50%
Esempio 50 - Impostare il limite massimo del gruppo CPU al 50%.
 Console

C:\vm\tools>[Link] SetGroupProperty /GroupId:36AB08CB-3A76-4B38-992E-

000000000001 /CpuCap:32768

A questo punto sarà possibile confermare l’impostazione visualizzando il gruppo

appena aggiornato.

Console

C:\vm\tools>[Link] GetGroups /GroupId:36AB08CB-3A76-4B38-992E-

000000000001

CpuGroupId CpuCap LpIndexes

------------------------------------ ------ ---------
36AB08CB-3A76-4B38-992E-000000000001 32768 0,1,16,17

Esempio 6 - Stampare gli ID gruppo CPU per tutte le

macchine virtuali nell'host
Console

C:\vm\tools>[Link] GetVmGroup

VmName VmId
CpuGroupId
------ ------------------------------------ --------------------------------
----
G2 4ABCFC2F-6C22-498C-BB38-7151CE678758 36ab08cb-3a76-4b38-992e-
000000000002
P1 973B9426-0711-4742-AD3B-D8C39D6A0DEC 36ab08cb-3a76-4b38-992e-
000000000003
P2 A593D93A-3A5F-48AB-8862-A4350E3459E8 36ab08cb-3a76-4b38-992e-
000000000004
G3 B0F3FCD5-FECF-4A21-A4A2-DE4102787200 36ab08cb-3a76-4b38-992e-
000000000002
G1 F699B50F-86F2-4E48-8BA5-EB06883C1FDC 36ab08cb-3a76-4b38-992e-
000000000002

Esempio 7 - Annullare l’associazione di una macchina

virtuale dal gruppo di CPU
Per rimuovere una macchina virtuale da un gruppo di CPU, impostare CpuGroupId della
macchina virtuale sul GUID NULL. Questa operazione annulla l'associazione della
macchina virtuale dal gruppo di CPU.
 Console

C:\vm\tools>[Link] SetVmGroup /VmName:g1 /GroupId:00000000-0000-0000-

0000-000000000000

C:\vm\tools>[Link] GetVmGroup
VmName VmId
CpuGroupId
------ ------------------------------------ --------------------------------
----
G2 4ABCFC2F-6C22-498C-BB38-7151CE678758 36ab08cb-3a76-4b38-992e-
000000000002
P1 973B9426-0711-4742-AD3B-D8C39D6A0DEC 36ab08cb-3a76-4b38-992e-
000000000003
P2 A593D93A-3A5F-48AB-8862-A4350E3459E8 36ab08cb-3a76-4b38-992e-
000000000004
G3 B0F3FCD5-FECF-4A21-A4A2-DE4102787200 36ab08cb-3a76-4b38-992e-
000000000002
G1 F699B50F-86F2-4E48-8BA5-EB06883C1FDC 00000000-0000-0000-0000-
000000000000

Esempio 8 – Associare una macchina virtuale a un gruppo

di CPU esistente
In questo caso, si aggiungerà una macchina virtuale a un gruppo di CPU esistente. Si
noti che la macchina virtuale non deve essere associata a nessun gruppo di CPU
esistente, altrimenti l'impostazione dell'id del gruppo di CPU avrà esito negativo.

Console

C:\vm\tools>[Link] SetVmGroup /VmName:g1 /GroupId:36AB08CB-3A76-4B38-

992E-000000000001

Verificare ora che la macchina virtuale G1 si trovi nel gruppo di CPU desiderato.

Console

C:\vm\tools>[Link] GetVmGroup
VmName VmId
CpuGroupId
------ ------------------------------------ --------------------------------
----
G2 4ABCFC2F-6C22-498C-BB38-7151CE678758 36ab08cb-3a76-4b38-992e-
000000000002
P1 973B9426-0711-4742-AD3B-D8C39D6A0DEC 36ab08cb-3a76-4b38-992e-
000000000003
P2 A593D93A-3A5F-48AB-8862-A4350E3459E8 36ab08cb-3a76-4b38-992e-
000000000004
 G3 B0F3FCD5-FECF-4A21-A4A2-DE4102787200 36ab08cb-3a76-4b38-992e-
000000000002
G1 F699B50F-86F2-4E48-8BA5-EB06883C1FDC 36AB08CB-3A76-4B38-992E-
000000000001

Esempio 9 - Stampare tutte le macchine virtuali

raggruppate per id gruppo CPU
Console

C:\vm\tools>[Link] GetGroupVms
CpuGroupId VmName
VmId
------------------------------------ ------ --------------------------------
----
36AB08CB-3A76-4B38-992E-000000000001 G1 F699B50F-86F2-4E48-8BA5-
EB06883C1FDC
36ab08cb-3a76-4b38-992e-000000000002 G2 4ABCFC2F-6C22-498C-BB38-
7151CE678758
36ab08cb-3a76-4b38-992e-000000000002 G3 B0F3FCD5-FECF-4A21-A4A2-
DE4102787200
36ab08cb-3a76-4b38-992e-000000000003 P1 973B9426-0711-4742-AD3B-
D8C39D6A0DEC
36ab08cb-3a76-4b38-992e-000000000004 P2 A593D93A-3A5F-48AB-8862-
A4350E3459E8

Esempio 10 - Stampare tutte le macchine virtuali per un

singolo gruppo di CPU
Console

C:\vm\tools>[Link] GetGroupVms /GroupId:36ab08cb-3a76-4b38-992e-

000000000002

CpuGroupId VmName
VmId
------------------------------------ ------ --------------------------------
----
36ab08cb-3a76-4b38-992e-000000000002 G2 4ABCFC2F-6C22-498C-BB38-
7151CE678758
36ab08cb-3a76-4b38-992e-000000000002 G3 B0F3FCD5-FECF-4A21-A4A2-
DE4102787200

Esempio 11 - Tentativo di eliminare un Gruppo CPU non

vuoto
È possibile eliminare solo i gruppi di CPU vuoti, ossia quelli senza macchine virtuali
associate. Il tentativo di eliminare un gruppo di CPU non vuoto avrà esito negativo.

Console

C:\vm\tools>[Link] DeleteGroup /GroupId:36ab08cb-3a76-4b38-992e-

000000000001
(null)
Failed with error 0xc0350070

Esempio 12 - Annullare l’associazione dell'unica macchina

virtuale da un gruppo di CPU ed eliminare il gruppo
In questo esempio, si useranno diversi comandi per esaminare un gruppo di CPU,
rimuovere la singola macchina virtuale appartenente a quel gruppo e quindi eliminare il
gruppo.

Prima di tutto, enumeriamo le macchine virtuali del gruppo.

Console

C:\vm\tools>[Link] GetGroupVms /GroupId:36AB08CB-3A76-4B38-992E-

000000000001
CpuGroupId VmName
VmId
------------------------------------ ------ --------------------------------
----
36AB08CB-3A76-4B38-992E-000000000001 G1 F699B50F-86F2-4E48-8BA5-
EB06883C1FDC

Si noterà che solo una singola macchina virtuale, denominata G1, appartiene a questo
gruppo. Si rimuoverà la macchina virtuale G1 dal gruppo impostando l'ID del gruppo
della macchina virtuale su NULL.

Console

C:\vm\tools>[Link] SetVmGroup /VmName:g1 /GroupId:00000000-0000-0000-

0000-000000000000

E verificare la modifica...

Console

C:\vm\tools>[Link] GetVmGroup /VmName:g1

VmName VmId
 CpuGroupId
------ ------------------------------------ --------------------------------
----
G1 F699B50F-86F2-4E48-8BA5-EB06883C1FDC 00000000-0000-0000-0000-
000000000000

Ora che il gruppo è vuoto, è possibile eliminarlo in modo sicuro.

Console

C:\vm\tools>[Link] DeleteGroup /GroupId:36ab08cb-3a76-4b38-992e-

000000000001

E confermare che il gruppo è scomparso.

Console

C:\vm\tools>[Link] GetGroups
CpuGroupId CpuCap LpIndexes
------------------------------------ ------ -----------------------------
36AB08CB-3A76-4B38-992E-000000000002 32768 4,5,6,7,8,9,10,11,20,21,22,23
36AB08CB-3A76-4B38-992E-000000000003 65536 12,13,14,15
36AB08CB-3A76-4B38-992E-000000000004 65536 24,25,26,27,28,29,30,31

Esempio 13 – Associare una macchina virtuale al gruppo

di CPU originale
Console

C:\vm\tools>[Link] SetVmGroup /VmName:g1 /GroupId:36AB08CB-3A76-4B38-

992E-000000000002

C:\vm\tools>[Link] GetGroupVms
CpuGroupId VmName VmId
------------------------------------ -------------------------------- ------
------------------------------
36ab08cb-3a76-4b38-992e-000000000002 G2 4ABCFC2F-6C22-498C-BB38-7151CE678758
36ab08cb-3a76-4b38-992e-000000000002 G3 B0F3FCD5-FECF-4A21-A4A2-DE4102787200
36AB08CB-3A76-4B38-992E-000000000002 G1 F699B50F-86F2-4E48-8BA5-EB06883C1FDC
36ab08cb-3a76-4b38-992e-000000000003 P1 973B9426-0711-4742-AD3B-D8C39D6A0DEC
36ab08cb-3a76-4b38-992e-000000000004 P2 A593D93A-3A5F-48AB-8862-A4350E3459E8

Commenti e suggerimenti
Questa pagina è stata utile?  Sì  No
Gestire Hyper-V tipi di utilità di
pianificazione dell'hypervisor
Articolo • 30/04/2025 •
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Azure Local 2311.2 and later

Questo articolo descrive le modalità della logica di pianificazione del processore virtuale in
Windows Server e Windows. Queste modalità, o tipi di scheduler, determinano come
l'hypervisor Hyper-V alloca e gestisce il lavoro tra i processori virtuali guest. Un amministratore
host Hyper-V può:

Selezionare i tipi di scheduler hypervisor più adatti per le macchine virtuali guest.
Configurare le macchine virtuali per sfruttare la logica di pianificazione.

Sfondo
Prima di considerare la logica e i controlli alla base della pianificazione del processore virtuale
Hyper-V, è importante comprendere alcuni concetti come il multithreading simultaneo (SMT) e
come Hyper-V virtualizzi i processori.

Informazioni su SMT
SMT è una tecnica nella progettazione moderna del processore che consente a thread di
esecuzione separati e indipendenti di condividere le risorse del processore. SMT offre in genere
un aumento modesto delle prestazioni per i carichi di lavoro. Parallelizza i calcoli quando
possibile, aumentando la velocità effettiva delle istruzioni. Tuttavia, quando i thread
competono tra loro per le risorse del processore condiviso, a volte non c'è un miglioramento
notevole delle prestazioni. Potrebbe anche verificarsi un lieve calo delle prestazioni.

Per usare SMT con Windows Server, è necessario disporre di un processore compatibile. I
processori con Intel Hyper-Threading Technology (Intel HT Technology) o SMT Advanced Micro
Devices (AMD) sono esempi di processori compatibili.

Ai fini di questo articolo, le descrizioni di SMT e il modo in cui vengono usate da Hyper-V si
applicano allo stesso modo ai sistemi Intel e AMD.

Per ulteriori informazioni sulla tecnologia Intel HT, consultare Intel Hyper-Threading
Technology .
Per altre informazioni su AMD SMT, vedere Architettura core AMD "Zen".
Comprendere come Hyper-V virtualizza i processori
Prima di prendere in considerazione i tipi di scheduler dell'hypervisor, è necessario
comprendere l'architettura Hyper-V. Per un riepilogo dettagliato del funzionamento di questa
architettura, vedere panoramica della tecnologiaHyper-V. Per il momento, tenere presenti i
concetti seguenti:

Hyper-V crea e gestisce le partizioni di macchine virtuali, l'allocazione e la condivisione

delle risorse di calcolo tra di esse, sotto il controllo dell'hypervisor. Le partizioni
forniscono limiti di isolamento sicuri tra tutte le macchine virtuali guest e tra le macchine
virtuali guest e la partizione radice.

La partizione radice è una partizione di macchina virtuale, anche se dispone di proprietà

univoce e privilegi maggiori rispetto alle macchine virtuali guest. Partizione radice:
Fornisce servizi di gestione che controllano tutte le macchine virtuali guest.
Fornisce supporto per dispositivi virtuali per gli ospiti.
Gestisce tutti gli input e l'output del dispositivo per le macchine virtuali guest.

È consigliabile non eseguire carichi di lavoro dell'applicazione nella partizione radice.

Esiste una corrispondenza uno-a-uno tra i processori virtuali della partizione radice e i
processori logici sottostanti. Un processore virtuale host viene sempre eseguito sullo
stesso processore logico sottostante. Non esiste alcuna migrazione dei processori virtuali
di partizione radice.

Per impostazione predefinita, i processori logici che ospitano i processori virtuali di

partizione radice possono anche eseguire processori virtuali guest.

L'hypervisor può pianificare l'esecuzione di un processore virtuale guest in qualsiasi

processore logico disponibile. L'utilità di pianificazione dell'hypervisor tenta di
considerare la località temporale della cache, la topologia NUMA (Accesso Non Uniforme
alla Memoria) e molti altri fattori quando pianifica un processore virtuale ospite. In
definitiva, il processore virtuale può essere pianificato in qualsiasi processore logico host.

Tipi di pianificatori hypervisor

L'hypervisor Hyper-V supporta diverse modalità di logica del pianificatore, che determinano
come l'hypervisor pianifica i processori virtuali sui processori logici sottostanti. Questi tipi di
schedulatori sono:

Utilità di pianificazione classica

Utilità di pianificazione di base
Schedulatore principale
Il pianificatore classico
L'utilità di pianificazione classica è l'utilità di pianificazione predefinita usata in tutte le versioni
di Hyper-V precedenti a Windows Server 2019. Il pianificatore classico offre un modello di
pianificazione a equa ripartizione, preemptive e round robin per i processori virtuali guest.

Il tipo di pianificatore classico è appropriato per la maggior parte degli utilizzi tradizionali di
Hyper-V, ad esempio cloud privati, provider di hosting e altro. Le caratteristiche delle
prestazioni del tipo di utilità di pianificazione classica sono ottimizzate per supportare
un'ampia gamma di scenari di virtualizzazione, ad esempio:

Allocazione eccessiva dei processori virtuali ai processori logici.

Esecuzione di più macchine virtuali e carichi di lavoro eterogenei contemporaneamente.
Esecuzione di macchine virtuali con prestazioni elevate su larga scala.
Supporto del set completo di funzionalità di Hyper-V senza restrizioni e altri scenari.

Utilità di pianificazione di base

L'utilità di pianificazione principale dell'hypervisor è un'alternativa alla logica classica dell'utilità
di pianificazione. L'utilità di pianificazione principale è disponibile a partire da Windows Server
2016 e Windows 10 versione 1607. Il pianificatore centrale offre una solida protezione di
sicurezza per l'isolamento del carico di lavoro guest. Riduce inoltre la variabilità delle
prestazioni per i carichi di lavoro all'interno di macchine virtuali eseguite in un host di
virtualizzazione abilitato per SMT. L'utilità di pianificazione principale supporta l'esecuzione
contemporaneamente di macchine virtuali SMT e non SMT nello stesso host di virtualizzazione
abilitato per SMT.

Pianificatore principale

Usa la topologia SMT dell'host di virtualizzazione.

Facoltativamente, espone le coppie SMT alle macchine virtuali guest.
Pianifica gruppi di processori virtuali guest dalla stessa macchina virtuale ai gruppi di
processori logici SMT.

Questo lavoro avviene simmetricamente. Se i processori logici si trovano in gruppi di due, i

processori virtuali vengono pianificati in gruppi di due e un core non viene mai condiviso tra le
macchine virtuali. Quando si pianifica un processore virtuale per una macchina virtuale senza
SMT abilitato, tale processore virtuale utilizza l'intero core quando viene eseguito. Quando si
usa l'utilità di pianificazione principale:

Crea un forte limite di sicurezza per l'isolamento del carico di lavoro ospite. I processori
virtuali guest possono essere eseguiti solo su coppie di core fisici sottostanti, riducendo la
vulnerabilità agli attacchi di ascolto via canale laterale.
 Riduce la variabilità nella velocità effettiva.
Può potenzialmente ridurre le prestazioni. Se solo un processore virtuale in un gruppo
può essere eseguito, solo uno dei flussi di istruzioni nel nucleo viene avviato. L'altra
rimane inattiva.
Il sistema operativo e le applicazioni in esecuzione nella macchina virtuale guest possono
usare il comportamento SMT e le API (Programming Interface) per controllare e
distribuire il lavoro tra thread SMT, proprio come fanno con un computer fisico.

A partire da Windows Server 2019, Hyper-V usa l'utilità di pianificazione principale per
impostazione predefinita. Nelle versioni precedenti, ad esempio Windows Server 2016, l'utilità
di pianificazione principale è facoltativa e l'utilità di pianificazione classica è quella predefinita.

Comportamento del pianificatore principale con SMT dell'host

disabilitato

In alcuni casi, è possibile configurare l'hypervisor per l'uso del tipo di utilità di pianificazione
principale, ma la funzionalità SMT è disabilitata o non è presente nell'host di virtualizzazione. In
questi casi, Hyper-V utilizza il comportamento classico del gestore di pianificazione,
indipendentemente dall'impostazione del tipo di gestore di pianificazione dell'hypervisor.

Pianificatore principale
L'utilità di pianificazione radice è arrivata con Windows 10, versione 1803. Quando si abilita il
tipo di schedulatore root, l'hypervisor concede il controllo alla partizione radice per la
pianificazione delle attività di lavoro. Nell'istanza del sistema operativo della partizione radice,
l'utilità di pianificazione NT gestisce tutti gli aspetti dell'assegnazione del lavoro ai processori
logici di sistema.

Il pianificatore radice è progettato per soddisfare requisiti specifici e supportare una partizione
di servizio, fornendo un isolamento sicuro del carico di lavoro, utilizzato con Windows
Defender Application Guard (WDAG). In questo scenario, lasciando le responsabilità di
pianificazione per il sistema operativo radice offre diversi vantaggi:

È possibile usare i controlli delle risorse della CPU applicabili agli scenari di contenitori
utilizzando la partizione dell'utilità, semplificando la gestione e la distribuzione.
Lo scheduler del sistema operativo principale può raccogliere facilmente le metriche
relative all'uso della CPU del carico di lavoro all'interno del contenitore. Può usare questi
dati come input per i criteri di pianificazione e applicarli a tutti gli altri carichi di lavoro nel
sistema.
Queste stesse metriche aiutano anche ad attribuire il lavoro svolto in un contenitore di
applicazioni al sistema host. Tenere traccia di queste metriche è più difficile con i carichi di
 lavoro delle macchine virtuali tradizionali, in cui alcune operazioni per conto di tutte le
macchine virtuali in esecuzione vengono eseguite nella partizione radice.

Uso del programma di pianificazione principale nei sistemi client

A partire da Windows 10, versione 1803, il pianificatore radice viene utilizzato per impostazione
predefinita solo nei sistemi client, che implica:

È possibile abilitare l'hypervisor per supportare la sicurezza basata su virtualizzazione e

l'isolamento del carico di lavoro WDAG.
È importante gestire correttamente i sistemi futuri con architetture di base eterogenee.

Questa configurazione è l'unica configurazione dell'utilità di pianificazione hypervisor

supportata per i sistemi client. Gli amministratori non devono tentare di modificare il tipo di
schedulatore hypervisor predefinito nei sistemi client Windows.

Controlli delle risorse DELLA CPU della macchina virtuale e utilità di

pianificazione radice
I controlli delle risorse che l'hypervisor Hyper-V utilizza sui processori delle singole macchine
virtuali non sono supportati quando si abilita il pianificatore radice dell'hypervisor. Nel sistema
operativo radice, la logica dell'utilità di pianificazione gestisce le risorse host su base globale e
non gestisce le risorse guest di singole macchine virtuali. I controlli delle risorse del processore
Hyper-V per macchina virtuale, come limiti, pesi e riserve, valgono solo quando l'hypervisor
controlla direttamente la pianificazione del processore virtuale, ad esempio con i tipi di
scheduler classici e principali.

Uso del root scheduler nei sistemi server

Non è consigliabile usare l'utilità di pianificazione radice con Hyper-V sui server. Le
caratteristiche delle prestazioni non sono ancora completamente caratterizzate e ottimizzate
per supportare l'ampia gamma di carichi di lavoro tipici di molte distribuzioni di
virtualizzazione server.

Abilitare SMT nelle macchine virtuali ospiti

Dopo aver configurato l'hypervisor dell'host di virtualizzazione per utilizzare il tipo di
pianificazione del core, è anche possibile configurare le macchine virtuali guest per utilizzare
SMT. In particolare, è possibile specificare il numero di thread SMT virtuali da esporre a una
macchina virtuale guest. Il pianificatore del sistema operativo guest e i carichi di lavoro delle
macchine virtuali possono quindi rilevare e utilizzare la topologia SMT nella propria
pianificazione del lavoro.

In Windows Server 2016, la funzionalità SMT guest non è configurata per impostazione
predefinita. Un amministratore host Hyper-V deve abilitarlo in modo esplicito.
In Windows Server 2019 e versioni successive, le nuove macchine virtuali create nell'host
ereditano la topologia SMT host per impostazione predefinita. Ad esempio, una macchina
virtuale versione 9.0 creata in un host con due thread SMT per core ha anche due thread
SMT per core.

È necessario usare PowerShell per abilitare SMT in una macchina virtuale guest. Non è
disponibile alcuna interfaccia utente in Hyper-V Manager. Per abilitare SMT in una macchina
virtuale guest:

1. Aprire una finestra di PowerShell usando un account membro del gruppo Hyper-V
Administrators o equivalente.

2. Eseguire Set-VMProcessor -VMName <VM-name> -HwThreadCountPerCore <n> , dove <n> è il

numero di thread SMT per core visualizzati dalla macchina virtuale guest. Se si usa un
valore di 0 per <n> , il valore HwThreadCountPerCore viene impostato al conteggio dei
thread SMT per core dell'host.

７ Nota

Windows Server 2016 non supporta l'impostazione HwThreadCountPerCore su 0 .

Lo screenshot seguente mostra le informazioni di sistema ottenute dal sistema operativo guest
in esecuzione in una macchina virtuale. Sono disponibili due processori virtuali e SMT è
abilitato. Il sistema operativo guest rileva due processori logici appartenenti allo stesso core.
Configurare il tipo di scheduler dell'hypervisor
Il tipo di utilità di pianificazione dell'hypervisor che Hyper-V usa per impostazione predefinita
dipende dalla versione del sistema operativo. Indipendentemente dall'utilità di pianificazione
predefinita nel sistema operativo, è possibile configurare l'hypervisor per l'uso dell'utilità di
pianificazione principale. Il core scheduler aumenta la sicurezza limitando l'esecuzione dei
processori virtuali guest su coppie SMT fisiche corrispondenti. Questa configurazione supporta
l'uso di macchine virtuali con la pianificazione SMT per i processori virtuali guest.

７ Nota

In Windows Server 2016 Hyper-V usa l'utilità di pianificazione classica per impostazione
predefinita. Se si usa Hyper-V in Windows Server 2016 o versione successiva, è
consigliabile selezionare l'utilità di pianificazione principale. Questa opzione garantisce
che gli host di virtualizzazione siano protetti in modo ottimale da macchine virtuali guest
potenzialmente dannose.

Valutare l'impatto sulla sicurezza e sulle prestazioni

Per garantire che gli host Hyper-V vengano distribuiti in una configurazione di sicurezza
ottimale, Hyper-V utilizza il modello di pianificazione centrale dell'hypervisor come
impostazione predefinita da Windows Server 2019. L'amministratore host potrebbe
opzionalmente configurare l'host per utilizzare il pianificatore classico legacy. Prima di eseguire
l'override delle impostazioni predefinite, gli amministratori devono leggere, comprendere e
prendere in considerazione l'impatto di ogni tipo di utilità di pianificazione sulla sicurezza e
sulle prestazioni degli host di virtualizzazione. Per altre informazioni, vedere Informazioni sulla
selezione del tipo di schedulatore dell'hypervisor Hyper-V.

Selezionare il tipo di scheduler dell'hypervisor in

Windows Server
La configurazione del gestore dell'hypervisor è controllata dalla voce dei dati configurativi di
avvio ( hypervisorschedulertype BCD).

Per selezionare un tipo di pianificatore:

1. Aprire il prompt dei comandi con privilegi di amministratore.

2. Immettere bcdedit /set hypervisorschedulertype <type> , dove <type> è una delle

opzioni seguenti:

Classic

Core

Root

Per rendere effettive le modifiche apportate al tipo di scheduler dell'hypervisor, è necessario

riavviare il sistema.

７ Nota

L'utilità di pianificazione radice dell'hypervisor non è supportata su Hyper-V su Windows

Server al momento. Hyper-V gli amministratori non devono tentare di configurare il
scheduler radice per scenari di virtualizzazione del server.

Determinare il tipo di pianificatore corrente

È possibile determinare il tipo di utilità di pianificazione dell'hypervisor che Hyper-V sta
attualmente utilizzando esaminando il log di sistema di Windows. Cerca l'evento di avvio
dell'hypervisor più recente con un ID pari a 2. Tale evento riporta il tipo di scheduler
dell'hypervisor configurato all'avvio dell'hypervisor. I valori seguenti sono possibili per il tipo di
schedulatore dell'hypervisor:

ﾉ Espandi la tabella
 Valore Tipo di scheduler

1 Pianificatore classico, SMT disabilitata

2 Pianificatore classico

3 Pianificatore centrale

4 Pianificatore radice

È possibile usare Visualizzatore eventi o PowerShell per visualizzare i registri eventi di avvio
dell'hypervisor.
Usare PowerShell per eseguire query sui log di sistema per un
evento di avvio dell'hypervisor
Per eseguire una query sui log di sistema per un evento hypervisor con ID 2 usando
PowerShell, eseguire il comando seguente:

PowerShell

Get-WinEvent -FilterHashTable @{ProviderName="Microsoft-Windows-Hyper-V-

Hypervisor"; ID=2} -MaxEvents 1
Informazioni sulla selezione del tipo di
utilità di pianificazione dell'hypervisor
Hyper-V
Articolo • 02/11/2024 •
Si ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
applica Windows Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Stack HCI, versions
a: 23H2 and 22H2

Questo documento descrive le importanti modifiche apportate alle impostazioni

predefinite di Hyper-V e sull'uso consigliato dei tipi di utilità di pianificazione
dell'hypervisor. Tali modifiche influiscono sia sulla sicurezza del sistema che sulle
prestazioni di virtualizzazione. Gli amministratori host di virtualizzazione devono
esaminare e comprendere le modifiche e le implicazioni descritte in questo documento,
nonché valutare attentamente gli impatti, le indicazioni suggerite sulla distribuzione e i
fattori di rischio coinvolti per comprendere meglio come distribuire e gestire gli host
Hyper-V nel panorama della sicurezza in rapida evoluzione.

） Importante

Al momento, le vulnerabilità di sicurezza lato canale note rilevate in più architetture

del processore possono essere sfruttate da una macchina virtuale guest dannosa
tramite il comportamento di pianificazione del tipo di utilità di pianificazione
classico dell'hypervisor quando viene eseguito negli host con multithreading
simultaneo (SMT) abilitato. Se usato correttamente, un carico di lavoro dannoso
potrebbe osservare i dati al di fuori del limite della partizione. Questa classe di
attacchi può essere mitigata configurando l'hypervisor Hyper-V in modo da usare il
tipo di utilità di pianificazione principale dell'hypervisor e riconfigurando le
macchine virtuali guest. Con l'utilità di pianificazione principale, l'hypervisor limita
l'esecuzione dei VP di una macchina virtuale guest nello stesso core del processore
fisico, isolando fortemente quindi la capacità della macchina virtuale di accedere ai
dati ai limiti del core fisico in cui viene eseguito. Si tratta di una mitigazione
estremamente efficace contro questi attacchi sul lato canale, che impedisce alla
macchina virtuale di osservare eventuali artefatti da altre partizioni,
indipendentemente dalla radice o da un'altra partizione guest. Pertanto, Microsoft
sta modificando le impostazioni di configurazione predefinite e consigliate per gli
host di virtualizzazione e le macchine virtuali guest.
Background
A partire da Windows Server 2016, Hyper-V supporta diversi metodi di pianificazione e
gestione dei processori virtuali, noti come tipi di utilità di pianificazione dell'hypervisor.
Una descrizione dettagliata di tutti i tipi di utilità di pianificazione hypervisor è
disponibile in Informazioni e uso dei tipi di utilità di pianificazione hypervisor Hyper-V.

７ Nota

I nuovi tipi di utilità di pianificazione dell'hypervisor sono stati introdotti per la

prima volta con Windows Server 2016 e non sono disponibili nelle versioni
precedenti. Tutte le versioni di Hyper-V precedenti a Windows Server 2016
supportano solo l'utilità di pianificazione classica. Il supporto per l'utilità di
pianificazione principale è stato pubblicato solo di recente.

Informazioni sui tipi di utilità di pianificazione

dell'hypervisor
Questo articolo è incentrato in particolare sull'uso del nuovo tipo di utilità di
pianificazione principale dell'hypervisor rispetto all'utilità di pianificazione "classica"
legacy e sul modo in cui questi tipi di utilità di pianificazione si intersecano con l'uso di
SMT. È importante comprendere le differenze tra le utilità di pianificazione principali e
classiche e il funzionamento di ogni posizione dalle macchine virtuali guest nei
processori di sistema sottostanti.

Utilità di pianificazione classica

L'utilità di pianificazione classica si riferisce al metodo di equa condivisione round robin
di pianificare il lavoro nei processori virtuali (VP) nel sistema, inclusi i VP radice quelli
appartenenti alle macchine virtuali guest. L'utilità di pianificazione classica è il tipo di
utilità di pianificazione predefinito usato in tutte le versioni di Hyper-V (fino a Windows
Server 2019, come descritto di seguito). Le caratteristiche delle prestazioni dell'utilità di
pianificazione classica sono ben comprensibili ed è dimostrato che supporta in modo
efficiente l'over-subscription dei carichi di lavoro, ovvero l'over-subscription del
rapporto VP:LP dell'host in base a un margine ragionevole (a seconda dei tipi di carichi
di lavoro virtualizzati, dell'utilizzo complessivo delle risorse e così via).

Quando viene eseguito in un host di virtualizzazione con SMT abilitato, l'utilità di

pianificazione classica pianifica i VP guest da qualsiasi macchina virtuale in ogni thread
SMT appartenente a un core in modo indipendente. Di conseguenza, è possibile
eseguire macchine virtuali diverse nello stesso core contemporaneamente (una
macchina virtuale in esecuzione in un thread di un core mentre un'altra macchina
virtuale è in esecuzione nell'altro thread).

Utilità di pianificazione principale

L'utilità di pianificazione principale sfrutta le proprietà di SMT per fornire l'isolamento
dei carichi di lavoro guest, che influiscono sulle prestazioni di sicurezza e di sistema.
L'utilità di pianificazione principale garantisce che VP da una macchina virtuale siano
pianificate in thread SMT di pari livello. Questa operazione viene eseguita in modo
simmetrico così che se gli LP si trovano in gruppi di due, i VP vengono pianificate in
gruppi di due e un core CPU di sistema non viene mai condiviso tra le macchine virtuali.

Pianificando i VP guest sulle coppie SMT sottostanti, l'utilità di pianificazione principale

offre un limite di sicurezza sicuro per l'isolamento del carico di lavoro e può essere
usato anche per ridurre la variabilità delle prestazioni per i carichi di lavoro sensibili alla
latenza.

Si noti che quando il VP è pianificato per una macchina virtuale senza SMT abilitata, tale
VP utilizzerà l'intero core durante l'esecuzione e il thread SMT di pari livello del core
verrà lasciato inattiva. Ciò è necessario per garantire l'isolamento corretto del carico di
lavoro, ma influisce sulle prestazioni complessive del sistema, in particolare quando gli
LP di sistema diventano over-subscribed, ovvero quando il rapporto VP:LP totale supera
1:1. Pertanto, l'esecuzione di macchine virtuali guest configurate senza più thread per
core è una configurazione non ottimale.

Vantaggi dell'uso dell'utilità di pianificazione principale

L'utilità di pianificazione principale offre i vantaggi seguenti:

Un limite di sicurezza sicuro per l'isolamento del carico di lavoro guest: i VP guest
sono vincolati all'esecuzione su coppie di core fisici sottostanti, riducendo la
vulnerabilità agli attacchi di snooping sul lato canale.

Riduzione della variabilità del carico di lavoro: la variabilità della velocità effettiva
del carico di lavoro guest è notevolmente ridotta e offre maggiore coerenza del
carico di lavoro.

Uso di SMT nelle macchine virtuali guest: il sistema operativo e le applicazioni in

esecuzione nella macchina virtuale guest possono usare il comportamento SMT e
 le interfacce di programmazione (API) per controllare e distribuire il lavoro tra
thread SMT, proprio come quando vengono eseguiti non virtualizzati.

L'utilità di pianificazione principale viene attualmente usata negli host di virtualizzazione

di Azure, in particolare per sfruttare i potenti limiti di sicurezza e la variabilità del carico
di lavoro bassa. Microsoft ritiene che il tipo di utilità di pianificazione principale sia e
continuerà a essere il tipo di pianificazione dell'hypervisor predefinito per la maggior
parte degli scenari di virtualizzazione. Pertanto, per garantire che i clienti siano protetti
per impostazione predefinita, Microsoft sta apportando questa modifica per Windows
Server 2019.

Impatti delle prestazioni dell'utilità di pianificazione di

base sui carichi di lavoro guest
Anche se necessario per attenuare in modo efficace determinate classi di vulnerabilità,
l'utilità di pianificazione principale può anche potenzialmente ridurre le prestazioni. I
clienti possono riscontrare una differenza nelle caratteristiche delle prestazioni con le
macchine virtuali e un impatto sulla capacità complessiva del carico di lavoro degli host
di virtualizzazione. Nei casi in cui l'utilità di pianificazione principale deve eseguire un VP
non SMT, viene eseguito solo uno dei flussi di istruzioni nel core logico sottostante
mentre l'altro deve essere lasciato inattivo. In questo modo verrà limitata la capacità
totale dell'host per i carichi di lavoro guest.

Questi impatti sulle prestazioni possono essere ridotti al minimo seguendo le indicazioni
sulla distribuzione in questo documento. Gli amministratori host devono considerare
attentamente gli scenari di distribuzione di virtualizzazione specifici e bilanciare la
tolleranza per il rischio della sicurezza in base alla necessità di densità massima del
carico di lavoro, oltre al consolidamento degli host di virtualizzazione e così via.

Modifiche alle configurazioni predefinite e

consigliate per Windows Server 2016 e
Windows Server 2019
La distribuzione degli host Hyper-V con il comportamento di sicurezza massimo richiede
l'uso del tipo di utilità di pianificazione principale dell'hypervisor. Per assicurarsi che i
clienti siano protetti per impostazione predefinita, Microsoft sta modificando le
impostazioni predefinite e consigliate seguenti.

７ Nota
 Mentre il supporto interno dell'hypervisor per i tipi di utilità di pianificazione è stato
incluso nella versione iniziale di Windows Server 2016, Windows Server 1709 e
Windows Server 1803, gli aggiornamenti sono necessari per accedere al controllo di
configurazione che consente di selezionare il tipo di utilità di pianificazione
dell'hypervisor. Per informazioni dettagliate su questi aggiornamenti, vedere
Informazioni e uso dei tipi di utilità di pianificazione hypervisor Hyper-V.

Modifiche all'host di virtualizzazione

L'hypervisor userà l'utilità di pianificazione principale per impostazione predefinita
a partire da Windows Server 2019.

Microsoft consiglia di configurare l'utilità di pianificazione principale in Windows

Server 2016. Il tipo di utilità di pianificazione principale dell'hypervisor è
supportato in Windows Server 2016, ma il valore predefinito è l'utilità di
pianificazione classica. L'utilità di pianificazione principale è facoltativa e deve
essere abilitata in modo esplicito dall'amministratore dell'host Hyper-V.

Modifiche alla configurazione della macchina virtuale

In Windows Server 2019, le nuove macchine virtuali create con la macchina virtuale
predefinita versione 9.0 erediteranno automaticamente le proprietà SMT (abilitate
o disabilitate) dell'host di virtualizzazione. In altre parole, se SMT è abilitato
nell'host fisico, le macchine virtuali appena create avranno anche SMT abilitato ed
erediteranno la topologia SMT dell'host per impostazione predefinita, con la
macchina virtuale con lo stesso numero di thread hardware per core del sistema
sottostante. Ciò si rifletterà nella configurazione della macchina virtuale con
HwThreadCountPerCore = 0, dove 0 indica che la macchina virtuale deve ereditare
le impostazioni SMT dell'host.

Le macchine virtuali esistenti con una versione 8.2 della macchina virtuale o
versioni precedenti manterranno l'impostazione originale del processore della
macchina virtuale per HwThreadCountPerCore e l'impostazione predefinita per i
guest della versione 8.2 della macchina virtuale è HwThreadCountPerCore = 1.
Quando questi guest vengono eseguiti in un host di Windows Server 2019,
verranno considerati come segue:

1. Se la macchina virtuale ha un conteggio VP minore o uguale al numero di

core LP, la macchina virtuale verrà considerata come una macchina virtuale
non SMT dall'utilità di pianificazione principale. Quando il VP guest viene
eseguito in un singolo thread SMT, il thread SMT di pari livello del core verrà
 reso inattivo. Ciò non è ottimale e comporterà una perdita complessiva delle
prestazioni.

2. Se la macchina virtuale ha più VP rispetto ai core LP, la macchina virtuale

verrà considerata come una macchina virtuale SMT dall'utilità di
pianificazione principale. Tuttavia, la macchina virtuale non osserverà altre
indicazioni che si tratta di una macchina virtuale SMT. Ad esempio, l'uso
dell'istruzione CPUID o delle API di Windows per eseguire query sulla
topologia della CPU dal sistema operativo o dalle applicazioni non indicherà
che SMT è abilitato.

Quando una macchina virtuale esistente viene aggiornata in modo esplicito dalle
versioni precedenti alla versione 9.0 tramite l'operazione Update-VM, la macchina
virtuale manterrà il valore corrente per HwThreadCountPerCore. La macchina
virtuale non avrà SMT forzato abilitato.

In Windows Server 2016, Microsoft consiglia di abilitare SMT per le macchine

virtuali guest. Per impostazione predefinita, le macchine virtuali create in Windows
Server 2016 hannon disabilitato SMT, ovvero HwThreadCountPerCore è impostato
su 1, a meno che non venga modificato in modo esplicito.

７ Nota

Windows Server 2016 non supporta l'impostazione di HwThreadCountPerCore su 0.

Gestione della configurazione SMT della macchina virtuale

La configurazione SMT della macchina virtuale guest viene impostata per ogni macchina
virtuale. L'amministratore host può esaminare e impostare la configurazione SMT di una
macchina virtuale per selezionare le opzioni seguenti:

1. Configurare le macchine virtuali per l'esecuzione come SMT abilitato, ereditando

automaticamente in modo facoltativo la topologia SMT dell'host

2. Configurare le macchine virtuali per l'esecuzione come non SMT

La configurazione SMT per una macchina virtuale viene visualizzata nei riquadri
Riepilogo della console di gestione di Hyper-V. La configurazione delle impostazioni
SMT di una macchina virtuale può essere eseguita usando le impostazioni della
macchina virtuale o PowerShell.
Configurazione delle impostazioni SMT della macchina virtuale
tramite PowerShell

Per configurare le impostazioni SMT per una macchina virtuale guest, aprire una finestra
di PowerShell con autorizzazioni sufficienti e digitare:

PowerShell

Set-VMProcessor -VMName <VMName> -HwThreadCountPerCore <0, 1, 2>

Dove:

0 = Ereditare la topologia SMT dall'host (questa impostazione di

HwThreadCountPerCore=0 non è supportata in Windows Server 2016)

1 = Non-SMT

I valori > 1 = il numero desiderato di thread SMT per core. Non può superare il
numero di thread SMT fisici per core.

Per leggere le impostazioni SMT per una macchina virtuale guest, aprire una finestra di
PowerShell con autorizzazioni sufficienti e digitare:

PowerShell

(Get-VMProcessor -VMName <VMName>).HwThreadCountPerCore

Si noti che le macchine virtuali guest configurate con HwThreadCountPerCore = 0

indicano che SMT verrà abilitato per il guest ed esporrà lo stesso numero di thread SMT
al guest in quanto si trovano nell'host di virtualizzazione sottostante, in genere 2.

Le macchine virtuali guest possono osservare modifiche

alla topologia della CPU in scenari di mobilità delle
macchine virtuali
Il sistema operativo e le applicazioni in una macchina virtuale possono visualizzare le
modifiche alle impostazioni dell'host e della macchina virtuale prima e dopo gli eventi
del ciclo di vita della macchina virtuale, ad esempio la migrazione in tempo reale o le
operazioni di salvataggio e ripristino. Durante un'operazione in cui viene salvato e
ripristinato lo stato della macchina virtuale, viene eseguita la migrazione
dell'impostazione HwThreadCountPerCore della macchina virtuale e del valore realizzato
(ovvero la combinazione calcolata dell'impostazione della macchina virtuale e della
configurazione dell'host di origine). La macchina virtuale continuerà a essere in
esecuzione con queste impostazioni nell'host di destinazione. Al momento dell'arresto e
del riavvio della macchina virtuale, è possibile che il valore realizzato osservato dalla
macchina virtuale cambierà. Questo comportamento non dovrebbe essere dannoso,
perché il software del sistema operativo e dell'applicazione deve cercare informazioni
sulla topologia della CPU come parte dei normali flussi di codice di avvio e
inizializzazione. Tuttavia, poiché queste sequenze di inizializzazione dell'ora di avvio
vengono ignorate durante la migrazione in tempo reale o le operazioni di
salvataggio/ripristino, le macchine virtuali che subiscono queste transizioni di stato
potrebbero osservare il valore realizzato originariamente calcolato fino a quando non
vengono arrestate e riavviate.

Avvisi relativi alle configurazioni di macchine virtuali non

ottimali
Le macchine virtuali configurate con più VP rispetto ai core fisici nell'host generano una
configurazione non ottimale. L'utilità di pianificazione dell'hypervisor considererà queste
macchine virtuali come se fossero compatibile con SMT. Tuttavia, il software del sistema
operativo e dell'applicazione nella macchina virtuale presenterà una topologia della CPU
che mostra che SMT è disabilitato. Quando viene rilevata questa condizione, il processo
di lavoro Hyper-V registrerà un evento nell'host di virtualizzazione che avvisa
l'amministratore host che la configurazione della macchina virtuale non è ottimale e
consiglia di abilitare SMT per la macchina virtuale.

Come identificare macchine virtuali non configurate in modo

ottimale
È possibile identificare le macchine virtuali non SMT esaminando il registro di sistema
nel Visualizzatore eventi per l'ID 3498 dell'evento del processo di lavoro di Hyper-V, che
verrà attivato per una macchina virtuale ogni volta che il numero di VP nella macchina
virtuale è maggiore del numero di core fisici. Gli eventi del processo di lavoro possono
essere ottenuti dal Visualizzatore eventi o tramite PowerShell.

Esecuzione di query sull'evento della macchina virtuale del

processo di lavoro Hyper-V con PowerShell
Per eseguire una query per l'ID 3498 dell'evento del processo di lavoro Hyper-V 3498
usando PowerShell, immettere i comandi seguenti da un prompt di PowerShell.

PowerShell
 Get-WinEvent -FilterHashTable @{ProviderName="Microsoft-Windows-Hyper-V-
Worker"; ID=3498}

Impatto della configurazione SMT guest sull'uso delle

funzionalità di riconoscimento dei dati di hypervisor per i
sistemi operativi guest
L'hypervisor Microsoft offre più funzionalità di riconoscimento dei dati, o suggerimenti,
su sui il sistema operativo in esecuzione in una macchina virtuale guest può eseguire
query e usare per attivare ottimizzazioni, ad esempio quelle che potrebbero migliorare
le prestazioni o migliorare in altro modo la gestione delle varie condizioni durante
l'esecuzione virtualizzata. Uno dei concetti di riconoscimento dei dati introdotti di
recente riguarda la gestione della pianificazione del processore virtuale e l'uso di
mitigazioni del sistema operativo per gli attacchi sul canale laterale che sfruttano SMT.

７ Nota

Microsoft consiglia agli amministratori host di abilitare SMT per le macchine virtuali
guest per ottimizzare le prestazioni del carico di lavoro.

I dettagli di questa funzionalità di riconoscimento dei dati guest sono forniti di seguito,
ma la chiave per gli amministratori host di virtualizzazione è che le macchine virtuali
devono avere HwThreadCountPerCore configurato in modo che corrisponda alla
configurazione SMT fisica dell'host. In questo modo l'hypervisor può segnalare che non
esiste alcuna condivisione di core non architetturali. Di conseguenza, qualsiasi sistema
operativo guest che supporta le ottimizzazioni che richiedono il riconoscimento dei dati
può essere abilitato. In Windows Server 2019, creare nuove macchine virtuali e lasciare il
valore predefinito HwThreadCountPerCore (0). Le macchine virtuali meno recenti
migrate dagli host Windows Server 2016 possono essere aggiornate alla versione di
configurazione di Windows Server 2019. Al termine, Microsoft consiglia di impostare
HwThreadCountPerCore = 0. In Windows Server 2016, Microsoft consiglia di impostare
HwThreadCountPerCore in modo che corrisponda alla configurazione dell'host (in
genere 2).

Dettagli sul riconoscimento dei dati

NoNonArchitecturalCoreSharing
A partire da Windows Server 2016, l'hypervisor definisce un nuovo riconoscimento dei
dati per descrivere la gestione della pianificazione e del posizionamento di VP nel
sistema operativo guest. Il riconoscimento dati è definito nella specifica funzionale di
livello superiore dell'hypervisor v5.0c.

La foglia CPUID sintetica dell'hypervisor

[Link][NoNonArchitecturalCoreSharing = 1] indica che un
processore virtuale non condividerà mai un core fisico con un altro processore virtuale,
ad eccezione dei processori virtuali segnalati come thread SMT di pari livello. Ad
esempio, un VP guest non verrà mai eseguito su un thread SMT insieme a un VP radice
in esecuzione simultaneamente su un thread SMT di pari livello nello stesso core del
processore. Questa condizione è possibile solo quando si esegue virtualizzato e quindi
rappresenta un comportamento SMT non architetturale che ha anche gravi implicazioni
per la sicurezza. Il sistema operativo guest può usare NoNonArchitecturalCoreSharing =
1 come indicazione che è sicuro abilitare le ottimizzazioni, evitando così il sovraccarico
delle prestazioni dell'impostazione di STIBP.

In determinate configurazioni, l'hypervisor non indicherà

NoNonArchitecturalCoreSharing = 1. Ad esempio, se un host ha SMT abilitato ed è
configurato per l'uso dell'utilità di pianificazione classica dell'hypervisor,
NoNonArchitecturalCoreSharing sarà 0. Ciò potrebbe impedire agli utenti guest con
riconoscimento dei dati di abilitare determinate ottimizzazioni. Microsoft consiglia
pertanto agli amministratori host di usare SMT con l'utilità di pianificazione principale
dell'hypervisor e assicurarsi che le macchine virtuali siano configurate per ereditare la
configurazione SMT dall'host per garantire prestazioni ottimali del carico di lavoro.

Riepilogo
Il panorama delle minacce per la sicurezza continua a evolversi. Per garantire che i clienti
siano sicuri per impostazione predefinita, Microsoft sta modificando la configurazione
predefinita per l'hypervisor e le macchine virtuali a partire da Windows Server 2019
Hyper-V e fornendo indicazioni e consigli aggiornati per i clienti che eseguono Windows
Server 2016 Hyper-V. Gli amministratori host di virtualizzazione devono:

Leggere e comprendere le indicazioni fornite in questo documento

Valutare e modificare attentamente le distribuzioni di virtualizzazione per garantire

che soddisfino gli obiettivi di sicurezza, prestazioni, densità di virtualizzazione e
velocità di risposta del carico di lavoro per i requisiti univoci

Valutare la possibilità di riconfigurare gli host Hyper-V di Windows Server 2016

esistenti per sfruttare i vantaggi di sicurezza avanzata offerti dall'utilità di
pianificazione principale dell'hypervisor
 Aggiornare le macchine virtuali non SMT esistenti per ridurre gli effetti sulle
prestazioni derivanti dai vincoli di pianificazione imposti dall'isolamento VP che
risolve le vulnerabilità di sicurezza hardware

Commenti e suggerimenti
Questa pagina è stata utile?  Sì  No
servizi di integrazione Hyper-V
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

I servizi di integrazione, spesso chiamati componenti di integrazione, sono servizi che

consentono alla macchina virtuale di comunicare con l'host Hyper-V. Molti di questi servizi
sono pratici, mentre altri sono importanti per la capacità della macchina virtuale di funzionare
correttamente.

Questo articolo è un riferimento per ogni servizio di integrazione disponibile in Windows.

Funge anche da punto di partenza per informazioni relative a specifici servizi di integrazione o
alla relativa cronologia.

Per altre informazioni, vedere la Guida di Windows Server sulla gestione dei servizi di
integrazione.

Riferimento rapido
ﾉ Espandi la tabella

Nome Nome servizio Nome daemon Description Impatto sulla

Windows Linux macchina
virtuale
quando
disabilitata

servizio vmicheartbeat hv_utils Segnala che la Varia

heartbeatHyper-V macchina virtuale è in
esecuzione
correttamente.

Hyper-V servizio di vmicshutdown hv_utils Consente all'host di Alto

arresto guest attivare l'arresto delle
macchine virtuali.

Servizio di vmictimesync hv_utils Sincronizza l'orologio Alto

sincronizzazione della macchina virtuale
dell'ora diHyper-V con l'orologio del
computer host.

Hyper-V Data vmickvpexchange hv_kvp_daemon Fornisce un modo per Intermedio

Exchange Service scambiare i metadati
(KVP) di base tra la macchina
virtuale e l'host.
 Nome Nome servizio Nome daemon Description Impatto sulla
Windows Linux macchina
virtuale
quando
disabilitata

richiesta copia vmicvss hv_vss_daemon Consente al Servizio Varia

shadow del Copia Shadow del
volumeHyper-V Volume di eseguire il
backup della macchina
virtuale senza
spegnerla.

interfaccia del vmicguestinterface hv_fcopy_daemon Fornisce un'interfaccia Low

servizio per l'host Hyper-V per
guestHyper-V copiare i file da o
verso la macchina
virtuale.

Hyper-V servizio vmicvmsession non disponibile Consente di gestire la Low

PowerShell Direct macchina virtuale con
PowerShell senza una
connessione di rete.

Hyper-V servizio heartbeat

Nome servizio Windows: vmicheartbeat
Nome daemon Linux: hv_utils
Descrizione: Indica all'host Hyper-V che la macchina virtuale ha installato un sistema operativo
e che è stato avviato correttamente.
Aggiunta in: Windows Server 2012, Windows 8
Impatto: Se disabilitata, la macchina virtuale non può segnalare che il sistema operativo
all'interno della macchina virtuale funziona correttamente. Questa limitazione potrebbe influire
su alcuni tipi di monitoraggio e diagnostica lato host.

Il servizio heartbeat consente di rispondere a domande di base come "l'avvio della macchina
virtuale?".

Quando Hyper-V segnala che lo stato di una macchina virtuale è "in esecuzione" (vedere
l'esempio nella sezione seguente), significa Hyper-V mettere da parte le risorse per una
macchina virtuale; non significa che un sistema operativo sia installato o funzionante. Questa
limitazione è il limite dove l'heartbeat diventa utile. Il servizio heartbeat indica Hyper-V che il
sistema operativo all'interno della macchina virtuale è stato avviato.
Controllare l'heartbeat con PowerShell
Eseguire Get-VM come amministratore per visualizzare l'heartbeat di una macchina virtuale:

PowerShell
Get-VM -VMName $VMName | select Name, State, Status

L'output dovrebbe essere simile al seguente:

Output

Name State Status

---- ----- ------
DemoVM Running Operating normally

Il Status campo è determinato dal servizio heartbeat.

Hyper-V servizio di arresto guest

Nome servizio Windows: vmicshutdown
Nome daemon Linux: hv_utils
Descrizione: Consente all'host Hyper-V di richiedere l'arresto della macchina virtuale. L'host
può sempre forzare la disattivazione della macchina virtuale, ma l'azione è come capovolgere
l'interruttore di alimentazione anziché selezionare l'arresto.
Aggiunta in: Windows Server 2012, Windows 8
Impact:High Impact Quando disabilitato, l'host non può attivare un arresto descrittivo
all'interno della macchina virtuale. Tutti gli arresti sono spegnimenti rigidi, che potrebbero
causare la perdita di dati o il danneggiamento dei dati.

servizio di sincronizzazione dell'ora Hyper-V

Nome servizio Windows: vmictimesync
Nome daemon Linux: hv_utils
Descrizione: Sincronizza l'orologio di sistema della macchina virtuale con l'orologio di sistema
del computer fisico.
Aggiunta in: Windows Server 2012, Windows 8
Impact:High Impact Quando disabilitato, il clock della macchina virtuale deriva in modo
irregolare.

Hyper-V servizio di scambio dati (KVP)

Nome servizio Windows: vmickvpexchange
Nome daemon Linux: hv_kvp_daemon
Descrizione: Fornisce un meccanismo per scambiare i metadati di base tra la macchina virtuale
e l'host.
Aggiunta in: Windows Server 2012, Windows 8
Impatto: Se disabilitata, le macchine virtuali che eseguono Windows 8 o Windows Server 2012
o versioni precedenti non ricevono aggiornamenti per Hyper-V servizi di integrazione. La
disabilitazione dello scambio di dati potrebbe influire anche su alcuni tipi di monitoraggio e
diagnostica lato host.

Il servizio di scambio di dati (noto anche come KVP) condivide piccole quantità di informazioni
sulla macchina virtuale e l'host Hyper-V usando coppie chiave-valore (KVP) tramite il Registro
di sistema di Windows. È anche possibile usare lo stesso meccanismo per condividere dati
personalizzati tra la macchina virtuale e l'host.

Le coppie chiave-valore sono costituite da una "chiave" e da un "valore". Sia la chiave che il
valore sono stringhe e non sono supportati altri tipi di dati. Quando si crea o si modifica una
coppia chiave-valore, sia il guest che l'host possono visualizzarlo. Le informazioni sulla coppia
chiave-valore vengono trasferite attraverso il bus VM di Hyper-V e non richiedono alcun tipo di
connessione di rete tra il guest e l'host Hyper-V.

Il servizio di scambio dati è un ottimo strumento per conservare le informazioni sulla macchina
virtuale. Per la condivisione interattiva dei dati o il trasferimento dei dati, usare PowerShell
Direct.

Altre informazioni sull'uso di coppie chiave-valore per condividere informazioni tra l'host e il
guest in Hyper-V.

richiesta copia shadow del volume Hyper-V

Nome servizio Windows: vmicvss
Nome daemon Linux: hv_vss_daemon
Descrizione: Consente al servizio Copia Shadow del volume di eseguire il backup di
applicazioni e dati nella macchina virtuale.
Aggiunta in: Windows Server 2012, Windows 8
Impatto: Se disabilitata, non è possibile eseguire il backup della macchina virtuale durante
l'esecuzione (tramite VSS).

Il servizio di integrazione del richiedente copia shadow del volume è necessario per il servizio
Copia Shadow del volume ( VSS). Il servizio Copia Shadow del volume acquisisce e copia le
immagini per il backup nei sistemi in esecuzione, in particolare nei server, senza
compromettere eccessivamente le prestazioni e la stabilità dei servizi forniti. Questo servizio di
integrazione consente di coordinare i carichi di lavoro della macchina virtuale con il processo di
backup dell'host.

Altre informazioni su Copia shadow del volume in Backup e ripristino di macchine virtuali.

interfaccia del servizio guest Hyper-V

Nome servizio Windows: vmicguestinterface
Nome daemon Linux: hv_fcopy_daemon
Descrizione: Fornisce un'interfaccia per l'host Hyper-V per copiare i file in modo bidirezionale
da o verso la macchina virtuale.
Aggiunta in: Windows Server 2012 R2, Windows 8.1
Impatto: Se disabilitato, l'host non può copiare i file da e verso il guest usando Copy-VMFile .
Altre informazioni sul cmdletCopy-VMFile.

Note:
Disabilitato per impostazione predefinita. Vedere PowerShell Direct using Copy-Item
(PowerShell Direct using Copy-Item).

Hyper-V servizio Diretto di PowerShell

Nome servizio Windows: vmicvmsession
Nome daemon Linux: n/a
Descrizione: Fornisce un meccanismo per gestire una macchina virtuale con PowerShell tramite
una sessione di macchina virtuale senza una rete virtuale. Aggiunta in: Windows Server TP3,
Windows 10
Impatto: Se si disabilita questo servizio, l'host non può connettersi alla macchina virtuale con
PowerShell Direct.

Note:
Il nome del servizio è stato originariamente Hyper-V servizio sessione della macchina virtuale.
PowerShell Direct è in fase di sviluppo attivo ed è disponibile solo su host e guest Windows
10/Windows Server Technical Preview 3 o versioni successive.

PowerShell Direct abilita la gestione di PowerShell all'interno di una macchina virtuale dall'host
Hyper-V, indipendentemente da qualsiasi configurazione di rete o impostazioni di gestione
remota nell'host Hyper-V o nella macchina virtuale. Questa funzionalità semplifica
l'automazione e le attività di configurazione e gestione degli script da parte degli
amministratori di Hyper-V.

Le risorse seguenti potrebbero essere utili per la gestione di PowerShell Direct:

 PowerShell Direct.
Esecuzione di script in una macchina virtuale
Copia di file da e verso una macchina virtuale

Last updated on 28/10/2025

Gestire Hyper-V Integration Services
14/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Hyper-V Integration Services migliora le prestazioni delle macchine virtuali e offre funzionalità
utili sfruttando la comunicazione bidirezionale con l'host Hyper-V. Molti di questi servizi sono
comodità, ad esempio la copia dei file guest, mentre altri sono importanti per la funzionalità
della macchina virtuale, ad esempio i driver di dispositivi sintetici. Questo set di servizi e driver
viene talvolta definito componenti di integrazione. È possibile controllare se i singoli servizi di
praticità operano per qualsiasi macchina virtuale specificata. I componenti driver non sono
destinati a essere manutenuti manualmente.

Per informazioni dettagliate su ogni servizio di integrazione, vedere Hyper-V Integration

Services.

） Importante

Ogni servizio che si vuole usare deve essere abilitato sia nell'host che nel guest per
funzionare. Quando si abilita un servizio nell'host, l'esecuzione viene avviata
automaticamente nel guest. Tutti i servizi di integrazione, ad eccezione dell'interfaccia di
Hyper-V Integration Services, sono attivati per impostazione predefinita nei sistemi
operativi guest Windows. I servizi possono essere attivati e disattivati singolarmente. Le
sezioni successive illustrano come.

Attivare o disattivare un servizio di integrazione

tramite Hyper-V Manager
1. Nel riquadro centrale fare clic con il pulsante destro del mouse sulla macchina virtuale e
scegliere Impostazioni.

2. Nel riquadro sinistro della finestra Impostazioni , in Gestione selezionare Integration

Services.

Nel riquadro Integration Services sono elencati tutti i servizi di integrazione disponibili nell'host
Hyper-V ed è indicato se l'host ha abilitato la macchina virtuale per usarli.

Attivare o disattivare un servizio di integrazione tramite

PowerShell
Per fare ciò in PowerShell, utilizzare Enable-VMIntegrationService e Disable-
VMIntegrationService.

Gli esempi seguenti dimostrano come attivare e disattivare il servizio di integrazione per la
copia dei file guest su una macchina virtuale chiamata DemoVM.

1. Ottenere un elenco di servizi di integrazione in esecuzione:

PowerShell

Get-VMIntegrationService -VMName "DemoVM"

2. L'output dovrebbe essere simile al seguente:

PowerShell

VMName Name Enabled PrimaryStatusDescription

SecondaryStatusDescription
------ ---- ------- ------------------------ --------
------------------
DemoVM Guest Service Interface False OK
DemoVM Heartbeat True OK OK
DemoVM Key-Value Pair Exchange True OK
DemoVM Shutdown True OK
DemoVM Time Synchronization True OK
DemoVM VSS True OK

3. Attivare l'interfaccia del servizio per ospiti:

PowerShell

Enable-VMIntegrationService -VMName "DemoVM" -Name "Guest Service Interface"

4. Verificare che l'interfaccia del servizio ospite sia abilitata.

PowerShell

Get-VMIntegrationService -VMName "DemoVM"

5. Disattivare l'interfaccia del servizio ospiti:

PowerShell

Disable-VMIntegrationService -VMName "DemoVM" -Name "Guest Service Interface"

Verificare la versione dei servizi di integrazione del
guest
Alcune funzionalità potrebbero non funzionare correttamente o se i servizi di integrazione del
guest non sono aggiornati. Per ottenere le informazioni sulla versione per Windows, accedere
al sistema operativo guest, aprire un prompt dei comandi ed eseguire questo comando:

PowerShell

REG QUERY "HKLM\Software\Microsoft\Virtual Machine\Auto" /v

IntegrationServicesVersion

Avviare e arrestare un servizio di integrazione da

un guest di Windows
Affinché un servizio di integrazione sia completamente funzionante, il servizio corrispondente
deve essere in esecuzione all'interno del guest oltre a essere abilitato nell'host. Nei guest di
Windows ogni servizio di integrazione è elencato come servizio Windows standard. È possibile
usare l'applet Servizi nel Pannello di controllo o in PowerShell per arrestare e avviare questi
servizi.

） Importante

L'arresto dei servizi di integrazione può compromettere gravemente la gestione della

macchina virtuale da parte degli host. Per funzionare correttamente, ogni servizio di
integrazione che si vuole usare deve essere abilitato sia nell'host che nel guest. Come
procedura consigliata, è consigliabile controllare solo i servizi di integrazione da Hyper-V
usando le istruzioni riportate in questo articolo. Il servizio corrispondente nel sistema
operativo guest si arresta o viene avviato automaticamente quando si modifica lo stato in
Hyper-V. Se si avvia un servizio nel sistema operativo guest ma è disabilitato in Hyper-V, il
servizio si arresta. Se si arresta un servizio nel sistema operativo guest abilitato in Hyper-V,
Hyper-V lo avvia nuovamente. Se si disabilita il servizio nel guest, Hyper-V non è in grado
di avviarlo.

Usare Servizi Windows per avviare o arrestare un servizio di

integrazione all'interno di un guest Windows
 1. Aprire Gestione servizi eseguendo [Link] come amministratore o facendo doppio
clic sull'icona Servizi nel Pannello di controllo.

2. Trovare i servizi che iniziano con Hyper-V.

3. Fare clic con il pulsante destro del mouse sul servizio che si desidera avviare o arrestare.
Selezionare l'azione desiderata.

Usare PowerShell per avviare o arrestare un servizio di

integrazione all'interno di un guest Windows
1. Per ottenere un elenco di servizi di integrazione, eseguire:

PowerShell

Get-Service -Name vmic* | FT -AutoSize

2. L'output deve essere simile al seguente:

PowerShell

Status Name DisplayName

------ ---- -----------
Running vmicguestinterface Hyper-V Guest Service Interface
Running vmicheartbeat Hyper-V Heartbeat Service
Running vmickvpexchange Hyper-V Data Exchange Service
Running vmicrdv Hyper-V Remote Desktop Virtualization Service
Running vmicshutdown Hyper-V Guest Shutdown Service
Running vmictimesync Hyper-V Time Synchronization Service
 Stopped vmicvmsession Hyper-V PowerShell Direct Service
Running vmicvss Hyper-V Volume Shadow Copy Requestor

3. Eseguire Start-Service o Stop-Service. Ad esempio, per disattivare Windows PowerShell

Direct, eseguire:

PowerShell

Stop-Service -Name vmicvmsession

Avviare e arrestare un servizio di integrazione da

un guest di Linux
I servizi di integrazione Linux vengono in genere forniti attraverso il kernel Linux. Il driver di
Servizi di integrazione Linux è denominato hv_utils.

1. Per verificare se hv_utils viene caricato, usare questo comando:

Bash

lsmod | grep hv_utils

2. L'output deve essere simile al seguente:

Bash

Module Size Used by

hv_utils 20480 0
hv_vmbus 61440 8
hv_balloon,hyperv_keyboard,hv_netvsc,hid_hyperv,hv_utils,hyperv_fb,hv_storvsc

3. Per verificare se i daemon necessari sono in esecuzione, usare questo comando.

Bash

ps -ef | grep hv

4. L'output deve essere simile al seguente:

Bash

root 236 2 0 Jul11 ? 00:00:00 [hv_vmbus_con]

root 237 2 0 Jul11 ? 00:00:00 [hv_vmbus_ctl]
 ...
root 252 2 0 Jul11 ? 00:00:00 [hv_vmbus_ctl]
root 1286 1 0 Jul11 ? 00:01:11 /usr/lib/linux-tools/3.13.0-
32-generic/hv_kvp_daemon
root 9333 1 0 Oct12 ? 00:00:00 /usr/lib/linux-tools/3.13.0-
32-generic/hv_kvp_daemon
root 9365 1 0 Oct12 ? 00:00:00 /usr/lib/linux-tools/3.13.0-
32-generic/hv_vss_daemon
user 43774 43755 0 21:20 pts/0 00:00:00 grep --color=auto hv

5. Per visualizzare i daemon disponibili, eseguire:

Bash

compgen -c hv_

6. L'output deve essere simile al seguente:

Bash

hv_vss_daemon
hv_get_dhcp_info
hv_get_dns_info
hv_set_ifconfig
hv_kvp_daemon
hv_fcopy_daemon

I daemon del servizio di integrazione che potrebbero essere elencati includono i seguenti.
Se mancano, potrebbero non essere supportati nel sistema o potrebbero non essere
installati. Per trovare i dettagli, vedere Macchine virtuali Linux e FreeBSD supportate per
Hyper-V in Windows.

hv_vss_daemon: questo daemon è necessario per creare backup di macchine virtuali

Linux attive.
hv_kvp_daemon: questo daemon consente l'impostazione e l'esecuzione di query su
coppie di valori di chiave intrinseche ed estriniche.
hv_fcopy_daemon: questo daemon implementa un servizio di copia file tra l'host e il
guest.

Examples
Questi esempi illustrano l'arresto e l'avvio del daemon KVP, denominato hv_kvp_daemon .

1. Usare l'ID processo (PID) per arrestare il processo del daemon. Per trovare il PID,
esaminare la seconda colonna dell'output o usare pidof . I daemon di Hyper-V vengono
 eseguiti come utente root, perciò è necessario disporre dei permessi di root.

Bash

sudo kill -15 `pidof hv_kvp_daemon`

2. Per verificare che tutti i hv_kvp_daemon processi non siano più presenti, eseguire:

Bash

ps -ef | hv

3. Per eseguire di nuovo il demone, eseguire il demone come utente root.

Bash

sudo hv_kvp_daemon

4. Per verificare che il hv_kvp_daemon processo sia elencato con un nuovo ID processo,
eseguire:

Bash

ps -ef | hv

Mantenere aggiornati i servizi di integrazione

È consigliabile mantenere aggiornati i servizi di integrazione per ottenere le migliori prestazioni
e le funzionalità più recenti per le macchine virtuali. Ciò si verifica per gli utenti guest di
Windows per impostazione predefinita se sono configurati per ottenere aggiornamenti
importanti da Windows Update. Gli utenti guest Linux che usano i kernel correnti contengono
servizi di integrazione incorporati, ma potrebbero essere disponibili aggiornamenti facoltativi.
Quando si aggiorna il kernel, si riceveranno i componenti di integrazione più recenti. Per
ulteriori informazioni sui guest di Linux, vedere Macchine virtuali Linux e FreeBSD supportate
per Hyper-V in Windows.

Installare o aggiornare i servizi di integrazione per

gli host Hyper-V precedenti a Windows Server 2016
e Windows 10
Per gli host Hyper-V precedenti a Windows Server 2016 e Windows 10, è necessario installare
o aggiornare manualmente i servizi di integrazione nei sistemi operativi guest.

Per installare o aggiornare manualmente i servizi di integrazione:

1. Aprire la console di gestione di Hyper-V.

2. Connettersi alla macchina virtuale. Fare clic con il pulsante destro del mouse sulla
macchina virtuale e scegliere Connetti.

3. Dal menu Azione di Virtual Machine Connection selezionare Inserire disco di

installazione di Integration Services. Questa azione determina il caricamento del disco di
installazione nell'unità DVD virtuale. A seconda del sistema operativo guest, potrebbe
essere necessario avviare l'installazione manualmente da Esplora file.

4. Al termine dell'installazione, i servizi di integrazione saranno disponibili per l'uso.

Panoramica di Hyper-V Replica
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Azure Local 2311.2 and later

Hyper-V Replica è una funzionalità predefinita di Hyper-V in Windows Server che consente la
replica di macchine virtuali tra Hyper-V host per la continuità aziendale e il ripristino di
emergenza (BCDR). Consente di creare e gestire copie offline di macchine virtuali in un host
secondario e persino di estendersi a un terzo host, che è possibile usare per il failover in caso
di errore di un host primario. Hyper-V Replica non è disponibile in Hyper-V nei sistemi
operativi client Windows.

Hyper-V failover clustering e Hyper-V Replica risolvono scenari di disponibilità che sono
correlati ma distinti. Un cluster di failover Hyper-V offre disponibilità elevata locale per
l'esecuzione di macchine virtuali usando più host (nodi) che in genere accedono alla stessa
risorsa di archiviazione in cluster. Se un nodo non riesce, il servizio cluster riavvia la macchina
virtuale interessata in un altro nodo, senza perdita di dati (o minima) perché i dischi rigidi
virtuali della macchina virtuale rimangono nell'archiviazione condivisa. Hyper-V Replica, al
contrario, è una tecnologia di ripristino di emergenza che gestisce una copia asincrona
dell'archiviazione di una macchina virtuale in un altro host o cluster, spesso in un sito diverso,
in modo da poter avviare manualmente il failover se l'host primario, il cluster o il sito non è più
disponibile. La replica non richiede l'archiviazione condivisa, introduce un obiettivo del punto
di ripristino (potenziale perdita di dati fino all'intervallo di replica) e integra anziché sostituire il
clustering di failover. Molte organizzazioni usano entrambi: il clustering per la disponibilità
elevata all'interno del sito e la replica Hyper-V per la resilienza e il ripristino tra siti.

Questo articolo offre una panoramica di Hyper-V Replica, delle relative funzionalità chiave, del
suo funzionamento e del modo in cui è possibile usarla per migliorare la strategia BCDR.

Funzionalità principali di Hyper-V Replica

Hyper-V Replica offre diverse funzionalità chiave che lo rendono uno strumento potente e
conveniente per la replica di macchine virtuali e il ripristino di emergenza:

Carico di lavoro e applicazione indipendente: Hyper-V Replica funziona a livello di

hypervisor, rendendolo adatto per replicare un'ampia gamma di carichi di lavoro e
applicazioni senza richiedere agenti o configurazioni specifici dell'applicazione.

Replica asincrona: le modifiche apportate alla macchina virtuale primaria vengono

confrontate usando il rilevamento delle modifiche resilienti (RCT) a livello di blocco e
possono essere inviate alla macchina virtuale di replica a intervalli regolari di 30 secondi, 5
minuti o 15 minuti, a seconda dei requisiti dell'obiettivo del punto di ripristino (RPO). RCT
riduce la necessità di controlli di coerenza dispendiosi in termini di tempo e offre una
grande resilienza.

Failover pianificato e non pianificato: in un failover pianificato, la macchina virtuale

primaria si arresta normalmente e replica le modifiche rimanenti prima di passare alla
replica. In un failover non pianificato, la macchina virtuale di replica viene avviata senza
arrestare la macchina virtuale primaria, con conseguente perdita di dati. Dopo aver
ripristinato l'host primario, è possibile eseguire una replica inversa per sincronizzare le
modifiche alla macchina virtuale primaria originale. Per altre informazioni, vedere Failover
e recupero.

Topologie flessibili: replicare tra singoli host, host in cluster o una combinazione di
entrambi, consentendo di progettare una strategia di replica adatta all'infrastruttura. Gli
host possono trovarsi nello stesso sito o in posizioni geografiche diverse.

Crittografia e autenticazione: supporto sia per Kerberos (per gli host aggiunti a un
dominio) che per l'autenticazione basata su certificati (per gli host non aggiunti a un
dominio), offrendo flessibilità nella protezione del traffico di replica. Crittografare il
traffico di replica con un certificato per proteggere i dati in transito. È possibile limitare la
replica tra host di Hyper-V specifici per migliorare la sicurezza.

Opzioni di archiviazione flessibili: replica basata su file indipendente dall'archiviazione e

dal carico di lavoro, consentendo flessibilità nella progettazione dell'infrastruttura per
l'uso di diversi tipi di soluzioni di archiviazione per gli host primario e di replica. È
possibile scegliere di replicare tutti i dischi rigidi virtuali per una macchina virtuale o solo
un subset di essi, consentendo di ottimizzare l'utilizzo dell'archiviazione e le prestazioni di
replica.

Rete e compressione: la replica è basata su TCP tramite HTTP o HTTPS. È possibile

abilitare la compressione per ridurre l'utilizzo della larghezza di banda durante la replica.

Cronologia di ripristino: fino a 24 punti di ripristino orari consentono di ripristinare uno

stato precedente della macchina virtuale, se necessario. L'integrazione del Volume
Shadow Copy Service (VSS) può fornire punti di ripristino consistenti con le applicazioni
per le macchine virtuali che eseguono applicazioni che supportano VSS, come Microsoft
SQL Server.

Test failover: eseguire test failover per convalidare il piano di disaster recovery senza
influire sull'ambiente di produzione. Per altre informazioni, vedere Failover e ripristino.

Replica estesa: è possibile estendere la replica dall'host secondario a un terzo host

Hyper-V, creando una topologia di replica a tre livelli. Questo approccio offre un ulteriore
livello di ridondanza e offre strategie BCDR più complesse. È possibile usare un intervallo
di replica diverso per la replica estesa per bilanciare gli obiettivi del punto di ripristino
 (RPO) e l'utilizzo della larghezza di banda in diversi siti. La replica non viene eseguita dal
server primario a due altri server di replica. Invece, il server primario replica al server di
replica, che a sua volta replica al server di replica estesa.

Nessun costo aggiuntivo per le licenze: Hyper-V Replica è incluso in Windows Server
senza costi aggiuntivi, rendendola una soluzione conveniente per la replica di macchine
virtuali e il ripristino di emergenza.

componenti di replica Hyper-V

Hyper-V Replica include i componenti descritti nella tabella seguente:

ﾉ Espandi la tabella

Componente Description

Motore di replica Gestisce la replica iniziale, i dettagli di configurazione della replica, la replica delle
modifiche differenziali e le operazioni di failover e test. Tiene traccia degli eventi di
mobilità delle macchine virtuali e dell'archiviazione e esegue le azioni appropriate
quando necessario.

Modulo di Tiene traccia delle modifiche apportate alla macchina virtuale in un host di Hyper-V
rilevamento delle di origine monitorando le operazioni di scrittura nei dischi rigidi virtuali
modifiche ,indipendentemente dalla posizione di archiviazione (locale, SAN, NAS, SMB 3 o
versione successiva o volume condiviso cluster).

Modulo di rete Fornisce un modo sicuro ed efficiente per trasferire i dati delle macchine virtuali tra
Hyper-V host. Riduce al minimo il traffico comprimendo i dati per impostazione
predefinita e può crittografare i dati quando viene usata l'autenticazione basata su
HTTPS e su certificato.

Gestore di replica Usato solo quando un host Hyper-V è un nodo in un cluster di failover. Consente
Hyper-V l'uso di Hyper-V Replica con macchine virtuali a disponibilità elevata che possono
spostarsi tra i nodi del cluster eseguendo query sul database del cluster e
reindirizzando le richieste al nodo in cui è in esecuzione la macchina virtuale.

Strumenti di Configurare e gestire Hyper-V Replica con Hyper-V Manager e Windows

gestione PowerShell. Usare Gestore cluster di failover per la gestione delle macchine virtuali e
le configurazioni di Hyper-V Replica quando gli host di origine o di replica fanno
parte di un cluster di failover.

Funzionamento di replica Hyper-V

Hyper-V Replica funziona replicando le modifiche apportate a una macchina virtuale primaria
in una macchina virtuale di replica in un host secondario Hyper-V. L'approccio adottato
dipende dal fatto che si stia eseguendo la replica in un cluster Hyper-V o in un singolo host. Si
configura il cluster o l'host ricevente, non il cluster o l'host primario. Configurare sia gli host
primari che secondari per la replica per assicurarsi che sia possibile eseguire il failback nell'host
primario originale dopo un failover.

Hyper-V Replica può avere le due istanze seguenti di una singola macchina virtuale che si
trovano in host Hyper-V diversi:

La macchina virtuale principale, che esegue attivamente, denominata macchina virtuale

primaria.
Una copia offline della macchina virtuale primaria, denominata macchina virtuale di
replica.

Il processo di replica prevede diversi componenti chiave e passaggi, descritti nel diagramma
seguente:

Primary Site Hyper-V Replica traffic Secondary Site

Primary virtual machines Replica virtual machines

One-time
Hyper-V virtual machine configuration Hyper-V
cluster or cluster or
standalone standalone
host host

TCP port 80 or 443

Virtual hard Tracked Virtual hard
disks changes disks

1. Quando si abilita Hyper-V Replica per una macchina virtuale, si crea una copia iniziale
della macchina virtuale nell'host secondario. È possibile inviare questa copia in rete o
usando supporti esterni.

2. Hyper-V usa un meccanismo di rilevamento delle modifiche per monitorare le modifiche

apportate ai dischi rigidi virtuali della macchina virtuale primaria. Archivia le modifiche nei
.hrl file nella stessa posizione. Questo approccio consente di Hyper-V identificare i

blocchi di dati modificati dall'ultimo ciclo di replica.

3. All'intervallo di replica configurato (30 secondi, 5 minuti o 15 minuti), Hyper-V invia le

modifiche all'host secondario. Il processo di replica è asincrono, quindi la macchina
 virtuale primaria continua a funzionare mentre Hyper-V replica le modifiche.

4. L'host secondario riceve le modifiche e le applica ai dischi rigidi virtuali della macchina
virtuale di replica, assicurando che la macchina virtuale di replica rimanga up-to-date con
la macchina virtuale primaria.

5. Se un host primario ha esito negativo, si avvia un failover nella macchina virtuale di

replica. A seconda che si tratti di un failover pianificato o non pianificato, il processo è
leggermente diverso, ma il risultato finale è che la macchina virtuale di replica diventa la
nuova macchina virtuale primaria. È possibile avviare il failover manualmente o tramite
script di automazione.

6. Dopo aver ripristinato l'host primario, è possibile eseguire una replica inversa per
sincronizzare le modifiche apportate alla macchina virtuale di replica alla macchina
virtuale primaria originale, consentendogli di riprendere il ruolo come host primario.

Pianificare la replica Hyper-V

Quando si prevede di implementare Hyper-V Replica come parte della strategia BCDR,
prendere in considerazione e prendere decisioni sui punti di progettazione seguenti:

ﾉ Espandi la tabella

Punto di decisione Dettagli di supporto

Quali carichi di lavoro si Elencare le macchine virtuali di destinazione e i relativi carichi di lavoro. La
vuole replicare? replica predefinita protegge lo stato del sistema operativo, non lo stato in
esecuzione dell'applicazione. Se è necessario ripristinare lo stato
dell'applicazione, abilitare (e pianificare) punti di ripristino coerenti con
l'applicazione.

Quali VHD devono essere Escludere i dischi i cui dati modificati non sono necessari dopo il failover
replicati? (ad esempio, file di pagine o dischi dati temporanei) per risparmiare
larghezza di banda e archiviazione. Esclusioni di documenti.

Con quale frequenza è Scegliere 30 secondi, 5 minuti o 15 minuti in base a RPO, criticità e
necessario sincronizzare i larghezza di banda. Una maggiore urgenza e un RPO inferiore devono
dati? favorire intervalli più brevi; verificare la capacità di rete disponibile.

Qual è la frequenza di Un alto turnover aumenta il consumo di banda e di archiviazione delle

modifica dei dati in ogni repliche. Prendere in considerazione la compressione o un intervallo più
macchina virtuale? lungo se si verifica la saturazione. Includere ogni macchina virtuale nei
calcoli di ridimensionamento.
 Punto di decisione Dettagli di supporto

Quale metodo di Usare Kerberos quando entrambi gli host sono aggiunti a un dominio e non
autenticazione si userà e si è necessaria la crittografia. Usare l'autenticazione basata su certificati per
richiede la crittografia? crittografare il traffico di replica e/o se uno degli host non è aggiunto a un
dominio; effettuare il provisioning e considerare attendibili i certificati
necessari in anticipo.

È necessario eseguire il Il valore predefinito è un singolo (più recente) punto di ripristino.

failover a un punto Configurare fino a 24 punti orari per il recupero temporizzato; più punti
precedente nel tempo? aumentano l'overhead di archiviazione e I/O.

Come si esegue il seeding Options:

della replica iniziale dei - Invia in rete immediatamente.
dati della macchina - Pianificare il trasferimento di rete per un intervallo di tempo successivo.
virtuale? - Usare una macchina virtuale ripristinata esistente nell'host di replica.
- Esporta su supporti esterni, spedisci e importa presso il sito di replica.

Failover e ripristino
È importante testare regolarmente il piano BCDR per assicurarsi che Hyper-V Replica funzioni
come previsto e che sia possibile eseguire correttamente il failover e il ripristino delle macchine
virtuali. È necessario eseguire failover di test, convalidare i punti di ripristino e assicurarsi che
tutti i componenti della strategia di replica funzionino correttamente. I test regolari consentono
di identificare potenziali problemi e di assicurarsi che il team abbia familiarità con i processi di
failover e ripristino.

Esistono tre tipi di scenari di failover in Hyper-V Replica:

È possibile eseguire un failover di test in qualsiasi momento senza influire sull'ambiente di

produzione. Un failover di test crea una copia temporanea della macchina virtuale di
replica nell'host secondario, consentendo di convalidare il processo di failover e
assicurarsi che la macchina virtuale venga avviata correttamente. La macchina virtuale di
test è isolata dalla rete di produzione per evitare conflitti. La macchina virtuale primaria
continua a essere eseguita durante un failover di test, quindi non si verificano tempi di
inattività e il processo di replica non è interessato. Dopo aver completato il test, inclusi gli
altri componenti del piano BCDR, è possibile eliminare la macchina virtuale di test senza
influire sulla macchina virtuale di replica o sulla macchina virtuale primaria.

In un failover pianificato, la macchina virtuale primaria viene arrestata normalmente e

tutte le modifiche rimanenti vengono replicate nella macchina virtuale di replica prima di
cambiare i ruoli. Questo approccio garantisce che non si verifichi alcuna perdita di dati
durante il processo di failover. Durante un failover pianificato non viene creata alcuna
macchina virtuale duplicata. L'azione di failover viene avviata dall'host primario. È
 possibile invertire la replica dopo che l'host primario è nuovamente disponibile per
sincronizzare le modifiche apportate alla macchina virtuale di replica alla macchina
virtuale primaria originale, quindi eseguire un altro failover pianificato per tornare
indietro.

In un failover non pianificato, la macchina virtuale di replica viene avviata senza arrestare
la macchina virtuale primaria, con conseguente perdita di dati. La macchina virtuale di
replica diventa la nuova macchina virtuale primaria e successivamente è possibile
eseguire una replica inversa per sincronizzare le modifiche alla macchina virtuale primaria
originale dopo il ripristino. Durante un failover non pianificato non viene creata alcuna
macchina virtuale duplicata. L'azione di failover viene avviata dall'host secondario.

Per ulteriori informazioni sull'esecuzione di operazioni di failover e ripristino con Hyper-V

Replica, vedere Failover di una macchina virtuale replicata con Hyper-V Replica.

Passo successivo
Per configurare Hyper-V Replica, selezionare uno degli articoli seguenti in base all'ambiente:

Abilitare Hyper-V Replica su un cluster di failover

Abilitare replica Hyper-V in un singolo host

） Nota: L'autore ha creato questo articolo con l’assistenza dell'intelligenza artificiale. Ulteriori informazioni

Last updated on 17/11/2025

Abilitare la riproduzione Hyper-V in un
cluster di failover
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Azure Local 2311.2 and later

Hyper-V Replica consente di proteggere i carichi di lavoro replicando macchine virtuali tra
Hyper-V host che eseguono Windows Server. Questo articolo illustra come abilitare Hyper-V
Replica in un cluster di failover.

È possibile eseguire la replica tra cluster, singoli host o una combinazione di entrambi. Se si usa
un certificato per l'autenticazione, non esiste alcuna dipendenza di Active Directory tra gli host.
I singoli host possono essere membri di dominio o essere in un gruppo di lavoro.

Per informazioni su come abilitare Hyper-V Replica in un singolo host, vedere Abilitare la
replica Hyper-V in un singolo host. Per altre informazioni su Hyper-V Replica e sul relativo
funzionamento, vedere panoramica diHyper-V Replica.

Prerequisiti
Prima di iniziare, assicurarsi di soddisfare i prerequisiti seguenti:

È disponibile un cluster Hyper-V per ricevere la macchina virtuale replicata. È anche

disponibile un altro cluster o un singolo host che esegue la macchina virtuale da replicare.

Scegliere un metodo di autenticazione:

Se i cluster e gli host sono aggiunti agli stessi domini di Active Directory o attendibili, è
possibile usare l'autenticazione Kerberos (HTTP).

Se i cluster e gli host non sono aggiunti a un dominio o si trovano in domini non
attendibili o si vuole usare anche la crittografia, è necessario usare l'autenticazione
basata su certificati (HTTPS). È necessario avere un certificato valido installato in ogni
host, sia per l'invio che per la ricezione. Il certificato deve soddisfare i requisiti
seguenti:
Non deve essere scaduto
Avere attributi Enhanced Key Usage (EKU) per l'autenticazione sia del client che del
server e una chiave privata associata.
Termina con un certificato radice valido.
Il nome comune del soggetto (CN) o il nome alternativo del soggetto (SAN) deve
corrispondere al nome di dominio completo (FQDN) del ruolo gestore di replica di
Hyper-V fornito per il cluster ricevente. Se si invia una macchina virtuale da un
 cluster, è necessario anche un certificato per l'FQDN del ruolo Gestore di replica
Hyper-V in ogni host primario.

Connettività di rete tra i cluster e gli host. Per impostazione predefinita, se si usa
l'autenticazione Kerberos, la replica usa HTTP sulla porta 80. Se si usa l'autenticazione
basata su certificati, la replica usa HTTPS sulla porta 443.

Posizione di archiviazione nel cluster ricevente disponibile per tutti i nodi in cui archiviare
le macchine virtuali replicate.

Il ruolo gestore di replica Hyper-V richiede un indirizzo IP. Assicurarsi che per la rete del
cluster usata per la gestione sia disponibile un indirizzo IP statico nella subnet o che sia
disponibile DHCP nella subnet.

Un account utente con privilegi amministrativi sia per i cluster primario che per gli host di
replica.

Un account utente amministratore di dominio, o precreare un account computer in Active

Directory per il ruolo di Gestore Replica Hyper-V del cluster ricevente. Per altre
informazioni, vedere Pre-installare un account per un servizio o un'applicazione in cluster.

Abilitare il ruolo Gestore di replica Hyper-V

Prima di poter replicare le macchine virtuali in un cluster Hyper-V, è necessario abilitare il ruolo
gestore di replica Hyper-V. Si configura il cluster ricevente, non il cluster primario o l'host.

Hyper-V Replica Broker è un ruolo cluster che funge da destinazione per il traffico di replica.
Fornisce un singolo punto di contatto per il server primario a cui connettersi, anche se la
macchina virtuale di replica si sposta tra i nodi del cluster.

Per assicurarsi che sia possibile eseguire il failback di una macchina virtuale al cluster primario
o all'host originale dopo un evento di failover, configurare sia i cluster primari che gli host di
replica per la replica.

Usare Gestione cluster di failover o PowerShell per abilitare e configurare il ruolo gestore di
replica Hyper-V. Selezionare la scheda pertinente per le istruzioni.

Gestione del cluster di Failover

Per attivare e impostare il ruolo di cluster del Replica Broker di Hyper-V utilizzando
Failover Cluster Manager:

1. Aprire Gestione cluster di failover su un dispositivo usato per gestire il cluster verso
cui si desidera replicare o su uno dei nodi del cluster.
2. Nel riquadro sinistro espandere il nome del cluster in cui si vuole eseguire la replica e
quindi selezionare Ruoli.

3. Nel riquadro Azioni a destra selezionare Configura ruolo. Nella Procedura guidata
per l'alta disponibilità, se viene visualizzato Prima di iniziare, selezionare Avanti.

4. Per Seleziona ruolo selezionare Hyper-V Gestore di repliche e quindi selezionare

Avanti.

5. Per Punto di accesso client immettere il nome che si vuole usare per Hyper-V Replica
Broker, quindi selezionare Avanti. Il nome viene usato come nome NetBIOS per il
ruolo ed è limitato a 15 caratteri. Questo nome deve essere univoco nel dominio di
Active Directory.
 

6. Per Conferma esaminare le informazioni e quindi selezionare Avanti. Il ruolo "Replica

Broker" di Hyper-V è configurato. Inizialmente, il ruolo tenta di ottenere un indirizzo
IP da DHCP. È possibile modificare questa impostazione in un secondo momento se
si vuole usare un indirizzo IP statico. Se DHCP non è disponibile nella subnet, il ruolo
non viene online finché non si assegna un indirizzo IP statico.

7. Visualizzare il riepilogo, quindi selezionare Fine. È anche possibile visualizzare un log

delle azioni eseguite selezionando Visualizza report, che viene aperto in una finestra
del browser.

8. Nel riquadro Ruoli fare clic con il pulsante destro del mouse sul nuovo ruolo Gestore
di replicaHyper-V , quindi scegliere Impostazioni replica.

9. Nella finestra di dialogo Configurazione del Broker di Replica Hyper-V, apportare le

modifiche seguenti:

a. Selezionare la casella Abilita questo cluster come server di replica.

b. Selezionare la casella relativa al metodo di autenticazione che si vuole usare da

Usare Kerberos (HTTP) o Usare l'autenticazione basata su certificati (HTTPS).
Modificare la porta se non si vogliono usare le porte predefinite. Se si usa
l'autenticazione basata su certificati, selezionare Seleziona certificato, quindi
viene richiesto di selezionare il certificato che soddisfa i requisiti.

c. Per Autorizzazione e archiviazione selezionare Consenti replica da qualsiasi

server autenticato per consentire al server di replica di accettare il traffico di
 replica delle macchine virtuali da qualsiasi server primario che esegue
correttamente l'autenticazione oppure Consentire la replica dai server specificati
per accettare il traffico solo dai server primari selezionati in modo specifico. Per
entrambe le opzioni, è necessario specificare dove archiviare i dischi rigidi virtuali
replicati nel cluster di replica Hyper-V. Per un cluster, questa posizione deve essere
accessibile da tutti i nodi del cluster, come un Cluster Shared Volume (CSV) in
C:\ClusterStorage\Volume1\Replica .

Se si seleziona Consenti replica dai server specificati, selezionare Aggiungi. In

Aggiungi voce di autorizzazione, specificare il nome di dominio completo di un
host primario, un percorso in cui archiviare i file di replica e un gruppo di
attendibilità. Un gruppo di attendibilità è un campo di testo in formato libero che
è possibile usare per raggruppare i server primari. Seleziona OK.

d. Selezionare OK per salvare le impostazioni.


Abilitare le regole di Windows Firewall per la
replica Hyper-V
Per consentire la replica tra cluster e host primario e di replica, il traffico deve attraversare
Windows Firewall (o qualsiasi altro firewall di terze parti). Quando si installa il ruolo Hyper-V in
ogni host, Windows Firewall crea eccezioni per HTTP (80) e HTTPS (443), ma non le abilita per
impostazione predefinita. È necessario abilitare le regole appropriate per tutti gli host riceventi.

È possibile abilitare le regole usando il metodo preferito per la gestione di Windows Firewall,
ad esempio l'uso centrale di Criteri di gruppo o localmente in ogni nodo usando Windows
Firewall con la console sicurezza avanzata o PowerShell. Per altre informazioni sulla gestione di
Windows Firewall e sulle guide pratiche, vedere Strumenti di Windows Firewall.

Le regole che è necessario abilitare dipendono dal metodo di autenticazione scelto quando è
stato configurato il ruolo Gestore di replica Hyper-V:

Abilitare Hyper-V Replica HTTP Listener (TCP-In) per l'autenticazione Kerberos (HTTP).
Abilitare Hyper-V Replica HTTPS Listener (TCP-In) per l'autenticazione basata su
certificato (HTTPS).

Testare la configurazione della replica

Dopo aver abilitato e configurato Hyper-V Replica e aver abilitato le regole di Windows Firewall
appropriate, testare la configurazione per assicurarsi che il cluster primario o l'host possa
connettersi all'host di replica come previsto.

È possibile usare il cmdlet Test-VMReplicationConnection di PowerShell per testare la

connessione, come illustrato negli esempi seguenti. Assicurarsi di sostituire il segnaposto
<values> con il proprio.

1. Aprire una sessione di PowerShell come amministratore in uno degli host da cui si vuole
eseguire la replica o connettersi in remoto usando il cmdlet Enter-PSSession in un
dispositivo usato per gestire il cluster o l'host.

2. Usare uno dei comandi di esempio seguenti:

Per testare una connessione a un cluster di replica usando l'autenticazione Kerberos,

eseguire il comando seguente:

PowerShell
Test-VMReplicationConnection -ReplicaServerName '<Hyper-V Broker role
FQDN>' -ReplicaServerPort 80 -AuthenticationType Kerberos
 Per testare una connessione a un cluster di replica usando l'autenticazione basata su
certificato, eseguire il comando seguente. Serve l'impronta digitale di un certificato
valido per Hyper-V Replica sull'host o sul cluster primario.

PowerShell
Test-VMReplicationConnection -ReplicaServerName '<Hyper-V Broker role
FQDN>' -ReplicaServerPort 443 -AuthenticationType Certificate -
CertificateThumbprint AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00

Per uno di questi comandi di esempio, di seguito è riportato l'output che verrà
visualizzato se il test ha esito positivo:

Output
The connection to the specified Replica server with the specified parameters
was successful.

） Nota: L'autore ha creato questo articolo con l’assistenza dell'intelligenza artificiale. Ulteriori informazioni

Last updated on 17/11/2025

Abilitare replica Hyper-V in un singolo host
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Azure Local 2311.2 and later

Hyper-V Replica consente di proteggere i carichi di lavoro replicando macchine virtuali tra
Hyper-V host che eseguono Windows Server. Questo articolo illustra come abilitare Hyper-V
Replica in un singolo host usando Hyper-V Manager, PowerShell o Windows Admin Center -
Modalità di virtualizzazione.

È possibile eseguire la replica tra cluster, singoli host o una combinazione di entrambi. Se si usa
un certificato per l'autenticazione, non esiste alcuna dipendenza di Active Directory tra gli host.
I singoli host possono essere membri di dominio o essere in un gruppo di lavoro.

Per informazioni su come abilitare Hyper-V Replica in un cluster di failover, vedere Abilitare
invece replica Hyper-V in un cluster di failover. Per altre informazioni su Hyper-V Replica e sul
relativo funzionamento, vedere panoramica diHyper-V Replica.

Prerequisiti
Prima di iniziare, assicurarsi di soddisfare i prerequisiti seguenti:

È disponibile un singolo host Hyper-V per ricevere la macchina virtuale replicata. È anche
disponibile un altro cluster o un singolo host che esegue la macchina virtuale da replicare.

Scegliere un metodo di autenticazione:

Se gli host sono aggiunti agli stessi domini di Active Directory o attendibili, è possibile
usare l'autenticazione Kerberos (HTTP).

Se gli host non sono aggiunti a un dominio o si trovano in domini non attendibili o si
vuole usare anche la crittografia, è necessario usare l'autenticazione basata su
certificati (HTTPS). È necessario avere un certificato valido installato in ogni host, sia
per l'invio che per la ricezione. Il certificato deve soddisfare i requisiti seguenti:
Non deve essere scaduto
Avere attributi Enhanced Key Usage (EKU) per l'autenticazione sia del client che del
server e una chiave privata associata.
Termina con un certificato radice valido.
Il nome comune del soggetto (CN) o il nome alternativo del soggetto (SAN) deve
corrispondere al nome di dominio completo (FQDN) dell'host. Se si invia una
macchina virtuale da un cluster, è necessario anche un certificato per l'FQDN del
ruolo Gestore di replica Hyper-V in ogni host primario.
 Connettività di rete tra gli host. Per impostazione predefinita, se si usa l'autenticazione
Kerberos, la replica usa HTTP sulla porta 80. Se si usa l'autenticazione basata su certificati,
la replica usa HTTPS sulla porta 443.

Posizione di archiviazione nell'host ricevente per archiviare le macchine virtuali replicate.

Un account utente con privilegi amministrativi sia per i cluster primario che per gli host di
replica.

Abilitare la replica Hyper-V

Prima di poter replicare le macchine virtuali in un singolo host Hyper-V, è necessario abilitare
Hyper-V Replica. Si configura l'host ricevente, non il cluster primario o l'host.

Per assicurarsi che sia possibile eseguire il failback di una macchina virtuale all'host o al cluster
primario originale dopo un evento di failover, configurare sia gli host primari che i cluster per la
replica.

Usare Hyper-V Manager, PowerShell o Windows Admin Center - Modalità di virtualizzazione

per abilitare e configurare Hyper-V Replica. Selezionare la scheda pertinente per le istruzioni.

Hyper-V Manager

Per abilitare e configurare Hyper-V Replica tramite Hyper-V Manager:

1. Aprire Hyper-V Manager in un dispositivo usato per gestire l'host in cui si vuole
eseguire la replica o nell'host stesso in cui è installato Windows Server con
Esperienza desktop.

2. Nel riquadro sinistro selezionare l'host che si vuole configurare come server di
replica.

3. Nel riquadro destro, in Azioni, selezionare Hyper-V Impostazioni.

4. Nella sezione Server selezionare Configurazione replica nel riquadro sinistro e

apportare le modifiche seguenti:

a. Selezionare la casella Abilita il computer come server di replica.

b. Per Autenticazione e porte, selezionare la casella relativa al metodo di

autenticazione che si vuole usare da Usa Kerberos (HTTP) o Usare
l'autenticazione basata su certificati (HTTPS). Modificare la porta se non si
vogliono usare le porte predefinite. Se si usa l'autenticazione basata su certificati,
 selezionare Seleziona certificato, quindi viene richiesto di selezionare il certificato
che soddisfa i requisiti.

c. Per Autorizzazione e archiviazione selezionare Consenti replica da qualsiasi

server autenticato per consentire al server di replica di accettare il traffico di
replica delle macchine virtuali da qualsiasi server primario che esegue
correttamente l'autenticazione oppure Consentire la replica dai server specificati
per accettare il traffico solo dai server primari selezionati in modo specifico. Per
entrambe le opzioni, è necessario specificare dove archiviare i dischi rigidi virtuali
replicati nell'host di replica.

Se si seleziona Consenti replica dai server specificati, selezionare Aggiungi. In

Aggiungi voce di autorizzazione, specificare il nome di dominio completo di un
host primario, un percorso in cui archiviare i file di replica e un gruppo di
attendibilità. Un gruppo di attendibilità è un campo di testo in formato libero che
è possibile usare per raggruppare i server primari. Seleziona OK.

d. Selezionare OK per salvare le impostazioni.


Abilitare le regole di Windows Firewall per la
replica Hyper-V
Per consentire la replica tra cluster e host primario e di replica, il traffico deve attraversare
Windows Firewall (o qualsiasi altro firewall di terze parti). Quando si installa il ruolo Hyper-V in
ogni host, Windows Firewall crea eccezioni per HTTP (80) e HTTPS (443), ma non le abilita per
impostazione predefinita. È necessario abilitare le regole appropriate per tutti gli host riceventi.

È possibile abilitare le regole usando il metodo preferito per la gestione di Windows Firewall,
ad esempio l'uso centrale di Criteri di gruppo o localmente in ogni nodo usando Windows
Firewall con la console sicurezza avanzata o PowerShell. Per altre informazioni sulla gestione di
Windows Firewall e sulle guide pratiche, vedere Strumenti di Windows Firewall.

Le regole che è necessario abilitare dipendono dal metodo di autenticazione scelto quando è
stato configurato il ruolo Gestore di replica Hyper-V:

Abilitare Hyper-V Replica HTTP Listener (TCP-In) per l'autenticazione Kerberos (HTTP).
Abilitare Hyper-V Replica HTTPS Listener (TCP-In) per l'autenticazione basata su
certificato (HTTPS).

Testare la configurazione della replica

Dopo aver abilitato e configurato Hyper-V Replica e aver abilitato le regole di Windows Firewall
appropriate, testare la configurazione per assicurarsi che il cluster primario o l'host possa
connettersi all'host di replica come previsto.

È possibile usare il cmdlet Test-VMReplicationConnection di PowerShell per testare la

connessione, come illustrato negli esempi seguenti. Assicurarsi di sostituire il segnaposto
<values> con il proprio.

1. Aprire una sessione di PowerShell come amministratore in uno degli host da cui si vuole
eseguire la replica o connettersi in remoto usando il cmdlet Enter-PSSession in un
dispositivo usato per gestire il cluster o l'host.

2. Usare uno dei comandi di esempio seguenti:

Per testare una connessione a un cluster di replica usando l'autenticazione Kerberos,

eseguire il comando seguente:

PowerShell
 Test-VMReplicationConnection -ReplicaServerName '<Replica host FQDN>' -
ReplicaServerPort 80 -AuthenticationType Kerberos

Per testare una connessione a un cluster di replica usando l'autenticazione basata su

certificato, eseguire il comando seguente. Serve l'impronta digitale di un certificato
valido per Hyper-V Replica sull'host o sul cluster primario.

PowerShell
Test-VMReplicationConnection -ReplicaServerName '<Replica host FQDN>' -
ReplicaServerPort 443 -AuthenticationType Certificate -
CertificateThumbprint AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00

Per uno di questi comandi di esempio, di seguito è riportato l'output che verrà
visualizzato se il test ha esito positivo:

Output
The connection to the specified Replica server with the specified parameters
was successful.

） Nota: L'autore ha creato questo articolo con l’assistenza dell'intelligenza artificiale. Ulteriori informazioni

Last updated on 17/11/2025

Replicare una macchina virtuale con replica
Hyper-V
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Azure Local 2311.2 and later

Hyper-V Replica consente di proteggere i carichi di lavoro replicando macchine virtuali tra
Hyper-V host che eseguono Windows Server. Questo articolo illustra come replicare una
macchina virtuale dopo aver abilitato la replica nell'host o nel cluster ricevente usando Hyper-V
Manager, Gestione cluster di failover, PowerShell o Windows Admin Center - Modalità di
virtualizzazione.

È possibile eseguire la replica tra cluster, singoli host o una combinazione di entrambi. Se si usa
un certificato per l'autenticazione, non esiste alcuna dipendenza di Active Directory tra gli host.
I singoli host possono essere membri di dominio o essere in un gruppo di lavoro.

Per altre informazioni su Hyper-V Replica e sul relativo funzionamento, vedere panoramica
diHyper-V Replica. Se è necessario abilitare Hyper-V Replica, vedere:

Abilitare Hyper-V Replica in un cluster di failover.

Abilitare Hyper-V Replica in un singolo host.

Prerequisiti
Prima di iniziare, assicurarsi di soddisfare i prerequisiti seguenti:

È disponibile un cluster Hyper-V per ricevere la macchina virtuale replicata in cui è già
stata configurata Hyper-V Replica. Se è necessario configurare Hyper-V Replica, vedere
Abilitare replica Hyper-V in un cluster di failover o Abilitare replica Hyper-V in un singolo
host. È anche disponibile un altro cluster o un singolo host che esegue la macchina
virtuale da replicare.

Connettività di rete e larghezza di banda sufficienti tra i siti primari e di replica per
soddisfare il metodo rpo (Recovery Point Objective) e il metodo di replica iniziale.
Prendere in considerazione la possibilità di dedicare il traffico di replica o limitare il
traffico tramite QoS per evitare di influire sui carichi di lavoro di produzione.

Se si usa l'autenticazione basata su certificati, è necessario avere un certificato valido

installato in ogni host in ogni cluster o singolo host, sia per l'invio che per la ricezione. Il
certificato deve soddisfare i requisiti seguenti:
Non deve essere scaduto
 Avere attributi Enhanced Key Usage (EKU) per l'autenticazione sia del client che del
server e una chiave privata associata.
Termina con un certificato radice valido.
Il nome comune del soggetto (CN) o il nome alternativo del soggetto (SAN) deve
corrispondere al nome di dominio completo (FQDN) del ruolo gestore di replica di
Hyper-V fornito per il cluster ricevente.

Capacità di archiviazione adeguata nel sito di replica per la macchina virtuale, inclusi i file
di configurazione, il disco rigido virtuale (VHDX o VHD) e i punti di ripristino aggiuntivi
facoltativi (snapshot).

Un account utente membro del gruppo di sicurezza Hyper-V Administrators in ogni host.
In un dominio di Active Directory è possibile aggiungere utenti o gruppi a questo gruppo
usando Preferenze di Criteri di gruppo. In alternativa, l'account può essere un
amministratore locale in ogni host. Altre informazioni sul gruppo Hyper-V Administrators
sono disponibili nei gruppi di sicurezza di Active Directory.

Replicare una macchina virtuale

È necessario abilitare la replica per ogni macchina virtuale da replicare. È possibile replicare una
macchina virtuale usando le combinazioni seguenti:

Hyper-V Manager in cluster o singoli host.

Gestione cluster di failover solo nei cluster.
PowerShell su cluster o host singoli.
Windows Admin Center : modalità di virtualizzazione solo su singoli host.

Selezionare la scheda pertinente per le istruzioni.

Hyper-V Manager

Per replicare una macchina virtuale usando Hyper-V Manager:

1. Aprire Hyper-V Manager in un dispositivo usato per gestire un host nel cluster
primario o un singolo host primario con la macchina virtuale oppure nell'host stesso
in cui è installato Windows Server con Esperienza desktop.

2. Nel riquadro delle risorse selezionare l'host che contiene la macchina virtuale da
replicare.

3. Fare clic con il pulsante destro del mouse sulla macchina virtuale da replicare e
quindi scegliere Abilita replica. Nella schermata Abilita la replica, se viene
visualizzato Prima di iniziare, selezionare Avanti.
4. Per Specifica server di replica, nella casella Server di replica immettere NetBIOS o
FQDN del server di replica. Se il server di Replica fa parte di un cluster di failover,
immettere il nome del gestore di Replica Hyper-V. Quindi seleziona Avanti. La
connessione al server di replica viene verificata per recuperare le impostazioni di
autenticazione e porta configurate per il server di replica.

5. Esaminare le impostazioni del server di replica. Se si usa l'autenticazione basata su

certificati, selezionare Seleziona certificato, viene richiesto di selezionare il certificato
per l'host primario che soddisfa i requisiti. Se si desidera comprimere i dati trasmessi
in rete, selezionare la casella. Seleziona Avanti.
 

6. Per Scegliere dischi rigidi virtuali di replica, assicurarsi che le caselle di controllo per
i dischi rigidi virtuali da replicare siano selezionate e deselezionare le caselle di
controllo per tutti i dischi rigidi virtuali da escludere dalla replica. Quindi seleziona
Avanti.
 

7. Per Configurare la frequenza di replica, specificare la frequenza di sincronizzazione

delle modifiche dal cluster primario a quello di replica o dagli host da 30 secondi, 5
minuti o 15 minuti. Quindi seleziona Avanti.


8. Per Configura punti di ripristino aggiuntivi, selezionareMantieni solo il punto di
ripristino più recente o Crea punti di ripristino orari aggiuntivi e il numero di punti
di ripristino aggiuntivi che si desidera creare in ore. Quindi seleziona Avanti.

Quando si creano punti di ripristino orari aggiuntivi, è anche possibile selezionare la

casella Frequenza degli snapshot del Volume Shadow Copy Service (VSS) se si
desidera che i punti di ripristino garantiscano coerenza applicativa per le macchine
virtuali che eseguono applicazioni compatibili con VSS.

9. Per Choose Initial Replication (Scegli replica iniziale) selezionare il metodo di replica
iniziale. Vengono visualizzate le dimensioni totali della copia iniziale. Selezionare
un'opzione nell'elenco seguente, quindi selezionare Avanti.

Invia copia iniziale in rete: questo metodo è l'opzione predefinita.

Invia copia iniziale usando supporti esterni: specificare un percorso di cartella
su supporti locali o esterni in cui è possibile archiviare la copia iniziale.
Usare una macchina virtuale esistente nel server di replica come copia
iniziale: ripristinare la macchina virtuale nel server di replica e usarla come base
per la replica, quindi replicare solo le modifiche. È possibile trovare il processo
per importare la copia iniziale nella sezione Inviare una copia iniziale usando
supporti esterni.
 Se si seleziona Invia copia iniziale in rete o Usa una macchina virtuale esistente nel
server di replica come copia iniziale, facoltativamente è possibile specificare se
avviare la replica immediatamente o avviare la replica in un'ora e una data specifica
fino a sette giorni in futuro.

10. Esaminare le informazioni di riepilogo e quindi selezionare Fine.

 

11. Viene visualizzata una finestra di dialogo che indica che la replica è stata abilitata
correttamente.


 12. Per monitorare lo stato di avanzamento della replica iniziale, vedere la sezione
Monitorare lo stato di avanzamento della replica. È possibile modificare le
impostazioni di replica in un secondo momento se è necessario nella sezione Replica
delle impostazioni della macchina virtuale.

Se si sceglie di inviare la copia iniziale usando supporti esterni, vedere la sezione

Inviare una copia iniziale usando supporti esterni per il processo per importare la
copia iniziale. Nel sito di replica viene creata una macchina virtuale segnaposto e lo
stato di integrità della replica è Avviso. Il contenuto della replica per la macchina
virtuale viene archiviato nel supporto esterno in una sottocartella per la macchina
virtuale. Al termine dell'esportazione, espellere in modo sicuro il supporto esterno e
trasferirlo nel server di replica.

） Importante

I comportamenti seguenti si applicano alle macchine virtuali replicate:

Quando si replica una macchina virtuale, le relative schede di rete non sono
connesse a un commutatore virtuale nell'host di replica. Al termine della replica
iniziale, connettere tutte le schede di rete a un commutatore virtuale nell'host di
replica in modo che le macchine virtuali siano pronte per la connessione online se è
necessario eseguire il failover.

Se si apportano modifiche alla configurazione della macchina virtuale, ad esempio

modificando le impostazioni della memoria o del processore o modificando le
schede di rete, tali modifiche non vengono replicate automaticamente nella
macchina virtuale di replica. Se necessario, è necessario aggiornare manualmente la
macchina virtuale di replica. In alternativa, è possibile rimuovere la replica e
riabilitarla per creare una nuova macchina virtuale di replica con la configurazione
aggiornata.

Hyper-V Replica punta a un singolo volume predefinito per la replica di macchine

virtuali. Per evitare problemi di capacità o prestazioni, spostare lo spazio di
archiviazione della macchina virtuale in un volume diverso rispetto al volume
predefinito per la replica.

Se una macchina virtuale esegue un'applicazione che salva i dati tra dischi rigidi
virtuali, è possibile assicurarsi che tutti i dischi rigidi virtuali selezionati per la replica
vengano replicati nello stesso momento. Un esempio di dove questo approccio è
 utile è quando un'applicazione ha un disco rigido virtuale dedicato per i dati
dell'applicazione e un altro disco rigido virtuale dedicato per i file di log applicazioni.
Per usare questa funzionalità, configurare la replica di macchine virtuali usando
PowerShell con il Enable-VMReplication cmdlet e aggiungere il parametro
EnableWriteOrderPreservationAcrossDisks . Per altre informazioni, vedere Enable-

VMReplication.

Inviare una copia iniziale usando supporti esterni

Se si invia la copia iniziale usando supporti esterni, ad esempio un disco rigido o un'unità USB,
il processo crea una macchina virtuale segnaposto nel sito di replica con un checkpoint. Il
processo archivia il contenuto della replica per la macchina virtuale nei supporti esterni in una
sottocartella per la macchina virtuale. La copia iniziale viene trasferita nel server di replica e
viene quindi importata nella macchina virtuale di segnaposto.

È possibile abilitare la replica usando Hyper-V Manager, Gestione cluster di failover, PowerShell
o Windows Admin Center - Modalità di virtualizzazione. Selezionare la scheda pertinente per le
istruzioni.

Hyper-V Manager

Per inviare la copia iniziale usando supporti esterni e importarli usando Hyper-V Manager:

1. Seguire la procedura descritta nella sezione Replicare una macchina virtuale usando
Hyper-V Manager. Il processo crea una macchina virtuale segnaposto nel sito di
replica e imposta lo stato di integrità della replica su Avviso. Il processo archivia il
contenuto della replica per la macchina virtuale nei supporti esterni in una
sottocartella per la macchina virtuale. Al termine dell'esportazione, espellere in modo
sicuro il supporto esterno e trasferirlo nel server di replica.

2. Aprire Hyper-V Manager in un dispositivo usato per gestire l'host di replica o

nell'host di replica in cui è installato Windows Server con Esperienza desktop.

3. Nel riquadro delle risorse selezionare l'host che contiene la macchina virtuale
segnaposto che si sta replicando.

4. Fare clic con il pulsante destro del mouse sulla macchina virtuale segnaposto, quindi
scegliere Importa replica iniziale.

5. Specificare il percorso in cui è archiviata la copia iniziale, quindi selezionare

Completa replica iniziale.
 

6. Il processo applica il checkpoint iniziale alla macchina virtuale segnaposto e modifica

lo stato di integrità della replica su Normale. La replica continua con la frequenza
specificata. Vedere la sezione Monitorare lo stato della replica per monitorare lo stato
di avanzamento della replica continua.

Monitorare lo stato di avanzamento della replica

È possibile monitorare lo stato di avanzamento della replica iniziale e della replica in corso
usando Hyper-V Manager, Gestione cluster di failover, PowerShell o Windows Admin Center -
Modalità di virtualizzazione. Gli stati di integrità della replica sono:

Normale: i cicli di replica vengono completati in base alla pianificazione (RPO met), il
backlog è minimo e non sono presenti errori di replica recenti. Non è richiesta alcuna
azione.

Avviso: la replica funziona ma aumenta il ritardo o il backlog (spesso il carico di rete o

archiviazione temporaneo). Monitorare e indagare se non si risolve rapidamente.

Critico: la replica si blocca o non riesce. L'RPO è a rischio perché le modifiche non
vengono applicate. Analizzare immediatamente, ad esempio controllare la connettività, la
capacità di archiviazione e le prestazioni, l'autenticazione e i certificati e i log eventi.
Riprendere o risincronizzare in base alle esigenze.

Selezionare la scheda pertinente per le istruzioni.

Hyper-V Manager

Per monitorare lo stato di avanzamento della replica tramite Hyper-V Manager:

1. Tornare in Hyper-V Manager, selezionare un host.

2. Nel riquadro centrale aggiungere una colonna per Integrità replica per visualizzare
lo stato di integrità generale della replica per ogni macchina virtuale. Fare clic con il
 pulsante destro del mouse su un'intestazione di colonna, selezionare
Aggiungi/Rimuovi colonne. Nell'elenco Colonne disponibili, selezionare Stato della
replica, quindi selezionare Aggiungi per spostarlo in Colonne visualizzate. Seleziona
OK.

3. Visualizzare le informazioni di replica di riepilogo, ad esempio l'ultima ora di

sincronizzazione e i FQDN degli host primario e replica. Selezionare la macchina
virtuale, quindi nel riquadro inferiore selezionare la scheda Replica .

4. Per visualizzare informazioni più dettagliate sulla replica, fare clic con il pulsante
destro del mouse sulla macchina virtuale e selezionare Replica e quindi Visualizza
integrità replica. Se necessario, è possibile reimpostare le statistiche di replica
selezionando Reimposta statistiche.
 

Configurazione della replica estesa (facoltativa)

È possibile configurare la replica estesa, che consente di replicare una macchina virtuale in una
terza posizione, da un server di replica a un altro server di replica. Questo approccio consente
di soddisfare i requisiti di conformità per i backup fuori sede o di offrire un ulteriore livello di
protezione per i carichi di lavoro.

È possibile abilitare la replica estesa usando Hyper-V Manager, Gestore Cluster di Failover o
PowerShell. Non è possibile usare la modalità di virtualizzazione di Windows Admin Center per
configurare la replica estesa in questo momento.

Selezionare la scheda pertinente per le istruzioni.

Hyper-V Manager

Per configurare la replica estesa tramite Hyper-V Manager:

 1. Aprire Hyper-V Manager in un dispositivo usato per gestire l'host con la macchina
virtuale o nell'host stesso in cui è installato Windows Server con Esperienza desktop.

2. Nel riquadro delle risorse selezionare l'host che contiene la macchina virtuale per cui
si vuole configurare la replica estesa.

3. Fare clic con il pulsante destro del mouse sulla macchina virtuale per cui si vuole
configurare la replica estesa, quindi selezionare Replica>estesa.

4. Il processo per configurare la replica estesa è simile alla replica di una macchina
virtuale nel primo percorso di replica. Seguire il processo nella sezione Replicare una
macchina virtuale con le eccezioni seguenti:

Non è possibile specificare quali dischi rigidi virtuali replicare. I dischi rigidi
virtuali replicati nel primo server di replica vengono usati per la replica estesa.
La frequenza di replica può essere di soli 5 minuti o 15 minuti.
Non è possibile modificare il tipo di autenticazione.

Passo successivo
Dopo aver abilitato la replica per una macchina virtuale, è possibile testare il failover nel server
di replica senza influire sulla replica in corso. Per ulteriori informazioni su come eseguire un
failover di test e su come eseguire il failover durante un'interruzione, vedere Come effettuare il
failover di una macchina virtuale replicata con Hyper-V Replica.

） Nota: L'autore ha creato questo articolo con l’assistenza dell'intelligenza artificiale. Ulteriori informazioni

Last updated on 17/11/2025

Eseguire il failover di una macchina virtuale
replicata con Hyper-V Replica
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Azure Local 2311.2 and later

Dopo aver abilitato Hyper-V Replica e aver replicato una macchina virtuale, è possibile eseguire
operazioni di failover per passare la macchina virtuale all'host o al cluster di replica. Questo
articolo illustra come eseguire diversi tipi di operazioni di failover usando Hyper-V Replica con
Hyper-V Manager, Gestione cluster di failover, PowerShell o Windows Admin Center - Modalità
di virtualizzazione.

Per altre informazioni su Hyper-V Replica o se è necessario abilitare la replica o replicare una
macchina virtuale, vedere gli articoli seguenti:

Panoramica diHyper-V Replica

Abilitare replica Hyper-V in un singolo host
Abilitare Hyper-V Replica su un cluster di failover
Replicare una macchina virtuale con replica Hyper-V

Scenari di failover
Hyper-V Replica supporta i tre scenari di failover seguenti.

Test di failover: crea una macchina virtuale di prova nell'host di replica o nel cluster senza
influire sull'attività di replica in corso. Consente di verificare che la macchina virtuale di
replica funzioni correttamente. Dopo il test, è possibile arrestare il failover di test per
rimuovere la macchina virtuale di test.

Per impostazione predefinita, la macchina virtuale di test viene creata dal punto di
ripristino più recente e non è connessa a una rete. Se sono stati configurati punti di
ripristino aggiuntivi, è possibile scegliere di creare la macchina virtuale di test da uno di
questi punti. È possibile eseguire un solo failover di test in una macchina virtuale alla
volta.

Failover pianificato: usare quando è possibile arrestare normalmente la macchina virtuale

primaria. Aiuta a eseguire una convalida completa del piano di ripristino. Garantisce che
tutte le modifiche vengano replicate nella replica prima del passaggio, con conseguente
perdita di dati pari a zero. Dopo il failover pianificato, è possibile invertire
facoltativamente la replica nell'host o nel cluster primario originale, quindi eseguire il
failback della macchina virtuale nella posizione originale.
 Il failover pianificato non sostituisce la disponibilità elevata, ma consente di mantenere i
carichi di lavoro in esecuzione con tempi di inattività minimi senza perdita di dati. Può
essere utile per eventi come la manutenzione pianificata di un intero sito o un data
center.

Failover non pianificato: usare quando la macchina virtuale primaria non è disponibile a
causa di un errore, ad esempio un'interruzione dell'alimentazione. Consente di passare
alla macchina virtuale di replica usando il punto di ripristino più recente o i punti di
ripristino precedenti, se configurati. Dopo il failover non pianificato, è possibile
completare il processo di failover e, facoltativamente, eseguire di nuovo la replica inversa
nell'host o nel cluster primario originale, quindi eseguire il failback della macchina virtuale
nel percorso originale.

Il failover non pianificato è progettato per scenari di ripristino di emergenza in cui la

macchina virtuale primaria non può essere arrestata normalmente. Potrebbe verificarsi
una perdita di dati, a seconda del punto di ripristino selezionato.

Prerequisiti
Prima di iniziare, assicurarsi di soddisfare i prerequisiti seguenti:

Si dispone di una macchina virtuale da replicare usando Hyper-V Replica.

Lo stato di integrità della replica della macchina virtuale è Normale. Per controllare
l'integrità della replica, vedere Monitorare lo stato di avanzamento della replica.

Un account utente membro del gruppo di sicurezza Hyper-V Administrators in ogni host.
In un dominio di Active Directory è possibile aggiungere utenti o gruppi a questo gruppo
usando Preferenze di Criteri di gruppo. In alternativa, l'account può essere un
amministratore locale in ogni host. Per altre informazioni sul gruppo Hyper-V
Administrators, vedere Gruppi di sicurezza di Active Directory.

Eseguire il failover di una macchina virtuale

È necessario eseguire un'operazione di failover per ogni macchina virtuale. È possibile eseguire
una sola operazione di failover alla volta per una macchina virtuale. È possibile eseguire ogni
operazione di failover usando le combinazioni seguenti:

Hyper-V Manager su cluster o host singoli

Gestione cluster di failover nei cluster
PowerShell in cluster o singoli host
 Windows Admin Center : modalità di virtualizzazione solo su singoli host. È possibile
eseguire il failover solo usando Windows Admin Center - Modalità di virtualizzazione
dall'host primario all'host di replica. Al momento non è possibile eseguire un failover di
test o una replica inversa.

Selezionare la scheda pertinente per le istruzioni.

Hyper-V Manager

Il failover di una macchina virtuale tramite Hyper-V Manager dipende dal tipo di failover
che si vuole eseguire.

Testare il failover usando Hyper-V Manager

Per eseguire un failover di test usando Hyper-V Manager, seguire questa procedura:

1. Aprire Hyper-V Manager in un dispositivo usato per gestire un host nel cluster di
replica o in un singolo host di replica con la macchina virtuale oppure nell'host
stesso in cui è installato Windows Server con Esperienza desktop.

2. Nel riquadro delle risorse selezionare l'host che contiene la macchina virtuale di
replica per cui si vuole eseguire un failover di test.

3. Fare clic con il pulsante destro del mouse sulla macchina virtuale, selezionare Replica,
quindi selezionare Test Failover.

4. Nella schermata del Test del Failover selezionare il punto di ripristino da usare per il
Test del Failover dall'elenco a discesa, quindi selezionare Test del Failover.

5. L'host crea una macchina virtuale duplicata. Il nome della macchina virtuale è il nome
originale della macchina virtuale con - Test accodato. La macchina virtuale duplicata
 non è connessa a una rete per impostazione predefinita. A questo punto, è possibile
avviare la macchina virtuale ed eseguire test necessari per verificare che funzioni
correttamente.

6. Al termine del test, fare clic con il pulsante destro del mouse sulla macchina virtuale
di replica (non sul duplicato di test), selezionare Replica, quindi selezionare Arresta
failover di test. Nella finestra di dialogo di conferma selezionare Arresta failover di
test per eliminare la macchina virtuale di test e rimuovere i dati.

Failover pianificato tramite gestore di Hyper-V

Per eseguire un failover pianificato usando Hyper-V Manager:

1. Aprire Hyper-V Manager in un dispositivo usato per gestire un host nel cluster
primario o un singolo host primario con la macchina virtuale oppure nell'host stesso
in cui è installato Windows Server con Esperienza desktop.

2. Nel riquadro delle risorse selezionare l'host che contiene la macchina virtuale per cui
si vuole eseguire un failover pianificato.

3. Spegnere la macchina virtuale se è in esecuzione. È necessario arrestare la macchina

virtuale per eseguire un failover pianificato.

4. Fare clic con il pulsante destro del mouse sulla macchina virtuale, selezionare
Replicazione e quindi Failover Pianificato.

5. Nella schermata Failover pianificato selezionare la casella Inverti la direzione della

replica dopo il failover e, facoltativamente, selezionare la casella Avviare la
macchina virtuale di replica dopo il failover, a seconda dei requisiti. La finestra di
dialogo mostra un elenco dei controlli dei prerequisiti e delle azioni eseguite dal
failover pianificato. Per impostazione predefinita, la macchina virtuale di replica viene
avviata dopo il failover. Non dimenticare di collegare la macchina virtuale a una rete,
se necessario.
 

6. Selezionare Failover per avviare il processo.

A questo punto, il failover è completo. Se è stata selezionata l'opzione per invertire la

direzione della replica, la replica viene riconfigurata automaticamente per replicare le
modifiche all'host o al cluster primario originale. In alternativa, fare clic con il
pulsante destro del mouse sulla macchina virtuale di replica, selezionare Replica
inversa e quindi selezionare Replica inversa per configurare manualmente la replica
nell'host o nel cluster primario originale. Dopo aver configurato la replica inversa,
l'integrità della replica torna a Normal.
 7. Avviare la macchina virtuale se non è già in esecuzione facendo clic con il pulsante
destro del mouse sulla macchina virtuale e quindi scegliendo Avvia. Ricordarsi di
collegare la macchina virtuale a una rete, se necessario.

Failover non pianificato con Hyper-V Manager

Per eseguire un failover non pianificato usando Hyper-V Manager:

1. Aprire Hyper-V Manager in un dispositivo usato per gestire un host nel cluster di
replica o in un singolo host di replica con la macchina virtuale oppure nell'host
stesso in cui è installato Windows Server con Esperienza desktop.

2. Nel riquadro delle risorse selezionare l'host che contiene la macchina virtuale di
replica per cui si vuole eseguire un failover non pianificato.

3. Fare clic con il pulsante destro del mouse sulla macchina virtuale di replica,
selezionare Replica e quindi failover.

4. Nella schermata Failover selezionare il punto di ripristino da usare per il failover

dall'elenco a discesa, quindi selezionare Failover.

5. Il processo crea un checkpoint per la macchina virtuale di replica e quindi avvia la

macchina virtuale. Dovresti eseguire i test necessari per verificare che il punto di
ripristino scelto funzioni correttamente. Non dimenticare di collegare la macchina
virtuale a una rete, se necessario.

Se è necessario selezionare un punto di ripristino diverso, è possibile annullare il

failover facendo clic con il pulsante destro del mouse sulla macchina virtuale di
 replica, selezionare Replica, quindi scegliere Annulla failover. È quindi possibile
scegliere un punto di ripristino diverso.

6. Dopo aver testato la macchina virtuale, se non hai bisogno di ripristinare un punto di
recupero diverso, devi completare il failover. Fare clic con il pulsante destro del
mouse sulla macchina virtuale di replica, selezionare Replica e quindi Rimuovi punti
di ripristino. Questa azione rimuove i punti di ripristino e unisce il checkpoint, il che
significa che non è possibile ripristinare un punto di ripristino precedente. Se si
vogliono mantenere punti di ripristino aggiuntivi, è possibile esportare la macchina
virtuale di replica prima di completare il failover.

A questo punto il failover è stato completato, ma lo stato di salute della replica viene
visualizzato come Avviso perché tale direzione di replica non è configurata.

Replica inversa dopo il failover non pianificato tramite Hyper-V

Manager
Quando la macchina virtuale primaria è nuovamente disponibile, è necessario replicare le
modifiche apportate alla macchina virtuale di replica nella macchina virtuale primaria
originale. Il processo è denominato Replica inversa. Prima di poter invertire la replica, è
necessario contrassegnare la macchina virtuale primaria originale come destinazione per
ricevere la replica. Non è possibile eseguire questa azione in Hyper-V Manager.

1. Nell'host primario originale che contiene la macchina virtuale primaria originale

aprire una sessione di PowerShell come amministratore o connettersi in remoto
usando il cmdlet Enter-PSSession in un dispositivo usato per gestire l'host.

2. Contrassegnare la macchina virtuale primaria originale come destinazione per

ricevere la replica eseguendo il comando seguente. Assicurarsi di sostituire il
segnaposto <VMName> con il nome della macchina virtuale primaria originale.
 PowerShell
Set-VMReplication -VMName '<VM Name>' -AsReplica

3. Controllare lo stato della macchina virtuale primaria originale eseguendo il comando

seguente nell'host primario:

PowerShell
Get-VMReplication -VMName '<VM Name>' | FL VMName, ReplicationMode,
ReplicationState

Di seguito è riportato un esempio dell'output, che mostra che la macchina virtuale

primaria è ora configurata come replica ed è in attesa di replica:

Output
VMName : contoso-vm-01
ReplicationMode : Replica
ReplicationState : WaitingForInitialReplication

4. Nell'host di replica che contiene la VM di replica, in Hyper-V Manager fare clic con il
pulsante destro del mouse sulla VM di replica, selezionare Replica e quindi Replica
inversa. Nella schermata Replica inversa , se viene visualizzato Prima di iniziare,
selezionare Avanti.

5. Le opzioni della procedura guidata vengono precompilate in base alle impostazioni

della macchina virtuale primaria originale. Se non è necessario modificare le
impostazioni, selezionare Avanti in ogni schermata finché non si raggiunge la
schermata Riepilogo , quindi selezionare Fine per avviare la replica inversa. In
alternativa, le opzioni sono identiche a quando è stata inizialmente abilitata la replica
per la macchina virtuale.
 

A questo punto, tutte le modifiche vengono replicate e l'integrità della replica torna a
Normal. I ruoli primario e di replica sono stati scambiati. Per tornare alla direzione di
replica originale, è possibile eseguire un failover pianificato, come descritto nella
sezione Failover pianificato .

） Nota: L'autore ha creato questo articolo con l’assistenza dell'intelligenza artificiale. Ulteriori informazioni

Last updated on 17/11/2025

Configurare più csv per la replica di
macchine virtuali
16/08/2025Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Azure Local 2311.2 and later

Quando si configura la replica di macchine virtuali, è possibile che si verifichi una limitazione
per cui è possibile specificare soltanto un singolo percorso per i Volumi Condivisi di Cluster
(CSV). Questa guida illustra come superare questa limitazione per configurare più CSV per la
replica di VM. Questo approccio offre un maggiore controllo sulla macchina virtuale
migliorando la flessibilità e l'efficienza di archiviazione delle risorse.

Prerequisites
Prima di procedere, è necessario quanto segue nel dispositivo:

È necessario installare il ruolo Hyper-V . Per altre informazioni, vedere Installare il ruolo
Hyper-V su Windows Server.
La replica di macchine virtuali è abilitata e vengono configurate le regole del firewall in
ingresso. Per informazioni aggiuntive, vedere Configura Hyper-V Replica.
Spazio su disco sufficiente per la corretta migrazione dell'archiviazione.

７ Nota

Durante il processo di replica, l'hardware e la rete usati influiscono sui servizi che si basano
su di essi. A seconda della quantità di dati replicati tra i sistemi di origine e di
destinazione, questo processo utilizza una grande quantità di risorse di sistema. Le
prestazioni del tuo dispositivo sono influenzate fino al completamento di questo
processo.

Configurare più percorsi CSV

Quando si copiano macchine virtuali tramite un processo di replica, è possibile usare più
volumi di archiviazione per archiviare i dati replicati. Esistono due metodi per configurare nuovi
percorsi di replica, tramite l'interfaccia utente di Hyper-V Manager o tramite PowerShell.

Hyper-V

1. Aprire Hyper-V Manager, in Azioni selezionare Hyper-V Impostazioni.

 2. Sotto autorizzazione e archiviazione, selezionare Consenti replica da qualsiasi
server autenticato o Consenti replica dai server specificati, quindi selezionare
Sfoglia.
3. Nella finestra Seleziona cartella scegliere un nuovo percorso predefinito e quindi
selezionare Seleziona cartella.

Quando vengono apportate modifiche al "percorso predefinito" in cui la replica è abilitata

per una macchina virtuale, il nuovo volume di destinazione viene usato per qualsiasi nuova
abilitazione della replica successiva. Tuttavia, le macchine virtuali già replicate continuano
a usare il volume di destinazione originale configurato quando la replica è stata abilitata
per la prima volta.
Abilitare l’hardware di monitoraggio delle
prestazioni Intel in una macchina virtuale
Hyper-V
16/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

I processori Intel contengono funzionalità denominate collettivamente hardware di

monitoraggio delle prestazioni (ad esempio PMU, PEBS, LBR). Queste funzionalità vengono
usate da software di ottimizzazione delle prestazioni come Intel VTune Amplifier per analizzare
le prestazioni del software. Prima di Windows Server 2019 e Windows 10 versione 1809, né il
sistema operativo host né le macchine virtuali guest Hyper-V potevano usare l'hardware di
monitoraggio delle prestazioni quando Hyper-V era abilitato. A partire da Windows Server
2019 e Windows 10 versione 1809, il sistema operativo host ha accesso all'hardware di
monitoraggio delle prestazioni per impostazione predefinita. Le macchine virtuali guest Hyper-
V non dispongono dell'accesso per impostazione predefinita, ma gli amministratori di Hyper-V
possono scegliere di concedere l'accesso a una o più macchine virtuali guest. Questo
documento illustra i passaggi necessari per esporre l'hardware di monitoraggio delle
prestazioni alle macchine virtuali guest.

Requirements
Per abilitare l'hardware di monitoraggio delle prestazioni in una macchina virtuale, è
necessario:

Un processore Intel con hardware di monitoraggio delle prestazioni (ad esempio PMU,
PEBS, LBR). Fare riferimento a questo documento da Intel per determinare l'hardware di
monitoraggio delle prestazioni supportato dal sistema.
Windows Server 2019 o Windows 10 versione 1809 (aggiornamento di ottobre 2018) o
versione successiva
Una macchina virtuale Hyper-V senzavirtualizzazione annidata che si trova anche nello
stato arrestato

Per abilitare l'imminente hardware di monitoraggio delle prestazioni Intel Processor Trace (IPT)
in una macchina virtuale, è necessario:

Un processore Intel che supporta IPT e la funzionalità PT2GPA. [^1] Fare riferimento a
questo documento da Intel per determinare l'hardware di monitoraggio delle
prestazioni supportato dal sistema.
 Windows Server versione 1903 (SAC) o Windows 10 versione 1903 (aggiornamento di
maggio 2019) o versione successiva
Una macchina virtuale Hyper-V senzavirtualizzazione annidata che si trova anche nello
stato arrestato
È necessario abilitare PMU tramite la riga di comando usando il comando riportato di
seguito.

[^1]: PT2GPA fa riferimento al bit "Intel PT usa indirizzi fisici guest". Questo viene descritto nella
versione [Link] di Intel SDM.

Abilitazione dei componenti di monitoraggio delle

prestazioni in una macchina virtuale
Per abilitare diversi componenti di monitoraggio delle prestazioni per una macchina virtuale
guest specifica, utilizzare il cmdlet Set-VMProcessor di PowerShell durante l'esecuzione come
amministratore:

７ Nota

La generazione della macchina virtuale deve essere 9.1 o successiva. Se la virtualizzazione

annidata viene offerta anche al guest, è necessaria la versione 9.3 e versioni successive.

Powershell

# Enable IPT
Set-VMProcessor MyVMName -Perfmon @("ipt", "pmu")

Powershell

# Enable all components

Set-VMProcessor MyVMName -Perfmon @("ipt", "pmu", "lbr", "pebs")

Powershell

# Disable all components

Set-VMProcessor MyVMName -Perfmon @()

７ Nota
 Quando si abilitano i componenti di monitoraggio delle prestazioni, se "pebs" viene
specificato, è poi necessario specificare anche "pmu" .
PEBS è supportato solo su hardware con versione PMU >= 4.
Inoltre, qualsiasi comando che tenta di abilitare "ipt" deve specificare anche "pmu" .

L'abilitazione di un componente non supportato dai processori fisici dell'host genererà un

errore di avvio della macchina virtuale.

Effetti dell'abilitazione dell'hardware di

monitoraggio delle prestazioni in caso di
salvataggio/ripristino, esportazione e migrazione
in tempo reale
Microsoft non consiglia la migrazione in tempo reale o il salvataggio/ripristino di macchine
virtuali con hardware di monitoraggio delle prestazioni tra sistemi con hardware Intel diverso. Il
comportamento specifico dell'hardware di monitoraggio delle prestazioni è spesso non
architettonico e cambia tra i sistemi hardware Intel. Lo spostamento di una macchina virtuale in
esecuzione tra sistemi diversi può causare un comportamento imprevedibile dei contatori non
architettonici.
Compatibilità del processore per le
macchine virtuali Hyper-V
14/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Hyper-V modalità di compatibilità del processore consente la migrazione delle macchine

virtuali tra host con diverse funzionalità del processore. Un host Hyper-V passa attraverso le
funzionalità del processore alle macchine virtuali in esecuzione, consentendo al sistema
operativo guest e alle applicazioni di sfruttare le stesse funzionalità del processore dell'host.

In alcuni casi potrebbe essere necessario limitare le funzionalità del processore passate, ad
esempio quando si vuole spostare una macchina virtuale in tempo reale o una macchina
virtuale salvata tra host o cluster con diverse funzionalità del processore o sviluppare
applicazioni che devono essere eseguite su un'ampia gamma di hardware. In questi casi, è
possibile usare la modalità di compatibilità del processore. È consigliabile abilitare la modalità
di compatibilità del processore solo durante il processo di migrazione e quindi disabilitarla per
consentire alla macchina virtuale di sfruttare le funzionalità complete del processore dell'host.

La modalità di compatibilità del processore fornisce una macchina virtuale con un set comune
di funzionalità del processore. Esistono due modalità di compatibilità del processore:

Modalità di compatibilità del processore dinamico: per Hyper-V host in un cluster,

calcola in modo dinamico il set comune di funzionalità del processore in tutti i nodi,
consentendo alle macchine virtuali di sfruttare le funzionalità massime disponibili nel
cluster. La modalità di compatibilità del processore dinamico è stata introdotta in
Windows Server 2025.

Modalità di compatibilità del processore standard: usa un set fisso di funzionalità del
processore, indipendentemente dalle funzionalità dell'host o del cluster.

Questo articolo descrive la modalità di compatibilità del processore, perché è utile e come
funziona.

Perché la compatibilità del processore è utile

I produttori di processori spesso introducono ottimizzazioni e funzionalità nei loro processori.
Queste funzionalità spesso migliorano le prestazioni o la sicurezza usando hardware
specializzato per un'attività specifica. Ad esempio, molte applicazioni multimediali usano
funzionalità del processore per velocizzare i calcoli vettoriali. Queste funzionalità sono
raramente necessarie per l'esecuzione delle applicazioni; aumentano le prestazioni.
Il set di funzionalità disponibile in un processore varia a seconda della sua creazione, modello e
età. I sistemi operativi e il software dell'applicazione enumerano in genere la funzionalità del
processore del sistema impostata al primo avvio. Il software non prevede che le funzionalità del
processore disponibili in un dispositivo cambino durante la sua durata.

Tuttavia, le funzionalità di mobilità delle macchine virtuali consentono di eseguire la

migrazione di una macchina virtuale in esecuzione a un nuovo host di virtualizzazione. Se il
software nella macchina virtuale rileva e avvia l'uso di una particolare funzionalità del
processore e la macchina virtuale viene spostata in un nuovo host di virtualizzazione senza tale
funzionalità, il software può non riuscire. Diverse funzionalità del processore possono causare
l'arresto anomalo dell'applicazione o della macchina virtuale.

Per evitare errori, Hyper-V esegue controlli iniziali ogni volta che viene avviata una migrazione
in tempo reale di una macchina virtuale o un'operazione di salvataggio/ripristino. Questi
controlli confrontano il set di funzionalità del processore disponibili per la macchina virtuale
nell'host di origine con il set di funzionalità disponibili nell'host di destinazione. Se questi set di
funzionalità non corrispondono, l'operazione di migrazione o ripristino viene annullata.

Non è necessario abilitare la modalità di compatibilità del processore se si prevede di arrestare

e riavviare le macchine virtuali, perché il sistema operativo guest enumera le funzionalità del
processore disponibili nel nuovo host al riavvio della macchina virtuale.

Funzionamento della modalità di compatibilità del

processore
La modalità di compatibilità del processore non è abilitata per impostazione predefinita. È
necessario abilitarlo in modo esplicito per ogni macchina virtuale con cui si vuole usarla.

Quando si abilita la modalità di compatibilità del processore in una macchina virtuale,

garantisce che il set di funzionalità del processore disponibili in un set diverso di host di
virtualizzazione corrisponda presentando solo un set limitato di funzionalità del processore alla
macchina virtuale. La modalità di compatibilità del processore nasconde i set di istruzioni del
processore più recenti, in genere i processori introdotti negli ultimi 10 anni. Tuttavia,
nascondere queste funzionalità significa che il sistema operativo guest e il software
dell'applicazione non possono sfruttare questi miglioramenti del set di istruzioni del
processore.
La modalità di compatibilità del processore dinamico, introdotta in Windows Server 2025 per le
macchine virtuali che usano la versione di configurazione 10.0 o successiva, migliora la versione
precedente della modalità di compatibilità del processore consentendo alle macchine virtuali di
usare un set calcolato dinamicamente di funzionalità del processore comuni in tutti i nodi di un
cluster. Ciò significa che le macchine virtuali possono sfruttare le funzionalità massime
disponibili nel cluster garantendo al tempo stesso la compatibilità durante lo spostamento di
macchine virtuali tra host.

Ogni macchina virtuale riceve il numero massimo di set di istruzioni del processore presenti in
tutti i server del cluster. Questo processo viene eseguito automaticamente e viene sempre
abilitato e replicato nel cluster, quindi non è disponibile alcun comando per abilitare o
disabilitare il processo.

È difficile quantificare gli effetti generali sulle prestazioni della modalità di compatibilità del
processore. La perdita di prestazioni dipende principalmente dal carico di lavoro in esecuzione
nella macchina virtuale. Alcuni carichi di lavoro potrebbero non essere interessati, mentre altri
mostrano una differenza evidente. Il software che si basa principalmente sulle ottimizzazioni
hardware (ad esempio crittografia, compressione o calcoli a virgola mobile intensivi) ha un
impatto maggiore. Se si è preoccupati per l'impatto sulle prestazioni della modalità di
compatibilità del processore, è consigliabile confrontare le prestazioni del carico di lavoro delle
macchine virtuali con la modalità di compatibilità del processore abilitata e disabilitata.

Anche quando la compatibilità del processore è abilitata, non è possibile spostare macchine
virtuali tra host con produttori di processori diversi. Ad esempio, non è possibile spostare
macchine virtuali in esecuzione o macchine virtuali con stato salvato da un host con processori
Intel a un host con processori AMD.

Passo successivo
Informazioni su come configurare una macchina virtuale per usare la modalità di compatibilità
del processore.

） Nota: L'autore ha creato questo articolo con l’assistenza dell'intelligenza artificiale. Ulteriori informazioni
Configurare la modalità di compatibilità del
processore nelle macchine virtuali Hyper-V
15/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

La modalità di compatibilità del processore abilita la migrazione delle macchine virtuali tra host
con diverse funzionalità del processore. Limita le funzionalità del processore disponibili a una
macchina virtuale per garantire la compatibilità quando si spostano macchine virtuali tra host o
cluster con processori diversi.

In alcuni casi potrebbe essere necessario limitare le funzionalità del processore passate, ad
esempio quando si vuole spostare una macchina virtuale in tempo reale o una macchina
virtuale salvata tra host o cluster con diverse funzionalità del processore o sviluppare
applicazioni che devono essere eseguite su un'ampia gamma di hardware. In questi casi, è
possibile usare la modalità di compatibilità del processore. È consigliabile abilitare la modalità
di compatibilità del processore solo durante il processo di migrazione e quindi disabilitarla per
consentire alla macchina virtuale di sfruttare le funzionalità complete del processore dell'host.
Se si dispone di un cluster con generazioni di processori diverse, è necessario lasciare abilitata
la modalità di compatibilità del processore per il funzionamento della migrazione in tempo
reale.

La modalità di compatibilità del processore dinamico, introdotta in Windows Server 2025 per le
macchine virtuali che usano la versione di configurazione 10.0 o successiva, migliora la versione
precedente della modalità di compatibilità del processore consentendo alle macchine virtuali di
usare un set calcolato dinamicamente di funzionalità del processore comuni in tutti i nodi di un
cluster. Ciò significa che le macchine virtuali possono sfruttare le funzionalità massime
disponibili nel cluster garantendo al tempo stesso la compatibilità durante lo spostamento di
macchine virtuali tra host.

Per informazioni sulla modalità di compatibilità del processore, vedere Compatibilità del
processore in Hyper-V macchine virtuali.

Questo articolo illustra come configurare la modalità di compatibilità del processore per una
macchina virtuale usando Hyper-V Manager, PowerShell o Windows Admin Center.

Prerequisiti
Prima di iniziare, assicurarsi di soddisfare i prerequisiti seguenti:
 Si ha accesso amministrativo all'host o al cluster Hyper-V in cui è in esecuzione la
macchina virtuale e in cui si vuole eseguirne la migrazione.

La macchina virtuale che si vuole configurare la modalità di compatibilità del processore è

spenta. La modalità di compatibilità del processore non può essere abilitata o disabilitata
durante l'esecuzione della macchina virtuale.

La modalità di compatibilità del processore dinamico è stata introdotta per le macchine

virtuali in un host Hyper-V che esegue Windows Server 2025 o Azure Local (in precedenza
Azure Stack HCI) versione 21H2 e usare la versione di configurazione 10.0 o successiva. Se
la macchina virtuale usa una versione di configurazione precedente, aggiornarne la
versione di configurazione; in caso contrario, usa la modalità di compatibilità del
processore standard.

Configurare una macchina virtuale per l'uso della

modalità di compatibilità del processore
Questa sezione illustra come configurare una macchina virtuale per l'uso della modalità di
compatibilità del processore usando Hyper-V manager, PowerShell o Windows Admin Center. È
possibile eseguire macchine virtuali con e senza modalità di compatibilità nello stesso cluster.
Le due modalità di compatibilità del processore sono abilitate e disabilitate allo stesso modo.
La modalità di compatibilità del processore dinamico è trasparente per l'utente e viene abilitata
quando la macchina virtuale è in esecuzione in un cluster.

Selezionare la scheda pertinente per il metodo da usare.

Hyper-V manager

Per abilitare o disabilitare la modalità di compatibilità del processore per una macchina
virtuale usando Hyper-V Manager, seguire questa procedura. Non è possibile configurare
la modalità di compatibilità del processore dinamico in Hyper-V Manager; usare invece
PowerShell o Windows Admin Center.

1. Aprire Hyper-V Manager.

2. Selezionare il server che esegue Hyper-V e la macchina virtuale desiderata.

3. Se la macchina virtuale è in esecuzione, è necessario arrestare la macchina virtuale

per modificare l'impostazione della modalità di compatibilità del processore.

4. Nel riquadro Azioni per la macchina virtuale selezionare Impostazioni.

 5. Nel riquadro Hardware selezionare Processore. Espandere Processore, quindi
selezionare Compatibilità.

6. Per abilitare la modalità di compatibilità del processore, selezionare la casella Esegui

la migrazione a un computer fisico con un processore diverso. Per disabilitarla,
deselezionare la casella.

7. Selezionare OK per salvare la modifica, quindi avviare la macchina virtuale.

Verificare le funzionalità del processore in un host

Hyper-V e in una macchina virtuale
Dopo aver configurato la modalità di compatibilità del processore, è possibile verificare le
funzionalità del processore disponibili in un host Hyper-V e nella macchina virtuale. Queste
informazioni possono essere utili se si vuole verificare che la macchina virtuale disponga del set
previsto di funzionalità disponibili.
Per controllare le funzionalità del processore in un host Hyper-V e in una macchina virtuale
Windows, è possibile eseguire Coreinfo da Sysinternals:

1. Accedere all'host o alla macchina virtuale e scaricare ed estrarre lo strumento Coreinfo.

2. Aprire PowerShell come amministratore e passare alla directory in cui è stato estratto
Coreinfo.

3. Esegui il comando seguente: Se è la prima volta che si esegue Coreinfo in questo host, è
necessario accettare il contratto di licenza.

PowerShell

.\[Link] -f

Di seguito è riportato un esempio troncato dell'output, in cui ogni riga rappresenta una
funzionalità del processore e un asterisco (*) indica che la funzionalità è disponibile:

Output

HTT * Hyperthreading enabled

CET - Supports Control Flow Enforcement Technology
Kernel CET - Kernel-mode CET Enabled
User CET - User-mode CET Allowed
HYPERVISOR * Hypervisor is present
VMX - Supports Intel hardware-assisted virtualization
SVM - Supports AMD hardware-assisted virtualization
X64 * Supports 64-bit mode

SMX - Supports Intel trusted execution

SKINIT - Supports AMD SKINIT
SGX - Supports Intel SGX

...

Quando la modalità di compatibilità del processore è abilitata, si noterà che alcune funzionalità
non sono disponibili (indicate da un trattino - ) rispetto all'output dell'host. Un elenco ridotto
indica che la macchina virtuale è in esecuzione in modalità di compatibilità del processore ed è
limitata a un set comune di funzionalità.

Se si usa la modalità di compatibilità del processore dinamico, le funzionalità disponibili nella

macchina virtuale sono il set massimo di funzionalità comuni in tutti i nodi del cluster.

Macchine virtuali di Linux

Ecco un esempio di come controllare le funzionalità del processore in una macchina virtuale
Linux basata su Debian o Red Hat:

1. Accedere alla macchina virtuale e aprire un terminale.

2. Eseguire il comando seguente per elencare le funzionalità del processore:

Bash

lscpu | grep Flags

Ecco un esempio troncato dell'output che potrebbe essere visualizzato:

Output

Flags: fpu vme de pse tsc msr pae mce cx8 apic sep
mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm
constant_tsc rep_good nopl
xtopology aperfmperf pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic
movbe popcnt
tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm
3dnowprefetch invpcid_single
ssbd ibrs ibpb stibp ibrs_enhanced kaiser fsgsbase tsc_adjust bmi1 avx2 smep
bmi2 erms invpcid
avx512f avx512dq rdseed adx smap clflushopt avx512cd sha_ni avx512bw avx512vl
xsaveopt xsavec
xgetbv1 xsaves rdpid md_clear flush_l1d arch_capabilities

Quando la modalità di compatibilità del processore è abilitata, si noterà che alcune funzionalità
non sono elencate rispetto all'output dell'host. Un elenco ridotto indica che la macchina
virtuale è in esecuzione in modalità di compatibilità del processore ed è limitata a un set
comune di funzionalità.

Se si usa la modalità di compatibilità del processore dinamico, le funzionalità disponibili nella

macchina virtuale sono il set massimo di funzionalità comuni in tutti i nodi del cluster.

Comportamento della migrazione in tempo reale

delle macchine virtuali tra cluster separati
Supponendo che tutti i server in ogni cluster eseguano lo stesso hardware, è possibile eseguire
la migrazione in tempo reale delle macchine virtuali in esecuzione tra cluster. Esistono tre
scenari comuni.
 Migrazione in tempo reale di una macchina virtuale da un cluster con nuovi processori
a un cluster con gli stessi processori. Le funzionalità della macchina virtuale vengono
trasferite al cluster di destinazione. Questo scenario non richiede l'abilitazione della
modalità di compatibilità del processore; Tuttavia, lasciare abilitato non dovrebbe causare
problemi di migrazione.

Migrazione in tempo reale di una macchina virtuale da un cluster con processori meno
recenti a un cluster con processori più recenti. Le funzionalità della macchina virtuale
vengono trasferite al cluster di destinazione. In questo scenario, quando la macchina
virtuale viene riavviata, riceve la funzionalità calcolata più recente del cluster di
destinazione.

Migrazione in tempo reale di una macchina virtuale da un cluster con processori più
recenti a un cluster con processori meno recenti. È necessario impostare il processore di
macchine virtuali per usare MinimumFeatureSet per il CompatibilityForMigrationMode
parametro in PowerShell oppure selezionare Compatibile tra altri host con lo stesso
produttore della CPU in Windows Admin Center. Dopo il riavvio della macchina virtuale,
riceve la funzionalità calcolata più recente del cluster di destinazione.

） Nota: L'autore ha creato questo articolo con l’assistenza dell'intelligenza artificiale. Ulteriori informazioni
Panoramica di Live Migration
16/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Azure Local 2311.2 and later

La migrazione in tempo reale è una funzionalità di Hyper-V in Windows Server. Consente di

spostare in modo trasparente le macchine virtuali in esecuzione da un host Hyper-V a un altro
senza tempi di inattività percepiti. Il vantaggio principale della migrazione in tempo reale è la
flessibilità; Le macchine virtuali in esecuzione non sono associate a un singolo computer host.
In questo modo è possibile eseguire azioni come svuotare un host specifico di macchine
virtuali prima di rimuoverlo o aggiornarlo. Se abbinato a Windows Failover Clustering, la
migrazione in tempo reale consente la creazione di sistemi a disponibilità elevata e a tolleranza
di errore.

Tecnologie e documentazione correlate

La migrazione in tempo reale viene spesso usata in combinazione con alcune tecnologie
correlate, come Failover Clustering e System Center Virtual Machine Manager. Se si utilizza Live
Migration tramite queste tecnologie, ecco alcune indicazioni alla documentazione più recente.

Clustering di failover (Windows Server 2016)

System Center Virtual Machine Manager (System Center 2016)

Se si usano versioni precedenti di Windows Server o sono necessari dettagli sulle funzionalità
introdotte nelle versioni precedenti di Windows Server, ecco i puntatori alla documentazione
cronologica:

Live Migration (Windows Server 2008 R2)

Live Migration (Windows Server 2012 R2)
Clustering di failover (Windows Server 2012 R2)
Clustering di failover (Windows Server 2008 R2)
System Center Virtual Machine Manager (System Center 2012 R2)
System Center Virtual Machine Manager (System Center 2008 R2)

Migrazione in tempo reale in Windows Server 2016

In Windows Server 2016 esistono meno restrizioni per la distribuzione della migrazione in
tempo reale. Ora funziona senza Clustering di failover. Altre funzionalità rimangono invariate
rispetto alle versioni precedenti di Live Migration. Per ulteriori dettagli su come configurare e
utilizzare la migrazione in tempo reale senza Failover Clustering:
Configurare gli host per la migrazione live senza cluster di failover
Usare la migrazione live senza failover clustering per spostare una macchina virtuale
Configurare gli host per live migration
senza Clustering di Failover
16/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Azure Local 2311.2 and later

La migrazione in tempo reale consente di spostare le macchine virtuali in esecuzione tra server
con tempi di inattività minimi. Questo articolo illustra come configurare gli host non cluster per
la migrazione in tempo reale in Hyper-V, incluse le opzioni di autenticazione, la configurazione
di rete e le procedure consigliate per la sicurezza. Usare questi passaggi se non è stata
configurata la migrazione in tempo reale durante l'installazione di Hyper-V o se è necessario
aggiornare le impostazioni.

Requisiti per configurare la funzionalità live

migration
Per configurare host non cluster per la migrazione in tempo reale, è necessario:

L'appartenenza al gruppo Administrators locale Hyper-V o al gruppo Administrators nei

computer di origine e di destinazione soddisfa questo requisito, a meno che non si stia
configurando la delega vincolata. Per configurare la delega vincolata, è necessaria
l'appartenenza al gruppo Domain Administrators.

Ruolo Hyper-V in Windows Server installato nei server di origine e di destinazione. È

possibile eseguire una migrazione in tempo reale tra host che eseguono Windows Server
2012 R2 e versioni successive. Per istruzioni sull'installazione, vedere Installare il ruolo
Hyper-V in Windows Server.

Computer di origine e di destinazione che appartengono allo stesso dominio di Active

Directory o ai domini che si considerano attendibili tra loro.

Gli strumenti di gestione Hyper-V installati in un computer che esegue almeno Windows
Server 2016 o Windows 10, a meno che gli strumenti non siano installati nel server di
origine o di destinazione ed eseguano gli strumenti dal server.

Prendere in considerazione le opzioni per

l'autenticazione e di rete
Decidere come configurare le opzioni di autenticazione, prestazioni e rete.
 Autenticazione: quale protocollo si usa per autenticare il traffico di migrazione in tempo
reale tra il server di origine e quello di destinazione? Il protocollo scelto determina se è
necessario accedere al server di origine prima di avviare una migrazione in tempo reale:

Kerberos consente di evitare l'accesso al server, ma richiede di configurare la delega

vincolata. Per istruzioni, vedere i dettagli seguenti.

CredSSP consente di evitare di configurare la delega vincolata, ma richiede l'accesso al

server di origine. È possibile farlo tramite una sessione di console locale, una sessione
Desktop remoto o una sessione remota di Windows PowerShell.

CredSSP richiede di accedere per le situazioni che non sono sempre ovvie. Ad esempio,
se si accede a TestServer01 per spostare una macchina virtuale in TestServer02 e quindi
si vuole spostare di nuovo la macchina virtuale in TestServer01, è necessario accedere a
TestServer02 prima di provare a spostare nuovamente la macchina virtuale in
TestServer01. In caso contrario, il tentativo di autenticazione non riesce, si verifica un
errore e viene visualizzato il messaggio seguente:

"Operazione di migrazione di macchina virtuale non riuscita all'origine della

migrazione. Impossibile stabilire una connessione con il nome del computer host:
nessuna credenziale è disponibile nel pacchetto di sicurezza 0x8009030E."

Prestazioni: è necessario configurare le opzioni di prestazioni? Queste opzioni possono

ridurre l'utilizzo della rete e della CPU e velocizzare le migrazioni in tempo reale.
Controllare i requisiti e l'infrastruttura e testare configurazioni diverse per decidere. Le
opzioni sono descritte alla fine del passaggio 2.

Preferenze di rete: si consente il traffico di migrazione in tempo reale attraverso una rete
disponibile o si isola il traffico verso reti specifiche? Come procedura consigliata per la
sicurezza, isolare il traffico su reti private attendibili perché il traffico di migrazione in
tempo reale non viene crittografato quando inviato in rete. È possibile isolare la rete
usando una rete fisicamente isolata o un'altra tecnologia di rete attendibile, ad esempio
VLAN.

Aggiornamento a Windows Server 2025

A partire da Windows Server 2025, Credential Guard è abilitato per impostazione predefinita in
tutti i server aggiunti a un dominio che non sono controller di dominio. Per questo motivo, non
è possibile usare la migrazione in tempo reale basata su CredSSP con Hyper-V dopo
l'aggiornamento a Windows Server 2025. La delega basata su CredSSP è l'impostazione
predefinita per Windows Server 2022 e versioni precedenti per la migrazione in tempo reale.
Usare invece la delega vincolata Kerberos, come descritto nella sezione seguente. Per altre
informazioni, vedere Live Migration with Hyper-V break when upgrade to Windows Server
2025 (Migrazione in tempo reale con interruzioni di Hyper-V durante l'aggiornamento a
Windows Server 2025).

Passaggio 1: Configurare (facoltativa) per la delega

vincolata
Se si decide di usare Kerberos per autenticare il traffico di migrazione in tempo reale,
configurare la delega vincolata usando un account membro del gruppo Domain
Administrators.

Usare lo snap-in Utenti e computer per configurare la delega

vincolata
1. Aprire lo snap-in Utenti e computer di Active Directory. In Server Manager selezionare il
server, quindi selezionare Strumenti>Utenti e computer di Active Directory.

2. Nel riquadro di spostamento in Utenti e computer di Active Directory selezionare il

dominio e quindi fare doppio clic sulla cartella Computer .

3. Nella cartella Computer fare clic con il pulsante destro del mouse sull'account computer
del server di origine e quindi scegliere Proprietà.

4. In Proprietà selezionare la scheda Delega .

5. Nella scheda Delega selezionare Considera attendibile il computer per la delega solo ai
servizi specificati e quindi selezionare Usa qualsiasi protocollo di autenticazione.

6. Seleziona Aggiungi.

7. In Aggiungi servizi selezionare Utenti o computer.

8. Da Seleziona utenti o computer, digitare il nome del server di destinazione. Selezionare

Controlla nomi per verificarlo e quindi selezionare OK.

9. In Aggiungi servizi, nell'elenco dei servizi disponibili, eseguire le operazioni seguenti e

quindi selezionare OK:

Per spostare l'archiviazione delle macchine virtuali, selezionare cifs. Questa

operazione è necessaria se si vuole spostare lo spazio di archiviazione insieme alla
macchina virtuale e se si vuole spostare solo lo spazio di archiviazione di una
macchina virtuale. Se il server è configurato per l'utilizzo dello spazio di
archiviazione SMB per Hyper-V, questa opzione è già selezionata.
 Per spostare macchine virtuali, selezionare Servizio di migrazione sistema virtuale.

10. Nella scheda Delega della finestra di dialogo Proprietà selezionare che i servizi selezionati
nel passaggio precedente siano elencati come servizi a cui il computer di destinazione
può presentare credenziali delegate. Seleziona OK.

11. Nella cartella Computer selezionare l'account computer del server di destinazione e
ripetere il processo. Nella finestra di dialogo Seleziona utenti o computer assicurarsi di
specificare il nome del server di origine.

Le modifiche alla configurazione diventano effettive dopo:

Le modifiche vengono replicate nei controller di dominio a cui vengono connessi i server
che eseguono Hyper-V.
Il controller di dominio rilascia un nuovo ticket Kerberos.

Passaggio 2: Configurare i computer di origine e

destinazione per live migration
Questo passaggio illustra le opzioni per l'autenticazione e la rete. Per una maggiore sicurezza,
selezionare reti specifiche per il traffico di migrazione in tempo reale, come illustrato in
precedenza. In questo passaggio si sceglie anche un'opzione per le prestazioni.

Gestione di Hyper-V consente di configurare i computer di

origine e destinazione per live migration
1. Aprire la console di gestione di Hyper-V. In Server Manager selezionare
Strumenti>Hyper-V Manager.

2. Nel riquadro di spostamento selezionare un server. Se non è elencato, fare clic con il
pulsante destro del mouse su Hyper-V Manager, scegliere Connetti al server, immettere
il nome del server e scegliere OK. Ripetere per aggiungere altri server.

3. Nel riquadro Azione selezionare Hyper-V Impostazioni>migrazioni in tempo reale.

4. Nel riquadro Migrazioni in tempo reale selezionare Abilita migrazioni in tempo reale in
ingresso e in uscita.

5. In Migrazioni in tempo reale simultanee immettere un numero diverso se non si vuole

usare il valore predefinito 2.

6. In Migrazioni in tempo reale in ingresso, se si vogliono usare connessioni di rete

specifiche per accettare il traffico di migrazione in tempo reale, selezionare Aggiungi per
 digitare l'indirizzo IP addr1. Per impostare le opzioni Kerberos e prestazioni, espandere
Migrazioni in tempo reale e selezionare Funzionalità avanzate.

Se si configura la delega vincolata, in Protocollo di autenticazione selezionare

Kerberos.
In Opzioni prestazioni esaminare i dettagli e selezionare un'opzione diversa se si
adatta all'[Link]**, esaminare i dettagli e scegliere un'opzione diversa se è
appropriata per l'ambiente in uso.

7. Seleziona OK.

8. Selezionare l'altro server in Hyper-V Manager e ripetere questi passaggi.

Utilizzare Windows PowerShell per configurare il computer di

origine e destinazione per live migration
È possibile usare tre cmdlet per configurare la migrazione in tempo reale in host non cluster:
Enable-VMMigration, Set-VMMigrationNetwork e Set-VMHost. Questo esempio usa tutti e tre
per:

Configurare la migrazione in tempo reale nell'host locale

Consentire il traffico di migrazione in ingresso solo in una rete specifica
Scegliere Kerberos come protocollo di autenticazione

Ogni riga è un comando separato.

PowerShell

PS C:\> Enable-VMMigration

PS C:\> Set-VMMigrationNetwork [Link]

PS C:\> Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos

Set-VMHost consente anche di scegliere un'opzione di prestazioni e altre impostazioni host. Ad

esempio, per scegliere SMB, ma mantenere il protocollo di autenticazione impostato sul valore
predefinito credSSP, immettere:

PowerShell

PS C:\> Set-VMHost -VirtualMachineMigrationPerformanceOption SMB

La tabella seguente descrive come utilizzare le opzioni di prestazioni.

 ﾉ Espandi la tabella

Option Description

TCP/IP Copia la memoria della macchina virtuale nel server di destinazione tramite una
connessione TCP/IP.

Compression Comprime il contenuto della memoria della macchina virtuale prima della copia nel server
di destinazione tramite una connessione TCP/IP. La compressione è l'impostazione
predefinita .

SMB Copia la memoria della macchina virtuale nel server di destinazione tramite una
connessione SMB 3.0.
- SMB diretto viene usato quando le schede di rete nei server di origine e di destinazione
dispongono dell'accesso remoto diretto alla memoria (RDMA) abilitato.
- SMB multicanale rileva e usa automaticamente più connessioni quando viene
configurata una configurazione SMB multicanale appropriata.
Per altre informazioni, vedere Improve Performance of a File Server with SMB Direct.

Passaggi successivi
Dopo aver configurato gli host, si è pronti per eseguire una migrazione in tempo reale. Per
istruzioni, vedere utilizzare live migration senza Clustering di Failover per spostare una
macchina virtuale.
Utilizzare live migration senza Clustering di
Failover per spostare una macchina virtuale
16/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Azure Local 2311.2 and later

In questo articolo viene descritto come spostare una macchina virtuale eseguendo una
migrazione in tempo reale senza utilizzare il Clustering di Failover. Live migration sposta le
macchine virtuali in esecuzione tra gli host Hyper-V senza tempi di inattività evidenti.

Per poter eseguire questa operazione, è necessario:

Un account utente che è un membro del gruppo amministratori Hyper-V locale o il

gruppo Administrators nel computer di origine e di destinazione.

Il ruolo Hyper-V in Windows Server 2016 e Windows Server 2012 R2 installato nei server
di origine e di destinazione e configurato per le migrazioni in tempo reale. È possibile
effettuare una migrazione in tempo reale tra gli host che eseguono Windows Server 2016
e Windows Server 2012 R2 se la versione della macchina virtuale è almeno la 5.

Per istruzioni sull'aggiornamento della versione, vedere Aggiornare la versione della

macchina virtuale in Hyper-V in Windows 10 o Windows Server 2016. Per istruzioni
sull'installazione, vedere Configurare gli host per la migrazione in tempo reale.

Gli strumenti di gestione Hyper-V installati in un computer che esegue almeno Windows
Server 2016 o Windows 10, a meno che gli strumenti non siano installati nel server di
origine o di destinazione e li eseguirai da questa posizione.

Gestione di Hyper-V consente di spostare una

macchina virtuale in esecuzione
1. Aprire la console di gestione di Hyper-V. (Da Server Manager selezionare
Strumenti>>Hyper-V Manager.

2. Nel riquadro di spostamento, selezionare uno dei server. Se non è elencato, fare clic con il
pulsante destro del mouse su Hyper-V Manager, scegliere Connetti al server, digitare il
nome del server e scegliere OK. Ripetere per aggiungere altri server.

3. Nel riquadro Macchine virtuali fare clic con il pulsante destro del mouse sulla macchina
virtuale e quindi scegliere Sposta. Verrà visualizzata la procedura guidata sposta.
 4. Utilizzare le pagine della procedura guidata per scegliere il tipo di spostamento, server di
destinazione e le opzioni.

5. Nella pagina Riepilogo esaminare le scelte effettuate e quindi selezionare Fine.

Utilizzare Windows PowerShell per spostare una

macchina virtuale in esecuzione
L'esempio seguente usa il cmdlet Move-VM per spostare una macchina virtuale denominata
LMTest in un server di destinazione denominato TestServer02 e sposta i dischi rigidi virtuali e
altri file, ad esempio checkpoint e file di paging intelligente, nella directory D:\LMTest nel server
di destinazione.

PowerShell

PS C:\> Move-VM LMTest TestServer02 -IncludeStorage -DestinationStoragePath

D:\LMTest

Troubleshooting

Impossibile stabilire una connessione

Se è stata impostata una delega vincolata, è necessario accedere al server di origine prima di
poter spostare una macchina virtuale. Se non si esegue questa operazione, il tentativo di
autenticazione ha esito negativo, si verifica un errore, e viene visualizzato questo messaggio:

"Operazione di migrazione di macchina virtuale non riuscita all'origine della migrazione.

Impossibile stabilire una connessione con il nome del computer host: nessuna credenziale è
disponibile nel pacchetto di sicurezza 0x8009030E."

Per risolvere questo problema, accedere al server di origine e lo spostamento di provare

nuovamente. Per evitare la necessità di accedere a un server di origine prima di eseguire una
migrazione in tempo reale, configurare la delega vincolata. È necessario che le credenziali di
amministratore di dominio per configurare la delega vincolata. Per istruzioni, vedere
Configurare gli host per la migrazione in tempo reale.

Non è riuscita perché l'hardware host non è compatibile

Se una macchina virtuale non dispone di compatibilità processore accesa e presenta uno o più
snapshot, il passaggio ha esito negativo se l'host dispone di versioni diverse di processore. Si
verifica un errore e viene visualizzato questo messaggio:

Impossibile spostare la macchina virtuale nel computer di destinazione. L'hardware nel

computer di destinazione non è compatibile con i requisiti hardware della macchina virtuale.

Per risolvere questo problema, arrestare la macchina virtuale e attivare l'impostazione di

compatibilità del processore.

1. Nel riquadro Macchine virtuali di Hyper-V Manager fare clic con il pulsante destro del
mouse sulla macchina virtuale e scegliere Impostazioni.

2. Nel riquadro di spostamento espandere Processori e selezionare Compatibilità.

3. Selezionare Eseguire la migrazione a un computer con una versione del processore

diversa.

4. Seleziona OK.

Per usare Windows PowerShell, usare il cmdlet Set-VMProcessor :

PowerShell

PS C:\> Set-VMProcessor TestVM -CompatibilityForMigrationEnabled $true

Usare la migrazione in tempo reale con
cluster di gruppi di lavoro
16/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Azure Local 2311.2 and later

Questo articolo descrive come spostare una macchina virtuale eseguendo una migrazione in
tempo reale tra host che usano cluster di gruppi di lavoro. I cluster del gruppo di lavoro sono
un tipo di cluster di failover che non usa un controller di dominio locale o una foresta Active
Directory. I cluster del gruppo di lavoro vengono invece aggiunti dal gruppo di lavoro. I cluster
del gruppo di lavoro sono stati introdotti in Windows Server 2016. Tuttavia, la migrazione in
tempo reale per i cluster di gruppi di lavoro non è supportata fino ad ora, in Windows Server
2025. Sfruttare la flessibilità della migrazione in tempo reale combinata con la disponibilità
elevata dei cluster del gruppo di lavoro.

Seguire la procedura descritta in questo articolo per eseguire la migrazione in tempo reale.

Prerequisites
Per eseguire una migrazione in tempo reale degli host tramite cluster di gruppi di lavoro, è
necessario soddisfare i prerequisiti seguenti:

Un cluster del gruppo di lavoro con due o più nodi è operativo. Per altre informazioni
sulla creazione di un cluster del gruppo di lavoro, vedere Creare un cluster del gruppo di
lavoro.
Un account utente locale esiste in ogni nodo del server con un nome utente e una
password identici.

Prendere in considerazione le opzioni per

l'autenticazione e le prestazioni
Quando si configurano le migrazioni in tempo reale per i cluster di gruppi di lavoro, è
importante considerare il modo in cui l'autenticazione e le prestazioni.

Autenticazione: gli account locali con un nome utente e una password identici in ogni
nodo vengono usati per creare e configurare il cluster del gruppo di lavoro. Il cluster usa
certificati PKU2U autofirmato per eseguire l'autenticazione e poter spostare una macchina
virtuale da un nodo host a un altro nodo host senza Kerberos. Gli account locali in ogni
 nodo sono l'unico modo per autenticare correttamente i cluster del gruppo di lavoro e
consentire la migrazione in tempo reale tra server di origine e di destinazione.

Prestazioni: la configurazione delle opzioni di prestazioni può ridurre l'utilizzo della rete e
della CPU. Diverse opzioni, ad esempio le migrazioni simultanee, possono anche
velocizzare le migrazioni in tempo reale. Prendere in considerazione i requisiti e
l'infrastruttura e configurazioni diverse per decidere di test.

Eseguire una migrazione in tempo reale con cluster

di gruppi di lavoro Hyper-V
Nelle sezioni successive verranno completati i passaggi seguenti:

Installare i ruoli Hyper-V e gli strumenti di gestione di Hyper-V. Ogni macchina virtuale
richiede l'installazione di Hyper-V per potersi connettere ad altri host ed eseguire una
migrazione in tempo reale.
Creare una nuova macchina virtuale e aggiungerla al cluster del gruppo di lavoro.
Aggiungere un ruolo macchina virtuale per facilitare la migrazione in tempo reale.
Configurare i server di origine e di destinazione. Configurare ogni nodo del server per
abilitare le migrazioni in tempo reale.
Spostare una macchina virtuale in esecuzione con la migrazione in tempo reale.
Completare una migrazione in tempo reale spostando una macchina virtuale in
esecuzione tra host Hyper-V senza tempi di inattività evidenti.

Passaggio 1: Installare il ruolo Hyper-V

Il ruolo Hyper-V deve essere installato nei server di origine e di destinazione e configurato per
le migrazioni in tempo reale. Installare questo ruolo prima di continuare.

Hyper-V offre i servizi che è possibile usare per creare e gestire macchine virtuali. Hyper-V può
essere installato in molti modi. Questa sezione descrive come installare il ruolo usando
PowerShell o Server Manager.

PowerShell

1. Aprire una sessione di PowerShell come amministratore.

2. Usare il cmdletInstall-WindowsFeature per installare il ruolo Hyper-V con il comando

seguente:

PowerShell
 Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart

3. Attendere l'installazione del ruolo e quindi riavviare la macchina virtuale.

4. Ripetere l'installazione per le altre macchine virtuali nel cluster.

７ Nota

Se non è possibile installare il ruolo Hyper-V, potrebbe essere necessario abilitare la

virtualizzazione annidata. Vedere come abilitare la virtualizzazione annidata per
consentire l'esecuzione di Hyper-V all'interno di una macchina virtuale Hyper-V.

Passaggio 2: Creare una nuova macchina virtuale e

aggiungerla al cluster del gruppo di lavoro
Aggiungere una nuova macchina virtuale Hyper-V come ruolo al cluster del gruppo di lavoro
per eseguire una migrazione in tempo reale tra host.

PowerShell

1. Connettersi a uno dei nodi del server.

2. Aprire una sessione di PowerShell come amministratore.

3. Eseguire il comando New-VM seguente per creare una nuova macchina virtuale con
10 GB di memoria e usa un'immagine VHDX esistente nel nodo del server. Modificare
i parametri e i valori in base alle esigenze per personalizzare la configurazione.

PowerShell

New-VM -Name "<VM_NAME>" -MemoryStartupBytes 10GB -VHDPath

<PATH_TO_VHDX_FILE>

4. Aggiungere la macchina virtuale come ruolo Macchina virtuale nel cluster del
gruppo di lavoro abilita il failover automatico.

PowerShell
 Add-ClusterVirtualMachineRole -VirtualMachine <VM_NAME>

Passaggio 3: Configurare i computer di origine e di

destinazione per la migrazione in tempo reale
In questo passaggio configurare le macchine virtuali di origine e di destinazione host per
abilitare le migrazioni in tempo reale. Qui è anche possibile specificare le impostazioni di
migrazione in tempo reale, ad esempio il numero di migrazioni in tempo reale e di
archiviazione da consentire contemporaneamente.

PowerShell

1. Connettersi a uno dei nodi del server.

2. Aprire una sessione di PowerShell come amministratore.

3. Usare prima di tutto il cmdlet Enable-VMMigration per configurare la migrazione in

tempo reale nell'host della macchina virtuale Hyper-V.

PowerShell

Enable-VMMigration

4. Usare il cmdlet Set-VMHost per configurare l'host Hyper-V locale. Il comando

seguente configura la macchina virtuale per consentire 10 migrazioni in tempo reale
simultanee e migrazioni di archiviazione. Modificare questi valori impostando il
numero di migrazioni in tempo reale e di archiviazione simultanee consentite dalla
configurazione. Potrebbe essere necessario testare configurazioni diverse per
decidere.

PowerShell

Set-VMHost -MaximumVirtualMachineMigrations 10 -MaximumStorageMigrations

10

Set-VMHost consente anche di specificare un'opzione di prestazioni e altre

impostazioni host. Prendere in considerazione l'uso di un parametro come -
VMMigrationPerformance per scegliere altre impostazioni per la macchina virtuale.
 5. Ripetere i passaggi per l'altro nodo del server.

Passaggio 4: Spostare una macchina virtuale in esecuzione

con migrazione in tempo reale
Infine, eseguire una migrazione in tempo reale per spostare una macchina virtuale in
esecuzione.

1. Connettersi al nodo proprietario corrente nel cluster del gruppo di lavoro.

2. Aprire Gestione cluster di failover.

3. Nella sezione Ruoli selezionare il ruolo macchina virtuale e fare clic con il pulsante destro
del mouse.

4. Selezionare Sposta, quindi Migrazione in tempo reale e quindi Nodo migliore possibile.

5. Nella colonna Informazioni viene visualizzato uno stato con il messaggio Migrazione in
tempo reale, X% completato.

6. Al termine, verificare che la colonna Nodo proprietario venga aggiornata con l'altro nodo
nel cluster del gruppo di lavoro.

Passaggi successivi
Dopo aver completato una migrazione in tempo reale, è importante verificare che la
migrazione funzioni e che tutte le macchine virtuali migrate siano state migrate correttamente.
Se si verificano problemi durante o dopo una migrazione, potrebbe essere necessario rivedere
le migrazioni simultanee consentite o configurare le opzioni di prestazioni della migrazione in
tempo reale.

Per altre informazioni sulle opzioni relative alle prestazioni di Live Migration, vedere
Panoramica di Virtual Machine Live Migration

Altre informazioni sulle prestazioni della migrazione in tempo reale sono disponibili anche
nelle prestazioni di I/O della rete Hyper-V.
Uso di Hyper-V e Windows PowerShell
15/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Dopo aver esaminato le nozioni di base della distribuzione di Hyper-V, la creazione di

macchine virtuali e la gestione di queste macchine virtuali, si esaminerà come automatizzare
molte di queste attività con PowerShell.

Restituisce un elenco di comandi Hyper-V

1. Selezionare il pulsante Start di Windows e quindi digitare PowerShell.

2. Eseguire il comando seguente per visualizzare un elenco ricercabile dei comandi di

PowerShell disponibili con il modulo di PowerShell Hyper-V.

PowerShell

Get-Command -Module hyper-v | Out-GridView

Si ottiene un risultato simile al seguente:

1. Per altre informazioni su un particolare comando di PowerShell, usare Get-Help . Ad

esempio, l'esecuzione del comando seguente restituisce informazioni sul Get-VM
 comando Hyper-V.

PowerShell

Get-Help Get-VM

L'output mostra come strutturare il comando, i parametri obbligatori e facoltativi e gli

alias che è possibile usare.

Restituisce un elenco di macchine virtuali

Usare il Get-VM comando per restituire un elenco di macchine virtuali.

1. In PowerShell eseguire il comando seguente:

PowerShell

Get-VM

Verrà visualizzato un risultato simile al seguente:

2. Per restituire un elenco solo di macchine virtuali accese, aggiungere un filtro al Get-VM
comando. È possibile aggiungere un filtro usando il Where-Object comando . Per altre
 informazioni sul filtro, vedere Uso della documentazione di Where-Object .

PowerShell

Get-VM | where {$_.State -eq 'Running'}

3. Per elencare tutte le macchine virtuali in uno stato spento, eseguire il comando seguente.
Questo comando è una copia del comando del passaggio 2 con il filtro modificato da 'In
esecuzione' a 'Off'.

PowerShell

Get-VM | where {$_.State -eq 'Off'}

Avviare e arrestare le macchine virtuali

1. Per avviare una determinata macchina virtuale, eseguire il comando seguente con il nome
della macchina virtuale:

PowerShell

Start-VM -Name <virtual machine name>

2. Per avviare tutte le macchine virtuali attualmente spente, ottenere un elenco di tali
computer e inviare tramite pipe l'elenco al Start-VM comando:

PowerShell

Get-VM | where {$_.State -eq 'Off'} | Start-VM

3. Per arrestare tutte le macchine virtuali in esecuzione, eseguire il comando seguente:

PowerShell

Get-VM | where {$_.State -eq 'Running'} | Stop-VM

Creare un checkpoint della macchina virtuale

Per creare un checkpoint usando PowerShell, selezionare la macchina virtuale usando il Get-VM
comando e inviarlo tramite pipe al Checkpoint-VM comando . Assegnare infine al checkpoint un
nome usando -SnapshotName . Il comando completo è simile al seguente:
 PowerShell

Get-VM -Name <VM Name> | Checkpoint-VM -SnapshotName <name for snapshot>

Creare una nuova macchina virtuale

L'esempio seguente illustra come creare una nuova macchina virtuale in PowerShell Integrated
Scripting Environment (ISE). Questo è un semplice esempio e può essere ampliato per
includere funzionalità di PowerShell aggiuntive e distribuzioni di macchine virtuali più avanzate.

1. Per aprire PowerShell ISE fare clic sull'avvio, digitare PowerShell ISE.

2. Eseguire il codice seguente per creare una macchina virtuale. Per informazioni dettagliate
sul comando, vedere la documentazione relativa a New-VM .

PowerShell

$VMName = "VMNAME"

$VM = @{
Name = $VMName
MemoryStartupBytes = 2147483648
Generation = 2
NewVHDPath = "C:\Virtual Machines\$VMName\$[Link]"
NewVHDSizeBytes = 53687091200
BootDevice = "VHD"
Path = "C:\Virtual Machines\$VMName"
SwitchName = (Get-VMSwitch).Name
}

New-VM @VM

Riepilogo e riferimenti
Questo documento illustra alcuni semplici passaggi per esplorare il modulo di PowerShell
Hyper-V e alcuni scenari di esempio. Per altre informazioni sul modulo Hyper-V PowerShell,
vedere le informazioni di riferimento sui cmdletHyper-V in Windows PowerShell.
Panoramica della memoria dinamica di
Hyper-V
28/10/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Se sono presenti macchine virtuali inattive o a basso carico, ad esempio in ambienti VDI
(Virtual Desktop Infrastructure) in pool, la memoria dinamica consente di aumentare il
consolidamento e migliorare l'affidabilità per le operazioni di riavvio. È anche possibile
ottenere agilità per rispondere alle modifiche ai requisiti con queste nuove funzionalità.

Vantaggi principali
Con la memoria dinamica è possibile ottenere numeri di consolidamento più elevati con
maggiore affidabilità per le operazioni di riavvio. Questa funzionalità può comportare costi
inferiori, in particolare negli ambienti con molte macchine virtuali inattive o a basso carico, ad
esempio ambienti VDI in pool. Le modifiche alla configurazione della fase di esecuzione della
memoria dinamica possono ridurre i tempi di inattività e offrire maggiore agilità per rispondere
alle modifiche dei requisiti.

Hyper-V in esecuzione in Windows Server calcola automaticamente una quantità di memoria

da riservare per l'uso esclusivo dal sistema operativo host di gestione. Questa memoria viene
usata per eseguire i servizi di virtualizzazione. Se il computer fa parte di un cluster di failover,
Hyper-V riserva anche memoria sufficiente per eseguire i servizi del cluster di failover.

Panoramica tecnica
La memoria dinamica definisce la memoria di avvio come quantità minima di memoria che una
macchina virtuale può avere. Tuttavia, Windows richiede più memoria durante l'avvio rispetto
allo stato stabile. Di conseguenza, gli amministratori talvolta assegnano memoria aggiuntiva a
una macchina virtuale perché Hyper-V non può recuperare memoria da queste macchine
virtuali dopo l'avvio. La memoria dinamica introduce un'impostazione di memoria minima, che
consente Hyper-V di recuperare la memoria inutilizzata dalle macchine virtuali. Questa
funzionalità si riflette come un aumento dei numeri di consolidamento delle macchine virtuali,
in particolare negli ambienti VDI (Virtual Desktop Infrastructure).

Windows Server ha anche introdotto il paging intelligente per operazioni di riavvio affidabili
delle macchine virtuali. Anche se la memoria minima aumenta i numeri di consolidamento delle
macchine virtuali, comporta anche una sfida. Se una macchina virtuale ha una quantità di
memoria inferiore rispetto alla memoria di avvio e se viene riavviata, Hyper-V richiede memoria
aggiuntiva per riavviare la macchina virtuale. A causa della pressione della memoria host o
degli stati della macchina virtuale, Hyper-V potrebbe non avere sempre memoria aggiuntiva
disponibile. Questa limitazione può causare errori sporadici di riavvio della macchina virtuale. Il
paging intelligente risolve il divario di memoria tra memoria minima e memoria di avvio e
consente alle macchine virtuali di riavviarsi in modo affidabile.

Configurazione minima della memoria con un'operazione di

riavvio affidabile
Come nella versione precedente di Memoria dinamica, è possibile configurare una quantità di
memoria minima per le macchine virtuali e Hyper-V continua a garantire che assegni sempre
questa quantità alle macchine virtuali in esecuzione.

Per offrire un'esperienza di riavvio affidabile per le macchine virtuali configurate con memoria
minima rispetto alla memoria di avvio, Hyper-V usa il paging intelligente. Questo metodo di
gestione della memoria usa le risorse del disco come memoria aggiuntiva e temporanea
quando è necessaria più memoria per riavviare una macchina virtuale. Questo approccio
presenta vantaggi e svantaggi. Offre un modo affidabile per mantenere le macchine virtuali in
esecuzione quando non è disponibile memoria fisica. Tuttavia, può ridurre le prestazioni delle
macchine virtuali perché le velocità di accesso al disco sono molto più lente rispetto alle
velocità di accesso alla memoria.

） Importante

Quando si installa o si aggiorna il sistema operativo di una macchina virtuale, la quantità

di memoria disponibile per la macchina virtuale durante l'installazione e il processo di
aggiornamento è il valore specificato come RAM di avvio. Anche se si configura la
memoria dinamica per la macchina virtuale, la macchina virtuale usa solo la quantità di
memoria configurata nell'impostazione RAM di avvio . Verificare che il valore della RAM
di avvio soddisfi i requisiti minimi di memoria del sistema operativo durante la procedura
di installazione o aggiornamento.

Per ridurre al minimo l'impatto sulle prestazioni del paging intelligente, Hyper-V lo usa solo
quando si verificano tutte le condizioni seguenti:

La macchina virtuale viene riavviata.

Non è disponibile memoria fisica.
Non è possibile recuperare memoria da altre macchine virtuali in esecuzione nell'host.

Hyper-V non usa il paging intelligente quando:

 Si avvia una macchina virtuale da uno stato "disattivato" (invece di un riavvio).
Si sovrascrive la memoria per una macchina virtuale in esecuzione.
Una macchina virtuale esegue il failover nei cluster Hyper-V.

Quando si sovrascrive la memoria host, Hyper-V continua a basarsi sull'operazione di paging

nel sistema operativo guest perché è più efficace rispetto al paging intelligente. L'operazione di
paging nel sistema operativo guest viene eseguita da Windows Memory Manager. Il gestore
della memoria di Windows ha più informazioni rispetto all'host Hyper-V sull'utilizzo della
memoria all'interno della macchina virtuale, il che significa che può fornire a Hyper-V
informazioni migliori da usare quando si sceglie quale memoria paginare. Per questo motivo, il
sistema comporta un sovraccarico inferiore rispetto a Smart Paging.

Per ridurre ulteriormente l'impatto del paging intelligente, Hyper-V rimuove la memoria dalla
macchina virtuale dopo il completamento del processo di avvio. Questo obiettivo viene
raggiunto coordinando i componenti di memoria dinamica all'interno del sistema operativo
guest ("ballooning"), il che rende possibile per la macchina virtuale smettere di utilizzare il
paging intelligente. Con questa tecnica, l'uso del paging intelligente è temporaneo e non
dovrebbe durare più di 10 minuti.

Si noti inoltre quanto segue sul modo in cui Hyper-V utilizza il paging intelligente:

Crea file di paging smart solo quando è necessario per una macchina virtuale.
Elimina i file di paging intelligente dopo aver rimosso la quantità di memoria aggiuntiva.
Non usa di nuovo il paging intelligente per questa macchina virtuale finché non si verifica
un altro riavvio e non è disponibile memoria fisica sufficiente.

Modifiche alla configurazione della memoria dinamica in fase

di esecuzione
Hyper-V consente di apportare le modifiche di configurazione seguenti alla memoria dinamica
quando la macchina virtuale è in esecuzione:

Aumentare la memoria massima.

Ridurre la memoria minima.

Informazioni sulle impostazioni della memoria

dinamica
Le impostazioni della macchina virtuale seguenti in Hyper-V Manager consentono di
configurare la memoria dinamica. Esaminare le descrizioni seguenti per comprendere il
funzionamento delle funzionalità e come sono correlate.
 ﾉ Espandi la tabella

Impostazione Description

RAM di avvio Specifica la quantità di memoria necessaria per avviare la macchina virtuale. Il valore
deve essere sufficientemente elevato per consentire l'avvio del sistema operativo guest,
ma deve essere il più basso possibile per consentire un utilizzo ottimale della memoria e
rapporti di consolidamento potenzialmente più elevati.

RAM minima Specifica la quantità minima di memoria da allocare alla macchina virtuale dopo l'avvio
della macchina virtuale. Impostare il valore minimo di 32 MB fino a un valore massimo
uguale al valore di RAM di avvio .

RAM massima Specifica la quantità massima di memoria che può essere usata dalla macchina virtuale.
Impostare il valore da un valore inferiore a quello della RAM di avvio fino a un massimo
di 1 TB. Tuttavia, una macchina virtuale può usare solo la quantità massima di memoria
supportata dal sistema operativo guest. Ad esempio, se si specificano 64 GB per una
macchina virtuale che esegue un sistema operativo guest che supporta un massimo di
32 GB, la macchina virtuale non può usare più di 32 GB.

Buffer di Specifica la quantità di memoria Hyper-V tenta di assegnare alla macchina virtuale
memoria rispetto alla quantità di memoria effettivamente necessaria dalle applicazioni e dai
servizi in esecuzione all'interno della macchina virtuale. Il buffer di memoria viene
specificato come percentuale perché la quantità effettiva di memoria che rappresenta il
buffer cambia in risposta alle variazioni nell'utilizzo della memoria durante l'esecuzione
della macchina virtuale. Hyper-V usa i contatori delle prestazioni nella macchina virtuale
che identificano la memoria di cui è stato eseguito il commit per determinare i requisiti
di memoria correnti della macchina virtuale e quindi calcola la quantità di memoria da
aggiungere come buffer. Il buffer viene determinato usando la formula seguente:
Quantità di buffer di memoria = quantità di memoria effettivamente necessaria per la
macchina virtuale / (valore del buffer di memoria / 100). Ad esempio, se la memoria
sottoposta a commit nel sistema operativo guest è di 1.000 MB e il buffer di memoria è
20%, Hyper-V tenta di allocare un ulteriore 20% (200 MB) per un totale di 1.200 MB di
memoria fisica allocata alla macchina virtuale. Nota: Il buffer non viene mantenuto
quando nel computer non è disponibile memoria fisica sufficiente per assegnare a ogni
macchina virtuale il buffer di memoria richiesto.

Peso della Fornisce Hyper-V un modo per determinare come distribuire la memoria tra le macchine
memoria virtuali se nel computer non è disponibile memoria fisica sufficiente per assegnare a
ogni macchina virtuale la quantità di memoria richiesta.

Domande frequenti sulla gestione della memoria

dinamica/Hyper-V
Di seguito sono riportate alcune domande frequenti relative alla memoria dinamica.
È necessario configurare manualmente le dimensioni del file
di pagina dopo l'installazione del ruolo Hyper-V?
No, è consigliabile consentire al sistema di gestire le dimensioni del file di pagina durante
l'esecuzione di Hyper-V.

In che modo la memoria è divisa tra il sistema operativo host

e le macchine virtuali in esecuzione?
Hyper-V monitora l'integrità di runtime del sistema operativo host per determinare la quantità
di memoria che può allocare in modo sicuro alle macchine virtuali.

Impossibile avviare la macchina virtuale con il messaggio di

errore seguente "Memoria insufficiente nel sistema per
avviare la macchina virtuale" o "Impossibile inizializzare la
memoria: memoria insufficiente (0x8007000E)". Come è
possibile stabilire la quantità di memoria disponibile per le
macchine virtuali?
Come descritto in precedenza, Hyper-V monitora l'integrità del runtime del sistema operativo
host per determinare la quantità di memoria che può allocare in modo sicuro alle macchine
virtuali.

È possibile visualizzare l'attuale quantità di memoria disponibile per le macchine virtuali nel
seguente contatore di Performance Monitor: Hyper-V Dynamic Memory Balancer – Available
Memory.
Connessione macchina virtuale Hyper-V
16/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Connessione Macchina Virtuale (VMConnect) è uno strumento che si può usare per connettersi
a una macchina virtuale per installare o interagire con il sistema operativo guest in una
macchina virtuale. Tramite VMConnect è possibile eseguire alcune attività, incluse le seguenti:

Avvia e arresta una macchina virtuale

Connettersi a un'immagine DVD (file .iso) o a un'unità flash USB

Creazione di un checkpoint

Modificare le impostazioni di una macchina virtuale

Suggerimenti per l'uso di VMConnect

È possibile trovare le informazioni seguenti utili per l'uso di VMConnect:

ﾉ Espandi la tabella

Per fare questo… Fai questo...

Inviare i clic del mouse o Fai clic in un punto qualsiasi della finestra della macchina virtuale. Il
l'input da tastiera alla puntatore del mouse potrebbe essere visualizzato come punto piccolo
macchina virtuale quando ci si connette a una macchina virtuale in esecuzione.

Restituire i clic del mouse o Premere CTRL+ALT+FRECCIA SINISTRA e quindi spostare il puntatore
l'input da tastiera al computer del mouse all'esterno della finestra della macchina virtuale. Questa
fisico combinazione di tasti di rilascio del mouse può essere modificata nelle
impostazioni di Hyper-V nella console di gestione di Hyper-V.

Inviare la combinazione di Selezionare Azione>Ctrl+Alt+Canc o usare la combinazione di tasti

tasti CTRL+ALT+DELETE a una CTRL+ALT+FINE.
macchina virtuale

Passare dalla modalità finestra Seleziona Visualizza>Modalità schermo intero. Per tornare alla modalità
alla modalità schermo intero finestra, premere CTRL+ALT+INTERR.

Creare un checkpoint per Selezionare Azione>Punto di controllo oppure usare la combinazione di

acquisire lo stato corrente del tasti CTRL+N.
computer per la risoluzione
dei problemi
Per fare questo… Fai questo...

Modificare le impostazioni Seleziona File>Impostazioni.

della macchina virtuale

Connettersi a un'immagine Selezionare Supporti.

DVD (file .iso) o a un disco
floppy virtuale (file .vfd) I dischi floppy virtuali non sono supportati per le macchine virtuali di
seconda generazione. Per altre informazioni, vedi È necessario creare
una macchina virtuale di generazione 1 o 2 in Hyper-V?

Usare le risorse locali di un Abilita la modalità sessione avanzata nell'host Hyper-V, usa VMConnect
host in una macchina virtuale per connetterti alla macchina virtuale e, prima di connetterti, scegli la
Hyper-V, ad esempio un'unità risorsa locale che vuoi usare. Per le procedure specifiche, vedere Usare le
flash USB risorse locali nella macchina virtuale Hyper-V con VMConnect.

Modificare le impostazioni di Nel prompt dei comandi o in Windows PowerShell esegui questo
VMConnect salvate per una comando:
macchina virtuale [Link] <ServerName> <VMName> /edit

Impedire a un utente di La mancata attivazione della modalità sessione avanzata potrebbe

VMConnect di impossessarsi comportare rischi per la sicurezza e la privacy. Se un utente è connesso e
della sessione VMConnect di connesso a una macchina virtuale tramite VMConnect e un altro utente
un altro utente autorizzato si connette alla stessa macchina virtuale, la sessione viene
acquisita dal secondo utente e il primo utente perde la sessione. Il
secondo utente sarà in grado di visualizzare il desktop, i documenti e le
applicazioni del primo utente.

Gestire i componenti o i Negli host Hyper-V che eseguono Windows 10 o Windows Server 2016
servizi di integrazione che non puoi gestire i servizi di integrazione con VMConnect. Vedere questi
consentono alla macchina articoli:
virtuale di comunicare con - Abilitare o disabilitare i servizi di integrazione dall'host Hyper-V
l'host Hyper-V - Abilitare o disabilitare i servizi di integrazione da una macchina virtuale
Windows
- Abilitare o disabilitare i servizi di integrazione da una macchina virtuale
Linux
- Aggiornare i servizi di integrazione nella macchina virtuale

Per gli host che eseguono Windows Server 2012 o Windows Server 2012
R2, vedi Servizi di integrazione.

Ridimensionare la finestra Puoi modificare le dimensioni della finestra VMConnect per le macchine
VMConnect virtuali di seconda generazione che eseguono un sistema operativo
Windows. A tale scopo, potrebbe essere necessario attivare la modalità
sessione avanzata nell'host Hyper-V. Per le macchine virtuali che
eseguono Ubuntu, vedere Modifica risoluzione dello schermo di Ubuntu
in una macchina Virtuale Hyper-V.

Combinazioni di tasti
Per impostazione predefinita, i clic tramite tastiera e mouse vengono inviati alla macchina
virtuale. Potrebbe quindi essere necessario premere CTRL + ALT + FRECCIA SINISTRA prima di
usare i tasti di scelta rapida seguenti.

ﾉ Espandi la tabella

Combinazione di tasti Description

CTRL+ALT+FRECCIA SINISTRA Rilascio del mouse

CTRL+ALT+END Equivalente di CTRL+ALT+CANC nella macchina virtuale

CTRL+ALT+BREAK Passaggio dalla modalità schermo intero alla modalità finestra

CTRL+O Apertura delle impostazioni della macchina virtuale

CTRL+S Avvio della macchina virtuale

CTRL+N Crea un checkpoint

CTRL+E Ripristina un checkpoint

CTRL+C Esegue un'acquisizione dello schermo

Contenuti correlati
Hyper-V panoramica
Usare le risorse locali nella macchina virtuale Hyper-V con VMConnect
Usare le risorse locali in Hyper-V macchina
virtuale con VMConnect
16/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Virtual Manager Connection (VMConnect) consente di usare risorse locali del computer, come
una stampante o un'unità flash USB rimovibile, in una macchina virtuale. La modalità sessione
avanzata consente anche di ridimensionare la finestra VMConnect. Questo articolo illustra
come configurare l'host e concedere alla macchina virtuale l'accesso a una risorsa locale.

La modalità sessione avanzata e la funzione Incolla qui il testo degli Appunti sono disponibili
solo per le macchine virtuali che eseguono sistemi operativi Windows recenti. Vedere Requisiti
per l'uso delle risorse locali.

Per le macchine virtuali che eseguono Ubuntu, vedere Modifica risoluzione dello schermo di
Ubuntu in una macchina Virtuale Hyper-V.

Scegliere una risorsa locale

Le risorse locali includono stampanti, gli Appunti e le unità locali nel computer in cui è in
esecuzione VMConnect. Per altre informazioni, vedere Requisiti per l'uso delle risorse locali.

Per scegliere una risorsa locale:

1. Aprire VMConnect.

2. Spegnere la macchina virtuale a cui ci si vuole connettere.

3. Selezionare Mostra opzioni.

4. Selezionare Risorse locali.

5. Selezionare Altro.

6. Selezionare l'unità da usare nella macchina virtuale e fare clic su OK.

 7. Selezionare Salva impostazioni per connessioni future alla macchina virtuale.

8. Selezionare Connetti.

Il percorso dell'unità locale condivisa alla macchina virtuale, in una macchina virtuale guest
basata su Windows, si trova in Questo PC in Unità e cartelle reindirizzate. Il percorso di una
macchina virtuale guest basata su Linux si trova in /home/shared-drives.

Modificare le impostazioni di VMConnect

È possibile modificare facilmente le impostazioni di connessione per VMConnect eseguendo il
comando seguente in Windows PowerShell o nel prompt dei comandi:

[Link] <ServerName> <VMName> /edit

 ７ Nota

Può essere necessaria una finestra del prompt dei comandi con privilegi elevati.

Requisiti per l'uso delle risorse locali

Per poter usare le risorse locali del computer in una macchina virtuale:

È necessario aver attivato le impostazioni Criteri modalità sessione avanzata e Modalità

sessione avanzata dell'host Hyper-V.

Il computer in cui si usa VMConnect deve eseguire almeno Windows 10 o Windows

Server 2016.

La macchina virtuale deve avere Servizi Desktop remoto abilitati ed eseguire almeno
Windows 10 o Windows Server 2016.

Se il computer che esegue VMConnect e la macchina virtuale soddisfano entrambi i requisiti

previsti, è possibile usare una qualsiasi delle risorse locali seguenti, se disponibili:

Configurazione di visualizzazione

Audio

Printers

Appunti per copiare e incollare

Smart card

Dispositivi USB

Drives

Dispositivi Plug and Play supportati

Perché utilizzare le risorse locali del computer?

Si potrebbero usare le risorse locali del computer per:

Risolvere i problemi di una macchina virtuale senza una connessione di rete alla macchina
virtuale.
 Copiare e incollare i file da e verso la macchina virtuale con la stessa procedura usata con
una Connessione Desktop remoto.

Accedere alla macchina virtuale usando una smart card.

Eseguire la stampa da una macchina virtuale su una stampante locale.

Testare e risolvere i problemi delle applicazioni dello sviluppatore che richiedono il

reindirizzamento dell'audio e dei dispositivi USB senza usare RDP.

Vedere anche
connessione macchina virtualeHyper-V

È necessario creare una macchina virtuale di generazione 1 o 2 in Hyper-V?

Condividere i dispositivi con la macchina
virtuale Hyper-V
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Quando si usa la modalità sessione avanzata nello strumento Virtual Machine Connection
(VMConnect), è possibile connettersi alle macchine virtuali (VM) Hyper-V usando Remote
Desktop Protocol (RDP). Questa funzionalità non solo migliora l'esperienza di visualizzazione
generale delle macchine virtuali, l'uso di RDP consente anche alla macchina virtuale e al
computer di condividere i dispositivi. Questa funzionalità è disponibile solo per le macchine
virtuali Windows.

L'uso di RDP in modalità sessione avanzata offre molti vantaggi:

Rende le macchine virtuali ridimensionabili e con riconoscimento DPI elevato

Migliora l'integrazione delle macchine virtuali:
Appunti condivisi
Condivisione di file tramite trascinamento o copia e incolla
Rende possibile la condivisione dei dispositivi:
Microfono e altoparlanti
Dispositivi USB
Dischi dati, inclusa l'unità C
Stampanti

Poiché RDP è attivato per impostazione predefinita in Windows, probabilmente si usa già RDP
per connettersi alle macchine virtuali Windows. Questo articolo illustra alcuni dei vantaggi e
delle opzioni nascoste nella finestra di dialogo delle impostazioni di connessione. Illustra come
visualizzare il tipo di sessione, immettere modalità sessione avanzata e configurare le
impostazioni della sessione.

Controllare il tipo di sessione

È possibile controllare il tipo di connessione usando l'icona Modalità sessione avanzata sulla
barra degli strumenti VMConnect. È anche possibile usare questo pulsante per passare dalla
modalità sessione di base alla modalità sessione avanzata.
 ﾉ Espandi la tabella

 Icona Stato connessione

Attualmente è in esecuzione in modalità sessione avanzata. Selezionando questa icona si

riconnette alla macchina virtuale in modalità Basic.

È attualmente in esecuzione in modalità sessione di base, ma è disponibile la modalità sessione
avanzata. Selezionando questa icona si riconnette alla macchina virtuale in modalità sessione
avanzata.

Attualmente è in esecuzione in modalità sessione di base. La modalità sessione avanzata non è
disponibile per questa macchina virtuale.

Configurare una macchina virtuale per Desktop

remoto
La modalità sessione avanzata richiede l'attivazione di Desktop remoto nella macchina virtuale.
Nel menu Impostazioni o Start cercare Impostazioni Desktop remoto. Attivare l'interruttore
Abilita Desktop remoto .
Windows 10 (versione 2004 e successive) e Windows 11 richiedono un'impostazione
aggiuntiva. Se lo sfondo della finestra VMConnect non visualizza un prompt di accesso,
disabilitare l'accesso a Windows Hello:

1. Accedere alla macchina virtuale in modalità sessione di base.

2. Passare a Impostazioni Account> Opzioni > diaccesso.

3. Disattiva Per una maggiore sicurezza, consenti solo l'accesso a Windows Hello per gli
account Microsoft in questo dispositivo.

ﾉ Espandi la tabella

Windows 11 Windows 10

 

4. Disconnettersi dalla macchina virtuale o riavviarlo prima di chiudere la finestra

VMConnect.
 Per verificare, verificare che la finestra VMConnect visualizzi una richiesta di accesso alla
modalità sessione avanzata dopo la riconnessione.

Condividere unità e dispositivi

È possibile trovare le funzionalità di condivisione dei dispositivi della modalità sessione
avanzata nella finestra di dialogo di connessione visualizzata quando ci si connette a una
macchina virtuale:

Per impostazione predefinita, la modalità sessione avanzata fornisce alle macchine virtuali
l'accesso alle risorse seguenti:

Appunti
Stampanti
Riproduzione audio (verso altoparlanti di sistema)

Per condividere i dispositivi con la macchina virtuale o per modificare le impostazioni

predefinite:

1. In VMConnect selezionare la macchina virtuale a cui connettersi.

2. Selezionare Mostra opzioni.

 3. Selezionare Risorse locali e quindi modificare le impostazioni.

Per verificare, verificare che le risorse selezionate siano disponibili dopo la connessione
alla macchina virtuale.

Condividere l'archiviazione e i dispositivi USB

La modalità sessione avanzata supporta anche la condivisione di tipi di dispositivi aggiuntivi, ad
esempio:

ﾉ Espandi la tabella

Tipo di dispositivo Esempi

Storage Unità locali (incluse C:), unità rimovibili

Dispositivi USB Unità flash, archiviazione esterna

Dispositivi di sicurezza Smart card, dispositivi complementari Windows Hello

Per condividere questi dispositivi con una macchina virtuale:

1. In Dispositivi e risorse locali selezionare Altro.

2. Selezionare i dispositivi da condividere con la macchina virtuale. L'unità di sistema, che è

unità C in Windows, è particolarmente utile per la condivisione di file.
 Per verificare, verificare che le unità condivise siano visualizzate in Questo PC in Esplora
file all'interno della macchina virtuale.

Condividere dispositivi audio (altoparlanti e microfoni)

Per impostazione predefinita, le macchine virtuali trasferisce l'audio nel computer host usando
il dispositivo audio attualmente selezionato. È possibile configurare le impostazioni audio
seguenti:

ﾉ Espandi la tabella

Impostazione Options

Riproduzione audio Riproduci su questo computer, Riproduci su un computer remoto, Non

remota riprodurre

Registrazione audio Registra dal computer (collegamento del microfono), Non registrare
remota

Per modificare le impostazioni audio:

1. Selezionare Impostazioni per configurare le impostazioni audio remote.

 2. Configurare le impostazioni audio e microfono.

Per le macchine virtuali locali, Gioca su questo computer e Gioca su computer remoto
producono lo stesso risultato.

Per verificare, verificare che l'audio venga riprodotto tramite il dispositivo configurato e
che l'input del microfono venga rilevato se la registrazione è abilitata.

Riaprire le impostazioni di connessione

Se non viene visualizzata la finestra di dialogo di connessione o il pulsante Mostra opzioni ,
provare ad aprire VMConnect in modo indipendente dal menu di Windows o dalla riga di
comando come amministratore.

PowerShell
[Link]

VMConnect si apre e visualizza la finestra di dialogo di connessione con Mostra opzioni

disponibili.

Last updated on 22/01/2026

Automazione e gestione delle macchine
virtuali con PowerShell
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

È possibile usare PowerShell Direct per eseguire PowerShell arbitrario in windows 10 o versione
successiva o Windows Server 2016 o versione successiva, macchina virtuale dall'host Hyper-V.
Usare PowerShell Direct indipendentemente dalla configurazione di rete o dalle impostazioni di
gestione remota.

Ecco alcuni modi per eseguire PowerShell Direct:

Come sessione interattiva usando il cmdlet Enter-PSSession

Come sezione a uso singolo per eseguire un singolo comando o uno script usando il
cmdlet Invoke-Command
Come sessione persistente (build 14280 e versioni successive) usando i cmdlet New-
PSSession, Copy-Item e Remove-PSSession

Requisiti
Requisiti del sistema operativo:

Host: Windows 10, Windows Server 2016 o versione successiva che esegue Hyper-V.
Guest/Macchina virtuale: Windows 10, Windows Server 2016 o versione successiva.

Se si gestiscono macchine virtuali meno recenti, usare Virtual Machine Connection

(VMConnect) o connettersi tramite una connessione di rete.

Requisiti di configurazione:

La macchina virtuale deve essere eseguita localmente nell'host.

La macchina virtuale deve essere attivata ed eseguita con almeno un profilo utente
configurato.
È necessario essere connessi al computer host come amministratore di Hyper-V.
È necessario fornire credenziali utente valide per la macchina virtuale.

Creare ed uscire da una sessione interattiva di

PowerShell
Il modo più semplice per eseguire i comandi di PowerShell in una macchina virtuale consiste
nell'avviare una sessione interattiva.

All'avvio della sessione, i comandi digitati vengono eseguiti nella macchina virtuale, proprio
come se li digitassero direttamente in una sessione di PowerShell nella macchina virtuale
stessa.

Per avviare una sessione interattiva:

1. Nell'host Hyper-V aprire PowerShell come amministratore.

2. Eseguire uno dei comandi seguenti per creare una sessione interattiva usando il nome o il
GUID della macchina virtuale:

PowerShell
Enter-PSSession -VMName <VMName>
Enter-PSSession -VMId <VMId>

Immettere le credenziali per la macchina virtuale quando richiesto.

3. Eseguire i comandi nella macchina virtuale. Il nome VMName dovrebbe essere

visualizzato come prefisso per il prompt di PowerShell come segue:

Output

[VMName]: PS C:\>

Qualsiasi comando eseguito viene eseguito nella macchina virtuale. Per testare, eseguire
ipconfig o hostname per assicurarsi che questi comandi vengano eseguiti nella macchina

virtuale.

4. Al termine, eseguire il comando seguente per chiudere la sessione:

PowerShell
Exit-PSSession

７ Nota

Se la sessione non si connette, vedere la risoluzione dei problemi per possibili cause.

Per altre informazioni su questi cmdlet, vedere Enter-PSSession e Exit-PSSession.

Eseguire uno script o un comando con Invoke-
Command
PowerShell Direct con Invoke-Command è ideale per situazioni in cui è necessario eseguire un
comando o uno script in una macchina virtuale, ma non è necessario continuare a interagire
con la macchina virtuale oltre quel punto.

Per eseguire un singolo comando:

1. Nell'host Hyper-V aprire PowerShell come amministratore.

2. Eseguire uno dei comandi seguenti per creare una sessione usando il nome o il GUID
della macchina virtuale:

PowerShell

Invoke-Command -VMName <VMName> -ScriptBlock { command }

Invoke-Command -VMId <VMId> -ScriptBlock { command }

Immettere le credenziali per la macchina virtuale quando richiesto.

Il comando viene eseguito nella macchina virtuale. Se il comando produce output, lo

viene visualizzato nella console. La connessione viene chiusa automaticamente non
appena viene eseguito il comando.

Per eseguire uno script:

1. Nell'host Hyper-V aprire PowerShell come amministratore.

2. Eseguire uno dei comandi seguenti per creare una sessione usando il nome o il GUID
della macchina virtuale:

PowerShell
Invoke-Command -VMName <VMName> -FilePath C:\host\script_path\script.ps1
Invoke-Command -VMId <VMId> -FilePath C:\host\script_path\script.ps1

Immettere le credenziali per la macchina virtuale quando richiesto.

Lo script viene eseguito nella macchina virtuale. La connessione viene chiusa

automaticamente non appena viene eseguito il comando.

Per altre informazioni su questo cmdlet, vedere Invoke-Command.

Copiare file con New-PSSession e Copy-Item

７ Nota

PowerShell Direct supporta solo sessioni persistenti nelle build di Windows 14280 e
versioni successive

Le sessioni di PowerShell persistenti sono estremamente utili quando si scrivono script che
coordinano le azioni in uno o più computer remoti. Dopo la creazione, le sessioni permanenti
esistono in background fino a quando non si decide di eliminarle. Ciò significa che è possibile
fare riferimento alla stessa sessione più o più volte con Invoke-Command o Enter-PSSession
senza passare le credenziali.

Con lo stesso token, le sessioni mantengono lo stato. Poiché le sessioni persistenti vengono
mantenute, tutte le variabili create in una sessione o passate a una sessione vengono
mantenute tra più chiamate. È possibile usare diversi strumenti per lavorare con sessioni
persistenti. Per questo esempio, usare New-PSSession e Copy-Item per spostare i dati dall'host
a una macchina virtuale e da una macchina virtuale all'host.

Per creare una sessione, copiare i file:

1. Nell'host Hyper-V aprire PowerShell come amministratore.

2. Eseguire uno dei comandi seguenti per creare una sessione di PowerShell persistente
nella macchina virtuale usando New-PSSession .

PowerShell
$s = New-PSSession -VMName <VMName> -Credential (Get-Credential)
$s = New-PSSession -VMId <VMId> -Credential (Get-Credential)

Immettere le credenziali per la macchina virtuale quando richiesto.

２ Avviso

C'è un bug nelle build precedenti alla 14500. Se non si specificano esplicitamente le
credenziali con il flag -Credential , il servizio nel sistema ospite si arresta in modo
anomalo e deve essere riavviato. Se si verifica questo problema, vedere la sezione
Errore: una sessione remota potrebbe essere terminata per istruzioni alternative.

3. Copiare un file nella macchina virtuale.

 Per eseguire la copia C:\host_path\[Link] nella macchina virtuale dal computer host,
eseguire:

PowerShell
Copy-Item -ToSession $s -Path C:\host_path\[Link] -Destination C:\guest_path\

4. Copiare un file dalla macchina virtuale (nell'host).

Per copiare C:\guest_path\[Link] nell'host dalla macchina virtuale, eseguire:

PowerShell
Copy-Item -FromSession $s -Path C:\guest_path\[Link] -Destination
C:\host_path\

5. Arrestare la sessione persistente usando Remove-PSSession .

PowerShell

Remove-PSSession $s

Risoluzione dei problemi

PowerShell Direct visualizza un piccolo set di messaggi di errore comuni. Le sezioni seguenti
descrivono i messaggi di errore più comuni, alcune cause e strumenti per la diagnosi dei
problemi.

-VMName o parametri -VMID non esistono

Problema:

Enter-PSSession , Invoke-Command o New-PSSession non hanno un -VMName parametro o -VMId .

Possibili cause:

Il problema più probabile è che il sistema operativo host non supporta PowerShell Direct.

È possibile controllare la compilazione di Windows eseguendo il comando seguente:

PowerShell

[[Link]]::[Link]
Se si esegue una build supportata, è anche possibile che la versione di PowerShell non supporti
PowerShell Direct. Per PowerShell Direct e JEA, la versione principale deve essere 5 o
successiva.

È possibile controllare la build della versione di PowerShell eseguendo il comando seguente:

PowerShell
$[Link]

Errore: una sessione remota potrebbe essere terminata

７ Nota

Per Enter-PSSession tra le build host 10240 e 12400, tutti gli errori segnalano come "Una
sessione remota potrebbe essere terminata".

Messaggio di errore:

Enter-PSSession: si è verificato un errore che windows PowerShell non può gestire. Potrebbe
essere stata terminata una sessione remota.

Possibili cause:

La macchina virtuale esiste ma non è in esecuzione.

Il sistema operativo guest non supporta PowerShell Direct. Vedere i requisiti.
PowerShell non è ancora disponibile nel guest
L'avvio del sistema operativo non è terminato
Il sistema operativo non può essere avviato correttamente
Per alcuni eventi di avvio è necessario l'input dell'utente

Usare il cmdlet Get-VM per verificare quali macchine virtuali sono in esecuzione nell'host.

Messaggio di errore:

New-PSSession: si è verificato un errore che windows PowerShell non può gestire. Potrebbe
essere stata terminata una sessione remota.

Possibili cause:

Uno dei motivi elencati in precedenza - tutti si applicano a New-PSSession

Bug nelle build correnti in cui è necessario passare in modo esplicito le credenziali con -
Credential . Quando si verifica questo bug, l'intero servizio si blocca nel sistema operativo
 guest e deve essere riavviato. È possibile verificare se la sessione è ancora disponibile con
Enter-PSSession.

Per risolvere il problema delle credenziali, accedere alla macchina virtuale usando VMConnect,
aprire PowerShell e riavviare il servizio vmicvmsession con il comando di PowerShell seguente:

PowerShell
Restart-Service -Name vmicvmsession

Errore: Impossibile risolvere il set di parametri

Messaggio di errore:

Enter-PSSession : l'insieme di parametri non può essere risolto usando i parametri denominati
specificati.

Possibili cause:

Non è possibile usare -RunAsAdministrator per la connessione alle macchine virtuali.

Quando ci si connette a un contenitore di Windows, il -RunAsAdministrator flag consente

connessioni di amministratore senza credenziali esplicite. Poiché le macchine virtuali non
forniscono l'accesso implicito all'amministratore host, è necessario immettere in modo
esplicito le credenziali.

È possibile passare le credenziali di amministratore alla macchina virtuale con il -Credential

parametro o immettendole manualmente quando richiesto.

Errore: La credenziale non è valida

Messaggio di errore:

Enter-PSSession: le credenziali non sono valide.

Possibili cause:

Non è stato possibile convalidare le credenziali guest

Le credenziali specificate non sono corrette.
Non sono presenti account utente nel guest (il sistema operativo non è stato avviato
prima)
Se ci si connette come amministratore: l'amministratore non è impostato come utente
attivo. Per altre informazioni, vedere Abilitare e disabilitare l'account amministratore
predefinito.
Errore: il parametro VMName di input non viene risolto in
alcuna macchina virtuale.
Messaggio di errore:

Enter-PSSession: il parametro VMName inserito non corrisponde a nessuna macchina virtuale.

Possibili cause:

Non si è un amministratore Hyper-V.

La macchina virtuale non esiste.

Usare il cmdlet Get-VM per verificare che le credenziali usate abbiano il ruolo di
amministratore Hyper-V e per verificare quali macchine virtuali sono in esecuzione localmente
nell'host e avviare.

Esempi e guide utente

PowerShell Direct supporta Just Enough Administration (JEA).

Vedere gli esempi in GitHub .

Last updated on 28/10/2025

Creare una raccolta di macchine virtuali
personalizzata
14/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Windows 10 Fall Creators Update e versioni successive.

In Fall Creators Update, Creazione rapida espansa per includere una raccolta di macchine
virtuali.

Anche se è disponibile un set di immagini fornite dai partner Microsoft e Microsoft, la raccolta
può anche elencare le proprie immagini.

Questo articolo illustra in dettaglio:

creazione di macchine virtuali compatibili con la raccolta.

creazione di una nuova origine della raccolta.
aggiunta dell'origine della raccolta personalizzata alla raccolta.

Architettura della raccolta

La raccolta di macchine virtuali è una visualizzazione grafica per un set di origini di macchine
virtuali definite nel Registro di sistema di Windows. Ogni origine macchina virtuale è un
percorso (percorso locale o URI) in un file JSON con macchine virtuali come elementi di elenco.

L'elenco delle macchine virtuali visualizzate nella raccolta è il contenuto completo della prima
origine, seguito dal contenuto della seconda origine, così via e così via fino a quando non sono
state elencate tutte le macchine virtuali disponibili. L'elenco viene creato dinamicamente ogni
volta che si avvia la raccolta.

Chiave del Registro di sistema: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows

NT\CurrentVersion\Virtualization

Nome valore: GalleryLocations

Digitare: REG_MULTI_SZ

Creare macchine virtuali compatibili con la raccolta

Le macchine virtuali nella raccolta possono essere un'immagine del disco (.iso) o un disco
rigido virtuale (con estensione vhdx).

Le macchine virtuali eseguite da un disco rigido virtuale hanno alcuni requisiti di

configurazione:

1. Progettato per supportare il firmware UEFI. Se vengono creati usando Hyper-V, si tratta di
una macchina virtuale di seconda generazione.
2. Il disco rigido virtuale deve essere di almeno 20 GB, tenendo presente che è la
dimensione massima. Hyper-V non occupa spazio per la macchina virtuale non viene
usata attivamente.
Test di una nuova immagine di macchina virtuale
La raccolta di macchine virtuali crea macchine virtuali usando lo stesso meccanismo
dell'installazione da un'origine di installazione locale.

Per convalidare l'avvio e l'esecuzione di un'immagine di macchina virtuale:

1. Aprire la raccolta di macchine virtuali (Hyper-V Creazione rapida) e selezionare Origine

installazione locale.

2. Selezionare Cambia origine installazione.

3. Selezionare il .iso o vhdx che verrà usato nella raccolta.

 4. Se l'immagine è un'immagine Linux, deselezionare l'opzione Avvio protetto.

5. Creare una macchina virtuale. Se la macchina virtuale viene avviata correttamente, è

pronta per la raccolta.

Creare una nuova origine della raccolta

Il passaggio successivo consiste nel creare una nuova origine della raccolta. Si tratta del file
JSON che elenca le macchine virtuali e aggiunge tutte le informazioni aggiuntive visualizzate
nella raccolta.

Informazioni sul testo:

 name : obbligatorio: si tratta del nome visualizzato nella colonna sinistra e anche nella
parte superiore della visualizzazione macchina virtuale.

publisher : obbligatorio

description : obbligatorio: elenco di stringhe che descrivono la macchina virtuale.

version : obbligatorio

lastUpdated: il valore predefinito è lunedì 1 gennaio 0001.

Il formato deve essere: aaaa-mm-ggThh:mm:ssZ

Il comando di PowerShell seguente fornirà la data odierna nel formato corretto e la

inserisce negli Appunti:

PowerShell

Get-Date -UFormat "%Y-%m-%dT%TZ" | [Link]

impostazioni locali: il valore predefinito è vuoto.

Immagini:
 logo - obbligatorio
simbolo
miniatura

Naturalmente, la macchina virtuale (.iso o vhdx).

Per generare gli hash, è possibile usare il comando powershell seguente:

PowerShell

Get-FileHash -Path .\[Link] -Algorithm SHA256

Il modello JSON seguente include elementi iniziali e lo schema della raccolta. Se lo si modifica
in VSCode, verrà fornito automaticamente IntelliSense.

JSON

{
"$schema": "[Link]
Documentation/live/hyperv-tools/vmgallery/[Link]",

"images": [
{
"name": "",
"version": "",
"locale": "",
"publisher": "",
"lastUpdated": "",
"description": [
 ""
],
"disk": {
"uri": "",
"hash": ""
},
"logo": {
"uri": "",
"hash": ""
},
"symbol": {
"uri": "",
"hash": ""
},
"thumbnail": {
"uri": "",
"hash": ""
}
}
]
}

Connettere la raccolta all'interfaccia utente della

raccolta di macchine virtuali
Il modo più semplice per aggiungere l'origine della raccolta personalizzata alla raccolta di
macchine virtuali consiste nell'aggiungerla in regedit.

1. Aprire [Link]

2. Passare a Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Virtualization\

3. Cercare l'elemento GalleryLocations .

Se esiste già, passare al menu Modifica e modificare.

Se non esiste già, passare al menu Modifica , passare a Nuovo a Valore multistrido

4. Aggiungere la raccolta alla chiave del GalleryLocations Registro di sistema.

Risoluzione dei problemi

Verificare la presenza di errori durante il caricamento della

raccolta
La raccolta di macchine virtuali fornisce la segnalazione errori nel Visualizzatore eventi di
Windows. Per verificare la presenza di errori:

1. Aprire il Visualizzatore eventi

2. Passare a Log di Windows ->Applicazione
3. Cercare gli eventi da Macchina virtuale di origineCrea.

Risorse
Nel collegamento a GitHub sono disponibili alcuni script e helper della raccolta.

Vedere una voce della raccolta di esempio qui . Si tratta del file JSON che definisce la raccolta
in-box.
Hyper-V Module

This reference provides cmdlet descriptions and syntax for all Hyper-V-specific cmdlets. It lists
the cmdlets in alphabetical order based on the verb at the beginning of the cmdlet.

Hyper-V Cmdlets
ﾉ Espandi la tabella

Cmdlet Description

Add-VMAssignableDevice Adds an assignable device to a specific virtual machine.

Add-VMDvdDrive Adds a DVD drive to a virtual machine.

Add-VMFibreChannelHba Adds a virtual Fibre Channel host bus adapter to a virtual

machine.

Add-VMGpuPartitionAdapter Adds a GPU partition adapter to a virtual machine.

Add-VMGroupMember Adds group members to a virtual machine group.

Add-VMHardDiskDrive Adds a hard disk drive to a virtual machine.

Add-VMHostAssignableDevice Adds an assignable device to a virtual machine (VM) host.

Add-VMMigrationNetwork Adds a network for virtual machine migration on one or

more virtual machine hosts.

Add-VMNetworkAdapter Adds a virtual network adapter to a virtual machine.

Add-VMNetworkAdapterAcl Creates an ACL to apply to the traffic through a virtual

machine network adapter.

Add-VMNetworkAdapterExtendedAcl Creates an extended ACL for a virtual network adapter.

Add- Adds a routing domain and virtual subnets to a virtual

VMNetworkAdapterRoutingDomainMapping network adapter.

Add-VMRemoteFx3dVideoAdapter Adds a RemoteFX video adapter in a virtual machine.

Add-VMScsiController Adds a SCSI controller in a virtual machine.

Add-VMStoragePath Adds a path to a storage resource pool.

Add-VMSwitch Adds a virtual switch to an Ethernet resource pool.

Add-VMSwitchExtensionPortFeature Adds a feature to a virtual network adapter.

Cmdlet Description

Add-VMSwitchExtensionSwitchFeature Adds a feature to a virtual switch.

Add-VMSwitchTeamMember Adds members to a virtual switch team.

Checkpoint-VM Creates a checkpoint of a virtual machine.

Compare-VM Compares a virtual machine and a virtual machine host

for compatibility, returning a compatibility report.

Complete-VMFailover Completes a virtual machine's failover process on the

Replica server. Removes all recovery points on a failed
over virtual machine.

Connect-VMNetworkAdapter Connects a virtual network adapter to a virtual switch.

Connect-VMSan Associates a host bus adapter with a virtual storage area

network (SAN).

Convert-VHD Converts the format, version type, and block size of a

virtual hard disk file.

Copy-VMFile Copies a file to a virtual machine.

Debug-VM Debugs a virtual machine.

Disable-VMConsoleSupport Disables keyboard, video, and mouse for a generation 2

virtual machine.

Disable-VMEventing Disables virtual machine eventing.

Disable-VMIntegrationService Disables an integration service on a virtual machine.

Disable-VMMigration Disables migration on one or more virtual machine hosts.

Disable-VMRemoteFXPhysicalVideoAdapter Disables one or more RemoteFX physical video adapters

from use with RemoteFX-enabled virtual machines.

Disable-VMResourceMetering Disables collection of resource utilization data for a virtual

machine or resource pool.

Disable-VMSwitchExtension Disables one or more extensions on one or more virtual

switches.

Disable-VMTPM Disables TPM functionality on a virtual machine.

Disconnect-VMNetworkAdapter Disconnects a virtual network adapter from a virtual

switch or Ethernet resource pool.

Disconnect-VMSan Removes a host bus adapter from a virtual storage area

network (SAN).
Cmdlet Description

Dismount-VHD Dismounts a virtual hard disk.

Dismount-VMHostAssignableDevice Dismounts a device from a virtual machine (VM) host.

Enable-VMConsoleSupport Enables keyboard, video, and mouse for virtual machines.

Enable-VMEventing Enables virtual machine eventing.

Enable-VMIntegrationService Enables an integration service on a virtual machine.

Enable-VMMigration Enables migration on one or more virtual machine hosts.

Enable-VMRemoteFXPhysicalVideoAdapter Enables one or more RemoteFX physical video adapters

for use with RemoteFX-enabled virtual machines.

Enable-VMReplication Enables replication of a virtual machine.

Enable-VMResourceMetering Collects resource utilization data for a virtual machine or

resource pool.

Enable-VMSwitchExtension Enables one or more extensions on one or more switches.

Enable-VMTPM Enables TPM functionality on a virtual machine.

Export-VM Exports a virtual machine to disk.

Export-VMSnapshot Exports a virtual machine checkpoint to disk.

Get-VHD Gets the virtual hard disk object associated with a virtual
hard disk.

Get-VHDSet Gets information about a VHD set.

Get-VHDSnapshot Gets information about a checkpoint in a VHD set.

Get-VM Gets the virtual machines from one or more Hyper-V

hosts.

Get-VMAssignableDevice Retrieves information about the assignable device from a

specific virtual machine.

Get-VMBios Gets the BIOS of a virtual machine or snapshot.

Get-VMComPort Gets the COM ports of a virtual machine or snapshot.

Get-VMConnectAccess Gets entries showing users and the virtual machines to

which they can connect on one or more Hyper-V hosts.

Get-VMDvdDrive Gets the DVD drives attached to a virtual machine or

snapshot.
Cmdlet Description

Get-VMFibreChannelHba Gets the Fibre Channel host bus adapters associated with
one or more virtual machines.

Get-VMFirmware Gets the firmware configuration of a virtual machine.

Get-VMFloppyDiskDrive Gets the floppy disk drives of a virtual machine or

snapshot.

Get-VMGpuPartitionAdapter Gets the information of assigned GPU partitions to a

virtual machine.

Get-VMGroup Gets virtual machine groups.

Get-VMHardDiskDrive Gets the virtual hard disk drives attached to one or more
virtual machines.

Get-VMHost Gets a Hyper-V host.

Get-VMHostAssignableDevice Retrieves device information assigned to a virtual machine

(VM) host.

Get-VMHostCluster Gets virtual machine host clusters.

Get-VMHostNumaNode Gets the NUMA topology of a virtual machine host.

Get-VMHostNumaNodeStatus Gets the status of the virtual machines on the non-

uniform memory access (NUMA) nodes of a virtual
machine host or hosts.

Get-VMHostPartitionableGpu Gets the host machine’s partitionable GPU.

Get-VMHostSupportedVersion Returns a list of virtual machine configuration versions

that are supported on a host.

Get-VMIdeController Gets the IDE controllers of a virtual machine or snapshot.

Get-VMIntegrationService Gets the integration services of a virtual machine or

snapshot.

Get-VMKeyProtector Retrieves a key protector for a virtual machine.

Get-VMMemory Gets the memory of a virtual machine or snapshot.

Get-VMMigrationNetwork Gets the networks added for migration to one or more

virtual machine hosts.

Get-VMNetworkAdapter Gets the virtual network adapters of a virtual machine,

snapshot, management operating system, or of a virtual
machine and management operating system.
Cmdlet Description

Get-VMNetworkAdapterAcl Gets the ACLs configured for a virtual machine network

adapter.

Get-VMNetworkAdapterExtendedAcl Gets extended ACLs configured for a virtual network

adapter.

Get- Gets the IP address of a virtual network adapter

VMNetworkAdapterFailoverConfiguration configured to be used when a virtual machine fails over.

Get-VMNetworkAdapterIsolation Gets isolation settings for a virtual network adapter.

Get- Gets members of a routing domain.

VMNetworkAdapterRoutingDomainMapping

Get-VMNetworkAdapterTeamMapping

Get-VMNetworkAdapterVlan Gets the virtual LAN settings configured on a virtual

network adapter.

Get-VMProcessor Gets the processor of a virtual machine or snapshot.

Get-VMRemoteFx3dVideoAdapter Gets the RemoteFX video adapter of a virtual machine or

snapshot.

Get-VMRemoteFXPhysicalVideoAdapter Gets the RemoteFX physical graphics adapters on one or

more Hyper-V hosts.

Get-VMReplication Gets the replication settings for a virtual machine.

Get-VMReplicationAuthorizationEntry Gets the authorization entries of a Replica server.

Get-VMReplicationServer Gets the replication and authentication settings of a

Replica server.

Get-VMResourcePool Gets the resource pools on one or more virtual machine

hosts.

Get-VMSan Gets the available virtual machine storage area networks

on a Hyper-V host or hosts.

Get-VMScsiController Gets the SCSI controllers of a virtual machine or snapshot.

Get-VMSecurity Gets security information about a virtual machine.

Get-VMSnapshot Gets the checkpoints associated with a virtual machine or

checkpoint.

Get-VMStoragePath Gets the storage paths in a storage resource pool.

Get-VMSwitch Gets virtual switches from one or more virtual Hyper-V

Cmdlet Description

hosts.

Get-VMSwitchExtension Gets the extensions on one or more virtual switches.

Get-VMSwitchExtensionPortData Retrieves the status of a virtual switch extension feature

applied to a virtual network adapter.

Get-VMSwitchExtensionPortFeature Gets the features configured on a virtual network adapter.

Get-VMSwitchExtensionSwitchData Gets the status of a virtual switch extension feature

applied on a virtual switch.

Get-VMSwitchExtensionSwitchFeature Gets the features configured on a virtual switch.

Get-VMSwitchTeam Gets virtual switch teams from Hyper-V hosts.

Get-VMSystemSwitchExtension Gets the switch extensions installed on a virtual machine

host.

Get-VMSystemSwitchExtensionPortFeature Gets the port-level features supported by virtual switch

extensions on one or more Hyper-V hosts.

Get-VMSystemSwitchExtensionSwitchFeature Gets the switch-level features on one or more Hyper-V

hosts.

Get-VMVideo Gets video settings for virtual machines.

Grant-VMConnectAccess Grants a user or users access to connect to a virtual

machine or machines.

Import-VM Imports a virtual machine from a file.

Import-VMInitialReplication Imports initial replication files for a Replica virtual

machine to complete the initial replication when using
external media as the source.

Measure-VM Reports resource utilization data for one or more virtual

machines.

Measure-VMReplication Gets replication statistics and information associated with

a virtual machine.

Measure-VMResourcePool Reports resource utilization data for one or more resource

pools.

Merge-VHD Merges virtual hard disks.

Mount-VHD Mounts one or more virtual hard disks.

Mount-VMHostAssignableDevice Mounts a device to a virtual machine (VM) host.

Cmdlet Description

Move-VM Moves a virtual machine to a new Hyper-V host.

Move-VMStorage Moves the storage of a virtual machine.

New-VFD Creates a virtual floppy disk.

New-VHD Creates one or more new virtual hard disks.

New-VM Creates a new virtual machine.

New-VMGroup Creates a virtual machine group.

With Hyper-V, there are two types of VMGroups: a

VMCollectionType and a ManagementCollectionType. A
VMCollectionType VMGroup contains VMs while the
ManagementCollectionType VMGroup contains
VMCollectionType VMGroups. For example, you could
have two VMCollectionType VMGroups VMG1 (containing
VMs VM1 and VM2) and a second VMG2 (containing VMs
VM3 and VM4). You could then create a
ManagementCollectionType VMGroup VM-All containing
the two VMCollectionType VMGroups. You use the Add-
VMGroupMember cmdlet to add VMs to
VMCollectionType VMGroups and to add
VMCollectionType groups to ManagementCollectionType
VMGroups.

New-VMReplicationAuthorizationEntry Creates a new authorization entry that allows one or more

primary servers to replicate data to a specified Replica
server.

New-VMResourcePool Creates a resource pool.

New-VMSan Creates a new virtual storage area network (SAN) on a

Hyper-V host.

New-VMSwitch Creates a new virtual switch on one or more virtual

machine hosts.

Optimize-VHD Optimizes the allocation of space used by virtual hard disk

files, except for fixed virtual hard disks.

Optimize-VHDSet Optimizes VHD set files.

Remove-VHDSnapshot Removes a checkpoint from a VHD set file.

Remove-VM Deletes a virtual machine.

Remove-VMAssignableDevice Removes information about the assignable devices from a

specific virtual machine.
Cmdlet Description

Remove-VMDvdDrive Deletes a DVD drive from a virtual machine.

Remove-VMFibreChannelHba Removes a Fibre Channel host bus adapter from a virtual

machine.

Remove-VMGpuPartitionAdapter Removes an assigned GPU partition from a virtual

machine.

Remove-VMGroup Removes a virtual machine group.

Remove-VMGroupMember Removes members from a virtual machine group.

Remove-VMHardDiskDrive Deletes a hard disk drive from a virtual machine.

Remove-VMHostAssignableDevice Removes a device assigned to a virtual machine (VM)

host.

Remove-VMMigrationNetwork Removes a network from use with migration.

Remove-VMNetworkAdapter Removes one or more virtual network adapters from a

virtual machine.

Remove-VMNetworkAdapterAcl Removes an ACL applied to the traffic through a virtual

network adapter.

Remove-VMNetworkAdapterExtendedAcl Removes an extended ACL for a virtual network adapter.

Remove- Removes a routing domain from a virtual network

VMNetworkAdapterRoutingDomainMapping adapter.

Remove-VMNetworkAdapterTeamMapping

Remove-VMRemoteFx3dVideoAdapter Removes a RemoteFX 3D video adapter from a virtual

machine.

Remove-VMReplication Removes the replication relationship of a virtual machine.

Remove-VMReplicationAuthorizationEntry Removes an authorization entry from a Replica server.

Remove-VMResourcePool Deletes a resource pool from one or more virtual machine

hosts.

Remove-VMSan Removes a virtual storage area network (SAN) from a

Hyper-V host.

Remove-VMSavedState Deletes the saved state of a saved virtual machine.

Remove-VMScsiController Removes a SCSI controller from a virtual machine.

Remove-VMSnapshot Deletes a virtual machine checkpoint.

Cmdlet Description

Remove-VMStoragePath Removes a path from a storage resource pool.

Remove-VMSwitch Deletes a virtual switch.

Remove-VMSwitchExtensionPortFeature Removes a feature from a virtual network adapter.

Remove-VMSwitchExtensionSwitchFeature Removes a feature from a virtual switch.

Remove-VMSwitchTeamMember Removes a member from a virtual machine switch team.

Rename-VM Renames a virtual machine.

Rename-VMGroup Renames virtual machine groups.

Rename-VMNetworkAdapter Renames a virtual network adapter on a virtual machine

or on the management operating system.

Rename-VMResourcePool Renames a resource pool on one or more Hyper-V hosts.

Rename-VMSan Renames a virtual storage area network (SAN).

Rename-VMSnapshot Renames a virtual machine checkpoint.

Rename-VMSwitch Renames a virtual switch.

Repair-VM Repairs one or more virtual machines.

Reset-VMReplicationStatistics Resets the replication statistics of a virtual machine.

Reset-VMResourceMetering Resets the resource utilization data collected by Hyper-V

resource metering.

Resize-VHD Resizes a virtual hard disk.

Restart-VM Restarts a virtual machine.

Restore-VMSnapshot Restores a virtual machine checkpoint.

Resume-VM Resumes a suspended (paused) virtual machine.

Resume-VMReplication Resumes a virtual machine replication that is in a state of

Paused, Error, Resynchronization Required, or Suspended.

Revoke-VMConnectAccess Revokes access for one or more users to connect to a one

or more virtual machines.

Save-VM Saves a virtual machine.

Set-VHD Sets properties associated with a virtual hard disk.

Set-VM Configures a virtual machine.

Cmdlet Description

Set-VMBios Configures the BIOS of a Generation 1 virtual machine.

Set-VMComPort Configures the COM port of a virtual machine.

Set-VMDvdDrive Configures a virtual DVD drive.

Set-VMFibreChannelHba Configures a Fibre Channel host bus adapter on a virtual

machine.

Set-VMFirmware Sets the firmware configuration of a virtual machine.

Set-VMFloppyDiskDrive Configures a virtual floppy disk drive.

Set-VMGpuPartitionAdapter Assigns a partition of a GPU to a virtual machine.

Set-VMHardDiskDrive Configures a virtual hard disk.

Set-VMHost Configures a Hyper-V host.

Set-VMHostCluster Configures a virtual machine host cluster.

Set-VMHostPartitionableGpu Configures the host partitionable GPU to the number of

partitions supported by the manufacturer.

Set-VMKeyProtector Configures a key protector for a virtual machine.

Set-VMMemory Configures the memory of a virtual machine.

Set-VMMigrationNetwork Sets the subnet, subnet mask, and/or priority of a

migration network.

Set-VMNetworkAdapter Configures features of the virtual network adapter in a

virtual machine or the management operating system.

Set- Configures the IP address of a virtual network adapter to

VMNetworkAdapterFailoverConfiguration be used when a virtual machine fails over.

Set-VMNetworkAdapterIsolation Modifies isolation settings for a virtual network adapter.

Set- Sets virtual subnets on a routing domain.

VMNetworkAdapterRoutingDomainMapping

Set-VMNetworkAdapterTeamMapping

Set-VMNetworkAdapterVlan Configures the virtual LAN settings for the traffic through
a virtual network adapter.

Set-VMProcessor Configures settings for the virtual processors of a virtual

machine. Settings are applied uniformly to all virtual
processors belonging to the virtual machine.
Cmdlet Description

Set-VMRemoteFx3dVideoAdapter Configures the RemoteFX 3D video adapter of a virtual

machine.

Set-VMReplication Modifies the replication settings of a virtual machine.

Set-VMReplicationAuthorizationEntry Modifies an authorization entry on a Replica server.

Set-VMReplicationServer Configures a host as a Replica server.

Set-VMResourcePool Sets the parent resource pool for a selected resource

pool.

Set-VMSan Configures a virtual storage area network (SAN) on one or

more Hyper-V hosts.

Set-VMSecurity Configures security settings for a virtual machine.

Set-VMSecurityPolicy Configures the security policy for a virtual machine.

Set-VMSwitch Configures a virtual switch.

Set-VMSwitchExtensionPortFeature Configures a feature on a virtual network adapter.

Set-VMSwitchExtensionSwitchFeature Configures a feature on a virtual switch.

Set-VMSwitchTeam Configures a virtual switch team.

Set-VMVideo Configures video settings for virtual machines.

Start-VM Starts a virtual machine.

Start-VMFailover Starts failover on a virtual machine.

Start-VMInitialReplication Starts replication of a virtual machine.

Start-VMTrace Starts tracing to a file.

Stop-VM Shuts down, turns off, or saves a virtual machine.

Stop-VMFailover Stops failover of a virtual machine.

Stop-VMInitialReplication Stops an ongoing initial replication.

Stop-VMReplication Cancels an ongoing virtual machine resynchronization.

Stop-VMTrace Stops tracing to file.

Suspend-VM Suspends, or pauses, a virtual machine.

Suspend-VMReplication Suspends replication of a virtual machine.

Cmdlet Description

Test-VHD Tests a virtual hard disk for any problems that would
make it unusable.

Test-VMNetworkAdapter Tests connectivity between virtual machines.

Test-VMReplicationConnection Tests the connection between a primary server and a

Replica server.

Update-VMVersion Updates the version of virtual machines.

Hyper-V documentazione sulle API e sulle
specifiche
Documentazione per la specifica funzionale di primo livello e le API per Hyper-V per gli
sviluppatori.

Hyper-V specifica funzionale di primo livello

ｅ PANORAMICA

Panoramica delle specifiche funzionali di primo livello

ｉ RIFERIMENTO

Tipi di dati

Individuazione delle funzionalità

Hypercalls

Partitions

Processore virtuale

ｉ RIFERIMENTO

Unità di gestione della memoria virtuale

Controller di interrupt virtuale

comunicazione Inter-Partition

Timers

Modalità protetta virtuale

Virtualizzazione annidata

API Hyper-V

ｅ PANORAMICA

Panoramica dell'API

ｉ RIFERIMENTO
Hyper-V provider WMI

Informazioni di riferimento sulla gestione

API del sistema di calcolo host

API di rete di calcolo host

Definizioni dell'API della piattaforma Hypervisor di Windows

Interfaccia del disco rigido virtuale

API dell'emulatore di istruzioni hypervisor

API del provider di dump salvato dalla macchina virtuale

Hyper-V documentazione del prodotto

ｅ PANORAMICA

Hyper-V documentazione

Informazioni generali
gestione Hyper-V
Qui viene descritto come gestire o ottenere informazioni sulle macchine virtuali.

In questa sezione
ﾉ Espandi la tabella

Argomento Descrizione

Informazioni sulla gestione Hyper- Questa sezione contiene informazioni per la gestione di Hyper-V.
V

di riferimento per la gestione Questa sezione contiene le informazioni di riferimento per la

diHyper-V gestione di Hyper-V.

Last updated on 13/03/2025

Hyper-V provider WMI (V2)

Scopo
Hyper-V offre un ambiente di elaborazione server virtualizzato scalabile, affidabile e a
disponibilità elevata. Consente l'esecuzione simultanea di uno o più sistemi operativi guest in
un singolo computer fisico. I principali usi per la tecnologia delle macchine virtuali includono
quanto segue:

Consolidamento dei server

Consolidamento degli ambienti di sviluppo e test
Ripristino di emergenza semplificato

In questa sezione
ﾉ Espandi la tabella

Argomento Descrizione

Informazioni sul provider Il provider WMI per Hyper-V consente agli sviluppatori e agli scripter di
WMI Hyper-V creare rapidamente strumenti personalizzati, utilità e miglioramenti per la
piattaforma di virtualizzazione. Le interfacce WMI possono gestire tutti gli
aspetti dei servizi Hyper-V.

Uso del provider WMI Negli argomenti seguenti viene descritto come usare il provider WMI
Hyper-V Hyper-V.

Hyper-V classi WMI Di seguito sono riportate le classi WMI Hyper-V.

Hyper-V'API di L'API di monitoraggio dell'integrità delle applicazioni Hyper-V viene usata

monitoraggio dell'integrità per monitorare lo stato di integrità delle applicazioni in esecuzione in una
delle applicazioni macchina virtuale.

Hyper-V api di replica L'API di replica Hyper-V viene usata per controllare la replica delle macchine
virtuali e il ripristino del failover.

API Hyper-V metriche L'API delle metriche Hyper-V viene usata per monitorare lo stato di integrità
delle applicazioni in esecuzione in una macchina virtuale.

Hyper-V api di rete L'API di rete Hyper-V viene usata per controllare la rete in Hyper-V.

Hyper-V'API di migrazione L'API di migrazione Hyper-V viene usata per controllare l'archiviazione e la
migrazione in tempo reale in Hyper-V.

Hyper-V'API Fibre Channel L'API Fibre Channel virtuale Hyper-V viene usata per controllare le schede
virtuale Fibre Channel virtuali in Hyper-V.
 Argomento Descrizione

Hyper-V API di L'API di posizionamento della macchina virtuale (VM) Hyper-V contiene le
posizionamento delle informazioni di compatibilità per le macchine virtuali o il sistema del
macchine virtuali computer di hosting.

classi soglia Contiene le classi introdotte in Windows 10.

classi RS2 Contiene le nuove classi per Windows 10 versione 1703.

classi RS3 Contiene le nuove classi per Windows 10 versione 1709.

Hyper-V glossario Glossario dei termini usati nella documentazione di Windows Virtualization
SDK.

Requisiti di runtime
Hyper-V servizi richiedono un sistema basato su x64 che supporta la virtualizzazione assistita
da hardware che esegue Hyper-V. I programmi che interagiscono con le interfacce WMI Hyper-
V possono tuttavia essere eseguiti in remoto in qualsiasi sistema che supporta WMI.

Argomenti correlati
Hyper-V (Libreria tecnica di Windows Server 2008 R2)

strumentazione gestione Windows

Windows Server Virtualization

Last updated on 13/03/2025

Creare servizi di integrazione personalizzati
15/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

A partire dall'aggiornamento dell'anniversario di Windows 10, chiunque può creare

applicazioni che comunicano tra l'host Hyper-V e le relative macchine virtuali usando Hyper-V
socket, ovvero un Windows Socket con una nuova famiglia di indirizzi e un endpoint
specializzato per la destinazione delle macchine virtuali. Tutte le comunicazioni su Hyper-V
socket vengono eseguite senza usare la rete e tutti i dati rimangono nella stessa memoria
fisica. Le applicazioni che usano Hyper-V socket sono simili ai servizi di integrazione di Hyper-
V.

Questo documento illustra la creazione di un semplice programma basato su socket Hyper-V.

Sistema operativo host supportato

Windows 10 e versioni successive
Windows Server 2016 e versioni successive

Sistema operativo guest supportato

Windows 10 e versioni successive
Windows Server 2016 e versioni successive
Guest Linux con Linux Integration Services. Vedere Macchine virtuali Linux e FreeBSD
supportate per Hyper-V in Windows

７ Nota

Un guest Linux supportato deve avere il supporto del kernel per:

Bash

CONFIG_VSOCKET=y
CONFIG_HYPERV_VSOCKETS=y

Funzionalità e limitazioni
Supporta azioni in modalità kernel o in modalità utente
 Solo flusso di dati
Nessuna memoria a blocchi (non ottimale per il backup/video)

Come iniziare
Requisiti:

Compilatore C/C++. Se non è disponibile, vedere Visual Studio Community

Windows SDK : preinstallato in Visual Studio 2015 con Update 3 e versioni successive.
Un computer che esegue uno dei sistemi operativi host specificati con almeno un
computer vitual. - Questo è per il test dell'applicazione.

Nota: L'API per i socket Hyper-V è diventata disponibile pubblicamente

nell'aggiornamento dell'anniversario di Windows 10. Le applicazioni che usano HVSocket
verranno eseguite in qualsiasi host e guest di Windows 10, ma possono essere sviluppate
solo con Windows SDK successiva alla build 14290.

Registrare una nuova applicazione

Per usare Hyper-V socket, l'applicazione deve essere registrata nel registro dell'host Hyper-V.

Registrando il servizio nel Registro di sistema, si ottiene:

Gestione WMI per abilitare, disabilitare ed elencare i servizi disponibili

Autorizzazione per comunicare direttamente con le macchine virtuali

PowerShell seguente registrerà una nuova applicazione denominata "HV Socket Demo". Deve
essere eseguito come amministratore. Istruzioni manuali riportate di seguito.

PowerShell

$friendlyName = "HV Socket Demo"

# Create a new random GUID. Add it to the services list

$service = New-Item -Path "HKLM:\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Virtualization\GuestCommunicationServices" -Name ((New-
Guid).Guid)

# Set a friendly name

$[Link]("ElementName", $friendlyName)

# Copy GUID to clipboard for later use

$[Link] | [Link]
Percorso e informazioni del Registro di sistema:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Virtualization\GuestCommunicationServices\

In questo percorso del Registro di sistema verranno visualizzati diversi GUID. Questi sono i
nostri servizi in scatola.

Informazioni nel Registro di sistema per servizio:

Service GUID

ElementName (REG_SZ) - questo è il nome descrittivo del servizio

Per registrare il proprio servizio, creare una nuova chiave del Registro di sistema usando il
proprio GUID e il nome descrittivo.

Il nome descrittivo verrà associato alla nuova applicazione. Verrà visualizzato nei contatori delle
prestazioni e in altre posizioni in cui un GUID non è appropriato.

La voce del Registro di sistema è simile alla seguente:

Output

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Virtualization\GuestCommunicationServices\
999E53D4-3D5C-4C3E-8779-BED06EC056E1\
ElementName REG_SZ VM Session Service
YourGUID\
ElementName REG_SZ Your Service Friendly Name

７ Nota

Il GUID del servizio per un guest Linux usa il protocollo VSOCK che punta tramite un
svm_cid e svm_port anziché un GUID. Per colmare questa incoerenza con Windows, il

GUID noto viene usato come modello di servizio nell'host che si traduce in una porta nel
guest. Per personalizzare il GUID del servizio, è sufficiente modificare il primo "00000000"
in base al numero di porta desiderato. Ad esempio: "00000ac9" è la porta 2761.

C++

// Hyper-V Socket Linux guest VSOCK template GUID

struct __declspec(uuid("00000000-facb-11e6-bd58-64006a7986d3"))
VSockTemplate{};
 /*
* GUID example = __uuidof(VSockTemplate);
* example.Data1 = 2761; // 0x00000AC9
*/

Mancia: Per generare un GUID in PowerShell e copiarlo negli Appunti, eseguire:

PowerShell

(New-Guid).Guid | [Link]

Creare un socket Hyper-V

Nel caso più semplice, la definizione di un socket richiede una famiglia di indirizzi, un tipo di
connessione e un protocollo.

Ecco una definizione di socket semplice

// Windows
SOCKET WSAAPI socket(
_In_ int af,
_In_ int type,
_In_ int protocol
);

// Linux guest
int socket(int domain, int type, int protocol);

Per un socket Hyper-V:

Famiglia di indirizzi - AF_HYPERV (Windows) o AF_VSOCK (guest Linux)

digitare- SOCK_STREAM
protocol - HV_PROTOCOL_RAW (Windows) o 0 (guest Linux)

Di seguito è riportato un esempio di dichiarazione/creazione di istanze:

// Windows
SOCKET sock = socket(AF_HYPERV, SOCK_STREAM, HV_PROTOCOL_RAW);

// Linux guest
int sock = socket(AF_VSOCK, SOCK_STREAM, 0);
Eseguire il binding a un socket Hyper-V
Bind associa un socket alle informazioni di connessione.

La definizione della funzione viene copiata di seguito per la convinzione. Per altre informazioni
sull'associazione, vedere qui.

// Windows
int bind(
_In_ SOCKET s,
_In_ const struct sockaddr *name,
_In_ int namelen
);

// Linux guest
int bind(int sockfd, const struct sockaddr *addr,
socklen_t addrlen);

A differenza dell'indirizzo socket (sockaddr) per una famiglia di indirizzi Internet Protocol
standard ( AF_INET ) costituita dall'indirizzo IP del computer host e da un numero di porta in tale
host, l'indirizzo del socket per AF_HYPERV usa l'ID della macchina virtuale e l'ID applicazione
definiti in precedenza per stabilire una connessione. Se l'associazione da un guest AF_VSOCK
Linux usa svm_cid e . svm_port

Poiché Hyper-V socket non dipendono da uno stack di rete, TCP/IP, DNS e così via. L'endpoint
socket richiedeva un formato non IP, non hostname, che descrive comunque in modo non
ambiguo la connessione.

Ecco la definizione per l'indirizzo socket di un socket di Hyper-V:

// Windows
struct SOCKADDR_HV
{
ADDRESS_FAMILY Family;
USHORT Reserved;
GUID VmId;
GUID ServiceId;
};

// Linux guest
// See include/uapi/linux/vm_sockets.h for more information.
struct sockaddr_vm {
__kernel_sa_family_t svm_family;
unsigned short svm_reserved1;
 unsigned int svm_port;
unsigned int svm_cid;
unsigned char svm_zero[sizeof(struct sockaddr) -
sizeof(sa_family_t) -
sizeof(unsigned short) -
sizeof(unsigned int) - sizeof(unsigned int)];
};

Al posto di un IP o di un nome host, AF_HYPERV endpoint si basano principalmente su due

GUID:

ID macchina virtuale: id univoco assegnato per ogni macchina virtuale. L'ID di una
macchina virtuale è reperibile usando il frammento di codice di PowerShell seguente.

PowerShell

(Get-VM -Name $VMName).Id

ID servizio: GUID, descritto in precedenza, con cui l'applicazione viene registrata nel
registro host Hyper-V.

È disponibile anche un set di caratteri jolly VMID quando una connessione non è a una
macchina virtuale specifica.

Caratteri jolly VMID

ﾉ Espandi la tabella

Nome GUID Description

HV_GUID_ZERO 00000000-0000-0000- I listener devono essere associati a questo VMId per

0000-000000000000 accettare la connessione da tutte le partizioni.

HV_GUID_WILDCARD 00000000-0000-0000- I listener devono essere associati a questo VMId per

0000-000000000000 accettare la connessione da tutte le partizioni.

HV_GUID_BROADCAST FFFFFFFF-FFFF-FFFF-
FFFF-FFFFFFFFFFFF

HV_GUID_CHILDREN 90db8b89-0d35-4f79- Indirizzo con caratteri jolly per gli elementi figlio. I
8ce9-49ea0ac8b7cd listener devono essere associati a questo ID vm per
accettare la connessione dai relativi elementi figlio.

HV_GUID_LOOPBACK e0e16197-dd56-4a10- Indirizzo di loopback. L'uso di questo ID vm si

9195-5ee7a155a838 connette alla stessa partizione del connettore.
 Nome GUID Description

HV_GUID_PARENT a42e7cda-d03f-480c- Indirizzo padre. L'uso di questo ID vm si connette alla

9cc2-a4de20abb878 partizione padre del connettore.*

* HV_GUID_PARENT L'elemento padre di una macchina virtuale è il relativo host. L'elemento

padre di un contenitore è l'host del contenitore. La connessione da un contenitore in
esecuzione in una macchina virtuale si connetterà alla macchina virtuale che ospita il
contenitore. L'ascolto su questo VMId accetta la connessione da: (All'interno dei contenitori):
host contenitore. (All'interno della macchina virtuale: host contenitore/ nessun contenitore):
host della macchina virtuale. (Non all'interno della macchina virtuale: host contenitore/ nessun
contenitore): non supportato.

Comandi socket supportati

Socket() Bind() Connect() Send() Listen() Accept()

Opzioni socket HvSocket

ﾉ Espandi la tabella

Nome TIPO Description

HVSOCKET_CONNECTED_SUSPEND ULONG Quando questa opzione socket è impostata su un socket

senza valore zero, non disconnettersi quando la macchina
virtuale viene sospesa.

Collegamenti utili
Completare l'API WinSock

Informazioni di riferimento suHyper-V Integration Services

Scambio di dati: uso di coppie chiave-
valore per condividere informazioni tra
l'host e il guest in Hyper-V
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Scambio di dati è un servizio di integrazione (noto anche come scambio di coppie chiave-
valore o KVP) che può essere usato per condividere piccole informazioni tra una macchina
virtuale (guest) e il relativo host Hyper-V. Le informazioni generali sulla macchina virtuale e
sull'host vengono create e archiviate automaticamente come coppie chiave-valore. È anche
possibile creare coppie personalizzate per condividere dati personalizzati.

Le coppie chiave-valore sono costituite da una "chiave" e da un "valore". Entrambe sono

stringhe; non sono supportati altri tipi di dati. Quando viene creata o modificata una coppia
chiave-valore, diventa visibile sia al guest che all'host. I dati KVP passano attraverso la Hyper-V
VMbus e non richiedono alcuna connettività di rete tra il guest e l'host.

Una volta create, le coppie chiave-valore rimangono fino a quando non vengono eliminate.
Tutte le applicazioni che creano coppie chiave-valore devono eliminarle quando non sono più
necessarie. Le coppie chiave-valore si spostano con la macchina virtuale durante la migrazione
in tempo reale.

Utenti guest di Windows

Nei guest di Windows i dati KVP vengono archiviati nel Registro di sistema in:

text
HKLM\SOFTWARE\Microsoft\Virtual Machine

I dati sono organizzati in queste sottochiavi:

Macchina virtuale\Auto : dati che descrivono il guest. Creato dai driver del servizio di
integrazione dopo il caricamento. Visibile all'host come dati intrinseci.
Macchina virtuale\Esterna – i dati inviati al guest dall'host da un utente.
Macchina virtuale\Ospite – dati creati sull'ospite. Visibile all'host come dati non intrinseci.
Macchina virtuale\Guest\Parameter : dati trasferiti nel guest dall'host che descrivono
l'host.
L'aggiunta di valori dall'interno del guest è facile quanto creare un nuovo valore stringa in
HKLM\SOFTWARE\Microsoft\Virtual Machine\Guest . Per modificare questo percorso, è necessario

essere un amministratore del sistema operativo guest. È possibile usare WMI (PowerShell o altri
strumenti) dall'host o da un computer remoto (con autorizzazioni) per recuperare il valore.

Per informazioni sui limiti delle dimensioni del Registro di sistema, vedere l'articolo (legacy)
Limiti delle dimensioni degli elementi del Registro di sistema .

Aggiungere una nuova coppia chiave-valore nel guest

In questo esempio il valore di Status è impostato su Ready :

PowerShell
$regPath = "HKLM:\SOFTWARE\Microsoft\Virtual Machine\Guest"
Set-ItemProperty -Path $regPath -Name "Status" -Value "Ready" -Type String

È possibile usare la stessa sintassi per modificare il valore.

Eseguire query sulle coppie chiave-valore nel guest

Per interrogare il valore della sottochiave Esterna (dati trasmessi al guest dall'host):

PowerShell

$regPath = "HKLM:\SOFTWARE\Microsoft\Virtual Machine\External"

Get-ItemProperty -Path $regPath -Name "Name"

Ospiti Linux
Linux non dispone di un registro, quindi gli elementi KVP vengono archiviati nel file system. Un
processo daemon, hv_kvp_daemon , deve essere in esecuzione per gestire l'elaborazione. Per la
maggior parte delle distribuzioni con Linux Integration Services (LIS) o driver in kernel installati,
questo daemon viene avviato automaticamente. In alcuni casi, potrebbero essere necessari
passaggi aggiuntivi per installare e avviare il daemon.

I servizi di integrazione Linux implementano lo scambio di dati con i pool KVP. Un pool KVP è
un file archiviato in un percorso specifico. Sono disponibili quattro file del pool:

text
/var/lib/hyperv/.kvp_pool_0
/var/lib/hyperv/.kvp_pool_1
 /var/lib/hyperv/.kvp_pool_2
/var/lib/hyperv/.kvp_pool_3

Questi file del pool vengono mappati ai set di chiavi del Registro di sistema di Windows
seguenti:

Pool 0: Virtual Machine\External

Pool 1: Virtual Machine\Guest
Pool 2: Virtual Machine\Auto
Pool 3: Virtual Machine\Guest\Parameter

７ Nota

Per altre informazioni sul supporto KVP di Linux, vedere Macchine virtuali Linux e
FreeBSD in Hyper-V.

L'infrastruttura della coppia chiave-valore potrebbe non funzionare correttamente senza

un aggiornamento software Linux. Se si verificano problemi, contattare il fornitore di
distribuzione per un aggiornamento.

Struttura del pool

Ogni file del pool contiene record con questa struttura:

struct kvp_record
{
unsigned char key[ HV_KVP_EXCHANGE_MAK_KEY_SIZE ];
unsigned char value[ HV_KVP_EXCHANGE_MAX_VALUE_SIZE ];
};

Tali costanti di dimensioni sono definite in hyperv.h (un'intestazione del kernel distribuita con
le origini del kernel Linux).

Leggere e visualizzare i valori del pool 0

Questo esempio legge i valori KVP dal pool 0 e li visualizza.

A
```c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <fcntl.h>
#include "../include/linux/hyperv.h"

typedef struct kvp_record

{
unsigned char key [HV_KVP_EXCHANGE_MAX_KEY_SIZE];
unsigned char value [HV_KVP_EXCHANGE_MAX_VALUE_SIZE];
} KVP_RECORD;

KVP_RECORD myRecords[200];

void KVPAcquireLock(int fd)

{
struct flock fl = {F_RDLCK, SEEK_SET, 0, 0, 0};
fl.l_pid = getpid();

if (-1 == fcntl(fd, F_SETLKW, &fl))

{
perror("fcntl lock");
exit (-10);
}
}

void KVPReleaseLock(int fd)

{
struct flock fl = {F_UNLCK, SEEK_SET, 0, 0, 0};
fl.l_pid = getpid();

if (-1 == fcntl(fd, F_SETLK, &fl))

{
perror("fcntl unlock");
exit (-20);
}
}

int main (int argc, char **argv)

{
char poolName[] = "/var/lib/hyperv/.kvp_pool_0";
int i;
int fd;
int bytesRead;
int numRecords;

fd = open(poolName, O_RDONLY);
if (-1 == fd)
{
printf("Error: Unable to open pool file %s\n", poolName);
exit (-30);
}

KVPAcquireLock(fd);
bytesRead = read(fd, myRecords, sizeof(myRecords));
 KVPReleaseLock(fd);

numRecords = bytesRead / sizeof(struct kvp_record);

printf("Number of records : %d\n", numRecords);

for (i = 0; i < numRecords; i++)

{
printf(" Key : %s\n Value: %s\n\n", myRecords[i].key,
myRecords[i].value);
}

close(fd);

return 0;
}

Creare un elemento KVP nel pool 1

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <fcntl.h>
#include "../include/linux/hyperv.h"

typedef struct kvp_record

{
unsigned char key [HV_KVP_EXCHANGE_MAX_KEY_SIZE];
unsigned char value [HV_KVP_EXCHANGE_MAX_VALUE_SIZE];
} KVP_RECORD;

void KVPAcquireWriteLock(int fd)

{
struct flock fl = {F_WRLCK, SEEK_SET, 0, 0, 0};
fl.l_pid = getpid();

if (-1 == fcntl(fd, F_SETLKW, &fl))

{
perror("fcntl lock");
exit (-10);
}
}

void KVPReleaseLock(int fd)

{
struct flock fl = {F_UNLCK, SEEK_SET, 0, 0, 0};
fl.l_pid = getpid();

if (-1 == fcntl(fd, F_SETLK, &fl))

{
 perror("fcntl unlock");
exit (-20);
}
}

int main (int argc, char **argv)

{
char poolName[] = "/var/lib/hyperv/.kvp_pool_1";
int fd;
KVP_RECORD newKvp;

if (3 != argc)
{
printf("Usage: WritePool keyName valueString\n\n");
exit (-5);
}

fd = open(poolName, O_WRONLY);
if (-1 == fd)
{
printf("Error: Unable to open pool file %s\n", poolName);
exit (-30);
}

memset((void *)&newKvp, 0, sizeof(KVP_RECORD));

memcpy([Link], argv[1], strlen(argv[1]));
memcpy([Link], argv[2], strlen(argv[2]));

KVPAcquireWriteLock(fd);
write(fd, (void *)&newKvp, sizeof(KVP_RECORD));
KVPReleaseLock(fd);

close(fd);

return 0;
}

Eliminare un elemento KVP dal pool 1

In questo esempio viene eliminato un elemento.

A
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <fcntl.h>
#include <uapi/linux/hyperv.h>

typedef struct kvp_record

{
unsigned char key [HV_KVP_EXCHANGE_MAX_KEY_SIZE];
unsigned char value [HV_KVP_EXCHANGE_MAX_VALUE_SIZE];
} KVP_RECORD;

void KVPAcquireWriteLock(int fd)

{
struct flock fl = {F_WRLCK, SEEK_SET, 0, 0, 0};
fl.l_pid = getpid();

if (-1 == fcntl(fd, F_SETLKW, &fl))

{
perror("fcntl lock");
exit (-10);
}
}

void KVPReleaseLock(int fd)

{
struct flock fl = {F_UNLCK, SEEK_SET, 0, 0, 0};
fl.l_pid = getpid();

if (-1 == fcntl(fd, F_SETLK, &fl))

{
perror("fcntl unlock");
exit (-20);
}
}

int find_record_offset(int fd, char *key)

{
int bytesRead;
int offset = 0;
int retval = -1;

KVP_RECORD kvpRec;

while (1)
{
lseek(fd, offset, SEEK_SET);
bytesRead = read(fd, &kvpRec, sizeof(KVP_RECORD));
if (0 == bytesRead)
{
break;
}

if (0 == strcmp(key, (const char *) [Link]))

{
retval = offset;
break;
}

offset += sizeof(KVP_RECORD);
}
 return retval;
}

int main (int argc, char **argv)

{
char poolName[] = "/var/lib/hyperv/.kvp_pool_1";
int fd;
int exitVal = -1;
int bytesRead;
int bytesWritten;
int offset_to_delete;
int offset_last_record;
KVP_RECORD kvpRec;

if (2 != argc)
{
printf("Usage: WritePool keyName valueString\n\n");
exit (-5);
}

fd = open(poolName, O_RDWR, 0644);

if (-1 == fd)
{
printf("Error: Unable to open pool file %s\n", poolName);
exit (-10);
}

KVPAcquireWriteLock(fd);
offset_to_delete = find_record_offset(fd, argv[1]);
if (offset_to_delete < 0)
{
exitVal = -15;
goto cleanup2;
}

offset_last_record = lseek(fd, -sizeof(KVP_RECORD), SEEK_END);

if (offset_last_record < 0)
{
exitVal = -20;
goto cleanup2;
}

if (offset_last_record != offset_to_delete)
{
lseek(fd, offset_last_record, SEEK_SET);
bytesRead = read(fd, &kvpRec, sizeof(KVP_RECORD));
lseek(fd, offset_to_delete, SEEK_SET);
bytesWritten = write(fd, &kvpRec, sizeof(KVP_RECORD));
}

ftruncate(fd, offset_last_record);

exitVal = 0;

cleanup2:
 KVPReleaseLock(fd);

cleanup1:
close(fd);

return exitVal;
}

Lavorare con coppie di chiavi e valori dall'host

utilizzando WMI
Negli esempi seguenti viene usato lo spazio dei nomi WMI v2. Per WMI v1 (versioni
precedenti), rimuovere il \v2 segmento dal percorso dello spazio dei nomi.

７ Nota

Se utilizzi Windows 8 o Windows 8.1, installa Client Hyper-V per ottenere i namespaces.

Leggere il valore dall'host

Questo esempio ottiene il valore della chiave Status da una macchina virtuale denominata
Vm1 :

PowerShell
$vm = Get-WmiObject -Namespace root\virtualization\v2 -Class \
Msvm_ComputerSystem -Filter {ElementName = 'Vm1'}
$[Link]("Msvm_KvpExchangeComponent").GuestExchangeItems | % { \
$GuestExchangeItemXml = ([XML]$_).SelectSingleNode(\
"/INSTANCE/PROPERTY[@NAME='Name']/VALUE[child::text() = 'Status']")
if ($GuestExchangeItemXml -ne $null)
{
$[Link](\
"/INSTANCE/PROPERTY[@NAME='Data']/VALUE/child::text()" ).Value
}
}

Aggiungi o modifica le coppie chiave-valore dall'host

Per aggiungere una coppia chiave-valore dall'host, accedi alle istanze del servizio di gestione e
della macchina virtuale e crea una nuova istanza di Msvm_KvpExchangeDataItem . Quando si crea
la nuova istanza, specificare Name , Data e Source (deve essere 0 ). Quindi chiamare
AddKvpItems .
L'esecuzione di query per le coppie chiave-valore create dall'host è simile alle query guest, ma
richiede un hop di associazione aggiuntivo a Msvm_KvpExchangeComponentSettingData . La
modifica e l'eliminazione di valori funzionano allo stesso modo: specificare lo stesso nome di
chiave e chiamare il metodo appropriato Modify o Remove .

） Importante

Gli esempi seguenti usano lo spazio dei nomi v2. Se si usa Windows Server 2008 o
Windows Server 2008 R2, rimuovere il \v2 segmento.

Aggiungere una nuova coppia chiave-valore

PowerShell
$VmMgmt = Get-WmiObject -Namespace root\virtualization\v2 -Class \
Msvm_VirtualSystemManagementService
$vm = Get-WmiObject -Namespace root\virtualization\v2 -Class \
Msvm_ComputerSystem -Filter {ElementName='VM1'}
$kvpDataItem = ([WMIClass][String]::Format("\\{0}\\{1}:{2}", \
$[Link], \
$[Link], \
"Msvm_KvpExchangeDataItem")).CreateInstance()

$[Link] = "Name"
$[Link] = "Data"
$[Link] = 0

$[Link]($Vm, $[Link](1))

Eseguire query sulle coppie chiave-valore nell'host

PowerShell
$VmMgmt = Get-WmiObject -Namespace root\virtualization\v2 -Class \
Msvm_VirtualSystemManagementService
$vm = Get-WmiObject -Namespace root\virtualization\v2 -Class \
Msvm_ComputerSystem -Filter {ElementName='VM1'}
($[Link]("Msvm_KvpExchangeComponent")[0]
).GetRelated("Msvm_KvpExchangeComponentSettingData").HostExchangeItems | % { \
$GuestExchangeItemXml = ([XML]$_).SelectSingleNode(\
"/INSTANCE/PROPERTY[@NAME='Name']/VALUE[child::text() = 'Name2']")
if ($GuestExchangeItemXml -ne $null)
{
$[Link](\
"/INSTANCE/PROPERTY[@NAME='Data']/VALUE/child::text()" ).Value
 }
}

Modificare una coppia chiave-valore

PowerShell
$VmMgmt = Get-WmiObject -Namespace root\virtualization\v2 -Class \
Msvm_VirtualSystemManagementService
$vm = Get-WmiObject -Namespace root\virtualization\v2 -Class \
Msvm_ComputerSystem -Filter {ElementName='VM1'}
$kvpDataItem = ([WMIClass][String]::Format("\\{0}\\{1}:{2}", \
$[Link], \
$[Link], \
"Msvm_KvpExchangeDataItem")).CreateInstance()

$[Link] = "Name"
$[Link] = "Data2"
$[Link] = 0

$[Link]($Vm, $[Link](1))

Rimuovere una coppia chiave-valore

PowerShell
$VmMgmt = Get-WmiObject -Namespace root\virtualization\v2 -Class \
Msvm_VirtualSystemManagementService
$vm = Get-WmiObject -Namespace root\virtualization\v2 -Class \
Msvm_ComputerSystem -Filter {ElementName='VM1'}
$kvpDataItem = ([WMIClass][String]::Format("\\{0}\\{1}:{2}", \
$[Link], \
$[Link], \
"Msvm_KvpExchangeDataItem")).CreateInstance()

$[Link] = "Name"
$[Link] = [String]::Empty
$[Link] = 0

$[Link]($Vm, $[Link](1))

Vedere anche
Hyper-V integration services
Linux e FreeBSD macchine virtuali supportate per Hyper-V in Windows
PowerShell Direct
Last updated on 28/10/2025
Passare da Hyper-V WMI v1 a WMI v2
15/08/2025
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local 2311.2 and later

Strumentazione gestione Windows (WMI) è l'interfaccia di gestione sottostante Hyper-V

Manager e i cmdlet di PowerShell di Hyper-V. Anche se la maggior parte delle persone usa i
cmdlet di PowerShell o Hyper-V manager, a volte gli sviluppatori hanno bisogno direttamente
di WMI.

Sono stati presenti due spazi dei nomi WMI Hyper-V (o versioni dell'API WMI Hyper-V).

Spazio dei nomi WMI v1 (root\virtualization) introdotto in Windows Server 2008 e l'ultimo
disponibile in Windows Server 2012
Spazio dei nomi WMI v2 (root\virtualization\v2) introdotto in Windows Server 2012

Questo documento contiene riferimenti alle risorse per la conversione del codice che comunica
con lo spazio dei nomi WMI precedente a quello nuovo. Inizialmente, questo articolo fungerà
da repository per informazioni sull'API e codice/script di esempio che possono essere usati per
convertire eventuali programmi o script che usano Hyper-V API WMI dallo spazio dei nomi v1
allo spazio dei nomi v2.

Esempi MSDN
Esempio di migrazione di macchine virtualiHyper-V
esempio di Fiber Channel virtualeHyper-V
Hyper-V esempio di macchine virtuali pianificate
esempio di monitoraggio dell'integrità dell'applicazioneHyper-V
Esempio di gestione del disco rigido virtuale
esempio di replicaHyper-V
Esempio di metricheHyper-V
Hyper-V esempio di memoria dinamica
Hyper-V driver di filtro dell'estensione Extensible Switch
Esempio di reteHyper-V
Esempio di gestione del pool di risorseHyper-V
Hyper-V esempio di snapshot di ripristino

Esempi da blog
Aggiunta di una scheda di rete a una macchina virtuale tramite lo spazio dei nomi WMI V2
Hyper-V
Connessione di una scheda di rete vm a un commutatore tramite lo spazio dei nomi WMI V2 di
Hyper-V
Modifica dell'indirizzo MAC della scheda di interfaccia di rete usando lo spazio dei nomi WMI
V2 Hyper-V
Rimozione di una scheda di rete in una macchina virtuale usando lo spazio dei nomi WMI V2
Hyper-V
Collegamento di un disco rigido virtuale a una macchina virtuale tramite lo spazio dei nomi
WMI V2 Hyper-V
Rimozione di un disco rigido virtuale da una macchina virtuale usando lo spazio dei nomi WMI
V2 di Hyper-V
Creazione di una macchina virtuale usando lo spazio dei nomi WMI V2 Hyper-V