Moc nevím, o co jde, ale zajímalo by mě, k čemu je ta virtualizace dobrá pro běžného uživatele. Umožní to nějak implicitně spouštět systém v systému bez potřeby softwaru jako je Xen, vmware...? Nebo to práci těmto programům ulehčuje? Nebo je to úplně o něčem jiném?
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).
Nevím sice, co myslíš "běžným uživatelem", ale použití si dokážu představit.
- Programátoři si otestuji, jak jejich program běží pod jinými OS.
- Programátoři si otestuji, jak jejich program instalovat na stejném OS, ale tzv. "instalaci na čistý počítač". Je to jednodušší obnovit virtuální stroj než přeinstalovávat pokaždé OS na harddisku.
- Spuštění nativní aplikace pro jiný OS bez nutnosti restartu.
- Zájem o vývojové verze jádra nebo vývojové distra, bez nutnosti instalace.
Já znám použití virtualizace (sám používám třeba vmware), ale nevím, co přesně dělá ta podpora virtualizace v jádře, čím to samotnou virtualizaci má ulehčit apod.
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á.
Normálně, nikdo SIDT nevolá, tak funguje. Vím, že na VmWare nějaký rootkit způsoboval pád celého systému, protože SIDT volal, aby nalezl a patchnul tabulku syscallů.
BTW. možná si pleteš LIDT a SIDT. LIDT --- nastavení adresy/velikosti tabulky přerušení --- je privilegovaná instrukce, takže ji jde normálně emulovat. SIDT --- získání adresy/velikosti tabulky přerušení --- neprivilegovaná instrukce, kernel to nepotřebuje (ví, kde ji nastavil), userspace to taky nepotřebuje, protože mu po tom nic není, kde ta tabulka je (vyjma toho rootkitu :)
Mam obavy, ze v XEN ide spustat aj MS Windows, je na to ale treba komercnu verziu XEN Enterprise a procesor s podporou virtualizacie (uz spomenuty Intel-VT a AMD Pacifica, co su vsetky XEON 5xxx a Opteron 2xxx).