Proč je virtual HW hloupost, proč uspěje a co to znamená (diskuse)

[Mikos]

Tedy už jen nadpis vašeho blogpostu "Proč je virtual HW hloupost, proč uspěje a co to znamená" je tak neuvěřitelně flame-vyvolávající, že snad nemá ani cenu to komentovat. Jako byste říkal "já mam patent na pravdu".

Podle mě např. virtualizace ala Xen s HW podporou procesoru je velmi dobrá věc, která má slibnou budoucnost.

[Mikos]

Stejně tak to, že si výrobci x86 CPU tak trochu "vynutili" příchod 64-bit procesorů je jen a jen dobře a jsem strašně moc rád, že se to stalo. To samé mohu říct o vícejádrových procesorech a vektorizaci (kterou mají na svědomí právě ty vaše multimediální instrukce jako SSE2).

[Veronika]

64 bitů si nevynutili výrobci, vyžádali si je zákazníci. Na 32 bitech je maximální velikost jednoho procesu 2GB, což už je silně limitující faktor. Xeony měly sice 36bitů na adresaci, ale pořád jenom 2GB na proces. Připomíná mi to omezení 8086 na 1MB RAM (a to ještě těžko použitelný) nebo 80286 a 16MB - lidi chtějí prostě víc.

Já tady třeba mám MSSQL a stroj s 2.5GB paměti; za pár korun by ta paměť šla rozšířit. Kdyby ji to SQL využilo, tak se to hodně projeví na výkonu, ale prostě to nejde, potřebujeme 64bit server a systém.

[zde]

Tak používej Linux, ten umí i na 32-bit strojích využít 64GB paměti. Kernel to sice nedá procesu, který by to ani neuměl adresovat, takže to poslouží jen jako disková cache, navíc se bude šaškovat s bounce bufferama, ale DB aplikaci by to zrychlit mohlo.

Já vidím přínos 64 bitů nikoliv v přímé podpoře velké fyzické RAM, ale spíš v tom že projdou mmap()y opravdu velkých souborů, což bude velmi užitečné pro jednoduché extrémně výkonné objektové databáze.

[Veronika]

Myslím, že si pleteš virtuální a fyzickou paměť. 32bit procesor má 32bit adresovou sběrnici a tak si do fyzické paměti může sahat na pro byte na adrese 0 až 2^32. Jak se to mapuje přes výpadky stránek atd. je věc druhá, ale fyzické uspořádání paměti je vždycky jenom jedno. Xeon (teda ty starší, novější už jsou 64bit) má 36bit sběrnici (v dalším módu) a umí teda přímo (fyzicky) adresovat 4x víc paměti*, ale to se jaksi moc neujalo a navíc je to posunutí hranice jenom o kousek. Taky je tady pořád limit na 2GB pro jeden proces a práve databáze většinou jeden proces je. Ano, dá se napsat multiprocesová databáze, ale to už je obcházení problému.

Ad*: Ještě to musí umět chipset, teda vlastně paměťový řadič, takkže u Xeonu bylo AFAIK možných jenom 12GB, ale to už si vůbec nejsem jistá.

[zde]

Uff, já tvrdil že proces dostane 64GB? Psal jsem že Linux tu paměť využije jako buffery, což zrychlí IO toho DB procesu. Samozřejmě že jen na stroji který umí PAE a externě adresuje 36bit.

Jo a 2GB je limit Windows, Linux má obvykle 3+1 split, takže 3GB na virtuální adresaci pro proces a 1GB fyzické paměti pro kernel, vše v jedné tabulce aby se při syscallu nemusel přepínat CR0. Případně 4+4 s přepínáním, pak se využije i 4GB fyzické paměti, ale syscally se dost zpomalí. Taky 4 bity navíc nejsou 4x ale 16x víc paměti.

[Veronika]

Uff, já tvrdil že proces dostane 64GB? Psal jsem že Linux tu paměť využije jako buffery, což zrychlí IO toho DB procesu. Samozřejmě že jen na stroji který umí PAE a externě adresuje 36bit.

A není pak opravdu lepší a jednodušší jet přímo v 64bitovém režimu?

Taky 4 bity navíc nejsou 4x ale 16x víc paměti.

Samozřejmě máš pravdu, kupecké počty mi nikdy moc nešly. :)

[zde]

Ano, je to lepší. Ale na skutečné 64-bit architektuře, tj cokoliv krom AMD64.

[Spike]

To "krom AMD64" bych chtěl vysvětlit.

[Michal Kubeček]

Co na tom chcete vysvětlovat? Prostě klasický snobácký FUD… :-(

[zde]

Omluva- AMD64 sice skutečně JE 64 bitová architektura, ale je příliš šílená. Příliš krátký opcode (jen 8 bitů), příliš velký počet módů, příliš komplikovaný instrukční soubor s příliš mnoha výjimkami a příliš mnoha prefixy. Architektura x86 fungovala dobře na osmbibitech a pseudo-16-bitech, 286-kový protected mód byl omyl a 32-bit režim od i386+ byl ohnutím na hranici možností.

To že to jakžtakž funguje je pouze díky tomu že moderní procesory v podstatě stejně dělají dynamickou kompilaci, takže dekódované instrukce se nějak cachují- ale to má svou cenu: komplikovaný dekodér, problém se správou té cache (invalidace při selfmod), atd.

Jinak problémy se "sémantikou" AMD64 nemám- 16 registrů je tak akorát, a rozumnou pc-relativní adresaci už sdílené knihovny potřebují dosti zoufale. Problém mám mouze s tou "syntaxí" nových instrukcí..

AMD měla radši udělat kompletně nový CPU core, který by byl pinově kompatibilní s Athlonem, k tomu vlastní bios na přeflashnutí pro pár populárních motherboardů, a zasponzorovat přeportování nějaké distribuce na tuto platformu.

[Mikos]

Vy jste koukam mistr FUDu

[zde]

Proč je virtualizace hloupost: protože mít správu zdrojů ve dvou vrstvách (hypervisor + N*kernel) je vždy méně efektivní než to udělat přímo. Nabízí se analogie s threadovým modelem 1:1 vs 1:N (thready v userspacu).

Proč uspěje: Protože efektivně řeší aktuální problémy.

Co to znamená: Že jiná, koncepčně lepší řešení, jsou implementována na hranici použitelnosti.

Patent na pravdu nemám, a po seznámení s fakty docela ochotně měním názory.

[Mikos]

A napadlo vás třeba využití virtualizace k souběžnému provozu zcela jiného OS? K takové věci je virtualizace velmi užitečná, spousta lidí jí k tomu využívá (viz. VMWare, Qemu + kqemu, atd.). Pokud pro to bude přímo podpora v CPU a zlepší se tak výrazně výkon virtualizace (tak že se nebude v praxi moc lišit od nativního běhu), je to jen a jen dobře.

Samozřejmě si uvědomuju že tohle je jen jedno z noha využití virtualizace a že pro jiné případy mohou být jiné metody vhodnější, nicméně čistá vďrtualizace s podporou v HW tu opravdu _má_ své místo.

[zde]

Když budu spokojený se stávajícím OS, nebudu potřebovat jiný, natož pak souběžně. Výjimkou je vývoj nízkoúrovňového software pro embedded hardware, tam přirozeně jiný OS bude. Ovšem pak máte téměř jistě jinou ISA, takže virtualizace stejně nestačí, a nemá smysl ji akcelerovat.

[Mikos]

Jenže jsou lidé, kteří bohužel musí (i když by třeba nechtěli) pracovat i se softwarem, který je pouze pro jiný OS, protože je k tomu nutí např. zaměstnavatel a daný software nemá pod Linuxem kompatibilní ekvivalent. Naštěstí můj případ to není Nicméně znám pár takových...

Sice v takovém případě pomůže např. VMWare nebo Qemu + kqemu, ale pořád je ta virtualizace oproti nativnímu řešení pomalá (nejvíce se to projeví pokud daný program třeba využívá 3D grafiku, to je pak tragedie). V takovém případě by se HW podpora virtualizace rozhodně hodila.

Ale toto stejně není jediný případ, těch případů kdy se skutečná virtualizace hodí je mnohem víc...

[kavol]

Jenže jsou lidé, kteří bohužel musí (i když by třeba nechtěli) pracovat i se softwarem, který je pouze pro jiný OS, protože je k tomu nutí např. zaměstnavatel a daný software nemá pod Linuxem kompatibilní ekvivalent.

viz - obcházení problému ...

[Michal Kubeček]

Celkem běžně používám VMware v situaci, kdy host i guest je Linux, nezřídka i stejná distribuce ve stejné verzi. O možnosti testovat windowsové klienty bez nutnosti bootovat do Windows ani nemluvím.

[zde]

No, já windowsové klienty testuju tak, že mám pod stolem další krabici s Win2k na nějakém celeron@466, a v Linouchu na ně pouštím xvncviewer, přijde mi to jednodušší. A hlavně se nepřetahujou o disk a paměť..

[Jiří (BoodOk) Kadeřávek]

Ja napr. testuji ve 4 prostredich, to si jako poridim 4 krabice? Nebo do racku zbytecne narvu 5 serveru, protoze chci oddelit role, protoze na jednom serveru jsou NTcka, protoze na jednom je Woody a na druhem Sarge atd. Zaplatim za to cele 5-10x tolik, 5-10x casteji budu resit HW problemy, budu mit 4-nasobne naklady na klimatizaci. Neporidim, budu virtualizovat, protoze mi to umoznuje setrit zdroje a byt nezavisly na HW. Chovam se tak navic ekologicky a mam v kanclu ticho. Dekuji vyvojarum za takovou BLBOST, jakou je virtualizace.  

Muzu se zeptat? To jen tak teoretizujete, nebo opakovane situace, ktere lze vyresit virtualizaci resite setupem a provozem dalsi masiny? A nebo proste mate pod stolem jedny Windows a tim jste s potrebou/nepotrebou virtualizace skoncil?

[zde]

Jo, to poslední je správně. Potřebuju ty windowsy jako loader pro MSIE, když dělám změny na interním webu (plone). Ta krabice je HP Brio, má 100W zdroj, pasiv na CPU, a počítám že bere tak 40W, zhruba stejně jako halogenová lampička, co mám na stole. Jo a kdyby se to PC dalo do bazaru, dostanu za to max. 2.000,- coz je myslim zhruba polovina ceny VMWare.

Ale o tom to neni, podivejte jestli jste precetl zapis na blogu cely, pochopil jste ze rozhodne nepopiram ze V SOUCASNE SITUACI je virtualizace hardwaru uzitecna, dokonce predpokladam jeji siroke nasazeni!!! Jenom tvrdim ze NEPOPIRATELNE resi problemy, ktere mel uz davno predtim vyresit nekdo jiny, ale trestuhodne selhal.

[martink]

Doporučuji googlit pojmy jako "virtual machine migration", "workload balancing", "clustering" a "single point of failure". Pak vám to možná docvakne...

[zde]

virtual machine migration: užitečná věc, ovšem OS které umějí migrovat procesy tu jsou už hezky dlouho, na to nepotřebujete virtualizovat tak nízko a duplikovat kernely.

workload balancing & clustering: Balancing nevyžaduje nízkoúrovňovou virtualizaci (leda jako berličku kdyby OS neuměl migrovat procesy, ale to se opakujete), clustering už vůbec ne.

single point of failure: Tím zůstává železo, ne?

[martink]

Nejde o migraci procesů, ale celých virtuálních strojů. Dojde např. k hardwarové chybě a celý virtuální stroj se během pár stovek milisekund "přemigruje" na úplně jiný host. Výpadek nulový.

Představte si nějaký HA cluster s mnoha virtuálními stroji, kde si zákazník může spouštět služby jaké chce; může si řešit třeba firewall jak chce; může vkládat vlastní moduly do jádra (chce třeba použít SELinux, šifrovaný filesystem, nějakou featuru LSM,...), přičemž případná kompromitace jeho kernelu neovlivní ostatní virtuální stroje; dokonce může použít OS jaký potřebuje atd. Všechno je zároveň imunní vůči hardwarovým chybám, je možné vyrovnávat workload (některé virtuální stroje se prostě přemigrují na jiný host), takže všechny zákazníkovy služby jsou pořád dobře dostupné...

Doporučuji přečíst třeba http://www.cl.cam.ac.uk/Research/SRG/netos/papers/2005-migration-nsdi-pre.pdf

[zde]

V podstatě souhlas, jen ten argument kde uvažujete o možnosti kompromitace jádra mi v podstatě dává za pravdu, že jde o druhotné, náhradní řešení, díky tomu že něčemu co má být pevné jak žula (jádro) se nedá věřit ergo to není dostatečně kvalitní.

Na hypervisoru mi vadí, že bude hodně neefektivní- určitě bude nejen suboptimální plánovač, ale hlavně žádné sdílení RO nebo COW stránek přes hranice virtuálních strojů (netuším jak by to šlo implementovat- hypervisor neví nic o implementaci VM subsystémů v OS, které hostuje).

NAvíc se bojím že rozdělení fyzické paměti mezi jednotlivé stroje bude muset být statické, z čehož plyne jejich omezený počet.. prostě je to hloupost, slušný kernel to samé bude dělat 100x líp..

[martink]

Na hypervisoru mi vadí, že bude hodně neefektivní

Tenhle benchmark je už docela starý, takže aktuální výsledky budou nejspíš ještě lepší (minimálně pro Xen).

Určité sdílení paměti mezi stejnými OS možné je. VMware to tak dělá, takže předpokládám, že Xen to taky umí. Detaily neznám. Viz http://news.com.com/Next-gen+VMware+software+to+get+memory+boost/2100-1016_3-5500084.html?tag=bplst

Pokud někdo úplnou virtualizaci nepotřebuje, nic mu nebrání použít třeba FreeBSD Jail, Linux-vserver nebo Solaris zones.

"[...] jde o druhotné, náhradní řešení, díky tomu že něčemu co má být pevné jak žula (jádro) se nedá věřit [...]"

Bezchybný software bohužel neexistuje, a to platí i o kernelech. Musí se vycházet z reality, ne z nějakého ideálu jak by to mělo fungovat. Bohužel.

[wake]

Bezchybný software bohužel neexistuje, a to platí i o kernelech...:... hypervisorech a tabulkách FDIV v matematických koprocesorech.

[Jiří (BoodOk) Kadeřávek]

Kdyby slo jen o chybovost SW, nebo chybnost jeho navrhu, ta je az na druhem miste. Prvni v rade je skutecnost, ze virtualizace dokaze jakztakz vyresit problem s naprosto protichudnymi naroky. Tady nejde o to, jestli existuje idealni kernel, jde o to, zda z hlediska matematiky muze existovat vseresici kernel. A zde, ac nejsem matematik, se obavam, ze nemuze, ze spolecny jmenovatel, ktery splnuje predstavu idealniho SW se zde limitne blizi nule. Virtualizace je odpovedi na realne problemy, stejne jako jadro je odpovedi na realne problemy. A nase prace je o nachazeni reseni realnych problemu. Hloubani nad otazkou zivota, vesmiru a vubec ponechme matematikum a filosofum.

[wake]

Me se virtualni stroje libi, sam jeden (obcas) pouzivam. Ale nevim proc nekoho nechat je podporovat scestnou argumentaci.

[zde]

No, já se pokorně přiznávám že si hraju s vlastním (zcela zbytečným) bootloaderem, a ladím to pod QEMU.

[Jiří (BoodOk) Kadeřávek]

Jaka scestna argumentace proboha. Kdyz chci, abych mel neco v bile i v cerne, pak musim to neco mit bud ve dvou variantach, a nebo to neco zbavit vlastnosti barva (potom nemohu chtit, aby to barvu melo). A o tom to je.

_NEEXISTUJE_ a ani teoreticky _NEMUZE_ existovat univerzalni jadro OS, ktere by splnilo vsechny protichudne pozadavky. Pokud si myslite, ze tohle je scestnost, pak Vam doporucuji vykaslat se na tento flame a pustit se do programovani dokonaleho jadra. Proc na tom jeste nepracujete?

[zde]

Chyba je už v tom požadavku na dvě barvy. Nemá smysl. Protože se jedná o interní API mezi aplikací a OS, není pro uživatele zvenku vidět. Vy chcete kuličku, o kterých panuje konsensus že zvenku vypadají stejně a nikdy se nebuvou rozřezávat, která bude uvnitř černá i bílá. Takovýto požadavek nemá smysl, ledaže připustíme že kuličky nejsou tím čím mají být.

[Jiří (BoodOk) Kadeřávek]

Kdyz chcete bilou a cernou kulicku, musite my dve kulicky. Kdyz chcete mit monoliticke jadro a mikrokernel, musite mit jadra dve, chcete-li mit realtime jadro a jadro zvladajici nadmernou zatez, potrebujete jadra dve. Kdyz chcete mit off-road a mestske vozitko, musite si koupit dve auta. Zkuste pochopit, co se Vam snazim vysvetlit.

[zde]

Kdo chce mikrokernel? Proc jej nemuze nahradit monoliticky kernel? Proc by realtime jadro nemelo zvladat nadmernou zatez? Kazda aplikace pozaduje jiny feature set, ale jejich prunik je hrube nadpolovicni, a zcela zjevne existuje reseni ktere je pokryje vsechny. Takze proc zbytecne duplikovat to co maji spolecneho?

Navic realtime jadro byl obzvlast blby priklad, protoze si neprejte vedet co udela virtualizace hardwaru s latencema interruptu, vystihuje to jedno velmi sproste slovo.

[Jiří (BoodOk) Kadeřávek]

Kazda aplikace pozaduje jiny feature set, ale jejich prunik je hrube nadpolovicni, a zcela zjevne existuje reseni ktere je pokryje vsechny.

A v tom se IMO milite. Tvrdite svou vetou, ze soubor vsech feature setu je konecny a vypocitatelny. Jedine za takove podminky muzete tvrdit, ze jejich prunik je hrube nadpolovicni. Pro upresneni, aplikaci zde neuvazuji SW aplikaci, ale realnou aplikaci (nasazeni) jadra. Proste, vy tvrdite, ze staci jedno jadro pro vsechny pripady, ja tvrdim, ze nikoliv, ani teoreticky.

[zde]

Kdyz nebude konecny, virtualizace vam stejne nepomuze.

Jedno jadro pro vsechny pripady je rozhodne lepsi reseni nez jeden hypervisor pro vsechny operacni systemy.

[zde]

Jasně, takže za dalších 15 let tu máme další HYPE s názvem ULTRAVISOR, a vývojáři budou slintat blahem, jak se jim pod tím krásně současně spouští několik navzájem nekompatibilních, zabugovaných, a děravých hypervisorů. :) :) :)

Proboha vždyť pokročilá demence z tohoto přístupu přímo odkapává. Kdyby se úsilí, vynakládané na takovéto sračky vložilo do odladění a unifikace kernelu, budem hotoví za 1/10 času.

Opět se potvrzuje staré ajťácké přísloví: Nikdy není dost času to udělat pořádně, ale vždy je dost času udělat to znovu., případně oblíbené Každý IT problém lze vyřešit přidáním další vrstvy abstrakce, s výjimkou problému se správou příliš mnoha vrstev..

[Jiří (BoodOk) Kadeřávek]

Vy si snad skutecne myslite, ze muze existovat JEDEN JEDINY PORADNY kernel? Nejsou na ruzna jadra ruzne pozadavky? A od kdy by mel tento SUPER-TRUPER kernel existovat, aby nemusel byt verzovan (chapej vyvijen)? Od nepameti? Jako vesmir? A kdo by ho vyvinul? Velky bubak pri velkem tresku?

Ti co vyviji realtime jadra je vyviji proto, ze jsou tak dementni, ze nevi, ze staci donutit Linuse, aby trosicku odladil Linux (ale pro jednou navzdy a dokonale, bubak). Ale on by jim, dement jeden, odpovedel: "Ten linux, ktery my vyvijime nemuze byt realtime, protoze jeho primarni nasazeni neni pri rizeni letadlovych lodi ani jadernych elektraren."

A taky ti dementi z debianu, proc proboha rozdeluji distro na stable, testing, unstable. Vzdyt pri trose poradne prace by slo vsechno idealne zamichat.

Ad abstrakce. Sam jste abstrakce. Rikame ji clovek a je to slozenina z 13 trilionu bunek. I bunka je abstrakce, sklada se z mitochondrii, jadra, atd. A ty se skladaji z molekul a ty zase z atomu a atomy z kvarku a kvarky jsou na x-te urovni mozna poskladany ze superstrun, ktere se vlni ve 12-cti rozmerech z nich 4 z nich tvori nas casoprostor. A tento casoprostor/nas vesmir je doufejme prvni vrstvou abstrakce, pokud se ale nenachazi na krunyri velke smradlave zelvy. Proc se asi buh na tyhle abstrakce nevykaslal?

[zde]

Ano, jeden kernel pro každou architekturu. Proč ne? Vývoj a verzování je ok a přirozený, bude se postupně zpomalovat ale nikdy se nezastaví. Pokud se bude dodržovat kompatibilita, nikomu to nebude vadit. Pokud se předčasně nepřidávají zbytečné nebo nedozrálé featury, je dodržování kompatibility snadné.

Ad abstrakce: To co jste vyjmenoval je dáno externě, s tím nic nenaděláme, a proto to s problémem o kterém diskutujeme nesouvisí.

OT: letadlove lodi i jaderne elektrarny muze ridit stock kernel. Dukovany udajne bezi na relatkach. Kvalitni ruska technologie, co prezije i jaderny vybuch (pravda, s 20 lety bezneho provozu ale uz ma trochu problemy).

[Martin]

Je to sice super argument, ale dost mimo. Kernel ani hypervisor není bezchybný, ale když izoluji kernel virtuálního stroje od hypervisoru a ostatních virtuálních strojů, je úroveň zabezpečení úplně někde jinde, než když vše poběží na jednom kernelu.

A proč existuje třeba chroot, jail, SELinux, ..., když žádný software stejně není bezchybný?

[zde]

Tssss.. izolace je přelud... stejně na tom poběží nějaké poblblé vysokoúrovňové služby jako web services.. to vám neprostřelí směrem dolů na roota, to prolezou shora nějakým bugem v XML parseru nebo tak něco.. A hlavně celá ta slavná izolace bude na kočku, pokud v "zabetonované" VM někdo bude pouštět nějaký vhodný runtime pro makroviry, třeba office..

Druhý odstavec jsem nepochopil..

[zde]

Tenhle benchmark ...

Hmm, to nechápu.. řekl bych že UML bude výrazně lepší než virtualizace hardwaru, nechápu proč je o 50% pomalejší...

Sdílení paměti mezi stejnými OS v různých VM možné nebude, leda by na to daný OS obsahoval háky, a hypervisor je podporoval. Transparentně to impolementovat jednoznačně nejde.

Také dynamické přerozdělování fyzické paměti mezi VM nebude nikdy možné, pokud daný OS nebude podporovat něco jako hotplug memory.

To samé skutečné plánování procesů. Je triviální odchytit null task v jedné VM, když vletí na HALT, a spustit jinou VM, případně dělat timeslicing s pevnými prioritami. Cokoliv složitějšího ale vyžaduje opět spoupráci daného OS, tj definovat API mezi hypervisorem a OS.

Výsledkem je vznikne poměrně složité API, které:

1) Lidem kteří virtualizaci nechtějí bude naprosto k ničemu, přitom jim podpora pro ni bude smrdět v jejich desktopovém OS.

2) Libovolné API, které je delší než 10 řádků .H souboru, bude kdekterý idiot forkovat, takže za pár let budeme ve stejné díře jako dnes, a jediná cesta jak provozovat nekompatibilní hypervisory na stejném HW bude ultravisor.

[Martin]

Hmm, to nechápu.. řekl bych že UML bude výrazně lepší než virtualizace hardwaru, nechápu proč je o 50% pomalejší...

Možná jste si nejdřív měl o problematice něco přečíst, než jste začal tuhle "diskuzi".

Výše byla uvedena některá využití pro virtuální stroje, která jste zatím nedokázal zpochybnit.Vysvětlete mi prosím, jak to hodláte řešit bez virtuálních strojů (http://www.abclinuxu.cz/blog/Linuch/2005/9/29/103318#15)?

Pořád mluvíte o tom co není možné a zároveň dáváte najevo, že o skutečné implementaci hypervisorů nevíte nic. Zajímavý přístup...

Lidem kteří virtualizaci nechtějí bude naprosto k ničemu, přitom jim podpora pro ni bude smrdět v jejich desktopovém OS.

Nevšiml jsem si, že by mi někdo virtualizaci nutil...

Zbytek jsou jen spekulace.

[zde]

Možná jste si nejdřív měl o problematice něco přečíst, než jste začal tuhle "diskuzi".

Sorry, ale vlastní hlava mi říká že jádro, PŘEDEM UPRAVÉ k tomu aby běželo co nejefektivněji pod jiným jádrem, poběží mnohem efektivněji, než obdobné jádro které s tím nepočítá, leze přímo na železo, a je virtualizováno různejma špinavejma hackama.

Pokud tahle samozřejmost neplatí, nepotřebuju k tomu aby mi to bylo divný nic číst. Nejste vy takovej ten co si nepřečtu od jinejch, tomu nevěřím???

Pořád mluvíte o tom co není možné a zároveň dáváte najevo, že o skutečné implementaci hypervisorů nevíte nic.

Pokud víte o způsobech, jak obejít konkrétní technické problémy, které jsem zmiňoval, rád se je dozvím a změním názor.

Příklad: sdílení RO stránek, načtených ze stejného sektoru na disku. Aby to hypervisor mohl dělat, musí:

- pro každý virtuální stroj sledovat jak programuje PCI DMA, kam které sektory načítá, kam je poté kopíruje. - jestli se stránka občas nemění na RW a není modifkovaná. - jestli některý VM mezitím nemění data na disku..

Hmm, tohle by mozná šlo, aspoň v případě že OS stránku načte na pevnou adresu a pak s ní nehýbe, což asi většinou opravdu nebude..

Ale dynamicky přehazovat fyzickou paměť mezi VM zcela jistě nepůjde, když jim při bootu řeknete v součtu víc než fyzicky máte, budete je muset v okamžiku kdy všechno zaberou odstřelovat... nebo hyperswapovat??? brrrr to je svinstvo... no dobře řekněme že hypervisor má swap..

Ale jak se hypervisor dozví priority tasků, která jsou v jednotlivých VM ready? Každý OS může mít jinou implementaci run queue, to hypervisor nemůže prohlédnout, při schedullingu bude nutně střílet naslepo!

První dva argumenty beru zpět, souhlasím že s pamětí může hv dělat opravdu slušné kejkle.

A na to že "ostatní jsou jen spekulace" klidně zapomeňte, opearční systémy byly původně vyvíjeny jako KONEČNÁ abstrakce hardwaru, a pokud naznáte že potřebujete hypervisor (tj že selhaly), nutně připouštíte to samé o úroveň výše.

[Martin]

Samozřejmě že že OS portovaný na Xen "poběží" efektivněji než neportovaný OS.

opearční systémy byly původně vyvíjeny jako KONEČNÁ abstrakce hardwaru

Jak byly vyvíjeny původně, na tom nezáleží. Důležité jsou současné požadavky. A s virtualizací se počítá už hóódně dlouho. Viz třeba "Formal requirements for virtualizable third generation architectures" od Popka a Goldberga z roku 1974. Tyhle požadavky mimochodem x86 dodnes nesplňuje a díky tomu je nutné dělat takové hnusné hacky jako dělá např. VMware...

[zde]

Kde bych se prosím o těch hackách co používá VMWare dočetl víc? Kdysi jsem to hledal a nic nenašel..

ad požadavky na virtualizovatelnou architekturu: Nejde hlavně o to, aby šlo levně oblbnout kód v user modu cpu, aby si myslel že běží v supervisor módu? Je ten text někde online?

[Martin]

Kromě toho, že provádí dynamickou rekompilaci se toho asi moc zjistit nedá.

Ten Popkův a Goldbergův text můžete zkusit stáhnout z http://portal.acm.org/citation.cfm?id=361011.361073

[zde]

To si nemyslím. Dynamickou rekompilaci dělá QEMU taky, a řekl bych že velmi dobře, přesto je mnohem pomalejší. VMWare bude mít podle mne nějakou heuristiku, jak pozná v určitých konkrétních OS, co se emulovat nemusí, jen na konkrétní místa nastrká breakpointy, a spouští to přímo.

Ten link na ACM jsem měl taky, ale nejsem member, ti hlupáci mají full text za "controlled feature", a já je nehodlám podporovat.. Citeseer na to má sice hafo citací, ale dokument nikoliv. I tak díky.

[zde]

Zapoměl jsem na diskový scheduler.. ten taky v hypervisoru poběží blbě, protože hypervisor bude nutně z každé VM vidět jen aktuální žádosti- ty sice může přeskládávat ale nevidí "za ně", takže smůla. Leda emulovat disk s NCQ a nekonečnou hloubkou fronty, a doufat že to VM umějí poznat a použít, což většinou neumějí.

[wake]

proč by vývojáři měli klečet na hrách???

[zde]

Hrách setý. Sušený, samozřejmě. Klečet. Zaslouženě.

[wake]

<noflame>no, vývojáři takového qnx či beos se nemají za co stydět. to spíš marketroidi, kterým se nepodařilo prosadit tyto a podobně skutečné systémy na úkor parodií jako Win, Lin & co.</noflame>

[Jiří (BoodOk) Kadeřávek]

Hnusny marketroid Thorvalds. Do zelez s nim, parchantem!

[wake]

... Thor Waldez...

[zde]

Linus je v tísni!!!

[hajma]

nevím, ale představa vývojářů klečících na hromadě CDček s Doomem III se mi docela líbí