A Ovest Di Paperino

Welcome to the dark side.
ARCHIVED

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