[Request]: strange doc comments about machines versus containers

[afbjorklund]

Feature or enhancement request details

The container machine documentations talks about filesystems and init:

"each machine keeps its filesystem and runs the image's own init system"

But a container also keeps its filesystem, and it can use the --init flag?

So there is no major difference between the two, it's more of a convenience...

The real difference is in the user setup and in the default volume mounts:

"Host integrations such as automatic user and home directory sharing"

---

Talking about container machine versus container here, not about containers.

Otherwise it would be more about reusing the old kernel, vs starting a new one...

A container machine (with user and home) is usually referred to as a "toolbox".

And you can run those on top of container machine (or container), if needed:

• Toolbx https://containertoolbx.org/

• Distrobox https://distrobox.it/

Code of Conduct

• I agree to follow this project's Code of Conduct

[katiewasnothere]

Hi @afbjorklund for "regular" containers with container, the container's filesystem is ephemeral and cleaned up when a container is removed with container rm <container name>. Every time you run your container, you would start with a fresh view of the container's configured filesystem.

In the case of container machine, the machine's filesystem is persisted such that when it is stopped (and thus the backing VM is stopped and removed) then rerun, you have all the same data in the machine that you did before stopping it. This is helpful for scenarios where you want to persist filesystem changes over a long period of time but you don't want to keep the VM resources around when you're not actively using the machine. Plus all the other features like the host integration ones are nice :)

Does that help clear things up?

[afbjorklund]

Does that help clear things up?

Not really, if you delete (rm) the machine then the filesystem is also removed?

If you stop a container, then the filesystem is still there the next time you start it.

Except for any tmpfs mounts etc, but

---

You are more likely to delete a container ("cattle") than a machine ("pet"), though.

So that is where the volumes come in, for things you want to preserve for next time.

(volume seem missing from machine)

[jglogan]

@afbjorklund Hi!

each machine keeps its filesystem and runs the image's own init system

So there is no major difference between the two, it's more of a convenience...

This is correct. Do you think the documentation could be improved by explaining that up front? Or is it something else that you think needs to be changed?

Something that captures the essence of a machine as a convenience wrapper around a container and a separate root disk image file (I hesitate to say "hidden volume" because it's not stored as a proper volume resource) that persists changes throughout the lifetime of the container.

It'd be nice to have something that conveys the meaning readily to non-technical users that just want to know when and why they'd use a container machine, and provides enough implementation summary to developers and the technically curious.

You are more likely to delete a container ("cattle") than a machine ("pet"), though.

I called up the pets vs cattle analogy in a talk about the feature this week. It's a good way to differentiate machine vs container.

[afbjorklund]

I like the new convenience functions, as they make it easier to create and connect to a "machine".

# container=$(container run -c 4 -m 4G -d ubuntu-systemd)
container machine create --home-mount=none ubuntu-systemd

# container exec -it $container bash
container machine run

But I am not sure that I would have split everything else down the middle, with a new command...

---

Not sure what would be the easiest/best way to explain the differences, especially with "container".

Or what differs these machines with the VM machines (as it mostly boils down to the provisioning)

[afbjorklund]

First we had Docker Machine, so that we could run Docker containers.

Then a Minikube Machine, so that we could run Kubernetes containers.

Then also a Podman Machine, so that we could run Podman containers.

Then it got repetitive, and now we just have Linux Machines to run all of it...

---

But then it is provisioned like a cloud machine, with cloud-init and with scripts.

The main difference in the Container provisioners, is actually the image used.

Sure, you can still use a base image and scripts - but you can also build images.

So when using the WSL2 or the AC/DC drivers, it can use a rootfs (or an image):

• The Lima container drivers lima-vm/lima#3829

---

It gets confusing with the Container Machine, because it doesn't really run containers?

But you can easily add a Container Engine to it, and then it does work for both purposes.

You can use it as your macOS Subsystem for Linux (mSL), or you can use it to run containers....

For now I think it is mostly the Distribution images missing, and after that it is the GUI (wslg).