[lxc-users] Containers have network issues when their host uses a bonded interface

[Peter Steele]

On 09/13/2015 06:19 AM, Fajar A. Nugraha wrote:
> Had you use Ubuntu you could probably say something like "kernel 4.2
> should be released as linux-generic-lts-wily for ubuntu 14.04 in about
> two months, and we can switch to distro-supported package then"
>
> Had you use Oracle Linux with support subscription, you could probably
> nag them about when they would relase unbreakable enterprise kernel
> release 4, which should be newer kernel, with some features added by
> oracle, tested and supported to run on oracle linux (which is mostly a
> clone of RHEL, with some additions)
>
> Had you use RHEL with support subscription, you could probably ask
> Redhat to backport kernel fix for this particular issue to RHEL 7's
> kernel.
>
> Since you use Centos, your best bet would probably:
> - Hope someone else nags Redhat, so the fix would eventually trickle
> down to centos. OR
> - Use 4.2 kernel, with its consequences (e.g. not tested and supported
> by redhat). OR
> - Try kernel 4.1. That version should be an LTS kernel, and elrepo
> would probably release kernel-lt 4.1 for rhel/centos7 (like they did
> with rhel/centos 5 and 6) sometime in the future. Being longterm
> kernel, you should be able to stick with kernel 4.1.x for a few years,
> without having to upgrade to mainline/stable kernel.
>
The decision to go with CentOS was made some time ago. We did a network 
throughput comparison between the Ubuntu and CentOS releases available 
at that time and CentOS performed better. Since then CentOS has been 
very solid for us, and this is the first real issue we've faced. If we 
had gone with RHEL of course, we'd be hitting the same problem right 
now, and of course we'd be reporting this bug. Alas, getting a fix from 
Redhat in a timely manner, even with a support contract, would not 
necessarily be an expedient process.

We will have to do some thorough testing with the 4.2 (or possibly 4.1) 
kernel over the next few weeks to make sure this kernel doesn't 
introduce new issues. Our only other option would be to fall back to KVM 
instead of containers and that's not something we really want to do.