Проект OpenVZ начал выкладывать тестовые сборки Virtuozzo 7

Я уж взглянув на заголовок подумал что OpenVZ портировали Windows 7.

Что с Virtuozzo Parallels слышно? Когда ждать стабильной версии? Как-то мало инфы по ссылке.

Кстати, мне без холивара кто-нибудь объяснит, почему пацанов в ядро не пускают?

Как дела обстоят с утилитами?

А чем оно лучше xen/kvm ?

Вот тут чуть побольше инфы http://www.montanalinux.org/virtuozzo-7-openvz-pre-release.html

о, спасибо вам

Сейчас не пускают потому-что есть LXC.
Раньше не пускали то-ли потому-что считали это ненужным, то-ли потому-что код не соответствовал высоким стандартом разрабов ядра (ведь этот патчсэт кажется никогда не шёл в ногу с апстримом), то-ли потому-что разработчики ядра такие злые дядьки и русских людей обижают. Не помню.
Но кое-что они в апстрим всё-равно проталкивали.

Разрабы из parallels регулярно рассказывают эту историю на всяких там конференциях (а так-же в статьях, текстах и постах).

Сейчас не пускают потому-что есть LXC.

Вообще значительная часть lxc вроде как и произошла от openvz, а то, что до апстрима не дошло, то ли слишком привязано к ядру от rhel, то ли действительно не дотягивает по качеству до «высоких стандартов разрабов ядра». Но понемногу таки проталкивают, и уже дотолкали до того состояния что vzctl может работать на ванильном ядре, хотя и не с полной функциональностью.

Вообще значительная часть lxc вроде как и произошла от openvz

Там ведь конструктор на самом деле (что в ovz, что в lxc). Куча более-мернее самостоятельных компонентов. Так-что происхождения там могли быть одновременно самые разные.
В целом ядерные части LXC и OVZ усредняются, но поцы из паралелс говорят что окончательно их патчсэт скорее всего не исчезнет никогда.

меньше оверхед. общая память, диск, кеш.

оно не лучше, а вообще по другому принципу работает

Тем, что позволяет запрещать клиенту строить тоннели.

Где официальная документация на всё это дело?

И пользуясь случаем, пара вопросов:

1. Если контейнеры будут на одном и том же дистрибутиве, что и хост система - можно уменьшить место занимаемое каждым контейнером? Т.е. есть механизмы выноса одинаковых файлов «за скобки»? Какой будет выигрыш/проигрыш?

2. Каждый контейнер запускает копию ядра и тем самым кушает дополнительную память, помимо пользовательских процессов? Или оверхеда по памяти нет и все пробрасывается на хост-ядро?

0. Официальная информация http://openvz.org/ 1. От выноса одинаковых файлов выигрыш не на столько велик, чтобы его можно было ощутить на современных серверах (по RAM/HDD). 2. Нет, всё также как в LXC: нет расхода дополнительной памяти и лишних прослоек существенно влияющих на работу с дисками. Отсюда востребованность контейнеров как таковых.

выигрыш не на столько велик, чтобы его можно было ощутить

Предоположим, мне нужно 200 контейнеров запустить на одном сервере, будет какой-то выигрыш? Или в лучшем случае 10-20% места освободится и не более?

всё также как в LXC: нет расхода дополнительной памяти и лишних прослоек

Тем не менее, будут запущены копии системных служб, всякие syslog, cron и прочее, прочее на каждый контейнер? Для 200 контейнеров на одном сервере, думаю это будет значительным оверхедом.

Может проще заюзать cgroups без контейнеров? Группировать процессы по пользователям выставлять им лимиты на cpu, ram, net и в путь? Или какой-нибудь умник повысит привелегии до рут?

то-ли потому-что разработчики ядра такие злые дядьки и русских людей обижают.

лютое 4.2

Мой любимый вопрос.

Нас пускают в ядро, но процесс этот не такой быстрый как хотелось бы. Отвечу цитатой Кира Колышкина: «У нас есть OpenVZ — большой набор патчей, реализующих разную функциональность для контейнеров. Эта функциональность делится на некие „кирпичики“, составляющие. Ну, например, network namespaces — возможность иметь в ядре Линукса не одну сущность под названием „сетевая подсистема“, а много. Эта сущность включает в себя экземпляр TCP/IP стека, таблицы маршрутизации, таблицы фаерволлинга, всякие разные кеши и хеши, ну и собственно сами сетевые устройства. Возможность создавать свои отдельные экземпляры сетевой подсистемы, отдавать его контейнеру, прокидывать туда устройства и т.п. — это и есть один из „кирпичиков“, из которых построена OpenVZ.

Так вот, время от времени мы берём такой кирпичик и пытаемся воссоздать его в мейнстрим-ядре. Не просто послать на linux-kernel@ часть наших патчей, а именно воссоздать, то есть по сути с нуля, заново реализовать, представить на суд общественности, получить комментарии, поправить, представить на суд общественности — и так далее, пока или оно не будет принято, или кончится терпение и мы плюнем на это неподъёмное дело. Вот таким примерно образом мы „засовываем“ OpenVZ в мейнстрим ядро. После того, как „кирпичик“ появляется в мейнстриме, мы выкидываем аналогичную часть из нашего патча и адаптируемся к мейнстримному (иногда написанному нами же, иногда нет).»

И тут он описал процесс появления наших патчей в основной ветке ядра:

«Отчего же тогда мы не отдаём весь ядерный код OpenVZ в ваниллу? Мы отдаём! Уже несколько лет как этим занимаемся, с переменным успехом (сейчас, я посмотрел, в ядре примерно 1700 патчей от нас, что не так уж и хреново, хотя, конечно, хочется много больше).

Как это примерно происходит, описано выше на примере PID namespace. Бывает, что сложнее, бывает, что проще, бывает, что вообще не удаётся сделать то, что примут. Не потому, что криво, глючно и никому не надо, как думают аналитики на ЛОРе, а потому, что процесс принятия патчей — сложный, по ряду причин. Например, мало кто понимает, что такое контейнеры и нафига они вообще нужны. Или понимают, но имеют своё, отличающееся от нашего видение, как решать ту или иную проблему. Поэтому тут больше надо разговаривать, убеждать, отстаивать свои подходы, чем просто писать и засылать хороший код. Для тех, кто думает, что на самом деле всё просто, а просто наши инженеры тупые — покажите мне, сколько ваших нетривиальных патчей приняли, и мы поговорим.

Что насчёт светлого будущего? Какое оно? Когда оно наступит? В нашем понимании, идеальное светлое будущее — это когда OpenVZ патч к ядру будет нулевого размера, то есть мы хотим, чтобы вся функциональность, которая есть в OpenVZ, появилась в ванильном ядре. Когда это наступит? Я боюсь, что никогда, ибо мир неидеален. Но если, скажем, в ванилле будет 60 или 80% нашей функциональности — я буду счастлив (сейчас там примерно 20-30%, точнее сложно сказать).»

Мы сделали в общей сложности 2000 патчей для Linux ядра. На вики проекта есть график, который показывает сколько патчей мы отдали в основную ветку. С новой функциональностью мы поступаем по-другому - сразу делаем патчи для ванильного ядра и добиваемся их добавления. Так мы поступили с новой версией memory management для контейнеров (кстати эта фича уже готова и её можно попробовать в тестовых сборках): сделали патчи для ванильного ядра и когда патчи приняли, то спортировали эти патчи в свое ядро. На данный момент наше ядро отличается от ванильного как минимум такими вещами: ploop, патчи для veth, io лимиты, iops лимиты, /dev/console, виртуализация tmpfs, различные фиксы для багов.

Дела такие:

Остаётся vzctl, но в следующей версии планируем его убрать в пользу prlctl. С vzctl в Virtuozzo 7 есть одна беда: развитие коммерческого продукта (Parallels Cloud Server) и OpenVZ шло паралллельно, поэтому vzctl в OpenVZ содержит часть патчей, которые отсутствуют в версии для коммерческого продукта. А в Virtuozzo 7 вошла именно эта версия. Возможно со временем важные патчи приедут из OpenVZ версии в версию vzctl, которая вошла в VZ7.

Появляется утилита prlctl, с помощью которой можно управлять и виртуальными машинами и контейнерами:

[root@gw ~]# prlctl list -a
UUID                                    STATUS       IP_ADDR         T  NAME
{8df603f0-bf06-4b8f-98cd-ab3f26dcde41}  running      10.34.2.178     CT 118
{85763823-3e06-4615-af44-1d170599888e}  running      10.34.2.184     CT 119
{0095b0dc-8b28-40f4-872e-f0ffeee47560}  running      10.34.2.183     CT 120
{7feec2aa-e540-4a57-aea4-c24cf17aca23}  stopped      -               VM OpenBSD 5.6 x86_64
{06be566c-c947-4148-9d2f-df3485176269}  running      -               CT pvcwin

Появляется утилита для управления EZ темплитами - vztt. Если раньше надо было выкачивать закэшированные темплиты, то в Virtuozzo 7 схема такая: темплиты распространяются в виде RPM пакетов и содержат только метаинформацию. Вы устанавливаете этот пакет, создаёте кэш темплита и потом на базе этого кэша можно создать контейнер. По мере необходимости можно обновлять кэш, чтобы версии пакетов не протухали.

Появляется утилита vcmmd для управления памятью контейнеров.

Появляется утилита prlsrvctl для управления общими настройками сервера Virtuozzo. Вот список опций утилиты для общего представления её возможностей:

root@gw ~]# prlsrvctl 
prlsrvctl version 7.0

Usage: prlsrvctl ACTION [OPTIONS] [-l user[[:passwd]@server[:port]]
Supported actions are:
  info [-j, --json] [--license] [-f, --full]
  install-license -k,--key <key> [-n,--name <name>] [-c,--company <name>]
  update-license
  set [--mem-limit <auto|size>] [-s,--min-security-level <low|normal|high>]
        [--mng-settings <allow|deny>] [{--device <device> --assignment <host|vm>}]
        [-c,--cep <on|off>] [--backup-path <path>] [--backup-timeout <timeout>]
        [--backup-tmpdir <tmpdir>] [--backup-storage <user[[:passwd]@server[:port]]>]
        [--verbose-log <on|off>]
        [--cpu-features-mask <mask|off>]
  shutdown [-f,--force] [--suspend-vm-to-pram]
  user list [-o,--output name[,name...]] [-j, --json]
  user set --def-vm-home <path>
  problem-report <-d,--dump|-s,--send [--proxy [user[:password]@proxyhost[:port]]] [--no-proxy]> [--stand-alon
e] [--name <your name>] [--email <your E-mail>] [--description <problem description>]
  net add <vnetwork_id> [-i,--ifname <if>] [-m,--mac <mac_address>]
                   [-t,--type <bridged|host-only>]
                   [-d,--description <description>]
                   [--ip <addr[/mask]>] [--dhcp-server <on|off>] [--dhcp-ip <ip>]
                   [--ip-scope-start <ip>] [--ip-scope-end <ip>}]
                   [--ip6 <addr[/mask]>] [--dhcp6-server <on|off>] [--dhcp-ip6 <ip>]
                   [--ip6-scope-start <ip>] [--ip6-scope-end <ip>}]
  net set <vnetwork_id> [-i,--ifname <if>] [-m,--mac <mac_address>]
                   [-t,--type <bridged|host-only>]
                   [-d,--description <description>] [-n,--name <new_name>]
                   [--ip <addr[/mask]>] [--dhcp-server <on|off>] [--dhcp-ip <ip>]
                   [--ip-scope-start <ip>] [--ip-scope-end <ip>]
                   [--ip6 <addr[/mask]>] [--dhcp6-server <on|off>] [--dhcp-ip6 <ip>]
                   [--ip6-scope-start <ip>] [--ip6-scope-end <ip>}]
  net del <vnetwork_id>
  net info <vnetwork_id>
  net list [-j, --json]
  privnet add <private_network_id> [-a,--ipadd <addr[/mask]>] [--global <yes|no>]
  privnet set <private_network_id> [-a,--ipadd <addr[/mask]>] [-d,--ipdel <addr[/mask]>]
                                   [--global <yes|no>]
  privnet del <private_network_id>
  privnet list [-j, --json]
  usb list [-j, --json]
  usb del <usb-device-id>
  usb set <usb-device-id> <vm-uuid | vm-name>
  cttemplate list [-j, --json]
  cttemplate remove <name> [<os_template_name>]
  cttemplate copy <dst_node> <name> [<os_template_name>] [-f,--force]
  plugin list [-j, --json]
  plugin refresh

Может проще заюзать cgroups без контейнеров? Группировать процессы по пользователям выставлять им лимиты на cpu, ram, net и в путь? Или какой-нибудь умник повысит привелегии до рут?

Коммент про docker.

Как минимум плотностью контейнеров на одном физическом сервере, скоростью разворачивания окружений, производительностью. Вот например графики измерений для vConsolidate UP, vConsolidate SMP, DVD store.

Все не совсем так. Вернее совсем не так.

Буду опять цитировать ранние записи Кира:

«Что такое 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 — это то, что в мейнстримном ядре, плюс наши патчи, плюс наши утилиты. Что из этого всего следует — решать вам.»

Где официальная документация на всё это дело?

как водится у большинства открытых проектов у OpenVZ не было актуальной и полной документации. Было руководство пользователя OpenVZ (может быть немного устаревшим), набор man страниц, ну и вики с её статьями. Для Virtuozzo 7 мы готовим нормальную документацию с детальным описанием функциональности VZ7. Документация будет сильно похожа на документацию от коммерческой версии, но будет описана новая функциональность.

1. Если контейнеры будут на одном и том же дистрибутиве, что и хост > система - можно уменьшить место занимаемое каждым контейнером?
Т.е. есть механизмы выноса одинаковых файлов «за скобки»?
Какой будет выигрыш/проигрыш?

Место на диске и так экономится - контейнеры используют общий темплит, если это контейнеры одного дистрибутива. Память тоже может экономится, если вы используете большое количество контейнеров с одинаковым темплитом. Технология называется pfcache, почитать можно например тут.

2. Каждый контейнер запускает копию ядра и тем самым
кушает дополнительную память, помимо пользовательских процессов?
Или оверхеда по памяти нет и все пробрасывается на хост-ядро?

Ядро для всех контейнеров общее, это же виртуализация на уровне ОС.

Да, так гораздо лучше.

Место на диске и так экономится - контейнеры используют общий темплит

Правильно я понимаю что экономия эта до первого apt-get update? Последующая дедупликация не производится, экономится только место занимаемое неизменяемыми файлами? Ведь это скорее всего какие-то копейки.

А что тебе мешает обновить темплейт вместо контейнера?

Например то что контейнер управляется не тобой, а клиентом, и клиент может не обрадоваться тому что у него внезапно обновился похапэ например.
Как мне кажется такие вещи вообще имеют какой-то смысл только если тэмплэйты действительно тяжёлые, но обычно они довольно компактны (это либо базовая система, либо она-же плюс что-то вроде LAMP).

имеют какой-то смысл только если тэмплэйты действительно тяжёлые

Это имеет смысл на SSD, когда у тебя 100 контейнеров на одном сервере. То каждый из них кушает по гигу. И вот 100 гигов, как корова языком слизнула.

Гиговый темплэйт — многовато будет. У меня тестовая система (в которую понаставлена куча всякой ереси, чуть-ли не иксы) весит гиг (без /var, в котором уже мой личный тестовый хлам в основном). По моему мнению это уже близко к нижней границе «действительно тяжёлых».

Жаль. Оч-чень жаль, что вся «сопроводиловка» исключительно на английском языке.
Неужели все разработчики OpenVZ общаются исключительно на английском языке?

Жаль. Оч-чень жаль, что вся «сопроводиловка» исключительно на английском языке.

Документация на англ. языке позволяет достичь бОльшей аудитории нежели только на русском. Но мы не против если кто-то возьмется за переводы. Возьметесь?

Неужели все разработчики OpenVZ общаются исключительно на английском языке?

английский и русский

А у вас есть разработчики в Германии? Посмотрел по сайтам, понял так, что вроде бы только продажники в Мюнхене. Спасибо.

Вы имеете ввиду Parallels/Odin? Да, есть офис в Мюнхене, но насколько я знаю там нет разработчиков.

Да, я имею в виду работодателей разработчиков, которые работают над OpenVZ :-) Жалко что нет, но что же поделаешь...

Блин, вы в ИТ, знание английского здесь базовая вещь, хотя бы на чтение. Это как в медицине латынь, так у нас английский.

Неосилятор английского detected.

«Опубликованные сборки компонентов Virtuozzo являются тестовыми и не готовы для серьёзного применения»

ReactOS мира линупс?

Как я понимаю - у вас сопроводиловку пишут на русском, сразу переводя её на английский, а потом тщательно уничтожают исходные тексты?
Или все гораздо свободнее владеют английским, чем русским?
Или просто все являются членами секты, правила которой запрещают пользоваться русским языком? Тогда почему вы мне ответили на русском?.
Не понятно.

By the way, reading texts in English is not difficult, but surprises such persistence in ignoring Russian texts.

Троллинг хороший. Но нет, это не про нас.

Каждый продукт перед финальным публичным релизом имеет промежуточные релизы: Technical Preview, Alpha, Beta, Release Candidate, GA (General Avaiability), RTM (Ready To Market). Каждый из этих промежуточных релизов не годится для серьёзного применения (хотя бывают и исключения). В соответствии со своими планами разработки мы последовательно добавляем функциональность и улучшаем качество:

• 27 июля - Выпуск Virtuozzo 7 Technical Preview - Containers
• 1 июля - Публикация тестовых регулярных сборок Virtuozzo

Дальше будут другие Technical Preview, а там уже и финальный релиз будет не за горами. Вот увидите сами.