Minikube: Support for predictable IP's across restarts

Created on 28 Dec 2016  ·  72Comments  ·  Source: kubernetes/minikube

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.

arenetworking kinfeature triagunresolved

Most helpful comment

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.

All 72 comments

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.

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

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.

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

@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).

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.

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.

Same issue with vmwarefusion driver on OSX.

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

  1. minikube start
  2. minikube ip (note the IP address)
  3. minikube stop
  4. minikube delete
  5. minikube start
  6. minikube ip (IP address has changed)

Assigned IP address has so far incremented from 192.168.99.100 to 192.168.99.105

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.

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

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.

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.

@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)

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.

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.

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.

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.

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.

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?

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

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

Best regards!

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

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.";

On Debian I'm doing this:

  1. 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
  1. Stop minikube
minikube stop
  1. 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>
  1. Recreate the minikube-net network
sudo virsh net-destroy minikube-net
sudo virsh net-start minikube-net
  1. 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
  1. Restart minikube
minikube start
  1. 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

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.

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\machinesminikube\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)

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?

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.

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

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

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.

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 ]

@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

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

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.

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.

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

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.

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)

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

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

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?

@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.)

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.

@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:

  1. minikube stop; minikube delete
  2. Shut down the VirtualBox app. (added this step 1 Mar)
  3. rm ~/Library/VirtualBox/HostInterfaceNetworking-vboxnet0-Dhcpd.leases
  4. 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.

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

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





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.

A bit heavy handed way to guarantee minikube gets 192.168.99.100 everytime with virtualbox.

function minikube_reset_vbox_dhcp_leases() {
  # # Reset Virtualbox DHCP Lease Info
  common_message_print "Resetting Virtualbox DHCP Lease Info..."
  kill -9 $(ps aux |grep -i "vboxsvc\|vboxnetdhcp" | awk '{print $2}') 2>/dev/null

  if [[ -f ~/Library/VirtualBox/HostInterfaceNetworking-vboxnet0-Dhcpd.leases ]] ; then
    rm  ~/Library/VirtualBox/HostInterfaceNetworking-vboxnet0-Dhcpd.leases
  fi
}

minikube_reset_vbox_dhcp_leases

@daxgames I'm using similar approach, however if you have other vboxes on the same host network, all will ip's will be new for those as well when deleting the dhcp leases file. I haven't found a way to remove single ip's through the vbox management cli.

@LEIFCR I am aware of that, like I said its heavy handed. I needed something quick.

If you have code that is less aggressive please share, it could save me some time.

This issue may be fixed for some users with #3572 - which shipped with minikube v0.34.1.

I can confirm though that the problem still exists for kvm2, however. I'd love to hear if it helps for any other users.

I am on MacOS 10.14 (Mojave), minikube v.0.33.1, Virtualbox 6.0.4.

@massenz I am getting the incrementing IP even just with minikube start/stop (no delete).

@dgoldssfo Thank you so much - this is what finally fixed it for me. It seems that it works as long as the Virtualbox app is closed (so I can do stop, delete leases, and start and be at .100 again)

@tstromberg Thanks for the heads up on the new version. Unfortunately, I'm still seeing the same thing with virtualbox even after updating minikube to v.0.34.1.

What is suggested in this serverfault answer seems to have done it for me using kvm. I've set an static ip for "minikube" on the "minikube-net".

Something interesting about this issue is that it was working fine for me without doing anything before. It started happening after switching OS (from archlinux to xubuntu 18.10).

Also upgraded minikube from 0.33.x to 0.34.1

Sorry if I'm poking my head into a place it doesn't belong, but it seems like people are searching for a way to do this, so I wanted to point out some prior art. Vagrant has supported static IPs across VM providers and host OSs for as long was they have supported multiple VM providers and host OSs (they don't have built-in support for all the VM providers minikube supports).

It is basically done by creating a new network interface with a static IP. Under the hood Vagrant knows how to create those interfaces across host OSs, and how to link those interfaces into multiple VM providers.

For me personally, as someone who creates development environments that get used across engineering teams, I would rather have a static IP that is known ahead of time than a dynamic IP that doesn't change after being assigned. By having a static IP I can document that IP, it is consistent across developer workstations, and I can even have it added to DNS or /etc/hosts so there are hostnames associated with the IP.

I solve it inspired on mac version of remove leases. I test it in Xubuntu 18.10 with VirtualBox 6.

#!/usr/bin/env bash

function minikube_reset_vbox_dhcp_leases() {
  # # Reset Virtualbox DHCP Lease Info
  common_message_print "Resetting Virtualbox DHCP Lease Info..."
  kill -9 $(ps aux |grep -i "vboxsvc\|vboxnetdhcp" | awk '{print $2}') 2>/dev/null

  if [[ -f ~/.config/VirtualBox/HostInterfaceNetworking-vboxnet0-Dhcpd.leases ]] ; then
    rm  ~/.config/VirtualBox/HostInterfaceNetworking-vboxnet0-Dhcpd.leases
  fi
}

minikube_reset_vbox_dhcp_leases

I'm also having this issue on minikube 0.34.1 with hyperkit in macOS. PR #3572 didn't fix it for me. I had to resort to deleting entries in /private/var/db/dhcpd_leases.

  • minikube start --vm-driver=hyperkit
  • minikube ip (note the IP address)
  • minikube stop
  • minikube delete
  • minikube start --vm-driver=hyperkit
  • minikube ip (IP address has changed)
  1. Set configuration context $ kubectl config use-context k8s
    List all PVs sorted by name, saving the full kubectl output to /opt/KUCC0010/my_volumes . Use
    kubectl s own functionally for sorting the output, and do not manipulate it any further.
    Question weight 3%
    Answer:
    $kubectl get pv --all-namespaces --sort-by="metadata.name" >>
    /opt/KUCC0010/my_volumes or
    $kubectl get pv --all-namespaces --sort-by="spec.capacity.storage" >>
    /opt/KUCC0010/my_volumes

C:\Users\trump\.VirtualBox\HostInterfaceNetworking-VirtualBox Host-Only Ethernet Adapter-Dhcpd.leases

using vbox under win10, just edit such file, change the ip and restart minikube.

hyperkit has uuid which is used in MAC address generation, when you start the machine with UUID like

minikube start -p makkara-1 --vm-driver hyperkit --uuid 00000000-0000-0000-0000-000000000001 --cpus 12 --memory 2048

the MAC address stays the same even if you delete the machine - the IP addresses can be changed in /var/db/dhcpd_leases the address must be in 192.168.64.xx because /Library/Preferences/SystemConfiguration/com.apple.vmnet.plist sets the address range. I haven't tried changing that range.

Based on comments https://github.com/kubernetes/minikube/issues/951#issuecomment-467044217 , https://github.com/kubernetes/minikube/issues/951#issuecomment-458238635 I created a multi OS support variant of the "workaround" script because I needed to support both MacOS and Linux systems.
Is here for anyone might find it useful.

Maybe I can help someone else. First I put VBox 6.* and then I had a problem with changing the ip address, then I made downgrade on VBox 5.2.

A bit heavy handed way to guarantee minikube gets 192.168.99.100 everytime with virtualbox.

function minikube_reset_vbox_dhcp_leases() {
  # # Reset Virtualbox DHCP Lease Info
  common_message_print "Resetting Virtualbox DHCP Lease Info..."
  kill -9 $(ps aux |grep -i "vboxsvc\|vboxnetdhcp" | awk '{print $2}') 2>/dev/null

  if [[ -f ~/Library/VirtualBox/HostInterfaceNetworking-vboxnet0-Dhcpd.leases ]] ; then
    rm  ~/Library/VirtualBox/HostInterfaceNetworking-vboxnet0-Dhcpd.leases
  fi
}

minikube_reset_vbox_dhcp_leases

I experienced a bit unstable VirtualBox Manager (GUI) with this.

hi,

for anyone interested, i worked around this with a simple static ip. Disadvantage is, its not returned with "minikube ip". But since i can configure it thats not a big problem..
minikube ssh "sudo ifconfig eth0:0 192.168.99.200"

regards,
strowi

Marking as a backlog item, because I don't believe this will be likely possible to do consistently across hypervisors until we migrate away from libmachine to something like terraform.

This is still an ongoing thing for me as well. Do we have any additional information in regards to this?

The lease deletion workaround implemented as a bash script for ubuntu users:

minikube stop
mkdir ~/.config/VirtualBox/leasebackup/
mv ~/.config/VirtualBox/*.leases ~/.config/VirtualBox/leasebackup/
mv ~/.config/VirtualBox/*.leases-prev ~/.config/VirtualBox/leasebackup/
VBoxManage hostonlyif remove vboxnet0

-- edit:
All vms and vbox services must be shutdown before restarting minikube

on docker driver we could do this : https://github.com/kubernetes/minikube/issues/7756

I would be happy for anyone who like to pick that issue first for docker driver, and then later we could do same logic for KVM and virtualbox

I'm closing this admittedly popular, but overly broad issue, because it is effectively unsolvable for all drivers we interact with.

It is not currently a priority for the maintainers to address this issue, but PR's are certainly welcome to introduce predictable IP support for a particular driver. I caution that doing so may be tricky, particularly when running multi-cluster and/or multi-node configurations.

Not for hyperkit - setting UUID works.

On 23. Apr 2020, at 20.28, Thomas Strömberg notifications@github.com wrote:


Closed #951.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Was this page helpful?
0 / 5 - 0 ratings