Xen recipes #2: creazione di macchine virtuali

Una delle migliori feature di Xen, secondo mio modesto parere, è il supporto di due tipi di virtualizzazione. Quella più tradizionale, vera e propria emulazione di una macchina fisica, e quella che viene definita para-virtualizzazione.

La para-virtualizzazione è una variante della virtualizzazione in cui il sistema operativo host espone delle periferiche virtuali e non emulate al sistema operativo guest, il cui kernel deve essere scritto in modo appropriato per gestire queste periferiche (in parole povere il kernel para-virtualizzato sa di avere a che fare ad esempio con una VCPU anziché un processore vero). Questo kernel modificato è disponibile in quasi tutte le distro Linux ed in generale con sistemi operativi Unix based (Solaris, BSD, etc.). La para-virtualizzazione pertanto non può essere usata per far girare dei guest Windows.

Una macchina virtuale in XEN non è altro che un file di configurazione che elenca le proprietà e le periferiche emulate/passate nella macchina virtuale. Il template da usare, per

device_model = '/usr/lib/xen/bin/qemu-dm'
kernel = '/usr/lib/xen/boot/hvmloader'
builder = 'hvm'
memory = 4096
name = 'vm_name'
vif = [
        'type=ioemu, bridge=br0, mac=00:0b:27:1f:ed:75, model=e1000'
      ]
disk = [
        'phy:/dev/disk/by-id/scsi-SATA_SAMSUNG_HM640,ioemu:hda,w',
        'file:/xen/whs/install.iso,ioemu:hdc:cdrom,r'
]
pci = [
        '00:1d.0',  #front usb panel
]
boot = 'd'
vnc = 1
vncdisplay = 1
usb = 1
usbdevice = 'tablet'
vcpus = 4
localtime = 1

Le righe evidenziate sono quelle da modificare e che contengono il succo della configurazione della macchina virtuale.

Memory: quantità di RAM assegnata in MB
Name: nome della VM
Vif: contiene l’elenco delle schede di rete virtuali; è fondamentale settare correttamente il nome del bridge e creare un mac address ad hoc; se non si specifica il mac address ne verrà assegnato uno a caso diverso ad ogni avvio della macchina virtuale (Windows usa il mac address per l’attivazione)
Disk: l’elenco dei dischi fisici/virtuali da assegnare.
Pci: elenco delle schede PCI visibili al guest (richiede che il sistema supporti VT-d/IOMMU e che la scheda PCI sia sganciata dal sistema operativo host)
Vncdisplay: è la porta vnc da usare. 1 significa porta 5901, 2 significa 5902, ecc.
Vcpu: numero di CPU virtuali da assegnare

Prima di far partire la macchina virtuale bisogna però sganciare dal sistema host le periferiche PCI associate al guest. Per far ciò bisogna conoscere sia il PNP-id della periferica, sia l’indirizzo PCI associato.

Il secondo si ottiene usando il comando lspci che sul mio sistema sputa qualcosa del genere:

[…]
00:1d.0 USB Controller: Intel Series Chipset Family USB Enhanced
Host Controller #1
01:00.0 VGA compatible controller: [FirePro V5700]
01:00.1 Audio device: ATI Technologies Inc RV710/730
[…]

Per ottenere il PNP-id va usato la variante:

lspci -n

che restituisce nel caso in esempio:

00:1d.0 0c03: 8086:1c26 (rev 04)
01:00.0 0300: 1002:949e
01:00.1 0403: 1002:aa38

A questo punto si ha a disposizione sia il PCI-id sia il PNP-Id e si può chiedere all’host di sganciare la periferica con questa serie di comandi prontamente trascritta in un file .sh:

echo "8086 1c26" >/sys/bus/pci/drivers/pci-stub/new_id
echo "0000:00:1d.0" >/sys/bus/pci/devices/0000:00:1d.0/driver/unbind
echo "0000:00:1d.0" >/sys/bus/pci/drivers/pci-stub/bind

La macchina virtuale poi può essere fatta partire via terminale sudato con:

xm create nome-file-configurazione

Una volta partita ci si può collegare usando un qualsiasi client VNC usando l’indirizzo IP della macchina host e la porta specificata nel file di configurazione. Nel caso in esempio poi tutte le periferiche USB collegate al controller PCI verranno viste nativamente dal sistema operativo guest (nel mio caso una stampante e una scheda audio USB).

Il passthru della scheda grafica richiede qualche piccola operazione dal lato client: vanno dapprima installati i driver della scheda grafica “fisica” assegnata, che verrà prontamente rilevata e riconosciuta dal sistema operativo guest, e in seguito va disabilitata la scheda grafica emulata tramite device manager. A causa di qualche problema di instabilità, il file di configurazione di Windows 7 contiene queste ulteriori due righe:

timer_mode = 2
viridian = 1

Last but not least l’uso di driver para-virtualizzati (firmati) disponibili a questa pagina può portare a qualche interessante miglioramento in termini di prestazioni delle periferiche ‘emulate’ (scheda di rete e hard drive).

Sulla necessità della seconda non sono però molto sicuro. E questo è quanto è necessario per ottenere ‘o miracol di una workstation completamente virtualizzata

Il prossimo appuntamento sarà dedicato alla para-virtualizzazione di Solaris.

-quack

Pubblicato martedì 31 gennaio 2012 alle 9:29 PM - 0 commenti so far
Archiviato in: Virtualizzazione

Economia applicata uan-o-uan

Cosa si può fare per trasformare il traffico su un ponte galleggiante di 640 metri da così:

bridgetraffic

a così:

520vc00241?

Basta introdurre un pedaggio dal costo che va di un minimo di 1.60$ ad un massimo di 5.00$ per singola traversata (0.78 centesimi al metro, probabilmente tra i più cari del mondo). Il tutto per finanziare il nuovo progetto di allargamento dello stesso ponte. Il sistema di pedaggio automatico, tra i più avanzati al mondo, ha richiesto diverse iterazioni e rinvii ma è stato finalmente “battezzato” lo scorso 29 dicembre e compiva ieri il suo primo mese di vita.

La leggenda narra di colleghi in preda alla sindrome di astinenza da traffico che dichiarano di attraversare il ponte ad oltre 100mph (per intenderci altra leggenda narra che colti in fragrante oltre i 90mph ci sia l’arresto).

-quack

P.S. sono totalmente favorevole al sistema di tassazione “a consumo”, solo che per ovvie ragioni le tariffe parrebbero elevate. O si lascia intervenire la legge della domanda e dell’offerta oppure (molto più probabile) si introduce un pedaggio sul ponte cugino e parallelo.

Pubblicato lunedì 30 gennaio 2012 alle 7:11 PM - 7 commenti so far
Archiviato in: Seattle e dintorni

Al lupo

Altre due parole sulla questione secure boot.

Riflettevo alla periodicità di certi allarmismi:

C’è stato allarmismo quando è stato imposto l’utilizzo di driver firmati per Windows x64.

C’è stato tantissimo allarmismo quando Windows Vista ha aggiunto il supporto al TPM.

Oggi c’è tantissimo allarmismo per l’introduzione del supporto, in alcuni casi obbligatorio, del secure boot.lupooooo

In realtà da sempre l’introduzione di una nuova piattaforma (x64 allora, ARM oggi) è sempre occasione per ripensare a cosa si poteva fare meglio. I driver firmati sono un passo avanti a tanta robaccia che prima installava pezzi di codice in kernel mode. Ma il salto è stato possibile solo con il cambio di piattaforma in virtù delle qualità di backward compatibility dell’ecosistema Windows, qualità più uniche che rare.

Anche allora si gridava all’anatema: ma oggi, la mancanza di driver non firmati per WinX64 la sente davvero qualcuno?

-quack

Pubblicato lunedì 30 gennaio 2012 alle 8:01 AM - 21 commenti so far
Archiviato in: Software, Trusted Computing

Xen recipes #1: HW e software di base

Ingredienti fondamentali per riprodurre ‘o miracolo.

  1. Scheda madre Intel che supporti VT-d. Ci sono altri produttori che supportano VT-d nei loro modelli ma il tutto è abbastanza fumoso. La mia scelta è andata per una DQ67OW
  2. Processore compatibile VT-d. Ho scelto lo XEON E3-1260L per via della scheda grafica integrata, delle prestazioni (4 core, 8 thread) e dei consumi (45W TDP).
  3. Una sheda grafica supportata, la mia scelta è andata per una FirePro V5700 tra l’altro poco costosa a causa del crash da bitcoin mining (vedasi).

Il bios della scheda madre è alquanto antipatico ed oltre a quello non sono riuscito a configurare l’opzione di default di GRUB: cioé sono riuscito a impostarla, ma il bootloader semplicemente la ignora, per cui ho scelto la via più semplice. Installare GRUB su una chiavetta USB e fare il boot da quella.

Dei tre componenti HW quello più delicato sembra essere la scheda grafica: la percentuale di successo con schede grafiche NVidia o non FirePro è decisamente bassa mentre la V5700 è indicata tra le schede testate (e spero supportate).

UPDATE: ho testato e verificato il funzionamento della ATI 5670 e ATI 5450. Quest’ultima è diventata la scheda grafica che sto usando in quanto silenziosissima per via del raffreddamento passivo e estremamente conveniente (prezzo/prestazioni)

Dopo di che ho installato Fedora 16 in versione x64.
Xen si installa via terminale sudato con

yum install xen

Fin qui la parte facile, descritta anche in questa pagina Wiki.

Più complicato è stato creare il network bridge necessario per la connettività dei vari sistemi virtualizzati. Le istruzioni della pagina Wiki di cui sopra a tal riguardo sono incomplete. Nella directory /etc/sysconfig/network-scripts vanno creati due file.

File ifcfg-br0:

DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
ONBOOT=yes
DELAY=0
NM_CONTROLLED=NO

File ifcfg-em1:

DEVICE=em1
TYPE=Ethernet
ONBOOT=yes
BOOTPROTO=dhcp
NM_CONTROLLED=NO
BRIDGE=br0

Per chi vuole spolparsi il manuale, la documentazione riguardo questi interface configuration files è linkata qui. Il nome del bridge (nel caso di cui sopra è br0) è importante per la configurazione delle macchine (para)virtuali. Dopo di che va disabilitato il servizio NetworkManager (che non supporta i bridge) e abilitato il servizio network al suo posto:

systemctl disable NetworkManager.service
systemctl stop NetworkManager.service
systemctl enable network.service
systemctl start network.service

Come ultima fase del setup iniziale ho creato un folder /xen e ho abilitato la condivisione dei file via SMB usando le istruzioni che ho trovato qui.

Ho creato una nuova installazione di grub su chiavetta USB usando:

grub2-install --force --no-floppy --root-directory=/mnt/USB /dev/sdx

laddove /mnt/USB è la directory su cui è montata la chiavetta USB e /dev/sdx è il file associato al dispositivo che si ottiene usando il comando lsscsi. Ho poi copiato e alleggerito il file di configurazione grub da /boot/grub2/grub.cfg a /mnt/USB/boot/grub2/grub.cfg.

UPDATE:

Ho reinstallato Fedora, non per fun ma in quanto ho notato qualche freeze di troppo possibilmente imputabile all’HD di sistema, e ho messo alla prova quanto scritto. Effettivamente mancano un po’ di passi di cui non avevo preso nota in precedenza.

1. FONDAMENTALE: disabilitare SeLinux editando il file /etc/sysconfig/selinux Nella configurazione da me creata non serve ad un pazzo (oserei dire che molto più in generale SeLinux, alla pari dell’Hardening di Windows Server, non serve ad un emerito pazzo).

2. Se ci si vuole connettere ai vari server VNC da altri client è necessario editare il file /etc/xen/xend-config.sxp modificando la linea che contiene vnc-listen in

(vnc-listen '0.0.0.0')

3. È buona norma spegnere il firewall durante la configurazione iniziale.

4. Disabilitare la shell grafica modificando il run level (vedasi):

rm /etc/systemd/system/default.target 
ln -sf /lib/systemd/system/multi-user.target
/etc/systemd/system/default.target

Last but not least non sono riuscito a trovare un buon sistema per fare un boot affidabile se non cancellando le linee indesiderate da /boot/grub2/grub.conf

Il passo successivo è la creazione di macchine virtuali.

Pubblicato martedì 24 gennaio 2012 alle 1:47 AM - 21 commenti so far
Archiviato in: Virtualizzazione

Xensolidation

Tempo fa mi son posto una domanda che non saprei qualificare: ma se invece di avere un laptop, una workstation e un server creassi un super-computer che ne faccia le veci e sostituissi il laptop con un tablet più consono alla lettura di PDF e CBR?

A pensarci la tecnologia per farlo c’è. Ad esempio VT-d, sigla con cui Intel indica la capacità di virtualizzare, ovvero assegnare fisicamente ad un sistema operativo guest, intere periferiche: controller SATA, controller di RETE, controller USB, porte PCI-*, ecc. Teoricamente si potrebbe assegnare un’intera scheda grafica ed un controller USB ad un sistema operativo desktop che emulerebbe completamente l’esperienza di una macchina desktop pur girando su un hypervisore in compagnia di Solaris per ZFS, WHS per il backup e per servizi .Net, un Windows XP per esperimenti da usa e getta, ecc. (AMD offre una tecnologia equivalente, ma la mia familiarità con i loro prodotti è decisamente scarsa).

Il problema è che sembra che questo scenario interessi veramente a pochi esseri umani in tutto il globo relativisticamente parlando: il supporto della virtualizzazione della scheda grafica è a livello di leggenda ma posso dire, visto che sto scrivendo dalla workstation virtuale, che con un po’ di sforzo è possibile farcela. Ci son voluti mesi, dal punto di vista puramente economico è un discorso completamente in perdita se non si considera la conoscenza derivante avere un valore. Ho provato tante soluzioni: ESXi, 4.x e 5.0, non funziona. XenServer 6.0 sulla carta supporta lo scenario ma non sono riuscito ad installarlo e quindi ho deciso di propendere per la strada più contorta, ovvero XEN.Book of Xen

Devo dire che se avessi fatto l’esperimento un anno fa avrei fallito miseramente: in un anno grossi pezzi di XEN sono diventati parte del kernel ufficiale di Linux per cui oggi tutto è estremamente più semplice o in una parola sola possibile.

Va aggiunto che XEN è uno dei progetti peggio documentati che esistano per cui navigare a vista è impossibile e si sopravvive solo grazie alla Bibbia opportunamente integrata da vagonate di ricerche su Google.

Io sono partito da Ubuntu 11.10, a causa della totale disinformazione a riguardo, che mi ha lasciato intendere che l’Oniric fosse una delle poche distro a supportare XEN come Dom0. L’esperimento ha avuto però alcuni risvolti positivi, ovvero mi ha dato la possibilità di verificare che era possibile sostituire il mio setup basato su ESXi 4.x con uno pseudo-equivalente basato su XEN (improvvisamente VMWare a causa della Netflixizzazione è diventata estremamente antipatica).

Nel frattempo è stato aggiornato il Wiki con una pagina dedicata a Fedora 16 che ne esplicitava la compatibilità completa come Dom0. La sostituzione di Ubuntu con Fedora è stata pressoché indolore (un eufemismo nel mondo Linux).

L’ultimo pezzo del puzzle è stato quello di verificare la virtualizzazione della scheda grafica che seppur parziale (ovvero non funziona durante la fase di boot ma solo dalla schermata di login in poi) è risultata funzionale abbastanza da completare il mio sogno di nuvola personale. C’è ancora qualche asperità da limare (ad esempio cambiare i parametri di default di grub2 che sono complicati) ma il risultato è soddisfacente e consiste in un super-computer, prontamente battezzato Cray1, così configurato:

  • WHS che gira con il suo hard-disk dedicato e un controller USB assegnato (la scheda madre ne ha due e per fortuna uno dei due controlla le USB “frontali”, l’altro le USB “posteriori”). In tal modo ho potuto assengare una scheda audio USB ed un lettore di SD al server per il “servizio rippatutto e senza click” a cui dedicherò uno dei prossimi post.
  • Windows 7 che gira con il suo SSD dedicato e l’altro controller USB per tastiera, mouse e tutto il resto (ció però lascia il sistema Host completamente senza controller USB e per ora non mi sembra rappresenta un problema: nel caso peggiore una scheda PCI-e con qualche porta USB colmerebbe la lacuna)
  • Windows XP che gira in maniera completamente virtuale
  • Solaris, nell’incarnazione made in Nexenta, che gestisce in paravirtualizzazione i 4 dischi dati
  • Linux Fedora 16 a fare da host puro; volendo è possibile controllarlo tramite SSH o via VNC.

Per completare l’opera dal punto di vista prettamente “materiale” ho dovuto hackerare un “comodino” IKEA in piedistallo per il nuovo server accorciandolo in due dimensioni su tre e farcelo stare comodamente all’interno dell’angolo cottura.

Mi aspetto che il futuro, con il rilascio di XCP 1.5, sarà sempre più friendly verso questo tipo di progetti.

-quack

Pubblicato martedì 3 gennaio 2012 alle 7:05 AM - 16 commenti so far
Archiviato in: Virtualizzazione

 
1