-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
hyperv: cannot use "fe80::215:5dff:fe45:3110" as the bind address for the API Server (IPv6) #3963
Comments
Also seeing the same issue, same Wwin v1809 version. Has anyone been able to resolve it? |
Seems to be same for me - I'm trying to spin off Minikube in Azure Windows Server 2019; and am using similar command as above mentioned for spinning off the minikube using HyperV minikube start --vm-driver hyperv --hyperv-virtual-switch "NATSwitch" --alsologtostderr --logtostderr _I0605 16:53:33.682694 5220 utils.go:240] > [Jun 5 16:53] systemd-fstab-generator[4344]: Ignoring "noauto" for root device
|
I'm experiencing the same issue running an Azure VM with Windows Server 2019. |
I am also getting the same error / issue while running the command on Azure VM Windows Server 2016 Datacenter build 1607. |
Had the same problem, was able to work around it using the "Default Switch" instead. Hope someone finds this useful |
I was getting similar error while using either a user-defined vSwitch or the default vSwitch. Disabling IPv6 in the vAdapter settings, running 'minikube delete' and then restarting resolved the issue. |
I think in some case that when an IPv4 address cannot be assigned this could happen. |
followed this suggestion. Thank you. this is working fine. |
in addition to @odytrice ,s comment , use |
Currently, the best workaround if you see IPv6 addresses trying to get passed through is to disable IPv6 in your switch settings. We're looking into either better documentation or a way to fix it on our end to avoid this happening at all. The good news is the minikube 1.4 now picked the default switch automatically and no longer requires a user-defined external switch at all. |
Apparently this can still happen with the default switch. Anyone have a tutorial on how to disable IPv6 for the default switch in Hyper-V? |
I found this link useful to explain the workaround https://medium.com/@JockDaRock/disabling-ipv6-on-network-adapter-windows-10-5fad010bca75 |
Whenever I encounter this I remove the shared virtual switch from the main network adapter and re-add it. I then disable and re-enable the main network adapter and everything starts working when I attempt to do a kubectl start again. Not ideal but it gets me back up and running every time. |
I was getting that exact error when I was rebooting my Window 10 Pro laptop. On my side I use ICS with internal VM Switch. Even if ICS seems configured correctly after reboot, starting minikube would give me that exact same error. That is why I need to reset the ICS setting after each reboot. Actually I ended up automating a call to Set-ICS.ps1 before each 'minikube start' to ensure I don't get that problem anymore. This script that you can see below is disabling ICS and re-enabling it automatically.
I hope it gets you to a working solution for your setup. Definitely there is a lack of support about minikube on Windows. But I am committed to use it since it allows for greater productivity overall. Have a look at this issue if you wonder why I use an internal VM Switch #5072 . |
Can you try:
|
Still suffering from this issue. :( reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" /v DisabledComponents /t REG_DWORD /d 0xffffffff /f
netsh interface ipv6 set global randomizeidentifiers=disable
Disable-NetAdapterBinding -Name "*" -ComponentID ms_tcpip6 |
I believe part of this is our kubeadm templates that uses the ipv4 format. |
I'm a bit confused about the fix #6241. Don't the build logs for Hyper-V on Windows exhibit exactly the problem of this issue? build log snippet
I've also tried the windows executable of this build myself and the issue still persists. Edit: More precisely, the build logs reflect the error described in #5774, which is also the exact error I am facing currently. Edit2: Hm, if I understand it correctly, then the built executable and the tests apparently don't use the "minikube.iso" of #6241 (containing the fix), which explains my observations above. So, I tried starting minikube by providing the iso manually:
I am not familiar with what is happening underneath, but from what I gathered from this and related issues is, that on my machine only an IPv6 address is provided to minikube, but never an IPv4 address. |
/reopen |
@AlexKulizhnikov: You can't reopen an issue/PR unless you authored it or you are a collaborator. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Problem
minikube start fails with
cannot use "fe80::215:5dff:fe45:3110" as the bind address for the API Server
command-lines
The full output of the command that failed
The output of the "minikube logs" command, if applicable
Which operating system version was used
Windows 1809 Build 17763.379
Notes
It looks like IPv4 is not initialized within virtual machine.
This gets fixed when I connect to console in HyperV, login via docker/tcuser and execute
ping k8s.gcr.io
.After that when I ssh into virtual host and execute
sudo kubeadm config images pull --config /var/lib/kubeadm.yaml
it finishes OK:But ... problem with
cannot use "fe80::215:5dff:fe45:3110" as the bind address for the API Server
still present when i manually re-executesudo /usr/bin/kubeadm init <... see full command in the log above ...>
The text was updated successfully, but these errors were encountered: