user-v2: allow externally managed daemons (managed: false) instead of auto-starting lima's own
- 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
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