Make the VM IP settable

[bfalor]

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

Please provide the following details:

Environment:
Windows 10 or Mac High Sierra
Minikube version (use minikube version): ALL

• Install tools: choco or homebrew

What happened:
Minikube ip changes after stopping and starting it. This is inconsistent as sometimes it doesn't change
What you expected to happen:
Minikube ip to be configurable
How to reproduce it (as minimally and precisely as possible):
minikube start
minikube ip
minikube delete
minikube start
minikube ip

As a feature request, I would appreciate it if there was a flag that could specify that IP when you run minikube start.

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

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

[tstromberg]

NOTE: #951 covers the predictable IP feature request

[leifcr]

I do think this will be difficult to implement, as the MAC address for the NIC is generated on creation of the virtual machine, and this will complicate matters when running more than one minikube instance on one host.

#951 implements predictable IP until machine is deleted, as a new machine will have a new nic.

Suggestions for implementation:

1. Store mac of each started minikube instance matching give hostname, so that a newly created minikube instance, uses same mac, which again lets dhcp from vms will assign same IP.
2. Map against IP, and modify the VM's to ensure that IP is free when starting the VM.

Any options requires quite tight interaction with the VM host when creating the VM.

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

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

[tstromberg]

Still an issue. I believe this is related to a libmachine limitation.

[brainfull]

I also got a lot of problems getting a working solution and tried to get a static address setup in minikube or even a DHCP server to assign a static address. Here is what I did on my side. I understand your setup is different and my solution may not fit your needs. My setup is Hyper-V on Windows 10 Pro. I hope it gives you some food for thought as a minimum.

1. Use internal VM Switch. You can set it up easily with the following powershell. It will take care of creating the VM switch if it doesn't exist and establish ICS between your internet connection and the internal VM Switch.
   Set-ICS.ps1.txt
   Open Powershell and call the script. In the following example it creates a VM Switch named 'minikube':
   ./Set-ICS.ps1 -VMSwitch minikube Enabled

2. Create your minikube VM. Open Powershell and call the following command. In the following example it creates a VM named 'minikube' using the VM switch named 'minikube':
   minikube start --vm-driver hyperv --hyperv-virtual-switch minikube

3. From that point on, your VM 'minikube' is available internally in your computer under the hostname (VM Name).mshome.net, if you followed the previous instructions that is 'minikube.mshome.net'. It is ICS DHCP server that takes care of defining that hostname under C:\Windows\System32\drivers\etc\hosts.ics

4. Expose a service on a predefined Nodeport. Here is an example of a yaml that expose the port 22 of a container on Nodeport 30022, if you followed the previous instructions that is 'minikube.mshome.net:30022'. In my case this is an Open-SSH listening on port 22 so it allows me to SSH in my container.
   dev-service-bekno-worker-debug.yaml.txt

5. Then you can open the port on your laptop which has its own external IP address and own external hostname on your network. One way to do it in Powershell is the following:
   netsh interface portproxy add v4tov4 listenaddress=127.0.0.1 listenport=2222 connectaddress=minikube.mshome.net connectport=30022

6. F**k yeah! In my case I can open SSH connection on port 2222 from another computer. That opens up an SSH connection to a container within minikube!!! You may have to change your firewall rules to allow incoming connection on port 2222. If the port 2222 or 30022 are not available because of other services running on it, the previous steps may fail, in which case you need to change the ports.

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 .

[tstromberg]

This is still an issue in minikube v1.6 - and will likely be an issue until we migrate to using something other than libmachine.