Ivan Salvade’

Il mio punto di vista su Virtualizzazione, Sicurezza, Messaggistica, Network Management…

  • Ivan

    248418_467427256623661_1655875885_n.jpg
  • Abbonati

  •  

    novembre 2017
    L M M G V S D
    « gen    
     12345
    6789101112
    13141516171819
    20212223242526
    27282930  
  • Tag Cloud

Archivi per la categoria 'Hyper-V' Categoria


Le novità di Hyper-V 2016

Scritto da Ivan Salvade' il 7 ottobre 2015

Ecco alcune delle novità salienti della piattaforma Hyper-V 2016…

Versione di Configurazione delle macchine virtuali

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).   L’aggiornamento della versione di configurazione a valore 6 (compatibilità solo con Hyper-V 2016) deve essere eseguita manualmente su ogni macchina virtuale (o in maniera massiva utilizzando comandi powershell).

Per interrogare lo stato della versione, utilizzare il seguente comando powershell :

Get-VM nome_macchina | FT name,version

Per aggiornare la versione, utilizzare il seguente comando powershell :

Update-VMConfigurationVersion nome_macchina

L’operazione di aggiornamento deve essere eseguita a macchina spenta, e non è reversibile.  Non è più inoltre possibile spostare la macchina virtuale su un server Hyper-V 2012.

Nuova estensione del file di configurazione delle macchine virtuali

.VMCX è la nuova estensione dei files di configurazione (invece di .XML).  Inoltre i nuovi file .VMRS contengono i dati di Runtime della macchina virtuale (invece dei vecchi .VSV).

Console di gestione Hyper-V

Con la console di gestione Hyper-V 2016, caricata su un server 2016 o su un client Windows 10, è possibile (finalmente!!) gestire anche piattaforme Hyper-V downlevel, cioè macchine virtuali configurate su Windows Server 2012 e 2012 R2, oppure Windows 8 e 8.1

Aggiornamento in-place di un cluster Hyper-V

Un cluster Hyper-V potrà ora contenere nodi con differenti sistemi operativi : è infatti possibile aggiungere “al volo” 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à “2012 R2″ (senza cioè poter sfruttare tutte le nuove features 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”.

In un cluster “ibrido”, è sempre possibile spostare a caldo le macchine virtuali dai nodi 2012 R2 a quelli 2016, o viceversa.

Quando la modalità del cluster è 2012 R2 con nodi 2016 già inseriti, 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 rimane a 5 (cioè compatibile con 2012 R2)
  • l’aggiornamento della versione di configurazione a valore 6 (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,  tenere presente che :

  • la versione di configurazione di ogni macchina virtuale deve essere innalzata a 6 (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

Aggiunta a caldo di memoria e schede di rete alle macchine virtuali

E’ possibile eseguire questa operazione sia su macchine virtuali di Generazione 1 che su quelle di Generazione 2, contenenti sistemi operativi Windows o Linux.

La RAM è modificabile anche se la macchina virtuale non è mai stata impostata ad utilizzare la Memoria Dinamica.

Production Checkpoint

E’ una tecnica che permette di creare snapshot (fotografie) “consistenti” di una macchina virtuale.  “Consistenti” significa che questi snapshot possono essere utilizzati in tempi successivi, con il pieno supporto Microsoft per tutti  i workload di produzione.

I Production Checkpoint utilizzano la tecnologia di backup VSS interna alle macchine virtuali, piuttosto che utilizzare la tecnologia “Salva Stato” esterna alle macchine virtuali, che realizzerebbe snapshot probabilmente inconsistenti in caso di loro creazione a macchina accesa.

Sono comunque ancora utilizzabili i normali Checkpoint, presenti nelle release precedenti di Hyper-V.

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).

Esecuzione di comandi powershell all’interno di una macchine virtuale

E’ possibile ora eseguire comandi powershell nel sistema operativo Guest, lanciandoli dall’Host Hyper-V.

Unici prerequisiti sono :

  • la presenza dei sistemi operativi Windows Server 2016 o Windows 10, sia sull’Host che nella macchina virtuale; nessuna modifica di rete o sui firewall è richiesta
  • credenziali amministrative complete sia sull’Host che sulla macchina virtuale
  • la macchina virtuale deve essere in esecuzione localmente sull’Host

Bisogna creare una sessione powershell verso la macchina virtuale con il seguente comando :

Enter-PSSession -VMName nome_macchina_virtuale

Successivamente si possono lanciare comandi powershell nel modo seguente :

Invoke-Command -VMName nome_macchina_virtuale -ScriptBlock {comando}


  • Share/Bookmark

Pubblicato in Hyper-V, Virtualizzazione | Nessun commento »

Impossibile lanciare una macchina virtuale in Hyper-V 2012 R2

Scritto da Ivan Salvade' il 24 marzo 2014

In alcuni casi può capitare di non essere in grado di accendere una macchina virtuale nella console Hyper-V 2012 R2, dopo aver eseguito un’operazione di importazione.

I casi più tipici possono essere questi :

  • macchina virtuale esportata da un server Hyper-V non facente parte del vostro dominio
  • macchina virtuale esportata da un server Hyper-V sotto gestione di VMM, con assegnazione di diritti utente sulla macchina virtuale eseguita da VMM
  • macchina virtuale esportata da un server Hyper-V di precedenti release (2008, 2008 R2, 2012)
  • macchina virtuale esportata da un ambiente di cluster

L’errore visualizzato è il seguente (Fig. 1) :

1-error-invalid-structure.PNG      Fig. 1 : “The security ID structure is invalid”

L’errore riportato “The security ID structure is invalid” (0×80070539), ci fa capire che si tratta di un problema di SID, e quindi di autorizzazioni sulla macchina virtuale.

Il file di configurazione xml della macchina virtuale contiene tutte le informazioni di configurazione e anche quelle sulla sicurezza.  Bisogna localizzare questo file nella cartella in cui avete memorizzato la macchina virtuale : tipicamente esiste il file di configurazione con un particolare GUID, ed una cartella con lo stesso nome (Fig. 2) :

2-posiz-del-file-xml.PNG      Fig. 2

Editare il file xml con un editor (es. Notepad), e ricercare all’interno del file la sezione ” <security> ” (Fig. 3) :

3-trova-security-in-xml.PNG      Fig. 3

Nella sezione Security sono riportate tutte le informazioni di sicurezza della macchina virtuale, compreso l’elenco delle utenze che hanno diritti di accesso alla macchine virtuale (es. la possibilità di modificare la configurazione della VM o semplicemente di avviarla nella console Hyper-V).

Un esempio di compilazione della sezione Security potrebbe essere la seguente (Fig. 4) :

4-sid-inseriti-in-xml.PNG      Fig. 4

Nell’esempio si può notare la presenza di due particolari utenze aventi diritto di accesso alle macchine virtuale.  Si tratta di due utenze amministrative di un particolare dominio (quello con prefisso 1346063433-4264430864-4209970739) : un’utenza (quella con RID 1122) è inserita nel gruppo Domain Admins, mentre l’altra (quella con RID 500) è l’amministratore Built-in del dominio.

Se il prefisso del dominio non corrisponde con il vostro, ecco trovato l’inghippo : il file xml garantisce accesso alla macchina virtuale solo a quelle due utenze elencate nella sezione Security, e a nessun altro.  Questo vale anche per il semplice avvio della macchina virtuale.   Probabilmente erano due utenze inserite dai precedenti “proprietari” della macchina virtuale.

Microsoft ci dà la possibilità di utilizzare un comando powershell (necessario almeno Hyper-V Windows Server 2012) per regolare facilmente le autorizzazioni di connessione ad una macchina virtuale.  Il comando è il seguente :

Grant-VMConnectAccess -VMName nome_VM_in_console -Username nome_utente 

Ecco l’esecuzione del comando in una sessione powershell (Fig. 5) :

5-powershell-command.PNG   Fig. 5

Ed ecco in Fig. 6 le modifiche apportate automaticamente al file di configurazione xml da parte del comando precedente.  Faccio notare che, nel mio esempio, l’utenza “Administrator” a cui ho assegnato diritti di accesso è un amministratore locale di un host Hyper-V di workgroup, ma avrei tranquillamente potuto utilizzare un’utenza di dominio.

6-nuovo-sid-in-xml-dopo-comando.PNG      Fig. 6

Il comando precedente ha praticamente riscritto la sezione Security del file xml, inserendo con autorizzazione di accesso e connessione l’amministratore locale da me indicato (invece del SID, si nota la dicitura “LA”, da intendere come “Local Administrator”).

Ora sarà possibile avviare regolarmente la macchina virtuale.

Un’altra soluzione poteva essere quella di cancellare completamente la sezione security, come in Fig. 7 : questo lascerebbe la macchina virtuale “priva” di autorizzazioni, e solo il proprietario (colui che l’ha creata o importata) avrebbe il diritto di accesso.

7-altra-soluzione-delete-security.PNG      Fig. 7

Buona virtualizzazione :-)

  • Share/Bookmark

Pubblicato in Hyper-V, Windows Server 2012 | Nessun commento »

Windows Server 2012 R2 alle porte…

Scritto da Ivan Salvade' il 3 giugno 2013

Parecchie novità segnalate nella seconda release di Windows Server 2012.

Le più interessanti, secondo me, riguardano Hyper-V.  Eccone una veloce panoramica :

  • Nuovo tipo di macchine virtuali creabili (”Generation 2 VMs”) : eseguono boot da UEFI e non hanno devices emulati.  Compatibili solo ad ospitare Windows Server 2012 e Windows 8 come sistema operativo Guest.  Hanno lo “scopo” di assomigliare il più possibile ad un’effettiva macchina fisica.  Si affiancano alle macchine virtuali di vecchia generazione, naturalmente ancora presenti
  • Live Migration più veloce con compressione dei dati
  • Live Migration over SMB
  • Ridimensionamento a caldo dei dischi virtuali in formato VHDX
  • Live Virtual Machine Cloning, in pratica la possibilità di esportare a caldo uno snapshot di una macchina virtuale, a scopo di eseguire la risoluzione di un problema in laboratorio
  • Hyper-V Replica con frequenza di replica configurabile tra 30 secondi e 15 minuti
  • Data Deduplication supportata su librerie di VHD online
  • Live Migration, Live Backup, Memoria Dinamica e ridimensionamento VHDX anche per macchine virtuali Linux (dotate di Hyper-V Linux Integration Services)

Non vedo l’ora di testare queste novità. Voi?  :-)

  • Share/Bookmark

Pubblicato in Cafè, Hyper-V, Virtualizzazione, Windows Server 2012 | Nessun commento »

Gestire un server Hyper-V 2008 R2 da Windows 8 : niente da fare!!

Scritto da Ivan Salvade' il 6 maggio 2013

Era già da tempo nota questa impossibilità.

Malgrado ciò, ho tentato numerose modifiche (sia lato Windows 8 che lato Windows Server 2008 R2), nel tentativo di far funzionare il collegamento.

Gli “smanettamenti” hanno riguardato :

  • chiavi di registro
  • regole di firewall
  • Servizi Componenti (DcomCnfg.exe)
  • WMI

Niente da fare : tutte le prove hanno dato esito negativo.

Purtroppo Microsoft ha deciso di creare un nuovo “WMI namespace” per Hyper-V 2012 (”Root\Virtualization\v2″): questo permette di sfruttare (anche tramite comandi powershell) tutte le nuove features del nuovo Hyper-V.

E’ stato mantenuto anche il vecchio “WMI Namespace” (”Root\Virtualization”), ma questo non ha nessuna API di gestione delle nuove features Windows 2012/Windows 8.

Per supportare tutte le nuove caratteristiche di Hyper-V, anche gli strumenti di gestione sono stati aggiornati, ed utilizzano il nuovo namespace “Root\Virtualization\v2″ : proprio questo causa l’impossibilità degli strumenti Windows 8/2012 a gestire le piattaforme più vecchie.

Rimane invece possibile gestire un server Hyper-V 2012 con gli strumenti  di gestione Windows 7/2008 R2, anche se in questo modo non è possibile accedere alle nuove features.

Detto questo, non mi piace la situazione : esistono già strumenti di terze parti che permettono la gestione di tutte le versioni di Hyper-V da un’unica console.

Microsoft dovrebbe provvedere il più presto possibile : mi sembra una grossa mancanza :-(

  • Share/Bookmark

Pubblicato in Cafè, Hyper-V, Windows 8 | Nessun commento »

Nuovo corso su Hyper-V 2012

Scritto da Ivan Salvade' il 2 maggio 2013

E’ disponibile un nuovo corso interamente dedicato ad Hyper-V 2012.  Il suo nome completo è il seguente :

Course 55021 - Configuring and Administering Hyper-V in Windows Server 2012″

Non è un corso ufficiale Microsoft (il famoso MOC), ma un corso creato da comunità indipendenti, e disponibile nel Courseware Marketplace di Microsoft.

Non essendo un MOC, è di più difficile individuazione su Internet, ma i centri di formazione Microsoft (CPLS) sono certamente in grado di organizzarlo, con trainer in aula.

Il corso è di 3 giorni, ed è molto ricco di argomenti :

  1. Installazione e configurazione di base
  2. Storage, networking, DCB (Data Center Bridging), Resource Metering
  3. VHD, VHDX, Pass-Through Disks, creazione e importazione macchine virtuali, Virtual Fibre Channel, MPIO
  4. Extensible Switch, Network Virtualization, NIC Teaming, VLAN tagging, SR-IOV, QoS, Trunk Mode
  5. Hyper-V Scaling, NUMA, Dynamic Memory, Smart Paging
  6. Hyper-V Replica, Hyper-V Clusters, Backup & Restore
  7. Live Migrations :
    • Storage Live Migration
    • Live Migration in ambiente di cluster (shared storage)
    • Live Migration senza shared storage
    • Live Migration senza infrastruttura
    • Live Migration usando SMB
    • Live Migration tra cluster diversi

I prerequisiti per partecipare al corso sono i seguenti :

  • Conoscenza delle tecnologie di virtualizzazione
  • Esperienza con le precedenti edizioni di Hyper-V o con altre tecnologie di virtualizzazione
  • Esperienza su sistemi di storage e networking

Buon corso :-)

  • Share/Bookmark

Pubblicato in Cafè, Corsi e Certificazioni, Hyper-V, Windows Server 2012 | Nessun commento »

Le novità di Windows Server 2012 - parte 9 - : Hyper-V Virtual Fibre Channel

Scritto da Ivan Salvade' il 18 febbraio 2013

Link per tornare all’indice degli articoli della serie “Le novità di Windows Server 2012” :

http://ivansalvade.it/2012/09/06/le-novita-di-windows-server-2012-indice-generale-degli-articoli/

—————————————————————————————————————————————————————————————————————————–

Ottima novità di Hyper-V 3.0 : la possibilità di collegare le macchine virtuali direttamente a dispositivi di storage a fibra ottica!!

In effetti, molte aziende hanno già investito nell’acquisto di SAN a fibra ottica, per avere un sistema di storage espandibile, ridondante e performante.  E può essere un peccato garantire il collegamento alle SAN FC solo agli host Hyper-V : con il costante aumento dell’utilizzo di macchine virtuali, non sarebbe male garantire il collegamento diretto alle SAN FC anche alle macchine virtuali, in modo da massimizzare l’utilizzo dello storage.

Detto fatto! Ecco l’Hyper-V Virtual Fibre Channel : è in grado di fornire “porte virtuali a fibra ottica” (virtual Fibre Channel HBA ports) all’interno del sistema operativo Guest, permettendo la mappatura diretta di dischi presenti su una SAN FC.

Ci sono alcuni requisiti essenziali per il corretto funzionamento del VFC (Virtual Fibre Channel) :

  • l’ovvia presenza fisica, nell’host Hyper-V che ospita le macchine virtuali, di un opportuno HBA (Host Bus Adapter) a fibra ottica
  • il supporto al VFC da parte dei drivers del HBA fisico (QLogic, Brocade e altri già offrono questo tipo di supporto)
  • il LUN a cui la macchina virtuale si collega tramite il VFC non deve essere un disco di boot del sistema operativo
  • la SAN deve supporare lo standard NPIV
  • il sistema operativo all’interno della macchina virtuale deve essere Windows Server 2008, Windows Server 2008 R2, Windows Server 2012

Diverse sono le caratteristiche tecniche del VFC (Virtual Fibre Channel) :

  • garantisce alla macchina virtuale l’accesso alla SAN tramite un WWN (World Wide Name) associato alla macchina virtuale
  • per supportare la Live Migration tra host Hyper-V mantenendo la connettività a fibra ottica, sono configurati due WWN (”Address Set A” e “Address Set B”) per ogni VFC.  Hyper-V alterna automaticamente tra il “Set A” e il “Set B” durante la Live Migration
  • utilizza lo standard NPIV (N-Port ID Virtualization) T11, che permette di mappare multipli N_Port ID virtuali a una singola N_Port di un HBA fisico a fibra ottica.  Una nuova porta NPIV è creata sull’host ogni volta che si avvia una macchina virtuale configurata con un HBA virtuale.  Quando la macchina virtuale si spegne, la porta NPIV viene rimossa.  La SAN deve anch’essa supportare lo standard NPIV

La configurazione e l’uso dei VFC sono possibili solo a patto di creare almeno una “Virtual SAN” in Hyper-V (Fig. 1), utilizzando il wizard “Virtual SAN Manager” ed assegnando ad essa un generico nome (in Fig. 1, il nome è “Fibre Channel SAN”).  E’ proprio la “Fibre Channel SAN” che viene collegata agli opportuni HBA fisici a fibra ottica.  In Fig. 1 si nota cosa succederebbe se non venisse rilevato nessun HBA fisico sull’host, mentre in Fig.2 sono visualizzati degli esempi di HBA a fibra ottica rilevati sugli host.  In questo caso, è sufficiente selezionare le opportune porte del HBA in modo che vengano collegate alla Virtual SAN.

7newfbrchsan.JPGFig. 1

wwn.jpg      Fig.2

A questo punto, nella configurazione della macchina virtuale posso aggiungere un VFC (Fibre Channel Adapter, ne posso aggiungere un massimo di 4), collegandolo all’opportuna Virtual SAN creata prima (Figg. 3 e 4) :

6addfbrchadpt.JPG      Fig. 3

8fbrchsanparams.JPG      Fig. 4

La macchina virtuale è ora collegata direttamente alla SAN a fibra ottica, e ne potrà utilizzare i LUN configurati.

  • Share/Bookmark

Pubblicato in Hyper-V, Windows Server 2012 | Nessun commento »

Le novità di Windows Server 2012 - parte 2 - : Hyper-V Virtual Switch

Scritto da Ivan Salvade' il 15 novembre 2012

Link per tornare all’indice degli articoli della serie “Le novità di Windows Server 2012” :

http://ivansalvade.it/2012/09/06/le-novita-di-windows-server-2012-indice-generale-degli-articoli/

—————————————————————————————————————————————————————————————————————————–

Come spesso ho detto nei corsi su Hyper-V in versione 1 e 2, ho sempre ritenuto il termine “Virtual Network” piuttosto ambiguo, ed infatti è ora stato sostituito con il più appropriato termine “Virtual Switch”.

In effetti, una rete virtuale di Hyper-V è ben di più di una semplice rete virtuale, come il termine Virtual Network poteva far pensare :  è, a tutti gli effetti, una vera e propria versione virtuale di uno switch di rete (per la precisione, è una rappresentazione software di uno switch di rete Layer 2), e ad esso possono essere collegate le schede di rete delle macchine virtuali e le schede di rete fisiche dei server fisici, permettendo le comunicazioni tra le macchine virtuali, gli host fisici e gli altri dispositivi presenti in rete.

E’ quindi assolutamente appropriata la scelta di Microsoft di rinominarlo “Virtual Switch”.

Essendo dotato di numerose estensioni e personalizzazioni, il Virtual Switch è denominato anche “Hyper-V Extensible Switch”.

Come nella precedente release, Hyper-V 3.0 supporta tre differenti tipi di Virtual Switch :

  • External : da utilizzare per mappare una rete ad una specifica scheda di rete fisica dell’host (o team di schede di rete fisiche) e permettere le comunicazioni delle macchine virtuali verso intere reti fisiche.  La novità In Hyper-V 3.0 è la possibilità di mappare un virtual switch External ad una scheda di rete wireless, a patto che il server Hyper-V abbia una scheda wireless compatibile ed il servizio “Wireless Local Area Network” installato
  • Internal : da utilizzare per permettere le comunicazioni tra le macchine virtuali presenti su un host hyper-V e l’host stesso (ma non permettere comunicazioni verso altri dispositivi presenti in rete)
  • Private : da utilizzare per permettere comunicazioni solo tra le macchine virtuali presenti su un certo host

Per un virtual switch di tipo External o Internal, è possibile configurare anche un VLAN ID (numero compreso tra 1 e 4094) che possa essere associato alla rete.  Questo permette di estendere le VLAN esistenti sulla rete esterna alle VLAN configurate sui virtual switch degli host Hyper-V.  Le VLAN permettono di partizionare il traffico di rete , e funzionano come reti logiche separate.  Il traffico può passare da una VLAN all’altra solo se attraversa un router.

In Hyper-V 3.0 è ora possibile dotare un virtual switch di particolari estensioni :

  • si possono installare “Filtri NDIS (Network Driver Interface Specification) personalizzati” oppure “Filtri WFP (Windows Filtering Platform) personalizzati”, agganciati come estensioni all’Hyper-V Virtual Switch, che possono eseguire diverse operazioni ausiliarie, come per esempio la cattura e il monitoraggio dei pacchetti, oppure il filtraggio e l’inoltro (es. ispezione ed eliminazione di alcuni pacchetti, o reindirizzamento verso opportune VLAN).   Tutti questi filtri possono essere realizzati da Microsoft oppure da terze parti, rispettando l’architettura “NDIS Filter Driver”.   Le estensioni sono visibili nelle proprietà di un certo Virtual Switch, come mostrato in Fig. 1 :

1virtswext.JPG   Fig. 1

Ulteriori capacità avanzate sono utilizzabili dai Virtual Switch.  Sono reperibili nella sezione “Advanced Features” di ogni Network Adapter di ogni macchina virtuale : sono quindi capacità attivabili per macchina virtuale e/o per scheda di rete virtuale.  Ecco l’elenco :

  • è attivabile il DHCP Guard (Fig. 2) : è una tecnica che evita la spedizione di messaggi DHCP da parte di macchine virtuali che “pretendono” di essere Server DHCP.  Questo è utile, per esempio, in un’azienda dotata di un lab, dove spesso i sistemisti creano ambienti virtuali di test, e dove può accadere che qualche macchina virtuale server con i servizi DHCP installati inizi a distribuire indirizzi IP a destra e a manca in produzione.  Questo può essere evitato anche con altri accorgimenti (netta separazione tra produzione e lab, blocco dell’autorizzazione dei server DHCP virtuali in Active Directory, configurazione di regole a livello degli switch/router di rete, ecc…), ma indubbiamente la semplicità di questo metodo (un banale flag) è lampante :-)
  • è attivabile il Router Guard (Fig. 2) : è una tecnica simile al DHCP Guard, con lo scopo di evitare la spedizione di messaggi di tipo “Router Advertisement” (messaggi rilasciati periodicamente, o su sollecitazione di un host, da un router, per indicare la propria presenza e la propria configurazione) e di tipo “Redirection” (indicano la necessità, per una certa comunicazione, di dover utilizzare - o no - un certo router per raggiungere la destinazione) da parte di macchine virtuali configurate come dei router (es. RRAS installato)
  • è attivabile il MAC Address Spoofing (Fig. 2) : è una tecnica (già presente in Hyper-V 2.0) che permetterebbe alle macchine virtuali (o a del software all’interno delle macchine virtuali) di modificare il MAC Address sorgente dei pacchetti uscenti in un MAC Address non assegnato alle macchine virtuali stesse.   Questa possibilità è disabilitata per default, per ovvi motivi di sicurezza (MAC address spoofing usato a scopo malizioso), ma potrebbe essere utile in alcuni scenari : per esempio quando configuro le macchine virtuali in NLB utilizzando la modalità Unicast, oppure quando utilizzo una macchina virtuale dentro un’altra (es. quando eseguo una VM Virtual PC dentro una VM Hyper-V, oppure quando utilizzo i simulatori virtuali dei palmari in una VM Hyper-V)

2macdhcprout.JPG   Fig. 2

  • è attivabile il Port Mirroring (Fig. 3) : permette di monitorare il traffico di rete di una macchina virtuale, inoltrando copie dei suoi pacchetti entranti o uscenti (configurabile) ad un’altra macchina virtuale, utilizzata  a scopo di monitoraggio

3portmirteam.JPG   Fig. 3

  • è attivabile il NIC Teaming (Fig. 3) : permette ad una macchina virtuale di avere schede di rete virtuali connesse a più di uno switch virtuale, e di continuare ad avere connettività anche se la scheda di rete fisica agganciata ad uno degli switch virtuali smettesse di funzionare
  • nella sezione “Hardware Acceleration” è attivabile “Virtual Machine Queue” (Fig. 4) : questa tecnica permette di generare, sulla scheda di rete dell’host, una coda dedicata per ogni scheda di rete virtuale.  E’ in pratica un modo per far apparire, alle macchine virtuali, la singola scheda di rete dell’host come se fosse un “insieme” di schede di rete, e ogni scheda di rete virtuale può creare ed utilizzare una propria coda specifica per il proprio traffico di rete.  Questo comporta un generale miglioramento delle operazioni di I/O
  • nella sezione “Hardware Acceleration” è attivabile “IPSec Task Offloading” (Fig. 4) :  ora anche la macchina virtuale può trasferire in offload alla scheda di rete fisica dell’host fisico.  Questo libera risorse CPU.   La regolazione del numero delle Security Associations (SA) tra 1 e 4096, permette di bilanciare la necessità di eseguire IPSec Offloading da parte di più macchine virtuali

4hwacc.JPG      Fig. 4

  • Nelle proprietà di una scheda di rete virtuale esiste la possibilità di utilizzare “Bandwidth Management” (Fig. 5) : questo permette di indicare per ogni macchina virtuale le quantità minima e massima (in Mb al secondo) di utilizzo della rete.

5bdwthmgm.JPG      Fig. 5

    Un’ulteriore funzionalità è disponibile nelle proprietà di un Virtual Switch.  Si tratta di ”Single-root I/O Virtualization (SR-IOV)” (Fig. 6) : è una tecnica che sfrutta il supporto dei chipset per le tecnologie di virtualizzazione, e che permette la ri-mappatura di DMA e interrupt in modo che alcune periferiche (che supportino SR-IOV) possano essere mappate direttamente alle macchine virtuali.  La disponibilità di SR-IOV nel Virtual Switch permette l’applicazione di questa tecnica a schede di rete fisiche presenti nell’host Hyper-V, a patto che la scheda di rete ed il suo driver siano compatibili con SR-IOV (il driver deve essere presente sia nel sistema operativo dell’host che in quello della macchina virtuale).

      9-sr-iov.JPG      Fig. 6

      • Share/Bookmark

      Pubblicato in Hyper-V, Virtualizzazione, Windows Server 2012 | Nessun commento »

      Le novità di Windows Server 2012 - parte 1 - : i nuovi limiti di Hyper-V

      Scritto da Ivan Salvade' il 10 settembre 2012

      Link per tornare all’indice degli articoli della serie “Le novità di Windows Server 2012” :

      http://ivansalvade.it/2012/09/06/le-novita-di-windows-server-2012-indice-generale-degli-articoli/

      —————————————————————————————————————————————————————————————————————————–

      Hyper-V 3.0 in Windows Server 2012 implementa nuovi limiti (per host e per macchina virtuale), molti dei quali ampiamente superiori alla precedente release.

      Eccoli riassunti nelle seguenti tabelle :

      Limiti per host Hyper-V

      hypervlimxsrv.jpg

      Fig. 1 : limiti per singolo Host Hyper-V

      Limiti per macchina virtuale

      hypervlimxvm2.jpg

      Fig. 2 : limiti per singola macchina virtuale

      Ecco qua sotto ulteriori delucidazioni sul contenuto delle tabelle precedenti.

      (1)     (2)

      Differenza tra processori logici e virtuali

      Per capire bene la differenza tra Processori Logici (Logical Processor) e Processori Virtuali (Virtual Processor), nel modo in cui la concepisce Microsoft,  è necessario avere un minimo di conoscenza dell’architettura dei processori e delle tecniche di MultiThreading.

      I concetti base si possono sintetizzare così :

      1. Un processore è un dispositivo che esegue istruzioni (chiamate “Thread”)
      2. Inzialmente i processori eseguivano i thread in maniera seriale, uno alla volta
      3. Dai primi anni 2000 è stata introdotta la tecnica “MultiThreading”, che permette ad un processore di eseguire più thread in contemporanea.  Intel ha chiamato questa tecnica “Hyper-Threading”, ed ha cominciato ad implementarla sui suoi processori a partire dal 2002, limitando i suoi processori all’esecuzione di non più di 2 thread in contemporanea
      4. Dal punto di vista del sistema operativo, un processore con la tecnica Hyper-Threading viene visto (per esempio nel Task Manager) come un doppio processore, e le due CPU condividono RAM e Cache.  Per sfruttare correttamente l’Hyper-Threading (e migliorare le prestazioni), le applicazioni devono saper interagire con questa tecnica
      5. Intel ha abbandonato la tecnologia Hyper-Threading con l’avvento dei processori dual-core, per poi reintrodurla intorno al 2008 con l’architettura Nehalem.
      6. Quindi ora esistono processori multi-core e multi-threading : per fare un esempio, un processore quad-core multi-threaded può eseguire 4*2=8 thread in contemporanea, e quindi viene visto dal sistema operativo come un processore “a 8 vie” (vedi Fig. 3) :

      taskmgrcores.JPG

      Fig. 3 : rappresentazione in Task Manager di un processore Intel I7 Q720 (Quad-Core con Hyper-Threading)

      Chiariti questi concetti base, ora possiamo dare le seguenti definizioni :

      • Processore fisico : il chip fisico inserito in un socket nelle mainboard
      • Processore logico : può rappresentare un Core o un Thread a seconda delle caratteristiche del processore fisico :
        • Se non è dotato di tecnologia Hyper-Threading (e quindi esegue solo un thread alla volta), allora 1 Processore Logico = 1 Core (quindi si dice che un processore fisico quad-core è dotato di 4 processori logici)
        • Se è dotato di tecnologia Hyper-Threading (e quindi esegue due thread alla volta), allora 1 Processore Logico = 1 thread (quindi si dice che un processore fisico quad core è dotato di 8 processori logici)
      • Processore virtuale : il processore assegnato in utilizzo alle macchine virtuali

      Ulteriori chiarimenti sono necessari per comprendere come Microsoft utilizza i Processori Virtuali : essi sono associati ai processori logici, e non ai Core o ai processori fisici.

      E’ stata fatta questa scelta per avere una misura più precisa e accurata della potenza di calcolo dei processori : se i processori virtuali fossero stati associati ai Core, sarebbe stata ignorata l’architettura del processore fisico (single-threaded o multi-threaded).  Associando un processore virtuale ai processori logici, si tiene invece conto dell’architettura del processore fisico.

      Ecco perché, nella tabella di Fig. 1, sono riportati due limiti :

      • Il numero massimo di Processori Virtuali per Processore Logico
      • Il numero massimo di Processori Virtuali per intero Server

      (3)

      In Windows Server 2008 R2 SP1, è supportato un massimo di 12 processori virtuali per processore logico, ma solo se tutti i sistemi operativi guest del server eseguono  Windows 7 (quindi per ambienti VDI); altrimenti il numero massimo supportato di processori virtuali per processore logico è 8.

      In Windows Server 2012 ogni limite è stato rimosso.

      (4)

      In Windows Server 2008 R2 SP1, il numero massimo supportato di processori virtuali per Server dipende dal numero massimo supportato di processori virtuali per processore logico : in ambienti VDI, con il rapporto 12:1, allora possiamo avere 64*8=512 processori virtuali; in ambienti non-VDI, con il rapporto 8:1, possiamo avere 64*12=768 processori virtuali.

      In Windows Server 2012 il limite è stato aumentato a 2048.

      (5)

      La grandezza massima è determinata dal sistema operativo guest

      (6)

      Sia Windows Server 2008 R2 SP1 che Windows Server 2012 supportano un massimo di 8 schede di rete di tipo sintetico e 4 schede di rete di tipo legacy (queste ultime utilizzabili per effettuare un boot PXE, in quanto il loro driver è emulato via software).

      Inoltre Windows Server 2012 supporta anche 4 adattatori a fibra ottica (FCA) per il collegamento delle macchine virtuali a un “Virtual Fibre Channel per Hyper-V”, che permette alle macchine virtuali stesse di collegarsi direttamente a SAN raggiungibili in fibra ottica.  Questo consente, per esempio, ad un’applicazione come SQL, in esecuzione in una macchina virtuale, di connettersi direttamente ai LUN di una SAN a fibra ottica.

      • Share/Bookmark

      Pubblicato in Hyper-V, Virtualizzazione, Windows Server 2012 | Nessun commento »

      Hyper-V presente in Windows 8 (client)

      Scritto da Ivan Salvade' il 28 ottobre 2011

      Hyper-V sarà incluso in Windows 8 client!!

      Questa è indubbiamente una delle maggiori novità presenti nel prossimo sistema operativo client di Microsoft.

      Avrete bisogno di processori Intel o AMD a 64 bit, di Windows 8 a 64 bit, di almeno 4 Gb di RAM, ma sarete poi in grado di utilizzare Hyper-V anche sul vostro Desktop o Portatile con installato Windows 8, ed eseguire, anche in contemporanea, macchine virtuali a 32 bit e a 64 bit.

      Oggi, per ottenere lo stesso ambiente, sareste costretti ad utilizzare un dual-boot tra Windows 7 e Windows Server 2008 o 2008 R2 (utilizzando Windows 7 Enteprise o Ultimate, il dual boot con Windows Server 2008 R2 potrebbe essere fatto anche utilizzando un VHD, ambiente che utilizzo, per esempio, sul mio portatile personale).

      Hyper-V in Windows 8 avrà le seguenti caratteristiche fondamentali :

      • Allocazione dinamica della memoria (già presente in Hyper-V 2008 R2 SP1)
      • Collegamento alle macchine virtuali con la VM Console oppure tramite Connessione Desktop Remoto
      • Spostamento di macchine virtuali da un disco all’altro, anche se accese
      • Possibilità di effettuare snapshot
      • Aggiornamenti automatici tramite Windows Update
      • Possibilità di far comunicare una macchina virtuale con il mondo esterno attraverso la connessione Wireless del vostro desktop/portatile, oltre che con la connessione Wired

      Quest’ultima tecnica è stata implementata modificando la precedente architettura, che prevedeva la possibilità di creazione di uno switch virtuale (External Network Switch) da collegare ad una scheda di rete fisica del vostro computer.  Così facendo, la scheda di rete fisica doveva essere in grado di far fluire pacchetti aventi diversi MAC address di origine (quello della scheda di rete fisica e quelli delle macchine virtuali) : questo è supportato sulle schede di rete fisiche (facendole funzionare in modalità promiscua), ma non sulle schede di rete wireless, in quanto il canale wi-fi stabilito tra la scheda wireless e l’Access Point consente il flusso solo di pacchetti con il MAC address della scheda wi-fi, e niente altro.

      E’ stata allora implementata la soluzione “Microsoft Bridging”, che ha il compito di sostituire, per i pacchetti in uscita,  i MAC address delle macchine virtuali con il MAC address della scheda wi-fi.  “Microsoft Bridge” mantiene anche una sorta di mappatura interna per consentire al traffico di risposta di raggiungere la corretta macchina virtuale.

      Quindi, se mappo l’External Network Switch ad una scheda di rete wireless, Hyper-V eseguirà le seguenti operazioni :

      1. Creazione del “Microsoft Bridge”, collegato alla scheda di rete wireless
      2. Creazione dell’External Network Switch, che continuerà ad eseguire funzioni di Ethernet switching
      3. Binding dell’External Network Switch al Microsoft Bridge, invece che alla scheda wi-fi fisica

      L’uscita di Windows 8 è, al momento, prevista per la seconda metà del 2012, o addirittura inizio 2013.

      • Share/Bookmark

      Pubblicato in Hyper-V, Windows 8 | Nessun commento »

      Cluster Shared Volumes (CSV) : parte 8

      Scritto da Ivan Salvade' il 26 giugno 2011

      In questa ottava parte dell’articolo su CSV, dimostrerò step-by-step come rendere altamente disponibile, in un cluster CSV,   una macchina virtuale dotata di dischi Pass-Through.   Ecco i link alle precedenti parti dell’articolo :

      Come già spiegato nella Parte 3 di questo articolo, nella sezione “Utilizzo dei Pass-Through Disk con CSV”, è possibile eseguire una Live Migration di una macchina virtuale dotata di dischi Pass-Through, a patto di configurarla correttamente nell’ambiente di Cluster CSV.   La configurazione deve prevedere :

      1. l’inserimento nello spazio CSV del vhd contenente il sistema operativo della macchina virtuale
      2. l’inserimento, come “dipendenza” della macchina virtuale”, di uno o più dischi pass-through in dotazione alla macchina virtuale, che verranno utilizzati tipicamente per la parte dati

      Vediamo in questo articolo le procedure step-by-step per questo tipo di implementazione.

      In questa dimostrazione, parto dall’assunzione di aver già reso altamente disponibile una macchina virtuale, come illustrato nella Parte 7 di questo articolo.

      Per prima cosa, vado a ricavare sull’iSCSI Target Software un LUN da dedicare come disco pass-through alla macchina virtuale. Nella figura, il LUN è il Virtual Disk 2 inserito in LUN-02 (Fig. 1) :

      lun-da-dedicare-come-passthrough.jpg      Fig. 1

      Non appena rendo visibile il nuovo LUN al Nodo 1 tramite l’iSCSI Initiator, eccolo comparire nella console Gestione Disco (Fig. 2) :

      lun-visto-da-nodo1.jpg      Fig. 2

      Eseguo il solito Online del disco (Fig. 3) …

      online-lun.jpg      Fig. 3

      …e la solita inizializzazione per rendere il disco riconoscibile dal sistema operativo e dai servizi di Clustering (Fig. 4) :

      initialize-lun.jpg      Fig. 4

      Ora riportare Offline il disco appena inizializzato : Hyper-V richiede che il disco sia Offline affinchè lo si possa agganciare come pass-through alla macchina virtuale; inoltre non serve formattarlo già ora, in quanto ci penserà il sistema operativo della macchina virtuale (Fig. 5) :

      riportare-offline-il-lun-se-no-non-si-aggiunge-come-passthrough.jpg      Fig. 5

      Il disco deve essere reso visibile tramite iSCSI Initiator anche al Nodo 2, altrimenti il Cluster restituisce il seguente errore (Fig. 6) :

      se-lun-non-mappato-a-entrambi-i-nodi-cluster-non-lo-vede.jpg      Fig. 6

      Dopo che il disco è stato reso visibile a entrambi i nodi, si procede a dichiarare il disco al Cluster, con l’azione “Add Disk” della console del Failover Cluster, sezione Storage (Fig. 7) :

      aggiunta-disco-al-cluster-storage.jpg      Fig. 7

      Ecco il riassunto dello storage ora disponibile : il Disk 1 in Quorum, il Disk 2 in CSV, il nuovo Disk 3 compare nello storage disponibile (Fig.8) :

      riassunto-storage.jpg      Fig. 8

      Come già detto, non è possibile assoggettare a CSV un disco che si pensa di utilizzare come pass-through in una macchina virtuale.  Il tentativo di eseguire questa operazione (Fig. 9) …

      tentativo-di-mettere-in-csv-il-lun-passthrough.jpg      Fig. 9

      … porta a degli errori, visibili in Fig. 10 e Fig. 11 :

      esito-1.jpg      Fig. 10

      esito2.jpg  

      Fig. 11

      Quali sono le motivazioni dell’errore di Fig. 11 ?   La tecnica CSV richiede che i dischi siano dotati di almeno una partizione formattata NTFS per poter ospitare i vhd delle macchine virtuali, e inoltre devono essere in stato Online, altrimenti CSV non riesce a leggere le informazioni di partizionamento dei dischi.   Nel nostro caso, però, dobbiamo tenere il disco Offline, perchè solo in questo stato è possibile inserirlo come pass-through in una macchina virtuale.   Questi due concetti antagonisti creano il suddetto errore.

      Ora proviamo ad inserire il Disk 3 come pass-through disk della macchina virtuale, utilizzando la voce Settings nelle proprietà della macchina in console del Failover Cluster (Fig. 12) :

      tentativo-di-assegnare-il-lun-passthrough-a-vm.jpg      Fig. 12

      Essendo il disco Offline, lo si può vedere nella sezione “Physical Hard Disk” (Fig. 13) :

      disco-9-messo-come-passthrough.jpg      Fig. 13

      Ora, nella sezione “Disk Drives”, compare il “Cluster Disk 3″.   Eseguo anche un Refresh (essenziale!!) della configurazione della macchina virtuale (Fig. 14) :

      refresh-della-vm.jpg      Fig. 14

      Il primo refresh, però, comporta dei (giusti…) ”Warning” indicati in Fig. 15 , Fig. 16 e Fig. 17 :

      refresh-e-warning-della-vm.jpg      Fig. 15

      avviso-rosso.jpg

      Fig. 16

      avviso-giallo.jpg

                     Fig. 17

      La motivazione dei warning di Fig. 17 è la seguente : eseguendo il refresh della macchina virtuale nella console del cluster, il cluster si è accorto che il “Cluster Disk 3″ (quello identificato dal cluster come \\.\PhysicalDrive9) non è ancora sotto il suo controllo.  In effetti, come si nota in Fig. 8, quel disco è visibile solo nella sezione “Available Storage”;  non è mai stato dichiarato in uso da qualche risorsa del cluster.   Il refresh della macchina virtuale esegue proprio questa operazione.  Infatti, appena sotto i due warning gialli, si nota proprio la dichiarazione del disco al cluster : “Adding the new storage required by virtual machine ‘HA-Test to the cluster“.

      Ora, rieseguendo un secondo refresh a scopo di controllo, si nota il differente esito (Fig. 18 e Fig. 19) :

      rifatto-con-lun-in-possesso-del-cluster.jpg      Fig. 18

      il-refresh-e-ora-corretto.jpg      Fig. 19

      Ora il disco è completamente sotto il controllo del cluster, ed inoltre è dichiarato come dipendenza della macchina virtuale.  Qualunque operazione di migrazione della macchina virtuale si porterà dietro pure il pass-through disk (Fig. 20) :

      lun-ora-in-dipendenza.jpg      Fig. 20

      Nella precedente Fig. 20, notare come la macchina virtuale era in esecuzione su Nyc-Host1.  Ecco ora l’esecuzione di una nuova Live Migration della macchina virtuale HA-Test (Fig. 21) :

      migrazione-in-corso.jpg      Fig. 21

      Al completamento della Live Migration, si nota che l’owner è diventato NYC-Host2 (Fig. 22) :

      migrazione-finita.jpg      Fig. 22

      Eseguendo un Diskpart all’interno della macchina virtuale, si nota come il disco pass-through venga correttamente visto (Disk 1).  E’ addirittura in stato Offline : è possibile ora procedere a partizionarlo e formattarlo secondo le esigenze, utilizzando il sistema operativo della macchina virtuale (Fig. 23) :

      lun-visto-da-dentro-vm.jpg      Fig. 23

      Conclusione : la Live Migration di una macchina virtuale dotata di dischi Pass-Through funziona! Eccome se funziona!!  :-)

      Buona implementazione a tutti!!  :-)

      • Share/Bookmark

      Pubblicato in Clustering, Hyper-V, Virtualizzazione, Windows Server 2008 R2 | 1 Commento »

       
      Usiamo i cookie per assicurarti la migliore esperienza di navigazione nel nostro sito web.
      Ok