Skip to content
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

Closed
Rexyyj opened this issue May 26, 2022 · 1 comment · Fixed by #14433
Closed

Unable to restore a container to an existing network namespace #14389

Rexyyj opened this issue May 26, 2022 · 1 comment · Fixed by #14433
Assignees
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

@Rexyyj
Copy link

Rexyyj commented May 26, 2022

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:

sudo podman --runtime /usr/bin/runc container restore -i ./ckp2.tar.gz  --print-stats

Error: cannot set static IP or MAC address if not creating a network namespace: invalid argument

Steps to reproduce the issue:

1.Create a network namespace and setup veth interface

ip netns add test
ip netns exec test /bin/bash
ip link add enp2s0 type veth peer name eth0
ip addr add 10.1.1.0/24 dev eth0
ip link set eth0 up
exit

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

sudo podman --runtime /usr/bin/runc container checkpoint --compress=none -e ./ckp.tar.gz test2  --print-stats

4.Restore the container with checkpoint image and get the error

sudo podman --runtime /usr/bin/runc container restore -i ./ckp2.tar.gz  --print-stats

Error: cannot set static IP or MAC address if not creating a network namespace: invalid argument

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:

Client:       Podman Engine
Version:      4.1.0
API Version:  4.1.0
Go Version:   devel go1.19-5f2fdbe7ed Wed May 18 01:02:54 2022 +0000
Built:        Wed May 18 17:11:36 2022
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.26.1
  cgroupControllers: []
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: Unknown
    path: /usr/local/libexec/podman/conmon
    version: 'conmon version 2.1.1, commit: 546e4dbe78c72754053d4029593e7d9fc59adff1'
  cpuUtilization:
    idlePercent: 99.76
    systemPercent: 0.1
    userPercent: 0.14
  cpus: 2
  distribution:
    codename: focal
    distribution: ubuntu
    version: "20.04"
  eventLogger: file
  hostname: rex-vm
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.8.18-050818-generic
  linkmode: dynamic
  logDriver: k8s-file
  memFree: 2447998976
  memTotal: 4123381760
  networkBackend: cni
  ociRuntime:
    name: runc
    package: Unknown
    path: /usr/bin/runc
    version: |-
      runc version 1.1.0+dev
      commit: v1.1.0-179-g95243661
      spec: 1.0.2-dev
      go: devel go1.19-5f2fdbe7ed Wed May 18 01:02:54 2022 +0000
      libseccomp: 2.5.1
  os: linux
  remoteSocket:
    path: /run/user/1000/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_AUDIT_WRITE,CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_MKNOD,CAP_NET_BIND_SERVICE,CAP_NET_RAW,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: ""
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: ""
    package: ""
    version: ""
  swapFree: 1469710336
  swapTotal: 1469710336
  uptime: 7h 23m 45.2s (Approximately 0.29 days)
plugins:
  log:
  - k8s-file
  - none
  - passthrough
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /home/rex/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: vfs
  graphOptions: {}
  graphRoot: /home/rex/.local/share/containers/storage
  graphRootAllocated: 31040933888
  graphRootUsed: 14684463104
  graphStatus: {}
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 0
  runRoot: /run/user/1000/containers
  volumePath: /home/rex/.local/share/containers/storage/volumes
version:
  APIVersion: 4.1.0
  Built: 1652886696
  BuiltTime: Wed May 18 17:11:36 2022
  GitCommit: ""
  GoVersion: devel go1.19-5f2fdbe7ed Wed May 18 01:02:54 2022 +0000
  Os: linux
  OsArch: linux/amd64
  Version: 4.1.0

Package info (e.g. output of rpm -q podman or apt 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.)

$ lsb_release -a

Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.4 LTS
Release:	20.04
Codename:	focal

$ uname -r
5.8.18-050818-generic
@openshift-ci openshift-ci bot added the kind/bug Categorizes issue or PR as related to a bug. label May 26, 2022
@Rexyyj Rexyyj changed the title Unable to restore a container to a existing network namespace Unable to restore a container to an existing network namespace May 26, 2022
@Luap99 Luap99 added the network Networking related issue or feature label May 30, 2022
@Luap99 Luap99 self-assigned this May 31, 2022
@Luap99
Copy link
Member

Luap99 commented May 31, 2022

Maybe a bit simpler to reproduce it fails the same way when --network none is used instead of the custom netns.

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>
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 20, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 20, 2023
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
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants