-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Restoring a checkpoint fails: requested static ip not in any subnet on network podman #12762
Comments
An extra note: if I restore using the --ignore-static-ip flag, then that does correctly restore the container, but on a different IP address.
|
Where does the 172.16.16.X subnet come from? Did you change the default network subnet? Could you provide the full output of |
I did not change any of the default settings, this is essentially straight after building podman. I don't know where that subnet comes from, I didn't type that in at any point.
|
It looks like you changed your default CNI config file to a driver we do not officially support. Is there any specific reason you do not use the default bridge? Anyway I see the problem now. The network does not contain a subnet (I assume you cni config contains the dhcp ipam plugin) and we try to check if the ip is in a given subnet but since there are subnets this check fails. I think we must only do this check if the local ipam driver is used. |
I did not intentionally change any CNI config file. In fact I don't even know what a CNI config file is or where it is. I definitely do want to use "the default bridge", whatever it is. How can I do that? The closest thing might be that I previously got an older version of podman from the Ubuntu repositories, before uninstalling it and building podman from source. Would that have left over any CNI junk? |
Check the files in If you never changed that then I have no idea were it came from. It might be worth to check if this is/was shipped by the debian package. |
Thanks, after replacing my existing /etc/cni/net.d/87-podman-ptp.conflist with that one you linked above, my repro steps above do allow checkpointing to work as expected. FYI, my previous 87-podman-ptp.conflist looked like this:
|
Looking it up, yeah that file I pasted above came directly from the current Ubuntu podman package, podman_3.2.1+ds1-2ubuntu3_amd64.deb , the one we can see here: https://packages.ubuntu.com/impish/amd64/podman |
Could yo uopen an issue with them? |
This is still an issue with the new network code, we should not error in this case. |
It also looks like this was already changed in the debian repo: https://salsa.debian.org/debian/libpod/-/commit/39723afc6b6d8067f63df6a2741cf71a0ce71dee |
If the hdcp ipam driver is used podman does not know any subnets so we cannot verify if the guven static ip is in the subnet. Fixes containers/podman#12762 Signed-off-by: Paul Holzinger <pholzing@redhat.com>
If the dhcp ipam driver is used podman does not know any subnets so we cannot verify if the given static ip is in the subnet. Fixes containers/podman#12762 Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
Following the sequence from this checkpoint/restore test, restoring a checkpoint fails when podman tries to reassign the static ip to the container:
https://src.fedoraproject.org/rpms/criu/blob/093f8b4513016427781231995f20e1213b722370/f/tests/run-podman-checkpoint-restore.sh
Steps to reproduce the issue:
Short repro steps:
Notably, every time I remove that container then re-create it with the same command, it gets assigned a new ip (172.16.16.8, 172.16.16.9, 172.16.16.10 and so on). But the old IP seems to become unusable afterwards.
If I try to re-create a container with an option like
--ip=172.16.16.8
when a previous, removed container used that ip, then that will fail with a similar error:Error: requested static ip 172.16.16.8 not in any subnet on network podman
But that IP really was the one that was auto-assigned to the previous container, and that was tested to work correctly. So I guess that somehow, the original container never releases its IP address when it gets checkpointed and stopped. Then it can't get restored because that IP is still blocked? (I don't really understand how the IP addresses get assigned here.)
This is the full output from my repro sequence, including the output from podman run:
https://thelo.ca/podman-cant-restore-ip.txt
Output of
podman version
:Output of
podman info --debug
:Package info (e.g. output of
rpm -q podman
orapt list podman
):Probably not useful because I have rebuilt podman from source since then, but:
Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)
Yes.
Additional environment details (AWS, VirtualBox, physical, etc.):
Physical machine running Ubuntu 21.10, but with the older kernel version 5.11.0-20-generic (to work around a kernel issue that can otherwise cause criu checkpoints to fail).
The text was updated successfully, but these errors were encountered: