VMware Workstation Shifting From Proprietary Code To Using Upstream KVM

Virtualizáció

https://www.phoronix.com/news/VMware-Workstation-KVM

es akkor milyen elonye lesz a vmware workstation-nek?

csak a gui?

( elod v | 2024. 11. 01., p – 17:24 )

Az égvilágon semmi előnye, ezt is kinyírják mint a többit is (idővel).

( Vamp | 2024. 11. 04., h – 18:49 )

Szerkesztve: 2024. 11. 04., h – 18:49

Update: Broadcom would like to clarify that while using KVM for the CPU virtualization, they will continue to rely on all of the existing VMware virtual devices for graphics and other functionality. Also on both macOS and Windows they have migrated to the native CPU virtualization frameworks.

 

Szoval win alatt meg kb egy Hyper-V GUI lesz....

 

 

Amúgy amit beidéztél az pont azt jelenti, hogy nem egy hyper-v gui. Pontosan úgy ahogy Linuxon a KVM != qemu-kvm.

Csak a CPU virtualizáláshoz szűkséges kernel módú trap-and-emulate funkcióról van szó, ami kb alig több, mint egy wrapper a  VT-x vagy az AMD-V utasításkészlethez.

Az összes periféria emulálás, image kezelés, snapshotolás, fejlesztő/debug/trace funkciók, API-k stb. GUI-ig bezárólag továbbra is a userspace alkalmazás dolga.

Nem sok dolog változik, csak nem kell proprietary kernelmodult forgatni vmware-hez, hanem (remélhetőleg) out of the box menni fog.

Rég volt már, amikor a vmware saját binary translationt használt és ez lényegi minőségi különbség volt köztük és a többi virtualizációs szoftver között.

Régóta vágyok én, az androidok mezonkincsére már!

Maguk a függvények/rendszerhívások elég vékonyak. Nem csinálnak sokmindent, a legtöbb kb 1-2 paraméter ellenőrzés esetleg atomic lock után 1db műveletből áll. Csak sokféle van belőlük. Főleg a memória-menedzsment miatt. A nested page table támogatás már egy utólagos ráépítés a VT-x/AMD-V-re, szóval gyakorlatilag megvannak az mmu funkciók CPU-ból natívan támogatott, illetve a host kernelnek magának kell csinálnia esetre is. Ez utóbbi kódsorban sok, de modern processzorokban gyakorlatilag már nem játszik.

Egyébként kb azóta lett tényleg gyors a hardveres virtualizáció, hogy a nested page table támogatás bejött. Azelőtt a VMware binary translation megverte a hardverest sebességben.

A másik, hogy az iommu (pci passthru, sr-iov dolgok, VT-d) miatt sok 'device' életciklus kezelő függvény is van, ami perifériákkal foglalkozik. Normál esetben ezzel a kernelnek nincs különösebb dolga (mindössze trappelni kell io read/write-ot, és egy az egyben továbbítani a hívást a userspace virtualizáló alkalmazásba). A bonyolult része ennek a passthru esetben játszik.

EDIT:
Amúgy ha, mindenképpen árnyalni akarunk:

Intel® 64 and IA-32 Architectures Software Developer’s Manual
Volume 3C: System Programming Guide, Part 3
(az Intel VMX, vagy brand néven VT-x fejlesztői dokumentációja)
316 oldal

Intel® Virtualization Technology for Directed I/O Architecture Specification
(az Intel IOMMU, brand néven VT-d fejlesztői dokumentációja)
354 oldal

És nincs egyik sincs bő lére eresztve, kb a doksi fele tömény regiszter és adatstruktúra specifikáció. Ehhez képest szerintem egyáltalán nem nagy a core KVM + Intel virtualizáció + AMD virtualizációt támogató kód mérete.

Régóta vágyok én, az androidok mezonkincsére már!

( Raynes v | 2024. 11. 04., h – 22:01 )

Ez jó hír, ezek szerint megunták, hogy a kernelváltozásokat lekövessék minden OS-en, így nagyban megkönnyítik a saját dolgukat is, meg mindenkiét. Bár a Hyper-V egy okádék, szóval windows-osoknak lehet ez rossz hír, bár a Win egy annyira rossz platform máris, hogy ez lesz a legkisebb gondjuk, hogy a VMware Hyper-V-t használ.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Ezt hallottam másoktól is. Az IO virtualizációja állítólag nagyon lassú.

Nekem konkrét bajom inkább a Hyper-V managerrel volt. Tudott olyat, hogy leszakadt egy-egy hypervisor a management szerverről és úgymaradt, de ezt a GUI-n semmi nem jelzi. Az infrát üzemeltető ops-os kolléga azt hiszi a scheduled maintenance előtt, hogy az a gép már teljesen evakuálva van, leállítja. Nálam meg csörög az alert, 3 aktív prod szerverünknek viszlát...

Tetézte, hogy a hyper-v server az anti-affinity szabályokat is csak amolyan ajánlás-félének tekintette. Simán előfordult, hogy HA failover-párjaink ugyanazon a hypervisoron futottak. Az előző hibával kombinálva ez nem egyszer szerzett kellemes oncall-perceket nekem. :)

A "megoldás" az lett, hogy én guest-ekből hv_kvp_daemonnal elkezdtem monitorozni, hogy melyik gépünk melyik fizikai hoston van és előre alerteltünk magunknak, ha valamelyik gép rossz helyre került. Utána öröm volt győzködni az infrás ops-ost, hogy higgye el, hogy hv_kvp alapján én tudom jobban, hogy a VM-ünk hol fut, az ő management UI-a hazudik.

Régóta vágyok én, az androidok mezonkincsére már!

én guest-ekből hv_kvp_daemonnal elkezdtem monitorozni, hogy melyik gépünk melyik fizikai hoston van

/facepalm... Ötletes megoldás a nyűgre, de jól mutatja az érintett management app kudarcát. Ideális esetben a guest nem is tudhatja, hogy virtualizáltan fut (ezen persze a teljesítmény kedvéért sokat enyhítünk paravirt driver-ekkel stb), de "belülről felügyelni" a host-okat, na az egy 180 fokos fordulat az eredeti célhoz képest.

> Ideális esetben a guest nem is tudhatja, hogy virtualizáltan fut

Mutatsz is ilyen idealizált esetet a gyakorlatban? Én speciel most ezt tudom csinálni:

FreeBSD_VM$ dmesg | fgrep Hypervisor

Hypervisor: Origin = "KVMKVMKVM"

FreeBSD_VM$ sysctl -d kern.vm_guest

kern.vm_guest: Virtual machine guest detected?

FreeBSD_VM$ sysctl kern.vm_guest

kern.vm_guest: kvm

99% eséllyel mondom, hogy a KVM-en kívül a Xen-t, a VBox-ot, a HyperV-t és szerintem a VMware-t is detektálja - de olyanom most nincs kéznél.

Arról nem beszélve, hogy a háttértárak tipus neve, a virtualizált hálózati interfészek gyártója / FW-verziója / stb. mind árulkodóak. És igen, ezek pl. sok esetben valóban "hamisíthatóak" (*), de tegye fel a kezét, aki már automatikusan minden ilyen infót hamisítottan ad át a VM-jeinek. (*)

Mondjuk az érdekelne, hogy amennyiben valamelyik host-ot felismeri, akkor az adott szoftverben van-e ez ellen valami *valóban* működő ellenlépés.

(*) kicsit olyan ez, mint volt millió éve az nslookup -cl=CH -ty=TXT version.bind . Hasznosnak tűnt elrejteni / hamisítani, de igazából az security by/through obscurity, sokkal hasznosabb napra késznek lenni peccseléssel és körbebástyázni a szolgáltatásokat.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Egy (részleges) példa: az NVIDIA consumer videokártyáinak Windows VM-hez rendelése (GPU assignment)  QEMU/KVM alatt. Ez mind hardveres, mind szoftveres szempontból teljesen jól tud menni (ha az alaplap megfelelő iommu group-okat tud kialakítani, és a kártya a megfelelő slot-ban van), csak az NVIDIA nem akarja, hogy a consumer kártyáikat ilyen célra használják. Azt akarják, hogy vedd meg a nagyon drága professzionális kártyát (amire mondjuk egy Windows-os FPS játékhoz nyilván nincs szüksége az embernek). A Windows guest-ben futó NVIDIA driver és a QEMU/KVM között mintegy "fegyverkezési verseny" volt (van?); a driver fel akarja ismerni, hogy VM-en fut, és megtagadni a működést, a QEMU/KVM user meg nyilván el akarja rejteni ezt a tényt, mert használni akarja a kártyát a VM-ben. Emiatt van, aki régebbi verziójú NVIDIA drivert futtat (nem frissít a VM-ben), mert az még kevésbé firtatja, hogy min fut.

csak indulaskor, vagy uzem kozben is?

mert azt neztem, hogy egy xen pvh guest kb 4s mire ujraindul, egy xen hvm quest 12s (a loading kernel es a loading initrd tunik nekem soknak), egy kvm qemu guest pedig kb 6s (a loading kernel es a loading initramfs csak felvillan) mindegyik esetben 1s van beallitva a grubban

neked aztan fura humorod van...

Mindkettőnél. Szabvány desktop virtuális gépeket próbáltam, alap beállításokon, elég RAM/CPU erőforrást adva, Win10-et és Linuxot guestként, mindkettő sokkal lomhábban futott Hyper-V alatt, ugyanazon a gépen, mint windowsos VMware Playerben vagy Linux alatt qemu-kvm-mel, azonos VM beállításokkal. Ahogy írod is, kb. 3× lassabban, de még működés közben is lehetett érezni, hogy itt-ott lagol a VM, sőt, még akkor is lagolt magának a Hyper-V-nek a GUI-ja, mikor nem is futott VM. Az is igaz, hogy ez volt vagy 4 éve, nem kizárt, hogy valamit javultak teljesítményügyileg, de nem nyerték el a bizalmam, az biztos. Ehhez képest a VMware teljesítménye azért sokkal jobb volt Windowson. Vagyis volt. Így el is hiszem, hogy vannak, akik anyáznak ezért a döntésért, de szerintem ez akkor is pozitív, ösztönözheti a MS-tot, hogy tegye rendbe a teljesítményt ezen a téren is.

Linux alatt viszont mindenképp pozitív lesz. A KVM-et szétoptimalizálták a fejlesztők, és így legalább nem kell a VMware miatt minden egyes kernelfrissítés után kernelmodulokat forgatni, meg kevesebb lesz az összeakadás.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Régebben használtam, de úgy emlékszem az usb átadás nem volt benne. Ez ma már működik? Mostanában nem nézegettem.

Virtualbox-ot használtam szinte mindenhol, ahol kellett asztali virtualizáció. Ill. most, hogy a Vmware workstation elérhető, éppen az van telepítve, gondoltam kipróbálom.