-
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
Unable to restore a container to an existing network namespace #14389
Labels
kind/bug
Categorizes issue or PR as related to a bug.
locked - please file new issue/PR
Assist humans wanting to comment on an old issue or PR with locked comments.
network
Networking related issue or feature
Comments
Maybe a bit simpler to reproduce it fails the same way when |
Luap99
added a commit
to Luap99/libpod
that referenced
this issue
May 31, 2022
When a container does not use the default podman netns, for example --network none or --network ns:/path a restore would fail because the specgen check validates that c.config.StaticMAC is nil but the unmarshaller sets it to an empty slice. While we could make the check use len() > 0 I feel like it is more common to check with != nil for ip and mac addresses. Adding omitempty tag makes the json marshal/unmarshal work correctly. This should not cause any issues. Fixes containers#14389 Signed-off-by: Paul Holzinger <pholzing@redhat.com>
mheon
pushed a commit
to mheon/libpod
that referenced
this issue
Jun 14, 2022
When a container does not use the default podman netns, for example --network none or --network ns:/path a restore would fail because the specgen check validates that c.config.StaticMAC is nil but the unmarshaller sets it to an empty slice. While we could make the check use len() > 0 I feel like it is more common to check with != nil for ip and mac addresses. Adding omitempty tag makes the json marshal/unmarshal work correctly. This should not cause any issues. Fixes containers#14389 Signed-off-by: Paul Holzinger <pholzing@redhat.com>
gbraad
pushed a commit
to gbraad-redhat/podman
that referenced
this issue
Jul 13, 2022
When a container does not use the default podman netns, for example --network none or --network ns:/path a restore would fail because the specgen check validates that c.config.StaticMAC is nil but the unmarshaller sets it to an empty slice. While we could make the check use len() > 0 I feel like it is more common to check with != nil for ip and mac addresses. Adding omitempty tag makes the json marshal/unmarshal work correctly. This should not cause any issues. Fixes containers#14389 Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
kind/bug
Categorizes issue or PR as related to a bug.
locked - please file new issue/PR
Assist humans wanting to comment on an old issue or PR with locked comments.
network
Networking related issue or feature
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
When a container is created by joining a network namespace with
--net ns:<path>
option, this container can be checkpointed successfully but will not be able to restore.During the restoring, the following error appears:
Steps to reproduce the issue:
1.Create a network namespace and setup veth interface
2.Run container by joining the network namespace
sudo podman run --name test2 --runtime /usr/bin/runc -d --network ns:/run/netns/test alpine sh -c 'while sleep 3600; do :; done'
3.Checkpoint the container
4.Restore the container with checkpoint image and get the error
Describe the results you received:
From the checkpointed image, the container did not create a network namespace, so the restore failed.
Describe the results you expected:
The container can restore to the original namespace. Or there is an option for user to specify a new namespace to restore the container to.
Output of
podman version
:Output of
podman info --debug
:Package info (e.g. output of
rpm -q podman
orapt list podman
):None. Built from source.
Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)
Yes, tested with version 4.1.0
Additional environment details (AWS, VirtualBox, physical, etc.):
The test is done in following environment in KVM:
(Note: the ubuntu kernel version is very important. Other kernel version may cause checkpoint failed.)
The text was updated successfully, but these errors were encountered: