Can't create correctly vm

[bsramin]

If I try to create a new machine with dinghy create command I receive this output:

Creating the default VM...
Starting NFS daemon, this will require sudo
Password:
Waiting for NFS daemon...
Mounting NFS /Users/ramin
Starting the FsEvents daemon
Starting DNS and HTTP proxy
setting up DNS resolution, this will require sudo
Unable to find image 'codekitchen/dinghy-http-proxy:2.5.3' locally
Pulling repository docker.io/codekitchen/dinghy-http-proxy
docker: Error while pulling image: Get https://index.docker.io/v1/repositories/codekitchen/dinghy-http-proxy/images: dial tcp: lookup index.docker.io on 192.168.64.1:53: read udp 192.168.64.21:51399->192.168.64.1:53: read: connection refused.
See 'docker run --help'.
VM: running
NFS: running
FSEV: running
DNS: stopped
PROXY: stopped

I've tried to uninstall toolbox and reinstall all docker via brew.
The only way was changing /etc/resolv.conf in the docker machine with
google dns with 'echo "nameserver 8.8.8.8" > /etc/resolv.conf'

but, how can I replicate the next steps of the dinghy create after changing the nameservers?

[codekitchen]

Sounds like your host DNS server isn't working for some reason -- what VM provider are you using? This is likely a docker-machine issue, if you use docker-machine create directly with the same VM provider and then try to pull a docker image, do you have the same problem?

[bsramin]

i'm using xhyve.
Until I replace the nameserver it doesn't work in any way. It'll definitely a problem with docker-machine. Is fixable automatically with dinghy's help?

Put a sort of try / catch on the "dinghy create" command in the pull: if that fails, replace the nameserver with google and try again: it is dirty, but I've seen around that is a common problem (with docker machine).

Thank you

[codekitchen]

I wouldn't want to make it a completely automatic thing, since it could easily be a transient problem and using google's DNS servers will cause custom name resolutions to stop working. It seems reasonable to make it an explicit option, though, or perhaps this is another use case for the "lifecycle hooks" idea that has been tossed around a couple times -- have dinghy execute shell scripts placed in ~/.dinghy at certain points in the create/start processes so people can extend it with their own logic.

[bsramin]

I think it's a good idea

[bsramin]

@codekitchen can I do a PR, for edit of cli.rb to move "start_services" out from private method?
So, we can do "dinghy create", then change resolv.conf and finally execute "dinghy start_service".

[codekitchen]

Yeah that seems reasonable. However, I think you'll have to modify resolv.conf every time you start the VM, the change won't persist.

[codekitchen]

I just ran into this myself creating a new machine with xhyve. It seems to be a new problem, or at least more common, with MacOS 10.12.

However, at least for me it wasn't permanent, DNS resolution only fails for a second or so after the DNS resolver has been configured, then it starts working as expected. It appears that MacOS takes a moment to reconfigure the DNS service, during which period all DNS lookups from the VM fail with a connection refused error.

My current workaround is to just wait for a few seconds before trying to pull the docker image, which is silly but effective. This fix is on master and will go out with the next release, probably in a couple days.

[codekitchen]

That fix has been released, let me know if you still see this problem after updating to dinghy 4.4.3

[bsramin]

Yes good job! Thank you

[qkdreyer]

I'm still having this issue using Dinghy 4.6.5 freshly installed