LINUX.ORG.RU

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

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

trofk ★★★
()
Ответ на: комментарий от post-factum

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

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

Indaril_Shpritz
() автор топика

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

menangen ★★★★★
()

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

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

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

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

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

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

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

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

Indaril_Shpritz
() автор топика
Ответ на: комментарий от post-factum

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

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

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

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

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

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

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

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

Indaril_Shpritz
() автор топика
Ответ на: комментарий от post-factum

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

Indaril_Shpritz
() автор топика

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

Amet13 ★★★★★
()

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

cast dvrts что ли.

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

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

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

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

Indaril_Shpritz
() автор топика

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нет. google://Kernel samepage merging

Pinkbyte ★★★★★
()

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

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

процесс init

как обычно

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

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

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

anonymous
()

OpenVZ лучше, чем kvm

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

axelroot
()

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

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

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