Support for predictable IP's across restarts

RaeesBhatti commented 7 years ago

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

Minikube version (use minikube version): v0.14.0

Environment:

OS : macOS Sierra 1.12.1
VM Driver : xhyve
Docker version: 1.11.1
Install tools:
Others:

What happened: Minikube changes IP address when recreated.

What you expected to happen: Minikube should retain the IP address when deleted and created again.

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

minikube start --vm-driver=xhyve
minikube ip (note the IP address)
minikube stop
minikube delete
minikube start --vm-driver=xhyve
minikube ip (IP address has changed)

Anything else do we need to know: I have several things configured to Minikube's IP address and have to recreate it occasionally. They all have to be reconfigured each time. It would be convenient to have Minikube not change its IP address after deleting and recreating.

ankon commented 7 years ago

This also happens with the kvm driver, but not with the virtualbox driver.

Would be great if one could force a fixed IP address when using minikube start, independent of the driver.

r2d4 commented 7 years ago

There is an option with the xhyve driver to set a static IP. By setting a static UUID here [0], you can ensure that you get the same IP across deletes/starts. We had this feature enabled for awhile but disabled it again because there were some issues. The discussion of the issues starts with this comment and continues in this issue. [1]

I think that this is a great feature to have, we just need to figure out the networking issues.

[0] https://github.com/zchee/docker-machine-driver-xhyve/blob/master/xhyve/xhyve.go#L70 [1] https://github.com/kubernetes/minikube/issues/708#issuecomment-255120598

dongsupark commented 7 years ago

Same here. I have been seeing the issue that the IP address of VM changes across restarts. It happens only with --vm-driver=kvm, not with --vm-driver=virtualbox. I don't know about the xhyve driver.

georgecrawford commented 7 years ago

I'm seeing this with the xhyve driver as well. Any updates on a fix?

tmirks commented 7 years ago

@georgecrawford There's a workaround by manually (or programmatically) updating /var/db/dhcpd_leases. I believe you can just delete the contents (make a backup just in case).

ankon commented 7 years ago

I've by now seen this also with the virtualbox driver: typically my VM is 192.168.99.100, but sometimes it ends up as .101 or similar. Removing the minikube VM in those cases seems to help.

gheibia commented 7 years ago

Same issue here. I'm using KVM and I don't even delete the cluster. I simply stop and start it again. I even tried to change dnsmasq's configuration to limit the DHCP's address range. Didn't make a difference.

n-k commented 7 years ago

Same issue with vmwarefusion driver on OSX.

jstangroome commented 7 years ago

Also occurring for minikube v0.19.0 with Virtualbox 5.1.18 on Windows 10 x64 Build 14393.1198.

minikube start
minikube ip (note the IP address)
minikube stop
minikube delete
minikube start
minikube ip (IP address has changed)

Assigned IP address has so far incremented from 192.168.99.100 to 192.168.99.105

andziak commented 7 years ago

The IP address for Minikube changes on Max OS with xhyve driver. It would be great to use static IP address as we're developing apps in Pycharm remotely on Minikube pods. This way we have a full working copy of the whole environment on developer's machine. When IP changes, we need to reconfigure dozen projects in Pycharm which takes lots of time.

zainul-ma commented 7 years ago

its, would be great to have feature set static ip in minikube, any temp solution for this ?

garethr commented 6 years ago

I've also seen this with the Hyper-V driver. Stopping and starting appears to fix the issue until you connect to a new network.

squillace commented 6 years ago

Yeah, this isn't a feature, as it makes dnsmasq harder to configure. Now you can't map domain names to a single IP. Looking for any workaround here.

dgoldssfo commented 6 years ago

@squillace On Mac:

minikube start minikube ip (for me, 192,168.99.100) minikube stop; minikube delete Stop/quiesce all running VMs sudo /Library/Application\ Support/VirtualBox/LaunchDaemons/VirtualBoxStartup.sh restart minikube start minikube ip (192,168.99.100 like I want and not 192.168.99.101)

yoshiwaan commented 6 years ago

Having the DHCP addresses reset after a login/logout or some other trick isn't a good solution. What if I want to work on minishift for a while before I start up minikube? What if I have a test kitchen run running that uses VirtualBox? You need a clear way to set a static address for minikube (and thus you can create a hosts entry for it as well). Something --ip-address 192.168.100.52.

The solution that micheletedeschi posts (there's 2 comments from him) in https://github.com/docker/machine/issues/1709 works pretty well for docker-machine. If minikube had a similar way to run arbitrary scripts at boot up then that would be one quick way to solve the problem in a way that doesn't remove the option for a command line flag in the future.

dgoldssfo commented 6 years ago

I agree, it's a workaround/hack and it should only be used in situations where you don't have a bunch of other VMs that you need to worry about running on VirtualBox. I should have indicated that in my previous post, thanks for posting this.

And yes, minikube definitely needs to have a way to use a static IP.

gbraad commented 6 years ago

Although I am now experimenting with adding an option --ip-address to minishift: https://github.com/minishift/minishift/issues/1293 this is not easy for each hypervisor. The workarounds used allow the VM to get an IP address from the hypervisors DHCP server, and then change it in-place with the given option.

In my case, I am experimenting with Hyper-V as it allows to pass data to the VM, but so far I none of the other hypervisors do this. This means that the value can be passed into the VM before it has even tried to get an IP address (before the docker-machine provisioning started). Since it would several problems we have with Hyper-V: https://github.com/minishift/minishift/issues/418 https://github.com/kubernetes/minikube/issues/1627 it is my focus for the moment.

If you have other suggestions, please let me know... especially when it concerns the other hypervisors.

gbraad commented 6 years ago

Static IP address option for Minishift using HyperV is being worked on as https://github.com/minishift/minishift/issues/1316. I am coordinating with @aaron-prindle to see if this can also work for minikube.

gbraad commented 6 years ago

PR with a possible solution is available at Minishift's repo for testing. Instructions are here: https://github.com/minishift/minishift/issues/1316#issuecomment-331946998 If results are usable, we will also integrate this in minikube and the iso.

coryasilva commented 6 years ago

https://willwarren.com/2015/04/02/set-static-ip-address-in-vmware-fusion-7/

The link above helped me with VMWare Fusion

JavaJung commented 6 years ago

New user of minikube and kubernetes-cli here. I have this issue of changing minikube ip too, on mac. The driver is Hyperkit commit 3e3161, minikube v0.24.1, kubectl 1.8.0 (client and server).

If it will be possible to integrate setting a static ip for the VM in minikube, would that work for every driver?

pfk-beta commented 6 years ago

Same issue, doesn't matter which vm driver used.

DennisBayer commented 6 years ago

Hi @gbraad, any news on this issue, e.g. an ETA?

Best regards!

styk-tv commented 6 years ago

So --vm-driver=virtualbox has no effect on my Mac. Start-Stop-Start will still rotate. It seems they go from 100 to 103 and then repeat.

I was experimenting with export HOSTALIASES (you can have your userspace personal hosts file. Works on Ubuntu, HOWEVER not working on Mac) Would be nice to just map minikube.local and then output that local hosts file.

Well i still decided to go that path with sudo to update /etc/hosts. (after minikube start) Not ideal but it works. All provisioning scripts after that reference minikube.local hostname.

EDIT: use below at your own risk. test on a copy of hosts first before you set against your system file. Tested on Macbook. It detects the line with minikube and replaces entire line with new line and new ip - puts a tab in between. Yes it asks for root pass, yes its bad, yes it works.

sudo sed -i -e 's/.*minikube.*/'$(minikube ip)$'\tminikube.local/' /etc/hosts

adammwood commented 6 years ago

Similar to @styk-tv's comment, we're working around this issue current (on MacOS) with the following script that we use to start Minikube. A few points about it:

We're using Dnsmasq to resolve *.minikube.test (our local development prefix for projects - you can change it at minikube_ingress_domain_root) to the Minikube IP on startup, so Homebrew and Dnsmasq is required to use this. You could alternatively put/replace entries in /etc/hosts, however this doesn't support wildcards, so Dnsmasq works better for us.
We dynamically allocate 50% of system resources to Minikube, which I've included in case it's useful to anyone, however it's irrelevant to this problem.
This script also works around the hyperkit.pid issue (#1926). Again, this is irrelevant to this problem.

#!/bin/bash

echo "Removing hyperkit.pid file if present (https://github.com/kubernetes/minikube/issues/1926)...";

if [ -f ~/.minikube/machines/minikube/hyperkit.pid ]; then
    sudo rm ~/.minikube/machines/minikube/hyperkit.pid
fi

echo "Configuring Minikube resource usage...";

machine_cpus="$(sysctl -n hw.ncpu)";
machine_memory="$(expr $(sysctl -n hw.memsize) / 1048576)"; # Bytes to megabytes conversion (x/2^20)
minikube_cpus="$(expr ${machine_cpus} / 2)";
minikube_memory="$(expr ${machine_memory} / 2)";

echo "Machine resources: ${machine_cpus} CPUs / ${machine_memory}MB Memory";
echo "Configure Minikube to use 50%: ${minikube_cpus} CPUs / ${minikube_memory}MB Memory";

echo "Running 'minikube start --vm-driver=hyperkit --cpus ${minikube_cpus} --memory ${minikube_memory}'..."

minikube start --vm-driver=hyperkit --cpus ${minikube_cpus} --memory ${minikube_memory};
minikube addons enable ingress;

echo "Minikube started. Status:";
minikube status;

echo "Configuring Dnsmasq...";
minikube_ingress_domain_root="minikube.test"

cat <<EOL > /usr/local/etc/dnsmasq.conf
address=/${minikube_ingress_domain_root}/$(minikube ip)
EOL

sudo mkdir -p /etc/resolver/

tmp_file=$(mktemp)
echo "nameserver 127.0.0.1" > ${tmp_file}
sudo mv ${tmp_file} /etc/resolver/${minikube_ingress_domain_root}

sudo brew services restart dnsmasq

echo "Dnsmasq configured. All local requests to *.${minikube_ingress_domain_root} will resolve to Minikube.";

mans0954 commented 6 years ago

On Debian I'm doing this:

Find the VM MAC address:

sudo virsh net-dhcp-leases default
Expiry Time          MAC address        Protocol  IP address                Hostname        Client ID or DUID
-------------------------------------------------------------------------------------------------------------------
2018-03-20 22:31:12  68:c2:7d:7b:be:42  ipv4      192.168.122.107/24        minikube        ff:5c:bb:eb:5e:00:02:00:00:ab:11:c0:9e:7d:2d:18:6f:69:18

Stop minikube
```
minikube stop
```

Edit the minikube-net to make a static reservation. I've chosen to fix 192.168.39.38 as the IP address for minikube

sudo virsh net-edit minikube-net
network>
<name>minikube-net</name>
<uuid>4d44ec57-88c0-4887-976a-6e52e609f893</uuid>
<bridge name='virbr1' stp='on' delay='0'/>
<mac address='52:54:00:3f:a7:fa'/>
<ip address='192.168.39.1' netmask='255.255.255.0'>
<dhcp>
  <range start='192.168.39.2' end='192.168.39.254'/>
  <host mac='68:c2:7d:7b:be:42' name='minikube' ip='192.168.39.38'/>
</dhcp>
</ip>
</network>

Recreate the minikube-net network

sudo virsh net-destroy minikube-net
sudo virsh net-start minikube-net

Check that the static lease has been created

cat /var/lib/libvirt/dnsmasq/minikube-net.hostsfile
68:c2:7d:7b:be:42,192.168.39.38,minikube

Restart minikube
```
minikube start
```
Check that the static lease is working
```
minikube ip
192.168.39.38
```
I imagine that this could be scripted somehow. I'm presuming that the MAC address of the VM is fairly static?

I don't know if Mac OS X uses libvirt, but if not presumably there is an equivalent library?

Does that help?

Christopher

mans0954 commented 6 years ago

As an aside, installing Libvirt's NSS module https://wiki.libvirt.org/page/NSS_module allows minikube to be accessed as minikube rather than by IP address. I don't think that helps on OS X though, and it's not useful for setting ufw firewall rules (e.g. for mounting host folders) or mapping other hostnames to minikube.

pangehrn commented 6 years ago

On Windows 10 and VirtualBox the following steps worked for me to set the IP back to the initial value:

[ ] minikube stop
[ ] edit config file: %USERPROFILE%\.minikube\machines\minikube\config.json
- change value of "IPAddress" back to the initial one (for me it was 192.168.99.100)
[ ] minikube start
[ ] minikube ip (shows 192.168.99.100)
[ ] minkube dashboard (the dashboard opens on IP 192.168.99.100)

lcannon commented 6 years ago

I've been trying to develop a script to set up local development environments for our team recently, and have run into an issue here. Given that we may also want to be running multiple profiles at the same time, and the inability to select a static IP, I thought the easiest way to handle things would be to assign a given profile a given mac address, then use dnsmasq to tie that mac address to a given IP.

Unfortunately, the virtualbox DHCP server interferes with the dnsmasq assigned addresses. I can turn off and disable the virtualbox DHCP, but it seems that it gets re-enabled the next time minikube start is run -- is there a way to work around this?

jolson490 commented 6 years ago

Note I tried the work-around described by @pangehrn on this comment above on my Mac (with Docker For Mac and minikube v0.28.0 and VirtualBox), but it didn't work for me - the minikube start command overwrote how I changed IPAddress to 192.168.99.100.

I swear minikube ip used to always return 192.168.99.100 for me, but lately every time I do a minikube delete & minikube start then the right-most digit increments by 1 each time - i.e. 192.168.99.101, 192.168.99.102, etc.

pietervogelaar commented 5 years ago

Being able to configure a fixed IP would be very nice!

compugician commented 5 years ago

+1 - It would indeed be very nice to have!

ianfoo commented 5 years ago

Agreed, I'd love to be able to force an IP address. We use minikube as our local dev environment, and unfortunately many of the scripts assume an IP address of 192.168.99.100, which was, admittedly, short-sighted, and now a problem since my minikube comes up as 192.168.99.104, after having created and deleted a few additional minikube profiles/clusters.

I was optimistic, before finding this issue, that editing the ~/.minikube/*/config.json files would do the trick, but alas, it does not, for my macOS+VirtualBox based minikubes.

gbraad commented 5 years ago

If a static IP is important, consider setting up a VM that you pre-configure and then target this with the none-driver.

On Sat, Aug 25, 2018 at 6:28 AM, Ian Molee notifications@github.com wrote:

Agreed, I'd love to be able to force an IP address. We use minikube as our local dev environment, and unfortunately many of the scripts assume an IP address of 192.168.99.100, which was, admittedly, short-sighted, and now a problem since my minikube comes up as 192.168.99.104, after having created and deleted a few additional minikube profiles/clusters.

I was optimistic, before finding this issue, that editing the ~/.minikube/*/config.json files would do the trick, but alas, it does not, for my macOS+VirtualBox based minikubes.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kubernetes/minikube/issues/951#issuecomment-415898621, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAHZnJJY1vLLqgrIO1wx0f7muS_fGZgks5uUH32gaJpZM4LW0OV .

--

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

bfarayev commented 5 years ago

@ianfoo I had the issue on my MacOS + VirtualBox and editing ~/.minikube/profiles/minikube/config.json "NodeIP": "192.168.99.1xx", line to

        "NodeIP": "192.168.99.100",

worked for me. Using minikube v0.28.2

ianfoo commented 5 years ago

Thanks @bfarayev, though I tried that, along with setting the IP in the .minikube/machines/minikube/config.json, and it keeps coming back as 192.168.99.104. I'm on minikube 0.25.2, though, since 0.28.x and 0.27.0 never get past Starting cluster components... (another--but separate--issue that I've been unable to resolve).

massenz commented 5 years ago

Update: @bfarayev solution does not actually seem to work on Ubuntu/Virtualbox (Minikube 0.28.2). Weird, as I tried it, and it seemed to work; but it no longer does.

The confusing part is that there are actually two config.json files: one in ~/.minikube/machines/minikube and the other in ~/.minikube/profiles/minikube: it's actually not clear whether these are generated (after the VM is started) or are used to drive the VM's configuration.

Be that as it may, changing the values for NodeIP and IPAddress does not seem to make any difference at all, they both are overwritten at startup with the new values (I found that the VBox vboxnet driver assigns DHCP addresses in sequence and never seems to "reset" the count, even if the machine that took the previous one was deleted).

The only workaround I could find, to have the minikube VM to always retain a "predictable IP" (192.168.99.100) after a minikube delete, was to also delete the vboxnet- that was associated with the VM.

Obviously, a major 👍 to having something like --ip 192.168.99.100 or similar as an argument for minikube start.

dmytro-y-dev commented 5 years ago

It would be interesting to hear what k8s developers think about this issue. People, do you have any plans to make this feature in near future?

Inability to have static IP kills my productivity in development environment, as I have to manually change IP address in my other tools (MySQL GUI, MongoDB GUI clients) periodically on Minikube restart.

tstromberg commented 5 years ago

@metamaker - It's something I fully feel should be implemented and be on our development roadmap, and I am fully open to accepting any patches. This is a prerequisite for multi-VM minikube, should it be determined that we want to go that route.

The complication that makes this slightly more difficult to implement than one would expect is the matrix of supported platfoms (hypervisors and host operating systems). The rest shouldn't be so bad.

massenz commented 5 years ago

The complication that makes this slightly more difficult to implement than one would expect is the matrix of supported platfoms (hypervisors and host operating systems).

That's an excellent point; maybe it could be simplified if, instead of allowing "pick an IP you like, any IP", the requirement were "we guarantee that the value returned by minikube ip will be consistent on your machine across delete and restarts" - but it may be different elsewhere, depending on the OS/hypervisor combination.

What I was originally trying to do was to have dev setup that required the same IP on Ubuntu and MacOS - but (a) that's probably a rather infrequent use case and (b) I was able to actually work around that.

massenz commented 5 years ago

Also, I'd like to point out that the title of this issue is slightly misleading: as far as I can tell, any sequence of minikube stop/start will preserve the IP - it is the minikube delete that messes up things (this is also consistent with the original report).

At least as far as I could tell (again, across Ubunt/MacOS); would be curious to know if others have a different experience?

(still somewhat annoying - as one ends up deleting the minikube VM more often than one would like to - but not as bad)

rmorrise commented 5 years ago

@massenz On win7, restarting my PC will sometimes cause the IP to change, even if minikube was not deleted and recreated.

fejta-bot commented 5 years ago

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

fhoffm commented 5 years ago

Can anyone confirm a workaround which is currently working for Mac OS? (minikube version: v0.26.1, Virtual Box 6.0, Mac OS mojave 10.14.2) So far I've tried to

delete minikube and delete vboxnet
deleting minikube and restarting virtual box How can one reset the dhcp leases or where are these stored?

dgoldssfo commented 5 years ago

@fhoffm If you look at how restart works in the 5.2 VirtualBoxStartup.sh script, it calls a couple of functions that unload and reload the VBox kernel extensions. Does the script not exist in 6, or is there nothing analogous? (I haven't installed 6 yet.)

fhoffm commented 5 years ago

No luck, the script exists and all extension are unloaded: sudo /Library/Application\ Support/VirtualBox/LaunchDaemons/VirtualBoxStartup.sh restart Unloading VBoxNetFlt.kext Unloading VBoxDrv.kext Loading VBoxDrv.kext Loading VBoxUSB.kext Loading VBoxNetFlt.kext Loading VBoxNetAdp.kext

After minikube start I still end up with a new ip, e.g. 192.168.99.125

Going back to VirtualBox 5.2 was my workaround for now.

dgoldssfo commented 5 years ago

@fhoffm I installed VBox 6.0.2 today and had a look. VirtualBox 6 now saves DHCP leases in the new ~/Library/VirtualBox/HostInterfaceNetworking-vboxnet0-Dhcpd.leases file. (I just looked at my VBox 5 installation, and this file doesn't exist in version 5.)

I've found a couple of problems with the DHCP lease support in 6. The obvious one - the problem we're experiencing - is that existing DHCP leases are not deleted out of this file when a virtual machine is deleted, so leases stay around forever, causing higher and higher IP addresses in the IP range to be assigned to the Minikube (or any other) VM. I also tried changing the IP range in the vboxnet0 adapter, and that seemed to have no effect. For example, when I changed the IP address range to have a low IP of .200, VBox still assigned new Minikube VMs an IP address that was below .200, using the IP address range as it was before I modified it.

I was able to work around our problem by using this sequence:

minikube stop; minikube delete
Shut down the VirtualBox app. (added this step 1 Mar)
rm ~/Library/VirtualBox/HostInterfaceNetworking-vboxnet0-Dhcpd.leases
minikube start

When I did this, VBox grabbed the low IP address in my IP range.

Although we shouldn't have to do it, it's a bit of a nicer workaround than before - no sudo, no waiting for the restart to work, and less jarring to VBox.

Give it a shot and let me know if it worked.

leifcr commented 5 years ago

For virtualbox, this seems to be and issue with the minikube VM sending new id's each time it asks for a new IP, hence the DHCP in virtual replies with a new IP.

Here's an example where the first entry is a Win 10 VM which has restarted 3 times, and the last 3 entries is the minikube that has been restarted 3 times.

$ cat HostInterfaceNetworking-vboxnet0-Dhcpd.leases

<?xml version="1.0"?>
<Leases version="1.0">
  <Lease mac="08:00:27:dd:25:37" id="01080027dd2537" network="0.0.0.0" state="acked">
    <Address value="192.168.99.103"/>
    <Time issued="1548246998" expiration="1200"/>
  </Lease>
  <Lease mac="08:00:27:b4:b0:56" id="ffaf818f7d00020000ab11780327cdbc986ba6" network="0.0.0.0" state="acked">
    <Address value="192.168.99.102"/>
    <Time issued="1548246524" expiration="1200"/>
  </Lease>
  <Lease mac="08:00:27:b4:b0:56" id="ffaf818f7d00020000ab11049fe1503cfdd13d" network="0.0.0.0" state="acked">
    <Address value="192.168.99.101"/>
    <Time issued="1548246304" expiration="1200"/>
  </Lease>
  <Lease mac="08:00:27:b4:b0:56" id="ffaf818f7d00020000ab111cde8d12115fba88" network="0.0.0.0" state="expired">
    <Address value="192.168.99.100"/>
    <Time issued="1548245781" expiration="1200"/>
  </Lease>
</Leases>

After checking up, it can be fixed by changing the dhcp identifier to mac instead of ID. More info here: https://github.com/coreos/bugs/issues/360

It should be fixable by changing /etc/systemd/network/20-dhcp.network to:

[Match]
Name=eth*

[Network]
DHCP=ipv4

[DHCP]
ClientIdentifier=mac

fhoffm commented 5 years ago

Thx! Sorry for the late reply, this is very helpful!

Am Mi., 23. Jan. 2019, 20:07 hat Leif Ringstad notifications@github.com geschrieben:

For virtualbox, this seems to be and issue with the minikube VM sending new id's each time it asks for a new IP, hence the DHCP in virtual replies with a new IP. Here's an example where the first entry is a Win 10 VM which has restarte 3 times, and the last 3 entries is the minikube that has been restarted 3 times.

$ cat HostInterfaceNetworking-vboxnet0-Dhcpd.leases

<?xml version="1.0"?>

After checking up, it can be fixed by changing the dhcp identifier to mac instead of ID. More info here: coreos/bugs#360 https://github.com/coreos/bugs/issues/360

It should be fixable by changing /etc/systemd/network/20-dhcp.network to:

[Match] Name=en*

[Network] DHCP=yes

[DHCP] ClientIdentifier=mac

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kubernetes/minikube/issues/951#issuecomment-456794746, or mute the thread https://github.com/notifications/unsubscribe-auth/AGmUMAPR0EXUn0kS1GmVe5kzFmFY--suks5vGF6sgaJpZM4LW0OV .

dgoldssfo commented 5 years ago

More - I had a situation a couple of days ago where the workaround I posted above did not work. The fix was to quit the VBox app after deleting Minikube, but before deleting the ~/Library/VirtualBox/HostInterfaceNetworking-vboxnet0-Dhcpd.leases file.

kubernetes / minikube

Support for predictable IP's across restarts #951