To do this efficiently they've had to make a bunch of changes on the VM side so the overhead is much smaller than an ordinary VM (of the order of 150ms and 20MB of RAM). I've also been looking at this and am hoping to give a talk about it at the KVM Forum in August (http://events.linuxfoundation.org/events/kvm-forum).
One note: you can run multiple "container processes", like redis and a redis dashboard, inside of these Clear Container VMs. This means in the case of Kubernetes we will only incur the cost of the startup time and Kernel/init overhead once per pod instead of once per process.
To justify the question a bit: booting traditionally meant physically turning a system on. The boot time included BIOS initialization, a concept now blurred by the advent of virtualization.
150ms is such an absurdly short amount of time that I'm left wondering what booting is in this context.
I imagine that most of the time would be in mocking some/all of the hardware interfaces to present to the VM, and running your init processes (and all that entails for whatever OS you're running).
Clear Linux was announced about a year ago, and it does boot absurdly quickly
https://www.kernel.org/doc/Documentation/filesystems/dax.txt
Taking a 50x hit to run "exit" from a container doesn't sound bad, but it doesn't sound all that far fetched either.
[1] time util from pstools, as installed by scoop.sh - similar to why gcc (not eg msvc - it's all in my path atm, no work needed :)
If you meant "running a process in a VM meets what requirement?", the requirement is security, which as the paper here proves is not available with simple containers running as processes on the host.