Probabil buba cea mai mare pe care o are (momentan?) Ubuntu 10.04 în ceea ce privește suportul pentru OpenVZ nu este faptul că (momentan?) nu poate fi folosit pe post de HN (Hardware Node), ci faptul că are probleme destul de mari în rularea ca guest. Abia acum am înțeles de ce DAB (Debian Appliance Builder) nu a venit cu suport pentru Ubuntu 9.10, iar acum pentru 10.04. Noul sistem de init, upstart, ce practic înlocuiește vechiul SysV init, nu se prea pupă cu OpenVZ, cel puțin nu implicit în unele pachete de servicii incluse în distribuție. Nu o să mai aduc aminte de clasica deja incompatibilitate între udev și OpenVZ.

Există mai sus vreo două întrebări din categoria “momentan”. Prima cel mai probabil va rămâne la stadiul de permanent. Din moment ce echipa din spatele Ubuntu adoptă LXC, eventualele bug-uri legate de OpenVZ vor intra în caregoria “won’t fix / invalid”, deci feedback-ul din partea comunității să se piardă. Sau să se ajungă la “by popular demand” – sper, deși slabe șanse. Cea de-a doua chestie în schimb se poate să fie rezolvabilă printr-un kernel comunitar ce să includă suport pentru OpenVZ (sper și pentru KVM). Între timp, Proxmox rulează și va adopta 2.6.32 și pentru OpenVZ. Momentan știe doar de KVM.

Ca regulă, cel mai probabil anumite servicii nu vor porni automat, la boot, fără a modifica scripturile de init, ce se găsesc în /etc/init nu în /etc/init.d (un upstart job din init.d este practic un symlink). Suport pentru SysV Init script încă mai este posibil dacă init-ul nu a fost convertit în upstart job din moment ce upstart a fost conceput cu gândul la “backward compatibility”. În ceea ce mă privește, cele mai problematice până acum au fost networking, ssh și mysql. Morala este: pentru a folosi Ubuntu 10.04 ca OpenVZ guest, este nevoie de pregătiri pentru doi termeni de bază: “hack” și “patch”. Cu toate acestea, consider că merită efortul. Lucid Lynx include suficiente soluții actualizate pentru a renunța la vechiul LTS, Ubuntu Hardy. Sau, de ce nu, la Debian Lenny.

Pentru că nu dețin toate informațiile, dau următoarele link-uri de unde mă inspir și eu:
Ubuntu 10.04 OpenVZ Templates
Download Ubuntu 10.04 OpenVZ Templates

Pentru că nu îmi place lucrul manual atâta timp cât există lucruri precreate:
http://bodhizazen.fivebean.net/openvz/

Printre altele, a trebuit să downloadez template-ul lamp pentru a mă inspira din scripturile de init pentru minimal. Sunt adeptul stilului minimal peste care să fac lego instalând direct din repo atunci când plasez o soluție. Less is more!

Dar să revenim la builder. Practic dab este un utilitar menit să subțieze destul de mult procesul de creare al unui template Debian. De fapt procesul în sine nu e mare filosofie, dar este stufos și necesită cel puțin un shell script pentru a reduce repetitivitatea. Cei de la Proxmox au reușit prin automatizarea etapelor de creare să reducă timpul și complexitatea necesară creării unui template OpenVZ pentru Debian. Având în vedere că Ubuntu este compatibil din punct de vedere binar cu upstream-ul (cel puțin la nivel declarativ), dab suportă printre altele și crearea de template-uri pentru câteva versiuni ale acestei distribuții.

Distribuții suportate de către Debian Appliance Builder:

• Debian Etch (4.0) (Legacy Stable)
• Debian Lenny (5.0) (Stable)
• Ubuntu Hardy (8.04) (LTS)
• Ubuntu Intrepid (8.10)
• Ubuntu Jaunty (9.04)

Remarcabilă este absență lui Karmic, deși nu este esențială având în vedere că următorul LTS, Ubuntu Lucid Lynx (10.04), stă să apară. Momentan a poposit la Beta 1.

Practic pașii necesari creării unui template au fost reduși la:

1. crearea unui fișier de configurare (dab.conf) cu o sintaxă “key: value” relativ simplă, explicată în documentație. Joacă rol de “metadata”.
2. init – moment în care se citește lista de pachete din repo-urile distribuției alese
3. bootstrap cu opțiuni, unde subsemnatul preferă “–minimal”. Prefer să am un setup minimal și să instalez din repo pachetele în funcție de context în momentul în care ajung la deploy. Less is more. La bootstrap se face downloadul efectiv al pachetelor în directorul cache al structurii pe care se construiește template-ul.
4. [opțional] instalare de pachete suplimentare. Minimalul lor nu corespunde minimalului meu, ce presupune și: htop, sysv-rc-conf, sysvconfig, bzip2.
5. configurare. Minimal în terminologia mea nu înseamnă o chestie redusă la dimensiune până la absurd, gen template-urile minimale de pe openvz.org ce funcționează cu o târlă de erori ce trebuie reparate de mână înainte de deploy. Plus faptul că sunt actualizate din an în Paște din moment ce sunt în secțiunea contrib iar maintainerii sunt de Duminică (one time only?). Printre altele, le optimizez pentru consum de memorie redus, și anume oprirea serviciilor ce nu sunt necesare cel puțin pe moment: cron, postfix, syslog (cu variații în funcție de distro), ceea ce se traduce prin: într-un container chel o să fie un memory footprint inițial de 1-2MiB necesar serviciului OpenSSH, după cum se lăudau și cei de la IntoVPS. Recordul personal e de 1MiB pe un template Debian Lenny i386 și aș merge pe varianta cu Dropbear în loc de OpenSSH doar de dragul virtualizării și a testării scenariului de “VPS small”. Timp pentru teste să găsesc. Ca dimensiune, ies în jur de 95MiB în urma arhivării gzip, în jur de 275MiB dezarhivat.
6. finalizare – ceea ce presupune curățarea automată a template-ului din containerul temporar urmată de arhivare. Având în vedere faptul că Proxmox VE necesită o sintaxă rigidă în ceea ce privește numele unui template ce trebuie să se regăsească în /var/lib/vz/template/cache (de pe la v1.2 dacă nu mă înșeală memoria), partea de finalize este un real ajutor pentru că se ocupă automat de numele buclucaș.

Singura bubă ce i-am găsit-o până acum este lipsa unui suport bun pentru edit & deploy. Cel puțin mie de îndată ce am rulat dab finalize – nu am mai putut reveni la reconfigurare, rearhivare, retestare. Din fericire dab clean nu șterge lista de pachete. Doar dab dist-clean face curățenie pe acolo, lăsând doar fișierul dab.conf și directorul cache ce e gol (WTF?).

Printre altele suportă crearea de template-uri folosind make și un Makefile. Nu îmi manifest interes deosebit pentru sintaxa Makefile cu care nu sunt familiarizat, iar shell scripting-ul e mai distractiv dacă tot e să automatizăm automatizarea. Suportă anumite scenarii gen bază de date sau PHP, dar cel puțin subsemnatul preferă să facă de mână instalarea de servicii esențiale în funcție de tipul de mașină, fie din repo, fie din surse dacă versiunea din repo e de pe vremea lui Nae.

Per total e un utilitar ce te poate scăpa de stufoșenia creării template-urilor de Debian/Ubuntu folosind debootstrap și un shell, utilitar ce îl Recomand™.

Atâta timp cât trebuie testată doar compatibilitatea userland-ului, o soluție de virtualizare bazată pe OS level virtualization este suficientă, adică se folosesc containere, nu instanțe virtualizare complet. Spre exemplu un setup testat local în container va putea rula pe un VPS, pe un VDS sau pe o mașină dedicată fără probleme. Nu o să fac referire la FreeBSD Jails și Solaris Containers pentru că am puțină experiență cu Jails și zero experiență cu Containers. În plus, destul de mulți se orientează în prezent spre Linux.

Dacă ești vreun guru în a rula vzctl în shell sau masochist, poți să te oprești din citit. Dacă nu, atunci voi vorbi în continuare despre OpenVZ plus metode civilizate și productive de a reproduce un setup. Bariera de intrare printre membrii ce folosesc tehnologia este destul de sus, motiv pentru care au apărut soluții integrate. Dintre acestea, recomand Proxmox VE (Virtual Environment). Băieții aceștia faini de la Proxmox au luat mai multe tehnologii de virtualizare și le-au pus sub același pachet: KVM (Kernel-based Virtual Machine) și OpenVZ, plus o interfață web pentru administrare. Practic Proxmox VE este un Debian Lenny împachetat cu tehnologiile despre care spuneam mai sus.

Setup-up este cretin de simplu, durează vreo 5 minute, se face pe o mașină ce nu are un alt OS. Își alocă tot disk-ul și își face partiții LVM. Este recomandat minim 2GB de RAM disponibil dacă se folosesc mai multe containere, minim 1GB RAM pentru un container folosind pentru ‘package maintenance’ ce are suport SMP și se folosește parallel build. Spre exemplu la un build de PHP cu make -j 3 am rămas fără memorie în container de 512MB RAM. Da, nu recomand instalarea unui compilator în producție sau build pe live servers. Alternativa ar fi DIY, adică o distribuție de Linux ce folosește kernel cu patch pentru OpenVZ, preferabil din repo, plus o interfață web precum WebVZ sau HyperVM.

Proxmox VE se poate instala fie direct pe fier (bare-metal hypervisor), fie într-o mașină virtuală creată cu VirtualBox ce este soluția pentru “desktop” ce o recomand. Am pus desktop între ghilimele pentru faptul că VirtualBox are o arhitectură complexă expusă prin CLI. În GUI se găsește doar un set limitat de funcții. În cazul în care se instalează într-o mașină virtuală creată cu VirtualBox (sau echivalent), nu se vor putea crea mașini virtuale folosind KVM pentru că este nevoie de extensiile de virtualizare din procesor (VT-x sau AMD-V) pentru aceasta. Oricum, scopul principal al acestui articol este OpenVZ datorită flexibilității ce o oferă. Acesta este motivul pentru care merită chiar și soluția de hypervisor sub hypervisor dacă nu îți permiți luxul unei mașini dedicate. În principiu pe o stație de lucru suficient de puternică nu ar trebui să fie probleme în ceea ce privește rularea unui Proxmox VE sub VirtualBox. Îmi permit aroganță de a menționa faptul că nu am mai lucrat de mult pe o mașină sub quad și 8GB RAM.

Având în vedere faptul că pentru OpenVZ se pot crea relativ ușor template-uri, iar virtualizarea constă în crearea unui container nou, operațiunea prin care se obține un nou setup durează destul de puțin. Iar în cazul în care un container nu mai este necesar, distrugerea acestuia este o operațiune rapidă. Practic se obține propriul mini-cloud, ușor de administrat, ce va scădea timpul în care se creează diferite scenarii ce vor ajunge în producție.

În cazul în care nu am fost suficient de clar la început, repet: setup pentru testarea userland-ului. OpenVZ oferă acces limitat la kernel din moment ce nu folosește virtualizare completă a sistemului de operare, doar rețeaua este virtualizată. Spre exemplu folosind kernel-ul livrat cu Proxmox VE se pot folosi FS-uri virtuale bazate pe FUSE dacă se sapă puțin prin vzctl, ceea ce deschide anumite posibilități în producție gen s3fs (netestat sub OpenVZ de subsemnatul, am testat alte module FUSE) prin intermediul căruia se poate monta un bucket de Amazon S3 ca FS local. De altfel, am reprodus și un sistem desktop într-un container OpenVZ, Ubuntu Hardy, accesat prin FreeNX, deci limitările sunt destul de puține gen lipsa unui suport civilizat pentru loop device.

Bun. La partea cu instalarea îmi doream să ajung. Mai bine zis la partea cu actualizarea. De regulă pe un Ubuntu Server ce mai rulează servicii mici/medii VirtualBox are bunul simț să ruleze în background ca daemon printr-un simplu init script. În concluzie actualizările le fac atunci când îmi mai aduc aminte să deschid interfața grafică. Sub Windows în schimb este o jucărie unde mai testez ultimele apariții în domeniul OS. Dar aici mă lovesc suficient de des de acea fereastră ce mă anunță faptul că a apărut o nouă versiune. Click – download  – next, next, next … gata. În teorie era gata. În practică 3.0.12, adică ultima versiune, refuză să adauge orice fel de HDD virtual nou și am o mică bănuială despre imposibilitatea de a adăuga noi mașini virtuale.

Mă apuc să lucrez în calculator să văd ce se întâmplă (doctore). Cretinătatea aceea de installer nu a închis VBoxSVC înainte de instalare. Adică acel serviciu ad-hoc din arhitectura VirtualBox ce se ocupă de mașinile virtuale atâta timp cât rulează cel puțin una. În mod normal stă închis acel proces. Ridicolul merge mai departe. Acel proces, VBoxSVC dă un ‘lock’ exclusiv pe fișierele de configurare astfel încât să nu apară chestia aceea numită ‘race condition’ în geek language. Iar acel proces nu mai vrea să moară. Task Manager-ul e inutil ca de obicei la omorât procese încăpățânate. Am scos artileria grea: Advanced Process Termination (APT). Pe lângă o duzină de metode de kill, știe două metode de kernel kill și încă două de crash kill. Kernel kill pe Windows 7 x64 nu are suport. Nu mi-am spart capul cu hack-ul de OS. Din păcate metodele din user mode au dat greș. Windows încă e copil mic și udă patul atunci când vine vorba de procese încăpățânate. Sistemele UNIX-like (ex: Linux, FreeBSD) rămân în situația penibilă de mai sus atunci când un proces rămâne blocat în ‘IO wait state & friends’. Soluția este evidentă: reboot. Dar m-am cam săturat să rămân cu procese blocate pentru ca Windows e rebut la management-ul lor din ‘user mode’. Iar VirtualBox e rebut la actualizare și nu își știe închide serviciul înainte de un nou ‘deploy’. În mod curios, procesul blocat nu apare în APT. Dar APT are o jucărie numită ‘Custom PID’ pentru a da kill după kill.