requested IP address X is not available in range

[thoraxe]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

ERRO[0000] Error adding network: failed to allocate for range 0: requested IP address 10.88.0.11 is not available in range set 10.88.0.1-10.88.255.254
ERRO[0000] Error while adding pod to CNI network "podman": failed to allocate for range 0: requested IP address 10.88.0.11 is not available in range set 10.88.0.1-10.88.255.254
Error: unable to start container "shinobi": error configuring network namespace for container ba61003219c7d5e197c83de43030d9c16448e102a877a0d18df6cd5a8a9f8171: failed to allocate for range 0: requested IP address 10.88.0.11 is not available in range set 10.88.0.1-10.88.255.254

This container was running prior to a reboot. After reboot when attempting to start it, this error appears. This is happening for 2/3 containers that have an ip address specified.

Steps to reproduce the issue:

1. create a container with an IP address:

podman run --ip 10.88.0.11 -d --name shinobi -v /var/containers/shinobi/videos/:/opt/shinobi/videos:Z -v /var/containers/shinobi/mysql/:/var/lib/mysql:Z -v /var/containers/shinobi/config/:/config:Z migoller/shinobidocker:debian

2. stop the container

3. reboot

4. attempt to start the container

Describe the results you received:
ERRO[0000] Error adding network: failed to allocate for range 0: requested IP address 10.88.0.11 is not available in range set 10.88.0.1-10.88.255.254
ERRO[0000] Error while adding pod to CNI network "podman": failed to allocate for range 0: requested IP address 10.88.0.11 is not available in range set 10.88.0.1-10.88.255.254
Error: unable to start container "shinobi": error configuring network namespace for container ba61003219c7d5e197c83de43030d9c16448e102a877a0d18df6cd5a8a9f8171: failed to allocate for range 0: requested IP address 10.88.0.11 is not available in range set 10.88.0.1-10.88.255.254

Describe the results you expected:
running container

Additional information you deem important (e.g. issue happens only occasionally):
Not sure it can be reproduced reliably because 1/3 containers using the ip stanza worked.

Output of podman version:

Version:            1.4.4
RemoteAPI Version:  1
Go Version:         go1.10.3
OS/Arch:            linux/amd64

Output of podman info --debug:

debug:
  compiler: gc
  git commit: ""
  go version: go1.10.3
  podman version: 1.4.4
host:
  BuildahVersion: 1.9.0
  Conmon:
    package: podman-1.4.4-4.el7.centos.x86_64
    path: /usr/libexec/podman/conmon
    version: 'conmon version 0.3.0, commit: unknown'
  Distribution:
    distribution: '"centos"'
    version: "7"
  MemFree: 2978381824
  MemTotal: 8197042176
  OCIRuntime:
    package: runc-1.0.0-57.dev.git9e5aa74.fc28.x86_64
    path: /usr/bin/runc
    version: 'runc version spec: 1.0.1-dev'
  SwapFree: 7918841856
  SwapTotal: 7918841856
  arch: amd64
  cpus: 12
  hostname: dumpster.festive.local
  kernel: 3.10.0-1062.4.3.el7.x86_64
  os: linux
  rootless: false
  uptime: 14m 20.78s
registries:
  blocked: null
  insecure: null
  search:
  - registry.access.redhat.com
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.centos.org
store:
  ConfigFile: /etc/containers/storage.conf
  ContainerStore:
    number: 34
  GraphDriverName: overlay
  GraphOptions: null
  GraphRoot: /var/lib/containers/storage
  GraphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 28
  RunRoot: /var/run/containers/storage
  VolumePath: /var/lib/containers/storage/volumes

Package info (e.g. output of rpm -q podman or apt list podman):

podman-1.4.4-4.el7.centos.x86_64

Additional environment details (AWS, VirtualBox, physical, etc.):
n/a

[thoraxe]

I think this is related to #3759

[thoraxe]

So, this is fixed by #4086 as best I can tell, but unfortunately that fix doesn't seem to have migrated its way back to a version that's natively available on CentOS 7.

Trying to update using https://cbs.centos.org/repos/virt7-container-common-candidate/x86_64/os/ gets me most of the way there, until I get hit with an error about trying to use crun:

Error: error creating libpod runtime: default OCI runtime "crun" not found: invalid argument

[mheon]

The default being crun there is probably a bug - @lsm5

…

On Sun, Nov 17, 2019, 10:25 Erik Jacobs ***@***.***> wrote: So, this is fixed by #4086 <#4086> as best I can tell, but unfortunately that fix doesn't seem to have migrated its way back to a version that's natively available on CentOS 7. Trying to update using https://cbs.centos.org/repos/virt7-container-common-candidate/x86_64/os/ gets me most of the way there, until I get hit with an error about trying to use crun: Error: error creating libpod runtime: default OCI runtime "crun" not found: invalid argument — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4526>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3AOCDU5DDBVEYC33UM6KTQUFO5XANCNFSM4JOKHA7A> .

[thoraxe]

so, changing the default to runc got me up and running with the fixed stuff. I will close this since my issue is not real. Let me know if you want me to reopen an issue regarding the default.

[ivan-jli]

Hello there,

As I faced the same problem, and because of DNS problems (I'm using Debian Stable, so still no podman 4 for me), I wrote this dirty one-liner to do the work:

#!/bin/sh
HOSTS_FILE=./shared/shared_sys/hosts

podman inspect panamax_server |rg IPAddr|rg -oe "[[:digit:]].[[:digit:]]"|perl -pe 's|\n|| ; s||\n|' > "$HOSTS_FILE"
echo " panamax_server" >> "$HOSTS_FILE"

$HOSTS_FILE needs of course be mounted to the container from which we want to access the target container (here panamax_server) using name instead of IP.

Best,

Ivan

[lsm5]

@ivan-jli please file a new issue. Thanks!