Dotaz: Akcelerace videa a USB přístup ve Virtualboxu

[Platonix]

Plánujeme v práci pořídit pracovní stanici na 3D grafiku a fyzikální výpočty. Z různých důvodů jsme se rozhodli pro Linux jako základní operační systém. Některý software, ale vyžaduje Windows. Moje otázka: Máte někdo zkušenosti s virtualizací Windows pomocí například Virtualboxu tak,

1. aby podporovala hardwarovou akceleraci videa ve virtualizovaném systému a
2. zároveň umožňovala virtualizovanému systému používat USB hardwarové klíče (software je používá na ověření své licence)?

Díky moc.

Odpovědi

[MadCatX]

S USB klíči bych neviděl problém, VirtualBox i QEmu umějí USB passthrough. S akcelerací videa, pokud se myslí HW dekódování, to bude horší a jediný způsob, který mě napadá je dát hostovi samostatné GPU.

[Platonix]

Díky moc za info. Máme program pro zpracování dat z LIDARu, který potřebuje Windows (wine nezabral :() a zároveň OpenGL pro zobrazování dat. Předpokládám, že vyžaduje přímý přístup na grafickou kartu, aby vykresloval ta data. Softwarové renderování bude pomalé. Je šance to rozjet ve Virtualboxu? Co myslíš tím "samostatné GPU"?

[PetebLazar]

Samostatnou GK se nejspíše míní virtualizace typicky KVM/QEMU s PCI passthrough (v případě dnešní GK tedy PCIe passthrough). Jedná se využití technologie IOMMU(AMD-Vi,VT-d), která umožní v rámci HostOSu izolaci určitých technických prostředků (např. GK) a jejich svěření GuestOSu. Virtualizovaný OS ji vidí jako další HW, který může využít prostřednictvím běžných ovladačů.

Pozn. Nvidia standardně blokuje běh ovladačů ve virtuálním prostředí u řady Geforce (nechvalně známá chyba Error 43), což se obchází zablokováním detekce virtualizace ze strany GuestOSu.

VirtualBox asi disponuje nějakým překladem, ale na přílišnou kompatibilitu a vysoký výkon bych si nevsadil.

U Virtualboxu si nejsem jist zda jeho GPL verze není omezena na USB1.x, vyšší verze USB jsou snad součástí placeného ExtensionPacku (100 licencí minimum?).

[Platonix]

Díky za informace. Nejsem nějak fixovaný na Virtualbox, jen mě tak napadnul. Co v zásadě potřebuju, je ten passthrough pro USB hardwarový klíč, aby ho virtualizovaný systém viděl a licencovaný software byl ochoten se spustit. Zároveň nějaký rozumný výkon grafiky ve virtualizovaném systému, aby byl schopen zobrazovat 3D modely. Je něco lepšího na to než ten Virtualbox?

[MadCatX]

O USB dongly bych strach neměl, na to postačí USB passthrough. VirtualBox poskytuje jakousi primitivní formu 3D „akcelerace“, je to ale vhodné hlavně pro programy, co se bez nějaké podpory HW 3D prostě vůbec nespustí. Moc spolehlivě mi to nikdy nefungovalo a výkon to má mizerný. Na linuxovém guestu to umí tuším nejvíc OpenGL 2.1, jak je to na Win s D3D jsem nezjišťoval. V rámci QEmu existuje projekt Virgil, který virtualizuje GPU i s HW akcelerací, pro kterou se pak používá GPU hostitele, vyžaduje to ale poslední verze jádra i QEmu a podpora ve Windows asi nebude nic moc.

Jestli v tom stroji bude sdílené i dedikované GPU, bude nejjednodušší přes VGA passthrough vždycky „půjčit“ to dedikované GPU virtuálnímu stroji, když to bude potřeba. No a nebo mít na železe Windows a virtualizovat Linux.

[PetebLazar]

Pokud by snad došlo na GPU passthrough, pak aspoň za sebe doporučuji dokumentaci k problematice na wiki ArchLinuxu (i jako uživateli Xubuntu mi přišla asi nejaktuálnější/nejzevrubnější).

Pro integraci výstupu GuestOSu(standardně se pro zobrazení GuestOSu využívá výstup ze "svěřené" karty na další monitor) na monitor HostOSu(Linux) je tu zajímavý projekt Looking Glass (využívající techniky přenosu framebufferu mezi GuestOSem a HostOSem).

[PetebLazar]

Vypadl mi odkaz https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF.

[LarryL]

Stručný přehled grafické akcelerace: https://wiki.archlinux.org/index.php/QEMU/Guest_graphics_acceleration

Pokud je tvoje pracovní stanice desktop a máš dvě grafické karty jak je nejlepší "PCI GPU/VGA passthrough" co ti tady již poradili. U notebooku budeš mít asi problém. V podstatě to jde i s jednou graf. kartou, ale je to nepraktické, protože když ji přiřadíš Windowsu, tak přijdeš o grafický výstup z Linuxu, který se ti objeví zase až virtuálku Win vypneš.

Další schůdná varianta co tady nepadla je iGVT-g, pokud máš procesor Intel. Tím rozdělíš grafické jádro Intelu na více virtuálních a jedno z nich přiřadíš virtuálce windowsu. Výkon samozřejmě nic moc (přece jen je to integrovaná grafika), ale je to pořád lepší než buil-in virtuální akcelerace ve Virtualboxu.

Ohledně toho Virgl/Virgil3d, co tady již taky padlo, dost pochybuji. Pro Linux to je použitelné, ale co vím, tak pro hosty Windowsu je to pořád v experimentální fázi.

[Peter Golis]

Len pre info. Jedná sa o HW na ktorom bude bežať Linux ako Hypervízor v ktorom bude jediná VM s Windows v ktorej sa budú vykonávať náročné výpočty na GPU pomocou SW ktorý je chránený pomocou tokenov do USB?

[LarryL]

Ano, tak jsme to pochopili. Pokud píšeš "náročné výpočty" tak to zdaleka nejlepší řešení je ten "VGA passthrough", někdy také nazýván "PCI passthrough" nebo "GPU passthrough". S tímto řešením se dostaneš ve virtuálce k téměř nativnímu 3D výkonu. Udávaný pokles výkonu je do 5%. Běžně se tak na Linuxu hrají áčkové Win hry - https://www.youtube.com/watch?v=37D2bRsthfI (dva monitory nejsou nutnost).

---

Pokud si ten SW neověřuje i jiné části HW a nezkoumá jestli neběží ve VM, tak bude fungovat "USB passthrough". Tam se nic složitého nenastavuje. V Qemu se používá příkaz:

-device usb-host,...

Cituji z dokumentace:

usb-host,hostbus=bus,hostaddr=addr

Pass through the host device identified by bus and addr

usb-host,vendorid=vendor,productid=product

Pass through the host device identified by vendor and product ID

Běžně se tímto způsobem předává třeba USB myš a klávesnice z hostitele do virtuálky kvůli dosažení co nejnižší latence. Je také možnost do virtuálky předat celý USB řadič (což je ten prve uvedený "PCI passthrough", protože předáváš celé PCI zařízení), tam už ale záleží na IOMMU Groups, což závisí od HW, který máš. Doporučuji pročíst odkaz na Archlinuxu, což je asi nejlepší dokumentace co k tomu na netu najdeš.

[PetebLazar]

Napriklad Davinci Resolve Studio je silne GPGPU-orientovanou ulohou (akcelerace dekodovani Blackmagic-RAW a color gradingu klidne spolykaji 80% vykonu 1080Ti), pres vyse zminene USB passthrough si je schopno ve VM(v tomto pripade Xubuntu pod KVM/QEMU/GPU_passthrough) sahnout na HW USB licencni klic Bus 004 Device 002: ID 096e:0201 Feitian Technologies, Inc..

[Peter Golis]

Pretože pokiaľ je hlavným programom nejaká predražená aplikácia pre Windows schovávaná do VM, tak sa touto cestou neušetrí nič. Cena za OS a jeho zabezpečenie je len mizivým zlomkom oproti cene za aplikáciu ktorá sa overuje oproti USB tokenu. Teda, ak sa tu nemihne aj otázka ako nazdieľať ten jediný token po sieti medzi ostatné pracovné stanice (fujki).

[PetebLazar]

Mě to příjde, že řada aplikací v jejich oboru je vyvíjena v prostředí Linuxu (proto možná ten Linux na HostOSu) a jedna věcí (zmíněný LIDAR) má podporu ve Windows. Ze světa zpracování genetických informací mám zas dojem jako by neexistovalo nic jiného než Python.

[Peter Golis]

Možno to bude divné, ale z môjho pohľadu by som nechal primárny OS ten z Redmondu, a Linux by som dal do headless VM. Tým sa zabezpečí matrica podpory aj s priamym prístupom na HW.

Tá voľba s Linuxom ako primárnym OS je síce pekná, ale stavia prekážku medzi HW a nosnou aplikáciou. Z pohľadu geeka len symbolickú, ale z pohľadu technickej podpory ku tomu komerčnému produktu môže byť tá prekážka zásadnou.

[PetebLazar]

Z úvodního příspěvku není zřejmé nakolik je Linuxová část řešení závislá na přístupu k HW(specializovanému), můžeme se jen dohadovat. Případně zda je Linux primární/cílovou platformou projektu (či vzniklého řešení).

Nedávno jsme pro výpočetní node zvolili také obrácený gard (Windows jako HostOS, výpočetní node(y) VM ve VirtualBoxu). Důvodem byla podpora zařízení pro získávání dat pouze ve Windows (popravdě než došlo od samotného návrhu k vlastní realizaci node, dodavatel zařízení rozšířil podporu i na Linux). To se nakonec může stát i v tomto případě.

[Peter Golis]

A to je dôvod prečo som môj úvodný príspevok zavesil na pôvodnú otázku. A tiež nechápem prečo mi odpovedali ľudia ktorý o reálnej situácii nevedia nič, len odhadujú jeho pohnútky.

[PetebLazar]

To patrně nastalo proto, že Vaše skladba věty vypadá spíše jako konstatování stavu a ne jako otázka (jíž je díky otazníku na konci). Taky "Len pro info." v úplném úvodu příspěvku správnému pochopení zrovna nepomáhá.

[Peter Golis]

Veta končiaca otáznikom nevypadá ako konštatovanie. A nezdá sa mi že by tie odpovede od náhodných okoloidúcich boli odpoveďami na konštatovanie.

Ale to je jedno. Z môjho pohľadu sa jedná snahu zmeny konceptu ktorá bude mať za následok problém s technickou podporou daného komerčného SW. A chcel som sa uistiť či si to zadávateľ témy uvedomuje, alebo si len chce zarobiť na prekvapenie v budúcnosti.

[k3dAR]

tazatel jasne pise 2 veci:

1. Z různých důvodů jsme se rozhodli pro Linux jako základní operační systém.
2. Některý software, ale vyžaduje Windows

takze tva rada nahodneho kolemjdouciho, co si ani neprecetl dotaz, kdyz radis pouzit jako zakladni Windows je proste mimo...
neni na tom nic divneho, pouzit Windows ve virtualu pro par SW z nichz 1 pozaduje HW klic, prodratovat USB do virtualu je otazka jednoho kliknuti, zda si SW nebude stezovat je otazka nasledneho overeni v praxi tazatelem...

[Peter Golis]

Naozaj? Povedz mi o tom niečo ďalšie. Ale pred tým sa skús zamyslieť.

PS: Nevedel som že záruka na SW končí tam, kde sa SW sťažuje. Tam by sa práve mala začínať, ak je zmluva platná a prostredie podporované.

[k3dAR]

v pozadavku bude OS Windows a minimalni HW konfigurace, pochybuju ze vis ze by dodatavatel toho SW mel v pozadavku fyzicky HW. Kazdopadne sni dal o sve premyslive vyjimecnosti

[Peter Golis]

Asi si ešte nemal v ruke komerčný SW ku ktorému je podpora.

Ale vidím, že sa tu snažia reagovať ľudia s príspevkami ako z ihc pohľadu pochopili otázku. A je ich stále viac.

[k3dAR]

mam pro tebe dobrou zpravu, drzis prvni misto v tom jak nepochopit dotaz, radit neco co s dotazem nesouvisi a pokladat otazky na zaklade informaci co sis vycucal z prstu, hura jsi jednicka

[PetebLazar]

Nestačí mít jen dobré příklady(vzory) co se jim chceme přiblížit. Musíme mít i takové, co nás ukáží čeho se zdaleka vyvarovat.

[LarryL]

Vidím, že se to tady během dne pěkně rozjelo. Jak správně napsal PetebLazar, to tvoje "Len pro info." bylo trochu matoucí. Nevěděl jsem jestli patříš k tazateli a upřesňuješ otázku nebo řešíš podobný problém jako tazatel a nebyly ti jasné předchozí odpovědi. Stačilo stručně napsal, že máš obavy, že při takovém řešení o které se pokouší tazatel hrozí komplikace kvůli podpoře ze strany dodavatele SW, který má běžet ve VM. Co vím, tak pár hráčů hlásilo problémy při hraní ve VM kvůli vyhodnocení anti-cheatovacího programu a daly by se spočítat na prstech jedné ruky. Problémy se SW kvůli tomu, že běží ve VM si teď nevybavuji. Pokud o nějakém problematickém SW víte, klidně hoďte odkaz, rád se něco nového dozvím.

Taky jsem moc nepochopil jak jsi psal "tak sa touto cestou neušetrí nič". Tazatel nepíše nic o tom, že by cílem bylo ušetřit. Z nějakého důvodu chce Linux jako primární OS a pokud se nechystá sdílet USB token mezi více stanic a pirátit SW (jak jsi naznačoval), tak na nabízeném řešení pomocí VGA passthrough nevidím nic špatného. Podporu-nepodporu ze strany dodavatele SW si musí tazatel zvážit sám.

[Peter Golis]

Podporu-nepodporu ze strany dodavatele SW si musí tazatel zvážit sám.

Na to som narážal. Aby sa mu náhodou nestalo že mu akúkoľvek reklamáciu toho SW odmietnu s tým, že mu to beží vo VM a nie priamo na železe. Je vedľajšie že mu to môže fungovať a výkon nebude moc obmedzený.

[1john2]

Technologicky off-topic, ale je to problem se SW ve VM:

Nextcloud ve Windows 10 virtualizovanych pomoci Hyper-v chcipne okamzite po startu :)

Nezalezi, jestli ho pustim pres RDP nebo v konzoli.

Technicke detaily - budou pozdeji, je to cerstvy problem ze vcerejsiho vecera.

V eventvwr je skaredy crash event.

[LarryL]

Otázka je jestli to padání bylo opravdu zapříčiněno tím, že je SW uvnitř VM. Třeba u Qemu se dá použít typ stroje Q35, který vychází z fyzického HW od Intelu. Pokud daný SW nemá nějakou speciální fci, která schválně znemožňuje spuštění pod VM (např. ty anti-cheatovací fce), tak by neměl být problém. Jediné co si teď vybavuji, tak se mi stalo, že když jsem měřil výkon na 3DMarku ve VM, tak test sice proběhl normálně, ale jen výjimečně mi to dovolilo výsledek zveřejnit online. Možná taky nějaká obdoba anti-cheatovacích testů zda jsem test nepovrhl. Na druhou stranu se mi to občas stalo i na železe. Teď jsem to ze zvědavosti zkusil ve VM a jako důvod nezveřejnění online to napsalo:

Your score was invalid for the following reasons - Result already present in 3DMark.com database, cannot upload result twice. Click the link above to see the result.; (problemId:89608409)

Mám dojem, že minule to psalo jinou hlášku, tak nevím co si o tom myslet.

[dustin]

Pro Fusion 360 na Win (vyžaduje OpenGL) jsem musel použít vmware player, jinak se fusion odmítlo instalovat s chybou o chybějící HW akceleraci. Běží jakž takž (TP x220, interní HD3000 ve starém i5).