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

 ( trey | 2011. május 29., vasárnap - 8:39 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

vidám subscribe

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

+1.

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.

lakossági virtualizálás :))

ti. bubuntu alatt a winxp

--
NetBSD - Simplicity is prerequisite for reliability

kispolgari :)
5 perce ezen vigyorgok...

közmunkaprogram keretében VM-be települ a sok OS


"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

Windows 7-ben az XP mód, amit a Windows fanboyok kompatibilitás-mantrázása ellenére kénytelenek voltak beletenni a Windows-ba.

--
trey @ gépház

ez lakossági?
'Designed primarily with small- and medium-sized businesses in mind'


"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

Ne zavarjon meg a "primarily" szó. Nem kizárólag oda való.

--
trey @ gépház

jó, nyilván minden vállalati felhasználásra szánt programot fel lehet tenni home computerre is :-)


"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

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!

Több scenario-t is láttam már, ahol kellett.

--
trey @ gépház

és hogy jön egymáshoz a Windows 7 XP mód és a Linux KVM, amiről szó volt, mint "lakossági virtualizálás"?

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.

Te nagyon okos vagy. Lakossagi virtualizalas nah arra jo a KVM semmi masra.XEN,ESX kepesseighez kepest sehol sincs.
--
1 leszel vagy 0 élő vagy hulla!

Az mar nagyon regen volt (ertsd evekkel ezelott), amikor ilyet ki lehetett jelenteni, hogy sehol sincs a Xen, ESX-hez kepest.

?
--
1 leszel vagy 0 élő vagy hulla!

A magasroptu beszelgetesetekbol szeretnek kimaradni, az viszont erdekelne, hogy mit hasznalsz a qcow2 helyett?

tompos

Ha teljesítmény kell, akkor raw lvm. A libvirtd/virt-manager jól kezeli ha kap egy VG-t, nem kell hozzá parancssorban bűvészkedni.

Ebben az esetben viszont dedikalt storage-on van az lvm, nem?
Vagy hogy mozgatod a gepek kozott a VM-eket?

tompos

Igen. Nem hiszek abban, hogy NFS-en normális VM IO teljesítmény érhető el, legyen azon bármilyen container. Inkább már DRBD primary-primary vagy bármi más, csak blokk szintű legyen.

Egy elet biztositas lehet az a rendszer ami DRBD-n megy. 2 NODE-al. Ezek mellet meg primary-primary is.
--
1 leszel vagy 0 élő vagy hulla!

Azert ez sok esetben nem jarhato ut szerintem.

Az teny viszont, h meg sehol nem lattam image alapu VM-ek osszehasinlitasat sem teljesitmeny, sem funkcionalitas szempontjabol.

tompos

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". :)

"Igen na most a KVMnek az I/O teljesitmenye a beka segge alatt van kettovel."

Ezt majd magyarazd el a ra epito IaaS providereknek is. :)

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

milyen nagy IaaS providerek építenek KVMre? szó volt arról, hogy EC2nél bevezetik, de aztán maradtak a Xennél.

Dell, IBM, The Planet, elastichosts, ...

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Tesztelted az RHEV-M-et? Tapasztalatok?

a Xen egyáltalán nincs lemaradva a vSpherehez képest. az Amazon EC2 talán elég jó referencia.

"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.