Minikube: HyperV minikube is actively refusing connections to 8443

[helloworlddan]

Is this a BUG REPORT or FEATURE REQUEST? (choose one):

Minikube version (use minikube version): v0.18.0

Environment:

• OS (e.g. from /etc/os-release): WIN 10 Enterprise
• VM Driver (e.g. cat ~/.minikube/machines/minikube/config.json | grep DriverName): HyperV
• ISO version (e.g. cat ~/.minikube/machines/minikube/config.json | grep -i ISO or minikube ssh cat /etc/VERSION): minikube-v0.18.0.iso
• Install tools:
• Others:

What happened: After the installation of the minikube-iso, the hyperv-machine is actively refusing a TCP connection to itself on 8443, initiated via kubectl

What you expected to happen: kubectl/minikube can connect to the VM on 8443

How to reproduce it (as minimally and precisely as possible): Blank WIN 10 Enterprise Install (all updates), minikube v18: start cluster --vm-driver hyperv (succesful creation), afterwards minikube dashboard fails:

Could not find finalized endpoint being pointed to by kubernetes-dashboard: Error validating service: Error getting service kubernetes-dashboard: Get https://[fe80::215:5dff:fe38:104]:8443/api/v1/namespaces/kube-system/services/kubernetes-dashboard: dial tcp [fe80::215:5dff:fe38:104]:8443: connectex: No connection could be made because the target machine actively refused it.

Anything else do we need to know: Might IPv6 be a problem here?

[helloworlddan]

I just checked: the problem persists with minikube v0.19.0

[aaron-prindle]

Can you post the output of minikube start w/ additional logging:
minikube start --v=10 --vm-driver hyperv

As well as the output of minikube logs once it has started

[bleleve]

Hi Aaron,

Same problem here. Everything was working great with Minikube v0.17.1.

Here are the logs.

May 12 08:50:53 minikube localkube[3570]: I0512 08:50:53.648758    3570 ready.go:30] Performing healthcheck on http://127.0.0.1:8080/healthz
May 12 08:50:53 minikube localkube[3570]: E0512 08:50:53.649239    3570 ready.go:33] Error performing healthcheck: Get http://127.0.0.1:8080/healthz: dial tcp 127.0.0.1:8080: getsockopt: connection refused
May 12 08:50:53 minikube localkube[3570]: I0512 08:50:53.734752    3570 interface.go:259] No valid IP found
May 12 08:50:53 minikube localkube[3570]: apiserver: Exit with error: Unable to find suitable network address.error='Unable to select an IP.'. Try to set the AdvertiseAddress directly or provide a valid BindAddress to fix this.
May 12 08:50:53 minikube localkube[3570]: I0512 08:50:53.935422    3570 interface.go:259] No valid IP found
May 12 08:50:53 minikube localkube[3570]: apiserver: Exit with error: Unable to find suitable network address.error='Unable to select an IP.'. Try to set the AdvertiseAddress directly or provide a valid BindAddress to fix this.

Best regards.

[mrts]

Same problem here as well. Downgrading to v0.17.1 did unfortunately not help, minikube start --vm-driver=hyperv gets stuck in the following infinite loop in v0.17.1:

Getting to WaitForSSH function...
(minikube) Calling .GetSSHHostname
(minikube) DBG | [executing ==>] : C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive ( Get-VM minikube ).state
(minikube) DBG | [stdout =====>] : Running
(minikube) DBG |
(minikube) DBG | [stderr =====>] :
(minikube) DBG | [executing ==>] : C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive (( Get-VM minikube ).networkadapters[0]).ipaddresses[0]
(minikube) DBG | [stdout =====>] :
(minikube) DBG | [stderr =====>] :
Error getting ssh command 'exit 0' : IP not found

[whereisaaron]

I thought for Hyper-V a Virtual Switch was required to be created and named, as per the install docs? Maybe this is more important or required now. Certainly I need to do this to using Windows 10 1703 with Hyper-V:

https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver

You need to create an 'External address' 'Virtual Switch' in Hyper-V:

https://docs.docker.com/machine/drivers/hyper-v/

and then name that when you first start your minikube:

minikube start --vm-driver hyperv ----hyperv-virtual-switch "Primary Virtual Switch"

I suggest you create the switch, and then delete and start minikube with the switch setting:

minikube delete
minikube start --vm-driver hyperv ----hyperv-virtual-switch "Primary Virtual Switch"

[lostmsu]

@whereisaaron explicitly connecting to a LAN-attached switch did not solve that problem for me. Now it correctly assigns IP to be in my LAN (192.168.1.8), but connection to https://192.168.1.8:8443 is still refused.

[dkirrane]

Had the same issue. Created the Virtual switch rebooted and the following worked

minikube delete
rm -Rf ~/.minikube/
rm -Rf ~/.kube/
minikube start --vm-driver hyperv ----hyperv-virtual-switch "Primary Virtual Switch"

[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.

Prevent issues from auto-closing with an /lifecycle frozen comment.

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

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

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 rotten
/remove-lifecycle stale

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

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

[RobertDiebels]

To anyone who is reading this to check for a solution when getting the "actively refused"-error. I found an answer** in this comment.

Rebooting did not work for me and I was also getting dashboard errors.
I am currently running on v0.24 and I've not had the problem since I followed the suggestions in the comment.

[anadil]

more than three entries found in /etc/resolv.conf