Надо понимать, что большая часть людей разрабатывает ядро за деньги. На мой взгляд, основная проблема — это практически полное отсутствие тестов. Они потихоньку появляются, но пока это все в очень начальном состоянии. Мы гоняем CRIU тесты на linux-next, и даже они ловят багов в ядре столько, что мы не успеваем их разгребать. Обычно, ждем пару дней и вот если баг не рассасывается, начинаем смотреть.
Да, и вы опять противоречите себе. То у вас нет своего ядра, то вы там что-то фиксите и накатываете? Где можно посмотреть ваши фиксы к вашему же ядру? Вы же знаете, что их надо выкладывать в публичный доступ?
Т е вы без опыта разработки ядра, полезете и все там пофиксити? Извините, не верю, что из этого что-то хорошее получится. Одна из идей работы с апстримом — это подтверждение свой компетенции. Если вы ничего не делаете с ядром, а потом вдруг решаете там что-то пофиксить, скорей всего ничего хорошего не получится. И вот такие вот фиксы, я бы называл грязным вмешательством без кавычек.
То что вы называете «грязным вмешательством» имеет хороший выхлоп в upstream. Кроме того, что мы добавляем новую функциональность, мы регулярно находим баги в апстримном ядре и фиксим их. К слову о том, кто тут может обеспечить поддержку своих продуктов, я не поленился и посмотрел сколько раз ваша компания упоминается в ядре. Ровно два раза! Это нам говорит, что ядро не входит в вашу поддержку. Может проверим и остальные компоненты?
Вы не совсем понимаете, как работает opensource, иначе вас бы не удивляло, что наш kvm для некоторых типов нагрузок работает быстрее. Приведу простой пример. Нами была реализована хостовая часть драйверов hyper-v, что позволило виндовым гостям взлетать с нативными драверами и использовать все прелести паравиртуализации. Вся эта функциональность тут же ушла в апстрим, но в rhel она появится в следующем мажорном релизе, а у нас уже все работает, и до следующего релиза будут новые фишки.
Изначально, я свой интерфейс делал через netlink, но неожиданно для себя обнаружил, что этот мощный интерфейс считается для нужд сетевой подсистемы и некоторые попытки использования его в других подсистемах плохо себя показали. Это я к тому, что если надо мой новый интерфейс не имеет жестких завязок на /proc.
Сама идея файловой системы /proc не является ошибочной. На пример, в /proc есть «magic symlink» (/proc/pid/root, /proc/pid/fd/X, /proc/pid/cwd, etc), которые вряд ли получится заменить на что-то координатно другое.
Через livepatch можно делать относительно простые изменения, которые не затрагивают изменения структур данных. Да и ядра для убунты нет.
Для вашего примера, LXC более чем достаточен. OpenVZ используется, когда действительно нужна изоляция контейнеров друг от друга, когда контейнеры отдаются в третьи руки, а в этом случае базовый дистрибутив играет уже второстепенную роль.
Понятие «работает» у всех разное. В случае с OpenVZ доступ к контейнеру можно отдать кому угодно. В случае с LXC этого сделать нельзя, потому что пользователь в контейнере довольно легко может положить всю ноду. Если вам нужен chroot для запуска отдельного окружения, то LXC легко справится с этой задачей. Если вы хотите отдавать доступ к контейнеру в третьи руки, то LXC вам не подходит.
В 2009 году в LXC работы с памятью просто не было, там и сегодня не все так хорошо. В OpenVZ в то время использовались UBC, которые действительно вызывали много вопросов у пользователей. Сегодня схема работы с памятью совсем другая и она сильно приближена к обычно системе. У контейнера есть два лимита на память и на своп.
Если это будет чистое qemu (без kvm), то должно задампиться. С kvm все сложнее, там часть стейта в ядре и его нужно как-то сохранять. Мы этим не занимались, потому что у qemu есть свой механизм миграции и он работает более оптимально, чем это сделаем CRIU.
Можно сказать docker run, но это будет не одно и то же. Во-первых, ядро будет старое. Во-вторых, в Dockere трудно стартануть всю систему целиком. В-третьих, Travis был просто взят для примера. Применений у этого подхода масса. У меня вот сейчас крутится джоб, который тестирует Linux-next ядра.
Я сначала отладил перезагрузку через kexec и только потом добавил обновление системы. Просто перезагрузка занимает пару минут, с обновлением минут 15-20.
На самом деле не так там все и медленно. Вот, на пример, джоб с компиляцией ядра и прогоном всех наших тестов бежит за пол часа https://travis-ci.org/avagin/criu/builds/186831426
Смотри, оказывается тесты в трависе гоняются и уже несколько месяцев https://travis-ci.org/xemul/criu/jobs/130000751.
Еще мы используем patchwork https://zdtm.openvz.org/project/criu/series/?ordering=-last_updated
И статический анализатор кода https://scan.coverity.com/projects/avagin-criu
Вы не совсем понимаете, как работает opensource, иначе вас бы не удивляло, что наш kvm для некоторых типов нагрузок работает быстрее. Приведу простой пример. Нами была реализована хостовая часть драйверов hyper-v, что позволило виндовым гостям взлетать с нативными драверами и использовать все прелести паравиртуализации. Вся эта функциональность тут же ушла в апстрим, но в rhel она появится в следующем мажорном релизе, а у нас уже все работает, и до следующего релиза будут новые фишки.
Сама идея файловой системы /proc не является ошибочной. На пример, в /proc есть «magic symlink» (/proc/pid/root, /proc/pid/fd/X, /proc/pid/cwd, etc), которые вряд ли получится заменить на что-то координатно другое.
Для вашего примера, LXC более чем достаточен. OpenVZ используется, когда действительно нужна изоляция контейнеров друг от друга, когда контейнеры отдаются в третьи руки, а в этом случае базовый дистрибутив играет уже второстепенную роль.
В 2009 году в LXC работы с памятью просто не было, там и сегодня не все так хорошо. В OpenVZ в то время использовались UBC, которые действительно вызывали много вопросов у пользователей. Сегодня схема работы с памятью совсем другая и она сильно приближена к обычно системе. У контейнера есть два лимита на память и на своп.
На самом деле не так там все и медленно. Вот, на пример, джоб с компиляцией ядра и прогоном всех наших тестов бежит за пол часа https://travis-ci.org/avagin/criu/builds/186831426
Еще мы используем patchwork https://zdtm.openvz.org/project/criu/series/?ordering=-last_updated
И статический анализатор кода https://scan.coverity.com/projects/avagin-criu