Xen projektem Linux Foundation (diskuse)

[smazáno]

Jesteze mame kvm . Posun pod LF bohuzel neni moc dobre znameni.

[Nikola Ciprich]

nic o tom nevím, tak bych se zeptal proč? třeba i kernel je v podstatě zaštiťován LF ne? Minimálně Linus tam přímo je zaměstnán.. jinak ale stejně preferuju KVM, takže mi to je skoro jedno..

[smazáno]

Nechci se poutset do detailu, protoze by se to nemuselo libit memu zamestnavateli. Ale rekneme, ze pod zastitout LF jsou i projekty, u ktery musis hackovat configure.ac a Makefile.am nahoru dolu aby se vubec zkompilovali, maji stupidni zavislosti, ./configure neni ./configure ale pousti ./configure v podprojektech a necheckuje ani return kod misto pouziti podpory pro takovyto use-case primo v autotools a radu dalsich obrovskych praktickych problemu. Neco takoveho bych se stydel vydat jako one-man show projekt. Mailing list taky zrovna ukazka open-source pristupu. Ale hlavne ze maji deset lidi ve steering committee . A o politickem pozadi a vubec motivaci, aby se z toho projektu stal open-source uz se radeji rozepisovat nebude.

[smazáno]

Ve zkratce, zastita LF je hlavne marketing, diky kteremu o sobe korporace (v tomto pripade Citrix) muzou prohlasovat jak moc jsou in protoze delaji open-source.

[chrono]

Takže vlastne na presune pod LF nezáleží?

[kyytaM]

Vies vobec o com melies? Xen nebol nikdy tak otvoreny ako je teraz a najdes malo projektov, ktore su vobec na podobnej urovni otvorene a naklonene OSS myslienke. Na user mailing listoch odpovedaju klucovi vyvojari a zakladatelia projektu, na user mailing listoch sa hlasovalo o sposobe zverejnovanie CVE a patchov a davno to nie je len o Citrixe. Hlasovalo o dizajne a obsahu stranok, pravidelne sa usporiadavu dokumentacne dni, kedy vyvojari a komunita opravuju a plnia Wiki. A inak preco by potom tlacili vobec XCP do Debianu, CentOSu a Fedory? Takisto co sa tyka upstreamu, tak prace na jadre a Qemu uz tak pokrocili, ze v Xen 4.3 sa uz bude pouzivat upstream kod Qemu (jadro je uz davno upstreamovane).

[smazáno]

Psal jsem o mych zkusenostech s LF ne se Xenem.

[kyytaM]

Ok, ohladom LF nemam vobec prehlad, ale dobre vediet o co ide. :)

[little.owl]

Jak zde kdysi nekdo nejmenovany psal, LF je predevsim na vybirani penez od sponzoru.

[pavlix]

Mám chuť ho prásknout :).

[smazáno]

no rikej

[pavlix]

To se kolegům nedělá, jen ať se práskne sám :).

[little.owl]

Muj kolega to neni, ale kdyby nebyl tak velke zvire u distribuce, kterou pouzivam, klidne bych ho bonznul .

[snajpa]

Super, je potreba mit nejakou rozumnou alternativu ke KVM (to se totiz soudruhum z Qumranetu/Red Hatu moc nepovedlo, ale rozebirat to nebudem, nemam naladu flamovat tu s fanatiky :)).

[smazáno]

Zalezi na use-case. Me se kvm dost libi. Nainstaluju minimalni instalaci Centos, pustim jeden "yum install" a pak uz si vsechno naklikam na desktopu. libvirt je dost fajn . A vykonove me take vyhovuje.

[smazáno]

I kdyz libvirt vlastne podporuje i Xen, takze jestli je kernel s xen v repozitarich centos, tak by to slo uplne stejne

[kyytaM]

Libvirt bola totalna kopa hovien, ktora takmer zlikvidovala Xen svojho casu. Neviem, ako to je dnes (verim, ze podstatne lepsie)_, ale v minulosti to z pokrocilej funckionality Xenu nepodporovalo takmer nic. Mailing-list bol plny ludi, ktori bojovali s roznymi bugmi libvirtu a nedokazali pochopit ze Xen s tym nic nema (povazovali libvirt za sucast Xenu)

[smazáno]

A za tohle https://jira.mongodb.org/browse/SERVER-2383 take muze libvirt ze?

[Franta]

Alternativa se vždycky hodí, ale to nepodložené házení špíny sis mohl odpustit.

[Sešívaný]

Mně vždycky fascinuje, jak lidi napíšou křišťálově čistý flamebait a k tomu dodají: no flame

[snajpa]

Mohl :) Ja jenom ze mi KVM ukradlo pres pul roku zivota, jak je to nefunkcni a nestabilni vykvet s nulovym vykonem :) [zkus si dat na 4 jadro ~20 VM a poznas]. Oproti tomu s uplne stejnym workloadem vevnitr to kontejnery davaji takovym stylem, ze mam na tom 4 jadru takovych VPS okolo 50ti bez problemu. Xen je jeste posledni rozumna alternativa, kdyby nahodou s kontejnery zacal byt problem - tam tech 20 VM aspon jde mit bez krvaceni z oci.

[little.owl]

Tvrzeni o vykonu v kontextu low level implementace mi prijde do znacne miry podivne. Chcete mi tedy tvrdit, ze KVM ma vyrazne vetsi overhead nez Xen? Za jakych podminek? A nestabilitou rozumite treba pady systemu? Overhead, a i tedy vas vykon lze merit a kvantifikovat. Byly by nejake konkretni cisla a popis scenare?

[zkus si dat na 4 jadro ~20 VM a poznas].

To je opoved na nic. Zkuste si dat pet rumu a uvidite jak vam to pojede.

[Heron]

Co 50. Klidně 500. A ty blbečky, co to chtějí skutečně používat, pošleme někam.

Aktuální zkušenost:

WARNING: You are running in OpenVZ. This is known to be broken!!!

http://www.mind-flip.com/theBlog/2012/08/02/running-to-stand-still-mongodb-and-openvz/

http://docs.mongodb.org/manual/administration/production-notes/#production-virtualization

[little.owl]

Toho je plno, ja jsem na to narazil zde.

[snajpa]

Ale prosim te, kdypak jsi to zkousel realne pouzivat? Ja mam pod OpenVZ 3 instance Monga, do kterych se chrli logy rychlosti cca 30Mbit/s a drzi to v pohode uz pul roku nonstop provozu, nemel jsem jediny problem. Dalsich par desitek lidi ma Mongo na vpsFree a taky s nim nemaji problem.
Ze nekdo napise nekam ze je cosi broken jenom proto, aby to nemusel udrzovat, mi prijde trosku smutne, obzvlast, kdyz plizivym pohybem prichazi LXC, ktere je OpenVZ hodne podobne - takze casem to nekdo pro ty kontejnery stejne musi opravit a mam pocit, ze se to deje i pres podobne hlasky typu "Pod OpenVZ to mame rozbite".
Za 4 roky jsem se dostal k tomu, ze pod OpenVZ mam na starost beh cca. 800 kontejneru, z toho 550 je vpsFree, tam se staram jenom o beh po level kontajneru, u dalsich i o aplikace v nich (clusterovani LAMP / Mongo / ...). Fakt s OpenVZ je mnohem mensi problem a je mnohem vykonnejsi, nez KVM.

[little.owl]

Nikdo nepopira, ze kontejnery maji sve dobre stranky, ale tuhle diskuzi pod Xen jste zacal utokem na KVM, ktery nakonec jen podporujete upornym tvrzenim, ze OpenVZ vam chodi ve vasich scenarich uziti lepe a coz je velmi slabe, a pritom vykrikujete v uvodnim prispevku cosi o fanaticich.

Fakt s OpenVZ je mnohem mensi problem a je mnohem vykonnejsi, nez KVM.

Plno lidi si mysli opak, vcetne Gold partneru SW-Soft, treba zde.

[Heron]

Ze nekdo napise nekam ze je cosi broken jenom proto, aby to nemusel udrzovat, mi prijde trosku smutne, obzvlast, kdyz plizivym pohybem prichazi LXC, ktere je OpenVZ hodne podobne - takze casem to nekdo pro ty kontejnery stejne musi opravit a mam pocit, ze se to deje i pres podobne hlasky typu "Pod OpenVZ to mame rozbite".

Zde se, co se týče virtualizace, zcela rozcházíme. Virtualizace, jak ji chápu já, má být z hlediska provozu OS a app pokud možno zcela nerozlišitelná od reálného HW s tím, že ty rozdíly (limita rozdílu mezi virtualizovaných a hw prostředím) má směřovat k nule. Z tohoto pohledu je zcela mimózní cokoliv upravovat pro jakékoliv virtuální prostředí, naopak, to virtuální prostředí by se mělo snažit jakékoliv rozdíly potlačit. Se zachováním všech výhod virtualizace.

Přijde mi zcela absurdní softwarovému vývojáři říct: "oprav to, na tamté obskurdní platformně to neběží." Co by měl opravovat, pokažené to není.

Mimochodem na zcela stejný princip jsem narazil i když jsem hledal (jen tak se zájmu), možnost běhu PostgreSQL nad NFS. Jediná informace je: požadujeme posix fs a je nám jedno, co to je. Nádherný přístup, tleskám.

[pavlix]

Fakt s OpenVZ je mnohem mensi problem

OpenVZ provozuju na několika strojích čistě z finančních důvodů a z důvodů špatné zkušenosti s LXC a nedostatku času si tu zkušenost nějak napravit.

Ale že bych tomu říkal menší problém než s KVM, které umí spustit virtuál, který se chová jako skutečný stroj. OpenVZ je kupa hnoje, který se v různých situacích různě rozbíjí. Síťová vrstva ze všeho nejvíc. Nastávají tam situace, které se samostatným kernelem ani nastat nemůžou jako že třeba kernelový ipsec tunnel mode nedokáže rozbalené pakety doručit guestům.

OpenVZ je omezené a s jako takovým se s ním musí nakládat. Nelze od něj čekat zázraky. V současném stavu, pokud se za poslední rok něco radikálně nezměnilo, ho považuju za „virtualizaci pro chudé“ (tedy i pro mě v některých projektech). Naději vidím v postupném začleňování jednotlivých věcí do upstreamového kernelu v jakž takž přijatelném stavu.

Výkonnostní srovnání KVM a OpenVZ má sice praktický význam, ale nelze z toho vyvodit, že na KVM je něco špatně. Přecijen KVM virtualizuje hardware, zatímco OpenVZ jen vyčleňuje skupiny systémových prostředků.

[Michal Kubeček]

Síťová vrstva ze všeho nejvíc. Nastávají tam situace, které se samostatným kernelem ani nastat nemůžou jako že třeba kernelový ipsec tunnel mode nedokáže rozbalené pakety doručit guestům.

Vzhledem k množství commitů typu "make XY per-netns" (nebo namespace aware apod.) to bude asi hodně záviset na konkrétní verzi jádra.

[pavlix]

Pokud se něco nezměnilo, tak bych to viděl úplně naopak, než píšeš. Když chci provozovat OpenVZ, tak si stahuju jejich kernel (nebo je zabalený v distribuci). A tím je dáno na jaké verzi upstreamu je založen.

[snajpa]

Jo a kdyz uz jsme u Monga, valim se na zemi ze zrovna to vytahavas jako priklad, protoze Mongo je jedna z nejvetsich prasaren by design, co snad kdy kdo napsal. Pod tvym milovanym KVM si zkus provozovat trochu rozsahlejsi replicasety. Pod OpenVZ se mi nestalo, aby se mi replicaset rozpadnul kvuli pretizeni hardware - pod KVM to ale padalo docela pravidelne (rozumej dvakrat-trikrat do tydne).

[Heron]

Pod tvym milovanym KVM

Spravuju tři lokality na našem vlastním hw, všechno na vmware.