zlacker

>>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?

>>datafl+0h
Creating the VM itself is fast. It depends on what you run in it. Unikernel VMs can start in a few milliseconds. For example, checkout OSv.

>>speed_+Qu
You're saying this is true on a Windows host?

>>datafl+Zv
Yes. The delay you’re complaining about happens because you are looking at general hypervisors which also come with virtualized hardware and need to mimic a bunch of stuff so that most software will work as usual.

For example: your VM starts up with the CPU in 16 bit mode because that’s just how things work in x86 and then it waits for the guest OS to set the CPU into 64 bit mode.

This is completely unnecessary if you just want to run x86-64 code in a virtualized environment and you control the guest kernel and can just assume things are in 64bit mode because it’s not the 70s or whatever

The guest OS would also need to probe few ports to get a bootable disk. If you control the kernel then you can just not do that and boot directly.

There’s a ton of stuff that isn’t needed

>>akdev1+kW
The 16 bit mode stuff and the guest OS probes are after what I'm asking, not before.

>>datafl+DW
No it is not. The “first instruction in the BIOS” is 16 bit mode code when dealing with an x86 VM.

A virtual environment doesn’t even really need any BIOS or anything like that.

You can feel free to test with qemu direct kernel booting to see this skips a lot of delay without even having to use a specialized hypervisor like firecracker