Vlákno názorů k článku
Jádro 2.6.25 nabídne vylepšený KVM od micaai - Moc nevím, o co jde, ale zajímalo by...

Já měl vždy za to, že KVM je alternativa ke Xenu. Ale k čemu je Xen pro běžného uživatele fakt nevím. Já se za něj považuju (ne za Xen) Xen se mi nepodařilo rozjet (skončil jsem u Virtualbox).

Všiml sis, že VMWare je o dost rychlejší než QEMU? Tak za to může to, co se snaží KVM implementovat.

Zjednodusene receno KVM vyuziva jednu funkcionalitu novych Intel/AMD procaku ktera umoznuje spoustet hostovany system na cca 80% nativniho vykonu. Tzn Wokenice ti pojedou rychleji.

Strucne receno - na x86 nelze rozumne odchytavat nektere privilegovane instrukce a tedy nelze rozumne virtualizovat. To se ruzne obchazelo - xen (paravirtualizace) predpoklada modifikovany kod, ktery tyto problematicke instrukce nepouziva (a misto nich primo vola Xenu), vmware za behu prochazelo kod a tyto instrukce detekovalo a nahrazovalo (coz je mene efektivni, nez kdyz je mozne je proste odchytavat). Nove moznosti procesoru umozni tyto instrukce primo odchytavat.

Podpora virtualizace v jadre pak umoznuje vyuzit tuto novou vlastnost CPU stylem, ze virtualozovany kod (kod napsany pro beh v ringu 0 - privilegovanem rezimu CPU) bude bezet v ramci Linuxu jako proces a kdyz se bude snazit delat privilegovanou operaci, odchyti ji podpurny proces.

KVM ulehčuje (lépe řečeno zrychluje) práci QEMU (jiný program s ním zatím nekomunikuje), protože všechen kód nevyžadující privilegované aplikace (např. komunikaci s HW) se nemusí emulovat (to samé má VMWare zabudované v sobě, ale ten není open source). Tuto technologii zvanou hypervisor (též Intel-VT nebo AMD-V) podporují jen novější procesory. KVM také začíná podporovat paravirtualizaci, kdy je ale potřeba spolupráce hostovaného OS (ne celého, jen ovladačů pro ten který HW), např. pro společný přístup k síťové kartě (tedy aby oba systémy měly stejnou IP adresu) nebo podporu Drag'n'Drop mezi oběma systémy.

Xen je implementace paravirtualizace, tam druhé OS musí být pro Xen upraveno (místo přímého přístupu k HW používá speciální API hostitelského jádra). Výhoda KVM je ta, že systém v něm běžící o emulaci vůbec neví, takže tam lze spouštět cokoliv (např. Microsoft Windows v Xenu nejedou). Výhoda Xen je, že funguje všude (i na starších systémech) a je rychlejší.

Pro běžného uživatele to může mít ten přínos, že místo dual-bootu má dva systémy, které běží najednou. Pro programátory to má neocenitelný přínos (např. může testovat chování své aplikace ve Windows, ale přitom vyvíjet v Linuxu).

A neslo by naopak virtualizovany system zpomalovat? Programatori to potrebuji jak sul. Bez poradne zpomaleneho systemu jsou schopni plodit sebetrivialnejsi aplikace vyzadujici osmiprocesorovy system.

Já programuji na Pentiu 200, takže to mám už zpomalené dost. Mimochodem, cache na zformátované dokumenty v Linksu jsem vymyslel, když jsem ho nějakou dobu používal na 486. Výhoda pomalého počítače se zde projevila.

1. Neříkal bych té technologii hypervisor, protože hypervisor je obecně dohled jednoho systému nad druhým. UML je taky hypervisor.

2. Spolupráce ovladačů HW (obecných) potřeba není. Je potřeba spolupráce stran správy paměti a přístupu k zařízením. UML není úplně dobrý příklad, protože nemá úplně oddělenou paměť, ale hostované jádro poskytuje systému nějaké zařízení, které vypadá jako disk (ubd), případně emuluje síťové zařízení, které bývá obvykle připojeno k tun/tap zařízení.

3. Nechápu smysl toho, aby dva systémy, které se mají tvářit odděleně, měly stejnou IP adresu. Nějak ani nedokážu pochytat, jak by to vůbec fungovalo.

4. Xen docela dlouhou dobu podporuje podporuje HW virtualizaci. Tudíž hostovaný systém o virtualizaci rovněž nemá páru. Paravirtualizace je na něm rychlá, ale třeba emulace zařízení, aby Windows vůbec běžely je docela porod. Používá na to části QEMU, stejně jako KVM, takže nějaký ultra speedup bych nečekal.

5. Není tak úplně pravda, že by běžely oba systémy rovnocenně. Obvykle není hypervisor zatěžován žádnými aplikacemi a vše se řeší v hostovaných systémech. Aby to mohlo aspoň nějak fungovat, může mít jeden z virtuálních systémů dedikované zařízení, jako třeba grafickou kartu. Nemám dojem, že je zvládnutý context switch mezi systémy, aby si třeba zrovna tu grafickou kartu předaly.

Já používám na serverech UML a Xen (s HW i paravirtualizací). Pro běžného uživatele je to podle mě stejně pořád slabota, protože to nejsou dva rovnocenné systémy, mezi kterými lze libovolně přepínat. Představa, že mám Linux a pak hupnu do Windows a zapařím Crysis, je podle mě pořád daleko.

No pozor. Neprivilegovany kod bezi nativne uz davno. Problem je s privilegovanym kodem a prave ten resi HW virtualizace. Ackoliv ne uplne efektivne. Viz technologie "nested pages" a "IOMMU". BTW, vi nekdo jak je daleko KVM v techto ohledech?

Jinak bezny uzivatel zatim o techto vecech nema ani paru. To je duvod proc na "features" listu jakehokoliv moderniho procesoru najdete tak maximalne neco ve stylu "run multiple tasks faster" (coz je technologie multicore) a "anti virus protection" (coz je NX). Jen nekde dole pod carou malym pismem je napsano "taky umi virtualizaci" a to ji jeste nektere BIOSy vypinaji.

Neprivilegovaný kód nemůže běžet nativně kvůli několika málo instrukcím, které jsou neprivilegované, ale vracejí stav protected módu --- SGDT, SIDT a podobné. VmWare to řešilo částěčně tak, že někdy bylo schopno ty GDT a IDT tabulky nastavit na stejné adresy jako v guest systému, takže tyto instrukce vracely správné hodnoty. V jiných případech to VmWare neřešilo, takže např. SIDT vracela nesmysly, a prostě se předpokládalo, že uživatelský kód v guest systému tu instrukci nezavolá.

presneji vsechny athlony64 x2 a novejsi ....