| 1.1, A.Stahl (ok), 21:05, 03/03/2016 [ответить] [﹢﹢﹢] [ · · · ] [↓] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– |
 >Исходный код Virtuozzo 7 полностью открыт и доступен
С лицензиями, правда, пока не очень понятно -- часть, видимо доставшаяся от OpenVZ, открыта и свободна, а остальной код никаких данных о лицензии не несёт.
Там же, где лицензия указана, используется GPL2 или LGPL.
| | |
| |
| 2.2, sergeyb (ok), 21:32, 03/03/2016 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +4 +/– |
 >>Исходный код Virtuozzo 7 полностью открыт и доступен
> С лицензиями, правда, пока не очень понятно -- часть, видимо доставшаяся от
> OpenVZ, открыта и свободна, а остальной код никаких данных о лицензии
> не несёт.
спасибо за замечание, мы это исправим (https://bugs.openvz.org/browse/OVZ-6701)
> Там же, где лицензия указана, используется GPL2 или LGPL. | | |
|
| |
| 2.14, Аноним (-), 10:49, 04/03/2016 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +1 +/– | |
>Once again, as Virtuozzo 7 containers and VMs are managed via the libvirt API, you can use Virtual Machine Manager (virt-manager) for the same purpose. You will need to install our customized version of virt-manager that supports any Red-Hat-based OS. We tested our version of virt-manager with CentOS 7.
Напомню, что вирт-менеджер умеет подключаться и к удалённым хостам. Как по мне, специализированное приложение лучше, чем набор перл-скриптов (не в обиду proxmox'у будь сказано).
| | |
|
| |
| |
| |
| 4.41, sergeyb (ok), 16:54, 05/03/2016 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +1 +/– | |
Когда ментейнеры Linux ядра согласятся принять все наши наработки из vzkernel, скорость можно оценить по этой картинке - http://imgur.com/WMFDib8
Какие-то части vzkernel быстрее продаются ментейнерам Linux ядра, а какие-то медленнее:
NET и PID неймспейсы приняли достаточно быстро.
Нашу реализацию C/R для живой миграции контейнеров не принимали в ядро. И у других проектов (http://criu.org/Comparison_to_other_CR_projects) не принимали. Мы решили эту проблему с помощью проекта CRIU (http://www.opennet.dev/opennews/art.shtml?num=43489) и в Virtuozzo 7 уже нет ядерного кода для C/R, его заменил инструментарий CRIU.
код для управления памятью (memcg) в ванильном ядре частично мы писали, в vz7 мы используем эти наработки и от старых UBC, vSwap, SLM (https://openvz.org/Memory_management_in_VZ7) практически ничего в vzkernel не осталось.
И это не все примеры "проталкивания" наших наработок. Со стороны мы можем выглядеть тормозами, но покажите того, у кого этот процесс проходит быстрее.
Из оставшегося:
- Ploop and related ext4 changes
- Memory management and accounting
- backport of kmemcg
** idle memory tracking (for vcmmd)
** network buffers memory accounting
** OOM killer virtualization
- /sys and /proc virtualization
- Network: venet, iptables (marks)
- FUSE upstream backports
- Printk virtualization
- /dev/console virtualization
- Time namespace (for monotonic timers wrt migration)
- Misc legacy (vziolimit, vzlist, vzredir, vznetstat, beancounters...)
- Beancounters: numiptent, numfile, numproc
| | |
|
|
|
| |
| |
| |
| 4.31, alex53 (?), 17:35, 04/03/2016 [^] [^^] [^^^] [ответить] [↓] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– |
Отвечу за автора.
Это не вопрос охвата рынка. Разработка ведется под конкретную версию ядра (которая актуальна в RH 7). На разработку под сразу несколько ядер просто нет ресурсов.
По теме.
Очень уж долго. Все новые контейнеры уже давно под lxc или docker-м. И когда выйдет production-ready релиз, ИМХО будет поздно.
| | |
| |
| 5.34, Michael Shigorin (ok), 20:12, 04/03/2016 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– |
 > По теме.
> Очень уж долго. Все новые контейнеры уже давно под lxc или docker-м.
> И когда выйдет production-ready релиз, ИМХО будет поздно.
А у меня под ovz -- потому что ovz и lxc (тем более дыркер) умеют совсем разное с весьма разным качеством.
| | |
| |
| 6.36, alex53 (?), 20:52, 04/03/2016 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– |
Понятно что изоляция lxc не фонтан, но функции свои она выполняет, и работает сейчас.
А специально переводить под ovz уже работающие контейнеры ради неких гипотетических фитч думаю мало найдется желающих.
Docker конечно редкое дерьмо, но он популярен главным образом благодаря своему api, а поскольку ovz это api не поддерживает, то и здесь мимо.
| | |
| |
| 7.42, sergeyb (ok), 17:04, 05/03/2016 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +2 +/– | |
> Понятно что изоляция lxc не фонтан, но функции свои она выполняет, и работает сейчас.
Зависит от того какие у вас функции. Все хостеры для Linux контейнеров используют OpenVZ или Virtuozzo.
Если у вас приватная сеть и нужно использовать контейнеры, то да, скорее всего свои задачи вы с помощью LXC решите.
У LXC главное преимущество, за которое его так любят это доступность в любом дистрибутиве.
Но нужно знать и о недостатках LXC. Отталкивайтесь от своих потребностей, хватает вам LXC - отлично, любите Docker - прекрасно.
Мы не пытаемся "впарить" свою Virtuozzo всем, поэтому составили таблицу сравнения (без всякого маркетингого буллшита) Virtuozzo с другими решениями - https://openvz.org/Comparison
Лично мое мнение, что существующие пользователи OpenVZ только приобрели нежели потеряли с новой версией Virtuozzo. А вы уж делайте свои выводы.
| | |
|
|
|
|
|
|
| |
| |
| 3.38, Pavel Odintsov (ok), 12:26, 05/03/2016 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– |
 Но, пожалуй, стоит уточнять, что поддержка OpenVZ в libvirt - мягко говоря хреновая и если этот веб-интерфейс будет использоваться, то он сможет рулить лишь VM, а конетйенрами - не сможет.
В этом случае решение Proxmox предпочтительнее, так как там и vm и контейнеры и все это управляется в одном интерфейсе по единому API/веб-интерфейсу.
В VZ7 я так понимаю есть лишь унифицированный API, но нет приложений (веб-морд), кто бы его реализовывал.
| | |
| |
| 4.39, sergeyb (ok), 13:38, 05/03/2016 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– |
> Но, пожалуй, стоит уточнять, что поддержка OpenVZ в libvirt - мягко
> говоря хреновая и если этот веб-интерфейс будет использоваться, то он сможет
> рулить лишь VM, а конетйенрами - не сможет.
Наверное ты имеешь ввиду тот факт, что в своем драйвере vz для LibVirt реализовали управление двумя типами инстансов: контейнерами и виртуальными машинами. Этот драйвер приняли в апстрим LibVirt, а значит и приложения должны это поддерживать. Если нормальной поддержки нет, то виноват не драйвер.
| | |
|
|
|
|
