2024. március 29., péntek

Gyorskeresés

Emuláció vagy virtualizáció?

Írta: | Kulcsszavak: virtualizáció . emuláció

[ ÚJ BEJEGYZÉS ]

A véleményetekre lennék kíváncsi. Elgondolkoztam, hogy mikor mondhatom hogy egy gép virtualizált és mikor, hogy emulált. Ha az elméleti definícióját nézzük, akkor minimális az eltérés:

- Az emuláció lényege, hogy egy teljesen eltérő környezetben teszi lehetővé a programok futását. Az emulátor tehát egy olyan (szoftver-hardver) eszköz, ami megvalósítja ezt a kompatibilitást.
- Virtualizáció során egy látszólagos környezetet hozunk létre, ami érinthet egy vagy több hardver vagy szoftver elemet.

Válasz 1:

Ez alapján minden emuláció, mert egy virtualPC vagy ESXi is több hardvert emulál. Pl. a vidókártyát, vagy a floppy meghajtót. Talán a legjobb választóvonal az lehetne, hogy a CPU-t emuláljuk-e. De itt bejön az, hogy a VT ide vagy oda, a ring 0-ba tartozó (guest operációs rendszer kernel egy része) kódot mindenféle trükkökkel tudják csak futtatni. Régebbi gépeken VT hiányában (S775-ön a kisebb CPU-ból az Intel kispórolta) szintén leginkább emulációhoz hasonló kód átalakító-trap beszúró átalakítás szükséges.

Válasz 2:

Egy határozott különbséget lehet húzni a kettő közé. Ha a CPU-t regiszterestül, ALU-val és FPU-val együtt emuláljuk és a bináris kód ezen fut, akkor emuláció. (Példa: dolphin-emu, bochs) Ha a bináris kód nagy része (90% fölött) natívan a fizikai gép CPU-ján fut átalakítás nélkül, akkor virtualizáció. (pl. virtualbox)

Az elmélet alapján az első válasz a korrekt. Ha azt nézem, hogy a gyakorlatban mire használjuk az elnevezéseket, akkor a második. Ehhez a másodikhoz hozzá lehet adni azt is, hogy az emuláció és a virtualizáció sebessége között hatalmas különbség (>10x) van az esetek többségében.

Hozzászólások

(#1) puttputt


puttputt
őstag

Részemről...

Az emulálást hallva mindig inkább a szoftveroldal jut eszembe először.
Sosem felejtem el, mikor PSP-t, Nintendót és PS2-t emuláltam
HP-Ipaq-on (azt hiszem még a régi rz17..18..20-as szériából...talán 17.).
Kifagyott párszor, de vitte a GTA2-t. :DDD
Egy Siemens T830-on is kísérletezgettem ilyenekkel. Lehet, hogy ott volt a GTA.
Pontosan nem rémlik fel. Ami biztos, hogy mindkettőn nyúztam az emulátorokat.
Szóval, nem csak Java-t érdemes és lehet. :)

A virtualizációnál még kell további vas is esetenként, nem is kevés. Persze, ott már akár komoly, sokkal aktívabb (vs. emuláció), tk. másodlagos rendszert kaphatunk.
Ahogy írtad, mélyebb a ráereszkedés a gépre.

Igen, szóval minden virtualizáció emuláció is. Ez nem rossz konklúzió.

:LKBK-Inventor / * Mindig más nő mellett ébredek ... a buszon. ///////////////////////

(#2) Peter Kiss


Peter Kiss
senior tag
LOGOUT blog

Igen, a "mélyebb ráereszkedés a gépre" egész jó megfogalmazás. Az emuláció kevesebb erőforrást képes "varázsolni" kevesebb rétegben, ráadásul sokkal nehézkesebb.

Virtualizáció meg pont ezekben több, jobb, de pl. azt nem szabad elfelejteni, hogy pl. a WINE-nal történő szoftverfuttatás olcsóbb, mintha Virtualbox-ban futna egy licenszelt Windows, és azon menne az adott program.

Viszont így a Microsoft Megnevezése az Application Virtualization-ra (App-V) rossz, az inkább emuláció, nemde?

(#3) danih válasza puttputt (#1) üzenetére


danih
addikt

SZerintem PSX-et emuláltál te azon az iPaq-on, nem PSP-t vagy PS2-t :)

(#4) kraftxld válasza Peter Kiss (#2) üzenetére


kraftxld
nagyúr

Az App-V az se nem virtualizáció se nem emuláció, inkább a szoftver különválasztása az oprendszertől és külön csomagban való futtatása.

| MCSE+M/S, MCITP, VCP6.5-DCV - ''Life can be hard, but Scooter is harder :)'

(#5) P.H.


P.H.
senior tag

A virtualizáció beilleszhető abba az időrendben evolúciós sorba, amely először a hardvert teljes mértékben birtokló programok egymás melleti futtatásának igényét szolgálta ki (először trükkökkel, aztán hardveres támogatással), most a hardvert teljes mértékben biztokló OS-ek egymás melletti futtatásának igényét szolgálja ki (először az említett szoftveres - pl. átalakító-trap, bit-translation -, majd később hardveres támogatással - pl. VT, AMD-V).

A hardver-emuláció megléte jelenleg a következők miatt van (és lesz) szvsz:
- egyrészt még a hardveres támogatás kidolgozottsága nem teljes, az IOMMU vagy az Intel hasonló megoldása és annak kihasználása nem általánosan elterjedt még; ezek segítségével a virtuális OS-ek közvetlenül férhetnek hozzá a fizikai hardverelemekhez úgy, hogy az egymás közötti átjárhatatlanságuk hardveresen megoldott (ahogy a programoké is védett módú OS alatt).
- praktikus pl. floppy-t emulálni ritka használat esetén olyan gépen, amelyen nincs valójában; vagy hálózati adaptert, amellyel belső hálózat alakítható ki a virtuális gépek között
- minél több az emulált hardver, annál könnyebb migrálni a virtuális gépeket más alaphardverre (pl. szervereken virtuális megjelenítő).

[ Szerkesztve ]

Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

(#6) frescho válasza P.H. (#5) üzenetére


frescho
addikt

Az evolúciós sort kezdheted korábbról. Virtuális környezetet igény a single user, single task gépeknél jelent meg. Először hardverből oldották meg az időosztást, így egy OS/user volt a e felállás. Ez azonban erőforrás pazarló volt. Következett a multi user rendszer, ami minden felhasználónak saját terminált biztosított. Ezt megoldották applikációkra is, elég ha csak egy chroot jail-re vagy a wine-ra gondolsz.

Erről jut eszembe a következő kérdés: Szerintem több szintű virtualizáció van HW, OS, Desktop, Applikáció. Ezek közül az OS-t hívják sokan virtualizációnak. Szerintetek melyik virtualizáció és melyik nem?

Nem kérdés, hogy kell emuláció. A ritkán használt, lassú hardverek, mint floppy vagy CD emulációja nagyrészt megoldották. Az IO-t is felgyorsítják saját driverek telepítésével. Szerver vonalon már majdnem tökéletes a dolog. Gondot csak a VGA jelent, de szerintem erre is lesz megoldás.

kraftxld: Az is egy virtuális környezetet ad. Csak a virtualizáció szintje eltolódik az OS fölé, az applikációs szintre. Lasd P.H.-nak írtakat

https://frescho.hu

(#7) P.H. válasza frescho (#6) üzenetére


P.H.
senior tag

Én egy kitüntetett irányból közelítettem meg a kérdést, nevezetesen mire készült dedikált hardveres támogatás: az időosztás (vagy sima időzítő megszakítás) megvolt a kezdeti rendszerekben is, erre jött az felhasználói programok által módosítható környezet (regiszterek, FPU) hardveres mentése/visszatöltése, majd ezek elszeparálása (pl. lapozás); jelenleg gyakorlatilag a teljes CPU-környezet (beállított lapozási módok, felprogramozott vezérlőregiszterek, ...) váltása történik hardveresen, és terjed az IOMMU-féle szeparálás (a lapozás "megfelelője" a hardverekre).
Ez egyféle megközelítés, nyilván nem teljeskörű; viszont a többi, amit említesz, desktop és applikáció, többé-kevésbé (alap)szoftveres kérdés.

Lehetséges az egészet tisztán szoftveresen is megközelíteni, úgy abszolút elmosódnak a határok, pl. [link].

Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

(#8) frescho válasza P.H. (#7) üzenetére


frescho
addikt

Ez egy jo nezopont. Jol ertem, hogy ha hardver, akkor virtualizacio, ha szoftver, akkor emulacio a velemenyed szerint? Az IOMMU nem rossz, de a +CPU terhelese esetenkent nem elhanyagolhato. A jelenlegi trendet szerintem az APU-k megjelenesevel tovabb fogjak vinni es a shaderek is szetoszthatoak lesznek.

Tudom, hogy elvalaszthatatlan a ketto es teoretikus a kerdes, de pont az elmosodo hatar miatt tettem fel. Tetszik a link.

https://frescho.hu

(#9) P.H. válasza frescho (#8) üzenetére


P.H.
senior tag

Jól érted, annyi kitétellel, hogy mivel a hardver egy lépéssel a már megvalósított szoftveres megoldások mögött ját, így virtualizáció az, ami legalább elméleti szinten támogatható hardverrel (se a sandbox-ok, se az OS-specifikus környezetimitálások - a wine, chroot jail -, se az architektúra-emulátorok nem ilyenek) és igény is lenne a támogatásra.

Az IOMMU-nak nincs CPU-terhelése, mivel a northbridge-ben és/vagy a southbridge-ben van a dedikált hardvere. Bár alapvetően DMA-megközelítésű; de a PIO amúgy is a CPU-t terheli.

Részletes áttekintés: [link] (5. oldal a rendszerfelépítés). Alapvetően arról van szó, hogy míg nélküle a host OS drivere kezeli a hardvert és ezért a driverért versengenek a virtuális gépek driverei, addig IOMMU-egység jelenléte esetén (annak felprogramozása után) a virtuális és a host driverek egyenrangúak, közvetlenül a hardverért versengenek. Az IOMMU-egység dönti el, melyik hardvert láthat egyáltalán egy-egy OS, illetve azok írási/olvasási kérései mely memóriaterületekkel köthetők össze ill. melyek szabálytalanok.

Valóban a VGA-k esetén már van igény ilyen szétosztásra, "GPU-multitasking-ra". Hogy ezt shader-elosztással fogják-e megoldani, vagy inkább időosztással, nem tudom, de a Fermi-t nézve úgy tűnik, neked lesz igazad.

[ Szerkesztve ]

Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

(#10) frescho válasza P.H. (#9) üzenetére


frescho
addikt

Ez a felosztassal kovetkezetes, megha nem is teljesen tudok vele egyeterteni. A problemat ott latom, hogy a gyakorlatban nincs tiszta virtualizacio, szinte mindig van emulacio is. Szoval azzal finomitanam, hogy aranyaiban ahol a fo komponensre (CPU) igaz, az a virtualizacio.

IOMMU-val tisztaban vagyok, de bizony plusz terhelese van. Ezt pont a versenges es a plusz reteg okozza. Ha sokan akarnak sok apro feladatot adni a HW-nek, akkor ez jelentos is lehet, legalabbis sajat meresek ezt bizonyitottak.

Szimplan egyszerubb megvalositani, a host OS/hypervisor-nak kell egy driver, amihez fordulhatnak a guest-ek. De ez meg a jovo zeneje.

https://frescho.hu

További hozzászólások megtekintése...
Copyright © 2000-2024 PROHARDVER Informatikai Kft.