start failed: timed out waiting for instance to respond (on Windows 10 host)

[ColinIanKing]

Running latest multipass (as of 1st April 2019) on Windows 10 Pro Xeon host with 8 CPUs + 16GB of memory. My network is 200mbit/sec so it's fast enough network + host IMHO.

multipass launch -c 8 -m 8G 16.04

.. after a long while I see the timeout message. No idea how to work around this.

"start failed: timed out waiting for instance to respond"

[townsend2010]

@ColinIanKing,

Sounds like it could be related to the virtual networking. Could you look in the Event Viewer and see if you see anything there? Also, in the Hyper-V Manager->Virtual Switch Manager, do you see an called "Default Switch"? Lastly, which build of Windows are you using?

[ColinIanKing]

Update: creating a vm with 2GB and 8 CPUs seems to work, so it maybe a memory constraint.

[ColinIanKing]

OK, seems like anything > ~6GB is not able to start and times out. :-(

[ColinIanKing]

So the timeout error message could be improved if it's possible to detect such failures. Took me a while to figure out what the failure was.

[Saviq]

Agreed, we need to realize the instance failed to start at all (as I'm expecting Hyper-V returned an error here).

[ntherrien]

We are having the same issue, on Windows 10 Host.

No errors in Hyper-V event viewer.

We can perform "multipass list" and see the vms in running state. But when we try to execute a command on it we are getting "ssh connection failed: 'Failed to resolve hostname microk8s-vm.mshome.net" where "microk8s-vm" was the name of the VM.

[Saviq]

Hi @ntherrien I think yours is a slightly different issue, and one more like #1052 - can you try creating a fresh VM from the Hyper-V Gallery and see if it gets networking fine? And whether its IP is reachable via "ping .mshome.net"?

[ntherrien]

Hi @Saviq, thanks for your response. Solution for us was to restart the Hyper-V default switch. It seems like the internal network was not allowing internet access. We realized that when we tried to do a vm manually and then download microk8s on it. I don't know why this happenned on two different machines but thanks for your help.

[Saviq]

@ntherrien glad you got it going, could you please document what exact steps you needed to take to unclog it? Thanks!

[ntherrien]

Of course @Saviq! Here goes:

In both cases, we went to the network adapters control panel, right clicked the default switch, selected Disable and then Enabled it again. That forced the adapter to obtain/refresh a LAN IP address on the same subnet as the ones allocated to the VMs attached to that default switch.

At first, I thought the problem could easily be detected by running ipconfig and verifying if the default switch was assigned a link-local address (169.254..) but this is not always the case. We had one computer which had a valid LAN address in the first place, and still had no route to the vms. Disabling/Enabling the default switch has fixed the problem in both cases, though.

We can also ping vmname.mshome.net as expected after doing this.

we are going to be paying attention as to whether the problem with the default switch still occurs after a reboot.

[mainrs]

I'm still experiencing this problem on my Windows 10 machine. It's my desktop computer without any network adapters installed beside the WiFi one that I use (which probably gets added after connecting to it...?)