Actually just screw all of that and have:
[OS] -> App
Cheaper, less administrative overhead, less abstraction, less vendor tie in (if you go POSIX for example).
I think that might upset the virtualization proponents though...
[OS] -> App
Cheaper, less administrative overhead, less abstraction, less vendor tie in (if you go POSIX for example).
I think that might upset the virtualization proponents though...
If processes are insufficiently isolated, it's the system call interface that's broken, not the isolation model.
It seems to me that virtual machines and containers could be implemented on top of the existing process hierarchy by allowing a parent process to intercept and reinterpret its child process' system calls. Simple example: Want to implement chroot? Intercept all open() calls and prepend the root path (taking care to prevent escaping with '../').
I am just curious as to why people would use virtualization at all if it is possible to accomplish the same thing using regular processes.
"You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes."
Quotas are easy enough to enforce. Most UNIX derivatives (including Linux) have disk and process quotas, some for over 3 decades.
Virtualization seems to be best used for reselling (and overselling) hosts that are smaller than the physical machine and not much else. Migration/failover is a non issue if you know what you are doing and if you need larger machines, it's just more overhead on top of a dedicated host. Plus it's increased administrative cost and more expense as a whole.
In theory, VMs should help reduce the attack surface by a lot. For example, all the system calls in the VM are handled by the guest OS. The actual system calls made to the host should be minimal and can be more easily audited.