VirtualBox zeer traag op surface laptop 4

[faziolifairmont]

Mijn vraag
...
De surface laptop 4 heeft problemen met VirtualBox. De bootscreens duren minuten lang en lopen steeds vast. Als de machine eenmaal draait is het ontzettend traag. Windows installeren duurt uren, en geeft soms zelfs een error voordat het klaar was.

Relevante software en hardware die ik gebruik

...
VirtualBox
Windows 11 client, windows 11 host
Surface laptop 4

Wat ik al gevonden of geprobeerd heb
...
Ik heb geprobeerd de virtuele harddrive op een andere schijf te zetten, maakte ook geen verschil. Zolang de surface laptop de host is, draait de VM verschrikkelijk.

De laptop heeft 16GB ram, en een 2.2 GB/s SSD. Dat zou toch genoeg moeten zijn.

in taakbeheer wordt de cpu voor 60-70% gebruikt door virtualbox. Terwijl het een i7-1185G7 betreft.

[Voor 13% gewijzigd door faziolifairmont op 20-02-2022 17:52]

[Nielson]

Niet toevallig W11 Pro op de laptop staan? Dan zou je eventueel ook Hyper-V kunnen proberen.

[MAX3400]

Welle errors komen er dan?
Wat had je zelf al gevonden / geprobeerd?
Waarom post je niet ook "gewoon" de exacte specs van de machine?
Hoe is de BIOS ingesteld voor virtualisatie?
Zijn je drivers up to date?
TPM is niet ondersteund nog? Hoe installeer je je guest Win 11 dan?

[Voor 14% gewijzigd door MAX3400 op 20-02-2022 18:00]

[faziolifairmont]

hyper-V is ene type 1 virtualisatie, en dat virtualiseert mijn host OS. en dat wil ik niet. De prestatieverlies is zeker niet unnoticable.

Virtualbox is overigens ook wat meer portable. Ik sleep nog wel eens een VM tussen computers.

Taakbeheer geeft aan dat virtualisatie is ingeschakeld.

De drivers zijn up to date.

Ik heb de exacte specs niet gepost, omdat er maar 1 surface laptop 4 bestaat met de i71185g7.

[eric.1]

in taakbeheer wordt de cpu voor 60-70% gebruikt door virtualbox. Terwijl het een i7-1185G7 betreft.

Je CPU is een quad-core met multithreading, zijn alle cores voor 60-70% in gebruik? Of zit 1 core op 100% terwijl de rest niets doet, om maar wat te noemen?

Verder kan je ook eens een simpele linux distributie proberen. Dan sluit je i.i.g. de virtuele windows machine uit.


Anders moet je wel wat meer diagnostische gegevens proberen te achterhalen, het is wel karigjes zo. Heb je bijvoorbeeld de Guest Addition Tools geïnstalleerd? Hoeveel CPU cores heb je toegewezen aan de VM, hoeveel geheugen, etc? En dan, hoeveel van het geheugen is in gebruik op je host, welke temperatuur is je CPU, kan je wat in de logboeken van de host achterhalen?

[Voor 5% gewijzigd door eric.1 op 20-02-2022 18:12]

[jeroen3]

Hyper-v en virtualbox zijn incompatible met elkaar. Als je hyper-v (of wsl) hebt geinstalleerd gaat virtualbox in emulatiemodus. Supertraag. Te herkennen aan een schildpad symbool in de balk onderin.

[faziolifairmont]

De virtuele machine laat zijn gebreken zien voordat de guest OS is geladen. Je mag blij zijn als de windows of Linux installer zo ver komt dat hij zijn installatie cyclus begint. Maar uiteindelijk duurt het zo lang dat ik de VM maar gewoon kill. Na 2 uur is de lol er ook wel vanaf, als hij dan nog op 11% install zit.

Interessant over die schildpad. Er staat bij mij een groene schildpad met een V erin.

Ik heb gekeken maar Hyper-V is niet geinstalleerd.

[MAX3400]

faziolifairmont schreef op zondag 20 februari 2022 @ 18:08:
hyper-V is ene type 1 virtualisatie, en dat virtualiseert mijn host OS.

Dan begrijp je de termen dus niet. En als je de termen niet snapt, waarom kies je dan voor VirtualBox?

Type-2 is per definitie langzamer dan Type-1.

[faziolifairmont]

nee type 1 virtualeert de HOST OS. dat wil zeggen dat de prestaties van de host OS langzamer worden. En dat verschil is groot. de prestaties van de gast OS intereseert me niet zo

[jeroen3]

faziolifairmont schreef op zondag 20 februari 2022 @ 18:16:
Interessant over die schildpad. Er staat bij mij een groene schildpad met een V erin.

Dat betekent dat de vt-x niet beschikbaar is. Of dus niet actief, of al bezet met een andere hypervisor.

[HKLM_]

faziolifairmont schreef op zondag 20 februari 2022 @ 19:07:
nee type 1 virtualeert de HOST OS. dat wil zeggen dat de prestaties van de host OS langzamer worden. En dat verschil is groot. de prestaties van de gast OS intereseert me niet zo

Ga je nog maar eens verdiepen https://searchservervirtu...-1-and-Type-2-hypervisors

the presence of an underlying OS with Type 2 hypervisors introduces unavoidable latency;

[Voor 27% gewijzigd door HKLM_ op 20-02-2022 19:25]

[faziolifairmont]

nee je hebt het echt zelf verkeerd.

daarmee bedoelen ze latency in de gast OS

type 1, maakt de host OS ook een VM. en dus heb je prestatieverlies in je host OS.

het gaat mij om de prestaties van het host OS, en totaal niet om de prestaties van de gast OS. ik gebruik zelden een VM.

[MAX3400]

faziolifairmont schreef op zondag 20 februari 2022 @ 19:25:
type 1, maakt de host OS ook een VM.

NEE!

[Voor 11% gewijzigd door MAX3400 op 20-02-2022 19:27]

[HKLM_]

faziolifairmont schreef op zondag 20 februari 2022 @ 19:25:
nee je hebt het echt zelf verkeerd.

daarmee bedoelen ze latency in de gast OS

type 1, maakt de host OS ook een VM. en dus heb je prestatieverlies in je host OS.

het gaat mij om de prestaties van het host OS, en totaal niet om de prestaties van de gast OS. ik gebruik zelden een VM.

No way man je hebt bij je type 2 juist prestatie verlies en niet bij een Type 1 denk je echt dat je bij type 1 prestatie verlies hebt? Waarom zij alle fatsoenlijke hypervisor dan type 1 en geen 2 (VMware vSphere, Microsoft Hyper-V, KVM, Xen hypervisor, Oracle VM, Citrix Hypervisor) Ook hyper-v onder Windows 10 of 11 is een Type1 en dat is juist een voordeel tegenover bijvoorbeeld Virtualbox welke een Type 2 is.

[Voor 8% gewijzigd door HKLM_ op 20-02-2022 19:32]

[faziolifairmont]

Je komt een beetje dom over.

Voor alle duidelijkheid:

Hyper-V maakt de host OS een VM. Ja.

met that out of the way:

Sterker nog bij type 1, is er geen host OS (je primary windows installatie), Dat wil zeggen dat je prestatieverlies hebt. Je primaire windows installatie is nu een Quest OS op de hypervisor. Met name in games, een goede 20 fps verlies zelfs.

daarnaast maakt het type de virtualiser niet 'fatsoenlijk'. Ze hebben beide totaal andere doeleinden. En grofweg de meeste mensen halen de beste prestaties uit type 2. Alleen al omdat de Host OS er niet aan mag leiden, en vanwege dat vreselijke RDP remote protocol van Hyper-V. Dat maakt alles wat screen related is ongeschikt voor Hyper-V. Dus hyper-V is echt voor screenless machines in een datacenter.

Dus al zou je betere prestaties halen uit processor screenless gerelateerde dingen, dan is de prestatie winst in type 1 weer neglible. Processors zijn namelijk snel genoeg. En bij Hyper-V over het RDP protocol zijn videoprestaties echt problematisch. Dus van prestatiewinst kunnen maar weinig mensen spreken.

[NTAuthority]

jeroen3 schreef op zondag 20 februari 2022 @ 19:17:
[...]

Dat betekent dat de vt-x niet beschikbaar is. Of dus niet actief, of al bezet met een andere hypervisor.

... en ik vermoed bij deze dat het dus toch al de Windows-hypervisor is die sinds 11 in meer gevallen standaard aan staat. (op CPUs waar een specifieke instructieset - naam ben ik even kwijt - beschikbaar is waardoor er veel minder tot geen prestatieverlies optreedt met syscalls op de host/andere VMs)

VirtualBox is een beetje flauw en ondersteunt WHP (API voor de Windows-hypervisor vergelijkbaar met KVM op Linux) niet al te goed, en de ontwikkelaars (Oracle) hebben weinig zin dit op te lossen.

Als de performance op de host nu al prima is, zal dit niet slechter worden als je Hyper-V inschakelt, want je host-Windows draait nu ook al in deze hypervisor.

Ook in het 'videoprestaties'-verhaal herken ik je niet, velen kunnen zelfs games draaien met 60+ FPS met GPU-PV via vmconnect/RDP over VMBus.

[Voor 33% gewijzigd door NTAuthority op 20-02-2022 21:57]

[MAX3400]

faziolifairmont schreef op zondag 20 februari 2022 @ 21:41:
Je komt een beetje dom over.

Voor alle duidelijkheid:

Hyper-V maakt de host OS een VM. Ja.

Nee. En als dat wel zo is, doe maar even een linkje posten naar een Microsoft artikel of VMware artikel waar dat letterlijk staat. Ik zal misschien wat kortaf klinken maar ik ontwerp, bouw & beheer clusters van zowel Hyper-V (gebaseerd op Server 2016) en VMware (gebaseerd op de laatste 6.7 release).

Het host OS, geinstalleerd met DVD, USB, PXE wordt niet gevirtualiseerd!

Met name in games, een goede 20 fps verlies zelfs.

Omdat je games niet kan / wil virtualiseren. Er is geen out-of-the-box ondersteuning voor DirectX, OpenGL of andere hardware-accelerated mogelijkheden. Niet met type-1 en ook niet met type-2. Dat verandert zodra je bijvoorbeeld een Nvidia A16 in je host prikt en daarna de GPU-capabilities via passthrough aan een VM geeft.

daarnaast maakt het type de virtualiser niet 'fatsoenlijk'. Ze hebben beide totaal andere doeleinden.

Oh, vertel?

en vanwege dat vreselijke RDP remote protocol van Hyper-V. Dat maakt alles wat screen related is ongeschikt voor Hyper-V. Dus hyper-V is echt voor screenless machines in een datacenter.

Je bent echt los? Zoals ik hierboven postte, ik beheer nog wel eens wat. Op dit moment een kleine 600 VM's waarvan 100x Windows 10, 50 stuks "zware" CVAD Desktops voor 700 seats en de rest is fileservers, domain controllers, etc. En ik durf te zeggen dat 90% van al die VM's "gewoon" RDP praat.

RDP is een protocol voor het versturen van data. Hier zitten ook graphics bij inbegrepen. Dat Microsoft tot op heden het grafische gedeelte amper / niet optimaliseert, heeft niets te maken met "dan moet het maar headless zijn".



Maar je bent nogal stellig in jouw kennis, ervaring, types, inrichting, etc. Maar iets "simpels" als 1 Windows 11 VM op VirtualBox krijg je niet werkend ?

[NTAuthority]

MAX3400 schreef op zondag 20 februari 2022 @ 21:58:

Het host OS, geinstalleerd met DVD, USB, PXE wordt niet gevirtualiseerd!

Dit ligt iets genuanceerder - voor CPU-tijd is dit deels het geval, zie concept 'root partition' in Hyper-V of 'dom0' in Xen, maar de host heeft wel volledig en direct toegang tot alle hardware by default inclusief grote delen van de CPU (timers enz.).

Op moderne CPUs (Zen 2 en later, en redelijk recente Intel) is dit dusdanig geoptimaliseerd dat dit <1% prestatieverlies geeft, en ik neem aan zelfs <0.1%. De benchmarks waar TS vermoedelijk op doelt zijn voornamelijk 'edge cases' waarbij deze optimalisatie niet ondersteund of functioneel is, bijvoorbeeld door oude processors of UEFI-bugs. Dit is niet het geval op de SL4, omdat deze juist van MS zelf is, met hun eigen UEFI.

Dat verandert zodra je bijvoorbeeld een Nvidia A16 in je host prikt en daarna de GPU-capabilities via passthrough aan een VM geeft.

Ietsjes anders tegenwoordig, maar dit is niet officieel gedocumenteerd, GPU-PV is vooral voor interne producten van MS (Windows Sandbox, 10X, WSL graphics) en wordt - omdat MS het verplicht - ook ondersteund voor alle gangbare consumenten-GPUs met WDDM 2.7-driver of hoger.

RDP is een protocol voor het versturen van data. Hier zitten ook graphics bij inbegrepen. Dat Microsoft tot op heden het grafische gedeelte amper / niet optimaliseert

Over VMBus (voor lokale verbindingen) zit je toch niet met beperkte bandbreedte dus is het vooral buffer-copying voor lokale video en geen vreemde compressie/codering, en zelfs dat is nog iets sneller tegenwoordig (WSLg heeft CPU-side resource sharing, en voor GPU is in aanbouw).

Remote is tegenwoordig ook H.264-encoding (in hardware indien beschikbaar) maar dat doet nogal eens wat nukkig met lange vertraging tussen input->beeld.

---

@TS, probeer tenminste 'Windows Hypervisor Platform' eens aan te zetten in zowel Windows als VirtualBox als dat nog niet het geval is.

[Voor 21% gewijzigd door NTAuthority op 20-02-2022 22:17]

[MAX3400]

NTAuthority schreef op zondag 20 februari 2022 @ 22:03:
[...]


Dit ligt iets genuanceerder - voor CPU-tijd is dit deels het geval, zie 'root partition' in Hyper-V of 'dom0' in Xen, maar de host heeft wel volledig en direct toegang tot alle hardware by default inclusief grote delen van de CPU (timers enz.).

Dom0 is nodig om DomU te starten. Dom0 is het "minimale OS" wat nodig is om drivers etc. te starten en daarna (bijvoorbeeld) een virtual disk aan een VM in DomU te geven. Hoe je het ook wendt of keert; Dom0 is gewoon "op disk" geinstalleerd en niet gevirtualiseerd.

Voor de rest ben ik het met je eens dat er een gedeelte is wat niet direct "bare-metal" draait maar ook zeker niet binnen de boundary van een VM (dus exporteerbaar / isoleerbaar).

Ietsjes anders tegenwoordig, maar dit is niet officieel gedocumenteerd, GPU-PV is vooral voor interne producten van MS (Windows Sandbox, 10X, WSL graphics) en wordt omdat MS het verplicht ondersteund voor alle consumenten-GPUs.


[...]

Over VMBus (voor lokale verbindingen) zit je toch niet met beperkte bandbreedte dus is het vooral buffer-copying voor lokale video en geen vreemde compressie/codering, en zelfs dat is nog iets sneller tegenwoordig (WSLg heeft CPU-side resource sharing, en voor GPU is in aanbouw).

Remote is tegenwoordig ook H.264-encoding (in hardware indien beschikbaar) maar dat doet nogal eens wat nukkig met lange vertraging tussen input->beeld.

Helemaal eens maar ook hier raken we allebei een stuk van de werkelijkheid; het gros van de hypervisor-hosts heeft geen "zware GPU" aan boord. Hiermee loop je dus vrij snel tegen de beperkingen aan die je grafisch over de lijn trekt / wil trekken. Dat hiervoor verschillende oplossingen zijn, waaronder Microsoft RemoteFX (leunend op hardware), Citrix HDX (compressie) en Citrix BCR (offloading to clients), datacenter-based GPU zoals een A16 of AMD W-serie, helemaal duidelijk.

Maar ook hier geldt weer, in context van het topic: zomaar roepen dat iets helemaal ruk is? Meh. Zomaar roepen dat je 20fps mist? Meh. Er wordt (zoals bij elke game-benchmark) niet eens een resolutie genoemd noch een rendering-engine; dan ben ik vrij rap afgehaakt met luisteren naar argumenten, eerlijk gezegd.

[M2M]

Is het niet zo dat het host-OS ook op de HyperV virtualization layer draait als je hyperV aanzet? Volgens wat bronnen links en rechts wel. Performance impact lijkt mij nihil tegenwoordig...

[faziolifairmont]

Ik ben er uit, in groepsbeleid kon ik de virualisatie van windows uitschakelen. Ook was de geheugenisolatie uitgezet, als advies van microsoft in defender.

M2M schreef op zondag 20 februari 2022 @ 22:31:
Is het niet zo dat het host-OS ook op de HyperV virtualization layer draait als je hyperV aanzet? Volgens wat bronnen links en rechts wel. Performance impact lijkt mij nihil tegenwoordig...

ja dat klopt. De performance impact is inderdaad nihil, maar hangt sterk af van wat je doet. Bij normaal gebruik zul je niks merken, maar er kunnen onverwachte kninken in de kabel komen bij bijvoorbeeld games. er zijn meerdere threads op internet over mensen die niet met HyperV kunnen werken vanwege de performance impact in games. soms dus idd wel 20 fps verschil.

[faziolifairmont]

De oplossing bleek te zijn om in groepsbeleid de virtualisatie van windows uit te schakelen. Tevens moest ik van microsoft support kernisolatie uitzetten in defender voor het geheugen.

nu werkt het allemaal vloeiend.

echter nog wel een vraag, geeft dat uitschakelen van die virtualisatie een eventueel kleine performance boost? dan bedoel ik de performance op de host OS, afgezien van of je een hypervisor gebruikt of niet.

[akimosan]

Om even weer eens helemaal om te denken.

je hebt het werkend gekregen dus op zich allemaal prima.
Als alternatief voor Virtual Box had je wat mij betreft ook kunnen kijken naar VMWare Player. Vanaf versie 16.2 werkt dat bij mij prima met Windows 10/11 met allerhande standaard virtualisatie instellingen en security instellingen die MS in de loop der tijd heeft geïmplementeerd dus ook met

- Credential Guard
- Device Guard
- Kernel Isolation
- Hyper-V platform support
- Windows Sandbox