[Request]: Avoid changing IP of a container unnecessary on restart #1836

Activity

1. vsarunas

   added the

   Feature

   issue type on Jun 26, 2026
2. vsarunas commented on Jun 26, 2026

   

   vsarunas

   on Jun 26, 2026

   Author

   More actions

   Fix is in #1740
3. jglogan commented on Jun 26, 2026

   

   jglogan

   on Jun 26, 2026

   Contributor

   More actions

   @vsarunas Thanks for filing the issue for your PR!

   I had started looking at it but we're working on the release this week and also trying to improve our integration testing.

   Have you looked at #282 regarding static IP allocation? Your work definitely ties into that. I described the difficulties with static IPs there:

   • With vmnet there's no guaranteed way to get the IPv4 subnet you ask for when creating a network. You can either leave ipv4Subnet nil and be guaranteed (unless there are no subnets left) a subnet of its choosing, or you can set ipv4Subnet but fail to get the subnet you want because it's already in use.
   • This means we can never guarantee that a fixed static IP address on a container will work across container system restarts. It may work, or it will have the wrong subnet if you have a vmnet-assigned subnet that come up differently, or the network will fail to start in the first place if you assigned the subnet and it's now in use elsewhere.

   We expressly chose the rotating IP policy because it's a historical way of reducing the incidence of ARP cache issues when creating and deleting containers. For cloud native development, wiring up configurations with IPs is brittle and that's why container supports local domain name resolution for containers - that a far more robust way of connecting things.

   Is yours an application server use case (I need a better term for using container/docker/etc to run packaged applications, as opposed to doing cloud native development)? Would you be better served by being able to ask for a specific IP when you create/run a container?

   The reason I ask is that you've done most of the work on the network plugin side for a pragmatic solution to the static IP issue. The way I saw that working is that if added, say, --network default,ip=192.168.64.13 to your container create or container run, the runtime helper would call your register API to try to allocate the IP. The network helper would replace the requested subnet prefix with the current prefix (which would usually be the same but could be different as described above), and use the transformed address in the allocation response.

   This would ensure that the container starts with a working network. Of course, anything relying on the original IP will not be able to communicate with the container if the subnet has changed.
4. vsarunas commented on Jun 26, 2026

   

   vsarunas

   on Jun 26, 2026

   Author

   More actions

   Background: I'm using container to orchestrate a number of VMs to test/emulate for high availability in stack that has a trading system and few components (Consul/Nomad/Kafka). Generally in my experience is that IP address is usually the same in cloud native if you just do a restart of the system; of course a different if you request a new allocation.

   I create a dedicated network and stick the containers on the range that is expected instead of relying on 192.168.6x given out.

   Yes I had looked at #282 / #751 ; hence the best attempt sticky solution of not having to deal with all of the edge cases. In a similar fashion where a DHCP server will hand out the same IP address lease if within a certain time window. And I agree that having static IP is cumbersome and has it's own set of issues (a container that is stopped that has a static IP address assigned, but a new container has been requested with the same address needs an XPC call to validate).

   Ok I see that also need to save and restore the mac address, as it rotates between restarts and new container comes up with a different one and for some time it is not accessible until arp expires; maybe I can just address that?
5. vsarunas commented on Sep 10, 2026

   

   vsarunas

   on Sep 10, 2026

   Author

   More actions

   @jglogan I have updated the PR #1740. MAC address is also now preserved so there should be no ARP timeout issues.

   See #2156 / #2158 of another workaround having to be done due to the incrementing IP address after a reboot.