В openvz хост можно напихать больше «виртуалок».
Плотнее будет.
Сам openvz не использую, но вот пример из смежного lxc - только что стартанувшая виртуальная машина с jabber сервером занимает в оперативной памяти 45.27MB.
если мне нужен один Web-сервер, одна машина под СУБД, одна машина под DNS, одна под почту, то мне можно рассчитывать, что взломав Web-сервер, хакер не добрется до всего остального, в случае с OpenVZ ? а с LXC?
OpenVZ уже отстой, теперь его прекрасно заменяет Docker. KVM и XEN круты тем, что полностью эмулируют железо, а могут (kvm, например) использовать своё ядро, общее для всех виртуалок. Короче, гибкость на уровне, но и плата - пара процентов накладных расходов.
OpenVZ — контейнер, KVM — виртуализация, со всеми вытекающими плюсам и минусами. Например, в OpenVZ меньше накладных расходов, но зато ядро общее и нельзя, естественно, какую-нибудь винду или бсд в контейнер запихать.
Раз уж я в этом треде, то спрошу. Docker это обертка над LXC, со всеми вытекающими минусами? Чем он лучше OpenVZ на данный момент кроме того, что присутствует в апстримном ядре?
я плюсов не вижу вообще. Если используется одно ядро, то в памяти будет его один экземпляр, только физические страницы будут по-разному замэпплены в виртуальные адресные пространства процессов. Механизм защиты используется один и тот же - разделение виртуальных адресных пространств процессов.
Я не вижу каким образом OpenVZ эффективнее, чем KVM (тем более, тут говорили, что kvm может тоже ядро разделять, хотя мне не ясно - как)
Нет дополнительных затрат на гипервизор, поэтому можно на сервер по тысячам этих контейнеров пихать. Скорость в некоторых случая выше, опять же из-за отсутствия прослойки в виде гипервизора.
Насчет разделения, в OpenVZ равно как и в LXC используются namespaces, для контроля ресурсов — cgroups.
я уже осознал, они действительно защищены (при помощи модели защиты процессоров Intel, кольза там всякие, разделение адресных пространств - вот это всё).
У меня теперь другой вопрос - а как отрабатывает initramfs и процесс init в случае контейнера?
можно рассчитывать, что взломав Web-сервер, хакер не добрется до всего остального, в случае с OpenVZ ? а с LXC?
В общем случае для контейнеров сбежать из контейнера можно используя уязвимость в ядре. Если уязвимостей нет (читай «нет уязвимостей известных злоумышленнику») то контейнеры не должны позволять сбежать из себя. В частности конечно-же есть масса способов выстрелить себе в ногу (:
Мне кажется кто-то из нас двоих не очень хорошо представляет как работает управление памятью в современных ОС. На сколько я понимаю процесс не может получить доступ к памяти другого процесса, а прямой доступ к памяти (как /dev/mem) работает через отдельные ручки, доступ к которым можно перекрыть со стороны ядра.
1. Низкие наладные расходы.
2. Возможность выделения ресурсов на лету без останова или перезапуска: количество процессоров, максимальная их загрузка, озу и своп, размер фс и тд.
3. Прямой доступ к ФС контейнеров с хоста без всяких там losetup, kpartx, etc.
4. Возможность «входа» в shell конернера с хоста и возможность выполнения программ в контейнере которые так же запускаются с хоста.
5. При использовании ploop - снапшоты ФС контейнера на лету.
6. Быстрое выключение севера при необходимости, в отличие от виртуалок в KVM, контейнерам не свойственно «залипание» при выключении сервера без предварительного выключения ВМ. Очень полезно в частности если сервер исчерпал ресурс батареи ИБП и гасится каким-нибуть NUT.
7. Единое время для хоста и контейнеров, (понятно что часовые пояся внутри контейнеров могут быть разными) - можно настроить на хосте NTP и правильное время будет сразу везде.
Наверное то, что kvm полностью эмулирует виртуализирует целевую систему, в то время как OpenVZ реализует «chroot» контейнеры на подобии BSD'шных jail'ов. А вообще OpenVZ больше не нужен, потому что есть LXC с cgroups.