Tag: virtualizzazione

In arrivo un hypervisor per OpenBSD/amd64

860 letture Lascia un commento

OpenBSDOggi Mike Larkin ha pubblicato un teaser sul progetto al quale ha lavorato per un po’ di tempo: un hypervisor nativo per OpenBSD.

I progressi fatti giustificano l’annuncio ufficiale e lo stato del progetto consente adesso l’inserimento di altri sviluppatori a supporto dell’iniziativa.

I motivi per cui è stato preferito sviluppare un progetto da zero piuttosto che portare uno degli hypervisor esistenti sono diversi, uno dei principali è quello che le altre implementazioni non supportano alcuni aspetti che sono particolarmente importanti per OpenBSD, come ad esempio il supporto per i386, lo shadow paging, la nested virtualization, il supporto per le periferiche legacy, ecc. Tentare di inserire tali features in un hypervisor già esistente avrebbe probablmente richiesto uno sforzo pari a quello necessario per scriverne uno nuovo.

Alcune domande e risposte sul tema:

D. Quali OS possono essere eseguiti?
R. Inizialmente, gli OS che supportano le periferiche virtio-based. In seguito, si cercherà di esporre qualcosa a cui Qemu possa agganciarsi (probabilmente simulando KVM) per eseguire OS legacy ed OS che richiedono il supporto al boot BIOS/UEFI.

D. Quando sarà pronto?
R. Difficile a dirsi. Si spera per la fine di Ottobre 2015, ma non è una promessa. Molto dipenderà anche dalla quantità di aiuto che verrà dato nello scrivere i backend virtio.

D. Quali saranno i requisiti di CPU?
R. Qualsiasi CPU AMD o Intel che supporta la virtualizzazione hardware (SVM per AMD, VMX per Intel). Per le CPU che non supportano RVI o EPT, si utilizzerà lo shadow paging.

D. Ma dai, i386?!
R. Sì. E’ utile per trovare i bug. E Mike invita a guardare la sua ultima dozzina di commit relativi a i386 per individuare un’altra ragione.

Infine, la domanda più importante:
D. Come posso aiutare?
R. L’autore non avrebbe avuto praticamente tempo di lavorare a questo progetto negli ultimi mesi se non grazie alla generosa sponsorizzazione della OpenBSD Foundation. Le donazioni lo hanno reso possibile, e ciò è valido anche per altri progetti. Per cui è possibile aiutare effettuando donazioni. Se ritenete che un hypervisor in OpenBSD sia qualcosa che vi può essere utile, partecipate alle donazioni.

Ecco infine un esempio di boot:

Attivazione vmm mode:

# vmmctl -e
cpu0: entered VMM mode

Avvio di una VM:

# vmmctl -S -c openbsd_amd64.vmrc
/dev/ttyp0

Aggancio alla VM console:

# cu -l /dev/ttyp0
exit save va/pa  0xfffff000bcff000 0xbcff000
exit load va/pa  0xfffff000bd1e000 0xbd1e000
entry load va/pa 0xffffff000bd2c000 0xbd2c000
vmd: new vm with id 1 created
loading 64 bit kernel
warning: bcopy during ELF kernel load not supported
warning: bcopy during ELF kernel load not supported
mark[start] = 0x1000000
mark[entry] = 0x1000160
mark[nsym] = 0x1
mark[sym] = 0x1939000
mark[end] = 0x1a1de00
mark[random] = 0x18a4000
mark[erandom] = 0x18a6408
vmd: all vcpu run threads for vm 3 launched
vcpu_run_vmx: yielding the cpu
vmd: waiting on thread 0
vcpu_run_vmx: yielding the cpu
vcpu_run_vmx: yielding the cpu
loading 0x1a44000-0x4000000 (0x1a44-0x4000)
loading 0x100000-0x1000000
avail_start = 0x26000
avail_end = 0x4000000
First_avail = 0x1a44000
[ bsd ELF symbol table not valid: bad magic ]
[ no symbol table formats found ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
        The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2015 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 5.8-current (GENERIC) #204: Mon Aug 31 01:13:40 PDT 2015
    mlarkin@miskatonic.azathoth.net:/export/bin/src/OpenBSD/vmm/src/sys/arch/amd64/compile/GENERIC
vmd: i8253 PIT: 16 bit counter I/O not supported
RTC BIOS diagnostic error ff
real mem = 50331648 (48MB)
avail mem = 45101056 (43MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0
acpi at bios0 not configured
cpu0 at mainbus0: (uniprocessor)
cpu0: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz
cpu0: FPU,VME,DE,PSE,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH
,DS,MMX,FXSR,SSE,SSE2,SS,HTT,PBE,SSE3,PCLMUL,DTES64,DS-CPL,SSSE3,CX16,xTPR,PCID,
SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,AVX,F16C,RDRAND,HV,ITSC,FSGSBASE,SMEP,E
RMS
pvbus0 at mainbus0: OpenBSD
vmx_handle_cpuid: unsupported rax=0x40000100
pci0 at mainbus0 bus 0
isa0 at mainbus0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns8250, no fifo
com0: console
vmm at mainbus0 not configured
vmx_handle_cr: mov to cr8 @ ffffffff8131854a
nvram: invalid checksum
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root device:

Ciò significa che OpenBSD/amd64 è sulla strada per diventare un sistema operativo host di virtualizzazione con un suo proprio hypervisor nativo, unendosi al club esclusivo che fino ad adesso annoverava solo OpenBSD/sparc64 con il suo supporto ai logical domain (LDOMs).

Virtualizzazione nella PA

1.798 letture 5 commenti

Mi permetto un articolo su un argomento di interesse “personale“, anche se comunque legato al mondo Unix e Linux in particolare, ossia la presentazione ufficiale del progetto “Virtualizza ME“, avvenuta lo scorso venerdì 18 febbraio presso il Comune di Messina.

Si tratta di un progetto al momento unico in Italia, che ho seguito in prima persona per conto dell’azienda in cui lavoro, e che mira alla trasformazione dell’infrastruttura tradizionale del Comune di Messina, costituita da alcune centinaia di pc installati con Windows e i suoi vari applicativi locali, in un sistema centralizzato in cui il desktop dei singoli utenti gira come macchina virtuale all’interno di alcuni potenti server e viene reso disponibile agli utenti per tramite di client grafici che richiedono pochissime risorse e possono essere eseguiti sia sui precedenti pc opportunamente riconfigurati che su thinclient a basso costo.

Ne parlo in questa sede perchè ovviamente tutta l’infrastruttura si basa su Unix e in particolare su Linux, ed è questo a rendere unico il progetto. Sia i server centrali che la macchina virtuale desktop che i client finali utilizzano Linux, in particolare Ubuntu Server, Ubuntu Desktop 10.04 e Ubuntu LTSP – cosa che non mi rende particolarmente felice, data la mia avversione personale per Ubuntu, ma in ogni caso è pur sempre Linux.

L’infrastruttura hardware è costituita da un sistema IBM BladeCenter E dotato di 3 lame HS22, ciascuna con 2 processori Xeon X5650 2.66Ghz a sei core, 28Gb 32Gb di Ram. Lo spazio disco è fornito da uno storage IBM DS3400, doppio controller RAID5 con 12 dischi SAS da 450Gb per un totale di 3,5 Terabytes e collegato in fiber channel allo chassis. Sulle tre lame è installata Ubuntu Server, e gli host condividono tra loro lo spazio dello storage grazie al file system OCFS2, che consente il montaggio contemporaneo di una stessa partizione tra più macchine, gestendo il locking dei file in modo che non si realizzino conflitti di accesso.

Verde VDI console

Il software di virtualizzazione vero e proprio è VERDE VDI della Virtual Bridges. VERDE è un prodotto commerciale ma si basa integralmente su tecnologie opensource già facenti parte di Linux. Infatti la virtualizzazione vera e propria avviene sfruttando KVM, che è integrato nel kernel. Questo viene corredato di appositi strumenti di gestione che permettono di creare e manutenere le immagini virtuali che poi vengono utilizzate dagli utenti. Il cuore del sistema è la filosofia della Gold Image, ossia una immagine congelata del sistema desktop, che viene creata dall’amministratore direttamente da una installazione standard del sistema operativo desktop così come avverrebbe su una macchina fisica, e poi personalizzata con tutti gli applicativi e le impostazioni necessarie. L’immagine viene freezata in uno stato immutabile da parte degli utenti. Il sistema provvede automaticamente a scindere i dati personali che l’utente crea nella fase di utilizzo (cartelle documenti, file, bookmark del browser, ecc.) e le memorizza in uno spazio separato rispetto a quello della Gold Image, anche se l’utente continua a vedere un tutt’uno esattamente come se il tutto risiedesse sul suo pc locale. Questo fa sì che l’utente non possa materialmente creare nessuna alterazione o danno alla macchina Gold Image e possa intervenire solo sui propri dati. La cosa è particolarmente rilevante ad esempio per quanto riguarda i virus e i trojan horse, i quali anche se dovessero riuscire a installarsi nella macchina virtuale, verrebbero comunque spazzati via al successivo riavvio. Bisogna infatti considerare che il sistema VERDE VDI può lavorare anche con desktop virtualizzati Windows, dove i problemi relativi a virus e danneggiamenti dei file di sistema sono senz’altro più sentiti.

Un altro elemento particolarmente innovativo in questo progetto è l’uso del sistema Ubuntu LTSP in Etherboot per i pc tradizionali. Molti progetti di Desktop Virtualization partono dall’idea che tutti i pc preesistenti vengano buttati via e siano sostituiti da thinclient. Questo rappresenta uno spreco di hardware immenso, genera problemi di smaltimento rifiuti e richiede investimenti per l’acquisto dei nuovi apparati. Noi invece abbiamo preferito trovare un metodo per riciclare l’hardware precedente, che sebbene sia lento e obsoleto per l’utilizzo di Windows è invece più che adeguato a fungere da client di un sistema VDI. E’ stata quindi realizzata una infrastruttura di Etherboot, ossia di avvio delle macchine tramite rete, senza l’utilizzo dei dischi fissi interni, che possono anche essere rimossi dalle macchine. Un servizio centrale di DHCP all’accensione di ciascuna macchina assegna automaticamente un indirizzo di rete e trasmette il sistema operativo, un Linux ridotto ai minimi termini contenente il client di collegamento al VDI. In questo modo il Comune non è obbligato a sbarazzarsi di tutti i pc precedenti ma li può riutilizzare fino alla loro “morte naturale“, e preoccuparsi solo allora di sostituirli con dei thinclient. Inoltre anche in questo caso non è possibile alcun danneggiamento o modifica da parte dell’utente finale, in quanto il tutto risiede su un server e viene trasmesso al pc al momento dell’avvio, ogni volta nel medesimo stato in cui l’amministratore del sistema lo ha preconfigurato.

Le ragioni d’essere di un progetto del genere sono essenzialmente due:

  • eliminare la necessità di continui acquisti di nuovi pc da fornire agli utenti finali, causati dall’aumento di risorse richieste dai sistemi operativi locali e dalla naturale obsolescenza dei sistemi.
  • ridurre le attività di manutenzione delle singole postazioni da parte del personale

Con il desktop virtualizzato, l’unico hardware da manutenere e potenziare è quello dei server centrali, mentre invece le postazioni utente devono essere semplicemente in grado di poter visualizzare il desktop. Anche dal punto di vista della manutenzione, tutte le operazioni di aggiornamento e installazione software, nonchè di gestione e salvataggio dati personali, avvengono sui server centrali. Gli unici eventi che possono accadere a livello di postazione personale sono quelli relativi ai guasti hardware, che si risolvono con la semplice sostituzione del terminale, che non ha nessun effetto sulle personalizzazioni dell’utente.

In questo modo abbiamo dimostrato che un sapiente uso delle tecnologie opensource a basso costo e delle filosofie Linux e UNIX può realizzare progetti di impatto sull’efficienza e sulla riduzione dei costi, applicabili sia in ambito privato che pubblico.