Docker forgot IPv4 in VMware Player 12 & 15 after resume from suspend

Hi all,

When VM is come back from suspend state then docker0 interface has no IPv4 address anymore.
Before suspend VM:

docker:~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:29:7f:da:c0 brd ff:ff:ff:ff:ff:ff
inet 192.168.80.133/24 brd 192.168.80.255 scope global eth0
valid_lft forever preferred_lft forever
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:a9:86:a2:d5 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
5: veth4081c84@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
link/ether 66:7a:92:1b:25:b7 brd ff:ff:ff:ff:ff:ff link-netnsid 0

Resumed suspend:

docker:~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:29:7f:da:c0 brd ff:ff:ff:ff:ff:ff
inet 192.168.80.133/24 brd 192.168.80.255 scope global eth0
valid_lft forever preferred_lft forever
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:a9:86:a2:d5 brd ff:ff:ff:ff:ff:ff
5: veth4081c84@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
link/ether 66:7a:92:1b:25:b7 brd ff:ff:ff:ff:ff:ff link-netnsid 0

I disabled IPv6 because I do not need it at all. With IPv6 the situation is the same. There is no IPv4 address after it came up from resumed mode. With Leap 42.3 this suspend/resume VM works fine.

Best,
Csaba

First for two reasons,
You should have posted in the Virtualization forum where both virtualization like VMware products and isolation like Docker containers are discussed, and your problem has to do with networking. There’s not really any Applications Forum type content in your post. For whatever problem is posted, posting in the right place will always get you a better response, and sometimes answers can be found by searching previous posts in the correct forum.

I’d recommend you start a new thread in the Virtualization forum and provide information likely relevant to your problem…

Like
Where did your container come from, is it your own creation or did you download from Docker Hub?
How are you configuring your networking, by command parameters or in your docker file?
Include the exact means you configure your networking

TSU

Hi,

Ok, next time I’ll ask these questions on the other forum. This was my first try because I did not find any solution for my problem…

I use both local and downloaded docker containers. I defined IPv4 in /etc/sysconfig/docker file with DOCKER_OPTS="–bip=172.17.0.1/24". After resume I have to restart docker daemon but then I lose my running containers.

My tip is that something went wrong with network package. There is not ifconfig command at all. Only “ip addr …” exists. The same docker containers are working with Lead 42.3 and older. I build more VMs with the same config (VM and docker). Version Leap 15 and 15.1 this problem exists.

This is expected as ifconfig is deprecated. As you can see in the manual:
https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.network.html
“The ifconfig and route tools are obsolete. Use ip instead. ifconfig, for example, limits interface names to 9 characters.”
Also for reference:

Besides ifconfig deprecated,
I’d also question why your docker file is located in /etc/sysconfig,

docker files should be unique to a particular instance, and usually a customized file specific only for your own use.
On the HostOS, the /etc/sysconfig location is for HostOS configurations, not container instances… or at least unless someone can describe a logical reason to me for how this location is appropriate.

TSU

I read in the past, when starts docker daemon (in case of OpenSUSE), its read configuration from /etc/sysconfig/docker
https://www.suse.com/support/kb/doc/?id=7018811

I read in the past, when starts docker daemon (in case of OpenSUSE), its read configuration from /etc/sysconfig/docker
https://www.suse.com/support/kb/doc/?id=7018811

My problem is the docker0 interface forgot the defined IPv4 network and address when OpenSUSE come back from suspend.
Settings from VMware player:
https://forums.opensuse.org/image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAScAAACvCAYAAAC/zhhAAAAQT0lEQVR4nO2dz28cRRaA5 8BLWg3miEx9gktP/aEfckuIqgvsU b3etKQFAizyAwkaUlQE4kB/vSHMF35w8YbJDg4DiGhb3EHPqSIDsbvT3M9Ex1TXV1V0 P5834e9IniGe6qrq7 nNVjadeQwiCIBRGY9oNIAiCcAVyIghCZSAngiBURpCcdlYb0miYLMjmwfiNONhc6Je3KjvjF0cQxBxEsJwWDBv1pDKmoA42ZaEmyREEMT8xlpxEDmRzwf5ZYBxsygIjJoIgrKhRTr3/X93ZkVVrijactmWngtmfN6SxOlRU3jFV6hke0/tv3pTUbo/RHE/ZIrKzWvtUlyDOe9Qip95D3BfVwmrm4TzYXJDGwqYcDAvJri05Rk7 Y6rUk0ppKI6d1Ubm/T35ZNu1uVOibHtaurOJnAiihhhLTr0Fcksa2SGFrI6MJEyhiUNORcdUqcdxTKbe3ihs1Tm3LCibaSlBTCTG 7TOHE3Y0ukdYH2655gy2Q934TFV6nEcY4547NGchJdtTwMJghgvxpzWmZEnjYJRhVNOvmOq1DOunEqMjA42ZYE/hyCI2mKycirzZwK2nAqPqVJPwTG 44P 1KGGTy8JghCRSctJ7HWp/vtWjemgY83Gf0yVeoqFNnK8sSDuLXtn1SjX3TaCIMJj4nJKjzPXavIXpsscU6WecqOt7PG 14yyB9M5x7kRBFE5 G4dQRAqAzkRBKEykBNBECoDOREEoTKQE0EQKgM5EQShMpATQRAqAzkRBKEykBNBECoDOREEoTKQE0EQKgM5EQShMhpJkkgKQRCElsjICQBAC8gJAFSCnABAJcgJAFSCnABAJcgJAFSCnABAJcgJAFSCnABAJcgJAFSCnABAJcgJAFSCnABAJcgJAFSCnABAJcgJAFSCnABAJcgJAFSCnABAJcgJAFSCnABAJcgJAFSCnABAJcgJAFSCnABAJcgJAFSCnABAJYrlFEvUaEq7q7mus2wjwPli nLqtqXZaEjDIIoTOZ9yQnYAKdOVUxwZMkqJJWq2pXsu5QQAKVOUU1fazYY0292c160HPzPCsoTQl9yAKDbKsEdknrraw3Ky7corx3dc9hjviLDblmYjkrj0OfffF6evRxIr6EwAddJ48OCBpJxp5d22NL2jDvNB7T3oAynE0fCBHCknliiKZUR AwHk1WVILY4MGfjKcR2XU4dxXByZAk2k2272/13ynNN6m23pKuhEAJNgIiMnU3g2g/d5ZZFI5kEdeeiNB7c/uhgZFY2U35OMe/Rkj2bs8vPKcR03Wk7DHv1kzienPN85e6aTvmsPMEtMTE6F7wsZOcWRNUqwRGNN66J49Gf qZ39sBvle8vxyaknk w0LzsaG8hvcG5lz5m1Lph/pienkDUn7yjCIn2vb4rlq8su31uOR07ONg/fm07luu2mW2AVR04A88IU5ZQEfFpnjULMBzeOsoIbjERG5ddtRzkPtPWwO6Zd7nI8crJHhpl1rOHrzWbJkdfImhNygvlmunJKkvJ/5 T95MqxruN6LXcB2VeGrxz/mlO33TQ QYxGhBJHdpsCP61DTjDHTF9OAAAOkBMAqAQ5AYBKkBMAqAQ5AYBKkBMAqAQ5AYBKkBMAqAQ5AYBKkBMAqAQ5AYBKVMnpwoULYzHtiwkA9aFOTlUDOQHMF8gJAFSCnKrQ7Uirv5VJq5O3WV4dxBI1WtKpsjXKmbVxAm2HKV8/Hfdu/uVkPKTFWVjK0JVOy87AMqkbWbVsu43TYNzrouMBCW9XXe3WKqeza9d8yylvp81WZ4ysJWfZaarWpeHB1tCGWT5vrXI6O ZYTr3Rg3dKkxlVmTejf3M6w QGvXJ6ZQ5HYWmuufTY/v/HabnG63ZZsV22p5OMtMN83R4RutpY4lwzbc4r29eZ7byBVgfPrT/JyTvouK5512FkdOz7rV824YVVRrcjrcL73ZKWt3/YZfvaU2L0UqpPFZ2z5945r3fAfQnqQ dJTt2OtAqH3wV54dLccoOO6eo0js6WGZm5ysorO dhyuTFS uy5FvYxoJzzbTZV7ZNX4aDPHxd6USd/h7w2evizjto36c076Djujqvmf1LKOC3vue8RnILdlo50nTd77z UdA 7z309IuQPuW4du57Z/c7V7sC7ou3D7mZczl5LkZhdhOfgMq NmZn9Ulm5PzMdSbruKBzLSrb1dld7TfK9eYd7D1Yo2WXvObOsot/KRWOsqwkF 5rW8f9zmtPaL oUEeZe e9F573hfSh8yknTyeNI doQbecjDYW5tOz5FT6XIvK9j3EOW331j9aX7EEfGUXjzjKjbKMNnY70hrUUef99rWnLjl56ihz76rKKShvpJv5lVPRmtOsj5wK8 mNMXIKyfmXO0ItOXLKvS8TGDkFjrLSqVy30woQSMD99ranJjn56ihz77ztCqk3nDmWUzKwt/vTOus3Su68OuCGTFpOjqmGKd9uJ/K0sey5FpVtU37NyVl/HI0ubrdcx/tHBtlRmG9Nx76entF1//2tVuj9NvtcdpTY7bTyp1WZ9tQkJ28dZe6d75x97wvpQ27mW06DDpYztCz6BEuFnHzrI9brzqlH6LkWlV2inUGf1uWdY9lrnmSnEFFUPBoq d4k6S M504b3dduWMdQwMNPszqZY/LbU9e0ruicS9y7SnIK7UOjzL c4Jzhn6rB7ICcYOaJI2NtY2SBHGYVdXJiyxQIJY7MaeF4i7CgB1VyAgBIQU4AoBLkBAAqQU4AoBLkBAAqQU4AoBLkBAAqQU4AoBLkBAAqQU4AoBLkBAAqQU4AoJIZl9M0t8dga47ZvX7cu1lAlZzsjBeDn1lbYHQ7rf7PZrmDa31AitpVV7u13jut9 X8oUpOeZvVZ7dJ7Qmrt/2n1g4 z8y7nEALuuRk73fc7UgriiWO8pIN9v8/OKlf0XE242xDm5A00ncPfKOXWU4amZvyCsqiS06OzeAHnTI3wWUjJ/lfUdLJRsnEliSNJGlkhaSRyGlslMnJfEgSiSMjg0T/ATFfL846UTLpZOEDlZcAIC8NjiErkkaWSGDguzZj1KE8aST4USen4bpTLFHm4el1iuF6U0HnCUk66XtQSBo5hpx87alLTp46lCeNBD/65GSucxjTjt66U0CnDUk6WXoqklMGSSMrtL0mOc1w0kjwo1BO/dFRq5VdfIwjabRaxm/4gs4TnHTSP8IgaaT5OkkjC5NGsuY0NirllOng6c/tRdHSndiV1C9ETo5ySBpJ0khv/0qQUw2olBP4KBIpwHyAnGYAkkbCeQQ5zQAkjYTzCHICAJUgJwBQCXICAJUgJwBQCXICAJUgJwBQiWo57e3tSbvdluXlZbl06ZJcunRJVlZWpN1uy97e3tQvHgBMDpVyOj4 lps3b0qz2ZStrS05OjqSk5MTOTk5kYcPH8rW1pY0m025fv26PHr0aOoXEQDqR52cjo P5erVq7KxsSHPnj2TvHj27JncunVLrl69KsfHx1O/kABQL rkdOPGDdnY2BhIaHd3V9bW1mRpaUmWlpZkbW1N7t /P3h9Y2NDbt68OfULWR8h352bl /ZTfM85uUazh q5LS/vy/NZnMwYrp9 7ZcuHDBye3btwcjqGazKfv7 44y7R0B7F0NNDLOt/XPsi111q9VTohrmqiSU7vdlq2tLRERuX//fq6YUnZ3d0VEZGtrS9rttlWea9vUWCL1X5rVJKdx2jqNcmatbvChSk7Ly8tydHQkIiJra2uFclpbWxMRkaOjI1leXs6W501akEjQHkqlsnakZXgyjZQ8zr1BXH/jNFfmkyrZQXKvg3ntHHsbkYlljGsNIaiS08WLF X09FRERJaWlgrltLS0JCIip6encvHiRau8/sOcO1IK2F0xiY2MKQ0ra0fOzoils72EZFfJ2ewsOPtMFjKx5F1Dx/lXycQClZgLOT1 /FgWFxcdZdqjjZCtX4sypqT/NrOsVMj2MnJcndvXlswOQiaW8XbFJBPLRFAlp6rTusPDQ1lZWSksv7eda95va/ 0zi0ZoxNWzfYSlJQg4EENyg5CJpax5EQmlomgSk7mgvju7m7pBfHt7W1ZX18vUUfI/tAGzowp6TGmnCpke5nUyCkwOwiZWIraVd 1hnKoktPe3l7lPyUY TpLN5taKkkSa4tbT9aQUhlTEv8aT1I224shuEGZ/vWX/IVk898F2UFsyMRScM41XmsohSo5JUn H2EuLi7K4uKirK2tDUZM6R9h3rhxw1GWvd7k2OI2N2uIb23E96ma9XrZbC VsqsUfTrma48bMrH4zrneaw3FqJOT7q v B4iAKgTdXJKkuwXf7e3t Wnn36Sp0 fypMnT Tw8FC2t7en9MVf5ARwVqiUU8r /r6sr6/Lm2 KS 99JK8/PLLsrKyIuvr61PaMgU5AZwVquUEAOcX5AQAKkFOAKAS5AQAKkFOAKAS5AQAKkFOAKAS1XLqfveDfHDrjrx 5Zq8 Npb8uJrb8kb71yTD27dke53P0z94gHA5FApp Pj3 S9jz X5165LHfjr Xw51/l5ORUTk5O5cFPv8rd Gt57pXL8q8P/y2PHpF5BWAeUSen4 Pf5Mo/35f2p18Wfrfuw8/uyZV/vC/Hx79N/UICQL2ok9O7H30m7U /zJWSHe1Pv5T3Pv586heydtLtaNPN0 x/e4 fl6/ZTPM85uUazi6q5PTt9z/K869c9o6YXCOo51 5LN9 /6NVnr29ySxtY2Fv81q07WvAxnm1UFR XfVrlRPiOgtUyemDW3fkbvx1aTGlcTf Wj64daewAw037p/ hfcTKpuzllNo 6ddzqzVDUmiTE6vX7kmhz//Giynw59/ldevXLPKc3Quc39sY5pk75ZoTpviyN7h0BRcdnQ2skPlII2SLzuIuw3mhnajKZjMckgZRcqo USVnF549W9yevo0WE6np0/lhVf/5u68RscepkBybY3be hH5dOSVjScDsZRelyJVFDeaWR G oZOTVIGUXKqJlmLuT0 Mnv8qe/vO3uvCO/Ee2ONnzvIFFB qDFUX/Tf8de4EGpoBz42lD7tK5su31tJGVU8Pa9pIwaC1VyqjqtOzj6Rd54p8S0LiWT6MDuNLFE/Q41GCWlCQ/MaWFQKqgqbZiQnEgZ5bgepIzSiCo5VV0Qv/fVN3L9ky8KOpeBd9SSSmkoqYGwzKwsQamgQtswaTmRMip/dFOm/BA5MY2riio5db/7ofKfEox naV4vSJPNN1OL0WSud4SRw1ptVojH XSwUV2oYqciJllH96lVcHKaO0okpOSVLtjzDf/egzR1kFD7Tzk7Lsa5nht/O3oLWOkZsKKrQNoXIiZVTRv0kZNXuokxNfXwGAJFEopyTJfvH33lffyMP//FeePv2fPPn9dzk4 kXuffUNX/wFmHNUyinl2 9/lOuffCGvvf13 cOf/yp/fONteeOda3L9ky/YMgVgzlEtJwA4vyAnAFAJcgIAlSAnAFAJcgIAlSAnAFAJcgIAlSAnAFAJcgIAlSAnAFAJcgIAlSAnAFBJQxoNafT U1uhyAkAxuX/GOAudSfP1PcAAAAASUVORK5CYII=

There is a big difference between the docker application and the individual containers which are stored in different locations…

The location you’re using is where the docker application configuration can be found,
Each container’s configuration is stored with the individual container.

And, the recommended way that docker sets up its container networking is different than all other virtualization and isolation technologies, instead of using bridge devices, network forwarding is configured by command line, either when invoking the container or stored in the container’s docker file.

TSU

“The location you’re using is where the docker application configuration can be found”

I know that, this is what I’m talking about. The docker0 is the interface of docker application. This configured only when docker daemon is running. If this interface has no IP then you can not reach those container which are running below this docker host. This is my problem. :slight_smile:

As I wrote this is not docker application issue because it is working with Leap 42.3. I tried older docker version on Leap 15 but this problem also existence. So, this is absolutely OpenSuse problem.

OK, I see now that you are using the “new” way to configure docker networking (everyone should prefer to do this instead of the older docker networking my older container networks still use).

A general reference

AFAIK there is no way for a virtual bridge device like docker0 to go down by itself, even after a resume from hibernation (more on that in a moment). Bridge devices are associated (bound) to a physical interface, you should inspect state/status of your physical interfaces to make sure they are up. Seems to me from time to time people have posted in the Networking forum about their regular network interfaces not active when resuming from hibernation, you should look through those posts to see if any apply to you.

As for hibernating a Guest and in this case there are likely similarities between a container and hypervisor Guests, I strongly discourage that practice. Successful hibernation depends on all processes ending properly before the HostOS can go into hibernation, and because of the “Guest”/container isolation, it’s possible and in some cases likely that the HostOS can’t be fully knowledgeable about the isolated processes, with uncertain results… maybe pre-mature termination resulting in corruption, maybe lost state, maybe hangs, the possibilities are endless.

So, my strong recommendation is to either suspend or shutdown the Guest/container processes using their technologies own management before doing a HostOS hibernation.
Who knows, maybe the very practice of resuming a container’s networking before HostOS networking is available might be triggering your situation.

TSU

“So, my strong recommendation is to either suspend or shutdown the Guest/container processes using their technologies own management before doing a HostOS hibernation.”

This is what I want to avoid to stop and start every day. LDAP servers are running on our containers. So it take time when the ldap server will came up and running again. So we won’t change to Lead 15 if there is not solution for this. Stay on Leap 42 or changing to another Linux distribution.

Thanks.

My recommendation applies regardless of openSUSE version, or even distro, OS or any other platform.
The point is that when processes are not running under single management, “orphaned” processes may not be instructed to shut down gracefully, and sudden “kills” can result in corruption or lost data.

There are ways to automate shutdown of unmanaged processes, you likely only need to script shutting down anything unmanaged if you don’t want to do it manually.

I don’t see that startup time should be affected by an orderly shutdown. When a container starts up, it will run like any other machine process, and unless your application has to somehow restore state, you should experience “instant start.”

TSU