Comments 16
Друзья, ну вы что-то затянули. Я понимаю, что LXC на пятки наступает, но вполне возможно благодаря открытию разработки сообществу несколько лет назад, в Docker возможно использовались бы ваши технологии.
Cогласен, индусы из ibm захватили своим lxc всё, что так долго завоевывалось openvz. Хотя я пользуюсь и lxc, и openvz, openvz мне более симпатичен.
Не понимаю сравнений openvz с lxc. Openvz — прежде всего ядро, lxc можно сравнивать с vzctl.
Что касается докера — в libcontainer вторым по вкладу вижу сотрудника parallels.
Что касается докера — в libcontainer вторым по вкладу вижу сотрудника parallels.
Боюсь вас разбудить, но Docker и LXC именно наши технологии и используют — те, что мы влили в ванильное ядро (network namespace, pid namespace, IPC namespace, разные улучшения для cgroups и так далее — всего около 2000 патчей).
Ваш К.О.
Ваш К.О.
Остался главный вопрос: почему вы ведёте разработку в отдельном репозитории, а не в апстриме? Боитесь язвительных комментариев из LKML?
Конечно же нет. Мы разрабатываем ядро в отдельном репозитории просто потому что так удобнее. Все свои изменения мы пытаемся добавить в апстримное ядро, но так как процесс этот не быстрый, то проще вести разработку в своём репозитории и параллельно вести работу с апстримом.
Вот, к примеру, патчи от проекта CRIU (Checkpoint and Restore in Userspace) — http://criu.org/Upstream_kernel_commits. Вот патч от нашего разработчика, который делает новый memory management для конетйнеров в 3.10 — https://lkml.org/lkml/2015/2/11/347. Остальные примеры вы можете сами найти.
P.S. есть ещё отчет о контрибьюторах в Linux ядро от Linux Foundation
Вот, к примеру, патчи от проекта CRIU (Checkpoint and Restore in Userspace) — http://criu.org/Upstream_kernel_commits. Вот патч от нашего разработчика, который делает новый memory management для конетйнеров в 3.10 — https://lkml.org/lkml/2015/2/11/347. Остальные примеры вы можете сами найти.
P.S. есть ещё отчет о контрибьюторах в Linux ядро от Linux Foundation
Не боимся, у нас уже около 3000 коммитов в ядро.
$ cd git/linux
$ git pull
$ git log --format=oneline --author='@openvz.org|@parallels.com|@sw.ru|@swsoft.com|@sw.com.sg|kuznet@|gorcunov@' -E | wc -l
2739
Ваш К.О.
$ cd git/linux
$ git pull
$ git log --format=oneline --author='@openvz.org|@parallels.com|@sw.ru|@swsoft.com|@sw.com.sg|kuznet@|gorcunov@' -E | wc -l
2739
Ваш К.О.
Крутейшая новость :) Интересно, а код настоящей итеративной live миграции откроют или нам придется подтянуться и выложить свою реализацию для нее в user space? :)
Код уже открыт: это проекты CRIU (Checkpoint and Restore in Userspace) и p.haul.
отсутствие совместимости ядра со старой версией утилиты для управления контейнерами vzctl, вследствие изменения API для управления контейнерами
это как раз то, чего когда-то не хватало LXC, а теперь наоборот github.com/lxctl/lxctl.
Это временная несовместимость. Мы не можем сделать всё и сразу, поэтому совместимости пока нет. Но в планах есть пункт с починкой этой совместимости. Кстати, если у вас есть опыт разработки, то можете заняться. У нас очень дружелюбные разработчики и если где-то будет непонятно, то они направят и помогут. :)
Так мы тоже умеем: openvz.org/Vzctl_for_upstream_kernel
Что-то по ссылке на репозиторий ядра открывается вики.
Дайте угадаю, поменяли в конфиге веб-сервера listen local_ip:80 на listen 80 и сделали не restart, а reload? :)
Дайте угадаю, поменяли в конфиге веб-сервера listen local_ip:80 на listen 80 и сделали не restart, а reload? :)
Нет, вы не угадали. Вот ссылка на репозиторий ядра https://src.openvz.org/projects/OVZ/repos/vzkernel/browse.
Sign up to leave a comment.
Virtuozzo переходит на открытую модель разработки