Questo articolo è stato scritto per WindowServer.it (vedere Windows Server 2016: Introduzione ad Hyper-V) ed è aggiornato alle novità della Technical Preview 4 di Windows Server 2016.

Con la nuova edizione di Windows Server, sarà introdotta anche un nuova versione di Hyper-V (sia in modalità ruolo di Windows Server 2016 che in modalità Hyper-V Server) che prevede moltissime novità al suo interno, discusse di seguito in questo articolo.

Requisiti di Sistema

Riguardo i numeri massimi supportati e minimi richiesti ancora non vi è un documento ufficiale (vi sarà solo in RTM), ma sono comunque chiari alcuni requisiti che la nuova versione richiederà, a tale proposito vedere il documento: System requirements for Hyper-V on Windows Server 2016 Technical Preview.

Oltre alle funzioni hardware Intel-VT o AMD-V, a partire dalla TP2 è necessario anche il supporto SLAT (Second Level Address Translation) che prima era richiesta solo se veniva installato anche il ruolo RD Virtualization Host o dal Clienti Hyper-V (installabile su Windows 8/8.1). Questa funzione corrisponde al supporto hardware di tipo Intel Extended Page Tables (EPT) o AMD Rapid Virtualization Indexing (RVI).

File di Configurazione delle Macchine Virtuali

Riguardo al file di configurazione vi sono due importanti novità (a partire fin dalla TP1):

  • Il nuovo formato binario del file di configurazione (con estensione .VMCX)
  • Il concetto di versione del file di configurazione della macchina virtuale

Vi sono state diverse ragioni tecniche per abbandonare il formato XML originario del file di configurazione, ma le più importanti sono legate alla possibilità abilitare le nuove funzionalità (come le nuove «snapshot»).

Il file con estensione .VMCX sostituisce il vecchio.XML, inoltre è stato introdotto un nuovo file con estensione .VMRS che contiene i dati di Runtime della macchina virtuale (al posto del vecchio .VSV). L’aggiornamento del formato è possibile solo a VM spenta da PowerShell (Update-VmConfigurationVersion) oppure da Hyper-V Manager, come mostra la figura 1.


Figura 1 – Aggiornamento Versione

Durante l’import o la migrazione di una VM il formato non viene aggiornato, come pure in caso di upgrade di Windows.

Come accade con le VM Generation (che non sono legate al formato del file, dato che posso avere il nuovo formato sia per le Gen1 che per le Gen2), il downgrade di formato non è possibile. Legato al nuovo formato esiste anche il concetto di versione del file di configurazione che è sempre esistito, ma era rimasto ad finora ad uso interno.

Spostando o importando macchine virtuali da un server Hyper-V 2012 a un server Hyper-V 2016, la versione di configurazione della macchina virtuale rimane impostata a valore 5 (compatibilità garantita con Hyper-V 2012 R2).

Le versioni possibili sono:

  • Configuration version 2.1 quello di Windows Server 2008 R2 SP1
  • Configuration version 5 quello di Windows Server 2012 R2
  • Configuration version 6 quello di Windows Server 2016 TP1
  • Configuration version 6.2 quello Windows Server 2016 TP2
  • Configuration version 7.0 quello di Windows 10 TH2 o Windows Server TP4

Per conoscere il numero della versione di una VM è possibile utilizzare il comando PowerShell:

Get-VM nome_macchina | FT name,version

Il valore è comunque riportato anche nell’Hyper-V Manager, nelle proprietà della VM. Per maggiori informazioni vedere anche (in inglese): Virtual machine configuration file format.

VM Hot-Add e Hot-Remove

Con Windows Server 2016 le VM saranno molto più dinamiche di quanto non lo siano già ora. Già con Windows Server 2012 R2 era possibile aggiungere o togliere nuovi dischi virtuali SCSI a caldo (Windows Server 2016 TP2 aggiungere la riconfigurazione automatica della VM replica), come pure aggiungere spazio o togliere spazio (shrink) ad dischi virtuali SCSI (con le VM di topo Gen1 il disco di sistema non può essere espanso a caldo, dato che è di tipo IDE).

Queste operazioni sono supportate sia su macchine virtuali di Generazione 1 che su quelle di Generazione 2, sia per sistemi operativi Windows che Linux.

Con Windows Server 2016 TP1 sono state aggiunte le funzionalità di:

  • VM Hot-add e hot-remove della RAM
  • VM Hot-add e hot-remove delle NIC

Per la RAM delle VM, l’hot-add rappresenta un’alternativa alla Dynamic Memory (introdotta con Windows Server 2008 R2 SP1), dato che quest’ultima non è consigliata per workload come SQL o Exchange.

Supporto VM Generation 1 e 2 sia su guest OS Windows che Linux. Per le schede di rete, le schede di rete virtuali (sintetiche) possono essere aggiunte o tolte a caldo.

Questa funzione è applicabile a qualunque VM in Generation 2 e a qualunque sistema operativo supportato dalla Generation 2.

Mancherebbe solo la possibilità di aggiungere e togliere Virtual CPU….a quel punto la dinamicità delle VM sarebbe comparabile con VMware vSphere (con però la possibile di togliere memoria, come pure di ridimensionare i dischi virtuali riducendone la dimensione).

VM con Hardware Fisico

Con Windows Server 2016 TP4 è stata aggiunta una funzione di device passthrough chiamata Discrete Device Assignment, figura 2.

Fornisce la capacità di mappare un dispositivo fisico collegato all’host direttamente alla macchina virtuale, senza passare della funzioni di virtualizzazione (un po’ come avviene in VMware vSphere con VMDirectpath I/O). Ad esempio, permette di aggiungere una scheda PCI Express ad una guest VM, come se fosse una macchina fisica (ovviamente le possibilità di migrazione della macchina diventano poi limitate).


Figura 2 – Schema DDA

In realtà di funzioni di passthrough in Hyper-V già ve ne erano nelle versioni precedenti: si pensi al Disk Passthrough (concettualmente simile a RDM nel mondo VMware vSphere e presente in Hyper-V fin dalle prime versioni, anzi, fin da quando Hyper-V ancora non esisteva e si usava Virtual Server), oppure si pensi a RemoteFX per le schede video oppure al supporto SR-IOV per le schede di rete.

La differenza è che con il Discrete Device Assignment si avrà qualcosa di generico per ogni tipo di dispositivo, sfruttando funzionalità di partizionamento hardware come SR-IOV e funzionalità di virtualizzazione assistita in hardware come le Intel VT-d!

La soluzione è abbastanza generica da poter essere usata anche per virtualizzazione schede GPU (senza usare RemoteFX) o device USB.

VM Snapshot e CBT

I checkpoint sono l’implementazione delle snapshot delle VM in Hyper-V (il nome è stato unificato di recente). Snapshot che a differenza del mondo VMware non soffrono delle stesse problematiche di prestazioni e possibile inconsistenze (almeno con il nuovo formato binario delle VM introdotto in Windows Server 2016).

Una limitazione era la difficoltà di ottenere snapshot a caldo consistenti. “Consistenti” significa che questi snapshot possono essere utilizzati in tempi successivi per eventuali ripristini, con il pieno supporto Microsoft per tutti  i workload di produzione.

Con la nuova versione vengono introdotti i Production Checkpoint che utilizzano la tecnologia VSS per le VM Windows (per le macchine Linux si esegue un flush della cache del filesystem), piuttosto che utilizzare la tecnologia “Salva Stato” esterna alle macchine virtuali, che realizza snapshot solo di tipo “crash consistant”.

Con Windows Server 2016 (fin dalla TP1), i production checkpoints sono utilizzati di default, ma è possibile utilizzare i vecchi checkpoint, presenti nelle release precedenti di Hyper-V. Per maggiori dettagli vedere: Choose between standard or production checkpoints.

Notare che a differenza di VMware le “snapshot” non sono vincolanti per il backup, e lo saranno ancora meno con la prossima versione dato che è stata implementata una funzionalità di Change Block Tracking (CBT) utile per eseguire backup incrementali partendo dai file che compongono le VM.

 

Shared VHDX

I virtual disk di tipo “condiviso” sono pensati per condividere uno o più virtual disk tra due o più virtual machine, utili ad esempio per implementare “guest cluster”. La funzione era già presente in 2012 R2, ma ora è stato introdotto un nuovo tipo di virtual disk: VHD Set o anche VHDS for shared VHDX o Shared Drive – figura 3.


Figura 3 – Shared VHDX

L’aspetto interessante, che spiega anche l’introduzione di questo nuovo tipo di VHDX, è l’obiettivo del team di sviluppo di rendere le VM con shared disk equivalenti ad ogni altra VM. Già da ora sarà possibile ridimensionare a caldo i Shared VHDX, come pure sarà possibile adottare soluzioni di tipo Host Based Backup (come ad esempio Veeam) per questi dischi.

Sicuramente un grosso passo in avanti rispetto a WS2012 R2 dove i dischi “shared” si comportavano come i physical RDM di VMware con le stesse limitazioni.

Virtual Machine Storage Resiliency

A partire dalla TP2 sono stati aggiunti dei nuovi controlli per aumentare la resilienza delle VM in seguito ad interruzioni di connessione tra host e storage, figura 4. Per minimizzare l’impatto del problema, la VM viene sospesa temporaneamente, ma passato un certo periodo di tempo viene spenta. A quel punto potrà fare il failover su un altro nodo.


Figura 4 – Schema Storage Resiliency

Il comportamento è comunque controllabile tramite PowerShell disattivando la funzione e/o impostando il tempo di timeout:

Set-VM -AutomaticCriticalErrorAction <None | Pause>  

Set-VM –AutomaticCriticalErrorActionTimeout <value in minutes>

Notare che esiste una funzione specifica per i dischi VHDX condivisi, per i quali viene notificato il problema alla VM, semplicemente disconnettendo il disco. Nell’ipotesi che i VHDX condiviso sia stato utilizzato per implementare un guest cluster, sarà questo ad intervenire a spostare la risorsa sull’altra VM del nodo del guest cluster, figura 5.


Figura 5 – Shared VHDX Resiliency

VM storage è supportato con:

  • Gen1 and Gen2 VMs
  • VHD, VHDX and Shared VHDX
  • Local block storage (SAN)
    • FC, iSCSI, FCoE, SAS with Cluster Shared Volumes
  • File Based storage (NAS)
  • File shares using SMB (Server Message Block protocol) with Continuous availability such as a Scale-out File Server (SoFS)

Virtual Machine Compute Resiliency

Con quest’altra funzione è invece possibile controllare la bontà di ogni nodo del cluster Hyper-V  e gestirne eventuali “disconnessioni” temporanee dovuti diverse casistiche

  • Node disconnected: The cluster service attempts to connect to all active nodes. The disconnected (Isolated) node cannot talk to any node in an active cluster membership.
  • Cluster Service crash: The Cluster Service on a node is down. The node is not communicating with any other node.
  • Asymmetric disconnect: The Cluster Service is attempting to connect to all active nodes. The isolated node can talk to at least one node in active cluster membership.

A livello di VM è stato aggiunto un nuovo stato (Unmonitored) per identificare una VM che non è più monitorata dal servizio cluster, come mostra la figura 6.


Figura 6 – Monitoraggio via Cluster

Per i nodi sono stati invece introdotti due novi stati:

Isolated:

  • The node is no longer in an active membership
  • The node continues to host the VM role


Figura 7 – Isolated VM

Quarantine:

  • The node is no longer allowed to join the cluster for a fixed time period (default: 2 hours)­
  • This action prevents flapping nodes from negatively impacting other nodes and the overall cluster health
  • By default, a node is quarantined, if it ungracefully leaves the cluster, three times within an hour
  • VMs hosted by the node are gracefully drained once quarantined
  • No more than 25% of nodes can be quarantined at any given time


Figura 8 – Quarantine VM

VM Shielded

Se la virtualizzazione fornisce un approccio per proteggere l’host dalle VM (il principio dell’isolamento che sta proprio alla base della virtualizzazione di sistema), risulta difficile proteggere le VM dall’host o dagli amministratori degli host. In ambienti multi-tenant (come ambienti di cloud pubblico IaaS) questo potrebbe risultare un grave problema di sicurezza.

Con Windows Server 2016 è stato introtto il concetto di shielded virtual machines in gradi proteggere la VM da attacchi di vario tipo. Per maggiori informazioni vedere: Shielded VMs and Guarded Fabric Validation Guide for Windows Server 2016.

Inoltre è stata estesa la possibilità di implementare il Secure Boot anche su macchine Linux (a partire da Ubuntu 14.04, SUSE Linux Enterprise Server 12, Red Hat Enterprise Linux 7.0 e CentOS 7.0) di tipo Gen 2.

 

Aggiornamento del cluster Hyper-V

Uno dei problemi dei cluster Microsoft era la necessità di avere nodi omogenei. Con Windows Server 2016 vi sarà un cambiamento epocale e i cluster Microsoft (e quindi anche i cluster Hyper-V) potranno contenere nodi con differenti versioni di Windows Server (al momento l’unica combinazione supportata è Windows Server 2016 e Windows Server 2012 R2): sarà così possibile aggiungere un nodo Hyper-V 2016 ad un cluster Hyper-V contenente nodi Hyper-V 2012 R2, senza dover passare dalla creazione di un nuovo cluster parallelo. Il cluster così formato funzionerà in modalità di compatibilità “2012 R2″ (quindi senza poter sfruttare tutte le nuove funzionalità di Windows Server 2016) finché non saranno eliminati tutti i nodi 2012 R2.  Quando tutti i nodi saranno 2016, sarà possibile innalzare il livello di funzionamento del cluster con il comando PowerShell Update-ClusterFunctionalLevel.

Il livello di funzionalità assomiglia molto allo stesso concetto presente in Active Directory dove il livello limita le versioni di sistemi operativi che possono agire da domain controller, ma dove un livello “basso” permette la massima interoperabilità.

Questa modalità di aggiornare i cluster nodo per nodo (dove il nodo può essere aggiornato o anche sostituito con uno nuovo) può tornare utile per aggiornamenti di release, ma anche per eventuali necessità di roll-back – figura 9.


Figura 9 – Cluster Rolling Upgrade

Ovviamente la funzione di Live Migration funziona tra nodi 2012 R2 a quelli 2016, o viceversa. Quando la modalità del cluster è 2012 R2 con nodi 2016 già inseriti, bisogna tenere presente che:

  • La gestione deve essere eseguita dalla console Hyper-V 2016 o da un client Windows 10
  • La versione di configurazione delle macchine virtuali esistenti deve rimanere 5 (cioè compatibile con 2012 R2)
  • L’aggiornamento della versione di configurazione a valore 7 (compatibile solo 2016), potrà essere eseguita solo quando il livello di funzionamento del cluster è innalzato a 2016
  • Le nuove macchine virtuali create sono sempre con versione di configurazione pari a 5

Quando la modalità del cluster viene innalzata a 2016, bisogna tenere presente che:

  • La versione di configurazione di ogni macchina virtuale deve essere innalzata a 7 (da console grafica o tramite il comando PowerShell “Update-VMConfigurationVersion”) per poter sfruttare le nuove features di Hyper-V 2016
  • Non si possono più aggiungere nodi 2012 R2 al cluster

Notare che la cmdlet Update-VmConfigurationVersion è bloccata in un cluster Hyper-V con livello di funzionalità Windows Server 2012 R2.

Aggiornamento degli Integration Services

Finalmente gli aggiornamenti degli Integration Services per macchine virtuali Windows sono distribuiti tramite Windows Update. L’uso dell’immagine ISO vmguest.iso non è più necessario e lo stesso file non è più incluso in Windows Server 2016.

Gli aggiornamenti saranno disponibili per i seguenti sistemi operativi:

  • Windows Server 2012
  • Windows Server 2008 R2
  • Windows 8
  • Windows 7

Migliorie nella Gestione di Hyper-V

Da un punto di vista della gestione vi sono importanti novità:

  • Hyper-V Manager “multi-version”: tramite l’Hyper-V Manager di Windows 10 o Windows Server 2016 è finalmente possibile gestire anche versioni precedenti di Hyper-V (Windows Server 2012, Windows 8, Windows Server 2012 R2 e Windows 8.1).
  • Alternate credentials support: tramite l’Hyper-V Manager è possibile specificare un set di credenziali diverse
  • Protocolli di gestione remota: Hyper-V Manager può gestire server Hyper-V remoti utilizzando il protocollo WS-MAN (Web Services Management) su porta 80.  E’ possibile eseguire le autenticazioni tra server Hyper-V remoti utilizzando Kerberos, NTLM o CredSSP.   Usando CredSSP è possibile lanciare una Live Migration di una macchina virtuale senza prima configurare la Constrained Delegation in Active Directory (necessaria invece in piattaforma 2012).
  • PowerShell Direct: permette l’esecuzione di comandi PowerShell all’interno di una macchine virtuale direttamente dal sistema operativo della macchina host, senza bisogno di rete, firewall o configurazioni speciali. Unici prerequisiti sono: la presenza dei sistemi operativi Windows Server 2016 o Windows 10, sia sull’Host che nella macchina virtuale; credenziali amministrative complete sia sull’Host che sulla macchina virtuale. La sessione PowerShell può essere creata con il comando: Enter-PSSession -VMName nome_macchina_virtuale

Storage

A livello di storage vi sono importanti novità che che non riguardano direttamente Hyper-V, ma possono avere rilevanza diretta:

  • Per chi implementa una soluzione di Hyper-V con Scale-Out File Server esiste ora ua policy di Quality of Service (QoS) per gestire la priorità di accesso delle varie VM. Maggiori informazioni sono disponibili in Storage Quality of Service.
  • Sempre per la parte di file server è possibile ora implementare una replica sincrona (chiamata Storage Replica) ed è possibile implementare una soluzione di tipo “stretched cluster”
  • Per quanto riguarda gli storage space, con la TP2 sono stati introdotti gli Storage Space Direct che permettono l’aggregazione di dischi locali di vari nodi in un unico pool di dischi condiviso. Questi possono essere utilizzati per implementare uno Scale-Out File Server oppure direttamente come nodi Hyper-V per una soluzione iper-convergente. A partire alla TP4, sono state poi aggiunte le funzionalità di multi-tiering e supporto di virtual disk sia in mirror che in parità.


Figura 10 – Stretch Cluster

Networking

La funzinalità di Remote direct memory access (RDMA) può essere ora combinata con quella di switch embedded teaming (SET) per convergere traffico di rete e traffico di storage sulle stesse schede di rete. Per maggiori informazioni vedere Remote Direct Memory Access (RDMA) and Switch Embedded Teaming (SET).

Anche la funzione di NIC offload chiamata VMQ è stata migliorata con la nuova Virtual Machine Multi Queues (VMMQ) dove le code sono ora gestite per VM, rendendo più scalabile la soluzione. Inoltre esiste un Quality of Service (QoS) anche a livello di virtual switch.

Infine esistono altre importanti novità a livello di rete, ma non direttamente legate ad Hyper-V, come ad esempio i Network Controller per implementare una soluzione di Software Define Networking (SDN). Per maggiori informazioni vedere: What’s New in Networking in Windows Server Technical Preview.

Nested Virtualization

Altra novità introdotta è la Nested Virtualization, che permette di far girare un ambiente Hyper-V all’interno di un altro server Hyper-V. Per maggiori informazioni, potete consultare questo articolo di Silvio Di Benedetto.

Tante novità che potete provare da oggi scaricando Windows Server 2016.

Andrea MauroAbout Andrea Mauro (2790 Posts)

Virtualization, Cloud and Storage Architect. Tech Field delegate. VMUG IT Co-Founder and board member. VMware VMTN Moderator and vExpert 2010-18. Dell TechCenter Rockstar 2014-15. Microsoft MVP 2014-16. Veeam Vanguard 2015-18. Nutanix NTC 2014-18. PernixPro 2014-16. Several certifications including: VCDX-DCV, VCP-DCV/DT/Cloud, VCAP-DCA/DCD/CIA/CID/DTA/DTD, MCSA, MCSE, MCITP, CCA, NPP.


Related Post:

Share