OpenVZ vs LXC - virtualizace bez HW podpory

[martin]

Mam tu jako domaci server starsi desku se 4 jadrovym Intel Atomem, ktery nema HW podporu virtualizace (Intel VT-x).
Rad bych zprovoznil "virtualizaci".

Mam zkusenosti s VMware Workstation, VirtualBox a trochu KVM+libvirt.
Vsude je ale pro rozumne pouziti potreba podpora v procesoru. VirtualBox, KVM a qemu jsou na mem Atomu nepouzitelne.

Koukal jsem na kontejnery OpenVZ a LXC. Pokud jsem pochopil, nevyzaduji podporu v procesoru.
Zadne ovladace typu TAP na VPN v jadre nepotrebuji, takze ani to by nemel byt problem.

Je cesta pomoci OpenVZ/LXC realna?

Na serveru mam serverove Ubuntu 12.04 64bit a nic novejsiho tam ted davat nechci.
Pro 12.04 je oficialni dokumentace na LXC, na OpenVZ nic.
Co jsem cetl, tak OpenVZ je stare a nema cenu ho resit.

Je realne rozjet virtualizovany system na Atomu? Zadny zazracny vykon necekam. Co je nejlepsi pouzit?

Nereste prosim napady jako vyhodit Atom, je to na hrani a na pokusy a zere malo elektriny. PC s Xeonem mam jako pracovni, ale kvuli spotrebe nemuze trvale bezet.

[Reklama]

[Ondra Satai Nekola]

A ceho chces dosahnout? (Btw: nad kontejnerizaci jsou i vyssi abstrakce, popularni je Docker.)

[Mirek Prýmek]

Je cesta pomoci OpenVZ/LXC realna? [...] Je realne rozjet virtualizovany system na Atomu? Zadny zazracny vykon necekam. Co je nejlepsi pouzit?

Kontejnery nejsou virtualizace v tom smyslu jako virtualizuje VirtualBox.

Princip kontejnerů si představ spíš takhle: spustíš proces a nastavíš mu flagy, co může a nemůže vidět. Když dvěma procesům nastavíš ty flagy rozdílně, nemůžou se vidět => běží každý v "jiném kontejneru".

Takhle se nastavuje i viditelnost síťových karet atd. takže každý kontejner má jakoby "svoji síťovku", ale všechno je to jenom taková iluze, ve skutečnosti jsou to normální procesy nad normálním jedním kernelem. Projekty jako Docker (a především lidi, kteří o tom píšou a vypráví aniž by pochopili princip) vytváří iluzi, že je to něco víc ("spusťte si ubuntu v centosu!" = kravina jak řemen), ale ve skutečnosti je to jenom "trochu lepší" chroot.

[Mirek Prýmek]

Sorry, úplně jsem zapomněl napsat závěr

Takže: pokud ti nevadí, že všechny kontejnery pojedou nutně nad stejným jádrem a že jejich izolace není kdovíjaká (tímpádem i bezpečnost je diskutabilní), tak klidně LXC nebo Docker nebo Racket použij. Nebo použij chroot, záleží na tom, o co ti jde, co chceš dosáhnout.

[DK]

doporucuju LXC, funguje vyborne... OpenVZ je mrtve (uz jenom diky pristupu ke komunite)

[Reklama]

[Sten]

OpenVZ nekončí, ale zatím není převedené na novější jádro, dokud nevyjde nový RHEL, protože používá jádra z RHEL. LXC využívá hodně toho, co OpenVZ dostalo do jádra. Oboje je kontejnerová virtualizace, takže výkon ± jako bez ní (je tam overhead při komunikaci mezi virtuály nebo grafickém výstupu, pokud použijete virtualizaci celého systému, tedy u OpenVZ vždy). LXC je podporováno libvirtem (existuje i ovladač pro OpenVZ), s Debian Jessie jej využívám. Kromě libvirt je nad LXC postavený ještě Docker, ale AFAIK umí virtualizovat jen jednotlivé aplikace, ne celý systém.

Na jádře starším než 3.8 šlo z LXC utéct, ale dalo se to řešit třeba AppArmorem nebo SELinuxem (ostatně je doporučené nějaký bezpečnostní modul s LXC používat). LXC přinejmenším do 3.16 vyzrazovalo nějaké informace o hostiteli.

[Mirek Prýmek]

Docker, ale AFAIK umí virtualizovat jen jednotlivé aplikace, ne celý systém.

Co znamena "virtualizovat cely system"?

Docker umi v kontejneru spustit proces. Kdyz tim procesem bude init, tak bude "virtualizovan cely system". Ze to neni moc prijemny na pouzivani, protoze takhle Docker nebyl zamyslen, to je jina vec.

[Sten]

Docker, ale AFAIK umí virtualizovat jen jednotlivé aplikace, ne celý systém.

Co znamena "virtualizovat cely system"?

Docker umi v kontejneru spustit proces. Kdyz tim procesem bude init, tak bude "virtualizovan cely system". Ze to neni moc prijemny na pouzivani, protoze takhle Docker nebyl zamyslen, to je jina vec.

Vytvoří to virtuální konzoli, grafický výstup a vstupní zařízení (klávesnici a myš) a správně reaguje na reboot a shutdown (zatímco sandboxovaný init se asi nikdy neukončí)

[Mirek Prýmek]

Vytvoří to virtuální konzoli, grafický výstup a vstupní zařízení (klávesnici a myš) a správně reaguje na reboot a shutdown (zatímco sandboxovaný init se asi nikdy neukončí)

A to snad nejaky kontejner umi?

[Ziktofel]

docker je takova nadstavba nad LXC pro pohodlny pouzivani uz udelanejch obrazu (dalo by se rict, ze docker je takovy slouceni GIT a LXC). Hlavni vyhodou dockeru je deployment aplikaci, kde pripravis uz komplet kontejner se vsema zavislostma pak na cilovem serveru bez ohledu na distro, co tam je abys to mohl jednoduse zprovoznit. takze pokud se chces kontejnerama zabejvat vaznejc, tak rozhodne docker a nove jadro (3.8+). btw u LXC vs OpenVZ uz tak pred rokem jsem nekde slysel, ze pri staveni neceho novyho dat jednoznacne prednost LXC.

[Sten]

Vytvoří to virtuální konzoli, grafický výstup a vstupní zařízení (klávesnici a myš) a správně reaguje na reboot a shutdown (zatímco sandboxovaný init se asi nikdy neukončí)

A to snad nejaky kontejner umi?

Docker neumí nastavit ten kontejner tak, aby tam šlo použít syscally na halt a reboot, nespouští to emulaci zařízení kromě sítě a kontejner se ukončuje s ukončením toho příkazu (je to spíš sandbox). Asi to tam nastavit půjde přímým nastavením LXC (když to nad tím běží), ale je otázka, jestli to má smysl, když to nemusí správně fungovat a libvirt to udělá za vás.

[martin]

Je realne, pokud by byl misto Atomu vykonny server postavit nad LXC jednoduche virtualni desktopy pro par uzivatelu?

Priklad:
Server Ubuntu 14.04 (jadro 3.13, 12.04 ma moc stare) - treba Core i5, nebo i7 a min 8GB RAM.
Na nem cca pro 5-10 uzivatelu virtualni desktopy. Stacilo by LXDE, idelane Lubuntu. Pristup by byl pres RDP/VNC/NX, nebo nejakou jinou vzdalenou plochu.
Neni ani potreba, aby kazdy uzivatel mohl instalovat spoustu programu. Stacil by jim prednastaveny "vlastni" system.

Je to realna myslenka?

[Mirek Prýmek]

Je to realna myslenka?

A k cemu tam ma byt ta virtualizace? Jinak tenci klienti jsou stari jak lidstvo samo a vic se o tom nadsene mluvi, nez se to realizuje

[martin]

A k cemu tam ma byt ta virtualizace? Jinak tenci klienti jsou stari jak lidstvo samo a vic se o tom nadsene mluvi, nez se to realizuje

K oddeleni systemu uzivatelu od systemu serveru.

[Mirek Prýmek]

K oddeleni systemu uzivatelu od systemu serveru.

Oproti normalnimu viceuzivatelskemu systemu to zbytecne zvysuje naroky. Tenci klienti se nijak masove neprosadili ani ve forme toho sdileneho systemu, takze kdyz to zeslozitis, tak tim imho nic moc neziskas. Dnesni hw je levny a ma vykonu na rozdavani, takze spis dava smysl presunovat logiku na klienta nez opacne (viz dnesni weby, kde pulka logiky je v js na klientovi). O virtualnich desktopech a spol. se porad mluvi, uz skoro dvacet let let je to "nejžhavější technologie tohoto roku" (http://en.wikipedia.org/wiki/Network_Computer) ale masove se to porad nenasazuje, asi je k tomu duvod...

Tenky klient ma jakztakz smysl u systemu, ktere se notoricky rozesravaji (Windows), u ostatnich mi davaji smysl spis jiny reseni (bezdiskove stanice, prenos casti vypoctu na server se specialnim hw apod.).