Containers seem light and cheap, but they have subtle problems lacking solid guarantees, prioritization, or limits on compute, network, and storage resources that type-1 v12n provides.
My VM is lighter (and safer) than your container (2017)
171–180 of 184 posts
Re: My VM is lighter (and safer) than your container (2017)
#172"VM" means it has its own kernel? Why have 2 kernels on the same machine? All processes in a proper OS are already isolated and there is no need for VM.
It depends on the type of v12n. Paravirtualization and similar, the answer is sort-of while hard emulation is definitely yes. There are efficiencies in memory usage because the often will share the same kernel code and userland code, which are memory pages that can be deduplicated at the hypervisor level. Read more about type-1 v12n.
> All processes in a proper OS are already isolated and there is no need for VM.
No. This is not how things work in reality. (Ideally, yes because hypervisors are OS "duct tape" but there is no such readily-available OS with strict resource limits and hard enforced VFS and network isolation.) Isolation, sharing, and hard limits on RAM, CPU, networking, and storage (bandwidth, block devices, and IOPS) is beyond the capabilities of every major OS. This is why VMware and similar type-1 hypervisors exist.
Re: My VM is lighter (and safer) than your container (2017)
#173Earlier quoted context omitted.
> So you do get strong isolation. No, you don’t. There is no benefit the container is providing, because The only feature of the container is isolating you from the zero other containers running on the VM.
The isolation I am referencing is from the VM, not the container. Containers don't provide strong isolation, that is why the VM is required in this model.
The VM is an isolated environment itself. You do not need to be isolated from it.
Using two levels of userland isolation makes about the same sense as using 457 levels of userland isolation.
Re: My VM is lighter (and safer) than your container (2017)
#174Firecracker micro VM uses musl not glibc. Is it true.
Re: My VM is lighter (and safer) than your container (2017)
#175Earlier quoted context omitted.
You don't need a VM on Mac to run containers, check out OrbStack, they provide a Docker compatible engine that is using native MacOS capabilities for running containers without the hidden Linux VM.
I don't know where you got that idea. OrbStack absolutely runs a Linux VM. That Linux VM then uses Linux containerization technologies (namely LXD) for each separate OrbStack 'machine' you set up, which is how you get such fast startup times for your OrbStack 'machines'. For Docker, OrbStack does the same thing as Docker Desktop, Podman Desktop, Rancher Desktop, etc., which is set up a Linux VM running Docker and the…
Interesting! I'd swear that in the early days of OrbStack somewhere on their website I've read they're using native MacOS frameworks without the need of Linux VM, but I can't find that anymore (they don't mention Linux VM either, but the language still differs from what I remember).
Re: My VM is lighter (and safer) than your container (2017)
#176Earlier quoted context omitted.
Processes run in a userspace and cannot do anything without OS approval.
The Linux kernel has far too large of an attack surface to be trusted as a hard security boundary. It is good enough to prevent mostly trusted software from accidentally interfering with each other but I would not trust it to protect me from an untrusted workload. For example GCP and AWS both have container running services. They both use hardware VMs to isolate different tenants. You will never share a kernel with a…
Maybe you need a better kernel then? For example, a microkernel.
Re: My VM is lighter (and safer) than your container (2017)
#177Earlier quoted context omitted.
No it didn't. I want to rebuild my image using a different base. Docker? One line possibly. VM? Afternoon (unless I want to write ansible too)
In this sort of scenario, then you can also use something like cloud-init: https://cloudinit.readthedocs.io/en/latest/
Or I could use the tool I currently am. Your reply doesn't solve my use case it just says use yet another tool.
Re: My VM is lighter (and safer) than your container (2017)
#178Earlier quoted context omitted.
I don't know where you got that idea. OrbStack absolutely runs a Linux VM. That Linux VM then uses Linux containerization technologies (namely LXD) for each separate OrbStack 'machine' you set up, which is how you get such fast startup times for your OrbStack 'machines'. For Docker, OrbStack does the same thing as Docker Desktop, Podman Desktop, Rancher Desktop, etc., which is set up a Linux VM running Docker and the…
Interesting! I'd swear that in the early days of OrbStack somewhere on their website I've read they're using native MacOS frameworks without the need of Linux VM, but I can't find that anymore (they don't mention Linux VM either, but the language still differs from what I remember).
They do use native GUI frameworks rather than something like Electron, which they still mention. And maybe they also used to have something about relying on Apple's Virtualization Framework or something like that, rather than qemu as Lima used for a long time. (I think it may still be Lima's default, but not for long.)
Re: My VM is lighter (and safer) than your container (2017)
#179Earlier quoted context omitted.
Yet it doesn't even come close to a fraction of the adoption scale of containers, no matter how good it is. Ecosystems matter more than individual quality.
I think that's a gross overstatement. Ecosystems matter, yes. But they don't matter more than quality.
I think Betamax might have something to say about that.
Re: My VM is lighter (and safer) than your container (2017)
#180Earlier quoted context omitted.
Nowadays it is fairly straightforward to set up docker in rootless mode.
Exactly, "set up". Many people (not all) don't want to fiddle with things, they just want it to work out of the box. The importance of secure defaults can't be overstated, especially when there are virtually no downsides.
It's more work to switch to podman than it is to just configure docker to run rootless.