zlacker

[return to "Microsandbox: Virtual Machines that feel and perform like containers"]
1. datafl+0h[view] [source] 2025-05-30 15:13:39
>>makebo+(OP)
Tangential question: why does it normally take so long to start traditional VMs in the first place? At least on Windows, if you start a traditional VM, it takes several seconds for it to start running anything.

Edit: when I say anything, I'm not talking user programs. I mean as in, before even the first instruction of the firmware -- before even the virtual disk file is zeroed out, in cases where it needs to be. You literally can't pause the VM during this interval because the window hasn't even popped up yet, and even when it has, you still can't for a while because it literally hasn't started running anything. So the kernel and even firmware initialization slowness are entirely irrelevant to my question.

Why is that?

◧◩
2. diggan+8m[view] [source] 2025-05-30 15:43:27
>>datafl+0h
I mean it is basically booting a computer from scratch, kind of makes sense. You have to allocate memory, start virtual CPUs, initialize devices, run BIOS/UEFI checks, perform hardware enumeration, all that jazz while emulating all of it, which tends to be slower than "real" implementations. I guess there is a bunch of processes for security as well, like wiping like zeroing pages and similar things that takes additional time.

If I let a VM use most of my hardware, it takes a few seconds from start to login prompt, which is the same time it takes for my Arch desktop to boot from pressing the button to seeing the login prompt.

◧◩◪
3. datafl+8p[view] [source] 2025-05-30 16:00:54
>>diggan+8m
> You have to allocate memory, start virtual CPUs, initialize devices, run BIOS/UEFI checks, perform hardware enumeration, all that jazz while emulating all of it, which tends to be slower than "real" implementations.

That's not what I'm asking.

I'm saying it takes a long time for it to even execute a single instruction, in the BIOS itself. Even for the window to pop up, before you can even pause the VM (because it hasn't even started yet). What you're describing comes after all that, which I already understand and am not asking about.

◧◩◪◨
4. drewg1+8w[view] [source] 2025-05-30 16:47:56
>>datafl+8p
Without any context in terms of what the VM is doing or what VMM software you use, my best guess is that the OS/VMM are pre-allocating memory for the VM. This might involve paging out other processes' memory, which could take some time.

I think task manager would tell you if there is a blip of memory usage and paging activity at the time. And I'm sure windows itself has profilers that can tell you what is happening when the VM is started..

◧◩◪◨⬒
5. drewg1+fx[view] [source] 2025-05-30 16:55:41
>>drewg1+8w
For some reason I can't reply to your reply. I'd strongly suggest that you profile virtual box. It beats speculation..
◧◩◪◨⬒⬓
6. HumanO+aJ1[view] [source] 2025-05-31 07:32:35
>>drewg1+fx
I experienced something similar back when Microsoft decided to usurp all hypervisors made for Windows and make Windows itself run as a VM on Hyper-V running as a Type 1 hypervisor on the hardware. That made it so other VMs could only run on Hyper-V alongside Windows or with nested virtualization.

So this meant VMWare, VirtualBox, etc as they were would no longer work on Windows. Microsoft required all of them to switch to using Hyper-V libs behind the scenes to launch Hyper-V VMs and then present them as their own (while hiding them from the Hyper-V UI).

VirtualBox was slow, hot garbage on its own before this happened, but now it's even worse. They didn't optimize their Hyper-V integration as well as VMWare (eventually) did. VMWare is still worse off than it was though since it has to inherit all of Hyper-V's problems behind the scenes.

Hope this brings some clarity.

[go to top]