Archive

Hyper-V

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.

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.

image

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.

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.

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