[vote] Do you want docker run equivalent lima run?

[loynoir]

Docker offers a convenient batch command docker run.

docker run \
  [ --name name ] \
  [ -v /tmp/host:/tmp/guest:ro ] \
  [ --rm ] \
  [ -it ] \
  "${image:?}" \
  echo 42

docker run packs at least 8 sugars.

Do you want docker run equivalent lima run?

• Automatically pulls the image only when it isn’t found locally.
• Automatically creates the container or VM.
• Generates a random default name, so you never have to worry about name conflicts.
• Makes it easy to share assets (files/directories) between host and guest.
• Automatically starts the container or VM.
• Lets you choose between non-interactive and interactive shell modes.
• Automatically stops when done, no need to remember to shut it down.
• Can automatically remove the container or VM, like --rm

Note

We, the project maintainers, are not conducting this "vote", and not bound to the poll results.
This kind of proposal could be better experimented as a third-party plugin.

• [feat] easy lima integration test #5332

[loynoir]

Third-party plugins are likely outside the control of system package managers.

AUR and Nix have a vast number of packages, yet at the time of writing, neither has any third-party Lima plugins.

It might take years for third-party plugins to be adopted by all distros.

There is already prior art for official plugins, such as docker/buildx.

Thus, official plugins seem like a good choice.

---

I do believe official docker run support would be good for many people.

Maybe I’m in the minority that wants a docker run equivalent. Maybe I’m not.

I want a place, to represent the community’s need.

I want a place, to represent the community’s voice.

Since non-project members are allowed to create GitHub votes as well, I’ve created a democratic vote.

---

If, unfortunately, I end up in the minority, or if nothing comes of it in the end, I apologize to everybody in advance.

Wishing you all the best.

[jandubois]

Since non-project members are allowed to create GitHub votes as well, I’ve created a democratic vote.

Yes, you can create a "democratic vote", but that is pretty uninteresting for the maintainers (unless you actually get several hundred votes).

But more important to change our minds would be to discuss the use case for any new feature you want to add, especially if it is "sugar" by your own definition.

Rather than a vote, I would want to see an explanation of the problem each user is facing, how they are dealing with it now, and how a proposed feature would make it easier.

In general we want to provide the building blocks that let people help themselves. So anything that can be done with a short shell script is unlikely to make the cut.

---

For reference: the fact that limactl start can be used to create a new instance is a historical accident. When we realized that the same start command would be interpreted differently depending on if the instance existed or not, we created the limactl create command.

The overloaded functionality, especially with conflicting semantics depending purely on local context is really bad for automation and scripting: you cannot predict what the command will do purely by looking at the command itself.

limactl start continues to support creating new instance purely because of our commitment to backwards compatibility. If it didn't do this already, then we would not entertain a proposal to add that functionality now.

---

We are trying to limit what goes into the core Lima distribution because ultimately the maintainers are responsible for it long term (see our commitment to backwards compatibility, and to making sure things continue to work in future environments).

We did reject adding advanced templates that implemented more complex use cases for this reason.

We have created a plugin driver system so that additional driver implementations in the future might live outside the code repository.

Given this goal of keeping the core distribution manageable, we are not going add small opinionated convenience method unless they address the needs of many users and are not possible to implement externally.

---

Having said all this, I applaud your enthusiasm! But build something first and share it with others before worrying about how to get something packaged for all the distros in the world. Start by creating a homebrew tap to begin with. Advocate for it in the user groups that would benefit from it. And then make the argument that this is essential functionality, that should be included in Lima itself. But keep in mind our preference to keep optional stuff outside.

[loynoir]

I agree that building blocks are great, but features like guaranteed resource release should really be part of the core, or at least provided as an official plugin.

There are plenty of examples where the language or compiler officially guarantees resource release — defer, __attribute__((cleanup)), destructors, the Drop trait, GC, using, with, and so on.

In many languages, resource release can obviously be handled with nothing more than building blocks. So why do they all provide built-in mechanisms to guarantee it? If building blocks alone were truly enough, could we convince all those languages and compilers to drop their guaranteed resource release features?

Let’s step back and ask: what problem are Lima’s building blocks trying to solve?
Virtual machines.
A virtual machine consumes resources of many types and in large quantities — memory (often on the order of gigabytes of RAM), disk space (virtual disk images, snapshots, temporary files), CPU cores and time, network interfaces and port forwarding rules, numerous host processes and threads, file descriptors, kernel resources such as KVM handles, cgroups and namespaces, and other I/O resources like mounted host directories or device passthrough. Compared to typical software, a virtual machine is in a completely different league — most applications don’t routinely allocate gigabytes of memory, hold large numbers of file descriptors, or spawn dedicated host threads and kernel resources just to function. This makes the need for a reliable, official resource release mechanism all the more critical. Take memory alone: even if a VM starts at one gigabyte, and that’s not even counting all these other resources, doesn’t that already make it a heavy resource consumer?

In short, we’re relying on building blocks to manage a heavy resource consumer.

Is it possible? Yes, but when facing such a heavy consumer, at least one critical building block is missing. As of the day of writing, there still isn’t a single official block from Lima that takes on the responsibility of releasing the resources of such a heavy consumer — the way those guaranteed resource release examples I mentioned earlier do.

That is why, I submitted that feature request.

[afbjorklund]

The Lima equivalent would be nerdctl.lima, otherwise we would rather be comparing Lima with Docker Machine.

But there are some good features in your list, but going bug-compatible with Docker put us in the "Podman trap"...

---

Automatically pulls the image only when it isn’t found locally.

This should already be happening, in the cache?

Automatically creates the container or VM.

This could also be prompted, something being considered.

FATA[0000] instance defaultdoes not exist, runlimactl create default to create a new instance

• limactl create should ask whether to start the instance #4402

Generates a random default name, so you never have to worry about name conflicts.

This is a valid feature, but you could also use --name

Makes it easy to share assets (files/directories) between host and guest.

This should already be implemented.

Automatically starts the container or VM.

Currently it will prompt you for it, but it can be defaulted.

? Do you want to start the instance now?

• limactl create should ask whether to start the instance #4402

Lets you choose between non-interactive and interactive shell modes.

Currently this is magically decided by the number of arguments.

lima uname or lima

Automatically stops when done, no need to remember to shut it down.

The "pause" feature would probably be less disruptive, to a VM.

Can automatically remove the container or VM, like --rm

This is typically not something you want to do with a VM, though.

[loynoir]

This is typically not something you want to do with a VM, though.

I think, there are two problems.

1. Anything that takes up space should have a delete option.
2. However, creating it is very time‑consuming, so it's best not to delete it.

A few Thoughts on faster creation:

Is it possible to create snapshot from snapshot?

What if we think of wrapper of snapshot readonly backup as Lima’s version of a Docker image?

What if we think of wrapper of snapshot copy as Lima’s version of a Docker container?

Given X have two snapshots Y1 and Y2, is it possible to enter Y1 shell and Y2 shell in parallel‌?

[afbjorklund]

The existing "snapshot" feature records the current disk (and runtime) state. It is so far only implemented for QEMU

• Does lima support checkpoint backup and restore like normal virtual machine? #1051

But if you delete the instance, then all such snapshots are also deleted. Only one snapshot can be restored at a time.

The "suspend" feature was also only implemented for QEMU, but it had some issues to restore SSH after a "resume".

• Implement suspend and resume of VM #598

The container drivers* have faster create and delete, than the virtual machine drivers (they also have faster boot times)

* WSL2, Apple Container, Kata Containers

Typically they start in 1 second, instead of 10

[loynoir]

Not tested.

Seem possible using linked clone?

https://superuser.com/questions/958739/create-linked-clone-or-layered-shared-disks-with-qemu#1010887

• base-image.qcow2 like image
• linked-image.qcow2 like container

Then start them in parallel?

• Y1-linked-image.qcow2
• Y2-linked-image.qcow2

[afbjorklund]

The linked images were removed, so now there is no R/O "basedisk" and R/W "diffdisk" - there is just one "disk"

As long as the machines are powered off, it should be possible to copy the disk images to make "clones".
But they do risk having conflicting IP addresses and such, when they are eventually powered back on?

So normally it is recommended to create two instances from the same image/provisionig, rather than "cloning".