Hyper-V e il tempo (2)

Un’altro caso di strano comportamento con il tempo mi è capitato su una macchina virtuale OpenSuSE 11.x ospitata su un Hyper-V. In questo caso la macchina virtuale non usava nessun servizio di integrazione ma solo l’emulazione hardware.

Come spesso capita in queste situazioni la macchina Linux utilizzava un server Windows nel dominio (il solito PDC) come server NTP. Nonostante questo la macchina accumulava un notevole errore temporale (un guadagno di circa 10 secondi al minuto).

Impostando clocksource=acpi_pm come parametro del kernel l’orologio e la sincronizzazione NTP ora funzionano correttamente.

Hyper-V e il tempo (1)

In una rete Windows, solitamente le macchine sincronizzano l’orologio con il domain controller che simula il PDC. Una classica configurazione prevede quindi che il PDC sincronizzi l’orologio con un server NTP in Internet. In questo modo tutte le macchine sono coerenti.

Ieri mi è capitato un effetto interessante. Un cliente aveva il server con il ruolo PDC virtuale su un server virtuale ospitato in Hyper-V. Questo server virtuale si collegava ad un server NTP pubblico ma non riusciva ad sincronizzare l’orologio. Tutte le macchine del dominio avevano un orario più avanti di circa 15 minuti.

Il fatto è che una macchina ospitata solitamente utilizza una serie di servizi forniti dall’ipervisore. Tra questi vi sono i servizi di Time Synchronization che fanno si che la macchina sincronizzi l’orario sulla base di quello dell’ipervisore. Quindi se l’ipervisore ha un orario errato (era il nostro caso) anche le macchine ospitate che usano questi servizi avranno un orario errato. Cambiare l’orario in una macchina ospitata non sortisce alcun effetto.

Per risolvere il problema si possono seguire varie strade. Ad esempio si sposta il PDC su un server fisico e si fa in modo che questo si sincronizzi con il server NTP. Oppure si fa in modo che l’ipervisore si sincronizzi via NTP così, di conseguenza, le macchine virtuali ospitate avranno l’ora corretta (ma questo potrebbe provocare una retroazione). Oppure, soluzione da me scelta in questo particolare caso, si disabilita il servizio di Time Synchronization per la macchina virtuale che ha il ruolo di PDC.

IBM System x, UEFI e Windows 2008 R2

La settimana scorsa siamo impazziti. Un cliente ha acquistato due nuovi IBM System x x3650 M2 destinati a costruire un cluster Hyper-V R2 su una SAN basata su uno storage IBM DS4700. Queste macchine non hanno più un BIOS all’interno ma hanno un nuovo firmware UEFI. UEFI gestisce il boot in modo differente e Windows 2008 R2 lo supporta pienamente.

Arrivate le macchine si è proceduto alla creazione di un volume RAID1 usando la funzionalità di management incorporata in UEFI. Poi si è efffettuata l’installazione del sistema operativo direttamente dal disco di Windows 2008 R2 (senza utilizzare ServerGuide che, al momento, non supporta ancora R2). E fin qui è andato tutto bene.

In seguito sono state collegate le schede in fibra QLogic e si sono associate 2 LUN (quorum + spazio per le macchine virtuali). Al reboot i sistemi non caricavano più il sistema operativo dal disco ma tentavano il boot dalla prima LUN (ovviamente senza riuscirci visto che non c’era nessun sistema operativo sopra).

Dopo vari tentativi alla fine la soluzione è stata quella di abilitare come primo device di boot quello Legacy (in pratica una emulazione del vecchio sistema BIOS) e reinstallare tutto. Fatto questo i sistemi hanno funzionato come dovevano e in poco tempo l’Hyper-V R2 in cluster (con CSV) è stato attivato.

La cosa più snervante sono stati i tempi di boot del firmware tra una prova e l’altra. In generale questo tipo di macchine sono lente visto la diagnostica che effettuano ma UEFI aumenta ulteriormente il tempo. Si fa prima a fare il boot di Windows che il boot del firmware! E questo dimostra che per avere PC veloci nel boot, anche i produttori di firmware devono fare la loro parte.

Aero in Remote Desktop

PC virtuale con Windows 7 Enterprise a 64 bit su Windows Server 2008 Hyper-V utilizzato via Remote Desktop da una macchina anch’essa con Windows 7 Enterprise (ma a 32 bit). Aero è attivato anche sul PC virtuale remoto.

Virtual PC e 7

Uno dei problemi di Windows 7 è che il nuovo Virtual PC può funzionare solamente su macchine che supportano la virtualizzazione hardware. Perchè una macchina lo faccia non basta avere il processore giusto ma occorrono anche BIOS e circuiterie apposite.

Molti dei nuovi PC supportano questo tipo di virtualizzazione senza problemi. Il punto, però, è che in azienda abbiamo dei discreti vecchi PC su cui 7 gira bene e dove dobbiamo usare una virtualizzazione che supporti il formato VHD (sono macchine virtuali per demo, test e sviluppo). Oggi, facendo un paio di prove veloci, ho scoperto che se non si installa il supporto di virtualizzazione di 7 (in RC) è comunque possibile usare il vecchio Virtual PC 2007 SP1. Domani farò verifiche più approfondite.

Ho anche “scoperto” che 7 include i driver di paravirtualizzazione per Hyper-V. Ma questa è un’altra storia.

Roundtable su Hyper-V

Per mercoledì abbiamo organizzato una roundtable a Padova sulla virtualizzazione in generale e Windows 2008 Hyper-V in particolare.

Hyper-V e i concorrenti

Qualche mese fa Microsoft ha rilasciato Hyper-V. Personalmente, dopo averlo provato, l’ho trovato molto interessante per vari motivi: costi, facilità d’uso e familarità con Windows, roadmap evolutiva. Recepito questo ho pensato che potesse essere una proposta molto interessante per tutti quei clienti che ancora non avevano soluzioni di virtualizzazione sofisticate. Ho quindi pensato di proporlo a diversi clienti (con un tasso di successo altissimo).

E’ però interessante notare come si è evoluta la reazione dei venditori di prodotti concorrenti in questi mesi:

1. Non funziona
2. E’ troppo nuovo,
3. Non ha le stesse caratteristiche
4. L’assistenza, in caso di problemi, non va bene

Non commento ma aspetto il prossimo passo. 😉

Virtualizzazione per un singolo server

Oggi, parlando con il mio socio, è saltata fuori la storia di un cliente che voleva virtualizzare un server operativo creando un PC virtuale da quello fisico, lavorare sulla macchina fisica e ricreare la macchina fisica da quella virtuale. In pratica un processo di virtualizzazione seguito da uno di devirtualizzazione. Il mio socio chiedeva a me che strade si potevano seguire.

Dopo aver detto che si poteva fare in vari modi ho subito aggiunto che non valeva la pena di farlo. Conveniva invece virtualizzare e lasciare il server virtualizzato.

In pratica quello che ho suggerito era di far girare la singola macchina virtuale su un singolo server fisico dedicato. Questa operazione ha un costo irrisorio, sia in termini di prestazioni che di risorse, ma permette di raggiungere il più grande vantaggio della virtualizzazione: l’indipendenza dal ferro!

L’indipendenza dal ferro significa soprattutto la possibilità di modulare l’hardware in base alle mutate esigenze senza stravolgere la parte software dei sistemi. In questo modo si aumenta anche la longevità della soluzione.

Questo modello di virtualizzazione singola macchina è già noto in diversi ambienti operativi ed io lo trovo particolarmente efficace.

Il risultato su PC Intel/AMD si può raggiungere usando vari virtualizzatori. Anche utilizzando l’infrastuttura Microsoft basata su Hyper-V: non molti lo sanno ma esiste anche Microsoft Hyper-V Server 2008. Si tratta di una versione stand-alone che non include Windows Server 2008  e che è gratuita, seppure con qualche limite in più. Non l’ho ancora provato (conto di farlo quanto prima) ma suppongo funzioni bene come il fratello inserito in Windows 2008.

Ovviamente occorre verificare che la soluzione che si intende virtualizzare sia supportata (oggi la situazione è migliore di qualche mese fa ma ci possono essere sorprese) e occorre verificare la situazione relativa alle licenze utilizzate nel sistema guest. Riguardo a questo ultimo punto vi consiglio di stare molto attenti perchè neppure molti commerciali di diversi vendor hanno le idee chiarissime e se vi si richiede una verifica della compliance potreste trovarvi nei problemi.

Windows 2008 e Hyper-V in cluster

Per una serie di motivi in questi giorni mi sono trovato personalmente coinvolto nella vendita e nell’installazione di un sistema di virtualizzazione basato su diversi prodotti hardware IBM e software Microsoft. In particolare abbiamo costruito e configurato un sistema a doppio server IBM x3655 con uno storage IBM DS4700 (in tecnologia Fibre Channel ovviamente) con un elevato livello di ridondanza per garantire alte affidabilità e continuità. Al tutto è stato aggiunto un tape storage IBM TS3100 con unità LTO3.

Installare l’hardware e configurarlo è stato (relativamente) molto semplice. Mi ha particolarmente impressionato lo storage DS4700 con l’ultima revisione del firmware in grado di supportare completamente Windows Server 2008 in cluster e con il supporto multipath nativo.

Ma visto che questo è un blog su Windows vorrei concentrarmi sull’aspetto del sistema operativo.

Per prima cosa abbiamo installato Windows Server 2008 Enterprise sulle due macchine. Poi, dopo i necessari aggiornamenti, abbiamo installato Hyper-V. Dopo aver configurato lo storage e aver agganciato alle macchine le partizioni logiche dello storage abbiamo lanciato il tool per la creazione del cluster (di failover): il wizard ha chiesto che macchine avrebbero fatto parte del cluster e ha lanciato una serie di test che hanno evidenziato alcuni errori di configurazione. Corretti velocemente questi problemi abbiamo rilanciato il wizard che in pochi minuti ha creato un sistema di cluster funzionante. Lasciatemi dire che rispetto a 2000/2003 è un bel miglioramento.

Visto la presenza di Hyper-V tra le risorse clusterizzabili esistono anche le macchine virtuali. Creare una macchina virtuale clusterizzata (quindi in grado di resistere al crash di uno dei nodi) è questione di pochi minuti. Ovviamente il solito wizard guida l’utente nell’operazione passo per passo.

La facilità di installazione e configurazione di tutto il sistema è veramente notevole.

Dopo aver fatto questo abbiamo installato il Data Protection Manager, la soluzione di backup di Microsoft. DPM (con l’SP1) ha riconosciuto immediatamente il tape storage IBM. In pochi minuti ha configurato il sistema di backup. Anche di questo mi ha stupito la semplicità.

E’ un dato di fatto che questa semplicità d’uso in pochi mesi ha convinto molti nostri clienti che, anche aiutati da noi, hanno deciso di montare 2008 e Hyper-V.

Migrati a Windows Server 2008 (quasi)

Direi che, con le operazioni di ieri, la nostra migrazione a Windows Server 2008 è quasi completa. Rimangono solamente 2 server 2003 significativi ma con le sostituzioni già pronte: dovremo farlo un fine settimana per evitare interruzione del servizio.

In pratica il progetto prevedeva 3 aspetti fondamentali: sostituzione di alcuni vecchi (anche di 10 anni) server, consolidamento di altre macchine e migrazione a 2008. Gli step che abbiamo seguito sono semplici:

• acquisto e installazione di una macchina adeguata per il supporto di Hyper-V;
• aggiornamento del domain controller “principale” da 2003 a 2008;
• installazione di una macchina di management con vari tool tra cui SCVMM 2008 (abbiamo iniziato con la beta e finito con la versione definitiva);
• aggiornamento della RAM di una macchina preesistente per metterla in grado di supportare Hyper-V;
• migrazione di diversi dei vecchi server sui 2 server Hyper-V (sto parlando di una serie di macchine, per lo più vecchi IBM Netfinity,  dove le più potenti avevano dei processori Pentium III);
• migrazione dei server virtuali preesistenti da Virtual Server 2005 R2 a Hyper-V;
• aggiornamento di alcuni di questi server virtuali da 2003 a 2008;
• riconfigurazione e riposizionamento dei servizi di alcuni server su altri server.

Oltre a questo ieri ho anche proceduto personalmente a virtualizzare un client basato su XP. Su questo client ci sono tutta una serie di programm più o meno orribili ma di cui non si può fare a meno (quelli del ministero per trasmettere dati fiscali ad esempio) e che non avevo proprio nessuna voglia di reinistallare (o far reinstallare). Dopo i vari test dei prossimi giorni potrò eliminare la macchina fisica e sostituirla con una più moderna e basata su Vista.

SCVMM 2008 sì è rivelato molto utile per catturare questo tipo di macchine e trasformarle da fisiche a virtuali. E’ stato anche utile per spostare le macchine tra i due server Hyper-V e per avere una gestione unificata dei due ambienti. 

Per restare in tema abbiamo anche installato un Terminal Services Gateway (è una funzionalità di Windows Server 2008) e abbiamo esposto una serie di programmi. Questo ci permette di utilizzarli ovunque grazie al tunnel dell’RDP nel HTTPS. In altri termini si possono usare anche attraverso i firewall purchè ci sia un proxy HTTPS aperto (situazione pressochè generale).

Come sottoprodotto di questa migrazione abbiamo  liberato delle macchine vecchie ma relativamente potenti su cui sposteremo fisicamente alcune funzionalità dei server Linux più vecchi. Alcuni però verranno virtualizzati (penso al repository del codice Java, ad esempio).

Le prestazioni del sistema sono ottime, le impressioni di utilizzo sono molto buone e gli utenti hanno avuto fastidi minimi. La migrazione è stata funestata però dai problemi avuti nell’ultimo mese dalla rete elettrica generale della zona di Pordenone.