XenRecipes #5 - OpenIndiana PV su XCP 1.6

Sono riuscito finalmente a trovare una versione di pygrub/pvgrub che supporti il boot da ZFS. Ovviamente come spesso accade con progetti distribuiti solo come codice sorgente, ho dovuto smadonnare un bel po’ prima di ottenere dei binari funzionanti. Poi giacche’ c’ero, ci ho aggiunto un tocco personale rimuovendo un po’ di messaggi diagnostici sparati alla console.

PvGrub consente di risolvere il problema dell’uovo o della gallina dovuto al fatto che bisogna far partire un kernel da un file-system che solo il kernel può “interpretare”. PvGrub emula un mini-OS che fa il boot e lancia una versione di Grub in grado di interpretare i file-system tra i più disparati.

Ricetta:

  1. scaricare l’ISO di OpenIndiana in /var/opt/xen/iso (creare il folder se già non esiste).
    cd /var/opt/xen/iso && wget [openindiana.iso url]
  2. copiare alcuni il kernel ed il boot_archive in /guests (creare il folder in caso)
    mkdir /iso
    mount -o loop /var/opt/xen/iso/openindiana.iso /iso
    cp /iso/platform/i86xpv/kernel/amd64/unix /guests/unix
    cp /iso/platform/i86pc/amd64/boot_archive /guests/boot_archive
    umount /iso
  3. scaricare mini-os.quiet.gz in /guests
    cd /guests && wget [url pvgrub]
  4. creare la macchina virtuale via XenCenter e assegnare l’ISO ma non avviarla
  5. switchare la macchina virtuale in modalità PV con avvio da CD
    export UUID=[uuid della VM]
    xe vm-param-set uuid=$UUID PV-kernel=/guests/unix
    xe vm-param-set uuid=$UUID PV-ramdisk=/guests/boot_archive
    xe vm-param-set uuid=$UUID PV-args=
    '/platform/i86xpv/kernel/amd64/unix -B console=ttya'
    xe vm-param-set uuid=$UUID HVM-boot-policy=
    xe vm-param-set uuid=$UUID PV-bootloader=
  6. installare Solaris e fare shutdown
  7. switchare il loader a pv-grub
    xe vm-param-set uuid=$UUID PV-kernel=/guests/mini-os.gz
    xe vm-param-set uuid=$UUID PV-ramdisk=
    xe vm-param-set uuid=$UUID PV-args='(hd0,0,a)/boot/grub/menu.lst'
  8. riavviare Solaris, creare gli utenti, le share, ridurre il timeout in grub, ecc.

Questo tipo di setup non richiede ulteriore manutenzione, ovvero non bisogna copiare o forzare l’update del boot_archive o altro.

PV-grub e’ scaricabile qui oppure qui in versione “quiet”.

-quack

Pubblicato mercoledì 7 maggio 2014 alle 11:55 PM - 0 commenti so far
Archiviato in: Virtualizzazione

Crayless

Ho ammazzato il mio Cray-1, omicidio involontario.

Tutto è cominciato con la violazione innocente e non voluta della legge fondamentale dell’Universo applicata all’informatica: se qualcosa funziona non toccarla, incarnatasi nella versione “tieni Windows Update attivo su Windows Home Server”. In realtà nei casi più comuni è cosa buona e giusta, ma essendo il server completamente rivolto verso l’interno della rete e protetto molto aggressivamente da firewall su firewall, avrei dovuto pensarci prima. Soprattutto perché questo Windows Home Server aveva in carico pochissimi compiti:

  • backup client per CrashPlan, responsabile di mandare nel cloud foto e documenti
  • servizio rippatutto, un piccolo server in grado di leggere una memory card formato Nikon e di smistare foto e thumbnail in share organizzate per mese e anno. Qualcosa che avevo fatto in casa e di cui ero molto orgoglioso
  • server per MyMovies
  • server per condividere la stampante (con funzionalità di scanner con un altro artificio personale ad hoc) in rete
  • server per backup dei PC, in realtà in pensione in attesa di tempi migliori da dedicare al backup dei PC di casa; cosa che sta avendo meno peso grazie ai vari dropbox e OneDrive

Tutto sommato un carico perfetto per una macchina virtuale in condivisione su Cray-1.

Tale server però aveva già mostrato segni di vetustà in quanto in alcune occasioni lo shutdown terminava o in un BSOD o non terminava affatto (neppure dopo 24 ore, test personale effettuato) e richiedendo quindi un hard reset. Non so se la colpa va attribuita a Crashplan (avido di RAM e CPU) o ai driver paravirtualizzati o altro, fatto sta che aveva cominciato a risentirne di ciò il servizio rippatutto, comodo in quanto basato su set-and-forget, richiedendo sessioni sempre più frequenti di baby-sitting. L’idea era di scrivere una app che mi facesse risparmiare tempo (vedasi) ma l’app pronta e funzionale dava segni di matto a causa di qualche impiccio non imputabile al codice stesso.

Poi durante le vacanze di Natale lo scanner ha smesso di funzionare e la causa imputabile a problemi software. Anche in questo caso il tempo investito nell’automation è stato abbondantemente ripagato, ma evidentemente qualche aggiornamento di Windows ha creato problemi ai driver dello scanner.

Se un server incaricato di quattro servizi smette di offrirne due e dà segni scleramento significa che è tempo di cominciare a preparare rimedi: messaggio subliminale accolto e recepito.

Con insolito ottimismo ho pensato: compro un disco a stato solido per installarci il sistema, ci aggiungo un pizzico di RAM (ho comprato un banchetto da 8GB da distribuire fra tutte le VM del Cray), ci aggiungo il vecchio disco meccanico da usare per il supporto del backup dei PC e vivo felice. Mi sfuggiva un particolare che avevo inconsciamente rimosso da tempo: ci avevo già provato ma Xen faceva casino con i dischi e non ho investigato oltre. Ma il prurito cominciava a diventare malanno e ho dovuto “mordere il proiettile” come dicono da queste parti.

Orbene: non so se per colpa di XenCenter o quant’altro, ma aggiungere un disco al sistema si è rivelato impossibile con la configurazione corrente. Pare che alcuni file di configurazione vengano completamente ignorati e sinceramente di capire più a fondo qual è il problema, dopo aver navigato per due giorni in cerca di soluzione, non è qualcosa che mi attira. Avrei risparmiato tempo e salute a corto termine se avessi comprato un disco SSD da un TB o giù di lì (ormai intorno ai 400$), ma a medio e lungo termine sentivo che la battaglia sarebbe stata solo rimandata.

Ho pensato di fare l’upgrade di XCP da sempre in versione 1.5 beta (legge fondamentale di cui sopra) e passare ad una più stabile, tipo la versione 1.6; che l’upgrade in place mi avrebbe preservato le VM e i miei sbattimenti si sarebbero ridotti al limite, ma l’informatica è una brutta bestia piena di promesse non mantenute o persino mantenibili. Mi son ritrovato che le VM erano tutte lì ma andavano tutte riconfigurate ex-novo, inclusa (e non me lo sarei mai aspettato!) una VM completamente virtuale su cui ci girava un XP di annata. Durante l’upgrade l’installer mi aveva persino tranquillizzato promettendo un backup della configurazione corrente in una partizione secondaria, ma i genii che hanno scritto l’installer non hanno messo l’opzione di restore nel CD di installazione. Con l’intenzione di rimandare l’upgrade a tempi più maturi, ho provato a fare un restore binario usando dd ma ho ottenuto un drive che non è più bootabile e, canaglia io, un po’ me l’aspettavo.

Morale della favola il Cray-1 così come era nato e stato concepito due anni fa è spento. Per emergenza ho collegato la stampate al mio router su cui gira tomato e sono rimasto felicemente sorpreso dal fatto che la condivisione della stampante, una delle poche cose che ancora funzionava e servizio da garantire al 99.99999% pena visita alla doghouse, è andata in buon porto senza tanti sbattimenti. Curioso ho provato a vedere se fosse possibile condividere anche lo scanner e mi sembra di aver ottenuto buone speranze: mi rincuora sapere che posso delegare alcuni dei servizi assegnati ad una macchina Windows a server che posso personalmente garantire maggiore stabilità (leggasi l’aggiornamento del firmware di un ruoter avrà cadenze di un paio di ordini di grandezza inferiori a quelli di qualsiasi macchina Windows di Paperopoli).

Sto pensando alle alternative adesso che, dopo due anni, posso permettermi il “lusso” di riconcepire il Cray: credo che testerò l’ultima versione del server VMWare che mi sembra meno pignolo di Xen nel supportare quello che supporta, ma penso che alla fine finirò per scegliere XenServer 6.2, tra tutti i mali quello che penso di conoscere meglio. Penso che sostituirò WHS con WSE (Windows Server Essentials, offre tutte le feature di WHS e di più) in quanto più nuovo anche se dover avere a che fare con Metro in una macchina virtuale o via RDC proprio non mi entusiasma. Il mio ottimismo informatico mi porta a credere che in due anni le cose saranno migliorate di parecchio. Il mio pessimismo cosmico mi dice che devo prepararmi ad un paio di notti insonni e avere un solido piano di rivitalizzazione degli Zombie. Alè.

-quack

UPDATE 1: la prima VM è resuscitata dal regno dei non-vivi, non dopo aver ceduto con l’onore delle armi: BSOD da boot a causa dei vecchi driver Xen. Note to self:

1) l’editor per unix nano non funziona bene e introduce dei line break casuali sulle linee editate
2) nell’esempio dei miei post precedenti non sono indicate (ovviamente) tutte le periferiche. Un buon lavoro però nonetheless.

UPDATE 2: altra buona notizia è che l’upgrade a XenServer 6.2 ha sistemato il baco che ha dato origine a tutto questo incasinamento. La prossima mossa è resuscitare la macchina virtuale Solaris, decisamente il passo più complicato di tutta la procedura.

UPDATE 3: dal supporto di XenServer 6.2:

Does XenServer support Solaris x86 as a guest operating system?

No. The experimental support for Solaris x86 has been removed from XenServer v6.2.0.

In parole povere adesso se l’hypervisor si accorge che stai facendo il boot di Solaris, ferma immediatamente la VM. Piano di backup: installazione di XCP 1.6 (basato su XenServer 6.1) e dita incrociate. Life sucks

Pubblicato mercoledì 30 aprile 2014 alle 7:20 PM - 11 commenti so far
Archiviato in: Cazzate, Virtualizzazione

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