Már minden megtalálható a mainline Linux kernelben a Xen Dom0 és DomU támogatáshoz

Kernel

Wim Coekaerts, az Oracle Linux engineering csapatának vezetője nemrég blogbejegyzésében közölte, hogy egy relatíve hosszabb és némi görönggyel tarkított út végéhez érkeztek, mert Linus kernelfája néhány napja már a szó szoros értelmében mindent tartalmaz a Xen Dom0 és DomU támogatáshoz.

"Mindez azt jelenti, hogy a támogatás minden egyes darabja, amely a Linux-ban ahhoz kell, hogy az tökéletesen együttműködjön a Xen-nel, benne van a mainline kernelfában. Az elmúlt években azt hallottam, hogy a versenytársak a "Nincs Xen támogatás a Linux-ban" szlogent használták fel FUD keltéshez a Xen felhasználói bázison belül, hogy az alternatívákat reklámozzák. Nos, minden ott van emberek. Mostantól, ahogy a Linux fejlődik, a kódbázison belül a Linux/Xen darabok is ugyanolyan ütemben fognak fejlődni különálló patch fák és nagy kódok cipelése nélkül."

A részletek elolvashatók itt.

( uid_18247 | 2011. 05. 29., v – 10:07 )

vidám subscribe

------------------------------------------
Egyetlen vi-parancsot ismerek, a kilépést.

( uid_6201 v | 2011. 05. 29., v – 14:24 )

Hajrá! Ismét fellángolhat a versengés a KVM és a XEN között. Mindez a felhasználók előnyére.
Nálam egyébként Debián alapon a XEN illetve a másikban KVM segítségével virtualizált szerverek egyaránt stabilan futnak évek óta.

Milyen versengés? Majd ha a Redhat olyan menedzsmenteszközöket szállít a KVM-hez, mint a Citrix a XenServerhez, akkor lehet erről beszélni.

És akkor arról még nem is beszéltünk, hogy a vSphere-het képest hol van mindkettő. :(

--
Web 2.0: you make the content, they make the money.

Nem csak az enterprise scene létezik. A lakossági virtualizálásban a KVM nagyon feljött és újabb boom előtt áll a SPICE végett.

Az enterprise szintű menedzsment eszközökért pedig nem kis nevek álltak a KVM mögé a Redhat, SUSE, Eucalyptus mellett: HP, IBM, Intel, BMC. Ha kicsit előretekintessz, a Xen-nek nagyon fel kell kötni a gatyát.

Egyébként látott már valaki olyan programot, aminek szüksége volt erre az XP mode-ra?

Én eddig egyetlen programmal találkoztam, ami alapból nem volt hajlandó elindulni a 64 bites win7-en, de egy patch és egy undocumented command-line kapcsoló megoldotta a dolgot. (Egyébként ez a '99-es revolt volt. :))

--
Don't be an Ubuntard!

Szerintem meg inkabb most jobb ha csondbe maradtal volna. Egyreszt a Redhat miota "lakossagi" virtualizaciot szallit? Igen na most a KVMnek az I/O teljesitmenye a beka segge alatt van kettovel. De kb latszik ,hogy kozod nincs a temahoz csak beirtad a googleba ,hogy XY nyujt hozza dolgokat.
--
1 leszel vagy 0 élő vagy hulla!

Nekem nagyon jó IO teljesítmény jött ki a KVM/QEMU Storage Stack Performance Discussion után beállított rendszeren, annyira, hogy manapság már egyes IO teszteket KVM-el virtualizált vason futtatok, mert majdnem natív teljesítmény.

Talán ha nem raid6-on lévő qcow2-ből próbálnád writeback cache nélkül IDE-t emulálva, anticipatory schedulerrel.. Hozzá nem értéssel vagy szándékosan nyilván el lehet rontani bármit..

Ebben a stílusban inkább neked nem kéne megszólalni, akkor sem, ha esetleg igazad lenne.

Azért blokk szinten is el lehet evickélni szerény eszközökkel, pl NFS helyett iSCSI. A redundáns iSCSI/NFS backend szerver pedig ígyis-úgyis megoldandó feladat (SAN/DRBD/stb). Valszeg kicsit nehezebb lesz a menedzsmentje, dehát kompromisszum mindenhol van.

Szerintem az a baj a rendszerképekkel (jó hupmagyarul), hogy egy fájlrendszer a fájlrendszeren egyszerűen őrültség. :) Nehézsúlyú layer-eket von be csöppnyi kényelemért. Persze én is használom akkor, ha nem kell az IO teljesítmény.

Nem ertem, hogy jon a kepbe az nfs?:)
A redundans let pedig tobb esetben csak opcio, nem kovetelmeny.

Igen, vmi kompromisszumot mindig kell kotnie a usernek, barmelyiket valasztja.

tompos

ui.: Sosem ertettem, az emberek tobbsegenek a SAN miert egyenerteku a redundanciaval? Az ugyanugy tonkremehet, mint ha az egy szimpla szamitogepnek hivott HDD-vel telepakolt eszkoz.

t

Az NFS-t csak onnan tippeltem, hogy kérdezted:
"Vagy hogy mozgatod a gepek kozott a VM-eket?"

Ha image-eid vannak és a VM-eket hol itt hol ott akarod futtatni, akkor az NFS triviális, gondoltam. Viszont mostmár teljesen elvesztettem a kontextust, haggyuk. :)

--

Azért van különbség, mert egy SAN dobozon belül a backplane-re már két független kontroller csatlakozik (kissé leegyszerűsítve). Az A kontroller, illetve a számítógép "gyakran" elromlik. SAN-nál ilyenkor ott a B kontroller, a számítógépnél meg csak a sarki PC kuckó.

Én azt szoktam mondani, hogy azt is le lehet ejteni.. De erre is azonnal rá lehet kontrázni, hogy a SAN-ok is tudnak "DRBD-zni" (tükrözni).

Az 1 kontrolleres SAN - hát - ott már tényleg csak az az érv marad, hogy a PC-t elég macerás FC targetté varázsolni. :)

Az nfs epphogy nem megfelelo, mivel azzal csak azt tudod biztositani, hogy mind a ket host elerje a NAS-t, a NAS redundanciajat nem.

Igen, controller ketto van, de a hajadra kenheted, ha megis mashol a problema. Igen, mindent lehet tukrozni, de nem ez nem volt kerdes. Ugy tekinteni, mint hogy 1 db SAN az egyenerteku a redundanciaval csak szemfenyvesztes. Annal akkor a ket PC drbd-vel is nagyobb redundancia-t biztosit.

tompos

ui.: Igen, lattam mar kampo SAN-t. Ott alltak az okoskak es csak bamultak tudalekosan a fejukbol.

Én se állítom, hogy a SAN a hovatovább, csak hogy egy mezei PC-nél 1 szintel fentebb van.

Egy I*M SAN egyszer úgy elhasalt egy online firmware frissítésen, hogy eldobta a writeback cache-t és durván lesérültek a fájlrendszerek, pedig I*M mérnök csinálta, én csak mögötte kapkodtam a levegőt amikor mondta, hogy "lehet van egy kis gond". :)

( Cajga | 2011. 05. 29., v – 20:54 )

"hogy a versenytársak a "Nincs Xen támogatás a Linux-ban" szlogent használták fel FUD keltéshez a Xen felhasználói bázison belül"

Igen, ezt én is beszívtam sajnos. Mikor megtudtam, hogy a RedHat EL6-ban nem lesz xen kernel az ilyen hasonló téves cikkek miatt azt hittem, hogy buktam a paravirtualizált RHEL6 guest-eket xen hypervisoron. :(
Nemrég világosodtam fel, hogy a DomU rész már a 2.6.24-óta benne van a mainline kernelben ( és redhat beleforgatja az RHEL6-os kernelébe a szükséges kódot).

Javítsatok ki ha tévedek, de mintha a Redhat segítségével is próbálták volna beolvasztani a fejlesztők (sokkal kisebb sikerrel), vagy nem?

Arra nem emlekszem, hogy a red hat be akarta olvasztatni a kernelbe, de az biztos, hogy domU tamogatast most is ad a piroskalap.

Egyebkent en nagyon orulok a beolvasztasnak, amit a citrix muvelt a xen technologiaval, az kicsit olyan volt, mintha nem is akartak volna igazan hasznalni.

--
Aki falra szerelt tehennel vitatkozik, olyan mint vonat kerek nelkul, nem jut sehova.

Azt tudtam, hogy DomU tamogatas megmaradt, csak azt nem tudtam, hogy paravirt-tel is es valjuk be anelkul nem sokat erne az a DomU tamogatas :)

Idokozben utanaolvasgattam, mar tobbszor megprobaltak beolvasztani az "egesz" kodot, de nagyon sokszor visszapattantak "tul sok valtoztatas", "nem megfelelo a kod minosege" mondatokkal.