Чем OpenVZ лучше, чем kvm ?

Меньшие накладные расходы. Но, вообще-то, эти штуки просто для разных задач.

В openvz хост можно напихать больше «виртуалок». Плотнее будет.

Сам openvz не использую, но вот пример из смежного lxc - только что стартанувшая виртуальная машина с jabber сервером занимает в оперативной памяти 45.27MB.

для разных задач

если мне нужен один Web-сервер, одна машина под СУБД, одна машина под DNS, одна под почту, то мне можно рассчитывать, что взломав Web-сервер, хакер не добрется до всего остального, в случае с OpenVZ ? а с LXC?

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

OpenVZ — контейнер, KVM — виртуализация, со всеми вытекающими плюсам и минусами. Например, в OpenVZ меньше накладных расходов, но зато ядро общее и нельзя, естественно, какую-нибудь винду или бсд в контейнер запихать.

могут (kvm, например) использовать своё ядро, общее для всех виртуалок.

Ух ты, а как? я видел, что можно ядро загружать снаружи, но в памяти-то будет много экземпляров, разви нет?

нельзя, естественно, какую-нибудь винду или бсд в контейнер запихать.

Меня другое интересует
http://ru-openvz.livejournal.com/1970.html

злонамеренный ассемблерный код сможет изнутри openvz и lxc занулит всю память компа?

Можно рассчитывать при грамотном развёртывании.

Только если уязвимость какую проэксплуатирует, в штатном режиме нет такой возможности.

что мешает злонамеренному ассемблерному коду обнулить память всего компьютера, а не только одного контейнера ?

в штатном режиме нет такой возможности.

А каким образом достигается такое разделение? Я всегда считал, что это возможно только в виртуальной машине (типа kvm или xen)

В любом коде есть дыры, и даже полная виртуализация может не спасти.

http://man7.org/linux/man-pages/man7/namespaces.7.html

namespace ...[is]... an abstraction

Абстракции никогда не защищали от оружия. Должен использоваться материальный механизм. Какой?

«управляет видимостью» - а что если стирать будет вслепую?

дыры дырам рознь. Я подозреваю глобальную дыру, которая заключается в том, что «security through obscurity» - это плохая практика

Плюсы очевидны, выше уже неоднократно сказали. Из минусов, ядро старое, но в этом году уже должно ядро 3.X выйти и вот тогда заживем.

Раз уж я в этом треде, то спрошу. Docker это обертка над LXC, со всеми вытекающими минусами? Чем он лучше OpenVZ на данный момент кроме того, что присутствует в апстримном ядре?

cast dvrts что ли.

Плюсы очевидны, выше уже неоднократно сказали.

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

Я не вижу каким образом OpenVZ эффективнее, чем KVM (тем более, тут говорили, что kvm может тоже ядро разделять, хотя мне не ясно - как)

а что в kvm такого тяжелого по сравнению с ней?

Тем что нужно емулировать железо и запускать отдельное ядро?

Плюс в том что оверхед меньше (к сожалению на графике нет KVM, но даже Xen, который по идее быстрее KVM, намного отстает от OpenVZ). http://openvz.org/images/5/56/Response_time_v2.png

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

Насчет разделения, в OpenVZ равно как и в LXC используются namespaces, для контроля ресурсов — cgroups.

По KVM сказать ничего не могу, ибо сам не знаком.

Что ты имеешь ввиду, говоря про «стирание вслепую»?

Должен использоваться материальный механизм. Какой?

CONFIG_NAMESPACES в ядре, толстячок

я уже осознал, они действительно защищены (при помощи модели защиты процессоров Intel, кольза там всякие, разделение адресных пространств - вот это всё).

У меня теперь другой вопрос - а как отрабатывает initramfs и процесс init в случае контейнера?

кольза там всякие

кольза рулят.

опечатался. Но заявлю, что это новое модное сокращение от "кольца защиты"

под твои задачи esxi без гуя.

OpenVZ на десктопе по феншую?

можно рассчитывать, что взломав Web-сервер, хакер не добрется до всего остального, в случае с OpenVZ ? а с LXC?

В общем случае для контейнеров сбежать из контейнера можно используя уязвимость в ядре. Если уязвимостей нет (читай «нет уязвимостей известных злоумышленнику») то контейнеры не должны позволять сбежать из себя.
В частности конечно-же есть масса способов выстрелить себе в ногу (:

Мне кажется кто-то из нас двоих не очень хорошо представляет как работает управление памятью в современных ОС.
На сколько я понимаю процесс не может получить доступ к памяти другого процесса, а прямой доступ к памяти (как /dev/mem) работает через отдельные ручки, доступ к которым можно перекрыть со стороны ядра.

Что-то ESXI и Hyper-V уж больно плохо выглядят по сравнению с Xen. Даже подозрительно.

я видел, что можно ядро загружать снаружи, но в памяти-то будет много экземпляров, разви нет?

Нет. google://Kernel samepage merging

1. Низкие наладные расходы. 2. Возможность выделения ресурсов на лету без останова или перезапуска: количество процессоров, максимальная их загрузка, озу и своп, размер фс и тд. 3. Прямой доступ к ФС контейнеров с хоста без всяких там losetup, kpartx, etc. 4. Возможность «входа» в shell конернера с хоста и возможность выполнения программ в контейнере которые так же запускаются с хоста. 5. При использовании ploop - снапшоты ФС контейнера на лету. 6. Быстрое выключение севера при необходимости, в отличие от виртуалок в KVM, контейнерам не свойственно «залипание» при выключении сервера без предварительного выключения ВМ. Очень полезно в частности если сервер исчерпал ресурс батареи ИБП и гасится каким-нибуть NUT. 7. Единое время для хоста и контейнеров, (понятно что часовые пояся внутри контейнеров могут быть разными) - можно настроить на хосте NTP и правильное время будет сразу везде.

Дёшево.

как отрабатывает initramfs

никак

процесс init

как обычно

процесс init

как обычно

Обычно говорят, что процесс init без initaramfs не работает, что initramfs нужна для того, чтобы подготовить среду

загрузись с init=/bin/sh и офигей

OpenVZ лучше, чем kvm

нельзя сравнивать столь разные инструменты, это все равно, что сравнивать киянку и кайло или ext4 c zfs.

а что в kvm такого тяжелого по сравнению с ней?

Наверное то, что kvm полностью эмулирует виртуализирует целевую систему, в то время как OpenVZ реализует «chroot» контейнеры на подобии BSD'шных jail'ов. А вообще OpenVZ больше не нужен, потому что есть LXC с cgroups.