Archivi categoria: Hyper-V

Hyper-V: Evolution, Current Innovations, and Future Developments

Since the first release of Hyper-V in Windows Server 2008, Microsoft has never ceased innovating this virtualization solution, and it has no intention of stopping. Hyper-V represents a strategic technology for Microsoft, being widely used across various areas of the IT ecosystem: from Windows Server to Microsoft Azure, from Azure Stack HCI to Windows clients and even on Xbox. This article will explore the evolution of Hyper-V from its inception, examining the current innovations that make it one of the most robust and versatile virtualization platforms available on the market today. Additionally, we will look at future developments from Microsoft for Hyper-V, discovering how this technology will help evolve the landscape of modern IT infrastructures.

The Evolution of Microsoft Virtualization: From Virtual Server to Hyper-V

Microsoft boasts a long history in virtualization, starting with the release of Microsoft Virtual Server in the early 2000s. This product was designed to facilitate the execution and management of virtual machines on Windows Server operating systems. The subsequent version, Microsoft Virtual Server 2005, introduced significant improvements in terms of management and performance, allowing companies to consolidate servers and reduce operational costs. However, this approach was still limited compared to the growing virtualization needs.

With the introduction of Windows Server 2008, Microsoft launched Hyper-V, a fully integrated virtualization solution within the operating system, marking a significant qualitative leap from Virtual Server. Hyper-V offered more robust and scalable virtualization, with support for hypervisor-level virtualization, better resource management, virtual machine snapshots, and greater integration with Microsoft’s management tools, such as System Center.

In subsequent versions of Windows Server, Hyper-V was continuously improved, introducing advanced features such as Live Migration, support for large amounts of memory and high-performance processors, and virtual machine replication for disaster recovery. These developments have consolidated Hyper-V as one of the leading virtualization platforms in the market, effectively competing with third-party solutions like VMware and Citrix.

The Present of Hyper-V: Power and Flexibility

Hyper-V is a virtualization technology that uses the Windows hypervisor, requiring a physical processor with specific features. This hypervisor manages interactions between the hardware and virtual machines, ensuring an isolated and secure environment for each virtual machine. In some configurations, virtual machines can directly access physical resources concerning graphics, network, and storage.

Hyper-V Technology in Windows Server

Hyper-V is integrated into Windows Server at no additional cost. The main difference between the Standard and Datacenter editions concerns the number of allowed guest OS instances:

Windows Server Standard: Allows up to two instances of Windows Server guest OS environments.
Windows Server Datacenter: Allows an unlimited number of Windows Server guest OS instances.

Hyper-V supports a wide range of guest operating systems, including various Linux environments such as Red Hat Enterprise Linux, CentOS, Debian, Oracle Linux, SUSE, and Ubuntu, with the relevant Integration Services included in the Linux kernel. Additionally, it supports FreeBSD starting from version 10.0.

Windows Server Datacenter, with Hyper-V, also provides access to advanced technologies like Storage Spaces Direct and software-defined networking (SDN), significantly enhancing virtualization and resource management capabilities.

Advantages of Hyper-V in Windows Server:

Effective Hardware Utilization: Allows server and workload consolidation, reducing the number of physical computers needed and optimizing hardware resource use.
Improved Business Continuity: Minimizes downtime through synergy with other Microsoft solutions, ensuring greater service availability and reliability.
Private Cloud Creation: Facilitates the creation and expansion of private and hybrid clouds with flexible and cutting-edge solutions.
Efficient Development and Testing Environments: Enables the reproduction of computing environments without additional hardware, making development and testing processes faster and more cost-effective.

The Hypervisor in the Azure Ecosystem

Azure uses Microsoft Hyper-V as the hypervisor system, demonstrating the importance and reliability of this technology for Microsoft itself, which continues to optimize it constantly. Hyper-V offers a range of advanced features that ensure a secure and shared virtualization environment for multiple customers. Among these, the creation of guest partitions with separate address spaces allows parallel execution of operating systems and applications relative to the host operating system. The root partition, or privileged partition, has direct access to physical devices and peripherals, sharing them with guest partitions through virtual devices. These elements ensure a secure and reliable environment for managing virtual machines on Azure.

Hyper-V: More Than Just a Virtualization Tool

Hyper-V is not only a powerful virtualization tool but also essential for ensuring the security of various environments. In fact, Virtualization-Based Security (VBS) leverages hardware virtualization and the hypervisor to create an isolated virtual environment, which acts as a “root of trust” for the operating system, even if the kernel is compromised. Windows uses this isolated environment to host various security solutions, offering them additional protection against vulnerabilities and preventing the use of exploits that might try to bypass existing protections. VBS imposes restrictions to protect vital system and OS resources, as well as safeguard security aspects like user credentials.

Hyper-V is also used for containers, offering isolation that ensures high security and greater compatibility between different host and container versions. Thanks to Hyper-V isolation, multiple container instances can run simultaneously on a host, with each container operating within a virtual machine using its own kernel. The presence of the virtual machine provides hardware-level isolation between each container and the container host.

Hyper-V and Azure Stack HCI

Azure Stack HCI and Hyper-V in Windows Server are two fundamental pillars in Microsoft’s virtualization solution offerings, each designed to meet different needs within the IT landscape. While Azure Stack HCI positions itself as the cutting-edge solution for hybrid environments, offering advanced integrations with Azure services for optimized management and scalability, Hyper-V in Windows Server remains a solid choice for organizations requiring more traditional virtualized solutions, with particular attention to flexibility and management in disconnected scenarios. The choice between these two solutions depends on specific virtualization needs, the organization’s cloud strategy, and the need for access to advanced management and security features.

In this regard, it is important to note that Azure Stack HCI is built on proven technologies, including Hyper-V, and meets advanced security requirements for virtualization thanks to integrated support for Virtualization-Based Security (VBS).

The Future of Hyper-V: Innovations and Prospects

The new version of Windows Server, named “Windows Server 2025,” is expected this fall. Although Microsoft has not yet announced an official release date, some predictions can be made based on previous release cycles. The company’s latest product, Windows Server 2022, was made available to the public on September 1, 2021. If Microsoft follows a similar schedule, it is likely that Windows Server 2025 will be released in the fall of this year. This version will include a new release of Hyper-V with significant new features.

Indeed, Hyper-V in Windows Server 2025 will introduce support for GPU Partitioning, allowing a GPU to be shared among multiple virtual machines. This feature will also ensure full support for Live Migration and cluster environments. GPU-P will also enable the Live Migration of VMs with partitioned GPUs between two standalone servers, without the need for a cluster environment, making it ideal for specific test and development environments. Additionally, improved support for Direct Device Assignment (DDA) and the introduction of GPU pools for high availability will further enhance Hyper-V’s capabilities.

Moreover, Windows Server 2025 will introduce “Workgroup Clusters,” simplifying Hyper-V deployments in various scenarios. Until Windows Server 2022, deploying a cluster required Active Directory (AD), complicating implementations in environments where an AD infrastructure was not always available. With Windows Server 2025, it will be possible to deploy “Workgroup Clusters” with Hyper-V that do not require Active Directory but use a certificate-based solution, significantly simplifying deployment.

For more information on the new features of Windows Server 2025, you can consult this article: Windows Server 2025: the arrival of a new era of innovation and security for server systems.

Conclusion

Hyper-V has proven to be a valuable and continuously evolving virtualization solution in the IT landscape. From its introduction with Windows Server 2008 to the innovations planned for Windows Server 2025, Hyper-V has maintained a prominent position thanks to the constant introduction of advanced features and improvements in performance, management, and security. New features such as GPU Partitioning and Workgroup Clusters are just a few examples of how Microsoft continues to invest in this technology to meet the increasingly complex needs of modern IT infrastructures. The integration of Hyper-V in various environments, from the hybrid cloud of Azure Stack HCI to traditional virtualization servers, demonstrates its versatility and strategic importance. Looking ahead, it is clear that Hyper-V will remain a key element in Microsoft’s virtualization and cloud computing strategies, continuing to offer robust and innovative solutions for the challenges of IT infrastructures.

Microsoft Hyper-V Server 2019: panoramica e caratteristiche del prodotto

Microsoft ha recentemente annunciato la disponibilità di Microsoft Hyper-V Server 2019, il prodotto di libera installazione, che consente di adottare il ruolo Hyper-V per erogare una soluzione di virtualizzazione di classe enterprise. Si tratta di un annuncio atteso da diverso tempo da molte persone per poter usufruire delle nuove funzionalità di virtualizzazione presenti in Windows Server 2019. In questo articolo vengono presentate le caratteristiche principali del prodotto e viene riportata la procedura da seguire per la relativa installazione.

Caratteristiche

Microsoft Hyper-V Server 2019 è un prodotto standalone che comprende esclusivamente i ruoli relativi alla virtualizzazione, è totalmente gratuito e include le stesse tecnologie dell’hypervisor Hyper-V presente in Windows Server 2019. Questo prodotto può essere di particolare interesse negli scenari dove non si ha la necessità di licenziare macchine virtuali Windows Server, e quando si devono mantenere in esecuzione macchine virtuali Linux oppure VDI. Tutti i sistemi operativi attivati su Hyper-V Server 2019 dovranno essere opportunamente licenziati se richiesto.

Confrontato a Windows Server il footprint è molto più piccolo, in quanto non è presente nessuna interfaccia grafica (GUI), non contiene altri ruoli ed è disponibile solo in modalità Server Core. A questo proposito è opportuno tenere in considerazione che Hyper-V Server 2019 non consente di utilizzare le funzionalità di Software Defined Datacenter come Storage Spaces Direct (S2D). Tali funzionalità richiedono la presenza di Windows Server Datacenter edition.

Installazione del prodotto

Prima di procedere con l’installazione è opportuno verificare che siano rispettati i requisiti hardware riportati nella documentazione ufficiale Microsoft.

Per ottenere Microsoft Hyper-V Server 2019 è necessario accedere nell’apposita sezione del Microsoft Evaluation Center e avviare il download della ISO. Avendo a disposizione la ISO di Hyper-V Server è possibile utilizzarla per fare il boot della macchina e iniziare l’installazione del prodotto.

La procedura di installazione non richiede nessuna chiave di licenza e non sono presenti limiti temporali per l’utilizzo. Si riportano i passaggi step by step per l’installazione del prodotto.

Figura 1 – Selezione della lingua e delle impostazioni della region

Figura 2 – Avvio del processo di installazione

Figura 3 – Accettazione dei termini di licenza

Figura 4 – Selezione del drive su cui effettuare l’installazione di Microsoft Hyper-V Server

Successivamente si avvierà l’installazione vera e propria, al termine della quale, dopo il cambio password dell’account Administrator, sarà possibile configurare Hyper-V Server 2019. La configurazione può essere fatta utilizzando il comando sconfig oppure tramite PowerShell.

Figura 5 – Configurazione del server tramite sconfig

Non è necessario effettuare l’installazione del ruolo Hyper-V in quanto risulta già attivo al termine dell’installazione.

Windows Admin Center, che consente di gestire totalmente e da interfaccia grafica l’ambiente di virtualizzazione, è possibile utilizzarlo anche per gestire Microsoft Hyper-V Server 2019.

Conclusioni

L’annuncio della disponibilità di Microsoft Hyper-V Server 2019 è arrivato dopo mesi dal rilascio ufficiale di Windows Server 2019, ma ora è utilizzabile in ambiente di produzione, e può risultare particolarmente idoneo qualora si ricada in uno degli scenari descritti in questo articolo. Microsoft Hyper-V Server 2019 è sicuramente un’ottima soluzione per adottare una piattaforma di virtualizzazione stabile e consolidata senza dover sostenere dei costi specifici per licenziare il sistema operativo dell’host di virtualizzazione, ma è opportuno tenere sempre in considerazione le relative limitazioni.

Azure Site Recovery: la protezione di macchine Hyper-V tramite Windows Admin Center

Tra le varie funzionalità che è possibile gestire tramite Windows Admin Center, esiste la possibilità di pilotare in modo semplice la protezione di macchine virtuali, presenti in ambiente Hyper-V, con Azure Site Recovery (ASR). In questo articolo vengono riportati gli step necessari da seguire e le possibilità offerte dall’Admin Center in questo ambito.

Windows Admin Center, conosciuto in passato anche con il nome di Project Honolulu, consente tramite una console web, di gestire la propria infrastruttura in modo centralizzato. Grazie a questo strumento Microsoft ha avviato un processo di centralizzazione in un unico portale di tutte le console di amministrazione, consentendo di gestire e configurare la propria infrastruttura con una esperienza utente moderna, semplice, integrata e sicura.

Windows Admin Center non richiede nessuna dipendenza con il cloud per poter funzionare e può esserne fatto il deploy localmente per ottenere il controllo di diversi aspetti della propria infrastruttura server locale. Oltre al componente Web Server, che consente di accedere tramite browser allo strumento, il Windows Admin Center è costituito da un componente gateway, grazie al quale è possibile gestire i server tramite Remote PowerShell e WMI over WinRM.

Figura 1 – Schema di base dell’architettura di Windows Admin Center

Connessione del Windows Admin Center gateway ad Azure

Windows Admin Center offre anche la possibilità di integrarsi con diversi servizi di Azure, tra i quali Azure Site Recovery. Per poter consentire al Windows Admin Center gateway di comunicare con Azure è necessario procedere con il relativo processo di registrazione, seguendo gli step in seguito documentati. La procedura guidata, al momento disponibile nella versione in preview del Windows Admin Center, effettua la creazione di una Azure AD app nella propria directory, la quale consente la comunicazione del Windows Admin Center con Azure.

Figura 2 – Avvio del processo di registrazione dalle impostazioni dell’Admin Center

Figura 3 – Generazione del codice necessario per il login

Figura 4 – Inserimento del codice nella pagina di Device Login

Figura 5 – Avvio del processo di autenticazione di Azure

Figura 6 – Conferma di avvenuto Sign-in

Figura 7 – Selezione del Tenant dove registrare l’Azure AD app

Figura 8 – Indicazioni per fornire i permessi all’Azure AD app

Figura 9 – Assegnazione dei permessi, dal portale Azure, all’app registrata

Figura 10 – Configurazione dell’integrazione con Azure completata

Configurazione ambiente ASR per la protezione delle VMs Hyper-V

Dopo aver configurato la connessione del Windows Admin Center con Azure è possibile, selezionando il sistema Hyper-V che detiene le macchine virtuali da replicare verso Azure, procedere con l’intera configurazione del Recovery Services vault, direttamente dalla console web del Windows Admin Center. Gli step sotto riportati documentano la semplicità di attivazione.

Figura 11 – Avvio della configurazione necessaria per la protezione delle VMs

Dall’Admin Center vengono richieste le informazioni di base per la configurazione dell’ambiente di ASR e viene fornita la possibilità di creare un nuovo Recovery Service vault oppure di selezionarne uno esistente.

Figura 12 – Configurazione dell’host Hyper-V in Azure Site Recovery

Nel form proposto dal Windows Admin Center vengono proposti solamente alcuni valori, pertanto consiglio di procedere prima alla creazione del Recovery Service vault e, nella schermata precedente, di selezionarne uno esistente, creato con tutti i parametri di configurazione a piacimento e in base alle proprie esigenze.

Questo step effettua le seguenti azioni:

Installa l’agente di ASR sul sistema Hyper-V oppure su tutti i nodi nel caso di un ambiente cluster.
Se si seleziona di creare un nuovo vault procede alla relativa creazione nella region scelta e lo posiziona in un nuovo Resource Group (assegnandogli un nome di default).
Effettua la registrazione del sistema Hyper-V con ASR e configura una policy di replica di default.

Figura 13 – Site Recovery Jobs generati dalla configurazione

Configurazione della protezione delle macchine virtuali

Completate le attività di configurazione precedentemente riportate è possibile attivare la protezione delle macchine virtuali.

Figura 14 – Attivazione del processo di protezione della VM

Figura 15 – Selezione dello storage account e avvio della protezione

Al termine del processo di replica è possibile validare il processo di replica azionando la procedura di test failover dal portale Azure.

Conclusioni

Poter interagire con determinati servizi di Azure direttamente da Windows Admin Center può facilitare e velocizzare l’amministrazione del proprio datacenter ibrido. Al momento le possibilità offerte di integrazione con Azure Site Recovery sono minimali e idonee per scenari non complessi. Tuttavia, Windows Admin Center è in costante evoluzione e sarà sempre di più arricchito di nuove funzionalità per poter interagire al meglio anche con i servizi Azure.

Le novità introdotte in Virtual Machine Manager 1807

In seguito al primo annuncio della Semi-Annual Channel release di System Center, avvenuto nel mese di febbraio con la versione 1801, nel mese di giugno è stata rilasciata la nuova update release: System Center 1807. In questo articolo saranno approfondite le nuove funzionalità introdotte in System Center Virtual Machine Manager (SCVMM) dall’update release 1807.

Networking

Informazioni relative alla rete fisica

SCVMM 1807 ha introdotto un importante miglioramento in ambito network. Infatti, utilizzando il Link Layer Discovery Protocol (LLDP), SCVMM è in grado di fornire informazioni per quanto riguarda la connettività alla rete fisica degli host Hyper-V. Questi i dettagli che SCVMM 1807 è in grado di recuperare:

Chassis ID: Switch chassis ID
Port ID: Porta dello Switch alla quale la NIC è connessa
Port Description: Dettagli relative alla porta, come ad esempio il Type
System Name Manufacturer: Manufacturer e dettagli sulla versione Software
System Description
Available Capabilities: Funzionalità disponibili del sistema (come ad esempio switching, routing)
Enabled Capabilities: Funzionalità abilitate sul sistema (come ad esempio switching, routing)
VLAN ID: Virtual LAN identifier
Management Address: Indirizzo IP di management

La consultazione di queste informazioni può avvenire tramite Powershell oppure accedendo alla console di SCVMM: View > Host > Properties > Hardware Configuration > Network adapter.

Figura 1 – Informazioni fornite da SCVMM 1807 in merito alla connettività fisica degli host Hyper-V

Questi dettagli risultano molto utili per avere visibilità sulla rete fisica e per facilitare le operazioni di troubleshooting. Tali informazioni saranno rese disponibili per gli host Hyper-V che rispettano i seguenti requisiti:

Sistema operativo Windows Server 2016 o successivo.
Feature DataCenterBridging e DataCenterBridging-LLDP-Tools abilitate.

Conversione SET in Logical Switch

SCVMM 1807 consente di convertire un Virtual Switch di Hyper-V, creato nella modalità Switch Embedded Teaming (SET), in un logical switch, utilizzando direttamente la console di SCVMM. Nelle precedenti versioni di SCVMM tale operazione era fattibile solamente tramite comandi PowerShell. Questa conversione può risultare utile per generare un Logical Switch, utilizzabile come template su differenti host Hyper-V gestiti da SCVMM. Per maggiori informazioni sui Switch Embedded Teaming (SET) vi invito a consultare l’articolo Windows Server 2016: La nuova modalità di creazione dei Virtual Switch in Hyper-V

Supporto per host VMware ESXi v6.5

SCVMM 1807 ha introdotto il supporto di host VMware ESXi v6.5 all’interno della propria fabric. Per quella che è la mia esperienza, anche in ambienti costituiti da più hypervisors, difficilmente si utilizza SCVMM per la gestione di host VMware. Tale supporto è però importante in quanto introduce la possibilità di convertire VMs ospitate su host VMWare ESXi 6.5 in VMs di Hyper-v.

Storage

Supporto per la selezione del CSV da utilizzare durante l’aggiunta di un nuovo disco

SCVMM 1807 consente di specificare, durante l’aggiunta di un nuovo disco virtuale a una VM esistente, in quale cluster shared volumes (CSV) posizionarlo. Nelle precedenti release di VMM non veniva fornita questa possibilità e i nuovi dischi virtuali di default venivano posizionati sullo stesso CSV dove erano presenti i dischi già associati alla macchina virtuale. In alcune circostanze, come ad esempio in presenza di CSV con poco spazio libero a disposizione, questo comportamento poteva risultare non adeguato e poco flessibile.

Figura 2 – Aggiunta di un nuovo disco a una VM selezionando su quale CSV posizionarlo

Supporto per l’update di cluster Storage Spaces Direct (S2D)

In Virtual Machine Manager 2016 è presente il supporto per effettuare il deployment di cluster Storage Spaces Direct (S2D). Con SCVMM 1807 è stata introdotta anche la possibilità di fare patching e update dei nodi di cluster Storage Spaces Direct, orchestrando l’intero processo di update, che sfrutterà le baseline configurate in Windows Server Update Services (WSUS). Questa funzionalità consente di gestire in modo più efficace l’ambiente Storage Spaces Direct, punto cardine del Software Defined Storage di casa Microsoft, che porta al raggiungimento del Software Defined Data Center.

Statement di supporto

Supporto per SQL Server 2017

In SCVMM 1807 è stato introdotto il supporto per SQL Server 2017 per ospitare il relativo database. Questo consente di effettuare l’upgrade da SQL Server 2016 a SQL Server 2017.

Conclusioni

L’update release 1807 introduce in Virtual Machine Manager diverse novità che lo arricchiscono notevolmente in termini di funzionalità. Inoltre, questo aggiornamento risolve anche una serie di problematiche riportate nella documentazione ufficiale Microsoft. Si consiglia quindi di valutare un aggiornamento delle implementazioni di Virtual Machine Manager, per avere una maggiore stabilità e per poter usufruire delle nuove features introdotte. Si ricorda che le release appartenenti al Semi-Annual Channel hanno un periodo di supporto di 18 mesi.

Per provare System Center Virtual Machine Manager è necessario accedere all’Evaluation Center e dopo essersi registrati è possibile avviare il periodo di trial.

Azure Site Recovery: il disaster recovery di macchine virtuali VMware

La soluzione Azure Site Recovery (ASR) consente di proteggere sistemi fisici oppure virtuali, ospitati sia in ambiente Hyper-V che VMware, automatizzando il processo di replica verso un datacenter secondario oppure verso Microsoft Azure. Con un’unica soluzione è possibile implementare piani di Disaster Recovery per ambienti eterogenei orchestrando in modo funzionale il processo di replica e le azioni necessarie per il corretto ripristino. Grazie a questa soluzione il proprio piano di DR sarà facilmente usufruibile in qualsiasi evenienza, anche la più remota, per garantire la business continuity. Recentemente la soluzione è stata ampliata prevedendo anche la possibilità di implementare una strategia di disaster recovery per macchine virtuali in Azure, consentendo di attivare la replica tra differenti region.

In questo articolo verrà mostrato come ASR può essere utilizzato per replicare macchine virtuali in ambiente VMware verso Azure (scenario 6 della figura seguente), esaminando le caratteristiche e la procedura tecnica da seguire. Nell’immagine seguente sono riportati tutti gli scenari attualmente contemplati dalla soluzione ASR:

Figura 1 – Scenari contemplati da Azure Site Recovery

Lo scenario di replica di macchine virtuali VMware verso Azure richiede la presenza della seguente architettura:

Figura 2 – Architettura nello scenario di replica di sistemi VMware verso Azure

Per poter attivare il processo di replica è necessaria la presenza di almeno un server on-premises su cui vengono installati i seguenti ruoli:

Configuration Server: coordina le comunicazioni tra il mondo on-premises ed Azure, e gestisce la replica dei dati.
Process Server: questo ruolo di default viene installato insieme al Configuration Server, ma possono essere previsti più sistemi Process Server in base al volume di dati da replicare. Agisce come replication gateway, quindi riceve i dati di replica, ne effettua un’ottimizzazione tramite meccanismi di cache e compressione, provvede all’encryption e li invia verso lo storage in ambiente Azure. Questo ruolo ha inoltre il compito di effettuare il discovery delle macchine virtuali sui sistemi VMware.
Master target server: anche questo ruolo viene installato di default insieme al Configuration Server, ma per deployment con un numero elevato di sistemi possono essere previsti più server con questo ruolo. Entra in azione durante il processo di failback delle risorse da Azure gestendo i dati di replica.

Su tutte le macchine virtuali sottoposte al processo di replica è necessaria la presenza del Mobility Service, che viene installato dal Process Server. Si tratta di un agente specifico che si occupa di replicare i dati presenti nella macchina virtuale.

In seguito viene descritto il processo da seguire per effettuare il deployment dei componenti on-premises e nel mondo Azure necessari per attivare la replica delle macchine virtuali VMware verso la cloud pubblica di Microsoft.

Il componente core necessario lato Azure è il Recovery Service Vault all’interno del quale, nella sezione Site Recovery, è possibile avviare il processo di configurazione pilotato per lo scenario di protezione prescelto.

Figura 3 – Scelta dello scenario di replica di macchine virtuali VMware all’interno del Recovery Service Vault

Successivamente è necessario procedere all’installazione sulla macchina on-premises del Configuration Server seguendo gli step indicati:

Figura 4 – Step da seguire per aggiungere il Configuration Server

In questa sezione del portale Azure è possibile scaricare il Microsoft Azure Site Recovery Unified Setup e la chiave necessaria per la registrazione del server al vault. Prima di avviare il setup accertarsi che la macchina su cui si intende installare il ruolo di Configuration Server sia in grado di accedere agli URL pubblici del servizio Azure e che durante il setup sia consentito il traffico web su porta 80 necessario per effettuare il download del componente MySQL utilizzato dalla soluzione.

Avviando il setup vengono richieste le seguenti informazioni:

Figura 5 – Scelta dei ruoli da installare

Selezionare la prima opzione per l’installazione del ruolo Configuration Server e Process Server. La seconda opzione è utile nel caso si debbano installare ulteriori Process Server per consentire uno scale out del deployment.

Figura 6 – Accettazione del license agreement di MySQL Community Server

Figura 7 – Selezione della chiave necessaria per la registrazione al Site Recovery Vault

Figura 8 – Scelta della metodologia per accedere ai servizi Azure (diretta o tramite proxy)

Figura 9 – Check di verifica dei prerequisiti

Figura 10 – Impostazione delle password relative a MySQL

Figura 11 – Ulteriore check sulla presenza dei componenti necessari per proteggere VMs VMware

Figura 12 – Scelta del path di installazione

L’installazione richiede indicativamente 5 GB di spazio a disposizione, ma sono consigliati almeno 600 GB per la cache.

Figura 13 – Selezione dell’interfaccia di rete e della porta da utilizzare per il traffico di replica

Figura 14 – Summary delle scelte di installazione

Figura 15 – Setup dei diversi ruoli e componenti completato con successo

Al termine del setup viene mostrata la connection passphrase che viene utilizzata dal Configuration Server, che è bene salvare con cura.

In seguito è necessario configurare le credenziali che verranno utilizzate da Azure Site Recovery per effettuare il discovery delle macchine virtuali nell’ambiente VMware e per effettuare l’installazione del Mobility Service sulle macchine virtuali.

Figura 16 – Definizioni delle credenziali utilizzate dal servizio

Completate queste operazioni sarà possibile selezionare il Configuration Server dal portale Azure e successivamente definire i dati del sistema VMware (vCenter oppure vSphere) con cui interfacciarsi.

Figura 17 – Selezione del Configuration Server e aggiunta vCenter/vSphere host

Conclusa questa configurazione è necessario attendere alcuni minuti per consentire al Process Server di effettuare il discovery delle macchine virtuali sull’ambiente VMware specificato.

In seguito occorre definire le impostazioni relative al target della replica:

Su quale sottoscrizione e con quale recovery model creare i sistemi.
Quale storage account utilizzare per ospitare i dati replicati.
vNet su cui attestare i sistemi replicati.

Figura 18 – Impostazioni relative al Target della replica

Lo step successivo prevede la definizione delle policy di replica in termini di RPO (espresso in minuti), retention dei recovery point (espresso in ore) e frequenza con cui effettuare delle snapshot consistenti a livello di applicazione.

Figura 19 – Creazione della policy di replica

Al termine di questa attività viene proposto di effettuare l’analisi del proprio ambiente tramite il tool Deployment Planner (scaricabile direttamente tramite il link riportato nel portale Azure) al fine di accertarsi di avere i requisiti, le risorse network e le risorse storage sufficienti per garantire il corretto funzionamento della soluzione.

Figura 20 – Step di preparazione dell’infrastruttura completati con successo

Terminati gli step di preparazione dell’infrastruttura è possibile attivare il processo di replica:

Figura 21 – Source e Target di replica

Figura 22 – Selezione delle macchine virtuali e dei relativi dischi da replicare

In questa sezione viene anche specificato quale account il Process Server utilizzerà per effettuare l’installazione del Mobility Service su ogni macchina virtuale VMware (account configurati in precedenza come documentato nella Figura 16).

Figura 23 – Selezione della policy di replica e abilitazione facoltativa della Multi-VM consistency

Nel caso venga selezionata l’opzione “Multi-VM consistency” verrà creato un Replication Group all’interno del quale verranno inserite le VMs che si desidera replicare insieme per utilizzare recovery point condivisi. Questa opzione è consigliata solo quando è necessaria una consistenza durante il processo di Failover su più macchine virtuali che erogano lo stesso workload. Inoltre attivando questa opzione è bene tenere in considerazione che per attivare il processo di Failover dei sistemi è necessario configurare un Recovery Plan specifico e non è possibile attivare il Failover per una singola macchina virtuale.

Al termine di queste configurazioni è possibile attivare il processo di replica

Figura 24 – Attivazione del processo di replica e relativo esito

Figura 25 – Stato della replica della macchina virtuale VMware

Una delle difficoltà maggiori quando si implementa uno scenario di Disaster Recovery è avere la possibilità di testarne il funzionamento senza impattare i sistemi di produzione ed il relativo processo di replica. Altrettanto vero è che non testare in modo appropriato il processo di DR equivale quasi a non averlo. Azure Site Recovery consente di testare in modo molto semplice la procedura di Disaster Recovery per valutarne la reale efficacia:

Figura 26 – Test della procedura di Failover

Figura 27 – Esito del processo di Test Failover

Conclusioni

Poter contare su un’unica soluzione come Azure Site Recovery che consente di attivare e testare procedure per la business continuity in infrastrutture eterogenee, contemplando anche macchine virtuali in ambiente VMware, ha sicuramente numerosi vantaggi in termini di flessibilità ed efficacia. ASR consente infatti di affrontare gli ostacoli tipici che si incontrano durante la realizzazione di piani di Disaster Recovery riducendo i costi e la complessità ed aumentando i livelli di compliance. La stessa soluzione può essere inoltre utilizzata per affrontare la migrazione vera e propria dei sistemi verso Azure con un impatto minimo sull’utenza finale grazie a downtime degli applicativi vicini allo zero.

Windows Server 2016: Introduzione agli Hyper-V VHD Set

In Windows Server 2016 una nuova e interessante funzionalità è stata introdotta in ambito Hyper-V ed è chiamata VHD Set. Si tratta di una nuova modalità di creazione dei dischi virtuali che necessitano di essere condivisi tra più macchine virtuali, utile per implementare guest cluster. In questo articolo verranno approfondite le caratteristiche dei VHD Set, verrà spiegato come implementarli al meglio e come affrontare in modo efficace scenari di migrazione.

Caratteristiche

La possibilità di condividere dischi virtuali tra più macchine virtuali è necessaria per realizzare configurazioni guest cluster che richiedono la presenza di storage condiviso e per evitare di dover configurare l’accesso allo storage tramite ad esempio HBA virtuali oppure attraverso l’utilizzo del protocollo di comunicazione iSCSI.

Figura 1 – VHD Set

In ambito Hyper-V questa funzionalità è stata introdotta con Windows Server 2012 R2 con la tecnologia chiamata Shared VHDX, la quale presenta i seguenti importanti limiti che spesso ne impediscono l’utilizzo in ambiente di produzione:

Il backup degli Shared VHDX deve avvenire con agenti specifici e non è supportato il backup host based
Non sono supportati scenari di replica Hyper-V
Il resize online di Shared VHDX non è contemplato

Con Hyper-V in Windows Server 2016 è stata rivoluzionata questa funzionalità con l’introduzione dei VHD Set al posto degli Shared VHDX che rimuove le limitazioni sopra elencate rendendola una tecnologia matura e affidabile anche per gli ambienti di produzione. Infatti le macchine virtuali configurate per accedere ai VHD Set è possibile proteggerle tramite backup host based, senza dover installare agenti sulle macchine guest. In questo caso è comunque consigliata una verifica per stabilire se la soluzione di backup in uso supporta questa configurazione. Inoltre i dischi nel formato VHD Set supportano il ridimensionamento online, senza la necessità di dover fermare il guest cluster configurato per accederci. Anche la replica Hyper-V supporta i dischi nel formato VHD Set consentendo di implementare scenari di disaster recovery anche per configurazioni guest cluster.

Al momento le uniche limitazioni nell’utilizzo dei VHD Set sono date dal mancato supporto per la creazione di checkpoint delle macchine virtuali che ci accedono e dall’impossibilità di effettuare delle storage live migration di macchine virtuali con VHD Set. L’obiettivo di Microsoft per il futuro è comunque di rendere le macchine virtuali configurate con VHD Set paritetiche a tutte le altre in termini di funzionalità.

Requisiti per l’utilizzo di VHD Set

Il formato VHD Set è supportato solamente per sistemi operativi guest Windows Server 2016. Inoltre per poter configurare guest cluster dove le macchine virtuali accedono a dischi virtuali condivisi è necessario rientrare in uno dei seguenti scenari:

Hyper-V failover cluster con tutti i file delle VMs, compresi i dischi nel formato VHD Set, che risiedono su un Cluster Shared Volumes (CSV).
Hyper-V failover cluster che ha come storage location per i VHD Set una share SMB 3.0 erogata da uno Scale Out File Server (SOFS).

Figura 2 – Scenari supportati per l’utilizzo di dischi virtuali condivisi

Come Creare VHD Set

La creazione di dischi virtuali nel formato VHD Set può essere fatta sia da interfaccia grafica (GUI) che tramite Powershell. Per crearli tramite GUI è sufficiente aprire Hyper-V Manager e dal riquadro Actions selezionare New, Hard Disk. Tra i possibili formati sarà presente anche VHD Set come mostrato nella figura seguente:

Figura 3 – Selezione del formato nel wizard di creazione dei dischi virtuali

Proseguendo con il Wizard è possibile specificare se il disco deve essere di tipologia Fixed piuttosto che Dynamic, il nome, la location e la relativa dimensione nel caso si scelga di creare un nuovo disco blank. La stessa operazione può essere svolta anche utilizzando il cmdlet Powershell New-VHD, specificando come estensione del disco virtuale la nuova estensione .vhds, come mostrato dall’esempio seguente:

Figura 4 – Esempio di creazione di un disco nel formato VHD Set utilizzando Powershell

La creazione del disco nel formato VHD Set comporta la creazione nel percorso specificato dei seguenti file:

Figura 5 – File generati dalla creazione di un disco nel formato VHD Set

Il file con estensione .avhdx contiene i dati e può essere fixed o dynamic in base alla scelta fatta durante la creazione, mentre il file .vhds contiene i metadati necessari per coordinare l’accesso dai differenti nodi del guest cluster.

Configurazione delle Macchine Virtuali con Dischi VHD Set

Per poter aggiungere i dischi nel formato VHD Set alle macchine virtuali è sufficiente modificare le proprietà delle stesse e configurare in modo opportuno il collegamento al controller SCSI:

Figura 6 – Aggiunta dello Shared Drive nelle proprietà della VM

Successivamente è necessario selezionare la location del file:

Figura 7 – Configurazione della location del drive condiviso

La stessa operazione sarà necessario svolgerla per tutte le macchine virtuali che costituiranno il guest cluster. In seguito alla configurazione dello storage condiviso, che comporta l’aggiunta alle macchine virtuali dei dischi nel formato VHS Set, è possibile proseguire con la configurazione dell’ambiente guest cluster secondo la procedura standard di creazione di un cluster descritta nella documentazione ufficiale Microsoft.

Conversione di Shared VHDX in VHD Set

In scenari di aggiornamento dell’infrastruttura Hyper-V da Windows Server 2012 R2 a Windows Server 2016, può capitare di dover affrontare la migrazione di Shared VHDX in VHD Set per poter usufruire di tutti i vantaggi apportati nella nuova tecnologia di condivisione dei dischi virtuali. Il passaggio a Windows Server 2016 non comporta nessun aggiornamento automatico degli Shared VHDX in VHD Set ed è comunque consentito continuare ad utilizzare i dischi condivisi nel formato Shared VHDX anche in Windows Server 2016. Per poter migrare gli Shared VHDX nel formato VHD Set è necessario seguire la seguente procedura manuale:

Spegnere tutte le macchine virtuali connesse allo Shared VHDX che si intende migrare.
Scollegare lo Shared VHDX da tutte le VMs tramite il cmdlet Powershell Remove-VMHardDiskDrive oppure utilizzando Hyper-V Manager.
Avviare la conversione dello Shared VHDX nel formato VHD Set tramite il cmdlet Powershell Convert-VHD
Collegare il disco appena convertito nel formato VHD Set a tutte le VMs utilizzando il cmdlet Powershell Add-VMHardDiskDrive oppure utilizzando Hyper-V Manager.
Accendere le macchine virtuali connesse al VHD Set.

Quando si utilizzano dischi nel formato VHD Set possono essere utili i seguenti cmdlet Powershell:

Get-VHDSet: utile per visualizzare diverse informazioni relative al disco nel formato VHD Set, compresa la lista di eventuali checkpoint.
Optimize-VHDSet: necessario per ottimizzare l’allocazione dello spazio utilizzato dal disco nel formato VHD Set.

Conclusioni

In Windows Server 2016 l’introduzione dei VHD Set in ambito Hyper-V consente di implementare in modo semplice architetture guest cluster senza dover utilizzare tecnologie di condivisione dello storage che richiedono configurazioni più laboriose e complesse. Inoltre sono state rimosse buona parte delle limitazioni riguardanti la metodologia di condivisione dei dischi virtuali, presenti nella precedente versione di Hyper-V, rendendo VHD Set una tecnologia matura, affidabile e di conseguenza utilizzabile anche in ambienti di produzione.

Virtual Machine Manager 2016: Installazione dell’agente in Windows Server 2016 (Server Core)

In questo articolo verranno riportate le operazioni che sono necessarie al fine di installare via push l’agente di Virtual machine Manager 2016 su un server Windows Server 2016 installato nella modalità Server Core, che è sicuramente la scelta di installazione più comune per i sistemi Hyper-V.

Iniziamo con il precisare che durante l’installazione di Windows Server 2016 il wizard richiede di scegliere una delle seguenti opzioni:

Windows Server 2016 che equivale all’installazione in modalità Server Core. Si tratta della modalità di installazione server consigliata a meno di particolari esigenze che prevedono l’utilizzo dell’interfaccia utente oppure dei tool grafici di gestione in quanto richiede un utilizzo inferiore dello spazio disco, diminuisce la potenziale superficie di attacco e riduce sensibilmente l’effort di gestione. In questa modalità di installazione non è presente l’interfaccia utente standard (“Server Graphical Shell”) e per gestire il server è necessario utilizzare la command line, Windows PowerShell oppure è possibile farlo da un sistema remoto.
Windows Server (Server con Desktop Experience) che corrisponde all’equivalente della versione Full di Windows Server 2012 R2 con installata la feature “Desktop Experience”.

A differenza delle precedenti versioni di Windows Server non c’è la possibilità di convertire un’installazione in modalità Server Core in una installazione Server con la Desktop Experience o viceversa, l’unica possibilità di conversione è effettuare una nuova installazione del sistema operativo.

In Windows Server 2016 è possibile usare anche la modalità Nano Server (per i possessori della Datacenter Edition) per aver un footprint ulteriormente ridotto. Per maggiori informazioni in merito a Nano Server vi invito a consultare i seguenti articoli Windows Server 2016: Introduzione a Nano Server e Windows Server 2016: Usare Nano Server Image Builder.

Tentando di effettuare l’installazione push dell’agente di VMM 2016 su una installazione di default di Windows Server 2016 (Server Core) si riceverà il seguente messaggio di errore in quanto è necessario effettuare una serie di task preliminari:

Figura 1 – Errore di VMM 2016 su installazione di default di WS2016

Consultando i dettagli dell’errore si viene indirizzati verso una serie di controlli che è opportuno effettuare e che richiedono diverse azioni correttive.

Ensure ‘Host’ is online and not blocked by a firewall.

Il primo punto è ovvio e richiede che il sistema sia online e che non ci siano sistemi firewall che blocchino la comunicazione dal server VMM.

Ensure that file and printer sharing is enabled on ‘Host’ and it not blocked by a firewall.

Utilizzando il commando seguente è possibile verificare che in effetti di default la regola del firewall ‘File and Printer Sharing (Echo Request – ICMPv4-In)’ non è abilitata. Nell’immagine seguente è riportato il comando necessario per consentire questo tipo di traffico in ingresso:

Figura 2 – Gestione regola del firewall ‘File and Printer Sharing (Echo Request – ICMPv4-In)‘

Ensure that WMI is enabled on ‘Host’ and it not blocked by a firewall.

Situazione analoga anche per quanto riguarda la regola del firewall per consentire il traffico Windows Management Instrumentation (WMI) in ingresso, di default non è attiva ed è necessario abilitarla:

Figura 3 – Gestione regola del firewall ‘Windows Management Instrumentation (WMI-In)‘

Ensure that there is sufficient free space on the system volume.

Naturalmente è necessario verificare che sul volume di Sistema ci sia spazio disco a sufficienza per l’installazione dell’agente di VMM che richiede poche decine di MB.

Verify that the ADMIN$ share on ‘Host’ exists. If the ADMIN$ share does not exist, restart ‘Host’ and then try the operation again.

Durante la prima fase di installazione push dell’agente VMM viene effettuata la copia del setup nella share ADMIN$ del server remoto. Windows Server 2016 installato in modalità server core è privo del ruolo File Server:

Figura 4 – Verifica presenza ruolo File Server

Di default è presente invece la feature per il supporto al protocollo SMB v1.0 / CIFS che nel caso specifico può essere tranquillamente rimossa in quanto non necessaria.

Per consentire l’accesso alla share ADMIN$ è quindi necessario aggiungere il ruolo File Server utilizzando il seguente comando Powershell:

Figura 5 – Installazione ruolo File Server e rimozione feature per supporto SMB v1.0 / CIFS

Terminate queste operazioni è possibile effettuare l’installazione push dell’agente di VMM 2016 su una installazione di default di Windows Server 2016 (Server Core):

Figura 6 – Job di installazione dell’agente di VMM completato con successo

Conclusioni

In Windows Server 2016 installato in modalità Server Core task semplici come l’installazione push dell’agente di VMM 2016 richiedono una attenta ed opportuna configurazione del sistema, nonostante questo ritengo che questa modalità di installazione sia la scelta più appropriata nella maggior parte dei deployment di Hyper-V.

Windows Server 2016: La nuova modalità di creazione dei Virtual Switch in Hyper-V

In questo articolo approfondiremo le caratteristiche e vedremo come configurare un Virtual Switch di Hyper-V in Windows Server 2016 nella modalità Switch Embedded Teaming (SET). Si tratta di una nuova tecnologia, alternativa al NIC Teaming, che consente di avere più schede di rete dell’host fisico di virtualizzazione in join allo stesso Virtual Switch di Hyper-V.

Con Windows Server 2012 era stata introdotta la possibilità di creare in modo nativo dal sistema operativo un teaming di rete (fino a un massimo di 32 schede di rete) senza dover installare software specifici dei vendor. Sugli host di virtualizzazione era pratica comune definire dei virtual switch di Hyper-V attestandoli su questi NIC teaming. Per avere quindi alta disponibilità e bilanciare il traffico di rete delle macchine virtuali era necessario unificare questi due differenti costrutti, il Team di rete e il Virtual Switch di Hyper-V. Utilizzando questa configurazione è opportuno specificare che il teaming tradizione LBFO (Load Balancer Fail Over) non era compatibile con la tecnologia RDMA.

In Windows Server 2016 è stata introdotta una ulteriore possibilità per quanto riguarda la configurazione dei Virtual Switch di Hyper-V chiamata Switch Embedded Teaming (SET), figura 1, la quale consente di unificare più schede di rete (fino a un massimo di 8) in un unico Virtual Switch senza configurare nessun teaming. SET ingloba infatti le funzionalità di teaming di rete all’interno del Virtual Switch consentendo di ottenere elevate performance e fault tolerance a fronte di guasti hardware delle singole NIC. In questa configurazione c’è la possibilità di abilitare la tecnologia RDMA sulle singole schede di rete e di conseguenza viene a decadere la necessità di avere set di NIC separati (uno per l’utilizzo con i Virtual Switch e uno per utilizzare la tecnologia RDMA).

Figura 1 – Architettura SET

Quando si valuta l’adozione della modalità Switch Embedded Teaming (SET) è importante considerare le compatibilità con le altre tecnologie relative al networking.

SET risulta compatibile con:

Datacenter bridging (DCB)
Hyper-V Network Virtualization sia in modalità NVGRE che VxLAN
Receive-side Checksum offloads (IPv4, IPv6, TCP) – Se supportato dal modello hardware delle NIC
Remote Direct Memory Access (RDMA)
SDN Quality of Service (QoS)
Transmit-side Checksum offloads (IPv4, IPv6, TCP) – Se supportato dal modello hardware delle NIC
Virtual Machine Queues (VMQ)
Virtual Receive Side Scalaing (RSS)

SET risulta invece non compatibile con le seguenti tecnologie di rete:

1X authentication
IPsec Task Offload (IPsecTO)
QoS (implementato lato host)
Receive side coalescing (RSC)
Receive side scaling (RSS)
Single root I/O virtualization (SR-IOV)
TCP Chimney Offload
Virtual Machine QoS (VM-QoS)

Differenze rispetto al NIC Teaming

Switch Embedded Teaming (SET) si differenzia dal tradizionale NIC Teaming in particolare per i seguenti aspetti:

Quando si fa un deployment di SET non è supportato utilizzare NIC in modalità standby, ma tutte le schede di rete devono essere attive;
Non è possibile assegnare un nome specifico al team, ma solamente al Virtual Switch;
SET supporta solamente la modalità Switch Independent, mentre il NIC teaming ha diverse modalità di funzionamento. Questo significa che gli switch di rete, dove le NIC che appartengono a SET vengono attestate, non sono a conoscenza della presenza di questa configurazione e di conseguenza non introducono nessun controllo su come distribuire il traffico di rete tra i differenti membri.

In fase di configurazione di SET è necessario solamente specificare quali schede di rete appartengono al team e il meccanismo di bilanciamento del traffico.

Un Virtual Switch in modalità SET deve essere composto da schede di rete certificate da Microsoft che hanno superato i test di compatibilità “Windows Hardware Qualification and Logo (WHQL)“ per Windows Server 2016. Un aspetto importante è che le NIC devono essere identiche in termini di marca, modello, driver e firmware.

Per quanto riguarda come viene distribuito il traffico di rete tra i differenti membri di SET sono disponibili due modalità: Hyper-V Port e Dynamic.

Hyper-V Port

In questa configurazione il traffico di rete viene suddiviso tra i diversi membri del team in base all’associazione porta del virtual switch e MAC address della macchina virtuale connessa. Questa modalità è particolarmente adatta quando si utilizza in congiunzione alla tecnologia Virtual Machine Queues (VMQs). Bisogna inoltre considerare che nel caso in cui siano presenti poche macchine virtuali sull’host di virtualizzazione si potrebbe non avere un bilanciamento omogeneo del traffico essendo un meccanismo poco granulare. In questa modalità inoltre la banda disponibile per una scheda di rete di una macchina virtuale (con il traffico proveniente quindi sempre da una singola porta dello switch) è sempre limitata alla banda disponibile sulla singola interfaccia di rete.

Dynamic

Questo meccanismo di load balancing ha le seguenti caratteristiche:

Il traffico in uscita viene distribuito (sulla base di un hash porte TCP e indirizzi IP) secondo il principio denominato flowlets (basato sulle interruzioni presenti nei flussi delle comunicazioni TCP). Inoltre in modalità Dynamic è presente un meccanismo di ri-bilanciamento del traffico in real time tra i vari membri di SET.
Il traffico in ingresso invece viene distribuito esattamente come nella modalità Hyper-V Port.

Per quanto riguarda la configurazione di SET così come per tutti i componenti appartenenti al software-defined networking (SDN) è consigliato adottare System Center Virtual Machine Manager (VMM). Nella configurazione del Logical Switch è sufficiente selezionare “Embedded” nell’Uplink Mode così come viene mostrato nella figura 2.

Figura 2 – Configurazione SET in VMM

Come alternativa per la configurazione di SET è possibile utilizzare i seguenti comandi PowerShell:

Creazione Virtual Switch in modalità SET

Il parametro EnableEmbeddedTeaming per la creazione di un team SET è opzionale nel caso siano elencate più schede di rete, ma risulta utile quando si vuole configurare un Virtual Switch in questa modalità con una singola scheda di rete per essere esteso con ulteriori NIC successivamente.

Modifica dell’algoritmo di distribuzione del traffico

Conclusioni

Grazie a questo nuovo meccanismo di creazione dei Virtual Switch introdotto in Hyper-V 2016 è possibile avere una maggiore flessibilità nella gestione del networking riducendo il numero di schede di rete e la complessità di configurazione, senza rinunciare ad elevate performance e all’alta disponibilità.

Windows Server 2016: What’s New in Hyper-V

Windows Server 2016 è stato ufficialmente rilasciato e molte sono le novità introdotte relative ad Hyper-V che lo rendono sempre più una potente piattaforma di virtualizzazione ricca di nuove e interessanti funzionalità. In questo articolo verranno riportate le nuove funzionalità di Hyper-V in Windows Server 2016 e verranno approfonditi i cambiamenti apportati rispetto alla precedente versione.

Nested Virtualization

Questa funzionalità consente di avere una macchina virtuale con il ruolo di Hyper-V e di conseguenze di poter ospitare su di essa altre machine virtuali. Si tratta di una funzionalità utile per ambienti di test e sviluppo, ma non è idonea per essere utilizzata in ambienti di produzione. Per poter utilizzare la nested virtualization devono essere rispettati i seguenti requisiti:

La macchina virtuale con il ruolo di Hyper-V deve avere almeno 4 GB di RAM
Le macchine virtuali guest devono anch’esse essere Windows Server 2016
Al momento la nested virtualization è disponibile solo se l’host fisico che detiene la VM con il ruolo Hyper-V ha processori Intel (VT-x e tecnologia EPT).

Per approfondimenti in merito potete consultare l’articolo Windows Server 2016: Introduzione ad Hyper-V Nested Virtualization a cura di Silvio Di Benedetto oppure il documento Microsoft riguardante la Nested Virtualization.

Networking Features

Anche in ambito networking sono state introdotte importanti novità che consentono di sfruttare al meglio l’hardware ed avere maggiori performance:

Remote direct memory access (RDMA) e switch embedded teaming (SET). Switch Embedded Teaming (SET) è una nuova tecnologia alternativa al NIC Teaming che consente di avere più schede di rete in join allo stesso Virtual Switch di Hyper-V. Prima di Windows Server 2016 era necessario avere set di NIC separati (uno per l’utilizzo con i Virtual Switch e uno per sfruttare RDMA) in quanto il teaming del SO non era compatibile con la tecnologia RDMA. In Windows Server 2016 c’è la possibilità di abilitare RDMA sulle schede di rete che sono associate ad un Virtual Switch configurato con oppure senza la modalità Switch Embedded Teaming (SET)
Virtual machine multi queues (VMMQ). Miglioramento sul VMQ throughput grazie alla possibilità di allocare più hardware queues per singola macchina virtuale
Quality of service (QoS) per software-defined networks

Hot add and remove for network adapters and memory

Per le machine virtuali di generazione 2 con sistema operativo sia Windows che Linux è possibile aggiungere o rimuovere schede di rete mentre la macchina virtuale è in esecuzione, senza nessun fermo. Inoltre per le macchine virtuali sia di generazione 1 che di generazione 2, ma con sistema operativo Windows Server 2016 o Windows 10 è possibile modificare la quantità di memoria RAM ad essa assegnata mentre è in esecuzione, anche se non è abilitata la memoria dinamica.

Rolling Hyper-V Cluster Upgrade

Importanti sono le novità anche in ambito cluster. Viene fornita la possibilità di aggiungere un nodo Windows Server 2016 a un cluster Hyper-V già esistente costituito da nodi Windows Server 2012 R2. Questo ci consente di aggiornare i sistemi cluster senza avere nessun downtime. Fintanto che tutti i nodi del cluster non vengono aggiornati a Windows Server 2016 il cluster rimane con le funzionalità di Windows Server 2012 R2. Al termine del processo di aggiornamento dei vari nodi del cluster è necessario aggiornare il livello di funzionalità tramite il cmdlet Powershell Update-ClusterFunctionalLevel.

Start Order Priority for Clustered Virtual Machines

Grazie a questa funzionalità si riesce ad ottenere un maggiore controllo sulla priorità di avvio delle machine virtuali in ambiente cluster. Questo può risultare utile per avviare macchine virtuali che forniscono servizi prima di avviarne altre che usufruiscono di questi servizi. Il tutto è facilmente ottenibile configurando dei set, assegnando le macchine virtuali ai vari set e definendo delle dipendenze.

Production Checkpoints

La creazione dei production checkpoint si basa su tecnologie di backup presenti all’interno della macchina virtuale anziché sullo stato di save (save state di Hyper-V). Per le macchine basate su sistema operativo Windows viene utilizzata la tecnologia Volume Snapshot Service (VSS), mentre per le macchine virtuali Linux viene effettuato un flush dei diversi buffer del file system per creare un checkpoint che è consistente a livello di file system. I Production checkpoint sono il default per le nuove macchine virtuali, ma c’è sempre la possibilità di creare i checkpoint basati sullo stato di save della macchina virtuale, denominati ora standard checkpoint.

Host Resource Protection

Questa funzionalità aiuta a prevenire condizioni dove le operazioni svolte da una singola macchina virtuale possono degradare le performance dell’host Hyper-V o di altre machine virtuali. Quando questo meccanismo di monitoring rileva una macchina virtuale con una attività eccessiva a questa vengono ridotte le risorse assegnate. Di default questo meccanismo di controllo è disabilitato ed è possibile attivarlo utilizzando il seguente comando Powershell: Set-VMProcessor -EnableHostResourceProtection $true

Shielded Virtual Machines

Le Shielded virtual machines, aggregando diverse funzionalità, rendono molto più difficili tutte quelle attività che possono essere fatte da malware oppure dagli amministratori stessi di Hyper-V per effettuare l’inspect, la manomissione e l’acquisizione impropria dei dati. I dati e lo stato delle Shielded virtual machines sono criptati e agli amministratori di Hyper-V non è consentito visualizzare l’output video e i dati contenuti nei dischi virtuali. Queste macchine virtuali possono essere eseguite esclusivamente su specifici host Hyper-V definiti e in stato di salute secondo le policy impartite dall’Host Guardian Server. Le shielded virtual machines sono compatibile con la funzionalità di Hyper-V Replica. Per attivare la replica è necessario che venga autorizzato l’host Hyper-V sul quale si vogliono replicare le shielded virtual machine. Per maggiori dettagli relativi a queste nuove funzionalità è possibile consultare il documento Guarded Fabric and Shielded VMs.

Virtualization-based Security for Generation 2 Virtual Machines

Nuove funzionalità in termini di sicurezza sono state introdotte per le machine virtuali generation 2 (a partire dalla versione 8 del file di configurazione) come Device Guard e Credential Guard, che sono in grado di aumentare la protezione del sistema operativo da attacchi malware.

Encryption Support for the Operating System Disk in Generation 1 Virtual Machines

Ora c’è la possibilità di proteggere i dischi del sistema operativo utilizzando BitLocker anche per le machine virtuali di generazione 1. Grazie alla nuova funzionalità Key Storage (richiede almeno la versione 8 del file di configurazione) viene creato un piccolo drive dedicato ad ospitare le chiavi utilizzate da BitLocker anziché utilizzare un Trusted Platform Module (TPM) virtuale che è disponibile solo per le macchine virtuali di generazione 2.

Linux Secure Boot

Le machine virtuali di generazione 2 basate su sistema operativo Linux possono effettuare il boot utilizzando l’opzione Secure Boot. Sono abilitate al Secure Boot su host Windows Server 2016 le seguenti distribuzioni Linux:

Ubuntu 14.04 +
SUSE Linux Enterprise Server 12 +
Red Hat Enterprise Linux 7.0 +
CentOS 7.0 +

Windows PowerShell Direct

Si tratta di un nuovo metodo per eseguire comandi Windows PowerShell in una macchina virtuale impartendoli direttamente dall’host, senza richiedere un accesso via network e indipendentemente dalla configurazione dei tool di gestione remoti. Windows PowerShell Direct è quindi un’ottima alternative ai tool attualmente utilizzati dagli amministratori di Hyper-V come PowerShell, Remote Desktop oppure Hyper-V Virtual Machine Connection (VMConnect) ed offre un’ottima experience in ambito scripting e automation (difficile ad esempio da ottenere con VMConnect).

Compatible with Connected Standby

Quando il ruolo Hyper-V viene abilitato su un sistema che utilizza come power model Always On/Always Connected (AOAC) è ora disponibile come power state Connected Standby.

Discrete Device Assignment

Questa interessante funzionalità consente di fornire a una macchina virtuale un accesso diretto ed esclusivo ad alcune device harware PCIe. Utilizzando un device in questa modalità viene bypassato l’intero stack di virtualizzazione Hyper-V garantendo così un accesso più rapido all’harware. Per avere maggiori dettagli sui requisiti hardware necessari è possibile consultare il paragrafo “Discrete device assignment” nel documento System requirements for Hyper-V on Windows Server 2016.

Windows Containers

Parlando delle novità in ambito Hyper-V è opportuno citare anche i Windows Containers che consentono l’esecuzione su un sistema di applicazioni isolate. Tra i principali punti di forza dei containers troviamo la velocità di creazione, l’alta scalabilità e la portabilità. Sono disponibili due tipologie di container runtime, ognuno fornisce un differente grado di isolamento dell’applicazione:

Windows Server Containers che utilizza namespace e process isolation
Hyper-V Containers che utilizza una piccola macchina virtuale per ogni container

Per maggiori dettagli sui containers vi invito a consultare la documentazione ufficiale dei Windows Container e la sezione specifica su WindowServer.it contenente diversi articoli molto interessanti.

Aggiornamento Funzionalità in Windows Server 2016

More Memory and Processors for Generation 2 Virtual Machines and Hyper-V Hosts

Le machine virtuali di generazione 2, a partire dalla versione 8 del file di configurazione, possono essere configurate con un numero maggiore di risorse in termini di processori virtuali e memoria RAM. Sono inoltre stati rivisti anche i limiti massimi di utilizzo delle risorse da parte degli host fisici. Per tutti i dettagli relativi alla scalabilità di Hyper-V in Windows Server 2016 è possibile consultare il documento Plan for Hyper-V scalability in Windows Server 2016.

Virtual Machine Configuration File Format

Il file di configurazione delle machine virtuali utilizza un nuovo formato che consente di leggere e scrivere in modo più efficiente le differenti configurazioni. Questo nuovo formato lo rende anche più resiliente a corruzioni nel caso dovessero verificarsi failure del sottosistema dischi. L’estensione del nuovo file di configurazione che detiene la configurazione della macchina virtuale è .vmcx mentre l’estensione .vmrs è utilizzata per detenere lo stato di runtime.

Virtual Machine Configuration Version

La versione del file di configurazione rappresenta il Livello di compatibilità della macchina virtuale con la versione di Hyper-V. Le machine virtuali con file di configurazione versione 5 sono compatibili Windows Server 2012 R2 e possono essere attivate sia su Windows Server 2012 R2 che su Windows Server 2016. Macchine virtuali aventi versioni del file di configurazione introdotte in Windows Server 2016 non possono essere eseguite in Hyper-V su Windows Server 2012 R2. Per poter utilizzare tutte le nuove funzionalità sulle macchine virtuali create con Windows Server 2012 R2 e poi migrate o importate in Hyper-V su Windows Server 2016 è necessario aggiornare la configurazione delle macchine virtuali. L’aggiornamento non avviene in automatico. Il downgrade del file di configurazione non è supportato. Tutti i dettagli su come aggiornare la versione della configurazione delle macchine virtuali li trovate nel seguente articolo: Upgrade virtual machine version in Hyper-V on Windows 10 or Windows Server 2016.

Hyper-V Manager Improvements

Anche Hyper-V manager introduce important miglioramenti:

Alternate credentials support – Viene fornita la possibilità di utilizzare un set di credenziali differenti in Hyper-V Manager quando ci si collega ad un host remoto Windows Server 2016 oppure Windows 10. Le credenziali possono anche essere salvate per essere facilmente riutilizzate.
Manage earlier versions – Utilizzando Hyper-V Manager in Windows Server 2016 e Windows 10 è possibile gestire anche sistemi Hyper-V basati su Windows Server 2012, Windows 8, Windows Server 2012 R2 e Windows 8.1.
Updated management protocol – Hyper-V Manager utilizza il protocollo WS-MAN per comunicare con gli host Hyper-V remoti. Tale protocollo di comunicazione consente l’autenticazione CredSSP, Kerberos oppure NTLM e facilita la configurazione degli host per consentire la gestione remota.

Integration Services Delivered Through Windows Update

Di grande utilità è la possibilità di aggiornare gli integration services delle virtual machine basate su sistema operativo Windows tramite Windows Update. Questo è un aspetto di particolare interesse anche per i service providers perché grazie a questo meccanismo il controllo dell’applicazione di questi aggiornamenti viene lasciato nelle mani del tenant che possiede la macchina virtuale. I tenant possono quindi aggiornare in autonomia la propria macchina virtuale Windows con tutti gli aggiornamenti, compresi gli integration services, utilizzando un unico metodo.

Shared Virtual Hard Disks

Viene fornita la possibilità di effettuare il resize dei virtual hard disks di tipologia shared, utilizzati per realizzare ambienti guest clustering, senza alcun downtime. Le dimensioni dei shared virtual hard disks possono infatti essere estese o ridotte mentre la macchina virtuale è online. I guest cluster che utilizzano shared virtual hard disks possono ora essere protetti con l’Hyper-V Replica a fini di disaster recovery.

Storage Quality of Service (QoS)

In ambito storage è possibile creare delle policy di QoS su Scale-Out File Server ed assegnarle ai vari dischi virtuali associati alle macchine virtuali Hyper-V. In questo modo si ha la possibilità di controllare le performance dello storage evitando che l’utilizzo dello stesso da parte delle singole macchine virtuali possa impattare l’intero sottosistema dei dischi. Potete trovare tutti i dettagli riguardanti questo argomento nel documento Storage Quality of Service.

Conclusioni

Molte sono le novità introdotte nella piattaforma di virtualizzazione Microsoft con Windows Server 2016 che la rendono ancora più completa e ricca di nuove funzionalità. Microsoft Hyper-V è ormai disponibile sul mercato da diversi anni, ha raggiunto altissimi livelli di affidabilità ed offre un’ottima soluzione di virtualizzazione a livello enterprise. Nella scelta della piattaforma di virtualizzazione è bene non trascurare anche le varie possibilità che Microsoft offre per scalare verso il public cloud oppure per implementare architetture ibride.

Potete testare tutte le nuove funzionalità di Microsoft Hyper-V Server 2016 scaricando la versione di valutazione dal TechNet Evaluation Center.

Per ulteriori approfondimenti sul tema vi invito a partecipare alle sessioni dedicate ad Hyper-V durante il SID // Windows Server 2016 Roadshow, l’evento gratuito dedicato al nuovo sistema operativo, rivolto a tutte le aziende, consulenti e partner che vogliono prepararsi al futuro e che vogliono conoscere le novità e le best-practice di implementazione del nuovo sistema operativo server.

Microsoft Azure Site Recovery: Replica di macchine virtuali di Hyper-V in Microsoft Azure

Microsoft Azure Site Recovery offre la possibilità di replicare macchine virtuali presenti su Hyper-V verso uno specifico cloud service a fini di disaster recovery.

Accedendo al seguente link è possibile consultare tutti i dettagli sui prerequisiti e sugli scenari supportati per utilizzare Azure Site Recovery: http://msdn.microsoft.com/it-it/library/azure/dn469078.aspx Continua a leggere→