Cosa c’è di nuovo in Hyper-V su Windows Server

• 09/21/2017
• 15 minuti per leggere
• • B
  • p
  • e
  • D
  • v
  • +5

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

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

Ecco cosa è incluso in questo articolo e se la funzionalità è nuova o aggiornata.

Windows Server, versione 1903

Aggiungi Hyper-V Manager alle installazioni Server Core (aggiornato)

Come forse sapete, si consiglia di utilizzare l’opzione di installazione Server Core quando si utilizza Windows Server, canale semestrale in produzione. Tuttavia, Server Core per impostazione predefinita omette una serie di utili strumenti di gestione. È possibile aggiungere molti degli strumenti più comunemente usati installando la funzione App Compatibility, ma ci sono ancora alcuni strumenti mancanti.

Così, sulla base del feedback dei clienti, abbiamo aggiunto un altro strumento alla funzione App Compatibility in questa versione: Hyper-V Manager (virtmgmt.msc).

Per maggiori informazioni, vedi funzione di compatibilità delle app di Server Core.

Windows Server 2019

Sicurezza: Miglioramenti macchine virtuali schermate (nuovo)

• Miglioramenti ufficio di filiale

  È ora possibile eseguire macchine virtuali schermate su macchine con connettività intermittente all’Host Guardian Service sfruttando le nuove funzionalità fallback HGS e modalità offline. Fallback HGS ti permette di configurare un secondo set di URL che Hyper-V deve provare se non riesce a raggiungere il tuo server HGS primario.

  La modalità offline ti permette di continuare ad avviare le tue VM protette, anche se HGS non può essere raggiunto, a patto che la VM sia stata avviata con successo una volta e che la configurazione di sicurezza dell’host non sia cambiata.

• Miglioramenti nella risoluzione dei problemi

  Abbiamo anche reso più facile la risoluzione dei problemi delle macchine virtuali schermate abilitando il supporto per VMConnect Enhanced Session Mode e PowerShell Direct. Questi strumenti sono particolarmente utili se hai perso la connettività di rete alla tua VM e hai bisogno di aggiornare la sua configurazione per ripristinare l’accesso.

  Queste funzioni non hanno bisogno di essere configurate, e diventano disponibili automaticamente quando una VM schermata viene posizionata su un host Hyper-V con Windows Server versione 1803 o successiva.

• Supporto Linux

  Se si eseguono ambienti mixed-OS, Windows Server 2019 ora supporta l’esecuzione di Ubuntu, Red Hat Enterprise Linux e SUSE Linux Enterprise Server all’interno di macchine virtuali schermate.

Windows Server 2016

Compatibile con Connected Standby (nuovo)

Quando il ruolo Hyper-V è installato su un computer che utilizza il modello di alimentazione Always On/Always Connected (AOAC), lo stato di alimentazione Connected Standby è ora disponibile.

Assegnazione discreta dei dispositivi (nuovo)

Questa funzione permette di dare a una macchina virtuale un accesso diretto ed esclusivo ad alcuni dispositivi hardware PCIe. Usando un dispositivo in questo modo si bypassa lo stack di virtualizzazione di Hyper-V, il che si traduce in un accesso più veloce. Per i dettagli sull’hardware supportato, vedere “Assegnazione di dispositivi discreti” in Requisiti di sistema per Hyper-V su Windows Server 2016. Per i dettagli, compreso come utilizzare questa funzione e le considerazioni, vedere il post “Assegnazione discreta dei dispositivi – Descrizione e background” nel blog della Virtualizzazione.

Supporto alla crittografia per il disco del sistema operativo nelle macchine virtuali di generazione 1 (nuovo)

È ora possibile proteggere il disco del sistema operativo utilizzando la crittografia dell’unità BitLocker nelle macchine virtuali di generazione 1. Una nuova funzione, la memorizzazione della chiave, crea una piccola unità dedicata per memorizzare la chiave BitLocker dell’unità di sistema. Questo viene fatto invece di usare un Trusted Platform Module (TPM) virtuale, che è disponibile solo nelle macchine virtuali di seconda generazione. Per decifrare il disco e avviare la macchina virtuale, l’host Hyper-V deve essere parte di un tessuto protetto autorizzato o avere la chiave privata da uno dei guardiani della macchina virtuale. La memorizzazione della chiave richiede una macchina virtuale versione 8. Per informazioni sulla versione della macchina virtuale, vedere Aggiornare la versione della macchina virtuale in Hyper-V su Windows 10 o Windows Server 2016.

Protezione delle risorse dell’host (nuovo)

Questa funzione aiuta a impedire che una macchina virtuale utilizzi più della sua quota di risorse di sistema cercando livelli eccessivi di attività. Questo può aiutare a prevenire che l’attività eccessiva di una macchina virtuale degradi le prestazioni dell’host o di altre macchine virtuali. Quando il monitoraggio rileva una macchina virtuale con un’attività eccessiva, alla macchina virtuale vengono date meno risorse. Questo monitoraggio e l’applicazione sono disattivati per impostazione predefinita. Usa Windows PowerShell per attivarlo o disattivarlo. Per attivarlo, esegui questo comando:

Set-VMProcessor TestVM -EnableHostResourceProtection $true

Per i dettagli su questo cmdlet, vedi Set-VMProcessor.

Hot add and remove for network adapters and memory (new)

Ora puoi aggiungere o rimuovere una scheda di rete mentre la macchina virtuale è in esecuzione, senza incorrere in tempi morti. Questo funziona per le macchine virtuali di generazione 2 che eseguono sistemi operativi Windows o Linux.

Puoi anche regolare la quantità di memoria assegnata a una macchina virtuale mentre è in esecuzione, anche se non hai abilitato la memoria dinamica. Questo funziona sia per le macchine virtuali di generazione 1 che di generazione 2, con Windows Server 2016 o Windows 10.

Miglioramenti di Hyper-V Manager (aggiornato)

• Supporto per credenziali alternative – Ora è possibile utilizzare un diverso set di credenziali in Hyper-V Manager quando ci si connette a un altro host remoto Windows Server 2016 o Windows 10. Puoi anche salvare queste credenziali per rendere più facile l’accesso di nuovo.

• Gestire versioni precedenti – Con Hyper-V Manager in Windows Server 2019, Windows Server 2016 e Windows 10, puoi gestire i computer che eseguono Hyper-V su 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-MAN, che consente l’autenticazione CredSSP, Kerberos o NTLM. Quando si utilizza CredSSP per connettersi a un host Hyper-V remoto, è possibile effettuare una migrazione live senza abilitare la delega vincolata in Active Directory. L’infrastruttura basata su WS-MAN rende anche più facile abilitare un host per la gestione remota. WS-MAN si connette sulla porta 80, che è aperta per impostazione predefinita.

Servizi di integrazione consegnati attraverso Windows Update (aggiornato)

Gli aggiornamenti ai servizi di integrazione per gli ospiti Windows sono distribuiti attraverso Windows Update. Per i service provider e gli host di cloud privati, questo mette il controllo dell’applicazione degli aggiornamenti nelle mani dei tenant che possiedono le macchine virtuali. Gli inquilini possono ora aggiornare le loro macchine virtuali Windows con tutti gli aggiornamenti, compresi i servizi di integrazione, utilizzando un unico metodo. Per i dettagli sui servizi di integrazione per i guest Linux, vedere Macchine virtuali Linux e FreeBSD su Hyper-V.

Linux Secure Boot (nuovo)

I sistemi operativi Linux in esecuzione su macchine virtuali di seconda generazione possono ora avviarsi con l’opzione Secure Boot abilitata. Ubuntu 14.04 e successivi, SUSE Linux Enterprise Server 12 e successivi, Red Hat Enterprise Linux 7.0 e successivi e CentOS 7.0 e successivi sono abilitati per Secure Boot su host che eseguono Windows Server 2016. Prima di avviare la macchina virtuale per la prima volta, è necessario configurare la macchina virtuale per utilizzare l’autorità di certificazione Microsoft UEFI. È possibile farlo da Hyper-V Manager, Virtual Machine Manager o da una sessione elevata di Windows Powershell. Per Windows PowerShell, esegui questo comando:

Set-VMFirmware TestVM -SecureBootTemplate MicrosoftUEFICertificateAuthority

Per maggiori informazioni sulle macchine virtuali Linux su Hyper-V, vedi Macchine virtuali Linux e FreeBSD su Hyper-V. Per maggiori informazioni sul cmdlet, vedi Set-VMFirmware.

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

A partire dalla versione 8, le macchine virtuali di generazione 2 possono usare significativamente più memoria e processori virtuali. Anche gli host possono essere configurati con molta più memoria e processori virtuali rispetto a quelli supportati in precedenza. Questi cambiamenti supportano nuovi scenari come l’esecuzione di grandi database in-memory di e-commerce per l’elaborazione delle transazioni online (OLTP) e il data warehousing (DW). Il blog di Windows Server ha recentemente pubblicato 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-memory. Le prestazioni erano superiori al 95% delle prestazioni di un server fisico. Per i dettagli, vedi Windows Server 2016 Hyper-V prestazioni VM su larga scala per l’elaborazione delle transazioni in-memoria. Per i dettagli sulle versioni della macchina virtuale, vedi Aggiornare la versione della macchina virtuale in Hyper-V su Windows 10 o Windows Server 2016. Per l’elenco completo delle configurazioni massime supportate, vedi Pianificare la scalabilità di Hyper-V in Windows Server 2016.

Virtualizzazione annidata (nuovo)

Questa funzione consente di utilizzare una macchina virtuale come host Hyper-V e creare macchine virtuali all’interno di quell’host virtualizzato. Questo può essere particolarmente utile per gli ambienti di sviluppo e di test. Per utilizzare la virtualizzazione annidata, avrete bisogno di:

• Eseguire almeno Windows Server 2019, Windows Server 2016 o Windows 10 sia sull’host fisico Hyper-V che sull’host virtualizzato.

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

Per i dettagli e le istruzioni, vedere Eseguire Hyper-V in una macchina virtuale con virtualizzazione annidata.

Funzioni di rete (nuove)

Le nuove funzioni di rete includono:

• Remote direct memory access (RDMA) e switch embedded teaming (SET). È possibile impostare RDMA sulle schede di rete legate a uno switch virtuale Hyper-V, indipendentemente dal fatto che sia utilizzato anche SET. SET fornisce uno switch virtuale con alcune delle stesse capacità del NIC teaming. Per i dettagli, vedere Remote Direct Memory Access (RDMA) e Switch Embedded Teaming (SET).

• Virtual machine multi queues (VMMQ). Migliora il throughput di VMQ allocando più code hardware per macchina virtuale. La coda predefinita diventa un insieme di code per una macchina virtuale, e il traffico è distribuito tra le code.

• Qualità del servizio (QoS) per reti definite dal software. Gestisce la classe predefinita del traffico attraverso lo switch virtuale entro la larghezza di banda della classe predefinita.

Per ulteriori informazioni sulle nuove funzionalità di rete, vedere Cosa c’è di nuovo nel Networking.

Production checkpoints (nuovo)

Production checkpoints sono immagini “point-in-time” di una macchina virtuale. Questi vi danno un modo per applicare un checkpoint conforme alle politiche di supporto quando una macchina virtuale esegue un carico di lavoro di produzione. I checkpoint di produzione si basano sulla tecnologia di backup all’interno del guest invece che su uno stato salvato. Per le macchine virtuali Windows, viene utilizzato il Volume Snapshot Service (VSS). Per le macchine virtuali Linux, i buffer del file system vengono lavati per creare un checkpoint che sia coerente con il file system. Se preferisci usare i checkpoint basati sugli stati salvati, scegli invece i checkpoint standard. Per i dettagli, consulta Scegliere tra checkpoint standard o di produzione in Hyper-V.

Aggiornamento del cluster Hyper-V (nuovo)

È ora possibile aggiungere un nodo con Windows Server 2019 o Windows Server 2016 a un cluster Hyper-V con nodi che eseguono Windows Server 2012 R2. Questo permette di aggiornare il cluster senza tempi morti. Il cluster funziona a un livello funzionale di Windows Server 2012 R2 fino a quando non si aggiornano tutti i nodi nel cluster e si aggiorna il livello funzionale del cluster con il cmdlet Windows PowerShell, Update-ClusterFunctionalLevel.

Per un cluster Hyper-V con un livello funzionale di Windows Server 2012 R2 con nodi che eseguono Windows Server 2012 R2, Windows Server 2019 e Windows Server 2016, si noti quanto segue:

• Gestire il cluster, Hyper-V e le 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 utilizzare le nuove funzionalità di Hyper-V, tutti i nodi devono eseguire Windows Server 2016 o e il livello funzionale del cluster deve essere aggiornato.

• La versione della configurazione della macchina virtuale per le macchine virtuali esistenti non viene aggiornata. È possibile aggiornare la versione di configurazione solo dopo aver aggiornato il livello funzionale del cluster.

• Le macchine virtuali che si creano sono compatibili con Windows Server 2012 R2, livello di configurazione della macchina virtuale 5.

Dopo aver aggiornato il livello funzionale del cluster:

• È possibile abilitare nuove funzionalità Hyper-V.

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

• Non è possibile aggiungere un nodo al cluster Hyper-V che esegue Windows Server 2012 R2.

Per i dettagli e le istruzioni, vedi l’aggiornamento continuo del sistema operativo del cluster.

Dischi rigidi virtuali condivisi (aggiornato)

È ora possibile ridimensionare i dischi rigidi virtuali condivisi (file .vhdx) utilizzati per il clustering del guest, senza tempi morti. I dischi rigidi virtuali condivisi possono essere aumentati o ridotti mentre la macchina virtuale è online. I cluster guest ora possono anche proteggere i dischi rigidi virtuali condivisi utilizzando Hyper-V Replica per il disaster recovery.

Abilita la replica sulla collezione. L’abilitazione della replica su una collezione è esposta solo attraverso l’interfaccia WMI. Vedere la documentazione per la classe Msvm_CollectionReplicationService per maggiori dettagli. Non è possibile gestire la replica di una collezione tramite cmdlet PowerShell o UI. Le VM dovrebbero essere su host che fanno parte di un cluster Hyper-V per accedere alle funzioni specifiche di una collezione. Questo include i VHD condivisi – i VHD condivisi su host stand-alone non sono supportati da Hyper-V Replica.

Seguite le linee guida per i VHD condivisi in Virtual Hard Disk Sharing Overview, e assicuratevi che i vostri VHD condivisi facciano parte di un cluster guest.

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

Backup della macchina virtuale (nuovo)

Se stai facendo il backup di una singola macchina virtuale (indipendentemente dal fatto che l’host sia in cluster o meno), non dovresti usare un gruppo VM. Né si dovrebbe usare una collezione di snapshot. I gruppi di VM e la raccolta di istantanee sono pensati per essere utilizzati esclusivamente per il backup di cluster di guest che utilizzano vhdx condivisi. Invece, si dovrebbe prendere un’istantanea utilizzando il provider Hyper-V WMI v2. Allo stesso modo, non utilizzare il provider WMI di Failover Cluster.

Macchine virtuali schermate (nuovo)

Le macchine virtuali schermate utilizzano diverse caratteristiche per rendere più difficile agli amministratori Hyper-V e al malware sull’host di ispezionare, manomettere o rubare i dati dallo stato di una macchina virtuale schermata. I dati e lo stato sono crittografati, gli amministratori Hyper-V non possono vedere l’uscita video e i dischi, e le macchine virtuali possono essere limitate per essere eseguite solo su host conosciuti e sani, come determinato da un Host Guardian Server. Per i dettagli, vedere Guarded Fabric e Shielded VMs.

Priorità dell’ordine di avvio per le macchine virtuali clusterizzate (nuovo)

Questa funzione ti dà un maggiore controllo su quali macchine virtuali clusterizzate vengono avviate o riavviate per prime. Questo rende più facile avviare le macchine virtuali che forniscono servizi prima delle macchine virtuali che utilizzano tali servizi. Definisci i set, posiziona le macchine virtuali nei set e specifica le dipendenze. Usate le cmdlets di Windows PowerShell per gestire i set, come New-ClusterGroupSet, Get-ClusterGroupSet e Add-ClusterGroupSetDependency..

Storage quality of service (QoS) (aggiornato)

È ora possibile creare politiche QoS di storage su uno Scale-Out File Server e assegnarle a uno o più dischi virtuali su macchine virtuali Hyper-V. Le prestazioni dello storage vengono automaticamente riadattate per soddisfare le politiche al variare del carico dello storage. Per i dettagli, vedi Storage Quality of Service.

Formato del file di configurazione della macchina virtuale (aggiornato)

I file di configurazione della macchina virtuale usano un nuovo formato che rende la lettura e la scrittura dei dati di configurazione più efficiente. Il formato rende anche meno probabile la corruzione dei dati se si verifica un errore di memorizzazione. I file di dati di configurazione della macchina virtuale usano un’estensione di nome file .vmcx e i file di dati di stato di runtime usano un’estensione di nome file .vmrs.

Versione configurazione macchina virtuale (aggiornata)

La versione rappresenta la compatibilità dei file di configurazione, stato salvato e snapshot della macchina virtuale con la versione di Hyper-V. Le macchine virtuali con la versione 5 sono compatibili con Windows Server 2012 R2 e possono essere eseguite sia su Windows Server 2012 R2 che su Windows Server 2016. Le macchine virtuali con le versioni introdotte in Windows Server 2016 e Windows Server 2019 non verranno eseguite in Hyper-V su Windows Server 2012 R2.

Se si sposta o si importa una macchina virtuale su un server che esegue Hyper-V su Windows Server 2016 o Windows Server 2019 da Windows Server 2012 R2, la configurazione della macchina virtuale non viene aggiornata automaticamente. Questo significa che puoi spostare di nuovo la macchina virtuale su un server che esegue Windows Server 2012 R2. Ma, questo significa anche che non è possibile utilizzare le nuove funzionalità della macchina virtuale fino a quando non si aggiorna manualmente la versione della configurazione della macchina virtuale.

Per le istruzioni su come controllare e aggiornare la versione, vedere Aggiornare la versione della macchina virtuale. Questo articolo elenca anche la versione in cui sono state introdotte alcune funzioni.

Sicurezza basata sulla virtualizzazione per macchine virtuali di seconda generazione (nuovo)

La sicurezza basata sulla virtualizzazione alimenta funzioni come Device Guard e Credential Guard, offrendo una maggiore protezione del sistema operativo contro gli exploit del malware. La sicurezza basata sulla virtualizzazione è disponibile nelle macchine virtuali guest di seconda generazione a partire dalla versione 8. Per informazioni sulla versione della macchina virtuale, vedere Aggiornare la versione della macchina virtuale in Hyper-V su Windows 10 o Windows Server 2016.

Windows Containers (nuovo)

Windows Containers consente l’esecuzione di molte applicazioni isolate su un unico sistema informatico. Sono veloci da costruire e sono altamente scalabili e portatili. Sono disponibili due tipi di runtime container, ognuno con un diverso grado di isolamento delle applicazioni. I container di Windows Server usano l’isolamento dello spazio dei nomi e dei processi. I contenitori Hyper-V usano una macchina virtuale leggera per ogni contenitore.

Le caratteristiche principali includono:

• Supporto per siti web e applicazioni che usano HTTPS

• Il server Nano può ospitare sia Windows Server che Hyper-V Containers

• Possibilità di gestire i dati attraverso cartelle condivise del contenitore

• Possibilità di limitare le risorse del contenitore

Per dettagli, comprese le guide rapide, vedere la documentazione di Windows Containers.

Windows PowerShell Direct (nuovo)

Questo ti dà un modo per eseguire comandi Windows PowerShell in una macchina virtuale dall’host. Windows PowerShell Direct viene eseguito tra l’host e la macchina virtuale. Questo significa che non richiede requisiti di rete o firewall, e funziona indipendentemente dalla vostra configurazione di gestione remota.

Windows PowerShell Direct è un’alternativa agli strumenti esistenti che gli amministratori Hyper-V usano per connettersi a una macchina virtuale su un host Hyper-V:

• Strumenti di gestione remota come PowerShell o Remote Desktop

• Hyper-V Virtual Machine Connection (VMConnect)

Questi strumenti lavorano bene, ma hanno dei compromessi: VMConnect è affidabile, ma può essere difficile da automatizzare. Remote PowerShell è potente, ma può essere difficile da impostare e mantenere. Questi compromessi possono diventare più importanti man mano che la tua implementazione di Hyper-V cresce. Windows PowerShell Direct affronta questo problema fornendo una potente esperienza di scripting e automazione che è semplice come usare VMConnect.

Per i requisiti e le istruzioni, vedi Gestire le macchine virtuali Windows con PowerShell Direct.