Grafikus teljesítmény modern virtuális gépekben: valódi kulcsok

Amikor létrehozunk egy modern virtuális környezetet, és úgy kezdjük el használni, mintha egy igazi asztali számítógép lenne, az első meglepetések egyike általában az, hogy bár a CPU és a RAM simán működik, A virtuális gépek grafikai élménye nehézkesebbnek tűnik.Akadozó és húzódó Windows rendszer, akadozó menük, vagy a nem olyan simán lejátszható YouTube-videók. Mindez még modern CPU-kkal és erős integrált grafikával felszerelt, viszonylag jó gépeken is.

Ez a viselkedés nem véletlen. A virtualizáció egy plusz réteget hoz létre a hardver és a vendég operációs rendszer között, és ennek a rétegnek ára van, különösen, ha a következőkről beszélünk: 2D/3D grafika és GPU gyorsulásUgyanakkor az iparág számos technológiát kínál (GPU áteresztés, vGPU, SR-IOV, GVT-g, GRID, MxGPU, VirGL stb.), amelyek a dolgok javítását ígérik, de nem mindig világos, hogy mit várhatunk el mindegyiktől, milyen korlátaik vannak, vagy hogy valóban megéri-e bonyolítani a dolgokat.

Miért nem egyezik meg soha egy virtuális gép grafikus teljesítménye a gazdagépével?

A virtuális gép a gazdarendszer szemében egyszerűen egy felhasználói térbeli folyamat. A hipervizornak folyamatosan le kell fordítania a vendéggép hívásait a valódi hardverre, hogy Mindig elkerülhetetlen a túlterhelés.Ez a büntetés sok munkaterhelésnél viszonylag észrevehetetlen a CPU és a RAM esetében, de a grafika és az I/O (lemez és hálózat) esetében általában szembetűnőbb.

Egy tipikus esetben, ha a KVM/QEMU és a Debian vagy Ubuntu szerver a gazdagép, az asztali virtuális gépek általában egy Virtio-GPU virtuális grafikus eszközt használnak (gyakran egy VNC vagy SPICE szerverrel az asztal eléréséhez). Ez az architektúra lehetővé teszi, hogy minden Virtuálisgép-renderelés áthalad egy további rétegen (a hipervizor, a távoli protokoll, a host compositor stb.), ami nagyobb késleltetést, kevesebb FPS-t és összességében rosszabb simaságérzetet eredményez, mint a fizikai rendszeren.

Még akkor is, ha az alap hardver erős (például egy Ryzen 7 integrált Radeon Renoirral, amely képes könnyedén kezelni egy 4K-s asztali gépet), A virtuális gép ritkán tudja reprodukálni ezt a simaságot. Ez különösen igaz, ha kizárólag szabványos virtuális grafikára vagy szoftveres renderelésre támaszkodik. Az összetett weboldalak, az asztali animációk és a nagy bitrátájú videólejátszás az első olyan forgatókönyvek, ahol a teljesítménycsökkenés észrevehetővé válik.

Továbbá figyelembe kell venni a virtualizáció általános hátrányait is: tipikus összehasonlító tesztekEgy jól konfigurált virtuális gép veszít körülbelül 5-10%-os CPU teljesítménynövekedés, egy között A RAM sávszélességének 7-15%-a y A lemez IOPS 15-25%-a a csupasz fémhez képest. Sok terhelésnél ez nem drámai, de ha mindezt kombináljuk a grafikai túlterheléssel, az asztali élmény jelentősen romolhat.

Ezért a kulcskérdés nem annyira az, hogy elérhető-e a natív teljesítmény (az őszinte válasz az, hogy szinte soha nem 100%), hanem az, hogy milyen mechanizmusok léteznek ennek elérésére. kerülj a lehető legközelebb a házigazda viselkedésére és arra, hogy milyen kompromisszumokkal jár mindegyik.

Virtio-GPU, VirGL és "szoftveres" 3D grafika KVM/QEMU-ban

Virtio-GPU Most már ez az alapértelmezett opció számos KVM környezetben, ha valami jobbat keresünk, mint a régebbi emulált VGA adapterek. Lehetővé teszi bizonyos gyorsítási képességek megosztását a host és a guest között, és ha a SPICE-szal vagy egy olyan klienssel kombináljuk, amely támogatja ezt a stacket, A 2D teljesítmény általában elfogadható Könnyű irodai alkalmazásokhoz, böngészéshez és fejlesztői környezetekhez, túl sok grafikai kidolgozás nélkül.

Azonban, amikor aktiválódik VirGL A virtuális gépen a 3D gyorsítás engedélyezéséhez az eredmények nagymértékben változhatnak a fizikai GPU-tól, az illesztőprogramoktól és a terheléstől függően. A VirGL delegálja az OpenGL parancsok végrehajtását a virtuális gépről a gazdagépre.A fordítás és a hozzáadott kontextus azonban lehetővé teheti, hogy szerényebb beágyazott hardvereken, az asztali gép még lassabb lesz 3D gyorsítás nélkül: lefagyó animációk, kevésbé sima görgetés, a GPU helyett a CPU-ra támaszkodó videók stb.

Az integrált GPU-val rendelkező gépeken, mint például az AMD Renoir vagy hasonló, nem ritka, hogy a VirGL engedélyezése miatt a gazdagép feldolgozási teljesítménye nem elegendő az extra réteg kezeléséhez, ami a teljesítményt az „elégséges, de javítható” szintről az „teljesen elviselhetetlen” szintre csökkenti. Ebben az összefüggésben, Irreális elvárás, hogy a VirGL egy virtuális gépet a gazdagép tökéletes grafikus klónjává alakítson.különösen 4K felbontásnál több aktív virtuális asztallal.

Tehát, ha valódi PC-szerű asztali folyékonyságot keresel, a VirGL általában nem a csodaszer. Hasznos bizonyos könnyű 3D-s tesztekhez vagy olyan alkalmazásokhoz, amelyek némi gyorsulást igényelnek, de Ez nem egyenértékű egy dedikált fizikai GPU-val minden virtuális gépen.

GPU áteresztés: közel natív teljesítmény a merevség rovására

A gazdagéppel közel azonos grafikus teljesítmény elérésének legközvetlenebb módja a következő: GPU áteresztés (közvetlen kiosztás) az IOMMU-n keresztül. Itt a virtuális gép szinte úgy látja a fizikai GPU-t, mintha az önmagában lenne: a natív illesztőprogramok a vendég belsejében, és mind 2D-ben, mind 3D-ben a csupasz fémhez nagyon közeli teljesítményt nyújt.

A hátránya, hogy ez a rendszer meglehetősen merev: hogy a GPU-t a virtuális gép "eltérítette" Amíg fut, a gazdagép már nem tudja saját asztali gépként használni. Grafikus felület nélküli szerveren ez nem jelent problémát, de egy laptopon vagy számítógépen, ahol a gazdagépnek és a virtuális gépnek ugyanazt a képernyőt és munkamenetet kell használnia, a dolgok bonyolulttá válnak.

Továbbá számos, játékokhoz vagy CAD-hez tervezett áteresztő konfiguráció megköveteli a használatát. a monitor fizikailag csatlakoztatva van a GPU kimenetéhez a virtuális géphez van rendelve. Ez magában foglalja a monitor bemenetének megváltoztatását vagy két képernyő használatát, ami meghiúsítja a gazdagép és a vendég „keverésének” célját ugyanabban a vizuális élményben.

Az olyan projektek, mint a Looking Glass, lehetővé teszik a virtuális gép framebufferének rögzítését (egy dedikált GPU-val) és megjelenítését a gazdagépen anélkül, hogy fizikailag monitort kellene váltani, de ez egy olyan megoldás, amely hozzáadja Több függőség, több konfigurációs lépés és több meghibásodási pontAzok számára, akik valami egyszerűt és Debiannal vagy más disztribúciókkal integrált megoldást keresnek, ez nem mindig a legjobb választás.

Összefoglalva, a klasszikus GPU-áteresztés ideális olyan helyzetekben, amikor azt szeretné, hogy egy adott virtuális gép maximális grafikus teljesítménye (3D szerkesztés, MI, játék, CAD), és a gazdagépnek nem kell ezt a GPU-t használnia a saját felületéhez. Azonban több, ugyanazon a képernyőn megosztó asztali számítógép esetén a hasznossága korlátozottabb, kivéve, ha a használhatóság terén kompromisszumokat fogadnak el.

SR-IOV, vGPU és hardveresen megosztott GPU: hogyan működnek és milyen korlátaik vannak

Az „egy GPU virtuális gépenként” modellel ellentétben a következő technológiák hardveralapú megosztott GPU A (vGPU) lehetővé teszi egyetlen fizikai eszköz több virtuális példányra osztását, így minden virtuális gép a grafikus teljesítmény egy dedikált részét kapja anélkül, hogy vendégenként külön GPU-t kellene fizetni.

Ezen belül számos családot találunk: NVIDIA vGPU/GRID (RTX vWS stb.), AMD MxGPU, Intel GVT-g és általánosságban az SR-IOV-alapú virtualizáció. Mindegyikben a cél az, hogy az egyes virtuális gépek grafikus parancsai a lehető legközvetlenebbül kerüljenek átadásra a GPU-nak. a hipervizor költséges fordításának elkerülése és a teljesítmény javítása a hagyományos emulált vagy paravirtualizált grafikákhoz képest.

Az elmélet tökéletesnek hangzik, de a gyakorlatban számos fontos árnyalatnyi különbség van:

• Ez nem egy „varázslatos” vagy teljesen átlátszó technológia. A virtuális gép továbbra is tudja, hogy egy speciális eszközzel kommunikál, speciális illesztőprogramokat igényel, és korlátozások vonatkoznak a gyorsmigrációkra, a pillanatképekre és a dinamikus memóriakezelésre.
• Sok vGPU megoldás, különösen az NVIDIA és az AMD esetében, Nagyon drága szakmai kártyákhoz kapcsolódnak., további licencekkel és néha nem vonzó előfizetési modellekkel otthoni használatra vagy kis helyi környezetekre.
• A hivatalos támogatás általában a tanúsított hipervizorokra és operációs rendszerekre (vSphere, Citrix Hypervisor, RHEL stb.) összpontosít, így olyan disztribúciókban, mint a Debian Lehet, hogy több súrlódás és kevesebb dokumentáció lesz..

Röviden, az SR-IOV és a vGPU egyértelműen javítja a grafikus teljesítményt a Virtio/VirGL-hez képest, de Nem teszik a virtualizációt megkülönböztethetetlenné a bare-metaltól és technikai és gazdasági korlátokkal kell együtt élniük, amelyeket a bevezetés előtt fel kell mérni.

Intel GVT-g / KVMGT, Proxmox és gyorsítás könnyű asztali számítógépekhez

Az integrált GPU-k területén, különösen az Intel termékeiben, az egyik legérdekesebb technológia a Intel GVT-g (más néven KVMGT)A célja pontosan az, hogy több virtuális gép is megoszthassa a processzor iGPU-ját, mindegyiket a saját gyorsított "szeletével", ahelyett, hogy kizárólagos áteresztést kellene végeznie egyetlen virtuális gép felé.

Böngészéshez, irodai alkalmazásokhoz, IDE-khez és könnyű 2D/3D alkalmazásokhoz a GVT-g használható. jelentős javulás az alap Virtio grafikához képestcsökkenti a késleltetést ablakok húzásakor vagy menük megnyitásakor, és hardveres gyorsítást biztosít bizonyos műveletekhez, amelyek egyébként teljes egészében a CPU-ra hárulnának.

Azonban a manuális beállítás egy egyszerű KVM/QEMU telepítésen Linuxon némileg munkaigényes lehet: módosítani kell az IOMMU konfigurációját, betölteni az egyes modulokat, meg kell határozni a vGPU eszköztípusokat stb. Olyan környezetek, mint a A Proxmox VE leegyszerűsíti ezt a folyamatot, amely a webes felület varázslóiból kínálja a PCI áteresztés és a virtuális GPU-k (például az Intel KVMGT) konfigurálását anélkül, hogy annyira bajlódna az alacsony szintű fájlokkal.

Érdemes tisztázni néhány pontot azzal kapcsolatban, hogy mit is várhatunk valójában a GVT-g-től:

• A grafikai fejlesztés létezik, de csodákat nem tesz. A tipikus asztali feladatokhoz, amelyek nem igényelnek nagy 3D-s munkaterhelést, a felhasználói élménybeli különbség általában elegendő ahhoz, hogy a virtuális gép közelebb érezze magát egy szerényebb fizikai számítógéphez, de ez nem megoldás az igényes játékokhoz vagy a nagy teljesítményű 3D-s rendereléshez.
• Nem varázslatosan "csatlakozik" a hipervizorhoz. A kernelnek, az iGPU-nak és a hipervizornak támogatnia kell a technológiát, és bár a Proxmox jobban elérhetővé teszi, mint egy manuális telepítés, továbbra is vannak hardver- és verziókövetelmények.
• Nem minden iGPU vagy Intel platform támogatja egyformán. Az újabb generációkban a grafikus virtualizáció átalakulóban van, és a hangsúly egy része a mobil vagy adatközponti termékek felé helyeződött át.

Tehát, ha kompatibilis Intel processzorral rendelkezik, és extra simaságot szeretne elérni anélkül, hogy belépne a professzionális GPU-k világába, A GVT-g egy olyan környezetben, mint a Proxmox, ésszerű lehetőség a virtuális gépeken belüli könnyű asztali gépek élményének javítása érdekében.

SR-IOV a modern GPU-kban: mit kínál, és miért nem csodaszer

Az SR-IOV egy PCI Express kiterjesztés, amely lehetővé teszi egy fizikai eszköz több virtuális függvényként való megjelenítését, amelyek mindegyike hozzárendelhető egy virtuális géphez. Ez a hálózati kártyákban jól bevált koncepció néhány modern GPU-ra is alkalmazták, így Egyetlen GPU több vGPU-példányt is képes biztosítani megfelelő izolációval.

Az integrált grafikák világában az egyik platform, amely a legnagyobb zajt csapta ezen a téren, a Intel Lunar Lake Xe2 grafikávalamely bizonyos modellekben támogatja az SR-IOV-ot az iGPU-n. Elméletileg ez lehetővé tenné több Linux vagy Windows virtuális gép számára, hogy hozzáférjenek a közel natív gyorsított grafikus képességekhez, jobb erőforrás-elosztással, mint a tisztán szoftveralapú megközelítések.

Azonban a hardvervásárlások eldöntésekor kizárólag az SR-IOV-ra hagyatkozni több okból is kockázatos:

• A GPU-kon a tényleges SR-IOV támogatás még mindig nagyon egyenetlen. gyártók és modellek között. Az Intel esetében néhány mobil integrált grafikus kártya kínálja ezt, míg az asztali Xe2 különálló kártyák nem, a Flex adatközponti termékcsaládok pedig egy másik szegmensre irányulnak, és sokkal magasabb költségekkel járnak.
• SR-IOV Továbbra is speciális illesztőprogramokat és karbantartást igényelEz nem transzparens a virtuális gépek számára, és inkompatibilitások merülhetnek fel bizonyos kernel- vagy hipervizorverziókkal.
• A gyakorlati tapasztalat azt mutatja, hogy bár a A késleltetés és az FPS javul, A virtualizáció többletterhelése nem szűnt meg teljesenés más szűk keresztmetszetek (CPU, memória, lemez, hálózat) sem oldódnak meg maguktól.

Más szóval: az SR-IOV segít, de Nem a „varázsmegoldás” az, ami bármelyik virtuális gépet a gazdagép tökéletes klónjává változtatja.És a piac jelenlegi állapotát tekintve, felesleges lehet kizárólag egy Xe2 Mobile-lal felszerelt laptop keresésére korlátozni magunkat, csak ezért a funkcióért, ha nincsenek igazán igényes grafikai terheléseink.

Fizikai szerverek kontra virtualizált környezetek: globális hatás a CPU-ra, RAM-ra és lemezre

A GPU-n túl fontos megérteni a viselkedésüket is. CPU, memória és tárhely virtualizált környezetben egy fizikai szerverhez képest, mivel ezen erőforrások bármelyikének szűk keresztmetszete súlyosbíthatja a "lassú virtuális gép" érzetét, még akkor is, ha a grafikus rész nem a fő probléma.

Általánosságban elmondható, hogy egy bare-metal szerver a következőket kínálja: a lehető legnagyobb teljesítményEz azért van, mert az operációs rendszer közvetlenül kommunikál a hardverrel, a hipervizor réteg nélkül. Amikor azonban virtualizációt (KVM, Proxmox, VMware, Hyper-V stb.) vezetnek be, a hipervizornak kell elosztania több virtuális gép hozzáférését ugyanazon fizikai erőforrásokhoz, ami némi adminisztratív terhelést jelent.

A tipikus referenciaértékek azt mutatják, hogy:

• La CPU a virtuális gépben Általában 5-8%-kal kevesebbet teljesít, mint a bare-metal, a hipervizortól függően.
• La RAM Ez némi effektív sávszélességet veszít (7-13%-os nagyságrendben) a címfordítás és a belső memória-elszámolás miatt.
• El diszkó Az IOPS 15-25%-os csökkenését tapasztalhatja, különösen akkor, ha több réteg van felül (távoli tároló, gyorsítótárazás stb.).

Ez a büntetés, bár elfogadható, gondosan mérlegelni kell annak értékelésekor, hogy egy nagyon alacsony késleltetési követelményekkel rendelkező alkalmazás (pl. nagy teljesítményű adatbázisok vagy valós idejű játékmotorok) jobban teljesít-e dedikált fizikai szerverek vagy kényelmesen áttérhetsz virtuális gépekre szenvedés nélkül.

Hasonlóképpen, a GPU-igényes munkaterheléseknél (MI, 3D renderelés, CAD) egy dedikált GPU-kkal rendelkező, bare-metal környezet fenntartja a mindig egy kis előny A virtualizációhoz képest, még vGPU-val és áteresztéssel is, ez egyszerűen azért van, mert megspórolja a hipervizor által elvégzett összes további elszámolást.

Milyen típusú munkaterhelések működnek a legjobban fizikai környezetben, és melyek virtuális gépekben?

Nem minden alkalmazás teljesít egyformán jól egy virtuális gépen. Néhányuk tökéletesen alkalmazkodik a virtualizációhoz, míg mások továbbra is jobban futnak csupasz fémen. Ennek a különbségtételnek a megértése nagyban segít a döntéshozatalban. Hol van értelme GPU-kba, CPU-kba, vagy mindkettőbe befektetni?.

Azok között az esetek között, amikor egy dedikált fizikai szerver Az előnyben részesített opció általában itt található:

• Nagy teljesítményű adatbázisok (Oracle, SAP HANA, SQL Server Enterprise), amelyek minimális késleltetésre és több ezer állandó IOPS-ra támaszkodnak.
• Renderelési és nagy teljesítményű számítástechnikai alkalmazások (Blender, AutoCAD, nagy AI/ML munkaterhelések), ahol a GPU és a lemez alrendszer a határaikon működik.
• Játékszerverek vagy valós idejű streamingahol az alacsony késleltetés és az állandó válaszidő teszi a különbséget.

Ezzel szemben a virtualizáció olyan alkalmazásokkal ragyog, amelyek profitálnak belőle rugalmasság, skálázhatóság és központosított menedzsment, Mit:

• Webszerverek, mikroszolgáltatások és API-k (Nginx, Apache, Kubernetes), amelyek jól illeszkednek a horizontális skálázás logikájához több virtuális géppel vagy konténerrel.
• Virtuális asztalok és VDI (Windows 365, Citrix stb.), ahol az izoláció és a központi adminisztráció meghaladja a maximális FPS-t.
• Fejlesztési és tesztelési platformok (Jenkins, GitLab Runners, efemer tesztkörnyezetek), amelyek gyors klónozást, pillanatképeket és egyszerű visszagörgetést igényelnek.

A webböngészéshez, irodai alkalmazásokhoz és hipervizoron, például KVM-en vagy Proxmoxon történő programozáshoz használt Linux vagy Windows asztali számítógépek esetében... A virtualizáció tökéletesen megvalósíthatóA kulcs a CPU, a RAM és a lemez megfelelő méretezésében, valamint a hardverhez elérhető legjobb grafikus opció használatában rejlik (Virtio-GPU jó konfigurációval, GVT-g, ha rendelkezésre áll kompatibilis Intel GPU, vagy akár passthrough/vGPU, ahol értelmes).

CPU, memória és lemez: hogyan befolyásolják a virtuális gép grafikus élményét

Gyakran a virtuális gép összes „laggolását” a grafikus komponensnek tulajdonítják, de sok esetben mögöttes problémák vannak a következőkkel: CPU, memória vagy lemez telített ami egy nehézkes felületet eredményez, függetlenül a GPU-tól.

Ha a virtuális gépnek nincs elég vCPU-ja, vagy a fizikai CPU túlterhelt (nagyon magas vCPU:pCPU túlterhelés), a hipervizor nem tudja időben ütemezni a virtuális gép folyamatait. Olyan metrikák, mint a CPU-ra kész A VMware-ben, vagy a KVM/Proxmoxban található hasonló számlálók segítenek észlelni ezt a jelenséget: ha a virtuális mag túl sok időt tölt a sorára várakozva (az intervallum 10%-a felett), a virtuális gép lassúvá válik, még akkor is, ha a GPU kihasználatlan.

Valami hasonló történik a memóriával is. Ha túl kevés RAM van lefoglalva a virtuális gép számára, a vendéggép swap metódust kezd használni, és minden ablakváltás magában foglalja a következőt: lemez olvas és írHa a gazdagépen túl sok memória van lefoglalva, és az swap protokollhoz folyamodik, mind a gazdagép, mind a virtuális gépek büntetendők lesznek. Éles környezetekben elengedhetetlen az agresszív memória-túlterhelés elkerülése.

A tárolási részben a nagy késleltetésű és kevés elérhető IOPS-szel rendelkező lemezes alrendszer a következőt fogja okozni: végtelen alkalmazásbetöltési idők, hosszú rendszerindítási idők és gyakori összeomlások Ideiglenes fájlok írásakor. Azok a virtuális gépek, amelyek lassú merevlemezeken vagy túlterhelt tárolótömbökben tárolják a lemezeiket, sokkal jobban észreveszik a virtualizációs büntetést.

Végül, a felhalmozott lemezpillanatképek (például több láncolt delta VMDK a VMware-ben) olvasási/írási terhelést jelentenek, mivel az adatok több fájlban vannak elosztva. A régi pillanatképek hosszú távú megőrzése biztonságos módja annak, hogy... rontja az összes érintett virtuális gép teljesítményét.

Gyakorlati tanácsok a virtuális gépek grafikus (és általános) teljesítményének javításához

Ahhoz, hogy a lehető legtöbbet hozhassuk ki a rendelkezésre álló hardverből, és a virtuális gép élményét közelebb hozzuk egy átlagos fizikai számítógép élményéhez, érdemes figyelembe venni néhány gyakorlati ajánlást:

• Megfelelő méretű CPU és memória. Ne fogyasszunk elég vCPU-t vagy RAM-ot, de ne növeljük túl a magokat és a memóriát sem „csak a biztonság kedvéért”. A túl sok vCPU-val rendelkező virtuális gépek együttes leállítási és ütemezési problémákat okozhatnak, ami a teljesítmény javítása helyett rontja azt.
• Használj gyors tárhelyet. Az SSD, NVMe vagy hálózati tárolók megfelelő IOPS-szal drasztikusan csökkentik a rendszerindítási és alkalmazásbetöltési időt, ami viszont simább érzetet kelt az asztali környezetben.
• Tartsa naprakészen az illesztőprogramokat és az integrációs eszközöket. Kereskedelmi hipervizorokon a VMware Tools, vGPU illesztőprogramok és hasonló szoftverek telepítése javítja az egérkezelést, a dinamikus felbontásokat és a grafikus gyorsítást. KVM/Proxmoxon a Virtio illesztőprogramok és vendégügynökök használata optimalizálja a gazdagép-virtuális gép kommunikációt.
• Kerüld a redundáns virtualizációs rétegeket. A KVM egy másik hipervizoron belüli futtatása (vagy a Hyper-V tetején lévő VMware stb.) több terhelést okoz, és jelentősen csökkentheti a teljesítményt.

Az erőforrásokat a gazdagépről is célszerű figyelni, nem csak a virtuális gépen belülről. Ilyen eszközök például a esxtop Az ESXi-ben a vCenter fejlett irányítópultjai, vagy a Proxmox és az RHEL KVM-metrikái lehetővé teszik, hogy lásd, mennyi CPU-t, RAM-ot, lemezt és hálózatot fogyaszt az egyes virtuális gépek, és időben észleld a „zajos” virtuális gépeket, amelyek rontják a többiek élményét.

Összességében a modern virtuális gépek grafikus teljesítménye számos tényező együttes hatásának eredménye: a Virtio-GPU, a VirGL, az átviteli vagy vGPU technológiák, például az SR-IOV vagy az Intel GVT-g közötti választástól kezdve a tároló típusán, a CPU és a memória túlterhelésén át az alapul szolgáló hálózat minőségéig. Amikor minden megfelelően van hangolva, a virtuális gépek a mindennapi használat során a fizikai számítógépekhez nagyon hasonló asztali élményt tudnak nyújtani.bare metal szervereket és dedikált GPU-kat tart fenn azokhoz a kivételes munkaterhelésekhez, ahol minden milliszekundum és minden képkocka másodpercenként valóban számít.

Kapcsolódó cikk:

Éles üzemre kész virtuális gépek? Stabilitás, teljesítmény és mikor érdemes őket választani

Izsák

Szenvedélyes író a bájtok és általában a technológia világáról. Szeretem megosztani tudásomat írásban, és ezt fogom tenni ebben a blogban, megmutatom a legérdekesebb dolgokat a kütyükről, szoftverekről, hardverekről, technológiai trendekről stb. Célom, hogy egyszerű és szórakoztató módon segítsek eligazodni a digitális világban.