LINUX.ORG.RU

Партнёрская поддержка OpenVZ

 , , ,


2

1

Компания Parallels, стоящая за проектом OpenVZ, на прошлой неделе предложила программу партнёрской поддержки (OpenVZ Maintenance Partnership).

Суть программы в том, что всем вступившим предлагается (за небольшую годовую плату) два преимущества:

1. Возможность создавать до 10 запросов с самым высоким приоритетом. Это могут быть как баги, так и обычные запросы в саппорт. Запросы попадают непосредственно разработчикам.

2. Возможность отправлять запросы по новой функциональности. В ответ инженеры оценят, насколько это сложно, долго и дорого (или просто, быстро и легко).

Почему это событие важно? Раньше было только два варианта — либо свободную OpenVZ, без денег и без поддержки, либо коммерческую Parallels Virtuozzo Containers, за деньги и с поддержкой. Теперь же можно использовать open source продукт с коммерческой поддержкой.

>>> Подробности



Проверено: tazhate ()

Ответ на: комментарий от Ttt

OpenVZ не особо лучше shared-хостинга.

И все таки лучше. С учетом его тонкости, это еще и недорого, сравнимо с shared.

AVL2 ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

А KVM тоже позволяет память

KSM

и общие системные файлы расшаривать между машинами?

Ненужно. Гигабайты нынче по 5 рублей за штуку.

no-dashi ★★★★★
()
Ответ на: комментарий от anonymous

я просто везде пытаюсь юзать одну систему, и 2.6.32 не оч на моём ноуте, так что debian wheezy, lxc, kvm

Khades ★★
()

У opnenvz есть свои плюсы, но после релиза Debian 7, мне придётся от неё потихоньку отказаться. LXC тоже пока не вариант.

suicider
()
Ответ на: комментарий от carasin

В разделе Правила говорится что когда кто-то становится модератором, его Score автоматически поднимается до 4 звёзд, если ранее не был таким же или выше.

ZenitharChampion ★★★★★
()

openvz не умеет selinuux и живет только на rhel 2.6,* ядрах, что не очень приятно

anonymous
()

за небольшую годовую плату
Теперь же можно использовать open source продукт с коммерческой поддержкой.

Совсем не покупают? :)

gh0stwizard ★★★★★
()

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

GreenTea ★★
()
Ответ на: комментарий от Umberto

Потому что это закат перед лицом kvm и lxc.

а чегой это на сайте lxc новости апрелем 2011 заканчиваются? хотя в загрузках есть и 13 год. с чего бы это так?

gray ★★★★★
()
Ответ на: комментарий от no-dashi

и общие системные файлы расшаривать между машинами?

Ненужно. Гигабайты нынче по 5 рублей за штуку.

Не так уж и по 5 - диски сейчас самая дорогая часть системы. Если будет дедупликация, SSD будет рентабельно использовать со всеми вытекающими. Даже SAS lbcrb будут дешевле, у меня, к примеру, памяти на серверах с KVM завались, а дисков не хватает.

kt
()
Ответ на: комментарий от tazhate

lxc, openvz, zones, jail это не паравиртуализация, это контейнеры. Это ещё дальше от обычной виртуализации (qemu) чем паравиртуализация.

MrClon ★★★★★
()
Ответ на: комментарий от gray

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

MrClon ★★★★★
()
Ответ на: комментарий от gray

Это сайт набора юзерспейсовых утилит для управления ядерными фичами совокупность которых и называют обычно lxc. Как вы понимаете не в утилитах соль.

MrClon ★★★★★
()
Ответ на: комментарий от zloelamo

Openvz постепенно вытесняется lxс
ибо lxc в ядре и активно пилится

LXC появилась в ядре благодаря Parallels/OpenVZ и активно пилится именно этими людьми. Чуть более чем наполовину.

Интересно, почему это никто не видит. Вот вы — почему об этом не знали?

ovzkir
() автор топика
Ответ на: комментарий от Umberto

Потому что это закат перед лицом kvm и lxc.

KVM — ортогональная к контейнерам технология, давайте не будем мешать котлеты и апельсины.

LXC появилась в ядре и развивается во многом благодаря Parallels/OpenVZ. Во многом — это чуть более чем наполовину.

Интересно, почему это никто не знает. Вот вы — почему об этом не знаете?

ovzkir
() автор топика
Ответ на: комментарий от shahid

есть управлением распределением i/o для гостей. Но не в ovz

В OpenVZ есть ioprio — это приоритет CFQ i/o шедалера, только не per process, a per container. Но этого недостаточно.

Вторая проблема — это journal contention, когда у всех контейнеров общая fs и общий журнал. Мы её решаем с помощью ploop, хотя, конечно, никто не мешает, если хочется, нарезать lvm разделы или что там ещё.

В коммерческой версии есть ещё iolimit (в мегабайтах в секунду) и iopslimit (в операциях в секунду). К сожалению, в OpenVZ пока нет.

ovzkir
() автор топика
Ответ на: комментарий от Khades

Но всётаки киллерфичей openvz является live migration

А мы (OpenVZ/Parallels), кстати, его тоже довольно успешно запиливаем в апстрим в рамках проекта CRIU (http://criu.org). Даже итеративную миграцию памяти приделали недавно, правда, в ванильное ядро она пока не попала.

Правда, почитав тут комменты, создаётся впечатление, что люди потом напишут «openvz умирает и никому не нужен, вот и живая миграция уже есть в ванилле», не сознавая почему-то, что та самая живая миграция именно силами OpenVZ дивелоперов туда и пришла.

PS пора написать про CRIU на LOR :)

ovzkir
() автор топика
Ответ на: комментарий от AVL2

ведь lxc или openvz в принципе не дают возможности
запустить свое ядро, загрузить свои модули и т.д.

Конечно, ведь каждый, кому нужна база данных, веб-сервер или там MTA, или компилятор, или браузер — он в первую очередь думает, как бы туда поставить своё ядро и загрузить свои модули.

Это был сарказм, извините. Если не сарказм, то я знаю одно приложение, которому как правило нужны свои ядерные модули. Это Asterisk, телефония. Спросите любого астерисковода (или гугл) — ни под каким VM он нормально не работает, потому что latency слишком большая, а в OpenVZ контейнере — запросто.

Ну а писать, что OpenVZ плох, потому что не даёт возможности запустить своё ядро — это то же самое, что утверждать, что легковой автомобиль плох, потому что он не оборудован кузовом для сыпучих грузов с гидравлическим подъёмником. «Именно поэтому самосвалов всё больше, а легковых машин — всё меньше.»

ovzkir
() автор топика
Ответ на: комментарий от gh0stwizard

Совсем не покупают? :)

Покупают. Реально миллионы долларов платят, вы не поверите.

А у вашего бизнеса как дела?

ovzkir
() автор топика
Ответ на: комментарий от GreenTea

В газенваген этих разработчиков.

Спасибо, мы тоже вас очень любим! :-*

ovzkir
() автор топика
Ответ на: комментарий от ovzkir

ненадо тут, openvz - готовое решение, а lxc - конструктор, с которым надо учиться пользоваться cgroups, lvm, apparmor и т д. Хотя лично я считаю это не самым плохим, особенно в связи с тем что всё это работает и с kvm. Честно, не другие виртуалки только изза того, что они пишут свои реализации планировщиков и т д.

Кстати, а криу можно будет в kvm?

Khades ★★
()
Последнее исправление: Khades (всего исправлений: 1)
Ответ на: комментарий от insider

KVM еще и хостовый LVM умеет

KVM'у пофиг на LVM. Ему просто можно подсунуть в качестве стораджа всё что угодно. А «хостовый LVM» умеет скорей libvirt или другой менеджер VM.

no-dashi ★★★★★
()
Ответ на: комментарий от carasin

почему у модератора всего четыре звезды? 0_o

Модераторам поднимают скор до 4 звезд(а не до 5). У меня УЖЕ было 4 звезды, когда я стал модератором, так что... :-)

Pinkbyte ★★★★★
()
Ответ на: комментарий от ovzkir

пора написать про CRIU на LOR

В порядке оффтопика - как оно вообще? Я сам его не пробовал, только писал на него ебилд для Gentoo, тестили и success story рассказывали мне другие люди(в тот момент нужно было патчить ядро, а мне было откровенно влом). Как с этим обстоят дела сейчас? На 3.9 взлетит без патчей?

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от no-dashi

На хост машине имеется LVM, для виртуалки просто создаем том и он подключается к ней, как виртуальный диск, например virtio /dev/vd* Я это имел ввиду.

Возможно, что KVM как-то ограничивает io на этот том, но на массиве это незаметно.

insider ★★★
()
Ответ на: комментарий от ovzkir

KVM — ортогональная к контейнерам технология

а тут дело не в технологическом принципе, а в сфере применения.
за себя могу сказать, что всё перевёл в уютный kvm.
смею предположить, что многие, кому нет нужды в специфике openvz так же рассосутся по kvm/xen/lxc.

LXC появилась в ядре и развивается во многом благодаря Parallels/OpenVZ

молодцы. спасибо. но при этом надо понимать, что мир - динамическая среда, что-то умирает, что-то рождается.

Интересно, почему это никто не знает. Вот вы — почему об этом не знаете?

если вы о lxc, то я им не пользуюсь.

Umberto ★☆
()

а када vzprocps сделают не только для рыдхата?

Jetty ★★★★★
()
Ответ на: комментарий от ovzkir

Интересно, почему это никто не видит. Вот вы — почему об этом не знали?

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

Реальность такова: lxc вы не продаете, вы продаете openvz (точнее свой сервер на openvz). Lxc в ядре, openvz в патчах. Openvz я клиентам рекомендовать не буду, как и ваш ентерпрайз, пока он на openvz. Более того, буду отговаривать, поскольку местечковая реализация, требующая специфических патчей на ядро сильно сужает возможности, и ставит в зависимость от компании параллелс.

zloelamo ★★★★
()
Ответ на: комментарий от Khades

lxc - конструктор, с которым надо учиться пользоваться cgroups, lvm, apparmor и т д.

Последние версии libvirt поддерживают lxc. Не знаю на сколько хорошо - не видел. И судя по презентации, RHEL7 тоже будет поддерживать инструментарий создания lxc контейнеров (наверное, через тот же libvirt)

Можно скастовать Макскома и узнать использует ли он lxc для лора, ибо последний на альфа версии RHEL крутится, вроде.

zloelamo ★★★★
()
Последнее исправление: zloelamo (всего исправлений: 2)
Ответ на: комментарий от shahid

Вообщето «The I/O priorities feature is implemented in OpenVZ since kernel 2.6.18-028stable021»

anonymous
()
Ответ на: комментарий от ovzkir

Только LXC развивается и уже в ядре, а OpenVZ готов, но в ядре его почему-то нет.

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

PS не ваша статья, кстати?

oxumorron
()
Ответ на: комментарий от insider

На хост машине имеется LVM, для виртуалки просто создаем том и он подключается к ней, как виртуальный диск, например virtio /dev/vd* Я это имел ввиду.

Точно также можно подключить и раздел, и физический девайс, и обычный файл. В _любую_ VM. Это не заслуга KVM.

no-dashi ★★★★★
()
Ответ на: комментарий от shahid

Именно поэтому во многих системах виртуализации есть управлением распределением i/o для гостей. Но не в ovz. Короче, читать учись.

грубиян, да еще и неуч... держи!

https://openvz.org/I/O_priorities_for_containers

crypt ★★★★★
()
Ответ на: комментарий от ovzkir

Это был сарказм, извините. Если не сарказм, то я знаю одно приложение, которому как правило нужны свои ядерные модули. Это Asterisk, телефония. Спросите любого астерисковода (или гугл) — ни под каким VM он нормально не работает, потому что latency слишком большая, а в OpenVZ контейнере — запросто.

у меня freeswitch хорошо работает в openvz. Но пришла пора подключить Е1. Начался гемор с водружением dahdi в проксмокс, а libpri в контейнер.

Ну а писать, что OpenVZ плох, потому что не даёт возможности запустить своё ядро — это то же самое, что утверждать, что легковой автомобиль плох,

Не совсем так. OpenVZ не плох, а опасен тем, что его возможностей виртуализации в любой момент может не хватить. Еслипо условиям задачи его возможностей гарантированно хватает, то и проблем в общем нет.

AVL2 ★★★★★
()
Ответ на: комментарий от Pinkbyte

CRIU ... На 3.9 взлетит без патчей?

В принципе в 3.9 почти всё уже есть. Чем дальше, тем больше взлетает, там просто в каждой версии ядра появляется какая-то новая функциональность. Процесс «вливания» можно посмотреть на http://criu.org/Commits

В 3.11 мы надеемся впихнуть http://criu.org/Memory_changes_tracking, который нужен для http://criu.org/Iterative_migration

ovzkir
() автор топика
Ответ на: комментарий от zloelamo

Видать маркетинг у вас не очень

Маркетинг?? :-0

Раз вы рассуждаете о ядрах, патчах, местечковых реализациях, то я предполагаю, что вы хоть раз смотрели в исходники ядра, ну или хотя бы заглядывали в git log.

вы продаете openvz (точнее свой сервер на openvz)

OpenVZ вообще ничего не продаёт — мы всё больше ядра и утилиты пилим, релизы делаем, баги фиксим, на вопросы в мейлинг листах и форумах отвечаем. Обычный опенсорс проект.

Продаёт — Parallels.

Lxc в ядре, openvz в патчах.

Это, мягко говоря, не верно. Хотя бы потому, что LXC (как и OpenVZ) состоит из ядерной и юзерспейсной части. Ядерная часть LXC состоит из того, что мы и другие ребята влили в апстримное ядро, и в перспективе она будет одинаковая (но пока до этого далеко). Ядерная часть OpenVZ включает в себя также и то, что в апстрим ещё не попало.

Юзерспейс разный — у них утилита lxc, у нас утилита vzctl. Насчёт последней могу заметить, что её можно использовать с более-менее свежим (скажем, 3.5 и больше) ядром, то есть это будет такая слегка обрубленная OpenVZ без ядра от OpenVZ.

Более того, буду отговаривать, поскольку местечковая
реализация, требующая специфических патчей на ядро сильно
сужает возможности, и ставит в зависимость от компании
параллелс.

Следуя вашей логике, вы также будете отговаривать от дистрибутивов RHEL, CentOS, Fedora, SUSE, SLES, Ubuntu, Debian, Gentoo и какие там ещё есть. Все вышеперечисленные дистрибутивы имеют модифицированное ядро со специфическими местечковыми патчами. У RHEL6, например, таких патчей примерно в 25 (по буквам — в двадцать пять) раз больше по объёму, чем весь патч OpenVZ для этого ядра. Только у Gentoo и Fedora, насколько я помню, опционально есть ванильное ядро.

Какие же вы дистрибутивы используете. LFS?

ovzkir
() автор топика
Ответ на: комментарий от oxumorron

Только LXC развивается и уже в ядре, а OpenVZ готов,
но в ядре его почему-то нет.

Вы так говорите, как будто OpenVZ — это такая фича, типа файловой системы. А это не так, это набор из десятков фич, совершенно разных, в разных подсистемах и так далее. Некоторые есть в ядре, некоторые прямо сейчас туда попадают, некоторых пока нет. Процесс идёт, и идёт на мой взгляд неплохо.

Вот если я вам покажу vzctl из OpenVZ, который честно работает с ванильным ядром 3.6 — создаёт контейнеры, выставляет лимиты и так далее — это будет считаться, что OpenVZ «уже в ядре»? Если да, то спешу вас обрадовать — OpenVZ таки уже в ядре, с сентября прошлого года, если считать этим моментом выпуск vzctl с поддержкой ванильного ядра. Подробности тут http://openvz.org/Vzctl_for_upstream_kernel

не ваша статья, кстати?

моя

ovzkir
() автор топика
Ответ на: комментарий от ovzkir

Ядерная часть LXC состоит из того, что мы и другие ребята влили в апстримное ядро, и в перспективе она будет одинаковая (но пока до этого далеко).

А почему далеко? Как сейчас обстоят дела с вливанием в апстрим?

Новость отличная! Как-то 3 месяца хоть какого-то ответа ждал в багзилле...

Aman
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.