Red Hat se zaměří na virtualizaci přes KVM (diskuse)

[thingie]

To je zřejmě krajně rozumné rozhodnutí

[alblaho]

Může sem někdo napsat, jaké jsou výhody KVM oproti XENu? Ubuntu taky razí KVM. Proč?

[Nikola Ciprich]

xen je des rozlezly po celem jadre, vyvoj probiha nad starymi kernely (naposled co jsem se na to dival to bylo snad 2.6.18), a navic byl koupen Citrixem coz spouste lidi taky moc na klidu neprida...

oproti tomu KVM staci prelozit jako modul, funguje na cele rade kernelu, lepe se ladi a hlavne firmu qumranet ktera KVM vyviji koupil redhat, takze je celkem zaruka ze vyvoj zustane otevreny...

[Nikola Ciprich]

na druhou stranu je treba uznat ze co se tyce vykonu, nema KVM oproti PARAVIRTUALIZOVANEMU linuxu pod XENem moc sanci, ale porad se to zlepsuje. HVM XENy vychazi ve srovnani s KVM +- stejne...

[trekker.dk]

nema KVM oproti PARAVIRTUALIZOVANEMU linuxu pod XENem moc sanci, ale porad se to zlepsuje

V jakém ohledu? (I/O operace/výpočetní výkon/...)

[skupko]

Skoro by som sa odvazil tvrdit, ze vo vsetkych, ale neodvazim sa...

[Nikola Ciprich]

no celkem velka penalizace ohledne cisteho procesoroveho vykonu... ani I/O vykon neni zatim nijak uchvatny, ale to je asi problem i XENu (pouzivaji velkou cast shodnych ovladacu) ale jak rikam, vse se zlepsuje - optimalizace pro paravirtualizovany beh linuxu pod KVM (nema zatim takovy vliv jako u XENu, ale kazde procento se pocita, bohuzel to zatim neni bez problemu), virtio ovladace (tam je "prinos" dost sporny, zatim to je spis pomalejsi nez emulace realnych zarizeni, ale pocitam ze to je jen docasne), a take pribyvaji dalsi moznosti v procesorech ktere muzou prinest taky vyrazne snizeni vykonove penalizace u virt. systemu...

nemam bohuzel rozumne nova mereni jak je na tom ted XEN (a po letech trapeni s XENem se mi do toho uz vubec nechce), ale KVM se rozhodne zlepsuje...

[trekker.dk]

no celkem velka penalizace ohledne cisteho procesoroveho vykonu...

No já nevim - pokud můžeme openssl speed brát jako měřítko čistého procesorového výkonu, tak tam moc velká penalizace není:

openssl speed rsa1024& openssl speed rsa1024& (2 jádra, 2 procesy naráz)

Hostitel:
rsa 1024 bits 0.001104s 0.000048s    905.7  20716.5
rsa 1024 bits 0.001083s 0.000047s    923.3  21251.1

1 host:
rsa 1024 bits 0.001192s 0.000052s    838.7  19317.3
rsa 1024 bits 0.001130s 0.000049s    884.6  20373.1

2 hosti:
rsa 1024 bits 0.001323s 0.000057s    755.8  17450.6
rsa 1024 bits 0.001331s 0.000058s    751.6  17323.6
rsa 1024 bits 0.001428s 0.000066s    700.5  15135.2
rsa 1024 bits 0.001437s 0.000066s    696.0  15178.3

4 hosti:
rsa 1024 bits 0.001501s 0.000064s    666.1  15548.4
rsa 1024 bits 0.001511s 0.000066s    661.8  15120.9
rsa 1024 bits 0.001570s 0.000071s    636.8  14041.9
rsa 1024 bits 0.001603s 0.000072s    623.8  13926.3
rsa 1024 bits 0.001576s 0.000072s    634.6  13807.8
rsa 1024 bits 0.001490s 0.000065s    671.2  15311.2
rsa 1024 bits 0.001503s 0.000068s    665.2  14655.5
rsa 1024 bits 0.001556s 0.000067s    642.8  14925.8

ani I/O vykon neni zatim nijak uchvatny, ale to je asi problem i XENu (pouzivaji velkou cast shodnych ovladacu)

V nějakých slidech o Xenu (ale jsou půl roku staré, tudíž to nemusí platit) KVM porazil Xen v testech s intenzivním I/O. Na druhou stranu v té době KVM mělo docela problémy při paralelním běhu několika hostů.

Ty slidy (v ne-slidové podobě) jsou např. tady

virtio ovladace (tam je "prinos" dost sporny, zatim to je spis pomalejsi nez emulace realnych zarizeni, ale pocitam ze to je jen docasne)

Taky jsem testoval a přínos virtio ovladačů je někde docela znát - emulovaný 100Mbit Realtek měl propustnost nějakých 896kB/s. Virtio síťovka 95MB/s. U disků to bylo přibližně nastejno, víc záleželo na tom, na čem je uložen obraz.

[linuxnew]

Jedna z opravdovych nevyhod XENu jen co je pravdu, stara jadra jak pisete 2.6.18, i RedHat dava od toho ruce pryc a to je co rict, ze se mu nechce patchovat nova jadra xenem. Ale co jsem cetl, tak by mohlo dojit k zacleneni !celeho! XENu ve 2.6.30 ci 31, nevite co je na tom nekdo pravdy?

[Nikola Ciprich]

no na zacleneni se asi stale pracuje (domU cast uz v kernelu davno je), i kdyz nevim kdo. mozna jeste stale i lide z redhatu. osobne mi to mozna prijde uz byt i zbytecne, protoze jak rikam, je to spousta kodu rozlezleho vsude mozne a vypada to ze se vetsina velkych hracu da spise cestou KVM...

[skupko]

Na margo kupy organizacie XenSource Inc. Citrixom - ano, nepridava to na pokoji a dovere k tejto technologii, hocako je dobra.
Podla mojich informacii spolocnost Citrix tuto virtualizacnu technologiu portovala na Windows - vsetky technologie a baliky Xen*, ktore predava su verzie pre Windows.
Citrix vsak ponechala zdrojove kody technologie Xen komunite OpenSource. Tieto zdrojove kody su vsak vyvijane mimo vetvy Citrixu...cize je otazne kolko spolocnost Citrix dava komunite OpenSource...

[Shadow]

Podporu KVM samozřejmě vítám, ale pokud RH Xen zahodí úplně, a že to podle článku tak vypadá, bude to škoda. Xen používám na slabších strojích, které jsou jednak pomalejší (tudíž paravirtualizace je pro ně jediným rozumným řešením) a jednak na nich chybí HW podpora virtualizace, takže KVM na nich AFAIK ani teoreticky pustit nejde. Některé z těchto strojů jsou sice starší a brzy je vyřadím, ale jiné jsou velmi čerstvé (malé mašinky s AMD Geode a mizivým odběrem) a virtualizaci bych na nich časem mohl chtít spáchat.

[thingie]

Je to RHEL, takže stará řešení by měla být podporována tuším dost dlouho, aby se ty stroje do té doby stačily proměnit v kousky nejenom povětšinou muzejní, ale zejména i už nefunkční, ni?

[Marek 'marx' Grác]

Podpora v 5.4 nemože byť viac nech tech-preview - takže v RHEL5 sa to nikto na nič seriózne nerozhodne použiť, tak ďalší rok až dva. Xen tu bude ešte dlho.

[thingie]

No, bohužel jo. :o)

[..... Izak .....]

No RH ve faq tvrdi, ze Xen bude podporovat soubezne, alespon v te podobe, jako doted.