Operációs rendszer szintű virtualizáció alapjai a Linux 2.6.19-ben

Linux

Jó hír azoknak, akik használják és szeretik az operációs rendszer szintű virtualizációs megoldásokat (pl.: OpenVZ, Linux-VServer), hogy minden jel szerint a Linux 2.6.19-es sorozata tartalmaz három fontos alapvető módosítást, ami könnyebbé teszi ezeknek a rendszereknek az illesztését a vanilla kernelhez a jövőben.

Persze ez elsősorban a fejlesztőknek öröm, de nézzük mik ezek a módosítások:

IPC névtér: ez az OpenVZ-ből érkező módosítássál jelentősen egyszerűsödik a virtualizált rendszereken a IPC kezelés.

UTS névtér: ez a patch az IBM-től érkezik, és általa az össes információ, az éppen futó kernelről (az uname -a kimenete) egyedi lehet minden virtuális gépen.

PID névtér előzmények: a PID szám direkt használata helyett a PID struktúrát vezeti be mindenhol, így később lehetővé válik, hogy minden virtuális gépnek saját, egyedi PID tere legyen.

(Forrás)

( gee v | 2006. 10. 19., cs – 10:05 )

Kérdés: Lehet-e egyszerűen különböző Linux kerneleket (verziókat, más-más patcheket) futtatni egy gépen?

Az egyszerűt úgy értem, hogy nem kell mondjuk vmware hozzá.

Ami jó lenne még, ha dinamikusan változhatna a (virtuális) gépek memóriahasználata, annyit használna, amennyi kell neki éppen. Közös diszk cache is jó lenne.

Bár ilyesmire valószínűleg a kernelek nincsenek felkészülve.

G

Szamos modszer (XEN, UML, vagy akar OpenVZ ill. VServer). De egyszerunek egyiket sem neveznem, mivel managelni kell a patcheket, verziokat es a patch-eknek ezekkel a szinten patch formaban terjedo virtualizacios technikakkal is ossze kell hozni, ami neha problemas lehet.

A memoriat altalaban fixre szokas hagyni egy virtualis gepnek, disk cache kozos lehet az operacios rendszer szintu megoldasoknal ill. azok a memoriaval is jobban tudnak gazdalkodni, cserebe csokken a virtualis gepek kozotti szeparacio es meg szamos limit van ekkor.

"Kérdés: Lehet-e egyszerűen különböző Linux kerneleket (verziókat, más-más patcheket) futtatni egy gépen?
Az egyszerűt úgy értem, hogy nem kell mondjuk vmware hozzá."

Van egy kexec nevu feature ami elvileg lehetove teszi, hogy kerneleket cserelgethessel egy futo OS alatt - legalabbis nekem ez jott le abbol amit anno olvastam rola. Tobbszor fejembe vettem, hogy probara tegyem, de valami mindig kozbe jott. :-)

"Ami jó lenne még, ha dinamikusan változhatna a (virtuális) gépek memóriahasználata"

x86 eseten fizikai hardvernel a bios csak egyszer inicializalja a memoria meretet, meghozza bootolaskor. Ezt a cimtartomanyt rogziti, majd adja tovabb a kernel fele. En nem tudok konkret esetrol, hogy a virtualis bios es a guest kernel kozt ezt a "hezagot" szoftveresen megkerulte-e mar valamelyik projekt, pl a virtualizacion keresztul. Lehet, hogy tevedek, de most igy feluletesen vegiggondolva, ketlem. :-(

---------------------
Minél korszakalkotóbb ötlettel állsz elő, annál több hülyén kell átverekedned magadat.

Ahhoz kepest, hogy kb. ket es fel eve olvastam, nagyon nem trafaltam melle:
"A kexec egy kernel patch, amely lehetővé teszi, hogy egy futó kernelből egy másik kernelt indítsunk anélkül, hogy végig kelljen mennünk a bekapcsolástól a másod szintű bootloader-ig terjedő szakaszokon."

---------------------
Minél korszakalkotóbb ötlettel állsz elő, annál több hülyén kell átverekedned magadat.

( gorgo75 v | 2006. 10. 19., cs – 10:07 )

Hála neked én xenezek...(2005 ös linuxtábor óta),érdemes amúgy ezekkel foglalkozni, van előnyük, pl swap használata, performancia ilyenek?

akkor van pl elonye, ha sok azonos linux kernelt akarsz futtatni, pl szolgaltatasonket egyet, ilyenkor jobban tudsz gazdalkondi a fizikai memoriaval.
Olyankor is lehet ilyet hasznalni, ha tobbet akarsz, mint a chroot/jail, de kevesebbet, mint xen/uml wmvare a biztonsag es manegelhetoseg teren.

( prez | 2006. 10. 19., cs – 10:48 )

pár szóban valaki összefoglalná, mi a különbség a xen és ezek között (oks, h az első userland az utóbbi meg nem), olyan oldalról, h ebből mit lát a user (rg)?

( Hunger | 2006. 10. 19., cs – 12:52 )

Az ilyen operációs rendszer szintű virtualizációnál (aka jail, ahol ugye 1 kernel alatt fut az összes "virtuális gép", szebben mondva az elkülönített felhasználói terek) mi értelve van annak, hogy változtatni lehet egyenként a futó kernel információit? Nem látom miért jó, hogy egy userland-be más kernel verziót lehet hazudni, mint a valódi, hisz csak kompatibilitási problémákat okozhat (köszönhetően a rendkívül stabil Linux kernel API/ABI-nak).