Minikube: hyperv: ssh: connectex: A connection attempt failed because the connected party did not properly respond

[siri-rao]

BUG REPORT

minikube version: v0.24.1
Windows 10
Hyper-V
minikube-v0.23.6.iso

What happened:

Trying to run minikube on Windows 10 laptop ( HyperV enabled, running Docker for Windows 17.09.1-ce-win42). Created a virtual switch for internal network since using external network switch is causing wifi problems at office.

Executed this command:

./minikube start --kubernetes-version="v0.24.1" --vm-driver="hyperv" --hyperv-virtual-switch="VmNAT" --v=7 --alsologtostderr

The docker machine returns an IPv6 address, minikube is not able to ssh into that machine. Please note that I have disabled IPv6 address on the virtual NIC but it does not help.

Running the command "minikube ip" returns fe80::215:5dff:fedc:eb17

What you expected to happen:

Minikube to start running

How to reproduce it (as minimally and precisely as possible):

Output of minikube logs (if applicable):

[stderr =====>] :
[executing ==>] : C:WINDOWSSystem32WindowsPowerShellv1.0powershell.exe -NoProfile -NonInteractive (( Get-VM minikub
e ).networkadapters[0]).ipaddresses[0]
[stdout =====>] : fe80::215:5dff:fedc:eb17

[stderr =====>] :
[executing ==>] : C:WINDOWSSystem32WindowsPowerShellv1.0powershell.exe -NoProfile -NonInteractive ( Get-VM minikube
).state
[stdout =====>] : Running

[stderr =====>] :
setting hostname "minikube"
[executing ==>] : C:WINDOWSSystem32WindowsPowerShellv1.0powershell.exe -NoProfile -NonInteractive ( Get-VM minikube
).state
[stdout =====>] : Running

[stderr =====>] :
[executing ==>] : C:WINDOWSSystem32WindowsPowerShellv1.0powershell.exe -NoProfile -NonInteractive (( Get-VM minikub
e ).networkadapters[0]).ipaddresses[0]
[stdout =====>] : fe80::215:5dff:fedc:eb17

[stderr =====>] :
SSH binary not found, using native Go implementation
&{{{ 0 [] [] []} docker [0x83feb0] 0x83fe60 [] 0s} fe80::215:5dff:fedc:eb17 22 }
About to run SSH command:
sudo hostname minikube && echo "minikube" | sudo tee /etc/hostname
Error dialing TCP: dial tcp [fe80::215:5dff:fedc:eb17]:22: connectex: A connection attempt failed because the connected
party did not properly respond after a period of time, or established connection failed because connected host has faile
d to respond.

Anything else do we need to know:
Minikube was running successfully with External Network switch. But this configuration cannot be used in our office network since it conflicts with existing IPs

[harshkumar1]

Is there a work around for this issue... Have hit the same while trying to run minikube on WINDOWS 10

[gbraad]

You should use an external network, an internal network with a dhcp server
or the new default switch

On Monday, March 5, 2018, Harsh Kumar [e-mail] wrote:

Is there a work around for this issue... Have hit the same while trying
to run minikube on WINDOWS 10

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.<
https://ci4.googleusercontent.com/proxy/c2BjZHrYN0dkYOE6Lww1xD2EnApOmsoF1zamx9Gh1BRC2WNe56nYroRV5zzzbNSj0fMB_U1WBVD8QstTUiwCGlq9qf9mbq1Zl8kZCzbwiO1-i89mPaQZ9ZprLyn5GeFXsfuWZuz1XhgZQExrh_31Odm7Mi3qcg=s0-d-e1-ft#https://github.com/notifications/beacon/AAAHZrufGiRzzi2lXlWxTgmHOWBZmFBWks5tbTw9gaJpZM4RZxGW.gif

--

Gerard Braad | http://gbraad.nl
[ Doing Open Source Matters ]

[briansmith]

or the new default switch

This doesn't consistently work:
[stderr =====>] :
[executing ==>] : C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive (( Get-VM minikube ).networkadapters[0]).ipaddresses[0]
[stdout =====>] : 172.25.54.119

[stderr =====>] :
Waiting for SSH to be available...
Getting to WaitForSSH function...
[executing ==>] : C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive ( Get-VM minikube ).state
[stdout =====>] : Running

[stderr =====>] :
[executing ==>] : C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive (( Get-VM minikube ).networkadapters[0]).ipaddresses[0]
[stdout =====>] : fe80::215:5dff:fe51:2600

Note that the IPv4 address was found first and then an IPv6 address was found second.

It would work more reliably if the IP address were looked up once and then passed to all the things that need it, instead of having the things that need the IP address look them up themselves.

[navono]

I have the same problem. When I start in Git bath with admin with:

minikube start --vm-driver="hyperv" --hyperv-virtual-switch="k8s" --v=7 --alsologtostderr

finally got:

[stderr =====>] :
Using SSH client type: native
&{{{ 0 [] [] []} docker [0x83ffb0] 0x83ff60 [] 0s} fe80::215:5dff:fec8:6504 22 }
About to run SSH command:
exit 0
Error dialing TCP: dial tcp [fe80::215:5dff:fec8:6504]:22: connectex: A connection attempt failed because the conne cted party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

[jwgain0]

I am having the same or very similar problem. I am searching through open issues to see if anyone has a work around for my problem. Again this looks very similar. Attempting to use Windows 10/Hyper-v. I have setup a Virtual Switch (external network with Ethernet network adapter). I am using release 0.25.2 to get around #2634.

I run the following command in powershell:
minikube start --vm-driver="hyperv" --memory=4096 --hyperv-virtual-switch="My Virtual Switch" --v=7 --alsologtostderr

The script goes along for while. It even successfully creates the minikube VM. But then it gets to a point where it continually polls for the vm's state and ip address. It appears the command to get the network adapter IP address returns nothing. But command to retrieve the state returns "Running". It does this several times until it just hangs indefinitely.

If I then open another powershell instance and do kubectl cluster-info, it initially says Kubernetes master is running at http://localhost:8080 but then receives an error stating it couldn't connect to target machine because connection has been actively refused.

Update: Minikube ssh does not work. But if I connect to the VM via Hyper-V Manager, I can execute curl commands, so it does have network connectivity with my Virtual Switch

[stephenpope]

@briansmith Just in case it might help. I had this exact same issue (and was getting very frustrated!)..

i would run the command (minikube start --vm-driver=hyperv --hyperv-virtual-switch="Default Switch" --v=7) at first it would pick up the IPV4 address and issue the SSH commands.. after a few commands it would seem to lose the IPV4 address and only get the IPV6 address (which then wouldnt accept SSH). Ever time I ran it it would fail at a different point, the IPV4 address seemingly just randomly dropping off. The annoyance was that the script constantly asked for the IP which seemed to be in a state of flux.

The solution for me (and I hope this solves it for a few other people) was to not use WIFI. When i used a wired/ethernet connection all those problems went away and it all worked fine and minikube installed without a problem. I dont know if its something to do with HyperV / Default Switch and wireless network cards but I would advise trying with a wired connection.

Hope this helps you / others who might be seeing this.

[borysl]

I have the same problem with IPv4, so use of IPv6 should not be an issue:

minikube start --vm-driver=hyperv --hyperv-virtual-switch=pvs --kubernetes-version="v1.10.0" --v
=7 --alsologtostderr --memory=4096

I0713 13:08:25.938050   15900 cluster.go:83] Machine state:  Running
Waiting for SSH to be available...
Getting to WaitForSSH function...
[executing ==>] : C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive ( Hyper-V\Get-VM minikube ).state
[stdout =====>] : Running

[stderr =====>] :
[executing ==>] : C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive (( Hyper-V\Get-VM minikube ).networkadapters[0]).ipaddresses[0]
[stdout =====>] : 192.168.1.114

[stderr =====>] :
SSH binary not found, using native Go implementation
&{{{<nil> 0 [] [] []} docker [0x83ffb0] 0x83ff60  [] 0s} 192.168.1.114 22 <nil> <nil>}
About to run SSH command:
exit 0
Error dialing TCP: dial tcp 192.168.1.114:22: connectex: No connection could be made because the target machine actively refused it.
Error dialing TCP: dial tcp 192.168.1.114:22: connectex: No connection could be made because the target machine actively refused it.
Error dialing TCP: dial tcp 192.168.1.114:22: connectex: No connection could be made because the target machine actively refused it.
Error dialing TCP: dial tcp 192.168.1.114:22: connectex: No connection could be made because the target machine actively refused it.

With native client result is the same

[stderr =====>] :
Using SSH client type: native
&{{{<nil> 0 [] [] []} docker [0x83ffb0] 0x83ff60  [] 0s} 192.168.1.114 22 <nil> <nil>}
About to run SSH command:
exit 0
Error dialing TCP: dial tcp 192.168.1.114:22: connectex: No connection could be made because the target machine actively refused it.
Error dialing TCP: dial tcp 192.168.1.114:22: connectex: No connection could be made because the target machine actively refused it.

[isurugiu]

I am getting the same issue when running v0.29.0. I cannot find any authorized key entry within the docker account range inside the minikube machine, so i'm thinking at three potential fixes:

• bake the key in the ISO (bad)
• provision the key during bootstrap (better)
• overall I would love to be able to run something like minukube start --ssh-user pinky --ssh-key /path/to/glory

I solved my problem by running PS C:\WINDOWS\system32> cat C:\Users\iulian\.minikube\machines\minikube\id_rsa.pub | ssh docker@minikube "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys" in a separate PS instance after minikube VM was up & running and got an IP from DHCP

Best,
-Iulian

[kodeva]

I have work-arounded this issue by using an internal switch (named "Internal"):

minikube start --vm-driver=hyperv --hyperv-virtual-switch="Internal" --memory=4096 --cpus=4 --v=7 --alsologtostderr

[matthiasg]

@kodeva does kubernetes work fine with an internal network though ? doesn't it require outside access to the docker container registry ?

[kodeva]

Yep, it worked nicely for me. The "internal" actually means that the VMs can access internet, but are only accessible from the local machine.
On contrary, VMs using the "external" switch can be access from outside networks as well.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[rajendragosavi]

Yes, Even I am facing the same issue. I installed minikube with LAN port, that time it received IPv4 address and it worked fine. Later i deleted the cluster and tried to bring up the cluster again with system connected to wireless connection, it received IPv6 address.

I switched back to LAN port and then i started to work fine.

Maybe minikube expects IPv4 address to SSH.

Thanks

[tstromberg]

@author: I believe this issue is now addressed by minikube v1.4, as it now defaults to using the
Hyper-V "Default Switch". If you still see this issue with minikube v1.4 or higher, please reopen this issue by commenting with /reopen

Thank you for reporting this issue!

[JoshuaCWebDeveloper]

This likely warrants no action, but I'm commenting here in case it helps someone else. I faced this exact same problem on Minikube v1.6.2. I tried explicitly specifying the "Default Switch", an internal switch, and an external switch and also not specifying a switch at all: none of these made a difference.

The culprit turned out to be that I was connected to a corporate VPN (using the Cisco client) that is notorious for causing internet connection issues with a variety of programs. Once in a while it causes local network issues too. This instance may be related to #1265 (had a hard time following that issue).

[cotyhamilton]

The culprit turned out to be that I was connected to a corporate VPN (using the Cisco client)

... disconnected from corporate VPN (cisco) and was able to start minikube. Thanks!