Pass DNS addresses from en0 interface to guest instance #199
Conversation
|
|
||
| import "github.com/lima-vm/lima/pkg/sysprof" | ||
|
|
||
| func DNSAddresses() ([]string, error) { |
There was a problem hiding this comment.
QEMU seems using libresolv to get DNS addresses https://gitlab.freedesktop.org/slirp/libslirp/-/blob/v4.6.1/src/slirp.c#L151
Why isn’t this working for us?
There was a problem hiding this comment.
Because it then only picks the first one it finds. It forwards DNS to that address instead of adding all the servers to the resolver inside the guest (probably because it isn't clear how it could do the latter).
So if the choosen server is not working, or is an IPv6 address in a broken IPv6 setup, then no names will resolve because there is no fallback.
|
Temporarily switched to Draft mode because I think the name servers should only be added to the QEMU slirp interface, and not the the vde interfaces. Will update once more. |
|
Seems to be working fine now: jan@lima-default:/Users/jan$ sudo cat /mnt/lima-cidata/network-config
version: 2
ethernets:
eth0:
match:
macaddress: '52:55:55:e9:a1:b4'
dhcp4: true
set-name: eth0
nameservers:
addresses:
- 192.168.123.53
- 192.168.123.17
vde0:
match:
macaddress: '52:55:55:be:2a:6a'
dhcp4: true
set-name: vde0
jan@lima-default:/Users/jan$ systemd-resolve --status
Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (eth0)
Current Scopes: DNS
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.123.53
DNS Servers: 192.168.123.53 192.168.123.17 192.168.5.3
Link 3 (vde0)
Current Scopes: DNS
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.105.1
DNS Servers: 192.168.105.1 fe80::864:900c:7ae3:f83c%22011
DNS Domain: home |
|
LGTM after gofmt, thanks |
| @@ -6,4 +6,11 @@ ethernets: | |||
| macaddress: '{{$nw.MACAddress}}' | |||
| dhcp4: true | |||
| set-name: {{$nw.Name}} | |||
| {{- if eq $nw.Name $.SlirpNICName }} | |||
There was a problem hiding this comment.
I'll change it, but I don't think it should make any difference. Setting a key to nil or not having the key at all should have the same effect. But having the check means we won't have to worry if there is a bug in dealing with this in cloud-init...
There was a problem hiding this comment.
|
ArchLinux CI is failing consistently after retrying several times |
Any idea what might be causing it? I can't repro it locally, even when I pass an empty |
qemu user-mode networking is forwarding DNS to just a single DNS entry from the host. So if that entry does not resolve the query, there is no fallback. Signed-off-by: Jan Dubois <jan.dubois@suse.com>
Worked first time now, but Fedora had to be restarted. I don't think this is related to the |
qemu user-mode networking is forwarding DNS to just a single DNS entry from the host. So if that entry does not resolve
the query, there is no fallback.
Fixes #150 (I hope)
Please review the code updating the DNS entries in the guest. The direct updates to
/etc/resolv.confare probably useless because the file will still be regenerated after cloud-init is done. I've included code to configuresystemd-resolved, andudhcpc(used by Alpine). Any other mechanisms needing support?The
sysprofcode is expected to be used to provide default proxy information as well (see #189 (comment))