What's missing from upstream kernel containers? - Kir Kolyshkin, Sergey Bronnikov
•Download as ODP, PDF•
4 likes•1,561 views
What's missing from upstream kernel containers? - Kir Kolyshkin, Linux Plumbers 2015
Recommended
Recommended
More Related Content
What's hot
What's hot (17)
Viewers also liked
Viewers also liked (19)
Similar to What's missing from upstream kernel containers? - Kir Kolyshkin, Sergey Bronnikov
Similar to What's missing from upstream kernel containers? - Kir Kolyshkin, Sergey Bronnikov (20)
More from OpenVZ
More from OpenVZ (20)
Recently uploaded
Recently uploaded (20)
What's missing from upstream kernel containers? - Kir Kolyshkin, Sergey Bronnikov
- 1. Containers in the upstream kernel (as compared to VZ kernel) Containers in the upstream kernel (as compared to VZ kernel) Kir Kolyshkin, Sergey Bronnikov
- 2. Who we are?Who we are? • OpenVZ is an open source implementation of Linux containers • Kir Kolyshkin - leading OpenVZ for 10 years • Sergey Bronnikov - community manager of OpenVZ project
- 3. OpenVZ contribution to the Linux kernel:OpenVZ contribution to the Linux kernel: v2.6.13v2.6.16v2.6.19v2.6.22v2.6.25v2.6.28v2.6.31v2.6.34v2.6.37 v3.0 v3.3 v3.6 v3.9 v3.12 v3.15 v3.18 HEAD 0 100 200 300 400 2000+ commits
- 4. Is OpenVZ kernel upstreamed yet? ● Yes! ● About 60% ● Biggest pieces: – NET and PID namespaces – Memory cgroup, device cgroup – CRIU – NFS virtualization
- 5. Virtuozzo kernel changes (LOC)Virtuozzo kernel changes (LOC) RHEL5 (2.6.18) RHEL6 (2.6.32) RHEL7 (3.10) 0 70000 140000 210000 280000 264,641 202,746 66,324
- 6. Things we (still) need to add 1/2 ● Ploop and related ext4 changes ● Memory management and accounting – backport of kmemcg – idle memory tracking (for vcmmd) – network buffers memory accounting – OOM killer virtualization ● /sys and /proc virtualization
- 7. Things we (still) need to add 2/2 ● Network: venet, iptables (marks) ● FUSE upstream backports ● Printk virtualization ● /dev/console virtualization ● Time namespace (for monotonic timers wrt migration) ● Misc legacy (vziolimit, vzlist, vzredir, vznetstat, beancounters...) – Beancounters: numiptent, numfile, numproc
- 8. Any patches? Questions?Any patches? Questions? Kir Kolyshkin kir@openvz.org, @kolyshkin Sergey Bronnikov sergeyb@openvz.org, @estet
Editor's Notes
- Зачем нам отдавать свои патчи в мейнстрим меньше усилий по поддержке своих патчей во время переезда на новую версию ядра хотим, чтобы нашими контейнерами можно было пользоваться без установки специального ядра FIXME: количество патчей для разных компонентов ядра 2.6.18 vs 2.6.32, 2.6.32 vs 3.11 FIXME: добавить картинку с нашими патчами в upstream (http://openvz.org/File:Kernel_patches_stats.png) мы добавили: namespaces (pid, ipc, network) CRIU cgroups controllers нужен график коммитов в ядро http://openvz.org/File:Kernel_patches_stats.png У нас есть OpenVZ -- большой набор патчей, реализующих разную функциональность для контейнеров. Эта функциональность делится на некие "кирпичики", составляющие. Ну, например, network namespaces -- возможность иметь в ядре Линукса не одну сущность под названием "сетевая подсистема", а много. Эта сущность включает в себя экземпляр TCP/IP стека, таблицы маршрутизации, таблицы фаерволлинга, всякие разные кеши и хеши, ну и собственно сами сетевые устройства. Возможность создавать свои отдельные экземпляры сетевой подсистемы, отдавать его контейнеру, прокидывать туда устройства и т.п. -- это и есть один из "кирпичиков", из которых построена OpenVZ. Так вот, время от времени мы берём такой кирпичик и пытаемся воссоздать его в мейнстрим-ядре. Не просто послать на linux-kernel@ часть наших патчей, а именно воссоздать, то есть по сути с нуля, заново реализовать, представить на суд общественности, получить комментарии, поправить, представить на суд общественности -- и так далее, пока или оно не будет принято, или кончится терпение и мы плюнем на это неподъёмное дело. Вот таким примерно образом мы "засовываем" OpenVZ в мейнстрим ядро. После того, как "кирпичик" появляется в мейнстриме, мы выкидываем аналогичную часть из нашего патча и адаптируемся к мейнстримному (иногда написанному нами же, иногда нет). http://k001.livejournal.com/774225.html Отчего же тогда мы не отдаём весь ядерный код OpenVZ в ваниллу? Мы отдаём! Уже несколько лет как этим занимаемся, с переменным успехом (сейчас, я посмотрел, в ядре примерно 1700 патчей от нас, что не так уж и хреново, хотя, конечно, хочется много больше). Как это примерно происходит, описано выше на примере PID namespace. Бывает, что сложнее, бывает, что проще, бывает, что вообще не удаётся сделать то, что примут. Не потому, что криво, глючно и никому не надо, как думают аналитики на ЛОРе, а потому, что процесс принятия патчей -- сложный, по ряду причин. Например, мало кто понимает, что такое контейнеры и нафига они вообще нужны. Или понимают, но имеют своё, отличающееся от нашего видение, как решать ту или иную проблему. Поэтому тут больше надо разговаривать, убеждать, отстаивать свои подходы, чем просто писать и засылать хороший код. Для тех, кто думает, что на самом деле всё просто, а просто наши инженеры тупые -- покажите мне, сколько ваших нетривиальных патчей приняли, и мы поговорим. Что насчёт светлого будущего? Какое оно? Когда оно наступит? В нашем понимании, идеальное светлое будущее -- это когда OpenVZ патч к ядру будет нулевого размера, то есть мы хотим, чтобы вся функциональность, которая есть в OpenVZ, появилась в ванильном ядре. Когда это наступит? Я боюсь, что никогда, ибо мир неидеален. Но если, скажем, в ванилле будет 60 или 80% нашей функциональности -- я буду счастлив (сейчас там примерно 20-30%, точнее сложно сказать). http://ru-openvz.livejournal.com/1970.html
- This slide show amount of patchset for three