KVM: felhasználóbarát virtualizáció Linuxra

Kernel

A küszöbön álló 2.6.20-as Linux kernel egy új virtualizációs keretrendszert hoz a felhasználók számára. A KVM (Kernel-based Virtual Machine) nem csak felhasználóbarát, hanem egyben nagyteljesítményű és stabil virtualizációs megoldás, még annak ellenére is, hogy hivatalosan még nincs kiadva - állítja ez a cikk, amely a 2.6.20-rc2-es kernel KVM szolgáltatását és a Debian-ban levő kvm és qemu csomagokat felhasználva telepít Windows XP-t Linuxra. A cikk a telepítés menetének leírásán kívül néhány benchmark-kal is szolgál.

( Csigaa | 2006. 12. 28., cs – 15:16 )

[rosszmáj]
Akkor mostmár nem csak a host hanem a guest rendszerek filejai is korruptálódhatnak? Csodás :D
[/rosszmáj]

Nezd en futtatok 2.2 -ot is ott ahol nem kellett cserelni fut 2.4 is, ugyanez ment 2.2 -> 2.4 valtas idejen, mindenki az instabilitasat hangoztatta. Van 2.6 is es bar en nem kovetem a legujabb kerneleket, de ettol meg a 2.6 is stabil (es joval gyorsabb mint a 2.4 pl network. (5-30%)) Miert is vagy 2.4 only?

ugyanez ment 2.2 -> 2.4 valtas idejen, mindenki az instabilitasat hangoztatta.

Nem véletlen a dolog, rohamosan romlik a Linux kernel minősége verzióról-verzióra, ezért is emelik fel jónéhányan ezzel kapcsolatban a hangjukat. Bár eddig az ilyen "vészmadarak" csak simán trolloknak voltak minősítve, de azért remélhetőleg páran már elgondolkoztak rajta (az abszolút elfogult Linux fanatikusokon kívül :), hogy lehet még is van benne valami, ha már a nagy Andrew Morton is eképp vélekedik... ;P

Miert is vagy 2.4 only?

A 2.6.16.XX ultra-giga-mega-stabil és csak-a-kritikus-fixek-kerülnek-bele és adrian-bunk-által-hosszan-karbantartott kernel fából hetente jön ki új verzió (jó, a legutolsónál most 2 hét volt kivételesen):

2.6.16.36 -> 2.6.16.37: 15 nap
2.6.16.35 -> 2.6.16.36: 7 nap
2.6.16.34 -> 2.6.16.35: 7 nap
2.6.16.33 -> 2.6.16.34: 7 nap
2.6.16.32 -> 2.6.16.33: 7 nap
2.6.16.31 -> 2.6.16.32: 8 nap
2.6.16.30 -> 2.6.16.31: 4 nap

És ez már ugye a 2.6.16 vége, melyet már 9 hónapja csak security bugfixelnek és semmi új nem kerül bele. Persze ilyenkor szokott jönni az, hogy "használj disztrib kernelt", de azért remélem világos, hogy a security bugfixek azokat is érintik (hisz ha talál valamelyik Linux terjesztés készítő egy hibát azt nem csak a saját forrásfájában javítja, hanem beküldi a mainline kernelhez is, tehát meglehetősen ritka az, hogy egy security bug érinti a vanillát, de nem érinti a disztribúció által szállított kernelt). Utóbbinál max. tovább marad sebezhető a rendszer (nagyobb a "sebezhetőségi ablak"), mert (az MS-hez hasonlóan ;) bevárnak és összefognak több javítást és egyszerre adják ki az új kernelt.

Tehát egyrészről nincs kedvem hetente, két hetente kernel szinten updatelni, mert rengeteg időbe tellik (illik éles frissítés előtt menteni és tesztelni, még ha a "kernel szállító" elvileg meg is tette ezt) és nem utolsó szempont az sem, hogy szolgáltatás kiesést okoz minden egyes alkalommal. A 2.4-es sorozat egy elég komoly auditáláson ment keresztül és rengeteg súlyos biztonsági hiba lett javítva benne, köszönhetően isec-es cliphnek és ihaquernek. Egyesek szerint már nem sok kihasználható bug maradhatott benne, főleg ha az ember megpatcheli PaX-al, amelyben lévő KERNSEAL és a nem régóta létező UDEREF is be van kapcsolva. A 2.6-ban viszont van dögivel és ehez nem kell szakértőnek sem lenni, csak elgondolkozni azon, hogy vajon 'Linus és a haverok' áttudnak-e nézni rendesen 20-30 megányi patcheket annyi idő alatt, mint amennyi eltellik 2 kernel release között. Az egészet súlyosbítja az, hogy az isec által már nem folyik a Linux auditálása, Paul Starzetz sem publikál már ilyesmit, ráadásul azt csiripelték a madarak, hogy eladott pár hónapja egy exploitot 2.6-ra, amelyből az következik, hogy van neki több is, meg másnak is. Szóval én hanyagolom éles szervereken a használatát, talán majd ha megnyitják a 2.7-et (vagy 2.8-at? :) és eltellik bizonyos idő (tisztulási folyamat :), akkor esetleg elgondolkozom rajta, de inkább csak akkor fogom használni, ha PaXTeam megcsinálja végre a KERNSEAL-t, amelyik elvileg garantáltan biztonságot fog nyújtani a kernel bugok kihasználása ellen. Nah, röviden ennyi. :P (PaXTeamnek meg küldöm a csekket a reklámért... :)

Figy en hasznalok kereskedelmi os-eket is, semmivel nem nagyobb teher a linux, sot soxor kissebb a sajat kernelfadat fenntartani, mint a masok altal takolt binaris patchekkel elhalmozott rendszeren (rosszabb esetben uj os verzio 2 hiba javit 3 hiba keletkezik (pl. IOS) szarozni.
Nem hinnem, hogy a bonyolultabb rendszer karbantartasa egyszerubbe valik parancsszora, a fejlodes meg szukseges, az luxus lenne. Nezd ubuntut mit tud? Feldiszitett debian, gyorsabb releasekkel, lassan lenyomja az apjat (legalabbis desktop). Es ne nezzunk minden ubuntu felhasznalot kenyelmes luzernek ha lehet...
A security igeny legyen 3party vagy saját kernelfa javitas, ha annyi rendszert tartasz karban akkor megeri..
A beirasommal azt akartam jelezni, hogy ugyan annak nem mond ellent amit irsz, de a 2.8 idejen 2.6 -ot ajanlasz majd csak szerverre...
Szoval az alternativa hol van?

Figy en hasznalok kereskedelmi os-eket is, semmivel nem nagyobb teher a linux, sot soxor kissebb a sajat kernelfadat fenntartani, mint a masok altal takolt binaris patchekkel elhalmozott rendszeren (rosszabb esetben uj os verzio 2 hiba javit 3 hiba keletkezik (pl. IOS) szarozni.

Nem tudom IOS-al kapcsolatban milyen problémád volt, de azért azt nehéz elhinni, hogy (időben és darabszámban) azonos mennyiségű hiba jött elő vele kapcsolatban, mint mondjuk Linuxal... Már csak azért is, mert IOS egy eléggé speciális feladatra szánt rendszer és a kódjának nagysága sem közelíti meg a Linuxét.

Nem hinnem, hogy a bonyolultabb rendszer karbantartasa egyszerubbe valik parancsszora, a fejlodes meg szukseges, az luxus lenne.

A Linux bonyolultabb rendszer, mint az IOS. A 2.6 bonyolultabb, mint a 2.4.

A security igeny legyen 3party vagy saját kernelfa javitas, ha annyi rendszert tartasz karban akkor megeri..

Kérdezd meg a PaXTeamet vagy spendert (vagy bárkit, aki third-party patchet készít Linuxhoz), hogy mennyi idejét viszi el az, hogy a 2.6 újabb verzióit próbálja követni, a saját kódját portolja az új verziókra. Nem egyszerű feladat. Céges környezetben pedig szinte lehetetlen. Nem véletlenül van szarban a Google sem a saját, összetákolt kerneleivel. Irgalmatlan erőforrásokat emészt fel egy saját kernelfa fenntartása.

A beirasommal azt akartam jelezni, hogy ugyan annak nem mond ellent amit irsz, de a 2.8 idejen 2.6 -ot ajanlasz majd csak szerverre...

A 2.4 idején volt 2.5, amelybe mentek a fejlesztések és a 2.4-be pedig csak a javítások, mégis látható, hogy így is ~ 2.4.30 körül lett olyan állapotú, amelyre az ember bátran meri azt mondani, hogy kiforrott. 2.6-nál nincs fejlesztői ág, lapátolják be az új kódokat akkora mennyiségben, hogy azt rendesen átnézni lehetetlenség. Sszoktam mutogatni ezt, ami már meglehetősen rég óta így van. Ha egy patchet így beemel Linus a saját fájába, akkor naívság lenne azt képzelni, hogy a kódot alaposan átnézi. És ez még csak nem is valami bonyolult security bug, amelyet csak hosszas kód tanulmányozás közben lehet felfedezni. Szóval ha lesz is 2.8, akkor is rengeteg időnek kell eltellnie, hogy a 2.6 letisztuljon, de azt hiszem ezt írtam előtte is. Az pedig könnyedén kikövetkeztethető, hogy jóval több időnek kell eltellnie, mint 2.4-nél.

Szoval az alternativa hol van?

Nem mondtam, hogy van alternatíva, csak kicsivel jobb és kicsivel kevesebb szívás. Ez nekem Linux esetén egyelőre a 2.4-et jelenti, ha komoly feladatra szánt szerverről van szó.

A 2.4 idején volt 2.5, amelybe mentek a fejlesztések és a 2.4-be pedig csak a javítások, mégis látható, hogy így is ~ 2.4.30 körül lett olyan állapotú, amelyre az ember bátran meri azt mondani, hogy kiforrott.

megjegyzendo, hogy a 2.5 csak 2.4.14 utan nyilt meg, miutan a nepharag a sorozatosan kijovo irgalmatlanul szar, 2.6-styleban (ezt akkor meg nem sejtettuk) osszeganyolt kernelek miatt kikovetelte (en is felemeltem mar akkor is a szavamat ez ellen).

Csak hogy kötekedjek. ;-))

meglehetősen ritka az, hogy egy security bug érinti a vanillát, de nem érinti a disztribúció által szállított kernelt

Debian stable 2.6.8 :-))
vanilla 2.6.19...

Amúgy a 2.6.18-as egy elég jól sikerült szériának tűnt/tűnik, bugzik ugyan kicsit (PCI-E), de sec. szempontból annyira nem vészes mint az eddigiek. legalábbis egyelőre csönd van körülötte...

És ha lehet mondani, inkább extrább "experimental"-jellegű cuccokban találtak hibát mostanság /SCTP, Bluetoth, Ipv6 / . (jó persze tudom, vannak nem-publikáltak is, de idő kérdése, és majd azokat is megismerjük . :)

A 2.6.19est viszont úgyfest megint elkurták. (fájl korrupciós bugra gondolok most).

Egyébként osztom a véleményedet, nekem még desktopra is jó lenne a 2.4, ha az újabb nvidia driverek rendesen vinnék a 2.4et. :-((

---------------------

Nem a zsömle kicsi, a pofátok nagy...

Debian stable 2.6.8 :-))
vanilla 2.6.19...

OMG. Nyilván az a kód amelyik később került be és bugos nehezen érintheti azt a verziót, amelyikben még benne sincsen. Amiről én beszéltem az az, hogy ha kijön egy security bug, amelyik mondjuk érint egy adott vanilla verziót (legyen akkor nálad mondjuk a 2.6.8 és utániak), akkor nagy valószínűséggel a disztribúció által szállított kernelben is benne van. Nem túl gyakori az, hogy a disztribúció pont átírta a bugos részt úgy, hogy az ne legyen érintett, de persze volt már erre is példa, csak _ritka_.

Amúgy a 2.6.18-as egy elég jól sikerült szériának tűnt/tűnik, bugzik ugyan kicsit (PCI-E), de sec. szempontból annyira nem vészes mint az eddigiek.

Az igazán "jó" security bugok olyanok, amelyek nem jönnek elő általános használat közben. Gondolj a 2.4-nél auditálás közben felfedezett memóriakezeléssel kapcsolatos problémákra. Hétköznapi használat közben (vagy akár nem is csak hétköznapi használat közben, hisz elég sok helyen, elég sok mindenre használják a Linuxot) nem jönnek elő ezek, így az hamis biztonság érzet, ha azt hiszed, hogy ha jól működik valami, akkor abban sechole sincs.

ha azt hiszed, hogy ha jól működik valami, akkor abban sechole sincs.

Azért ennyire naív én sem vagyok. Biztos vagyok benne, hogy fognak még találni 2.6.18-at is érintő sec. bugokat. De súlyosságuk és mennyiségük talán marad a 2.4es széria szintjén.

A 0-day exploitok számára az ünnepek a legjobb terjedési felület, hiszen ilyenkor a legnehezebb reagálni rájuk.

Eddig nyugi volt, tán megússzuk. :))

---------

Nem a zsömle kicsi, a pofátok nagy...

De súlyosságuk és mennyiségük talán marad a 2.4es széria szintjén.

Igen, mondjuk a 2.4.18 szintjén. :)

A 0-day exploitok számára az ünnepek a legjobb terjedési felület, hiszen ilyenkor a legnehezebb reagálni rájuk.

Linux 0day egyelőre nem így szokott napvilágra kerülni... :)

( kovi | 2006. 12. 28., cs – 15:28 )

egész jó sebességeket mértek, tetszik...

( LGee | 2006. 12. 28., cs – 20:43 )

jo ez a betuszo, elmeny lesz ra google-ozni