Чем отличается XEN от OpenVZ?

Question

[blueboar2]

Я знаю только две разницы — возможность ставить разные операционки в контейнеры и возможность отдавать устройства конкретному контейнеру. Ну и «более честное распределение процессорного времени» — в чем «более честное» непонятно, но пусть будет более.

А есть какие-то более «очевидные» плюсы?

Answer 1

[rPman]

Вот популярные системы в порядке понижения функционала:

Xen — на порядок сложнее и функциональнее, имеет помимо режима паравиртуализации (как openvz) режим полной виртуализации (в т.ч. поддержка соответствующих фич процессоров), есть механизмы переброса железа внутрь виртуалки (например, поддержка не самых слабых intel видеокарт), снапшоты, миграция,… много много вкусных фич.

VMWare — как и xen, сложен, наворочен, приправлен соответствующей инфраструктурой и хорошими забористыми ценами :) режима полноценной паравиртуализации не имеет

kvm/qemu — полная эмуляция процессора (а так же виртуализация через поддержку процессорами), есть вкусности от 'старших братьев' вида миграция запущенной виртуалки по сети, переброса железа (сильно хуже поддержка чем xen/vmware) и т.п. можно считать бакэндом, так как GUI в идеалогии не имеет, оно пилится желающим

VirtualBox — эмуляция процессора, в т.ч. использование поддержки виртуализации процессоров, идеален как отдельное десктопное приложение, миграции по сети нет, есть снапшоты, некоторые вкусности скрыты от GUI в коммандной строке

OpenVZ — это работа всех машин на одном ядре (патчи к нему так и зовутся openvz), нет виртуализации, максимальная скорость (так как фактически это расширенный chroot с изоляцией). Для запуска модуля ядра на поклон нужно идти к хост системе и ее администратору (например tun/tap адаптер у firstvds дают по запросу)
Снапшотов нет (но их реализуют через lvm), миграция есть, есть сброс состояния контейнера на диск и возобновление работы…

Lxc — еще проще чем openVZ, нет даже грамотной изоляции (если подсуетиться, можно, имея рут в контейнере, выйти в хост систему с рутовым доступом), прямой аналог jail во freebsd, имеет смысл для хитрых сетевых конфигураций, тестов и т.п.

Chroot — это даже не виртуалка, это просто простейшая изоляция в пределах файловой системы, подмена путей в вызовах функций работы с файлами.
p.s. lxc называют еще 'chroot на стероидах'

OpenVZ/lxc/chroot поддерживают почти полноценное каскадирование виртуалок (т.е. к примеру можно внутри контейнера openvz запустить kvm/virtualbox при наличии модулей, даже с поддержкой аппаратного ускорения)

Comments

[Андрей Нехайчик]

Зачем нужно каскадирование виртуальных машин?

[rPman]

Красивый пример привел ниже, обеспечение безопасности (усложнение) доступа к данным.

Как вариант, я запускал в qemu (без виртуализации) windows xp на почти самой дешевой firstvds, вполне работоспособно (к сожалению было слишком медленно, нужно было запускать очень сложный документ excell, openofice не справлялся никак, и прикручивать к нему автоматизацию через внешнее приложение).

Например виртуалка user mode linux (это ядро linux, позволяющее запускать почти с нативной скоростью виртуалки, даже без наличия root доступа), очень неплохая альтернатива, особенно если нужен расширенный функционал снапшотов, который просто недоступен ни в одной инфраструктуре виртуальных машин, кроме только что amazon, но там дорого)

[Everything_is_not_so_bad]

Интересно, откуда взята цитата.

[rPman]

Иерокопус Таманский, полностью моя

[Everything_is_not_so_bad]

rPman,
хорошо, а если цитата, то с другого ресурса?

[rPman]

Иерокопус Таманский, уже не помню, но скорее всего я собирал эту цитату из моих ответов человеку в чате, или просто собирал ответ, а квотировал его для красоты

Answer 2

[mastini]

да, это две совершенные разные системы.
Одна openz — псевдо

Comments

[blueboar2]

Ну да. Псевдо. А что это дает-то? Или наоборот что это «не дает»?

[avagin]

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

XEN виртуализцая ну уровне устройств, а OpenVZ виртуализация на уровне подсистем ядра.

Answer 3

[rPman]

Кстати еще очень немаловажное замечание:

* xen/vmware/virtualbox/kvm — умеют работать только с контейнерами, т.е. хост система не монтирует диски гостевых контейнеров (но может это делать через снапшоты, например) — значит хостер имеет ограниченный доступ к данным своих клиентов. Так как для этих технологий вполне возможно создать свою виртуальную машину, со своим ядром и загрузчиком initramfs, тру параноики создают шифрованный контейнер, а пароль вводят через ssh в initramfs. Для получения доступа к данным такой машины потребуется чуть больше чем просто права администратора (в простом случае необходимо будет изучать дампы памяти, а в сложном — потребуется специализированное железо и много много денег)

* openvz/lxc/chroot — файловая система виртуальной машины должна быть примонтирована в хост системе, шифрование файлов и т.п. фактически недоступно (защитить данные от хостера нереально сложно, но можно поиграться с каскадированием виртуальных машин)

Доступ хостера к данным — очень важный момент для некоторых проектов (здравствуй провайдер linode и украденные много много bitcoin, послужившие теоретически основной причиной смерти сервиса bitcoinica).

Answer 4

[pentarh]

в openvz нет свопа
openvz «нечестно» считает потребление памяти (по VSZ а не по RSS)
в openvz нет ppp, шифрования блочных устройств
в openvz контейнер админ может зайти «просто так», без пароля и процедуры сброса пароля с перезагрузкой сервера
в openvz куча других ограничений помимо памяти, которые зачастую косо настроены и мешают нормальной работе

Comments

[ValdikSS]

На самом деле, для OpenVZ есть vswap, и если он активирован, то память считается правильно.

Answer 5

[Андрей Буров]

Сравнение виртуальных машин
Нельзя так просто сравнить Xen и OpenVZ и выбрать что-то одно. Все зависит от конкретной задачи.
PS: есть еще KVM