colima: DNS names that can't be resolved in Colima, possibly only with gvproxy network driver

After some messing around, this seems to be the fix:

colima delete
colima start --edit

Change gvproxy to slirp. With such a limitation/bug, I wonder why it’s not the default.

@abiosoft https://wiki.musl-libc.org/functional-differences-from-glibc.html

Multiple reports on weird musl dns incompatibility with glibc. I think it is safer to use base image like debian for this.

I can add sbp-plugin-binaries.s3.eu-west-1.amazonaws.com

If indeed using slirp as the network driver fixes it, this should be resolved by the next release v0.5.0.

I hit this while running a container which does a lot of AWS service requests. DNS resolution would fail after some time when using vz vm, then subsequent run would fail almost immediately and only colima restart helped to get more time without DNS failures. And with qemu and slirp network driver it was actually even worse. So I resorted to Docker Desktop which runs without problems. Sad.

Hi! I started with colima version 0.5.5 two months ago and changing the config + restart worked fine for me today (without deleting).

@rfay just mentioned in DDEV discord the following:

If you have had your colima instance through many updates, it’s a worthwhile thing to delete it and recreate it. (After saving away databases of course via ddev snapshot -a)

So depends on how many updates happened in the meantime I guess?

@gpsa you’re making a bit of a mess of this issue. Could you please open one that’s on-topic for your issues?

I’ve observed sporadic failures with golang.org; I’m running on a 2021 Mac M1 Silicon using the vz virtualization driver. This manifests when using the devcontainer cli to build workspace images.

 $ yq '.network.driver' "$(colima template --print)"
gvproxy

$ colima version
colima version 0.5.2
git commit: 6b5b6fe0540e708f0c9d6e8919fab292c671fc72

runtime: docker
arch: aarch64
client: v23.0.1
server: v20.10.20

If anyone wants to switch, the following should also possible

colima start --edit
# change value with "i" insert mode, switch to slirp
# save via ":wq:"

Or edit ~/.colima/default/colima.yaml and re-start colima via colima stop and colima start.

No need for colima delete (as far as I know).

For me, after simply restarting nothing seemed to be working. To be more specific, a docker build failed right at the beginning, because it could not even resolve registry-1.docker.io. It was an i/o timeout right there, suggesting all/most networking was broken in the VM. I got the idea for the delete from here.

@abiosoft Is there a way to recreate it without destroying everything? I could try to see if by recreating would work

@gpsa yeah. It’s a regression actually, used to work before. You can edit the /etc/resolv.conf file in the VM and set the nameserver IP to 192.168.5.3.

In fact, it is the only entry in the file so you can simply replace it

colima ssh -- sudo sh -c 'echo "nameserver 192.168.5.3" > /etc/resolv.conf'

@abiosoft thank you so much, that worked like a breeze. Now both internal Docker DNS and external domains work just fine on SLIRP.

@abiosoft Is there a way to recreate it without destroying everything? I could try to see if by recreating would work

@gpsa yeah. It’s a regression actually, used to work before. You can edit the /etc/resolv.conf file in the VM and set the nameserver IP to 192.168.5.3.

In fact, it is the only entry in the file so you can simply replace it

colima ssh -- sudo sh -c 'echo "nameserver 192.168.5.3" > /etc/resolv.conf'

Edited, thanks @renatho