Компания Parallels приняла решение (http://openvz.livejournal.com/49158.html) объединить кодовые базы открытой системы контейнерной виртуализации OpenVZ и проприетарного продукта Parallels Cloud Server (http://sp.parallels.com/ru/products/pcs/) (бывший Virtuozzo), и в дальнейшем развивать их в рамках нового единого открытого проекта Virtuozzo Core.
Отмечается, что в 2005 году во время основания OpenVZ компания Parallels допустила ошибку и вместо изначального применения открытой модели разработки для своего первичного продукта Virtuozzo, для продвижения технологий контейнерной виртуализации в основное ядро Linux начала развивать отдельный открытый проект OpenVZ, со временем превратившийся в независимое ответвление. В обоих продуктах для обеспечения изоляции используются одни и те же подсистемы ядра Linux, а различия сводятся к инструментарию, который стал несовместим на уровне опций и файлов конфигурации.Спустя девять лет компания Parallels решила исправить неверно принятое решение и объединить кодовые базы обоих проектов. Подобный шаг будет выгоден для пользователей открытого OpenVZ, так как они получат более качественно протестированный код и дополнительные функциональные возможности. Для компании новая организация разработки позволит снизить трудозатраты и избавиться от необходимости выполнения двойной работы при работе над компонентами, работающими в пространстве пользователя.
Объединение проектов планируется провести в несколько этапов. На первом этапе в начале 2015 года будет запущен Git-репозиторий, в котором будет представлен код модифицированного ядра Linux, основанного на пакете с ядром из RHEL7 и включающего дополнительные патчи для обеспечения контейнерной виртуализации. Внутренний процесс разработки в компании будет смещён в сторону упрощения использования Git, а также будет открыт публичный доступ к внутреннему списку рассылки, в котором ведётся обсуждение связанных с ядром Linux разработок компании, что позволит энтузиастам оперативно отслеживать все тенденции в разработке и принимать участие в обсуждении их целесообразности. Таким образом, сообщество превратится в полноценного участника развития проекта, а не отстранённого наблюдателя, как было до сих пор.
Со временем планируется открыть доступ и к системе отслеживания ошибок. В настоящее время информация о проблемах в Parallels Cloud Server обрабатывается в системе на базе JIRA, а OpenVZ в Bugzilla. Им на смену придёт единая унифицированная система, принцип организации доступа к которой будет напоминать системы отслеживания ошибок Red Hat и других поставщиков Linux-решений - доступ будет ограничен только для небольшой части проблем, связанных с ещё не исправленными уязвимостями.
URL: http://openvz.livejournal.com/49158.html
Новость: http://www.opennet.me/opennews/art.shtml?num=41350
Чего это они вдруг? Да ещё через 9 лет. Хотя лучше поздно, чем никогда, да?
Ядро OpenVZ не поддерживает Systemd. "Семейство" Red Hat плотно сидит на поделии Поттеринга, остальные тоже тихо переползают (к примеру Debian, который использует куча хостинг провайдеров). Соответственно, для контейнерной виртуализации в ближайшем будущем OpenVZ будет подходить мало. Надо же было что-то делать спасать потенциальную клиентуру.
А-а-а, то есть альтруизмом, проснувшейся совестью и т.д. тут и не пахнет? )
> А-а-а, то есть альтруизмом, проснувшейся совестью и т.д. тут и не пахнет?
> )Не мой взгляд, продавать "гипервизор" в 21м веке - задача весьма странная на фоне действий других игроков рынка.
VmWare ESXi - гипервизор бесплатен
XenServer - гипервизор бесплатен
Microsoft Hyper-V - гипервизор бесплатен
Parallels Cloud Server/Virtuozzo - гипервизор (я про контейнерный движок) платен!А теперь PCS/Virtuozzo встает с общий ряд с ними и дает основной функционал бесплатно, а дополнительный - бэкапы, облачное хранилище, управление облаком - платно.
Логичный путь и очень выгодный сообществу.
XenServer - гипервизор бесплатен.. — ДА НУ???????? :) :) :) :) :) :) :) :) :) :)
> XenServer - гипервизор бесплатен.. — ДА НУ???????? :) :) :) :) :)
> :) :) :) :) :)XenServer free edition - этого мало? :)
> XenServer - гипервизор бесплатен.. — ДА НУ???????? :) :) :) :) :)
> :) :) :) :) :)Не только бесплатен, но и практически с полным открытым кодом. С шестой версии начиная.
Пруфлинк будет?Моя организация БЫЛА ВЫНУЖДЕНА СНЕСТИ XenServer из-за НЕПОМЕРНЫХ денежных требований к Citrix Receiver
> Пруфлинк будет?http://xenserver.org/overview-xenserver-open-source-virtuali...
https://github.com/xenserverИ совершенно не понимаю, при чём тут Citrix Receiver, если речь о гипервизоре и управлении к нему.
Так Вы ещё и слепец, не читал но осуждаю )))Ресивер это клиент для продуктов XenApp (Presentation server)
XenServer мало того что бесплатен, но ещё и открытым исходным кодом, да и нет в нём ни каких (кроме архитектурных) ограничений в отличии от бесплатных VMWare и Hyper-V
> Citrix ReceiverА он в каком месте гипервизором является? Или вы читать не умеете?
Microsoft Hyper-V - гипервизор бесплатен... — для покупателей лицензии ВынСёрвер?
Чем ты болен, пацан?
У тебя ДЦП? :)
> Microsoft Hyper-V - гипервизор бесплатен... — для покупателей лицензии ВынСёрвер?
> Чем ты болен, пацан?
> У тебяНу почитайте что ли: http://www.osp.ru/win2000/2014/01/13039204/ ставьте линуксы и все будет бесплатно.
Там где есть MS не бывает бесплатно - очередная наживка не иначе.
> Там где есть MS не бывает бесплатно - очередная наживка не иначе.Вы так говорите, как будто я рекомендую поделку мелкомягких =) Если так показалось - сильно извиняюсь, я радикально против использования закрытых огороженных аналогов, которые легко и непринужденно могут стать платными либо вообще перестать быть :)
Ну серверную то ось купить придется :)
>> Microsoft Hyper-V - гипервизор бесплатен... — для покупателей лицензии ВынСёрвер?
>> Чем ты болен, пацан?
>> У тебя
> Ну почитайте что ли: http://www.osp.ru/win2000/2014/01/13039204/ ставьте линуксы и все
> будет бесплатно.Чюкча не читатель. Чюкча пользователь.
Почитайте этикету в своих трусах :)
Я имею дело с конкретными денежными требованиями поставщиков решений.
> Логичный путь и очень выгодный сообществу.Если уж они про сообщество, мне кажется что самым логичным было бы не брать какое-то левое ядро редхата, а втолкать патчи в майнлайн, а оттуда уже и редхат возьмет и кто там еще. А они могли бы вокруг этого поддержку оказывать и продавать всякие плюшки. Ну там энтерпрайзный управлятор/вебморду/консультации для энтерпрайзятников захотевших напирмер барыжить серверами на опенвз/экстренный трублешутинг/оптимизацию и прочее, например.
В идеале это могло бы выглядеть как-то так: у них крутится репа типа vz-next, а при наступлении окна приема патчей - оттуда pull request в майнлайн. Ну то-есть как обычно у ядерщиков. Далее пока идет -rc, заинтересованные в технологии усиленно тестируют это у себя на конфигах. Ну и получают в очередном майнлайне то что натестировали, что вполне честно :).
А возякаться с левыми ядрами - это гемор и прошлый век, господа. Если на то пошло - KVM например не требует кастомных ядер.
> Если уж они про сообщество, мне кажется что самым логичным было бы
> не брать какое-то левое ядро редхата, а втолкать патчи в майнлайн1) они и так вталкивают;
2) на чём основывать публикуемые стабильные выпуски -- консультировались с дистрибутивами и ответ был практически однозначным: дистрибутивы, поставляющие ovz-ядра, на то время брали за основу ветки на базе rhel-ных (это было в районе 2.6.18--32, точнее не скажу, можно поднять переписку).
> Ядро OpenVZ не поддерживает Systemd. "Семейство" Red Hat плотно сидит на поделии
> Поттеринга, остальные тоже тихо переползают (к примеру Debian, который использует куча
> хостинг провайдеров). Соответственно, для контейнерной виртуализации в ближайшем будущем
> OpenVZ будет подходить мало. Надо же было что-то делать спасать потенциальную
> клиентуру.Ыксперт-Оналитег опеннете в действии
Такой же путь был у них при открытии OpenVZ - только тогда они не поддерживали udev. комьюнити им дописало. Но что бы не иметь проблем с лицензией патч был отвернут и ровно такой же был написан сотрудником тогда еще swsoft. хотя какие проблемы с лицензией могут быть при использовании ядра linux?
не верите? поднимите архивы их форума.
> Но что бы не иметь проблем с лицензией патч был отвернут и ровно такой же
> был написан сотрудником тогда еще swsoft.Очевидно, не "с лицензией", а чтоб иметь авторские права.
патч под gpl, продукт под gpl - но таки не принимается :) с аргументацией - что тогда не сможем выпускать закрытые продукты. Таки лицензия виновата :-)
> Таки лицензия виновата :-)Учите матчасть -- нет.
были бы там bsdl этих проблем не было :) а так обычная жаба пропринетарщиков открывать свое и бояться что кто-то сделает на базе этого лучше.
> были бы там bsdl этих проблем не было :)Были бы другие -- что кто-то другой тоже может закрыть.
> а так обычная жаба пропринетарщиков открывать свое и бояться
> что кто-то сделает на базе этого лучше.Ещё раз: учите матчасть, прежде чем лезть в дискуссии по лицензированию и авторскому праву. В данном разе вопрос про copyright assignment, ради которых и заводят всякие contributor agreement.
> Были бы другие -- что кто-то другой тоже может закрыть.Ну да. Тут странное желание и рыбку съесть и на ежика не сесть. И иметь возможность закрывать код и заставлять всех остальных делиться.
Как это назвать - дело 10е, вопрос о поведении.
так и есть, появились docker, комюнити coreos пилят rocket, разработчики systemd пилят свою контейнеризацию.
Для поддержания интереса к своему продукту, нужно что-то делать.
> так и есть, появились docker, комюнити coreos пилят rocket, разработчики systemd пилят
> свою контейнеризацию.
> Для поддержания интереса к своему продукту, нужно что-то делать.Апстримная контейнеризация она одна на всех. Никто своей не пилит. Docker/Rocket/LXC - это лишь рулилки ядром из юзерспейса, не более, не менее. А-ля веб-морды. Сама суть внутри.
Но, стоит отметить, что более изолированные конетйнеры предоставляется только OpenVZ/PCS/Virtuozzo (ядро у них идентичное) и как раз поддержки этих самых контейнеров у Docker/Rocket и прочих пока нету, а хотелось бы.
полят-попилят, выпилить не могут. а Openvz уже здесь и уже работает, причем на порядок проще и удобнее чем все те недопилки вместе взятые.
> полят-попилят, выпилить не могут. а Openvz уже здесь и уже работает, причем
> на порядок проще и удобнее чем все те недопилки вместе взятые.Да, апстримные контейнеры по изоляции сливают OpenVZ, но из-за дикой старости ядра - в целом тоже сливают апстриму, но уже по производительности :) Так что сложный вопрос.
> Ядро OpenVZ не поддерживает Systemd. "Семейство" Red Hat плотно сидит на поделии
> Поттеринга, остальные тоже тихо переползают (к примеру Debian, который использует куча
> хостинг провайдеров). Соответственно, для контейнерной виртуализации в ближайшем будущем
> OpenVZ будет подходить мало. Надо же было что-то делать спасать потенциальную
> клиентуру.OpenVZ поддерживает systemd внутри контейнеров уже более полугода, с самого релиза Fedora/CentOS 7 c systemd. А то, что стоит на ноде - не так важно, там может быть и Debian 7 и CentOS 6.
> А то, что стоит на ноде - не так важно, там может быть и Debian 7 и CentOS 6.Хозяйке на заметку: http://altlinux.org/starterkits#server
>> А то, что стоит на ноде - не так важно, там может быть и Debian 7 и CentOS 6.
> Хозяйке на заметку: http://altlinux.org/starterkits#serverНеплохо! Но я вообще подумываю отказаться от дистрибутива на ноде как такового. CoreOS в этом плане гениален. От ноды ничего не требуется, кроме запуска контейнеров/цепляния стораджа, а все это можно забить в PXE.
> Неплохо! Но я вообще подумываю отказаться от дистрибутива на ноде как такового.
> CoreOS в этом плане гениален. От ноды ничего не требуется, кроме
> запуска контейнеров/цепляния стораджа, а все это можно забить в PXE.Да можно и в PXE, было бы желание. Если хотите, давайте попробуем сообразить и сделать.
Да честно говоря, мне кажется, нет смысла что-либо делать пока. Я хочу дождаться RHEL7 ядра от OpenVZ, котором научится systemd, а потом взять CoreOS, заменить ядро и водрузить Rocket для менеджмента, тогда все и сойдется :)
>От ноды ничего не требуется, кроме запуска контейнеров/цепляния стораджаА от гостя тоже ничего не требуется кроме запуска приложения... Казалось бы.
Но практика показывает, что на данный момент намного комфортнее рулить из полноценной операционки полноценной операционкой(пусть минималистичной, но полноценной). И как ни парадоксально может показаться, нормальный дистрибутив работает значительно стабильнее и предсказуемее, чем обмылок наподобие ESXi. Это наблюдение касается гипервизоров и виртуалок, но уверен что с контейнерами все аналогично.
>>От ноды ничего не требуется, кроме запуска контейнеров/цепляния стораджа
> А от гостя тоже ничего не требуется кроме запуска приложения... Казалось бы.
> Но практика показывает, что на данный момент намного комфортнее рулить из полноценной
> операционки полноценной операционкой(пусть минималистичной, но полноценной). И как ни
> парадоксально может показаться, нормальный дистрибутив работает значительно стабильнее
> и предсказуемее, чем обмылок наподобие ESXi. Это наблюдение касается гипервизоров и
> виртуалок, но уверен что с контейнерами все аналогично.У меня обратная ситуация, а от дистрибутива, пока он был центос 5 - были лишь проблемы :) И если бы дистрибутив менялся в два клика - эксплуатация сотен ферм была бы решительно проще.
>>>От ноды ничего не требуется, кроме запуска контейнеров/цепляния стораджа
>> А от гостя тоже ничего не требуется кроме запуска приложения... Казалось бы.
>> Но практика показывает, что на данный момент намного комфортнее рулить из полноценной
>> операционки полноценной операционкой(пусть минималистичной, но полноценной). И как ни
>> парадоксально может показаться, нормальный дистрибутив работает значительно стабильнее
>> и предсказуемее, чем обмылок наподобие ESXi. Это наблюдение касается гипервизоров и
>> виртуалок, но уверен что с контейнерами все аналогично.
> У меня обратная ситуация, а от дистрибутива, пока он был центос 5
> - были лишь проблемы :)какие?
> И если бы дистрибутив менялся в
> два кликаДа было бы хорошо, если бы была кнопка "сделать хорошо". И почему ты думаешь, что нормальный дистр не может управляться двумя кликами из ЦУПа, а "голый" может?
> - эксплуатация сотен ферм была бы решительно проще.
Предпочитаю говорить предметно. Маркетинговые спичи про облака над Сколково не впечатляют.
>[оверквотинг удален]
>> У меня обратная ситуация, а от дистрибутива, пока он был центос 5
>> - были лишь проблемы :)
> какие?
>> И если бы дистрибутив менялся в
>> два клика
> Да было бы хорошо, если бы была кнопка "сделать хорошо". И почему
> ты думаешь, что нормальный дистр не может управляться двумя кликами из
> ЦУПа, а "голый" может?
>> - эксплуатация сотен ферм была бы решительно проще.
> Предпочитаю говорить предметно. Маркетинговые спичи про облака над Сколково не впечатляют.Ну а что предметно - вот у вас 50 нод на CentOS 5 + OpenVZ 2.6.32 (да, был апгрейд с 2.6.18). CentOS 5 скоро пойдет в EOL и вообще неюзабелен (Python 2.4? Доисторический Ruby. libstdc++ лохматой версии) и как обновиться без даунтайма контейнеров? А если /vz не вынесен в отдельный раздел? А каков шанс, что после предложенного шаманства все не сдохнет?
А в случае дистрибутива стянутого с PXE, все что потребуется на новое ядро и юзерспейс - ребут и все! По-моему, зачетно :)
> Ну а что предметно - вот у вас 50 нод на CentOS
> 5 + OpenVZ 2.6.32 (да, был апгрейд с 2.6.18). CentOS 5
> скоро пойдет в EOL и вообще неюзабелен (Python 2.4? Доисторический Ruby.
> libstdc++ лохматой версии) и как обновиться без даунтайма контейнеров? А если
> /vz не вынесен в отдельный раздел? А каков шанс, что после
> предложенного шаманства все не сдохнет?Если чисто умозрительно заменить CentOS 5 на ESX 3.5 или CoreOS, картина станет только печальнее.
Каким образом использование специализированного дистрибутива с урезанным и нестандартным инструментарием должно решить проблему EOL + ССЗБ? )
PS: Решить наверно можно если пофантазировать: реплицировать контейнеры, или mount --bind.
> А в случае дистрибутива стянутого с PXE, все что потребуется на новое
> ядро и юзерспейс - ребут и все! По-моему, зачетно :)Это тоже другой вопрос. Так можно загружать и любой самый обычный дистрибутив. Не готов обсуждать все плюсы и минусы, только замечу, что PXE сократит трудочасы, но не даунтайм.
PS:
>А каков шанс, что после предложенного шаманства все не сдохнет?
>[оверквотинг удален]
> Каким образом использование специализированного дистрибутива с урезанным и нестандартным
> инструментарием должно решить проблему EOL + ССЗБ? )
> PS: Решить наверно можно если пофантазировать: реплицировать контейнеры, или mount --bind.
>> А в случае дистрибутива стянутого с PXE, все что потребуется на новое
>> ядро и юзерспейс - ребут и все! По-моему, зачетно :)
> Это тоже другой вопрос. Так можно загружать и любой самый обычный дистрибутив.
> Не готов обсуждать все плюсы и минусы, только замечу, что PXE
> сократит трудочасы, но не даунтайм.
> PS:
>>А каков шанс, что после предложенного шаманства все не сдохнет?Тут шансы зависят только от моей кривости рук и только :) Каждый выбирает что удобно ему, мне мой вариант видится более удобным, когда диски вообще пусты и вся конфигурация фермы хранится на сервере конфигурации и получается машиной по сети. А на системе хранения данные только клиентов.
> Ну а что предметно - вот у вас 50 нод на CentOS 5 + OpenVZ 2.6.32 [...]
> и как обновиться без даунтайма контейнеров?Возможно, с промежуточной их миграцией, если поставлена задача предельной минимизации. Но я такое не делал, только видел фокус в руках Кирилла во время его доклада в Обнинске.
> А если /vz не вынесен в отдельный раздел?
Возможно, есть смысл в финте ушами с созданием отдельного на этот раз корня (если есть возможность -- впрочем, диски времён centos5, т.е. старше трёх лет, всяко в группе риска) и страховочного симлинка, который в текущей системе выглядит как /vz/vz -> . (иначе придётся сразу mv, а это более чревато).
> А каков шанс, что после предложенного шаманства все не сдохнет?
На это должно давать ответ стендовое тестирование. Но гарантию не даст и оно.
> А в случае дистрибутива стянутого с PXE, все что потребуется на новое
> ядро и юзерспейс - ребут и все! По-моему, зачетно :)Вот только "и всё" может включать "...сдохло" точно так же, а вся подготовительная работа из варианта "много на стенде и много по каждому узлу" превращается в вариант "очень много на стенде и чуточку по каждому узлу".
Плюс работоспособность HN будет зависеть ещё и от того места, где лежит корень. Это вполне нормально в ряде случаев, не знаю, как в этом конкретном -- опять же надо проверять год-другой, по-хорошему.
PS:
> мне мой вариант видится более удобным, когда диски вообще пусты и вся конфигурация
> фермы хранится на сервере конфигурации и получается машиной по сети. А на системе
> хранения данные только клиентов.Нечто подобное делали в рамках Clustrx в своё время, но там более чёткое разделение было -- вот здесь ферма управления, она грузится с локальных дисков, где мини-HN и по LXC-контейнерам распиханы сервисы (которые устанавливаются/конфигурируются/обновляются/удаляются из консоли управления кластером); а вот здесь бездисковые вычислительные узлы (либо дисковые, где весь диск отдан под своп для tmpfs). Немного упрощаю, т.к. посреди ещё MM были для сетевой загрузки, но это уже издержки масштаба (~5000 узлов).
Не подходит как "Bare Metal" решение
> Не подходит как "Bare Metal" решениеК слову, в PCS есть полноценный гипервизор, но его вряд ли будут открывать :) Хотя судя по ценам на него (сущие копейки за VM) - его, к сожалению, никто и не покупал.
Неправда ваша. Зачем утверждать то, чего не знаете или не понимаете?Текущее ядро опенвз позволяет запускать в контейнерах дистрибутивы с системд, например последние Федоры.
Я думаю что тут дела еще и в конкуренции. LXC, Docker, bla.А в выигрыше обычно то что работает с дефолтным ядром, в мейнлайне.
Весьма странно называть докер, предпочитающих в качестве graph-драйвера aufs, работающим с мейнлайновым ядром.
> Весьма странно называть докер, предпочитающих в качестве graph-драйвера aufs, работающим
> с мейнлайновым ядром.Инженеры Parallels уже очень давно работают над интегарцией Docker и OpenVZ/Containers: https://github.com/docker/libcontainer/pulls и фильтруйте по avagin - это один из инженеров ||, который работает над проектом.
Ну как чего... LXC слегка наступают на пятки, и дальше закрывать код стало бессмысленно.
Гы, смешно. Если учесть что в lxc они же много тащили.
> Ну как чего... LXC слегка наступают на пятки, и дальше закрывать код
> стало бессмысленно.Алекс, LXC - это управление, а код в ядре - Linux Container. Который процентов на 30-40 написан сотрудниками Parallels и отправлен в апстрим. Как они могут конкурировать-то?
> Алекс, LXC - это управление, а код в ядре - Linux Container.Не вижу противоречия. LXC - это управление, PCS - в основном тоже, плюс кое-какие ядерные наработки... А ядерный код OVZ и так открыт.
>> Алекс, LXC - это управление, а код в ядре - Linux Container.
> Не вижу противоречия. LXC - это управление, PCS - в основном тоже,
> плюс кое-какие ядерные наработки... А ядерный код OVZ и так открыт.Ну PCS - это куча закрытого юзерспейса + опенвз ядро + закрытые ядерные модули. Так что в общем-то да, разработка ядра станет лишь открытее и все. А вот с юзерспейсом - что будет вопрос.
LXC наступает на пятки? Лол, 90% кода LXC это и есть OpenVZ патчи
>объединяютсяО, это такая редкость в мире опенсорса. Уважуха.
>>объединяются
> О, это такая редкость в мире опенсорса. Уважуха.Да, эта новость просто made my day :) Просто потрясающе!
Вы о чём, вы понимаете что происходит вообще?
> Вы о чём, вы понимаете что происходит вообще?Крутой известный и популярный проект переходит на открытую модель разработки - вся суть новости :)
>> Вы о чём, вы понимаете что происходит вообще?
> Крутой известный и популярный проект переходит на открытую модель разработки - вся
> суть новости :)вам только кажется что переходят на открытую модель. В лучшем случае Open Core.
> Подобный шаг будет выгоден для пользователей открытого OpenVZ, так как они
> получат более качественно протестированный код и дополнительные функциональные > возможности.Может быть пользователи Virtuozzo получат более качественно
протестированный код?
>> Подобный шаг будет выгоден для пользователей открытого OpenVZ, так как они
>> получат более качественно протестированный код и дополнительные функциональные > возможности.
> Может быть пользователи Virtuozzo получат более качественно
> протестированный код?Да, именно так. У меня в свое время было 50/50 - PCS/OpenVZ на сотнях нод и практика показала, что OpenVZ в десятки раз надежнее и предсказуемее работает.
Видимо, вчера от сообщества был получен первый полезный коммит, который захотелось включить в общую ветку
Коммиты им много раз высылались, но почти никогда не принимались. У меня есть несколько штук - для vzctl reinstall, для поддержки openvswitch. Но их уже долгое время никто не мержит :(
> Видимо, вчера от сообщества был получен первый полезный коммит, который захотелось включить в общую веткуНа самом деле всё может быть просто и банально. Надо только узнать, кто был основным спонсором закрытой разработки.
>> Видимо, вчера от сообщества был получен первый полезный коммит, который захотелось включить в общую ветку
> На самом деле всё может быть просто и банально. Надо только узнать,
> кто был основным спонсором закрытой разработки.Любые платные разработки в тот же OpenVZ заказываемые в Parallels всегда выкладывались в полной мере в открытый код на git.openvz.org :) Но вопрос в том, что делали эти доработки сотрудники же ||. А вот случаев приема откровенно внешнего кода в проект я не видел ни разу.
>>> Видимо, вчера от сообщества был получен первый полезный коммит, который захотелось включить в общую ветку
>> На самом деле всё может быть просто и банально. Надо только узнать,
>> кто был основным спонсором закрытой разработки.
> Любые платные разработки в тот же OpenVZ заказываемые в Parallels всегда выкладывались
> в полной мере в открытый код на git.openvz.org :) Но вопрос
> в том, что делали эти доработки сотрудники же ||. А вот
> случаев приема откровенно внешнего кода в проект я не видел ни
> разу.да? напомните когда был открыт vziolimits? а когда он реально был сделан.. ?
Назрело.
> Назрело.Угу, проект OpenVZ (я про юзерспейс) в полудохлом состоянии последние пару лет и я искренне боялся, что на него забьют вообще. Если vzctl можно хоть как-то повторить самому, то ploop - дико сложная система (впрочем, как и почти любая другая ФС).
>> Назрело.
> Угу, проект OpenVZ (я про юзерспейс) в полудохлом состоянии последние пару лет
> и я искренне боялся, что на него забьют вообще. Если vzctl
> можно хоть как-то повторить самому, то ploop - дико сложная система
> (впрочем, как и почти любая другая ФС).ploop вещь простая - ram fs - еще проще :-) так что не надо тут..
Лучше скажите почему swsoft отказался интегрировать в свои утилиты учет трафиком? Хотя патчи ходят по форуму уже лет 5. со слов dev@swsoft это выходит за пределы разрешенного открытой версии.
Правда что ли?
>[оверквотинг удален]
>> Угу, проект OpenVZ (я про юзерспейс) в полудохлом состоянии последние пару лет
>> и я искренне боялся, что на него забьют вообще. Если vzctl
>> можно хоть как-то повторить самому, то ploop - дико сложная система
>> (впрочем, как и почти любая другая ФС).
> ploop вещь простая - ram fs - еще проще :-) так что
> не надо тут..
> Лучше скажите почему swsoft отказался интегрировать в свои утилиты учет трафиком? Хотя
> патчи ходят по форуму уже лет 5. со слов dev@swsoft это
> выходит за пределы разрешенного открытой версии.
> Правда что ли?Если Вы считаете, что ploop - простой, то я бы хотел увидеть его портинг в апстрим, это именно то, что сейчас нужно очень многим.
Управление трафиком там есть, если хочется шейпер, что на OpenVZ, что на PCS, пожалуйста: https://github.com/FastVPSEestiOu/openvz-network-shaper - работает в продакшене уже годы.
> Если Вы считаете, что ploop - простой, то я бы хотел увидеть его портинг в апстрим, это именно то, что сейчас нужно очень многим.Сколько пива выставите ?:) он реально простой - это же блочное устройство - а не FS.
Портирование можно сделать за неделю - было бы желание и свободное время.управление трафиком в vzctl? или сторонними тулзами? я вообще о патче на vzctl и шеловый скрипт который они используют для поднятия сети.
Кстати - баг с 2мя сетевками на OpenVZ хосте они починили - когда arp -s pub ставился не на тот адаптер ?
>> Если Вы считаете, что ploop - простой, то я бы хотел увидеть его портинг в апстрим, это именно то, что сейчас нужно очень многим.
> Сколько пива выставите ?:) он реально простой - это же блочное устройство
> - а не FS.
> Портирование можно сделать за неделю - было бы желание и свободное время.А как быть с юзерспейсом ploop? vzctl compact научить сжимать ext4 в случае развесистой метадаты - еще то развлечение, || эту фичу уже год обещает и постоянно откладывает :/ Да и когда речь идет про все связанное с хранением - надо иметь полные покрывающие тесты. У || они есть, а у нас, увы, нету, что приводит к тому, что их надо написать и досконально понимать что и когда может произойти.
Кроме этого, из сложностей ploop - собственный фреймворк для записи данных на диск в обход page cache - это еще то развлечение, можете полистать код, там много и забористо.
> управление трафиком в vzctl? или сторонними тулзами? я вообще о патче на
> vzctl и шеловый скрипт который они используют для поднятия сети.
> Кстати - баг с 2мя сетевками на OpenVZ хосте они починили -
> когда arp -s pub ставился не на тот адаптер ?
>>> Если Вы считаете, что ploop - простой, то я бы хотел увидеть его портинг в апстрим, это именно то, что сейчас нужно очень многим.
>> Сколько пива выставите ?:) он реально простой - это же блочное устройство
>> - а не FS.
>> Портирование можно сделать за неделю - было бы желание и свободное время.
> А как быть с юзерспейсом ploop?Юзер спейс ploop - это только монтирование/вытаскивание образа. что такое ext4 и вообще любая другая FS - ploop не знает. Еще раз подчеркну ploop это только блочное устройство.
> vzctl compact научить сжимать ext4 в
> случае развесистой метадаты - еще то развлечение, || эту фичу
> уже год обещает и постоянно откладывает :/Учитывая кучу комитов от паралелс в ext4 для resize - можно предположить что это сделано на базе этой фичи.
И она весьма не стабильна сейчас. Что в очередной раз поднимает вопрос о стабильности ext4. Родившейся из вполне понятного набора патчей одной конторы.> Да и когда речь
> идет про все связанное с хранением - надо иметь полные покрывающие
> тесты. У || они есть, а у нас, увы, нету, что
> приводит к тому, что их надо написать и досконально понимать что
> и когда может произойти.Зная как идет разработка внутри parallels - могу сказать что врядли у них есть тесты. Так же могу назвать стопку проблем с OpenVZ которые не исправлены и существуют by design. Для затравки предложу подумать что будет если попытаться ограничить запись журнала в рамках iolimit. или что делать в случае NFS клиента (как известно сделаного в виде FSM) когда один или несколько процессов влетают в hard cpu limit. Можно еще вспомнить :)
> Кроме этого, из сложностей ploop - собственный фреймворк для записи данных на
> диск в обход page cache - это еще то развлечение, можете
> полистать код, там много и забористо.Так просто как 2 копейки :-) полистайте код http://git.whamcloud.com/fs/lustre-release.git - там более не тривиальные вещи.
>>> Если Вы считаете, что ploop - простой, то я бы хотел увидеть его портинг в апстрим, это именно то, что сейчас нужно очень многим.
>> Сколько пива выставите ?:) он реально простой - это же блочное устройство
>> - а не FS.
>> Портирование можно сделать за неделю - было бы желание и свободное время.Так что там с пивом? сколько готовы выставить :)
Новость всего лишь о намерении. То есть ни о чём.
> Новость всего лишь о намерении. То есть ни о чём.Поцаны словами не бросаются :) Теперь сообщество с них не слезет, если "забудут"
:)
>> Новость всего лишь о намерении. То есть ни о чём.
> Поцаны словами не бросаются :) Теперь сообщество с них не слезет, если
> "забудут"
> :)пацаны долго закрывали патчи на ядро (начиная с 2.4.20 а открытая версия с 2.6.32). где было это сообщество ?
>>> Новость всего лишь о намерении. То есть ни о чём.
>> Поцаны словами не бросаются :) Теперь сообщество с них не слезет, если
>> "забудут"
>> :)
> пацаны долго закрывали патчи на ядро (начиная с 2.4.20 а открытая версия
> с 2.6.32). где было это сообщество ?Закрывать патчи на ядро никто не запрещает, тем более патчи для 2/6/32 и 2/6/18 вполне доступны. Разве что они влиты в один патч по аналогии с тем, как поступает RedHat. Но код - открыт, берите, читайте, изучайте.
>>>> Новость всего лишь о намерении. То есть ни о чём.
>>> Поцаны словами не бросаются :) Теперь сообщество с них не слезет, если
>>> "забудут"
>>> :)
>> пацаны долго закрывали патчи на ядро (начиная с 2.4.20 а открытая версия
>> с 2.6.32). где было это сообщество ?
> Закрывать патчи на ядро никто не запрещает, тем более патчи для 2/6/32
> и 2/6/18 вполне доступны. Разве что они влиты в один патч
> по аналогии с тем, как поступает RedHat. Но код - открыт,
> берите, читайте, изучайте.То есть распространять продукт на базе linux kernel без раскрытия исходников можно ? и даже не нарушать GPL ?
а как с тем что когда их просили предоставить исходники посылали лесом.
А когда человек раскрыл их старый код на базе 2.4.20 - ему грозили всякими карами и судом.
>[оверквотинг удален]
>>> с 2.6.32). где было это сообщество ?
>> Закрывать патчи на ядро никто не запрещает, тем более патчи для 2/6/32
>> и 2/6/18 вполне доступны. Разве что они влиты в один патч
>> по аналогии с тем, как поступает RedHat. Но код - открыт,
>> берите, читайте, изучайте.
> То есть распространять продукт на базе linux kernel без раскрытия исходников можно
> ? и даже не нарушать GPL ?
> а как с тем что когда их просили предоставить исходники посылали лесом.
> А когда человек раскрыл их старый код на базе 2.4.20 - ему
> грозили всякими карами и судом."То есть распространять продукт на базе linux kernel без раскрытия исходников можно ? и даже не нарушать GPL ?" - про какие времена Вы говорите? 2.6.18 - код был всегда. 2.6.32 - код был всегда. Что-то раньше, боюсь, я просто не застал, я не такой старый :)
> "То есть распространять продукт на базе linux kernel без раскрытия исходников можно
> ? и даже не нарушать GPL ?" - про какие времена
> Вы говорите? 2.6.18 - код был всегда. 2.6.32 - код был
> всегда. Что-то раньше, боюсь, я просто не застал, я не такой
> старый :)2.4.20, 2.6.8. 2.6.18 появился весьма не сразу как был сделан. Я к сожалению сталкивался с этим почти с момента создания Virtuozzo.
У них типо проблемы начались с Parallels Cloud Server или что, кто за новостями следит, кто в курсах?
Да и востребованность OpenVZ явно падает.
> У них типо проблемы начались с Parallels Cloud Server или что, кто
> за новостями следит, кто в курсах?
> Да и востребованность OpenVZ явно падает.Новостей о проблемах с PCS или падением востребованности OpenVZ я не наблюдал. А про OpenVZ наблюдаю скорее обратное - http://stats.openvz.org
Вы даёте ссылку на сайт OpenVZ...
> Вы даёте ссылку на сайт OpenVZ...Эта статистика собирается простым баш скриптом в vzctl зависимостях, так что не вижу смысла ей не верить. Да и только у наших клиентов порядка сотен 5 инсталляций OpenVZ на железе, так что я думаю - весьма внушительная цифра.
А Вы в OpenVZ работаете? А я вижу смысл не верить, ни одна компания не признается, что у неё начались проблемы, иначе ситация станет ещё хуже, они будут врать, что угодно и рисовать графики, какие нужно.У OpenVZ 500 клиентов, вы поняли, да?
Уходим на Docker, котаны.
Я не работаю в ||, ни в OpenVZ. Я говорю лишь о числе серверов на ovz, у меня как у оператора Дата Центра.
> У OpenVZ 500 клиентов, вы поняли, да?
> Уходим на Docker, котаны.1) из пальца можно высосать и не такие "открытия";
2) поищите docker cve;
3) нет, тоже не "в openvz".
Вот список:
- https://archipelproject.org
- cloudstack
- coreos.com
- eucalyptus
- https://github.com/siemens/jailhouse
- https://juju.ubuntu.com
- https://maas.ubuntu.com
- opennebula
- openstack
- proxmox
- smartos.org
- webvirtmgr ( https://github.com/retspen/webvirtmgr/wiki/Screenshots )Какие вы еще хорошие решения знаете?
Как обновить ОС template?
> Как обновить ОС template?1) собрать начисто (я так делаю при помощи altlinux.org/m-p);
2) распаковать рутом, сделать chroot внутрь, обновить пакеты*, выйти, запаковать.* может понадобиться либо настройка резолвера, либо указание источников по ip-адресу
> Как обновить ОС template?Ровно также как и отдельно стоящую ОС: yum update/apt-get update; apt-get upgrade;
А вот при апдейтах с одной ветки дистрибутива на другую стоит быть готовым написать в поддержку. Например, при обновлении с Debian 6 на Debian 7 меняется система инициализации и если воткнуть обычный апстарт - все рухнет и придется писать хостеру. Тоже самое касается имени шаблона ос - если центос 6 обновить, например, на 7ку в контейнере, то она тупо не запустится, ибо sysv init заменили на systemd и OpenVZ должен знать, что ostemplate поменялся и надо дергать иные скрипт.
Надо бы сформулировать это как фичриквест в опенвз, что-то типа синхронизации ostemplate с тем, что реально стоит внутри контейнера.
>> Как обновить ОС template?
> Ровно также как и отдельно стоящую ОС: yum update/apt-get update; apt-get upgrade;Плюс еще куча дополнительных телодвижений. Если мы конечно хотим получить нормальный template, а не просто обновить ОС в отдельном контейнере.
> готовым написать в поддержку. Например, при обновлении с Debian 6 на
> Debian 7 меняется система инициализации и если воткнуть обычный апстарт -
> все рухнет и придется писать хостеру.Мне кажется, что ты путаешь Debian с RHEL/Centos и Ubuntu. В wheezy(7) и squeeze(6) одна и та же система инициализации - sysvinit. Вот в jessie(8) планируется уже смена на systemd. А upstart вообще в ubuntu.
>[оверквотинг удален]
>> Ровно также как и отдельно стоящую ОС: yum update/apt-get update; apt-get upgrade;
> Плюс еще куча дополнительных телодвижений. Если мы конечно хотим получить нормальный template,
> а не просто обновить ОС в отдельном контейнере.
>> готовым написать в поддержку. Например, при обновлении с Debian 6 на
>> Debian 7 меняется система инициализации и если воткнуть обычный апстарт -
>> все рухнет и придется писать хостеру.
> Мне кажется, что ты путаешь Debian с RHEL/Centos и Ubuntu. В wheezy(7)
> и squeeze(6) одна и та же система инициализации - sysvinit. Вот
> в jessie(8) планируется уже смена на systemd. А upstart вообще в
> ubuntu.Там немного хитрее все, вот посмотрите: https://bugzilla.openvz.org/show_bug.cgi?id=2647
Посмотрел. Кто-то "умный" собрал шаблон беты debian 7 с upstart вместо дефолтного sysvinit. При обновлении этого чуда произошел закономерный факап. С обновлением с debian 6 до debian 7 это не связано никак.
Мне неоднократно приходилось успешно обновлять squeeze до wheezy в контейнерах без доступа к хардварной ноде. Проблемы были, но совсем не того плана.
> Посмотрел. Кто-то "умный" собрал шаблон беты debian 7 с upstart вместо дефолтного
> sysvinit. При обновлении этого чуда произошел закономерный факап. С обновлением с
> debian 6 до debian 7 это не связано никак.
> Мне неоднократно приходилось успешно обновлять squeeze до wheezy в контейнерах без доступа
> к хардварной ноде. Проблемы были, но совсем не того плана.Это стандартный имадж из dowload.openvz.org. Но это баг апдейтера в той же степени - зачем он меняется SYSInit - неизвестно. Вдруг я осознанно хочу свой "любимый" upstart?
> Это стандартный имадж из dowload.openvz.org.Ну расскажите по контакту там же, что он крив и лучше убрать (предъявив способ воспроизведения проблемы).
Почему у меня в стандартном образе debian 7 с dowload.openvz.org никакого upstart нет? Буквально вчера разворачивал несколько контейнеров и сразу же делал в них dist-upgrade. Ты хочешь убедить меня, что мне dowload.openvz.org тайно отгружает правильный образ, а тебе из вредности глючный?
Это не баг апдейтера, а баг в ДНК того, кто собрал глючный образ, не понимая работу apt-get/aptitude.
Если Вы так уверены в своей правоте, то чего на форуме пишете? Тут подразумевается, что могут быть версии. А Вы искренне уверены в своей, что же - пусть так и будет :)