[Users] Docker inside an OpenVZ container

Tue Mar 24 01:42:00 PDT 2015

On 24.03.2015 02:59, Pavel Snajdr wrote:
> On 03/24/2015 12:48 AM, Pavel Snajdr wrote:
>> On 03/23/2015 11:01 PM, Kir Kolyshkin wrote:
>>>
>>>
>>> On 03/23/2015 03:12 AM, Benjamin Henrion wrote:
>>>> On Mon, Mar 23, 2015 at 10:55 AM, Narcis Garcia
>>>> <informatica at actiu.net> wrote:
>>>>> As I read from Ubuntu/Debian package (version 0.9.1):
>>>>>
>>>>> Docker complements kernel namespacing with a high-level API which
>>>>> operates at the process level. It runs unix processes with strong
>>>>> guarantees of isolation and repeatability across servers.
>>>>>
>>>>> Docker is a great building block for automating distributed systems:
>>>>> large-scale web deployments, database clusters, continuous deployment
>>>>> systems, private PaaS, service-oriented architectures, etc.
>>>>>
>>>>> This package contains the daemon and client. *Using docker.io on
>>>>> non-amd64 hosts is not supported at this time*. Please be careful when
>>>>> using it on anything besides amd64.
>>>>>
>>>>> Also, note that *kernel version 3.8 or above is required* for proper
>>>>> operation of the daemon process, and that any lower versions may have
>>>>> subtle and/or glaring issues.
>>>> Redhat backported a lot of LXC features to 2.6.32, so that's one of
>>>> the reasons you can run docker/lxc on top of the openvz kernel.
>>>
>>> In addition to that, we did a significant amount of kernel work
>>> to allow running Docker inside our containers.
>>>
>>> In general, OpenVZ kernel version (which is 2.6.32) has very little
>>> to do with vanilla 2.6.32, so this number doesn't really mean anything
>>> except that Red Hat kernel team branched their kernel off this
>>> version when they started working on RHEL6.
>>>
>>> Currently this is 2.6.32 plus tons of patches from Red Hat plus
>>> a pretty big patchset from OpenVZ. In particular, we make sure all the
>>> recent distros work inside containers, so sometimes we have to backport
>>> some new syscall or other feature from recent kernels.
>>>
>>> From time to time I see people saying OpenVZ kernel is very old and
>>> obsoleted. It happens because the judge by the label, and the label starts
>>> with 2.6.32. Indeed, 2.6.32 is a very old kernel, but as I explained above
>>> our kernel has very little to do with 2.6.32.
>>
>> Hi Kir,
>>
>> I've been telling those people just about the same thing, but recently I
>> don't think I can agree. I've become more involved in ZFS on Linux
>> development and we run on RHEL6 OpenVZ kernel. The core of RHEL6 is
>> getting old and there are lots and lots of improvement, that have gone
>> upstream, which improve mainly performance and multi-core scalability.
>> For instance and probably the most importantly for me now, I would like
>> to have VFS scalability patches, that have gone into upstream, in OpenVZ
>> RHEL6 kernel as well, as I'd like to see doing more granular eviction on
>> dentries. (http://lwn.net/Articles/636133/)
> 
> Sorry, linked the wrong thing, I mean two separate things. Primary
> objective is to have the shrinker work, which has gone to 3.12,
> secondary and nice to have would be these VFS scalability patches.

Dear Pavel,

such backports are quite hard for us.
I'm not decision maker, but it's unlikely that we'll do it in RHEL6-based kernels.
We inherit all infrastructure changes from RHEL6 kernels, and do not changes it without urgent need.
- we risks to broke stable RHEL6 kernel
- it makes hard maintenance, we'll need to re-apply these patches after rebase to new RHEL6 kernels.
- it requires careful testing, so it's an additional load for our QA,
- of course it's an additional task for our developers, but let's forget about this.

You could push RHEL6 and convince them that they need to do this job.
If you'll have hard arguments, they will add the patches into next major update,
update 7 is expected in few months, update 8 most likely will be released in next year.
However nobody guarantees that they will do it too.

Good news is that we're rebasing to RHEL7-kenrels.
So I would recommend you to look at RHEL7 kernels right now, and wait for our rhel7-based kernel.
Docker support in RHEL6 kernels delayed us a little, but anyway we expect to publish first beta in few months.
http://openvz.livejournal.com/49158.html

Thank you,
	Vasily Averin

>> But this seems rather impossible, due to git/separated-out-patches not
>> being available for RHEL6 kernel and OpenVZ project following the suit.
>> I would have to invest a lot of time every time a rebase onto a newer
>> RHEL6 kernel release is made.
>>
>> I would like to help out with OpenVZ development from time to time,
>> especially with things related to storage, but the project doesn't seem
>> all that open, you guys only publish your final results, but nothing
>> from the process of getting to them.
>>
>> I don't mean to criticize or I don't mean it in any other bad way,
>> here's me just sighing at how things are. Do you see any room for change
>> in this regard? Or should we just leverage Parallels paid support for
>> OpenVZ to have you guys pull in the patches by yourselves?
>>
>> I love open-source and doing things openly, I know that you guys don't
>> have a whole lot of breathing room thanks to Red Hat here, but is there
>> any possibility of opening the project up more?
>>
>> Finally, I would like to thank all of you at the OpenVZ project, there
>> is no other usable container technology for Linux without you guys. I
>> highly respect that fact despite the relative closedness of the project.
>>
>> /snajpa
>> (vpsFree.cz)
>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at openvz.org
>>> https://lists.openvz.org/mailman/listinfo/users
>>
> 
> _______________________________________________
> Users mailing list
> Users at openvz.org
> https://lists.openvz.org/mailman/listinfo/users
> 