v2.0 planning (pluggable VM drivers, AI helpers, etc.)

[AkihiroSuda]

Here is a highlight of the features tentatively planned for v2.0 (ETA: September? October?).

Still subject to change.

Pluggable VM drivers

The support for VM driver plugins is being implemented by @unsuman as a part of the GSoC 2025 program:
https://github.com/lima-vm/lima/issues?q=label%3Agsoc%2F2025

The plugin API will be marked experimental in v2.0, and will be stabilized in v2.x or maybe in v3.0+.

The existing vz and qemu drivers will remain built-in at least in v2.0 to avoid potential regressions.

New drivers such as krun (w/ GPU acceleration) will be implemented as separate plugins:

• Support libkrun (mostly for Virtio-GPU Venus), maybe via krunkit #2277

Integration with AI agents

Two kinds of integration should be explored:

• AI inside Lima
• Lima inside AI

AI inside Lima

Lima v2.0 will have features to help running AI agents such as codex, gemini, and claude inside the VM so as to avoid breaking the host files.

• Add limactl shell --sync-host-workdir (prevents AI agents from breaking the host files) #3711
  • EDIT: Postponed to v2.1+
• Add a --with-env flag to limactl shell #3430
  • EDIT: Merged as limactl shell --preserve-env (implement preserving env from host into vm in shell command #3830)

$ limactl start --mount-none template://claude
$ cd ~/some-project
$ limactl shell --sync-host-workdir claude claude
Changed files:
- foo.go
- Makefile

⚠️Accept the changes?
→ Yes
  No
  View the changed contents

Still not sure whether we should have VM templates such as template://claude, as we have never included proprietary software in our template set.
Maybe acceptable as template://nonfree/claude ?

• templates: add gemini, claude, codex #4072
  • EDIT: The templates were not added in v2.0. Instead, example scripts were added to docs: https://lima-vm.io/docs/examples/ai/

Lima inside AI

Lima may provide MCP tools (lima_run_shell_command, lima_read_file, ...) to an AI agent running on the host for sandboxing shell command executions and file I/O operations.

• Define "MCP Sandbox Interface" and implement limactl mcp serve #3744

It is desired that eventually there will be the industry-standard API for sandbox technologies. Proposal:

• Proposal: plugin API for sandboxing shell commands and file I/O google-gemini/gemini-cli#3216

Other changes

Disable /tmp/lima mount

/tmp/lima will probably no longer be mounted by default:

• docs: discourage /tmp/lima on shared hosts (and deprecate it?) #3648

This will allow multiple user accounts to run Lima instances independently.

Consolidate diffdisk and basedisk to save the disk space

~/.lima/INSTANCE/{diffdisk,basedisk} will be consolidated to save the disk space, for newly created instances:

• vz: remove "basedisk"; rename "diffdisk" #1706
  • EDIT: Postponed to v2.1+

---

See also https://github.com/lima-vm/lima/milestone/59

[unsuman]

This sounds cool!

Still not sure whether we should have VM templates such as template://claude, as we have never included proprietary software in our template set.
Maybe acceptable as template://nonfree/claude ?

We can prioritise Ollama as the primary, default option. For proprietary models, we can go with template://nonfree/claude or maybe some other way?

[AkihiroSuda]

We can prioritise Ollama as the primary, default option. For proprietary models, we can go with template://nonfree/claude or maybe some other way?

Ollama does not seem comparable to codex/gemini/claude, as ollama does not execute shell commands and read/write files by itself

[jandubois]

Still not sure whether we should have VM templates such as template://claude, as we have never included proprietary software in our template set.
Maybe acceptable as template://nonfree/claude ?

I do not think there is any reason not to include example templates for proprietary applications, and I don't think we need "nonfree" in the template name either. I would be fine with something like template://app/claude to indicate this is not a distro, but a specific app.

Just like you can install nonfree software with Homebrew, e.g. brew install docker-desktop or brew install multipass.

Pointing out "nonfree" components seems to be more important to GPL licensed projects.

[jandubois]

~/.lima/INSTANCE/{diffdisk,basedisk} will be consolidated to save the disk space, for newly created instances:

How does this save disk space? Especially on filesystems with reflink/clonefile support?

[afbjorklund]

Would it be possible to add the generic ssh driver to v2?

• External driver, for cloud and physical #2109

It definitely needs a new name, now that it is "internal"...

• The Linux physical machines #2029

[tao12345666333]

I think both the Gemini cli and codex have sandbox by default.

MCP is a good idea 💡

[afbjorklund]

@AkihiroSuda

Maybe we can remove the default port (60022) when it is possible to break backwards compatibility (v2)?

And have any existing "default" instances add an explicit localPort: 60022 if they rely on that functionality.

  # A localhost port of the host. Forwarded to port 22 of the guest.
  # 🟢 Builtin default: 0 (automatically assigned to a free port)
  # NOTE: when the instance name is "default", the builtin default value is set to
  # 60022 for backward compatibility.
  localPort: null

In order to not have any hardcoded ports.

[jandubois]

Maybe we can remove the default port (60022) when it is possible to break backwards compatibility (v2)?

We don't need to break backwards compatibility because we store the Lima version used to create the instance in lima-version in the instance directory for just this purpose: so that we can change defaults for instances created with a new release without breaking existing instances that rely on old defaults.

For example we use the mechanism to change the admin username to lima in instances that have been created by Lima 1.0.0 or later, but keep it unchanged when the instance is older:

lima/pkg/osutil/user.go

Lines 152 to 159 in 2bfc04a

	if versionutil.GreaterEqual(limaVersion, "1.0.0") {
	if u.Username == "admin" {
	if warn {
	logrus.Warnf("local username %q is reserved; using %q instead", u.Username, fallbackUser)
	}
	u.Username = fallbackUser
	}
	}

[afbjorklund]

It is true that we could "break" 60022 at any time, but 2.0.0 just seemed like a good time to do it (like with /tmp/lima)

But it is nice that existing instances keep on working, without having to explicitly modify the yaml as with new instances