Just saw your other thread, Verifying that this machine isn't experiencing the same problems as the other one, that only this one has networking problems? Now want to ask if this machine had functional networking "as is" with its current configuration before an upgrade? Also, Are you using Docker files to build your docker containers? And, are you using any other composition tools? Tony On Sun, Jan 5, 2020 at 10:53 PM Tony Su <tonysu@su-networking.com> wrote:
I'm really surprised, I've never heard that any Guest running any virtualization on any kind of hypervisor would have any kind of problem running docker and having a networking problem.
There should be two possible approaches to your problem based on a common idea... All network bridge devices are the same regardless of how they were created and if they were created by a virtualization tool or not. Once created, they should be discoverable by any entity that needs to use a bridge device. For this reason, although it's possible to cascade bridge devices, you should avoid if possible.
So your likely choices, 1. If you create a bridge device in the Guest, it has to be bound to a network interface which communicates correctly with the HostOS network interface which in the case of Xen installed on openSUSE/SUSE likely itself has a bridge device bound to the network interface. Yes, that starts getting complicated, so...
2. You can go "old school" and implement docker networking the old way without a bridge device. Here is one old piece of documentation that describes how things used to be done and should still work
https://github.com/putztzu/docker/blob/master/docs/installation/linux/SUSE.m...
Otherwise, if you want to configure the first scenario above , you'll have to post your bridge device configurations for both in your Guest and your HostOS describing the actual physical interfaces they're bound to and what type of bridge device each are (are all bridging, are any NAT? Depending on the type of bridge may also need further details). Personally though, I like to live a life as uncomplicated as possible, I even avoid virtual switches as much as possible unless there is a real need that can't be accomplished by using bridge devices intelligently.
HTH, TSU
On Sun, Jan 5, 2020 at 8:41 AM Glen <glenbarney@gmail.com> wrote:
On Mon, Dec 23, 2019 at 1:26 AM Jan Beulich <jbeulich@suse.com> wrote:
On 21.12.2019 07:31, Glen wrote:
So just for laughs, I ran an lsmod in both modes, and sorted and diffed them: br_netfilter bridge One of these two is, according to my experience, a fair candidate for your problems. I'm not a networking specialist at all, so I can't give any suggestions on how to convert the upgraded guest to a network config not requiring these modules. (Trying to get rid of br_netfilter alone may be easier, but again I'm not really knowledgeable in this area at all.)
All -
During the past two weeks I've been trying to hunt these down, and I have discovered why these modules are loading.
The Xen guest is running Docker.... and Docker needs those modules to provide access to the outside world for docker container networking.
Those two modules don't exist in /etc/modprobe.d, and I can rmmod them without damaging the Xen guest at all - but when I do, the Docker containers lose their network connectivity. None of my other guests run Docker, which is why those modules don't exist in the other guests, and why, I'm now guessing, the other guests don't have crash issues.
*sigh*
So I may be in a chicken-and-egg scenario here, but I'll just put this out there - has anyone tried running Docker on a Xen guest, and/or could there be anything in those two modules Jan mentioned, or in Docker, that could be causing or related to these issues?
I'd be grateful for any thoughts anyone might have!
Glen -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org