Xenews - Luglio 2013

Alcuni giorni fa è stata rilasciata la versione 4.3.0 di Xen. Un sacco di novità enterprise friendly, ma anche qualche miglioria – sulla carta – per quanto riguarda la virtualizzazione di schede VGA.

Purtroppo i pacchetti precompilati non sono ancora disponibili e nel frattempo mi son deciso a provare la versione precedente (4.2.2) su Fedora 19. Si dice che questa versione abbia notato qualche regressione nella virtualizzazione grafica e posso confermare che è così. Ho seguito la primissima ricetta della serie, quella precendente all’installazione di XCP, cercando di utilizzare il nuovo toolkit stack per effettuare le operazioni richieste. Nel momento in cui eseguo il comando per fare il detach della scheda grafica, il sistema va in crash in maniera violenta senza neppure mostrare la schermata infausta di kernel panic (un solo messaggio sul terminale abbastanza agghiacciante: “Killed”; credo si riferisca all’intero sistema).

Probabile che nel prossimo weekend, usando il disco contenente l’installazione di Fedora, tenti l’installazione della “nuovissima” usando il repository sorgente.

Quello che spero sia migliorato:

  • il supporto di Solaris in qualche sua incarnazione (Nexenta?)
  • il supporto dell’uscita monitor durante la fase di avvio della macchina virtuale associata alla scheda grafica. Mi piacerebbe vedere le schermate del BIOS direttamente sul monitor anziché in VNC: oltre ad aumentare l’illusione da “workstation dedicata”, si aprirebbe la possibilità di fare cose come l’avvio in modalità provvisoria senza dover connettercisi via secondo PC.

La speranza è l’ultima a morire.

-quack

P.S. come qualcuno faceva notare, anche il rilascio full Open Source di XenServer è notizia degna di rilievo.

Pubblicato venerdì 19 luglio 2013 alle 9:09 PM - 0 commenti so far
Archiviato in: Virtualizzazione

Xenews - Ottobre 2012

Piccolo ragguaglio di quanto accaduto negli ultimi sette mesi di MondoXen e Cray1.

Non ho provato niente di nuovo seguendo il motto di se funziona non toccarlo. Il mio Cray1 ha un uptime di diversi mesi, senza nessun intoppo software (tocco ferro): gli ultimi due riavvii sono stati causati da pressioni accidentali del pulsante reset della macchina che si è riavviata in tutto il suo splendore e senza colpo ferire.

Ma nel frattempo…

  1. lo stack XCP è stato portato verso Ubuntu. Significa che dopo aver installato XEN si può installare lo stack XCP con un semplice comando apt-get
  2. è stata rilasciata la versione 4.2 di Xen con alcune feature interessanti in concomitanza del punto precedente
  3. è stata rilasciata la versione 1.6 beta di XCP (il Cray1 gira su 1.5 beta) che mimicka le feature di XenServer 6.1 e sono tutte interessanti per chi virtualizza per lavoro

Ora mi sta venendo la tentazione di tirare su un altro server per testare la configurazione parallela. Quel maledetto di Jeff di CodingHorror mi ha fatto notare una feature estremamente interessante delle schede madre SuperMicro.

Per fortuna c’è carenza di tempo ed io ne soffro un po’

-quack

Pubblicato venerdì 19 ottobre 2012 alle 8:48 PM - 0 commenti so far
Archiviato in: Virtualizzazione

Xen recipes #4: Xen Cloud Platform 1.5 beta

XCP è una versione standalone di Xen basata su CentOS. Ovvero da usare out-of-the-box invece di installare l’OS, poi Xen, poi configurare, bestemmiare, inveire, ecc.

È basata su XenServer allo stesso modo in cui CentOS è basato su Red Hat: ovvero siccome il sorgente è pressoché pubblico, non è altro che una ricompilazione accurata di quanto disponibile al punto che è possibile installare il “client” di XenServer per farlo parlare con XCP. XenServer 6.0 a sua volta è una ridistribuzione minima di CentOS + Xen4.1 + altri tool interessanti per la virtualizzazione + client abbastanza carino + preconfigurazione no-nonsense (infatti SELinux non mi pare sia neanche installato).

L’unica noia è che non so per quale motivo, ufficialmente si parla di stabilità ma io non ci credo, alcune feature di Xen non sono disponibili direttamente ma sono attivabili con workaround non ufficialmente supportati.

Quando ho cominciato l’esperimentòn la versione di XCP disponibile era la 1.1 basata su XenServer 5.6 basato a sua volta su Xen 3.0. Poche settimane fa invece è stata rilasciata la beta della versione 1.5 che ho installato su un disco di sistema separato, onde evitare rimpianti. Applicando tutti i workaround del caso XCP 1.5 offre tutto quello che mi ha finora offerto Fedora+Xen e anche qualcosina in più.

I workadound servono a:

  1. supportare il passaggio di dischi fisici direttamente al guest. È incredibile XS6 permetta di farlo solo con dischi rimuovibili: la “scusa” è che i dischi fisici non permettono la migrazione, ma questo cozza con il fatto che c’è il supporto del passthrough della scheda grafica che impedisce migrazioni.
    Il trucco è di aggiungere due regole al file /etc/udev/rules.d/50-udev.rules come spiegato in questo post. Le mie ad esempio:
    ACTION=="add", 
    ID=="1:0:0:0|3:0:0:0|6:0:0:0|7:0:0:0|8:0:0:0|9:0:0:0",
    SYMLINK+="xapi/block/%k", RUN+="/bin/sh -c
    '/opt/xensource/libexec/local-device-change
    %k 2>&1 >/dev/null&'"
    ACTION=="remove",
    ID=="1:0:0:0|3:0:0:0|6:0:0:0|7:0:0:0|8:0:0:0|9:0:0:0",
    RUN+="/bin/sh -c '/opt/xensource/libexec/local-device-change
    %k 2>&1 >/dev/null&'"
  2. supportare il PCI passthrough, per la stessa stupida scusa accampata al punto 1.
    Per farlo bisogna editare il file /boot/extlinux.conf e “nascondere” i dispositivi da passare ai guest:
    append /boot/xen.gz dom0_mem=752M lowmem_emergency_pool=1M
    crashkernel=64M@32M console= vga=mode-0x0311 ---
    /boot/vmlinuz-2.6-xen root=LABEL=root-ogqzyliv ro
    xencons=hvc console=hvc0 console=tty0 quiet vga=785 splash
    pciback.hide=(00:1a.0)(00:1b.0)(00:1d.0)
    --- /boot/initrd-2.6-xen.img

    Una volta riavviato e verificato che i dispositivi sono disponibili al pass-through (xl pci-list-assignable-devices), bisogna assegnarli alle macchine virtuali con il comando:
    xe vm-param-set 
    other-config:pci=0/0000:00:1a.0,0/0000:00:1b.0 uuid=...
    dove lo uuid della macchina virtuale che interessa si ottiene con:
    xe vm-list
  3. Manipolare il numero di versione in modo tale che il client riconosca il server come XenServer 6.0.99. P
  4. UPDATE: se ci si vuole connettere alle VM senza usare XenCenter (ad esempio su un Mac) è necessario creare dei tunnel SSH in quanto VNC non è esposto ad ip esterni. Per farlo ci sono un paio di tutorial:
    Using VNC to Connect to a XenServer VM’s Console
    How to Set Up VNC Channels Using PuTTY

In aggiunta ho trovato anche molto utile questo post in cui viene presentato uno script che faccia partire una serie di macchine virtuali in automatico.  UPDATE: un’alternativa è quella di creare una vApp chiamata “autostart” e lanciare la vApp tramite rc.local con:

sleep 10 && UUID=`/opt/xensource/bin/xe appliance-list 
name-label="autostart" | /bin/grep uuid | /bin/awk '{ print $5 }'`
&& /opt/xensource/bin/xe appliance-start uuid=$UUID

(su unica riga)

Questa seconda alternativa presenta il vantaggio che tramite la configurazione della vApp è possibile determinare l’ordine di lancio e il delay di ogni VM.

Last but not least da linea di comando è possibile settare la priorità delle singole VM con i comandi:

xe vm-param-set uuid=<Template UUID> VCPUs-params:weight=100
xe vm-param-set uuid=<Template UUID> VCPUs-params:cap=100

Per ora, a differenza di Fedora, non mi sembra che si sia presentata la necessità di modificare le priorità di default di ogni singola VM se non tramite l’aggiustamento di numero di VCPU assegnatele.

Fatto un calcolo finale il “costo” dei workaround è simile al “costo” di tutta una serie di configurazioni aggiuntive da fare in Xen puro. In cambio XenServer/XCP offre la possibilità di creare snapshot delle macchine virtuali, cosa non disponibile in Xen se non tramite artifici non proprio perfetti.

Il mio giudizio finale è che XCP competa molto bene con VmWare ESXi: quest’ultimo è ricchissimo di feature non tutte decisamente utili a patto di un costo abbastanza elevato e il mancato supporto al VGA passthrough, indispensabile per il Cray1. E che sia una beta non lo si sente affatto.

UPDATE: un paio di altre informazioni utili su XCP/XenServer.

PARAVIRTUALIZZAZIONE: questi sono i comandi utili per configurare le macchine para-virtuali ed in particolare Solaris

xe vm-param-set uuid=... PV-kernel=<host path to 'unix'>
xe vm-param-set uuid=... PV-ramdisk=<host path to 'boot_archive'>
xe vm-param-set uuid=...
PV-args='/platform/i86xpv/kernel/amd64/unix -B console=ttya'
xe vm-param-set uuid=... HVM-boot-policy=
xe vm-param-set uuid=... PV-bootloader=

PCI/VGA-PASSTHROUGH: se si sceglie di configurare la scheda grafica virtuale tramite l’interfaccia grafica del client, i setting relativi al PCI-Passthrough verranno sovrascritti. Per supportare il passthrough di dispositivi PCI in combinazione con la scheda grafica è importante usare la riga di comando come specificato sopra.

UPDATE 2:

Una delle ultime cose che ho fatto è stata la personalizzazione degli splash screen (ce ne sono due). Il primo è embedded nel ramdisk. Per modificarlo basta editare il file /usr/share/citrix-splash/background.png, fare un backup di /boot/initrd-2.6.-xen.img e ricrearlo con il comandone:

mkinitrd --theme=/usr/share/citrix-splash --builtin=dm-mirror 
--builtin=dm-snapshot --builtin=dm-zero
--builtin=scsi_trasnport_fc –f /boot/initrd-2.6-xen.img `uname -r`

Il secondo splash screen, animato, è più abbordabile ed è contenuto nel folder /usr/share/splashy/themes/default. Una volta editato lo si setta come splash screen attivo tramite:

splashy_config -s default

L’immagine che mi son scelto l’è carina:

background

E questa dovrebbe essere l’ultima noiosissima ricetta della serie, serie che somiglia tantissimo al Cray 1 deployment document.

-quack

Pubblicato lunedì 5 marzo 2012 alle 7:40 PM - 6 commenti so far
Archiviato in: Virtualizzazione

Xen recipes #3: guest OpenIndiana 151 para-virtualizzato

Per installare Solaris (o qualsiasi derivato come Nexenta/OpenIndiana/ecc.) c’è bisogno di fare ricorso alla para-virtualizzazione. In questo caso il sistema operativo guest viene fornito di un kernel appropriato e il tutto si trasforma in un piccolo esercizio di ricorsione.XenFu

Sotto questa modalità l’hypervisore lancia ed esegue direttamente il kernel para-virtualizzato ed il problema è quello di estrarlo e copiarlo sul sistema operativo host insieme a qualche altro pezzo di sistema (nel caso di Solaris c’è bisogno anche del boot_archive). Ergo occorre:

  1. estrarre e copiare i file platform/i86xpv/kernel/amd64/unix e /platform/i86pc/amd64/boot_archive dall’iso in una directory sul sistema operativo host (ad es.: /xen/openindiana)
  2. creare un file di configurazione usando il seguente template:
    name='openindiana'
    memory = "2048"
    vif = [ "mac=FF:FF:FF:FF:FF:FF, bridge=br0” ]
    disk =  [
            "file:/xen/openindiana/oi.img,xvda,w",
            ]
    vcpus=2
    kernel = "/xen/openindiana/unix"
    ramdisk = "/xen/openindiana/boot_archive"
    extra = "/platform/i86xpv/kernel/amd64/unix -B console=ttya"
  3. lanciare la macchina virtuale ed eseguire l’installazione.

Terminata l’installazione, prima di spengere la macchina virtuale, vanno annotati il root dataset (comando “zfs list”; valore di ‘default’ rpool/ROOT/openindiana) e il nome del disco di avvio così come identificato dal sistema (comando “echo format”, dovrebbe restituire qualcosa come xdf@51712).

Successivamente, prima del primo riavvio, va modificata la linea evidenziata in modo da indirizzare il kernel appena installato verso il file system appena creato con la seguente:

extra = "/platform/i86xpv/kernel/amd64/unix -B zfs- 
bootfs=rpool/ROOT/openindiana,bootpath=/xpvd/xdf@51712:a"

(unica riga)

A questo punto il sistema guest si avvierà e comincerà a funzionare come da aspettative. Se si vuole usare openindiana come server SMB, bisogna avere l’accortenza di aggiungere questa riga al file di configurazione /etc/pam.conf altrimenti l’autenticazione SMB non funzionerà come ci si aspetta:

other [TAB] password required [TAB] pam_smb_passwd.so.1 [TAB] nowarn

([TAB] rappresenta il carattere di tabulazione).

Un’ultima importante osservazione è che alcune operazioni, come l’import di pool esistenti, tendono a modificare il file di ramdisk. Per cui, prima di riavviare per l’ultima volta potrebbe essere necessario forzare l’aggiornamento del ramdisk (che solitamente avviene durante l’operazione di shutdown) con:

bootadm update-archive -f

e sovrascrivere il ramdisk presente sul sistema operativo host con:

scp /platform/i86pc/amd64/boot_archive 
root@ip_host:/xen/openindiana

(unica riga)

Teoricamente si può bypassare questa necessità di tenere copie aggiornate di kernel e ramdisk sul sistema operativo host usando dei bootloader di guest alternativi come pygrub, però purtroppo l’ultima versione di pygrub non supporta l’ultima versione di ZFS per cui, fino a patch definitiva, quella di sincronizzare i file sull’host è una pratica necessaria.

Le performance di una macchina para-virtualizzata su XEN tendono ad essere significativamente superiori a quelle di una macchina fully virtualized; c’è infine da aggiungere che purtroppo le ultime versioni di Solaris non girano correttamente in maniera fully virtualized e pertanto la para-virtualizzazione rappresenta l’unica via di uscita.

-quack

Linkografia utile:

http://www.gossamer-threads.com/lists/xen/users/200909
http://docs.oracle.com/cd/E19082-01/820-2429/smbservertasks/index.html
http://tinyurl.com/89m4j8s
http://360is.blogspot.com/2010/03/paravirtualized-opensolaris-solaris-on.html

Prossima puntata le variazioni sul tema XCP 1.5, versione opensource di XenServer 6

Pubblicato martedì 28 febbraio 2012 alle 2:43 AM - 6 commenti so far
Archiviato in: Virtualizzazione

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