HostResolver does not work with VZ

[jandubois]

I've been looking into a DNS issue that seems to be triggered by certain static DNS entries in the hostResolver.hosts setting, so assumed the error would be in pkg/hostagent/dns/dns.go.

The default template claims that the host resolver is enabled by default:

lima/templates/default.yaml

Lines 567 to 569 in 9d815d5

	hostResolver:
	# 🟢 Builtin default: true
	enabled: null

But this turns out not to be true when using VZ. The cidata code has a bug that prevents the host agent ports from being written to lima.env:

lima/pkg/cidata/cidata.go

Lines 278 to 283 in 9d815d5

	case firstUsernetIndex != -1 || *instConfig.VMType == limatype.VZ:
	args.DNSAddresses = append(args.DNSAddresses, args.SlirpDNS)
	case *instConfig.HostResolver.Enabled:
	args.UDPDNSLocalPort = udpDNSLocalPort
	args.TCPDNSLocalPort = tcpDNSLocalPort
	args.DNSAddresses = append(args.DNSAddresses, args.SlirpDNS)

This means that the host resolver has not been used with VZ contrary to our documentation. Which means we can't simply fix this bug because that would suddenly switch existing VZ instances to using the host resolver, which may be unwanted.

So I see 2 different options for us:

1. Fix the bug, but change the hostResolver.enabled default to false for VZ only.

2. Disallow using the host resolver with VZ because it looks like it never worked before, and it is unclear if anybody ever want this functionality. The host resolver exists to work around the limitations of DNS forwarding in QEMU.

The effort for both is about the same, as in both cases we would have to make the default dependent on the driver.

I guess my main reason to consider option 2 is that I don't want us to waste looking into host resolver issues when we could just rely on the gvisor implementation (ignoring for a moment that it too has a problem, which is how this whole story started).

So I'm looking for feedback from @lima-vm/maintainers if you favour option (1) or option (2), and why?

---

Unrelated, but I find it unfortunate that the static hosts are under hostResolver.host, and they are still being used in usernet networking even if hostResolver.enabled is false.

So these names should really be in a separate staticHosts section at the root of lima.yaml, but I don't know if we still want to make such changes before the 2.0 release with so many other things still in progress?

---

Almost forgot: the original DNS issue with static hosts and usernet is still unresolved, but really independent of this issue.

[nirs]

I like option 2 - it never worked so we did not have this feature and nobody complained about it. Deleting the code that never worked is the most effective way to fix the bug. We can add this feature later if we have a need.

[jandubois]

Deleting the code that never worked is the most effective way to fix the bug.

We can't delete the code; it is still used for QEMU, and it works fine. The bug is that we never enabled it for VZ, even though we claimed it was enabled by default.

I think nobody noticed until now because the gvisor-tap-vsock DNS implementation does essentially the same thing. I only found out because somebody complained that kind stopped working for them when they switched from QEMU to VZ (with specific static host names defined).

I've changed my mind and created a PR that implements (1) #4090.