[Users] Docker inside an OpenVZ container

[Pavel Odintsov]

Yep, nice suggestion!

An every switch between Red Hat kernel 2.6.32 milestones produce big
amount of bugs in OpenVZ. But do not provide enough benefits for
customers.

And I'm sure number of bugs in case of switch between major upstream
kernel versions (for example 3.10~3.11) will be same or even much
times less because every new version bring new code from OpenVZ patch
to upstream.

>From my point of view, an ideal approach about kernel version used in
CoreOS. They follow vanilla kernel and provide new features as soon as
possible (overlayfs, vxvlan, dpdk, vswitch, syn proxy, batch routing,
tcp/ip stack optimization, live kernel patching).

But the work with really huge companies and with important data and
know what is reliability. And they use vanilla kernel.

Yep, security flaws is and issue but we use containers and 90% of
kernel bugs is not affect us. For very important bugs kpatch could be
used for live patching.

Second nice idea from CoreOS project is consistent upgrade when we
could automatically switch to next OpenVZ kernel version on next
reboot (or kernel panic, it's more recent for OpenVZ).

I'm really sure old approach "we use old kernel and we assume it's
stable" become completely useless today.

Because old kernel has bunch of problems (route cache? syn cookies?
listen block on socket?) even in subsystems architecture and very
important things like tcp routing subsystem.






On Tue, Mar 24, 2015 at 2:57 PM, Narcis Garcia <informatica at actiu.net> wrote:
> A good strategy could be to make OpenVZ become fully as an LXC
> enhancement, and apply patches thinking in datacenter scenario for LXC.
> This focus could make easier to follow Linux kernel versions.
>
> OpenVZ for Linux 2.6.32 is excellent, but the time makes grow some
> matters that didn't seem a problem in 2010.
>
>
> El 24/03/15 a les 10:05, Pavel Odintsov ha escrit:
>> Hello, folks!
>>
>> CentOS 6 with 2.6.32 kernel is real nightmare (even in case of
>> networking) from my point of view. Simple syn flood could KILL my
>> HWN's (I can share details off list).
>>
>> You (Parallels) and RH do big amount of backporting but upstream is
>> far away in future.
>>
>> Difference even between 3.17 and 3.18 kernels is EXTREMELY HUGE. You
>> could look at diffs here
>> https://github.com/torvalds/linux/commits/master. And performance
>> could be improved for 50-70% with this upgrade (I assume even more
>> speed up with update from 2.6.32RH to 3.18).
>>
>> Red Hat interested only in few things about 2.6.32 kernel for running
>> Java and KVM (with Oracle?). But storages (what about stable
>> filesystem like ZFS instead bunch-of-crap-ext4 and
>> it-will-be-non-stable-for-ever-btrfs?), networking (routing! routing!
>> routing!) and many other extremely important things is out of focus.
>>
>> And I have innate desire to test new RHEL 7 kernel and switch my
>> hundreds of servers to it :)
>>
>> But this kernel based on enough old 3.10 kernel will be "obsolete"
>> since release (look at my comparison about 3.17 & 3.18 kernel).
>>
>> IMHO, best approach for OpenVZ will be "follow the upstream" because
>> your patch have significantly reduced since 2.6.32.
>>
>> You are trying to keep up stability with following to Red Hat with old
>> kernels but in reality OpenVZ kernel is not really stable (you could
>> grep my bug reports at bugzilla.openvz.org and found hundreds of
>> issues with stability) even with RH kernel.
>>
>> My instances with upstream kernel could work many months without any
>> issues. Yep, it's enough stable and completely suitable for OpenVZ
>> HWN's.
>>
>>
>
> _______________________________________________
> Users mailing list
> Users at openvz.org
> https://lists.openvz.org/mailman/listinfo/users



-- 
Sincerely yours, Pavel Odintsov