Repository navigation
Colima not inheriting system DNS - cannot docker login or pull #711
Description
Activity
- Reacted by Henri Cook
I have the same issue using VZ
running on macbook air M1 >= 13 (Ventura)
Colima Version: 0.7.0
Lima Version 0.22.0colima status INFO[0000] colima is running using macOS Virtualization.Framework INFO[0000] arch: aarch64 INFO[0000] runtime: docker INFO[0000] mountType: virtiofs INFO[0000] address: 192.168.107.2 INFO[0000] socket: unix:///Users/xu/.colima/default/docker.sockthe workaround results in having to restart colima everytime the network changed e.g. changing from wifi to mobile hotspot
still present on :
INFO[0000] colima is running using macOS Virtualization.Framework INFO[0000] arch: aarch64 INFO[0000] runtime: docker INFO[0000] mountType: virtiofs INFO[0000] socket: unix:///Users/mac/.colima/default/docker.sockWorked around it by following linked bug to add custom DNS servers.
Would be great if this can be improved, in my ase it was the VPN DNS I am using was not picked up.I've been running into this issue as well.. Setting our company's custom dns servers and restarting every time the network changes is a workaround at the moment; but it would be really nice if Colima either picked up the VPN DNS settings automatically, or if I at least didn't have to restart colima every single time my network changes.
my colima version is:
colima version colima version 0.7.6 git commit: 3ab92f54210503770223a8c9bb61662725e23004Maybe we can brainstorm about an implementation? like at start it could read network config, that would be an improvement. But it will be tricky to get MacOS and Linux both right.
MacOS 15 shows this to be used to check DNS ( comment in /etc/resolv.conf ) : scutil --dns .
On Linux it could be systemd-resolvd , dnsmasq or other.What the crc binary from Redhat does is to manipulate /etc/hosts, which could work on both.
I don't know if there are any agents in place that could handle dynamic changes in network.
And the requirement of restarting depends on qemu I suppose, not sure if it can take network changes without restart and if Alpine can pick that up.
Would be a nice feature :)Maybe we can brainstorm about an implementation? like at start it could read network config, that would be an improvement. But it will be tricky to get MacOS and Linux both right.
MacOS 15 shows this to be used to check DNS ( comment in /etc/resolv.conf ) : scutil --dns .
On Linux it could be systemd-resolvd , dnsmasq or other.
What the crc binary from Redhat does is to manipulate /etc/hosts, which could work on both.
I don't know if there are any agents in place that could handle dynamic changes in network.
And the requirement of restarting depends on qemu I suppose, not sure if it can take network changes without restart and if Alpine can pick that up.
Would be a nice feature :)
Agreed, using the resolvd file for Linux would make sense. Following this seems to be a good approach for Linux: https://github.com/qdm12/dns/blob/v2.0.0-beta/pkg/nameserver/getlocal_unix.go
And yeah I agree for MacOS, a good approach might be to use
scutil --dns.I also noticed in Go 1.20, DNS resolution changed and now it seems to work natively.. I noticed Colima is using Go 1.20 and it should be able to lookup DNS hosts using
net.LookupHost, so I wonder why there's issues when it comes to DNS resolution. https://danp.net/posts/macos-dns-change-in-go-1-20/I'm also curious how other container runtime environments handle network changes without restart.. My Rancher Desktop and Docker Desktop instances don't need to be rebooted after network changes. Originally, I would've expected that the
network-host-addressesflag would be sufficient at sharing my host network with the container runtime environment.Good catch with the Go update. I suppose that if this works as expected on Linux, implementing the MacOS version to use the Go method seems like the best thing to do.
I suppose reloading is needed because it reads the yaml file at boot and there are no cli options to send network options ? I haven't checked deeply on that, but network manipulation should be possbile with virsh : https://www.libvirt.org/manpages/virsh.html#virtual-network-commands . Any devs ready here ? should this be a feature request ?This workaround fixed the problem for me (
colima.yaml):# Workaround for broken DNS in the Ubuntu 26.04 Lima image: the image ships # /etc/resolv.conf as a symlink to a systemd-resolved stub, but systemd-resolved # is not present, and cloud-init skips manage_resolv_conf because it sees the # symlink. Remove the dangling symlink and write a real resolv.conf pointing at # the Lima host-gateway DNS so dockerd can resolve registries. provision: - mode: system script: | if [ -L /etc/resolv.conf ] && [ ! -e /etc/resolv.conf ]; then rm -f /etc/resolv.conf echo "nameserver 192.168.5.2" > /etc/resolv.conf fiReacted by Rene Leonhardt, linxxx3 and Henri CookThis workaround fixed the problem for me (
colima.yaml):# Workaround for broken DNS in the Ubuntu 26.04 Lima image: the image ships # /etc/resolv.conf as a symlink to a systemd-resolved stub, but systemd-resolved # is not present, and cloud-init skips manage_resolv_conf because it sees the # symlink. Remove the dangling symlink and write a real resolv.conf pointing at # the Lima host-gateway DNS so dockerd can resolve registries. provision: - mode: system script: | if [ -L /etc/resolv.conf ] && [ ! -e /etc/resolv.conf ]; then rm -f /etc/resolv.conf echo "nameserver 192.168.5.2" > /etc/resolv.conf fiyou saved my day
Description
Starting in the last couple of months three different members of our team have reported an issue with new Colima installs. The Colima VM has a
/etc/resolv.confthat contains192.168.107.1. This address can't resolve anything, on the public internet or on our VPN.The error they encountered when trying to
docker loginordocker pullwas:To (poorly) workaround the issue we had to use:
colima delete && start --dns 8.8.8.8 --dns 172.100.100.100(where the last address is our internal DNS server for use on our VPN)This can be added to the config file for persistence between reboots but if any of these server addresses change, or a user isn't connected to our VPN it can degrade performance.
Previously Colima picked up the system DNS, but this appears to be broken - does anyone have more information/is a fix visible?
Team members with this issue are running Colima 0.5.4
Version
Colima Version: 0.5.4
Lima Version: 0.15.1
Qemu Version: 8.0.0
Operating System
Output of
colima statusReproduction Steps
colima startExpected behaviour
No response
Additional context
No response