Novità di Hyper-V in Windows Server

Si applica a: Windows Server 2022, Windows Server 2019, Microsoft Hyper-V Server 2016, Windows Server 2016

Questo articolo illustra le funzionalità nuove e modificate di Hyper-V in Windows Server 2019, Windows Server 2016 e Microsoft Hyper-V Server 2016. Per usare le nuove funzionalità nelle macchine virtuali create con Windows Server 2012 R2 e spostate o importate in un server che esegue Hyper-V in Windows Server 2019 o Windows Server 2016, è necessario aggiornare manualmente la versione di configurazione della macchina virtuale. Per istruzioni, vedere versione aggiornamento macchina virtuale.

Ecco cosa è incluso in questo articolo e se la funzionalità è nuovo o aggiornato.

Windows Server, versione 1903

Aggiungere la console di gestione di Hyper-V alle installazioni Server Core (aggiornato)

Come già saprai, è consigliabile usare l'opzione di installazione Server Core quando usi Windows Server, Canale semestrale in fase di produzione. Server Core omette tuttavia per impostazione predefinita una serie di strumenti di gestione utili. Puoi aggiungere molti degli strumenti più comuni installando la funzionalità di compatibilità app, ma continueranno a mancare ancora alcuni strumenti.

In base ai commenti e suggerimenti dei clienti, in questa versione sono stati aggiunti altri strumenti alla funzionalità Compatibilità app: Console di gestione di Hyper-V (virtmgmt.msc).

Per altre informazioni, vedere Server Core App Compatibility Feature on Demand (FOD) (Funzionalità surichiesta per la compatibilità delle app Server Core).

Windows Server 2019

Sicurezza: miglioramenti delle macchine virtuali schermate (novità)

  • Miglioramenti di succursale

    Ora puoi eseguire macchine virtuali schermate in computer con connettività intermittente al servizio Sorveglianza host sfruttando le nuove funzionalità del server HGS di fallback e la modalità offline. Il server HGS di fallback ti consente di configurare un secondo gruppo di URL per Hyper-V per provare se è in grado di raggiungere il server HGS primario.

    La modalità offline ti consente di continuare ad avviare le macchine virtuali schermate, anche se HGS non può essere raggiunto, purché la macchina virtuale sia stata avviata correttamente una volta e la configurazione della sicurezza dell'host non sia cambiata.

  • Miglioramenti alla risoluzione dei problemi

    Abbiamo anche semplificato la risoluzione dei problemi delle macchine virtuali schermate abilitando il supporto per la modalità sessione avanzata VMConnect e PowerShell Direct. Questi strumenti sono particolarmente utili se hai perso la connettività di rete alla macchina virtuale e devi aggiornarne la configurazione per ripristinare l'accesso.

    Queste funzionalità non devono essere configurate e vengono rese disponibili automaticamente quando una macchina virtuale schermata viene posizionata su un host Hyper-V che esegue Windows Server versione 1803 o successiva.

  • Supporto di Linux

    Se esegui ambienti di sistema operativo misto, adesso Windows Server 2019 supporta l'esecuzione di Ubuntu, Red Hat Enterprise Linux e SUSE Linux Enterprise Server in macchine virtuali schermate.

Windows Server 2016

Compatibile con connected standby (nuovo)

Quando è installato il ruolo Hyper-V in un computer che utilizza il modello di risparmio energia sempre On/Always connessi (AOAC), il Standby connesso stato di alimentazione è ora disponibile.

Assegnazione di dispositivi discreti (nuovo)

Questa funzionalità consente di fornire accesso diretto ed esclusivo di una macchina virtuale per alcuni dispositivi hardware PCIe. Utilizzo di un dispositivo in questo modo consente di ignorare lo stack di virtualizzazione Hyper-V, che comporta un accesso più rapido. Per informazioni dettagliate sull'hardware supportato, vedere "Assegnazione di dispositivi discreti" in Requisiti di sistema per Hyper-V Windows Server 2016. Per informazioni dettagliate, tra cui come usare questa funzionalità e considerazioni, vedere il post "Discrete Device Assignment Description and background" (Descrizione e background dell'assegnazione di dispositivi discreti) nel blog sulla virtualizzazione.

Supporto della crittografia per il disco del sistema operativo nelle macchine virtuali di prima generazione (novità)

È ora possibile proteggere il disco del sistema operativo mediante crittografia unità BitLocker in macchine virtuali di generazione 1. Una nuova funzionalità, l'archiviazione chiavi, crea un'unità piccola e dedicata per archiviare la chiave BitLocker dell'unità di sistema. Questa operazione viene eseguita invece di utilizzare un virtuale modulo TPM (Trusted Platform), che è disponibile solo in macchine virtuali di generazione 2. Per decrittografare il disco e avviare la macchina virtuale, l'host Hyper-V deve far parte di un'infrastruttura protetta autorizzata o dispone della chiave privata da uno dei tutori della macchina virtuale. Archiviazione delle chiavi richiede una macchina virtuale versione 8. Per informazioni sulla versione di macchina virtuale, vedere versione aggiornamento macchina virtuale in Hyper-V in Windows 10 o Windows Server 2016.

Protezione delle risorse host (novità)

Questa funzionalità consente di evitare che una macchina virtuale utilizza più di relativa condivisione di risorse di sistema mediante la ricerca di livelli di un numero eccessivo di attività. Questo può impedire attività eccessiva della macchina virtuale di peggiorare le prestazioni di host o altre macchine virtuali. Quando il monitoraggio rileva una macchina virtuale con un eccesso di attività, la macchina virtuale viene assegnata meno risorse. Questo monitoraggio e l'applicazione è disattivata per impostazione predefinita. Utilizzare Windows PowerShell per attiva o disattivata. Per attivarla, eseguire questo comando:

Set-VMProcessor TestVM -EnableHostResourceProtection $true

Per informazioni dettagliate su questo cmdlet, vedere Set-VMProcessor.

Aggiunta e rimozione a caldo per schede di rete e memoria (novità)

È ora possibile aggiungere o rimuovere una scheda di rete, mentre la macchina virtuale è in esecuzione, senza ciò potrebbe comportare tempi di inattività. Questa procedura funziona per le macchine virtuali di generazione 2 che eseguono sistemi operativi Windows o Linux.

È inoltre possibile regolare la quantità di memoria assegnata a una macchina virtuale mentre è in esecuzione, anche se non è stata abilitata la memoria dinamica. Ciò avviene per la generazione 1 e macchine virtuali di generazione 2, che esegue Windows Server 2016 o Windows 10.

Miglioramenti della console di gestione di Hyper-V (aggiornato)

  • Supporto di credenziali alternative -è ora possibile utilizzare un diverso set di credenziali di gestione di Hyper-V quando ci si connette a un altro host remoto Windows 10 o Windows Server 2016. È inoltre possibile salvare le credenziali per rendere più semplice di accedere di nuovo.

  • Gestire le versioni precedenti: con la console di gestione di Hyper-V in Windows Server 2019, Windows Server 2016 e Windows 10 è possibile gestire i computer che eseguono Hyper-V in Windows Server 2012, Windows 8, Windows Server 2012 R2 e Windows 8.1.

  • Protocollo di gestione aggiornato -Hyper-V Manager ora comunica con gli host Hyper-V remoti utilizzando il protocollo WS-MANAGEMENT, che consente l'autenticazione CredSSP, Kerberos o NTLM. Quando si utilizza CredSSP per connettersi a un host Hyper-V remoto, è possibile eseguire una migrazione in tempo reale senza abilitare la delega vincolata in Active Directory. L'infrastruttura basate su WS-MAN rende anche più semplice attivare un host per la gestione remota. WS-Management effettua la connessione tramite la porta 80, aperta per impostazione predefinita.

Servizi di integrazione recapitati Windows Update (aggiornato)

Gli aggiornamenti a integration services per gli ospiti di Windows vengono distribuiti tramite Windows Update. Per i provider di servizi e hoster cloud privato, in questo modo il controllo di applicazione degli aggiornamenti nelle mani di tenant che possiedono le macchine virtuali. Tenant ora possono aggiornare le proprie macchine virtuali di Windows con tutti gli aggiornamenti, inclusi i servizi di integrazione, utilizzando un singolo metodo. Per informazioni dettagliate sui servizi di integrazione per i Guest Linux, vedere Linux e FreeBSD le macchine virtuali in Hyper-V.

Importante

Il file di immagine vmguest non è più necessario, pertanto, non è incluso con Hyper-V in Windows Server 2016.

Avvio protetto di Linux (nuovo)

Sistemi operativi Linux in esecuzione su macchine virtuali di generazione 2 possono ora di avvio con l'opzione di avvio protetto abilitata. Ubuntu 14.04 e versioni successive, SUSE Linux Enterprise Server 12 e successive, Red Hat Enterprise Linux 7.0 e versioni successive e CentOS 7.0 e versioni successive sono abilitati per l'avvio protetto sugli host che eseguono Windows Server 2016. Prima avviare la macchina virtuale per la prima volta, è necessario configurare la macchina virtuale per l'utilizzo di autorità di certificazione Microsoft UEFI. È possibile farlo dalla gestione di Hyper-V, Virtual Machine Manager o una sessione di Windows Powershell con privilegi elevata. Per Windows PowerShell, eseguire questo comando:

Set-VMFirmware TestVM -SecureBootTemplate MicrosoftUEFICertificateAuthority

Per ulteriori informazioni sulle macchine virtuali Linux in Hyper-V, vedere Linux e FreeBSD le macchine virtuali in Hyper-V. Per ulteriori informazioni sul cmdlet, vedere Set-VMFirmware.

Più memoria e processori per macchine virtuali di seconda generazione e host Hyper-V (aggiornato)

A partire dalla versione 8, macchine virtuali di generazione 2 possono utilizzare molte più memoria e processori virtuali. Host inoltre possono essere configurati con molte più memoria e processori virtuali che erano supportati. Queste modifiche supportano nuovi scenari quali l'esecuzione di database di grandi dimensioni in memoria per l'elaborazione delle transazioni online (OLTP) e di data warehousing (DW) e-commerce. Il blog di Windows Server ha pubblicato di recente i risultati delle prestazioni di una macchina virtuale con 5,5 terabyte di memoria e 128 processori virtuali che eseguono 4 TB di database in memoria. Le prestazioni sono superiori al 95% delle prestazioni di un server fisico. Per informazioni dettagliate, vedere prestazioni della macchina Virtuale su larga scala di Windows Server 2016 Hyper-V per l'elaborazione delle transazioni in memoria. Per informazioni dettagliate sulle versioni di macchina virtuale, vedere versione aggiornamento macchina virtuale in Hyper-V in Windows 10 o Windows Server 2016. Per l'elenco completo delle configurazioni massime supportate, vedere pianificare la scalabilità di Hyper-V in Windows Server 2016.

Virtualizzazione annidata (nuovo)

Questa funzionalità consente di utilizzare una macchina virtuale come host Hyper-V e creare macchine virtuali all'interno di tale host virtualizzato. Ciò può risultare particolarmente utile per ambienti di sviluppo e test. Per utilizzare la virtualizzazione nidificata, è necessario:

  • Per eseguire almeno Windows Server 2019, Windows Server 2016 o Windows 10 nell'host Hyper-V fisico e nell'host virtualizzato.

  • Un processore con Intel VT-x (virtualizzazione nidificata è disponibile solo per i processori Intel in questo momento).

Per informazioni dettagliate e istruzioni, vedere Eseguire Hyper-V in una macchina virtuale con virtualizzazione annidata.

Funzionalità di rete (novità)

Nuove funzionalità di rete includono:

  • Accesso diretto a memoria remota (RDMA) e switch embedded teaming (SET). È possibile impostare RDMA sulle schede di rete associate a un commutatore virtuale Hyper-V, indipendentemente dal fatto che SET viene anche utilizzato. SET di fornisce un commutatore virtuale con alcune delle stesse funzionalità gruppo NIC. Per informazioni dettagliate, vedere diretta accesso memoria remota (RDMA) e Switch incorporati di raggruppamento (SET).

  • Più code di macchine virtuali (VMMQ). Migliora la velocità effettiva VMQ allocando più code di hardware per ogni macchina virtuale. La coda predefinita diventa un insieme di code per una macchina virtuale e il traffico viene distribuito tra le code.

  • Qualità del servizio (QoS) per le reti definita dal software. Gestisce la classe predefinita del traffico attraverso il commutatore virtuale all'interno della larghezza di banda di classe predefinito.

Per ulteriori informazioni sulle nuove funzionalità di rete, vedere What's new in rete.

Checkpoint di produzione (nuovo)

I checkpoint di produzione sono immagini "point-in-time" di una macchina virtuale. In tal modo, è un modo per applicare un checkpoint che è conforme ai criteri di supporto quando una macchina virtuale in esecuzione un carico di lavoro di produzione. I checkpoint di produzione sono basati sulla tecnologia di backup nella macchina guest invece di uno stato salvato. Per le macchine virtuali Windows, viene utilizzato il servizio Snapshot Volume (VSS). Per le macchine virtuali Linux, verranno scaricati i buffer di file system per creare un checkpoint che è coerente con il file system. Se si desidera utilizzare i checkpoint in base agli stati salvati, scegliere i checkpoint standard. Per informazioni dettagliate, vedere Scegliere tra checkpoint standard o di produzione in Hyper-V.

Importante

Nuove macchine virtuali utilizzarli produzione come impostazione predefinita.

Aggiornamento in sequenza del cluster Hyper-V (nuovo)

È ora possibile aggiungere un nodo che esegue Windows Server 2019 o Windows Server 2016 a un cluster Hyper-V con nodi che eseguono Windows Server 2012 R2. Ciò consente di aggiornare il cluster senza tempi di inattività. Il cluster viene eseguito Windows Server 2012 livello di funzionalità R2 fino a quando non si aggiornano tutti i nodi del cluster e si aggiorna il livello di funzionalità del cluster con il cmdlet Windows PowerShell, Update-ClusterFunctionalLevel.

Importante

Dopo aver aggiornato il livello di funzionalità del cluster, è possibile restituire, a Windows Server 2012 R2.

Per un cluster Hyper-V con un livello di funzionalità Windows Server 2012 R2 con nodi che eseguono Windows Server 2012 R2, Windows Server 2019 e Windows Server 2016, tenere presente quanto segue:

  • Gestire il cluster, Hyper-V e macchine virtuali da un nodo che esegue Windows Server 2016 o Windows 10.

  • È possibile spostare le macchine virtuali tra tutti i nodi del cluster Hyper-V.

  • Per usare le nuove funzionalità di Hyper-V, tutti i nodi devono Windows Server 2016 o e il livello di funzionalità del cluster deve essere aggiornato.

  • La versione di configurazione macchina virtuale per le macchine virtuali esistenti non è aggiornata. È possibile aggiornare la versione di configurazione solo dopo l'aggiornamento a livello funzionale del cluster.

  • Le macchine virtuali create sono compatibili con Windows Server 2012 R2, il livello di configurazione macchina virtuale 5.

Dopo l'aggiornamento a livello funzionale del cluster:

  • È possibile abilitare le nuove funzionalità di Hyper-V.

  • Per rendere disponibili nuove funzionalità della macchina virtuale, usare il Update-vmVersion cmdlet per aggiornare manualmente il livello di configurazione della macchina virtuale. Per istruzioni, vedere versione aggiornamento macchina virtuale.

  • È possibile aggiungere un nodo al Cluster Hyper-V che esegue Windows Server 2012 R2.

Nota

Hyper-V in Windows 10 non supporta il clustering di failover.

Per informazioni dettagliate e istruzioni, vedere il aggiornamento in sequenza di Cluster del sistema operativo.

Dischi rigidi virtuali condivisi (aggiornati)

È ora possibile ridimensionare i dischi rigidi virtuali condivisi (vhdx) utilizzati per il clustering, senza tempi di inattività guest. Dischi rigidi virtuali condivisi può essere aumentati o ridotti mentre la macchina virtuale è in linea. Cluster guest ora possono inoltre proteggere dischi rigidi virtuali condivisi tramite Replica Hyper-V per il ripristino di emergenza.

Abilitare la replica nella raccolta. L'abilitazione della replica in una raccolta viene esposta solo tramite l'interfaccia WMI. Per altre informazioni, vedere la documentazione Msvm_CollectionReplicationService classe . Non è possibile gestire la replica di una raccolta tramite il cmdlet o l'interfaccia utente di PowerShell. Le macchine virtuali devono essere in host che fanno parte di un cluster Hyper-V per accedere alle funzionalità specifiche di una raccolta. Questo include il disco rigido virtuale condiviso: i dischi rigidi virtuali condivisi in host autonomi non sono supportati dalla replica Hyper-V.

Seguire le linee guida per i dischi rigidi virtuali condivisi in Panoramicadi Condivisione dischi rigidi virtuali e assicurarsi che i dischi rigidi virtuali condivisi siano parte di un cluster guest.

Una raccolta con un disco rigido virtuale condiviso ma nessun cluster guest associato non può creare punti di riferimento per la raccolta (indipendentemente dal fatto che il disco rigido virtuale condiviso sia incluso o meno nella creazione del punto di riferimento).

Backup macchina virtuale(nuovo)

Se si sta eseguire il backup di una singola macchina virtuale (indipendentemente dal fatto che l'host sia in cluster o meno), non è consigliabile usare un gruppo di macchine virtuali. Né è consigliabile usare una raccolta di snapshot. I gruppi di macchine virtuali e la raccolta di snapshot devono essere usati esclusivamente per il backup di cluster guest che usano vhdx condiviso. È invece consigliabile creare uno snapshot usando il provider WMI v2 Hyper-V. Analogamente, non usare il provider WMI del cluster di failover.

Macchine virtuali schermate (nuove)

Schermatura utilizzare macchine virtuali diverse funzionalità che rendono più difficile per gli amministratori di Hyper-V e malware nell'host controllare, alterare o rubare i dati dallo stato di una macchina virtuale schermata. I dati e lo stato sono crittografati, gli amministratori di Hyper-V non possono visualizzare l'output video e i dischi e le macchine virtuali possono essere limitate per l'esecuzione solo in host noti e integri, come determinato da un server Di guardiano host. Per informazioni dettagliate, vedere infrastruttura protetta e macchine virtuali schermati.

Nota

Le macchine virtuali schermate sono compatibili con la replica Hyper-V. Per replicare una macchina virtuale schermata, l'host che si desidera replicare deve essere autorizzato a eseguire tale macchina virtuale schermata.

Priorità ordine di inizio per le macchine virtuali in cluster (nuovo)

Questa funzionalità offre maggiore controllo sulla quale macchine virtuali del cluster viene avviate o riavviate prima. Questo rende più semplice avviare le macchine virtuali che forniscono servizi prima delle macchine virtuali che utilizzano tali servizi. Definire i set, posizionare le macchine virtuali nei set e specificare le dipendenze. Usare Windows PowerShell cmdlet per gestire i set, ad esempio New-ClusterGroupSet, Get-ClusterGroupSete Add-ClusterGroupSetDependency. .

Archiviazione qualità del servizio (QoS) (aggiornato)

È ora possibile creare criteri QoS di archiviazione in un File server di scalabilità orizzontale e assegnarli a uno o più dischi virtuali in macchine virtuali Hyper-V. Le prestazioni di archiviazione vengono regolate automaticamente in modo da soddisfare i criteri man mano che cambia il carico di archiviazione. Per informazioni dettagliate, vedere qualità del servizio di archiviazione.

Formato del file di configurazione della macchina virtuale (aggiornato)

File di configurazione macchina virtuale utilizzano un nuovo formato di operazioni di lettura e scrittura dei dati di configurazione più efficiente. Il formato rende inoltre il danneggiamento dei dati meno probabile che se si verifica un errore di archiviazione. File di dati di configurazione macchina virtuale utilizzano un'estensione di nome file .vmcx e file di dati dello stato di runtime utilizzano un'estensione di nome file .vmrs.

Importante

L'estensione del nome file .vmcx indica un file binario. Modifica dei file .vmcx o .vmrs non è supportata.

Versione di configurazione della macchina virtuale (aggiornata)

La versione rappresenta la compatibilità di configurazione della macchina virtuale, salvata lo stato e i file di snapshot con la versione di Hyper-V. Le macchine virtuali con la versione 5 sono compatibili con Windows Server 2012 R2 e possono essere eseguite in Windows Server 2012 R2 e Windows Server 2016. Le macchine virtuali con versioni introdotte in Windows Server 2016 e Windows Server 2019 non vengono eseguite in Hyper-V in Windows Server 2012 R2.

Se si sposta o si importa una macchina virtuale in un server che esegue Hyper-V in Windows Server 2016 o Windows Server 2019 da Windows Server 2012 R2, la configurazione della macchina virtuale non viene aggiornata automaticamente. Ciò significa che è possibile riportare la macchina virtuale a un server che esegue Windows Server 2012 R2. Tuttavia, ciò significa anche fino a quando non si aggiorna manualmente la versione di configurazione della macchina virtuale non è possibile utilizzare le nuove funzionalità di macchina virtuale.

Per ulteriori informazioni sulla verifica e l'aggiornamento della versione, vedere versione aggiornamento macchina virtuale. In questo articolo sono elencati anche la versione in cui sono state introdotte alcune funzionalità.

Importante

  • Dopo aver aggiornato la versione, non è possibile spostare la macchina virtuale in un server che esegue Windows Server 2012 R2.
  • È possibile effettuare il downgrade la configurazione di una versione precedente.
  • Il cmdlet Update-VMVersion viene bloccato in un cluster Hyper-V quando il livello di funzionalità del cluster Windows Server 2012 R2.

Sicurezza basata sulla virtualizzazione per le macchine virtuali di seconda generazione (novità)

Protezione basata su virtualizzazione alimenta funzionalità quali protezione del dispositivo e il controllo delle credenziali che offrono una maggiore protezione del sistema operativo contro gli attacchi da malware. La protezione basata di virtualizzazione è disponibile nelle macchine virtuali di generazione 2 guest a partire dalla versione 8. Per informazioni sulla versione di macchina virtuale, vedere versione aggiornamento macchina virtuale in Hyper-V in Windows 10 o Windows Server 2016.

Windows contenitori (nuovo)

Contenitori di Windows consentono molte applicazioni isolate per l'esecuzione in un sistema di computer. Che è veloce per compilare e sono estremamente scalabili e portabile. Sono disponibili due tipi di runtime di contenitore, ciascuno con un diverso livello di isolamento delle applicazioni. Windows Server Containers utilizzare l'isolamento di processo e lo spazio dei nomi. Contenitori di Hyper-V utilizzano una macchina virtuale leggera per ogni contenitore.

Le funzionalità principali includono:

  • Supporto per siti web e applicazioni utilizzando il protocollo HTTPS

  • Nano server può ospitare sia Windows Server e i contenitori di Hyper-V

  • Possibilità di gestire i dati all'interno delle cartelle condivise contenitore

  • Possibilità di limitare le risorse di contenitore

Per informazioni dettagliate, incluse le guide introduttive, vedere la documentazione Windows contenitori.

Windows PowerShell Direct (nuovo)

Ciò consente di eseguire i comandi di Windows PowerShell in una macchina virtuale dall'host. Windows PowerShell diretta viene eseguita tra l'host e la macchina virtuale. Ciò significa che non richiede requisiti di rete o firewall e funziona indipendentemente dalla configurazione della gestione remota.

Windows PowerShell diretto è un'alternativa per gli strumenti esistenti utilizzati dagli amministratori di Hyper-V per connettersi a una macchina virtuale in un host Hyper-V:

  • Strumenti di gestione remota, ad esempio PowerShell o Desktop remoto

  • Hyper-V Virtual Machine Connection (VMConnect)

Gli strumenti funzionano bene, ma sono compromessi: VMConnect è affidabile, ma può essere difficile da automatizzare. PowerShell remoto è potente, ma può essere difficile da configurare e gestire. Questi compromessi potrebbero diventare più importanti man mano che aumenta la distribuzione di Hyper-V. Windows PowerShell diretto risolve questo problema fornendo un'esperienza di scripting e automazione potenti che è semplice come l'uso di VMConnect.

Per i requisiti e le istruzioni, vedere Windows di gestire le macchine virtuali con PowerShell Direct.