Multipass for Windows instance cannot resolve hostnames

[marksztainbok-okta]

I just installed the beta of the Windows Multipass and set up an instance and found that it cannot resolve hostnames.

When I attempted to resolve a hostname, I'm getting an error similar to this:

multipass@dev:~$ ping www.google.com
ping: www.google.com: Temporary failure in name resolution

It's not a network connectivity issue as if I use an IP address I can successfully communicate:

multipass@dev:~$ ping 216.58.195.68
PING 216.58.195.68 (216.58.195.68) 56(84) bytes of data.
64 bytes from 216.58.195.68: icmp_seq=1 ttl=56 time=24.0 ms
64 bytes from 216.58.195.68: icmp_seq=2 ttl=56 time=24.6 ms
64 bytes from 216.58.195.68: icmp_seq=3 ttl=56 time=24.6 ms
^C
--- 216.58.195.68 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 24.020/24.430/24.636/0.316 ms

I configured instance using the 18.04.1 image and am running Windows 10 Enterprise version 10.0.17763 N/A Build 17763.

My resolv.conf in the instance contains the folllowing:

nameserver 127.0.0.53
search mshome.net

Any ideas what could be wrong and how to fix it?

[townsend2010]

Hi @marksztainbok-okta,

Thank you for reporting this issue. Are you running a firewall? If so, perhaps you need to allow instances access to DNS? But it certainly seems like something is blocking DNS lookup on the virtual network.

[Saviq]

127.0.0.53 is the local DNS caching server of systemd-resolve. To see the actual upstream DNS server, you can use systemd-resolve --status inside the instance - look for something similar to:

  Current DNS Server: 10.2.0.1
         DNS Servers: 10.2.0.1

Can you try pinging the address listed there? Also, the equivalent of dig google.com @10.2.0.1? Try with TCP using dig +tcp google.com @10.2.0.1?

Ultimately, it's Hyper-V providing the "Default Switch" network in the Hyper-V manager, and that's what should be handling the DHCP (which it does do, since you were able to reach the instance in the first place) as well as DNS (which seems broken in your case).

As a workaround, you could use the public 8.8.8.8 google's DNS. Note resolv.conf might still get overwritten, so read up about resolvconf to ensure your changes persist.

[marksztainbok-okta]

I don't see any DNS servers there in the output from that:

multipass@dev:~$ systemd-resolve --status
Global
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

Link 2 (eth0)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
          DNS Domain: mshome.net

[Saviq]

That's likely the culprit then, your Windows DHCP didn't give your instance a DNS address... Can you check and launch any other VM manually with the Hyper-V manager, connect it to the Default Switch and see if you get a happy network?

[marksztainbok-okta]

I thought maybe a reboot might help as I was playing with the Default Switch network card settings and messed something up. The settings got restored but for some reason now multipassd won't start. I can go into Services and start it and look in the Event Log and says it started but then it stops running.

[debsahu]

same issue here.

[debsahu]

Manually edited /etc/resolv.conf with cloudfare DNS nameserver 1.0.0.1 and everything is working now.

[townsend2010]

By chance, is anyone here using Docker Linux Containers on Windows (LCOW)? Having that running affects non-Docker VM's from having a usable DNS provided by the Hyper-V default switch.

See minishift/minishift#1792 (comment) and docker/for-win#1166 (comment).

[marksztainbok-okta]

Yeah I do have Docker for Windows installed and running.

I actually have bigger problems with multipass which are that I can't run it at all since rebooting as now multipassd won't start successfully for some reason. Is there some log or something I can look at to work out why that may be?

[townsend2010]

@marksztainbok-okta,

Thank you for confirming that you have Docker for Windows running. We'll have to think about how best to work around the issue where the Hyper-V Default Switch only allows sharing by one service.

Regarding the multipassd failure, have you tried starting multipassd manually in an elevated command prompt and see if it outputs any failures?

Something like C:\WINDOWS\system32>multipassd -V debug (or wherever you installed multipass) should try to start it up.

You might be hitting #573.

[marksztainbok-okta]

This is the log:

E0124 11:29:43.891000000 32384 server_secure_chttp2.cc:84] {"created":"@1548358183.891000000","description":"No address added out of total 2 resolved","file":"..\3rd-party\grpc\src\core\ext\transport\chttp2\server\chttp2_server.cc","file_line":307,"referenced_errors":[{"created":"@1548358183.891000000","description":"Failed to add port to server","file":"..\3rd-party\grpc\src\core\lib\iomgr\tcp_server_windows.cc","file_line":509,"referenced_errors":[{"created":"@1548358183.891000000","description":"OS Error","file":"..\3rd-party\grpc\src\core\lib\iomgr\tcp_server_windows.cc","file_line":201,"os_error":"An attempt was made to access a socket in a way forbidden by its access permissions.\r\n","syscall":"bind","wsa_error":10013}]},{"created":"@1548358183.891000000","description":"Failed to add port to server","file":"..\3rd-party\grpc\src\core\lib\iomgr\tcp_server_windows.cc","file_line":509,"referenced_errors":[{"created":"@1548358183.891000000","description":"OS Error","file":"..\3rd-party\grpc\src\core\lib\iomgr\tcp_server_windows.cc","file_line":201,"os_error":"An attempt was made to access a socket in a way forbidden by its access permissions.\r\n","syscall":"bind","wsa_error":10013}]}]}
error: Failed to start multipass gRPC service at localhost:50051

It looks like it is a similar issue

[townsend2010]

@marksztainbok-okta,

Yep, I think either Docker or Hyper-V has reserved that port:(

For a temporary workaround, you can set the address option in multipassd and set the MULTIPASS_SERVER_ADDRESS for client to get it working like in the aforementioned bug report.

Sorry about all of this frustration, but it's good to know what the issues are.

[marksztainbok-okta]

I tried the workaround but after it started multipassd and I do a multipass ls I no longer see the instance I had created. The instance is started and running in Hyper-V.

I tried restarting the VM but multipass ls is still reporting No instances found

[townsend2010]

Did you happen to uninstall and reinstall multipass? If you did, then the internal database multipass uses for its instances was wiped. You'll need to delete the running VM in the Hyper-V Manager and create a new instance in multipass.

[marksztainbok-okta]

I did not. It's the same installation. It seems like there should be a way to reattach an instance to the database in this case. Because of the DNS issue I hadn't configured the instance yet but I would have been exceptionally annoyed if I had invested time in configuring it and then found I couldn't access it.

[townsend2010]

Ah, ok, I think I know why it's not showing up in multipass. It's because the original instance was created when multipassd was running as a system service and so it stored the database in a different place than when running it manually due to the pathing of the environment.

Perhaps modifying the multipassd system service to use the address option may fix this.

[marksztainbok-okta]

I changed the service command line to "C:\Program Files\Multipass\bin\multipassd.exe" --address localhost:5001 /svc. The service starts and I can see in the event log that it binds to port 5001. However the Windows SCM does not recognize that the service started and get an error that it didn't respond in a timely manner and Windows kills it ☹️

[townsend2010]

Good grief...I'll look into if there is way to make that work.

[townsend2010]

Ok, I was able to make it work by doing the following:

1. Stop the Multipass service.
2. Open the Multipass Service Properties.
3. Under Start parameters near the bottom of the window, add --address localhost:5001 (or whatever port).
4. Start the service.

I did this and now have multipassd running as a service listening on port 5001. Hopefully this will work for you.

[townsend2010]

Another bug report supporting the DNS issue and Docker:
docker/for-win#1166 (comment)

[marksztainbok-okta]

Ok, I was able to make it work by doing the following:

1. Stop the Multipass service.
2. Open the Multipass Service Properties.
3. Under Start parameters near the bottom of the window, add --address localhost:5001 (or whatever port).
4. Start the service.

I did this and now have multipassd running as a service listening on port 5001. Hopefully this will work for you.

This doesn't work for me. The service looks like it starts successfully but then stops for some reason. The services UI says it is Running but if you refresh then it isn't again.

[ricab]

A bit of a shot in the dark, but do you have an internet connection when that happens? Because we currently have an open bug where multipassd fails to start when it can't access image hosts: #555

[ricab]

@marksztainbok-okta can you please also include -V debug in the Start parameters?

[marksztainbok-okta]

I do have an internet connection at the time I'm starting multipassd.

I've added the parameter. Does it produce logs somewhere I can look to see what the issue is?

[ricab]

Yes, you can access them in the Event Viewer, under "Windows Logs->Application". Is there anything suggestive?

[marksztainbok-okta]

No it says the service started but then it didn't.

[townsend2010]

Hmm, I'm not really sure what's going on at this point. multipassd --address localhost:5001 will still start manually, but not start fully when adding the --address localhost:5001 to the Start parameters?

[marksztainbok-okta]

That is correct

[Saviq]

We've not seen this in a while, please reopen if you have this issue still.

[pcgeek86]

This ought to fix it. Don't modify /etc/resolv.conf directly, per the built-in docs.

sudo netplan set ethernets.eth0.nameservers.addresses=[8.8.8.8,8.8.4.4]
sudo netplan apply

[iwnow]

This ought to fix it. Don't modify /etc/resolv.conf directly, per the built-in docs.

sudo netplan set ethernets.eth0.nameservers.addresses=[8.8.8.8,8.8.4.4]
sudo netplan apply

it's works, thank you! @pcgeek86

[changemenemo]

So multipass for windows, whether it's virtualbox or hyper-V, can't rely on the dns client from windows itself to serve it dns resolution?
If that's the case, it would be nice to put it in the documentation