Uno dei prodotti più attesi per il prossimo anno e che fa parte della famiglia System Center è Virtual Machine Manager 2012, il tool di management che permette di gestire un'infrastruttura di virtualizzazione basata sui 3 principali vendor: Microsoft, VMware e Citrix.

Questo tool è diventato talmente potente da poter gestire da un'unica interfaccia non solo l'infrastruttura di virtualizzazione di un intero datacenter, ma addirittura un "Private Cloud". Col termine Private Cloud si intende l'insieme di risorse e di elementi di un'infrastruttura informatizzata che ne permettono la creazione, l'automazione, la gestione del ciclo di vita e soprattutto la possibilità di avere procedure di self service automatizzate. È quindi importante non confondere la virtualizzazione con il Cloud, in quanto la piattaforma di virtualizzazione è solo uno degli elementi che forma il "Cloud".

Se volete cominciare a cimentarvi con SCVMM 2012 potete scaricare la Release Candidate che è uscita da pochissimi giorni e un VHD già preimpostato con la RC. Prima di muovere i primi passi per l'installazione vi consiglio di leggere:

Interfaccia di SCVMM 2012

Tra le novità che per prime colpiscono chi si appresta ad utilizzare SCVMM 2012 salta all'occhio una rinnovata interfaccia grafica che utilizza i ribbon di Office, che sostituisce la vecchia interfaccia di SCVMM 2008 R2. La nuova interfaccia è stata riprogettata per gestire al meglio il Cloud Fabric, i Servizi e le Library, con un focus particolare alla gestione degli Host, dei servizi, dei componenti di rete e degli storage.

Figura 1: La schermata di gestione delle risorse del Fabric di VMM 2012

 

Cloud

Tra i primissimi pulsanti che hanno catturato la mia attenzione, c'è il pulsante "Create Cloud". La possibilità di creare un cloud privato permette di organizzare tutte le risorse necessarie a far funzionare il nostro datacenter, come ad esempio Hosts, Logical Networks, Load Balancers, Storage, Library, Capacity. In particolar modo con VMM 2012 sono state ottimizzate le seguenti caratteristiche:

  • Self service: gli utenti possono gestire da soli, da console o da interfaccia web, tutte le risorse in base alla capacità e alle quote assegnate, senza la necessità che conoscano i componenti architetturali hardware e software a supporto.
  • Resource pooling: aggregando risorse come storage e networking se ne può limitare l'utilizzo in base alle quote assegnate agli utenti. Sono gestiti anche i Resource Pool di VMware e Citrix.
  • Opacity: gli utenti self-service non hanno assolutamente idea delle risorse fisiche che compongono il cloud privato.
  • Elasticity: le risorse possono essere aggiunte facilmente per aumentare la capacità del cloud.
  • Optimization: tutte le risorse che compongono il cloud sono continuamente ottimizzabili in base alle richieste del cliente e all'aumento di utilizzo delle risorse.

Figura 2: Creazione di un Cloud privato e assegnazione delle risorse

Per approfondire potete leggere l'articolo How to Create a Cloud in VMM 2012.

 

Componenti di VMM 2012

I componenti chiave su cui si basa VMM 2012 sono gli stessi di VMM 2008 R2:

  • VMM Management Server - gestisce le connessioni tra tutti i componenti di SCVMM;
  • VMM Database - supportati solo SQL 2008 SP2 e SQL 2008 R2;
  • VMM Console - ora da la possibilità di scegliere con quale utente autenticarsi;
  • VMM Command Shell - Interfaccia basata su PowerShell 2.0 – i cmdlet sono passati da 182 a 432;
  • VMM Library - gestisce VHD, Templates e Profili;
  • VMM Self-Service Portal - crea e gestisce le macchine virtuali dei private cloud.

Nelle piccole infrastrutture tutti i ruoli possono essere installati su un'unica macchina, mentre se il datacenter è abbastanza grande è possibile suddividere i ruoli su macchine diverse. Assolutamente degna di rilievo è anche la possibilità di poter installare VMM 2012 sia in modalità stand-alone che in modalità Cluster, utilizzando un cluster Microsoft precedentemente creato, ed eliminando così il "single point of failure" che aveva la versione precedente. Ovviamente andrebbe anche clusterizzato il database server di SQL Server e il file server con la Library. Maggiori dettagli sono contenuti negli articoli sul blog VMM:

 

Host di virtualizzazione supportati

Gli host di virtualizzazione supportati da System Center Virtual Machine Manager 2012 sono:

  • Microsoft Hyper-V e Hyper-V 2.0
  • VMware ESX ed ESXi 3.5 e 4.1 (utilizzando però vCenter 4.1)
  • Citrix XenServer 5.6 Feature Pack 1 (gli host vengono gestiti direttamente, senza usare XenCenter, ma richiedono l'installazione del Citrix "SCVMM Integration Suite Supplemental Pack". È supportato XenMotion)

Non sono più supportati invece

  • VMware ESX 3.0
  • Microsoft Virtual Server 2005 R2 SP1

Figura 3: Aggiunta di un host Citrix XenServer in VMM 2012

 

Gestione degli Host fisici

Per gestire gli host fisici con VMM 2012 bisogna utilizzare il nodo Fabric della management console. Con il termine Fabric si intende l'insieme delle risorse hardware che permettono alla nostra infrastruttura virtualizzata di esistere e funzionare (virtualization hosts, library, networking, storage).

In particolar modo VMM 2012 è capace di gestire dei server bare-metal (cioè senza sistema operativo) che possiedano però un Baseboard Management Controller (BMC). I BMC attualmente supportati sono:

  • Intelligent Platform Management Interface (IPMI)
  • Data Center Management Interface (DCMI)
  • System Management Architecture for Server Hardware (SMASH)

Una volta che VMM 2012 ha individuato i server fisici è capace di:

  • Usare un server PXE per installare un host Hyper-V utilizzando un determinato Host Profile precedentemente creato
  • Creare un Cluster Hyper-V direttamente dalla console di gestione di VMM
  • Aggiungere o rimuovere i nodi al cluster Hyper-V
  • Gestire il cluster utilizzando la console di VMM
  • Aggiornare i server usando WSUS 3.0 SP2 e spostare le macchine per permettere il riavvio degli host quando necessario (grazie all'Update Management)

Figura 4: Gestione degli host in VMM 2012

Gestione dello Storage

VMM 2012 può essere in grado di gestire lo storage collegandosi direttamente alle Storage Area Network (SAN) e poterlo classificare in base alla velocità per poi associarlo come risorsa nel Cloud. Per le connessioni viene usata la Storage management Initiative – Specification (SMI-S) ed attualmente nella versione RC sono supportati:

  • NetApp FAS
  • EMC Symmetrix
  • EMC Clariion CX
  • HP StorageWorks EVA

Una volta stabilita la connessione alla SAN, è possibile creare LUN, formattarle, assegnarle agli Host Hyper-V oppure ai cluster Hyper-V come Cluster Shared Volumes (CSV). Per quanto riguarda VMware e Citrix, lo storage deve essere invece gestito utilizzando le rispettive console (vSphere Client e XenCenter).

Trovate maggiori informazioni sul blog Technet leggendo l'articolo Storage Automation in VMM 2012.

Figura 5: Classificazione dello storage

 

Gestione del Networking

In VMM 2012 è possibile gestire in maniera centralizzata le risorse di rete ed in particolar modo:

  • Le Logical Network
  • I pool di IP e MAC Address
  • I Load balancer

Le Logical Networks permettono di associare tra loro una serie di reti e delle VLAN in modo tale da poterle assegnare ai vari host e alle macchine virtuali. È possibile creare una rete con il nome "Produzione" ed assegnargli la rete 10.10.0.0/24 e la VLAN 12 ed una rete con il nome "DMZ" ed assegnargli la rete 10.12.0.0/24 e la VLAN 14. In questo modo diventa facilissimo individuare quale rete assegnare alle varie macchine, senza conoscerne effettivamente le caratteristiche fisiche (indirizzo, vlan, ecc.). Ogni Logical Network è associata poi alla scheda di rete fisica, che può essere in Trunk.

Figura 6: Logical Networks in VMM 2012

Altra novità consiste nel poter creare dei pool di indirizzi IP (IPv4 e IPv6) e di MAC address da assegnare alle macchine virtuali, indipendentemente se stanno girando su Hyper-V, vSphere o XenServer. Anche gli address pool possono essere associati alle Logical Network e nel caso un indirizzo non viene più utilizzato da una macchina, viene rimesso a disposizione del pool.

Per approfondire potete leggere l'articolo Create networks with VMM 2012

Figura 7: Gestione del networking

VMM 2012 integra la possibilità di riconoscere e gestire i Load balancer hardware, in modo tale da poter creare dei template di IP virtuali (VIP) che potranno poi essere utilizzati per gestire il traffico di un certo protocollo e ripartire il carico di rete per ottimizzare il traffico. Attualmente i load balancer supportati nella beta sono:

  • F5 Networks BIG-IP
  • Citrix NetScaler

Interessante gli articoli presenti sul blog di VMM e su Technet:

Figura 8: Gestione dei Network Load Balancer

Prima di salutarvi e di darvi appuntamento al secondo articolo dedicato a System Center Virtual Machine Manager 2012 vi ricordo che da TechNet potete scaricare la Release Candidate insieme ad altri prodotti:

Alvin Morales, Senior Support Escalation Engineer del team di sviluppo di App-V, ha pubblicato sul Microsoft Application VIrtualization Blog un interessante articolo su come implementare il Microsoft Network Load Balancing (per gli amici NLB) in un'infrastruttura di App-V.

Utilizzando NLB è possibile creare un cluster di più server di App-V che possano  rispondere alle richieste dei client utilizzando il protocollo RTSP o RTSPS, puntando ad un unico nome di rete e riducendo il carico di lavoro dei vari server, oltre ad assicurare fault tolerance nel caso in cui uno dei server non sia raggiungibile.

Per approfondire leggete l'articolo How to configure App-V with Microsoft Network Load Balancing (NLB)

Buon lavoro

Nic

Uno dei problemi più sentiti durante la migrazione a Windows 7 partendo da Windows XP è la compatibilità delle applicazioni, in quanto alcune applicazioni scritte per Windows XP non funzionano con Windows 7 oppure ci sono siti web intranet che possono essere navigati solo con Internet Explorer 6.

Un modo per risolvere il problema è di utilizzare Windows XP Mode, una funzionalità disponibile in Windows 7 che permette di installare una macchina virtuale con Windows XP direttamente sulla workstation dell'utente e far girare le applicazioni obsolete all'interno della macchina virtuale. L'integrazione con il menù avvio della workstation permette all'utente di poter avere un'esperienza d'uso facilitata poiché le applicazioni virtuali possono essere lanciate dallo stesso menù da cui sono lanciate le altre applicazioni, come mostrato in figura 1, e il risultato finale è quello di vedere solo la finestra dell'applicazione e non l'intero desktop della macchina virtuale.

Figura 1: Integrazione delle applicazioni XP Mode con il menù avvio di Windows 7

Distribuire, ma soprattutto gestire, Windows XP Mode in una grande azienda non è sicuramente semplice. Per questo motivo Microsoft mette a disposizione delle aziende che hanno un contratto di Software Assurance il programma Med-V(Microsoft Enterprise Desktop Virtualization), contenuto nel pacchetto MDOP. Tramite Med-V 2.0 possiamo creare dei packages con all'interno la macchina virtuale con Windows XP SP3 e tutta una serie di configurazioni del Workspace che verrà utilizzato dall'utente.

Figura 2: Console per la creazione di un Workspace package in Med-V 2.0

Entrambe le opzioni viste però prevedono che la macchina virtuale che contiene Windows XP giri sulla postazione dell'utente e che quindi questa postazione abbia una potenza di calcolo adeguata e abbastanza RAM per far girare due sistemi operativi.

L'alternativa a queste soluzioni è permettere l'accesso da Windows 7 ad una applicazione legacy (ad es. Internet Explorer 6 oppure Access 97/2000) installata in una macchina remota con Windows XP SP3 e che viene presentata all'utente sotto forma di RemoteApp, che magari possa girare syde-by-syde con un'applicazione installata sulla macchina locale.

La macchina remota potrebbe anche essere una macchina virtuale che sta girando all'interno del nostro Datacenter in Hyper-V. Questo tipo di soluzione permette quindi ad ogni utente di avere il proprio Personal Virtual Desktop.
La macchina virtuale potrebbe anche essere una copia della stessa macchina fisica che l'utente stava utilizzando prima di passare a Windows 7, virtualizzata con una conversione Physical-to-Virtual (P2V).

Come abilitare le RemoteApp su XP

Dopo aver installato Windows XP SP3 o dopo aver convertito una macchina esistente, per prima cosa abilitiamo la funzionalità di desktop remoto e decidiamo a quali utenti è consentita la connessione remota, come mostrato in figura 3. Potremmo utilizzare un gruppo di Active Directory se la macchina XP è condivisa, oppure potremmo scegliere un unico utente se la vogliamo usare come Personal Virtual Desktop.

Figura 3: Abilitazione della funzionalità di Desktop remoto e scelta del gruppo di utenti autorizzati

Per abilitare la funzionalità di RemoteApp in Windows XP SP3 è sufficiente installare l' Aggiornamento per Windows® XP SP3 per abilitare RemoteApp™ e riavviare.

Dopo il riavvio della macchina bisogna modificare nella chiave di registro HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\TsAppAllowList il valore fDisabledAllowList mettendolo a 1.

Modificando la chiave di registro infatti permettiamo che le applicazioni installate nella macchina con Windows XP possano essere lanciate come RemoteApp, come mostrato in figura 4.

Figura 4: Abilitazione della chiave di registro per le RemoteApp

A questo punto è necessario creare una chiave di registro specifica per ogni applicazione che vogliamo autorizzare. Nel nostro caso per lanciare Internet Explorer 6 dovremo creare all'interno del valore HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\TsAppAllowList\Applications le chiavi mostrate in figura 5. Se la chiave Applications non esiste va creata.

Figura 5: Creazione delle chiavi di registro per autorizzare le singole applicazioni

Il passaggio successivo consiste nel creare un file .rdp opportunamente modificato per poter lanciare la RemoteApp.

Creiamo ad esempio una connessione RemoteApp per utilizzare via RDP Internet Explorer 6 installato in Windows XP SP3. Lanciamo dalla macchina con Windows 7 il client Connessione Desktop remoto (mstsc.exe) e digitiamo il nome del computer da raggiungere (nel mio caso xp.demo.lab). Salviamo il file RDP con il comando Salva con come in un posto comodo, scegliendo come nome quello dell'applicazione da lanciare (nel mio caso Internet Explorer 6.rdp) .

Figura 6: Creazione del file RDP per la connessione al computer remoto

Apriamo con il Blocco Note il file Internet Explorer 6.rdp appena creato e apportiamo le seguenti modifiche al file, come mostrato in figura 7:

  • remoteapplicationmode:i:1
  • alternate shell:s:rdpinit.exe
  • remoteapplicationprogram:s:||IE6
  • remoteapplicationname:s:Internet Explorer 6
  • disableremoteappcapscheck:i:1
  • prompt for credentials on client:i:1

Per chi vuole accedere all'applicazione dall'esterno dell'azienda può usare un Remote Desktop Gateway (nel mio caso rdgw.demo.lab) . In questo caso è necessario modificare nel file RDP appena creato i seguenti parametri, evidenziati anche loro nella figura che segue:

  • gatewayhostname:s:rdgw.demo.lab
  • gatewayusagemethod:i:1
  • gatewaycredentialssource:i:4
  • gatewayprofileusagemethod:i:1
  • promptcredentialonce:i:0 (mettere a 1 se volete usare le stesse credenziali per accedere alla macchine XP e Gateway)

Figura 7: Modifiche da apportare al file RDP per connettersi ad Internet Explorer 6 come RemoteApp

A questo punto possiamo salvare le modifiche e lanciare il file RDP per verificarne il funzionamento.

 

Figura 8: lancio della RemoteApp per la verifica di funzionamento

Dopo l'inserimento delle credenziali di autenticazione all'interno della finestra Dettagli, possiamo finalmente accedere alla nostra applicazione legacy, come mostrato in figura 9. Le volte successive che lanceremo l'applicazione o altre applicazioni che girano sulla stessa macchina remota non sarà necessario reinserire le credenziali, per tutta la durata della sessione di lavoro sulla macchina Windows 7. Purtroppo in Windows XP non è possibile usare il single sign-on per l'autenticazione, che invece è disponibile se usiamo come sistema operativo virtuale Windows Vista o Windows 7.

La sessione sulla macchina XP remota rimarrà aperta anche in caso di disconnessione dal computer client, quindi per chi ne avesse necessità può modificare la durata del Timeout della sessione disconnessa utilizzando le Group Policy locali e modificando il valore di Computer Configuration --> Administrative Templates --> Windows Components --> Remote Desktop Session Host --> Session Time Limits --> 'Set time limit for disconnected sessions'.

Figura 9: Lancio di Internet Explorer 6 come RemoteApp in Windows 7

 

Questo tipo di utilizzo delle RemoteApp può essere implementato sia se Windows XP SP3 gira su macchina fisica sia se gira su macchina virtuale, indipendentemente dalla piattaforma di virtualizzazione, che sia essa Microsoft o di altri vendor.

La distribuzione del file RDP può essere effettuata attraverso la nuova funzionalità di RemoteApp and Desktop Connection che si serve del Remote Desktop Web Access di Windows Server 2008 R2. In questo modo i collegamenti alle applicazioni legacy appariranno nel menù avvio dell'utente. Per pubblicare i vostri file personalizzati potete scrivere un plugin seguendo le linee guida dell'articolo RemoteApp and Desktop Connection Management Extensibility for provisioning apps via RD Web Access

 

Approfondimenti

RemoteApp for Hyper-V

RemoteApp for Hyper-V (VDI) Deployment