Feature Parity

Oggi, nella migrazione da XEN a KVM/VFIO, sono riuscito a raggiungere una milestone eccezionale: feature parity tra i due sistemi, ma con estrema – molto estrema – semplificazione di architettura. Ho dovuto fare una quantità di esperimenti interessanti, tempo che non considero perso in quanto per me altamente educativo.

Ad esempio all’inizio ero indeciso su quale distro scegliere tra le tre papabili:

  • arch-Linux, scartata immediatamente quando ho scoperto di cosa si tratta il repository AUR: roba distribuita in codice sorgente e mantenuta a tempo perso; anche Crashplan è distribuito purtroppo così e non mi fido di affidare l’applicazione per il backup a gente che dedica spiragli di tempo come me.
  • Fedora: VFIO è nato e sviluppato in Red-Hat. Però santa pazienza, su Fedora bisogna combattere coi draghi solo per installare un server XRDP. Non sto scherzando. La tentazione è stata grande perché le istruzioni più complete su VFIO sono scritte con Fedora in mente.
  • Ubuntu. Familiarità uber all. Ma anche qui il dilemma: LTS o no? Alla fine ho scelto LTS ferma a due anni fa ben conscio che alcune feature interessanti saranno disponibili nella nuova LTS in dirittura di arrivo per Aprile.

Il risultato interessante è che il servizio rippatutto, non senza dolori, adesso gira su una Micro-VM con XP. Avessi più tempo lo riscriverei in Java, ma le funzionalità Text To Speech su Linux sono alquanto primitive (le voci ricordano il SAM dei tempi andati su un C64). Il software di backup e il pool ZFS girano finalmente direttamente sull’host. Nel frattempo ho dovuto imparare come configurare AppArmor e una quantità non irrilevante di cosette, come ad esempio il fatto che il file da configurare per AppArmor è /etc/apparmor.d/abstractions/libvirt-qemu (aggiungere il file di script e sed alla lista).

Risultato finale: anche se parziale, sono soddisfatto.

-quack

P.S. ho comprato un case nuovo, vista l’abbondanza di spazio verticale nella nuova ubicazione. Ho intenzione di installare un adattatore 4x3 e rendere i dischi dati facilmente raggiungibili scopo creazione di un futuro server ridondante per la pace dei sensi.

Pubblicato martedì 16 febbraio 2016 alle 3:36 AM - 7 commenti so far
Archiviato in: Virtualizzazione

2016, fuga da

È arrivato il nuovo anno e approfittando delle vacanze natalizie ho messo a punto il mio piano di fuga. Della fuga da Windows ne ho già parlato, ma in questi giorni sto fuggendo da Solaris. Non è bello sapere di avere un sistema che gira su software in fin di vita. Il mio fedele Solaris para-virtualizzato, in esecuzione su XCP 1.5 BETA, non è più supportato nelle versioni successive. Ho guardato nel frattempo verso KVM che mi sembra molto più stabile con l'idea di avere un host che faccia anche da server SMB e risparmiare una macchina virtualizzata coi suoi costi. Armato di un nuovo HD di provenienza saldi da Black Friday ho fatto il backup del Pool. La mossa successiva è stata quella di installare il Pool su una VM Ubuntu con supporto ZFS ora che pare sia abbastanza stabile: ovviamente non tutto è filato liscio, la tabella delle partizioni di 3 HD su 4 era corrotta: strano che Solaris riuscisse a far partire il Pool in queste condizioni, ma armato di backup ho provato parted. Ho rifatto la tavola delle partizioni da zero e recuperato la partizione, un HD alla volta, e provato che i dati fossero ancora lì. Sistemato l'ultimo HD il Pool è stato importato con successo su Ubuntu. Purtroppo per chissà quale baco misterioso il Pool non è più importabile su Solaris, ma a questo punto poco importa.
Il passo successivo è stato quello di configurare SMB coi suoi permessi, piccoli grattacapi, ma dal punto di vista del Server Windows su cui gira CrashPlan tutto sembra uguale e la cosa è molto, estremamente incoraggiante (il backup di 1.8TB di dati spalmati su 125.701 file è appena completato con successo).
Prossimo passo è quello di spostare CrashPlan da Windows ad Ubuntu, ma sembrerebbe un gioco da ragazzi ampiamente documentato. Se tutto dovesse andare liscio il passaggio a KVM da Xen dovrebbe essere praticamente indolore. Reinstallerei la Workstation di Windows 7 da zero su KVM, visto che l'HD su cui gira al momento è quasi privo di spazio, ma terrò da parte i tre vecchi HD che non si sa mai.
Sorprese positive: SMB è stato più facile da configurare di Solaris una volta letta la paginetta di documentazione appropriata. E siccome Solaris usava CIFS la banda è pressoché raddoppiata: non che sia una cosa importantissima, ma come piccolo bonus extra non ci si può lamentare.
Il passo finale è quello di fare qualche test e decidere il sistema operativo host: sono indeciso tra Ubuntu per la velocità di messa in piedi e ArchLinux per il footprint incredibilmente limitato. Ma questa è una decisione che posso prendere con calma. L'importante è essere uscito da quel brutto vicolo cieco di un ammasso di sistemi arrivati a fine corsia (XCP, Windows Home Server, Solaris). Per i prossimi 4-5 anni dovrei essere a posto.

-quack

Pubblicato giovedì 7 gennaio 2016 alle 12:29 AM - 3 commenti so far
Archiviato in: Virtualizzazione

Upgrading Cray-1

È passato un bel po’ di tempo dal momento in cui “ho chiuso i giochi” su Cray-1. Credo ferventemente nella legge 0 dell’informatica per cui “se qualcosa funziona non si tocca”.

Ma se qualcosa comincia a non funzionare… Ad esempio la strategia di backup si basa su CrashPlan che gira su Windows Home Server. I file però risiedono su un pool RAID-Z gestito da una macchina OpenIndiana para-virtualizzata a cui WHS vi ci accede usando una modalità poco ortodossa. Un paio di volte è già capitato che il mount delle share non è partito in tempo causando un backup parziale. In poche parole ci sono troppi ingranaggi in moto anche se tendenzialmente “tutto funziona”.

Poi mi è capitato di leggere che KVM nel frattempo è migliorato parecchio e il VGA passthrough pare superiore anche a quello di XEN.

E poi ho provato ZFSONLINUX, migrando un pool da Nexenta 3.0 (stessa versione usata per creare il mio pool) a Ubuntu senza tanto dolore; scoprendo che è possibile usare un server SAMBA decente e anche le ACL Posix con ZFS con semplicemente:

# zfs set acltype=posixacl <dataset>

E allora fatti due conti… un nuovo setup basato su Ubuntu eliminerebbe la necessità di una VM per Solaris. Eliminerebbe la necessità di far girare CrashPlan su Windows Home Server, che eliminerei completamente affidandone i due ultimi compiti rimasti ad altri PC già esistenti. Risulterebbe in una virtualizzazione di Windows 7 migliore. E possibilmente in una virtualizzazione di OSX, magari in dual boot con Windows ora possibile visto che il BIOS viene sparato sull’uscita della VGA anziché in maniera cieca.

La tentazione è forte.

-quack

Pubblicato mercoledì 25 marzo 2015 alle 6:19 PM - 2 commenti so far
Archiviato in: Virtualizzazione

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