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. orev+bq[view] [source] 2025-05-30 16:08:17
>>datafl+0h
I think you need to provide more details on what VM software you’re using. On VirtualBox what you describe is very noticeable, and it didn’t have that delay in older versions. So it could be just an issue with that VM software and not a general “traditional VMs” issue.
◧◩◪
3. datafl+Wq[view] [source] 2025-05-30 16:12:48
>>orev+bq
Yup I'm asking about VirtualBox mainly, I just don't understand what the heck it's doing during that time that takes so long. Although I don't recall other VMs (like say, Hyper-V) being dramatically different either (ignoring WSL2 here).
◧◩◪◨
4. _facto+vs[view] [source] 2025-05-30 16:23:43
>>datafl+Wq
Try disabling Windows Defender and trying again.
◧◩◪◨⬒
5. datafl+1u[view] [source] 2025-05-30 16:32:54
>>_facto+vs
Are you just guessing or have you actually seen the delay I'm talking about disappear as a result of this (or as a result of anything else for that matter)? Because I've already done this (yes, entirely, even the kernel mode drivers) and it's definitely not the issue.
◧◩◪◨⬒⬓
6. hinkle+6A[view] [source] 2025-05-30 17:17:07
>>datafl+1u
There was a release of subversion back in the day that reduced the number of files that were opened during a repo action like pull, and the number of times any one file got opened. On Linux it ran about 2-3x faster. Very nice change.

On windows it was almost 10x faster. On the project where this change was released, my morning ritual was to come in, log on, run an svn pull command, lock my screen and go get coffee. I had at least ten minutes to kill after I got coffee, if the pot wasn’t empty when I got there.

Windows is hot garbage about fopen particularly when virus scanning is on.

[go to top]