-
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
virtualbox: minikube ip changes after laptop suspend/resume #9479
Comments
Looks like it uses the wrong interface, since 172.17.0.1 is normally |
I'm not sure how it would get that address. I have docker0 on my machine configured to use 100.121.23.2/26.
|
Not sure either, will try with your settings. Just that it happens to be the default docker network. |
It is worth noting that if I run |
I suppose you could try EDIT: Hmm, maybe that only reads the config though |
The virtualbox driver is looking for the MAC of the host-only adapter, and then tries to find that MAC in "ip addr show" Something like: $ VBoxManage showvminfo minikube --machinereadable | grep ^hostonlyadapter
hostonlyadapter2="vboxnet0"
$ VBoxManage showvminfo minikube --machinereadable | grep ^macaddress2
macaddress2="08002751D555" $ minikube ssh ip addr show | grep -A1 -i "08:00:27:51:D5:55"
link/ether 08:00:27:51:d5:55 brd ff:ff:ff:ff:ff:ff
inet 192.168.99.188/24 brd 192.168.99.255 scope global dynamic eth1 The actual go code in: https://github.com/docker/machine/blob/v0.16.2/drivers/virtualbox/virtualbox.go#L710_L802 |
Based on our discussion from slack:
|
So there are two bugs here:
Note that even if the bug is fixed, and it starts waiting for a "new" address - it still takes VirtualBox 1m13s to provide one! |
The changes between @@ -3452,13 +3363,23 @@ static int link_carrier_gained(Link *link) {
assert(link);
- if (!IN_SET(link->state, LINK_STATE_PENDING, LINK_STATE_UNMANAGED, LINK_STATE_FAILED)) {
+ r = wifi_get_info(link);
+ if (r < 0)
+ return r;
+ if (r > 0) {
+ r = link_reconfigure(link, false);
+ if (r < 0)
+ return r;
+ }
+
+ if (IN_SET(link->state, LINK_STATE_CONFIGURING, LINK_STATE_CONFIGURED)) {
r = link_acquire_conf(link);
if (r < 0) {
link_enter_failed(link);
return r;
}
+ link_set_state(link, LINK_STATE_CONFIGURING);
r = link_request_set_addresses(link);
if (r < 0)
return r;
Could be worth testing with the new minikube ISO (that has systemd 244.5), to see if it helps anything ? You can see the current state of systemd-networkd like so: $ minikube ssh -- networkctl --no-pager list
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 eth0 ether routable configured
3 eth1 ether routable configured
4 sit0 sit off unmanaged
5 docker0 bridge routable unmanaged
7 veth0aebfa1 ether carrier unmanaged
6 links listed. The eth0 is the nat, and the eth1 is the hostonly (see #4938) |
Here is a fix for the driver: machine-drivers/machine@master...afbjorklund:virtualbox-ipaddr |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
@afbjorklund - any luck with merging this? |
It's worth noting that this should not happen with the Docker driver any longer, but is likely to happen on other drivers. |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
Is there any update about this issue and merge of the fix? Can't use minikube with virtualbox at all. |
@afbjorklund Has your fix for libmachine been merged? |
To start minikube I am running
This starts minikube in a desired state. I can then stop/start it all day long.
The issue seems to arise when my laptop suspends itself after closing the lid. When it resumes, I can run minikube status and after some time I get:
In order to get the api server running again, I execute the exact same minikube start command above and get:
The IP address appears to have changed to 172.17.0.1, which is confusing. Since this IP is not routable given my Cisco AnyConnect settings, everything fails.
I'm happy to provide any additional info as needed.
The text was updated successfully, but these errors were encountered: