lima-vm / lima-vm/lima

user-v2: allow externally managed daemons (managed: false) instead of auto-starting lima's own

Open
#5,464 1 comment 0 reactions 0 assignees View on GitHub
component/network/user-v2 status/needs-design-consensus
Dominant language
Go
Stars
21.9k
Forks
957
Avg merge
2d 6h
Merged PRs (30d)
53

Description

### Description

We run our own gvisor-tap-vsock based daemon to serve a user-v2 network. The reason it's a user-v2 network rather than a socket network is that on vz it becomes the instance's only NIC, so everything the VM does goes through our daemon.

Lima currently assumes it owns every user-v2 daemon: if the pidfile has no live pid at instance start, `pkg/networks/usernet/recoincile.go` starts `limactl usernet` for it. So the only way to plug in an external daemon today is to write our own pid into that pidfile, and the failure mode of that arrangement is the actual problem:

```
# networks.yaml defines a user-v2 network "custom"
external-daemon & # serves /_networks/custom/custom_fd.sock etc., claims the pidfile
limactl start vm # attaches to the external daemon, single NIC, good
kill %1
limactl stop vm
limactl start vm # lima starts its own usernet, the VM boots fine on it, nothing is logged
```

The last step is the issue. The instance appears healthy, but it is on a completely different network than the one it was configured to be on, and there is no signal that the swap happened. Since the whole point of fronting the VM with our own daemon is that the VM has no other network path, "boots fine on a different network" is the worst way this can fail. The setup fails open; we'd much rather the instance refused to start.

Socket networks already have the ownership model we want ("the daemons will not be controlled by Lima, but the socket file must already exist") — they just don't get the eth0-replacement treatment that usernet networks get. The proposal is to make that model available for user-v2:

```yaml
networks:
custom:
mode: user-v2
managed: false # default true, current behaviour
```

With `managed: false`, reconcile never starts or stops a daemon for this network, and a missing or unresponsive fd socket at instance start is a hard error. Fail closed instead of fail open, and no pidfile juggling.

Touches `pkg/networks/config.go` (field + validation) and `recoincile.go` (skip start/stop, error on missing socket). I can send a PR if the direction is acceptable.

Contributor guide

Open the contributing guide

Research direction

Start with pkg/networks/config.go for the network field and validation, then inspect pkg/networks/usernet/recoincile.go and the existing socket-network ownership behavior. Done means managed: false is accepted for user-v2, reconciliation neither starts nor stops its daemon, and a missing or unresponsive fd socket causes instance startup to fail.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
networking
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
75/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.