Názory k článku OpenVZ: vytvořte si vlastní virtuální server

openvz je mrtve, posledni debianova distribuce, kde jde normalne, je lenny

ve wheezym uz nejsou image v repozitari, openvz ani oficialne zadne nenabizi -> oficialne doporucuje KVM

No, ale co budou profesionálové používat po upgrade na nový Debian neví... a to jim na tom běží přes 20 virtuálů a při představě, že to všechno migrují na KVM je jim poněkud mdlo:(

- alokaciu zdrojov zvlada prakticky kazdy virtualizacny nastroj
- vykon je typicky pre kontajnerovu virtualizaciu, so vsetkymi vyhodami aj nedostatkami
- konkurenciou pre OpenVZ je napriklad Vserver (chyba mu len virtualizacia siete)

Aby taky ne, když Red Hat používá jádro 2.6.32.x. Poslední verze OpenVZ je pro 2.6.32 a nevím jestli ještě vyjde pro jiné jádro. Spíš bych čekal, že dožije na Red Hatu a odvozených distribucích a pak už nebude nic. Tomu nahrává i fakt, že vývojáři OpenVZ přispívají do LXC.
Škoda, že se LXC ještě nedá pořádně použít v reálném nasazení, protože jde bez problémů přimountovat /proc i /sys a jako root tam cokoliv změnit. Ačkoliv v izolovaném prostředí to asi tolik nevadí.

Pamatam ze som OpenVZ chcel skusit, a zakysol som hned na zaciatku. Aj ked som pouzil odporucane jadro 2.6.32-openvz-049.6, v jeho konfiguracii som vobec nenasiel volby:

CONFIG_SCHED_VCPU=y
CONFIG_FAIRSCHED=y

Pritom podla wiki sa tieto volby vyzaduju:
http://wiki.openvz.org/Kernel_configuration

Spytal som sa v mail-liste, nikto neodpovedal. Tak som si povedal ze to je daka divna grupa, a skusil radsej vserver. Na pocudovanie, takmer vsetko fungovalo na prvy krat a bez problemov. Navyse komunita okolo vserveru je omnoho ustretovejsia (to mozem povedat na zaklade vlastnych skusenosti)...

Tu odpoved som uz nevidel, to som uz asi odtial odisiel (alebo skoncila v spame, musim pozriet), ale skusil som to aj s tymito options co pises a pamatam si ze kompilacia jadra padala na dakej nedefinovanej funkcii ci co.

Kazdopadne ta informacia vo wiki stale je, to tiez nieco vypoveda o tom aka aktualna je dokumentacia k OpenVZ. Ked clovek postupuje podla navodu, jednoducho musi zakysnut. To nie je dobra vizitka pre projekt...

to snad nemyslite vazne ze niekto by chcel virtualizovat na 32 bit CPU ? kazda virt technologia ma zmysel len na 64bit CPU kvoli dnesnym velkostiam RAM, viac ako 32GB je uplne ale uplne bezna vec na servrovom hardware. takze ak ma produkt poziadavku na 64bit CPU tak to iba svedci o tom ze to nie je "hracka" na doma ;)

Nic proti, ale jestli nekdo uvazujete o nasazeni OpenVZ, pouzijte nektery z klonu RHELu a primo oficialni baliky OpenVZ. Usetrite si hodne bolesti hlavy, budete mit dlouhou dobu supportovanou instalaci a v neposledni rade OpenVZ projekt se soustredi uz jenom na podporu RHEL kernelu. Na vsechno ostatni kaslou a radsi se snazi pomalu mergovat koncepty OpenVZ do upstream kernelu (kde tomu rikaji LXC).

A kdyz ctu tu diskuzi nad mym prispevkem:

Moje zkusenosti s OpenVZ trvaji o vic nez rok dele nez existuje vpsFree.cz, ktere jsem nad OpenVZ postavil (tzn. uz 4 a neco roku), takze si troufam rict, ze s nim opravdu umim a vim o cem mluvim.

OpenVZ *v zadnem pripade* neni mrtvy projekt. Je to zive, vyvojari se snazi, funkcionalitou v linuxovem svete naprosto neexistuje alternativa a stale jeste stale pribyvaji nove funkce.

Zmeny v poslednim roce z OpenVZ delaji nejpouzitelnejsi formu virtualizace pod linuxem, kdyz potrebuju pouzivat jenom virtualizovany linux, musel bych byt budto blbec a nebo paranoik (narazim na absenci SELinuxu), abych nepouzil OpenVZ (podpora NFS v kontajnerech budiz jednim z prikladu, bezproblemovy beh Javy a konecne poradny accounting pameti, ktery s tim souvisi jsou dalsi)

Jedine co je mrtve je OpenVZ v Debianu a Ubuntu, ale to je znama vec.

ehm, myslim ze porovnavat OpenVZ (kontajner) versus KVM (hypervisor), v tom nevidim velky zmysel. Kazda skupina virtualizacnych nastrojov ma svoje + aj - typicke pre dany pristup k virtualizacii. To je ako porovnavat hrusky a jablka.

Ak uz porovnavat, tak bud berme OS-level virtualizaciu (OpenVZ vs VServer vs LXC, pripadne jails na freebsd), alebo hypervisor (KVM vs Xen, pripadne aj free verzie ESXi a HyperV)...

Nemuselo by ist o porovnavanie v zmysle kto je lepsi/horsi, ale skor ktore riesenie co ponuka. Vyhody nevyhody nech posudi ten kto to nasadzuje podla toho comu dava prednost.

hlavne vzhledem k tomu ze v soucasne dobe neni kernel novejsi nez 2.6.32 (Debian 6, RHEL 6) s OpenVZ podporovan, pokud se divam spravne. Jak jiz bylo nekym zmimeno vyse vetsina odpovedi s ohledem na novejsi kernely doporucuje venovat se spise LXC, ktery diky tomu ze je v upstreamu ma snad o neco lepsi vyhlidky...

Taky mi tak nějak přijde, že s projektem, který zamrzl u jádra 2.6.32, se do budoucna vůbec nemá smysl zabývat.

Pozor, neplest RHEL6 kernel s 2.6.32. Dneska uz totiz tolik spolecneho nemaji :)

Neni to to same. Spousta veci je backportovana - veci z blokove vrstvy, filesystemu, sitovani a v neposledni rade hromada ovladacu na moderni hardware (RHEL byva jenom par mesicu pozadu po vydani nove platformy).

ja vim, tuhle praxi RedHat vede se svymi kernely uz leta. Nicmene porad se jedna v zakladu o 2.6.32 strom s naroubovanymi castmi kodu z novejsich verzi kernelu dle potreb a vyberu panu z RedHatu. Ale to pro mne porad neresi tu otazku co pouzivat do budoucna, a mne osobne se pouziti OpenVZ (jakkoliv je to kvalitni virtualizacni prostredi) jevi jen jak ocekani na konec ktery stejne (s ukoncenim podpory 2.6.32) prijde... alespon to zatim tak vypada.

Co pouzit do budoucna? Delate, jak kdyby RHEL6 koncila podpora zitra, nebo za rok :) RHEL6 tu s nami nejakou dobu jeste bude.

Nad OpenVZ stavi produkty Parallels (Virtuozzo), ti jiste maji zajem s byznysem nekoncit. Tipuju, ze jakmile vyjde RHEL7, vyvojari OpenVZ budou rebasovat nad jeho kernel.

Obavu nemam ani nejmensi, proste volim RHEL (konkretne Scientific Linux, zadny CentOS).

No prave, jediny kdo kernel 2.6.32 jeste za rok bude aktivne podporovat je uz jenom RedHat a to v ramci sve distribuce a odvozenin, do upstreamu kde je jadro uz jenom udrzovano se projevi patche na bezpecnostni problemy, zadne nove vlastnosti.
Firma jako je Parallels urcite nebude chtit s byznysem koncit, ale co udelaji a kdy udelaji vedi jen a jen oni, a jestli to bude rebase nebo do te doby nacpou do upstreamu v LXC vlastnosti ktere mu vuci OpenVZ chybi o tom muzem se muzem jen dohadovat...

No a já jsem takhle zmigroval 10 virtualu z Lennyho na Squeeze a vse bez problemu :)

Vzhledem k tomu, ze vmware ESXi je mozne provozovat zdarma, tak si myslim, ze je to mnohem lepsi moznost nez OpenVZ. vmware je jednickou na trhu, jejich produkty jsou propracovane, funkcni, stabilni.

PS.: nedavno jsme ve firme nainstalovali ESXi na server Apple Xserve a odemkla se nam nova moznost - virtualizovat OSX :)

Problem je v tom, ze ESXi nejde nainstalovat na libovolne hardware (na 2 servery nam to vubec neslo, nakonec se ro resilo nakupem certifikovaneho IBM serveru). Navic neplacena verze je neprijemne orezana a nema klienta pro Linux. A posledni vec je to, ze je to uplne neco jineho, OpenVZ jsou kontejnery, ne klasicka (para)virtualizace, tvrdit ze ESXi je lepsi nez OpenVZ je naprosto mimo mísu.

měl jsem podobný problém - ESXi mi nešel na server nainstalovat ... nakonec to vyřešila výměna siť karty

No jo, ESXi ma sice neprijemna omezeni (max 32GB pameti), presto se vyplati vyskouset. Jo a mimochodem, do tydne by mela vyjit verze 5.1 (administrace jenom pres web, uz zadnej vSphere client). I kdyz jeste porad neni tak docela jasne, jestli vubec bude i free verze...

Zas prehanat netreba, v 2 DC som uz videl tolko PSOD (vsetko certifikovany HP hardver), ze Windows a BSOD moze zavidiet. :D Support napicu, posles im dumpy so vsetkym a povedia ti, ze nevedia. :D Skratka propiertarna sracka ako vsetko ostatne.

http://download.openvz.org/kernel/branches/rhel6-2.6.32/current/

You can use latest RHEL6-based kernel builds on your Debian or Ubuntu
machine. Here's how.

1. Get the latest kernel from either Download/kernel/rhel6-testing or
Download/kernel/rhel6. You need vzkernel and vzkernel-devel packages
only, with the -devel being optional.

2. Install fakeroot and alien:
apt-get install alien fakeroot

3. Convert these two rpms to debs using alien. This is
fakeroot alien --to-deb --scripts --keep-version vzkernel-*.rpm

4. Install debs as usual. Reboot. Enjoy.
dpkg -i vzkernel*.deb

A z repozitare debianu testing uz sem si stahnul jenom asi 3 .deb balicky s posledni verzi vzctl. Naprosta spokojenost, testovano jak doma, tak nasledne na firemnich produkcnich serverech.

V minulosti bylo OpenVZ jádro, dostupné přes repozitáře Debianu (tehdy
Lenny), z vývojové větve RHEL 5 "testing", kde nefungovala řada věcí,
jako například nastavování horních limitů systémových prostředků.
V současné době je v repozitářích Debianu (Squeeze) k dispozici jádro
označované jako 2.6.32.5. Toto označení je jaksi matoucí, protože je
neúplné. Jádra OpenVZ, tak jak je vývojáři prezentují, mají vždy v názvu
suffix,
který jasně říká, že jádro je ze zkáceně "stab" nebo "test" větve. Kromě
toho tento suffix nese také čísla major a minor verzí, která dále
upřesňují míru stability tohoto kernelu, takže i jádro s označením
"stab" v suffixu může být určeno spíše k testování, než k produkčnímu
nasazení.

V repozitářích Debianu Squeeze, podobně jako to bylo u Lenny, chybí
informace o tom, o jaký kernel se tedy přesně jedná, neboť Debian zavádí
vlastní označení. Tím pádem je těžké dopídit se nyní nebo v budoucnu
přítomných chyb právě v takto nainstalovaném jádře a mít je pod
kontrolou.

V současné době jsou aktivně vyvíjena jádra 2.6.18 (RHEL5) a 2.6.32
(RHEL6).
Jádro 2.6.32 je podstatně mladší a je nedlouho vedeno také jako
stabilní. Zejména tři poslední vydané verze jádra 2.6.32 prošly spoustou
různě zásadních oprav a změn a to v různých částech jádra (viz
changelogy na stránkách projektu). Nemluvě o tom, že přidáním/úpravou
kódu lze zanést další dodatečné chyby, které se projeví obvykle později
a jinak. Nelze proto úplně souhlasit s tím, že OpenVZ má prudký vývoj
dávno za sebou a je proto již stabilní, bavíme-li se o větvi 2.6.32
(RHEL6). Z vlastní zkušenosti administrátora projektu www.4smart.cz
proto jádro 2.6.32 (aktuálně dostupné v repozitářích Debianu Squeeze)
nechávám stále u ledu a dávám přednost jádru stabilnějšímu, tedy větvi
2.6.18. Očekávám ještě poměně bouřlivý vývoj jádra 2.6.32. Na druhou
stranu, staršímu jádru začíná pomalu zvonit umíráček. Jádro 2.6.18 je
nekompatibilní s udevd, což je občas problém a je potřeba si některé
věci prostě dodělat ručně, kromě toho se postupně začínají objevovat
šablony, které se s takto starým jádrem nesmiřují, například posledni
verze Ubuntu LTS pro server. Jde-li o ovladače, tak i zde je občas
potřeba si trochu zašpinit ruce kompilací posledních verzí zdrojáků a
vytvářenm modulů pro jádro, jako například problém s ovladačem e1000e,
který sice v OpenVZ jádře je přítomen, ale nefungoval správně díky
ztrátám paketů, více na wiki.4smart.cz, kde jsem tento problém řešil s
jádrem 2.6.18. Protože náš projekt je z 90% založen na SSD discích, kde
sídlí virtuální servery našich uživatelů, napadá mě další nedostatek,
tím je absence TRIM v jádře, která se objevuje až od kernelu 2.6.33,
takže s ní nelze v jádrech RHEL5 a RHEL6 počítat.
Avšak i přesto jsou SSD úložiště tou nejlepší volbou a to i v kombinaci
se starším, vlastnoručně vymazleným jádrem 2.6.18, které hostujeme.

OpenVZ lze doporučit. Ovšem pokud to s ním myslíte opravdu vážně, bude třeba
se naučit řešit různé problémy spojené s provozem takového kernelu.

Jaroslav Marák.

Je s podivem, že OpenVZ (a kontejnery obecně) stále žije. Podle mého názoru se to hodí maximálně pro lepší variantu webhostingu, tzn. uděláte s tím nějaký partitioning, ale na nějaké provozování různých systémů s různými rolemi bych to neviděl. Navíc závislost na jednom konkrétním jádře, nedostatečná izolace, ...

Ale jak už bylo řečeno, není to hypervisor, je to kontejner.