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

Potrebbero interessarti anche:
Commenti (6):
1. Snake
domenica 3 febbraio 2013 alle 4:20 PM - chrome 23.0.1271.64 Windows 7
   

Mi permetto di gravediggare il post, perche` la cosa sta iniziando a suscitarmi *tantissimo* interesse

Sto raccogliendo informazioni in giro sul come poter realizzare una soluzione analoga allo scopo di ridurre gli eventuali client in casa a poco piu` di sistemini miniITX senza GPU discreta PCI-Express, ed avere una riserva di potenza di calcolo accessibile all'uopo da una macchina imboscata nello sgabuzzino (ad esempio per video encoding, number crunching con MatLab e robette cosi`), eliminando in un colpo solo il problema dello spazio occupato dallo "scassone" sul desktop (e del conseguente rumore dovuto alla necessaria dissipazione), e mi e` saltato in mente la serie di post che avevi realizzato proprio su XenServer, quindi ne approfitto per farti qualche domanda sparsa:

  1. A distanza di mesi come ti stai trovando con questa soluzione?
  2. Il performance hit rispetto al far girare l'OS guest nativamente in quanto lo quantificheresti, sia come prestazioni generiche che grafiche mediante passthrough della GPU?
  3. I sistemi Guest li usi dalla stessa macchina su cui girano, oppure ci accedi in remoto (come avrei intenzione di fare sostanzialmente io)? VNC e` adatto allo scopo, o magari suggerisci altro per non rovinare l'usabilita` del tutto (lag o perdita di fluidita` della UI etc)?
  4. E` da pazzi immaginare di realizzare un setup del genere anche per gaming saltuario attraverso la LAN, col server nascosto in uno sgabuzzino? (ho timore circa l'eventuale input lag tra client e server e viceversa)
  5. RemoteFX, per l'ultimo punto, potrebbe rappresentare una soluzione? (ho letto in giro di roba fatta da LucidLogix e nVidia, ma sembra che al momento non vi siano applicazioni disponibili per l'utente finale, di contro ho qualche licenza di Server 2012 sia Standard che Datacenter nel caso da usare allo scopo).

 

Grazie come al solito

   
2. Paperino
lunedì 4 febbraio 2013 alle 10:29 PM - chrome 24.0.1312.56 Windows 7
   

Domanda lunga, mi ci vorrà del tempo.

   
3. Paperino
mercoledì 6 febbraio 2013 alle 8:34 PM - IE 10.0 Windows 8
   
  1. A distanza di mesi mi trovo tutto sommato benissimo. Tantissime gioie, pochi dolori. Mi manca un pulsante di reset hardware per resettare la workstation, il PC meno virtuale di tutti. Pero' grossomodo XCP 1.5 e' molto stabile
  2. Non ho misurato e non mi va di farlo in quanto bisognerebbe far girare l'OS guest direttamente sull'HW ed e' una cosa che non mi attira (la scheda madre ha qualche baco nel BIOS antipatico, per cui configurazion che funziona non si cambia). All'atto pratico ho tutta la CPU che mi serve e la virtualizzazione della scheda grafica e' quasi perfetta. Se avessero introdotto le patch che mostrano anche i messaggi del pseudo-bios e le fasi di boot, sarei stato piu' contento. Ad esempio se mai dovessi avere la necessita' di fare girare l'OS in modalita' di recovery, avrei bisogno di accedervi da un altro client. Forse da questo punto di vista la 1.6 e' meglio, pero' non ho ancora voglia di rischiare con l'upgrade
  3. Un sistema guest (la workstation) lo uso direttamente con tastiera e video dedicati. Il resto ci accedo tramite VNC o remote desktop o sshell o quello che e'. Uno di questi e' Home Server che funziona perfettamente in remoto, l'altro e' XP (stessa cosa, VNC o remote desktop), il terzo e' solaris che gira in modalita' testo e quindi sshell.
  4. Io stavo pensando di virtualizzare persino il mediacenter e di usare un very thin client per accedervi. Pero' il lag mi preoccuperebbe parecchio.
  5. Non ho provato RemoteFX e per ora non sento la mancanza.

Sono sempre indeciso se de-virtualizzare il desktop o meno. Ho un PC separato che ho usato per la modalita' di recupero e di cui potrei fare a meno grazie al tablet Android. Pero' le volte che ho avuto noie con la mia virtual workstation sono cosi' poche che non sono per niente convinto di voler tornare indietro.

   
4. Snake
mercoledì 6 febbraio 2013 alle 10:34 PM - firefox 18.0 Windows 7
   

Grazie mille per la risposta

Per l'uso remoto, ho pure visto qualcosina con XenDesktop (che pare usi protocollo proprietario) e come prestazioni/qualita` sembra davvero buono (ho visto pure un demo con Mass Effect 3 eseguito su LAN), ma purtroppo non mi e` ben chiaro se con la Express (che latita di HDX, ma e` l'unica freeware per uso domestico) funzionerebbe ugualmente.

Comunque mi sa a breve provero` a farci qualcosina anch'io

   
5. bondocks
venerdì 8 febbraio 2013 alle 6:53 PM - chrome 24.0.1312.69 Linux
   

@Paperino

Una curiosità..utilizzi XEN con Fedora vero?

   
6. Paperino
lunedì 11 febbraio 2013 alle 3:21 AM - chrome 24.0.1312.57 Windows 7
   

XCP è una "distro" a parte. È una mini-distro ridotta all'ossissimo basata su CentOS. È la versione open di XenServer (anch'esso basato su CentOS ma commerciale). In poche parole:

XenServer : XCP = RedHat : CentOS

Il vantaggio è che posso utilizzare i tool client di XenServer per gestire l'hypervisor.

   
Lascia un commento:
Commento: (clicca su questo link per gli smiley supportati; regole di ingaggio per i commenti)
(opzionale, per il Gravatar)