Разработчики OpenVZ анонсировали выпуск Virtuozzo 7 Technical Preview для контейнерной технологии

Coming Soon

KVM-based virtual machines

Самое нужное-то не сделали еще

Осуществлён переход на уникальные идентификаторы (UUID) вместо числовых идентификаторов (VEID) для контейнеров

Ну наконец.

Ага, ну наконец то можно будет выкинуть все скрипты пользователей, пользовательские врапперы и обвязки, так-как они наивно считают, что CTID это число. А если создавать через prlctl контейнер, то vzlist как раз будет отображать этот UUID в поле CTID.

Им сразу нужно было делать уникальные идентификаторы, а получилось вот, как всегда.

4-е поколение менеджера памяти

Так что это за зверь, в двух словах как всегда не судьба?

Если вкратце, то так: Главный плюс нового менеджера памяти в том, что он использует memory cgroups, которые есть в мейнстрим ядре, и максимум нашего кода вынесено в пространство пользователя и реализовано в виде отдельного сервиса. Тем самым мы уменьшили набор патчей, которые отличают vzkernel от ванильного ядра. С точки зрения пользователя практически ничего не изменилось.

Сарказм ваш понятен. Формулировка получилась не совсем точная. Мы имели ввиду, что появится поддержка виртуальных машин QEMU/KVM.

Что подразумевается под поддержкой: изначально в коммерческой Virtuozzo был диспатчер для управления контейнерами и виртуальными машинами, в качестве гипервизора использовали свою собственную разработку. В Virtuozzo 7 мы будем вместо своего собственного гипервизора предлагать KVM/QEMU, а управление CT/VM с помощью связки libvirt и диспатчера. Драйвер для libvirt в целом уже работоспособный и все изменения в апстриме. Осталось все это интегрировать с диспатчером и протестировать. К слову Virtuozzo 7 это единственное решение, которое позволит управлять и контейнерами и виртуальными машинами на одном сервере с помощью libvirt.

Ubuntu с Debian как обычно в пролёте?

а где пилят виртуоза ?

Осуществлён переход на уникальные идентификаторы (UUID) вместо числовых идентификаторов (VEID) для контейнеров.

жаль. Все таки с контейнерами в основном человек работает, а теперь все свели к роботам.

Нет, вот темплиты для дебиана и убунты - https://src.openvz.org/projects/OVZT. Ну и в дистрибутиве они есть.

В рассылке и репозиториях.

Анон говорит что на Дебиан и убунте виртуозу он погонять не может.

Если вкратце, то так: Главный плюс нового менеджера памяти в том,
что он использует memory cgroups, которые есть в мейнстрим ядре, и
максимум нашего кода вынесено в пространство пользователя и
реализовано в виде отдельного сервиса. Тем самым мы уменьшили
набор патчей, которые отличают vzkernel от ванильного ядра.

А когда вы сделаете второй шаг, и перейдёте на LXC, который есть в мейнстрим ядра, чтобы набор патчей, которые отличают vzkernel от ванильного ядра, сократился до 0?

Для Fedora 22 есть пакеты?

Есть RPM пакеты, которые собираются на CentOS 7 и, насколько я знаю, они должны подойти для Fedora 22.

У меня недавно возникла странная идея. А возможно в контейнере запустить иксы с выводом на монитор?

Я в предыдущем анонсе уже отвечал про LXC, но чтобы вам не ходить по ссылке я приведу здесь ответ:

«Что такое LXC? Во-первых, это проект (в основном ведущийся сотрудниками компании IBM), ставящий своей целью обеспечить функциональность контейнеров а-ля OpenVZ в ванильном ядре. Во-вторых, так называют совокупность всех тех „кирпичиков“ для построения контейнеров, которые уже есть в ванильном ядре (забегая вперёд — это namespaces и cgroups). В-третьих, так называется утилита командной строки (в некотором смысле аналог vzctl), которую можно использовать с ванильным ядром для создания, запуска и т.п. контейнеров Кто написал LXC? Во-первых, его ещё не написали, там не хватает много какой функциональности (например, возможности „впрыгнуть“ в существующий контейнер). Во-вторых, если вопрос про утилиты, то Даниэль Лезкано из IBM France, а если про ядро — то кто только не писал. Скажем, CGroups — это переделка cpusets, которую изначально написали SGI, а переделал Поль Менаж, который в то время работал в Google. Контроллер памяти, PID namespace, network namespace написали в основном мои коллеги из Parallels (Linux kernel team) Паша Емельянов и Ден Лунёв, помогали им местами товарищи из IBM India и IBM US.

Как OpenVZ использует LXC? Все куски, которые попадают в ваниллу (например, неймспейсы), мы сразу же начинаем использовать в своих ядрах, выкидывая аналогичный кусок функциональности из своего патчсета, который у нас там был с незапамятных времён. То есть мы используем ядерную функциональность LXC. И не только используем, но и добавляем новую!

Например, вот как произошло с PID namespace. В наших ядрах был свой PID namespace, а потом Паша взял себя в руки и засабмитил его (в виде набора патчей, вестимо) для включения в ванильное ядро. Пришли кернель дивелоперы из IBM India и сказали „нам так не надо, нам надо эдак“ и засабмитили свой патчсет, с блекджеком и шлюхами возможностью создавать pidns внутри pidns (то есть делать иерархические пид-неймспейсы). Паша померял производительность своего и индийского варианта и возразил, что у них получилось тормозно. Индийцы возразили, что у Паши нет возможности создавать иерархии. Тогда Паша взял себя в руки и дописал поддержку иерархий. И сказали индийцы, что это хорошо, что-то там ещё подправили и засабмитили (от Пашиного имени — так тоже можно делать) ещё раз. И вошла эта фича в ваниллу.

Таким образом, OpenVZ можно рассматривать как надстройку над LXC (потому как LXC ещё не дописана, многих вещей в ванилле нет, OpenVZ патч это добавляет) плюс наши утилиты командной строки (vzctl и друзья), плюс всякие шаблоны и т.п. А разработчики OpenVZ — одновременно разработчики LXC!»

И по поводу разработчиков LXC:

«На смену OpenVZ в мейнстрим пришли lxc - linux containers. Существует несколько разных людей и команд, которые заинтересованы в том, чтобы в Линуксе (в мейнстрим-ядре) появились контейнеры и вся сопутствующая функциональность. Одна из таких команд — OpenVZ. Как я выше написал, мы сабмитим патчи в мейнстрим, иногда их даже принимают (какое-то время Parallels даже был в top10 linux contributing companies). Одна из других команд — это ребята из IBM (Франция, Индия, США). Их много и они упорные, и кроме некоторых патчей в ядро, они пишут свои утилиты. Вот LXC — это то, что есть в менйстримном ядре (включая патчи от OpenVZ, IBM и других людей типа Эрика Бидермана), плюс эти самые lxc утилиты. В противоположность, OpenVZ — это то, что в мейнстримном ядре, плюс наши патчи, плюс наши утилиты. Что из этого всего следует — решать вам.»

Уменьшить патч для наших контейнеров, который мы постоянно портируем с ядра на ядро, мы пытаемся уже несколько лет. Делаем мы это двумя путями:

• портирование функциональности из нашего ядра в апстрим (это то, что выше было написано). Прогресс можно оценить на графике.
• перенос кода из ядра в пространство пользователя. Здесь CRIU был пилотным проектом - раньше весь код для живой миграции был в ядре. Мы сделали утилиту, которая позволила все это сделать из пространства пользователя. Изменения в ядре были минимальными. Теперь мы сделали тоже самое с менеджером памяти (vcmmd) - в ядре используем memory cgroups, а остальная часть кода в юзерспейсе.

Выглядит очень неплохо. Хорошая основа, контейнеры ресурсно экономны, шаблоны есть для большинства систем, требования к железу минимальны.

А теперь еще и масштабируемо будет, если добавят обычные виртуалки.

У меня недавно возникла странная идея. А возможно в контейнере запустить иксы с выводом на монитор?

Иде совершенно не странная. Попытки есть, в принципе, ничего в этом сверхординарного нет, достаточно пробросить устройства видеокарты в виртуалку.

Вот тут вроде ещё с 2006 года люди пытались http://forum.openvz.org/index.php?t=msg&th=776

спасибо

Паша взял себя в руки и...

Похоже у вас только Паша и работает :) Паша возьми себя в руки и втолкни наконец оставшиеся патчи в ядро ;)

и Ден Лунёв

Ох пафосно то как. :) С Пашей запросто, а тут аж... его величество Ден. Так и напишите: Денис Лунев. Он стесняется своего имени или бальшая насяльника? ;)

PS: Кстати спасибо за толковый подробный коментарий. Изначально не верил в то что у вас получится слить ваши патчи с ядром, но сейчас вижу что надежда есть.

PPS: Паша, мы верим в тебя ;)

диспатчер

диспатчера

диспатчером

По-русски всё же принято писать «диспетчер»...

Ага, ну наконец то можно будет выкинуть все скрипты пользователей, пользовательские врапперы и обвязки, так-как они наивно считают, что CTID это число. А если создавать через prlctl контейнер, то vzlist как раз будет отображать этот UUID в поле CTID.

Обновись, когда свои портянки поправишь, силком апдейты натягивать никто не тащит. Заодно почитай «People have names».

По-моему, Рутковски пыталась это сделать в Qubes OS, получилось ли, я не следил.

>Virtuozzo 7 это единственное решение, которое позволит управлять и контейнерами и виртуальными машинами на одном сервере с помощью libvirt.

OVirt скорее всего сразу запилят докер очень скоро. Но вообще проект интересный, я бы даже резюме закинул если есть удаленка и нужны спецы именно по vdi/svi на kvm

Интересно, насколько оно рабочее?

И есть ли сборка под арм?

Да, но чтобы запилить поддержку Docker в oVirt нужно сделать драйвер для Docker в libvirt. А я такого драйвера в списке не вижу. Даже если драйвер появится, то он будет управлять только контейнерами Docker. А наш драйвер может одновременно управлять и ВМками и контейнерами. То есть более эффективно можно использовать серверные мощности.

По-моему, Рутковски пыталась это сделать в Qubes OS, получилось ли, я не следил.

Там это все делается поверх xen и vt-d. Это совсем другое. А здесь без ~ всякого оверхеда ставим маленький гипервизор и просто отдаем видеоустройство в контейнер.

А наш драйвер может одновременно управлять и ВМками и контейнерами. То есть более эффективно можно использовать серверные мощности.

звучит как proxmox...

У Proxmox, насколько я знаю, нет API для управления контейнерами и виртуальными машинами.

У Proxmox, насколько я знаю, нет API для управления контейнерами и виртуальными машинами.

ну собственно, сам проксмос ориентирован на человека. Это конечный продукт. А для человека АПИ, это вебинтерфейс и в нем есть управление и контейнерами и виртуальными машинами. И в консоли через командную строку тоже.

Я кстати так и автоматизирую мелкие задачи запуском его утилит через ssh.

Virtuozzo 7 это единственное решение, которое позволит управлять и контейнерами и виртуальными машинами на одном сервере с помощью libvirt

А как же virt-manager?

это все дело времени, ведь команда libvirt собственно направлена на поддержку тем нужных для всего двух вещей - oVirt и Openstack. Я прекрасно помню насколько много было воплей когда мы переводили vdsm с полного управления kvm напрямую, на работу с libvirt, и все было сделано за пару месяцев. докер сейчас в моде, и поэтому ориентируются на него, но если это будет тормозить, скорее всего просто сделают LXC.

В любом случае, будет интересно посмотреть во что выльется ваша поддержка kvm, таких платформ не очень много, и те которые появляются позже обычно избегают проблем с легаси и ошибок от которых потом не убежать (как например vmfs у vmware). Я собственно потому и писал про резюме - всегда интересно попасть в такой проект в самом начале, особенно заранее зная какие решения оказываются потом тупиковыми по опыту других проектов, а опыта этого у меня как раз хватает

API все таки намного удобнее при автоматизации. То есть вообще ни в какое сравнение это не идет

API все таки намного удобнее при автоматизации. То есть вообще ни в какое сравнение это не идет

Смотря для чего. Для конечного решения нет. Вся автоматизация там уже внутри. Собственно, проксмокс таковым и является.

А так, апи там есть - https://pve.proxmox.com/wiki/Proxmox_VE_API

Как раз вот тебе управление контейнерами из быдлопехапе https://github.com/CpuID/pve2-api-php-client

Смотря для чего. Для конечного решения нет. Вся автоматизация там уже внутри. Собственно, проксмокс таковым и является.

именно для конечного решения API идеален. вот например пишу я прогу которая цепляется к системе виртуализации и делаю бекап машин. если я это делаю через обычный cmdline я быстро упрусь в проблемы параллелизации и просто лишних телодвижений для выхода в командную строку каждый раз. А с API я просто загружаю нужную библиотеку и пишу все нативно, на том языке который мне подходит.

Что virt-manager, что oVirt работают через libvirt. Нет драйвера в libvirt - не будет поддержки ни в oVirt ни в virt-manager.

Если имеется в виду английское слово «template», то произносится оно примерно так: «тэмплэйт», «и» там нигде нету.

К слову Virtuozzo 7 это единственное решение, которое позволит управлять и контейнерами и виртуальными машинами на одном сервере с помощью libvirt.

Что, правда? Боюсь вы опять врете.
У вас там, в криокамере, слышали про Proxmox? А про virt-manager? У меня LXC и KVM-виртуалки управляются одним инструментом
Почему я уже управляю контейнерами(настоящими, а не OpenVZ) и виртуалками одним инструментом?

А это некрозоофилы просто соврали. Снова. Для команды некрозоофилов OpenVZ это нормально.

В проксмоксе уже написаны бекапы машин. По запросу, по расписанию через стоп или снепшот - все это настраивается прямо из его веб-морды или через cli.

То, что тебе нужен API какраз четко и недвусмысленно показывает, что это не конечное решение, а некий промежуточный слой.

И таки еще раз, в проксмоксе есть rest API и биндинги в десятки языков. Просто я этим не пользовался, хотя можт и зря.

Если имеется в виду английское слово «template», то произносится оно примерно так: «шаблон», «и» там нигде нету.

Исправлено во имя добра и справедливости!

Не говори ерунды. Openvz очень удобная и заслуженая система изоляции.

Не было бы никакого lxc, если бы не они.

напиши на sergeyb at openvz dot org

Давай ты не будешь мне говорить что мне писать, а я не скажу тебе куда пойти.

OpenVZ — глючное поделие которые пытается теперь выехать на чужом коде. LXC есть совершенно независимо от них и вертело их на МПХ.

Не пытайся рассказывать мне про OpenVZ, ладно? Ты еще в штаны гадил, когда я с этой кучей фекалий мучался, ибо досталось в наследство. OpenVZ нужен ровно для одного, для оверселлинга на дешевых тарифах ВПСок, потому что OpenVZ не умеет работать с памятью.

Да ты больной на всю голову. Срочно на обследование червей головного мозга!

Принято :-)

Бекaп это только пример. Открой для себя такое понятие как ISV.

Ну и насчет удобства API, самое простое - зайти в ipython и загрузить модули api. Довольно часто работа в таком шелле оказывается удобнее чем в cli