2 root-а, несколько сетевых карт — какой виртуализатор выбрать?

Если правая рука не знает, что делает левая, тогда xen.

> Интересуют все варианты.

OpenVZ, Xen, VirtualBox, VmWare, QUEMU, KVM. Что-то забыл? :-)

IMHO есйчас лучшее соотношение затраты/фичи+результат у VB и VmWare.

Имхо это соотношение лучше всего у промышленных систем: xen, openvz, vmware esx. Ну еще про kqemu много хорошего слышал, хотя и не тестил.
А десктопные (домашние) системы типа vmware server и workstation, virtialbox, все-таки дают ощутимую потерю производительности. Например, традиционно упоминаемый бенчмарк: http://www.cl.cam.ac.uk/research/srg/netos/xen/performance.html

> Имхо это соотношение лучше всего у промышленных систем: xen, openvz, vmware esx

Ты путаешь затраты/эффективность и голимую эффективность. Xen, OpenVZ - требуют извращеннейшим образом патченные ядра. VMWare ESXi жутко коммерческий (был) и насквозь завязан на прочие коммерческие продукты VmWare, VmWare server вбестолку жрет дохрена ресурсов, и для запуска нуждается в драйверах, которые отстают от текущего ядра на полгода минимум, и блокируют возможность апгрейда. Так что я остановился на VirtualBox (в реинкарнации VBoxHeadless).

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

Если бы прирост эффективности от патчей на ядро не окупал бы трудностей - люди бы просто не стали этим заниматься.

Для десктопа (запустил машинку - пошарился - закрыл) эти затраты могут и не окупиться. Но для режима непрерывной одновременной работы нескольких машин - очень даже окупаются. Чем ставить на core duo vbox, имхо проще купить по бесценке два древних селерончика :) Такой же непроизводительный лисапед получится.

Если проц поддерживает VT-x или SVM, то KVM без вопросов.

Почему, если не секрет?

> Большинство популярных дистров поддерживают xen-версию ядра

Угу. Fedora 8, RHEL/CentOS с ядром 2.6.18, Убунту 8.04 про чей xen написано "known as buggy" и Debian 4.0 (Etch)? :-)

>RHEL/CentOS с ядром 2.6.18

На самом деле довольно хорошее ядро. Тщательно вылизанное редхатовцами. http://www.linux.org.ru/jump-message.jsp?msgid=3913568&cid=3916028 По сути, оно так и есть. Правда, функции фаервола там реализованы фиговатенько, но в dom0 это и не нужно.

>Убунту 8.04 про чей xen написано "known as buggy"

Хм. По моим наблюдениями так можно про весь этот дистрибутив написать. А что вы хотите от debian experimental?

>Debian 4.0 (Etch)?

lolwut? http://packages.debian.org/linux-image-xen

* Debian 4.0 ("etch") contains 2.6.18 Xen dom0 kernel.
* Debian 5.0 ("lenny") contains 2.6.26 Xen dom0 kernel based on early version of OpenSUSE forward-ported patches. Some users have experienced stability problems with this kernel, when used with newer Xen 3.3 and 3.4 hypervisors. Also, some users have reported live migrations being broken with this lenny's kernel.
(c) http://wiki.xensource.com/xenwiki/XenDom0Kernels

> Почему, если не секрет?

По сочетанию простоты использования и производительности. Да и вообще, KVM - это будущее аппаратной виртуализации. Относительная простота, кроссплатформенность, RedHat за спиной...

Тем не менее, it works. В сусе xen сделан на совесть, и поломать его при портировании - это нужны очень кривые руки. Они же с той же версии переносили. Разве что конфликт вендорских патчей... Маловероятно.
Знаем мы этих паникеров: "а-а-а, все сломалось и ничего не ходит, мейнтейнеры казлы!" А на самом деле у самого просто руки не из того места растут.

Хотя мы, например, используем centos в dom0 и debian в domU. Именно такой вариант для наших задач наиболее оптимален.

Вообще же, для производителя серверного дистра поддержка xen-сборки ядра - это как поддержка архитектуры amd64: если отказаться от нее, появится куча свободного времени и нервы крепче будут, но юзеры засмеют.
А от не-серверных дистров требовать наличия промышленных технологий виртуализации - зачем? Юзер Вася ворованную винду с ворованным вордом и под vbox'ом запустит.

>По сочетанию простоты использования и производительности. Да и вообще, KVM - это будущее аппаратной виртуализации. Относительная простота, кроссплатформенность, RedHat за спиной...

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

По поводу производительности - пруф?

>> По сочетанию простоты использования и производительности. Да и вообще, KVM - это будущее аппаратной виртуализации. Относительная простота, кроссплатформенность, RedHat за спиной...

> Ну-ну-ну, давай-ка без патриотических лозунгов.

Не понял. Ты считаешь, что я родился в KVM? Или в RedHat? Ты норкоман штоле сцуко?

> не рановато ли на него переползать именно сейчас?

Требованиям, которые озвучил OP, KVM удовлетворяет. А тебе что нужно?

> По поводу производительности - пруф?

Сейчас лень искать. Погугли - была совместная статья людей из Xen, KVM и вроде даже VMware о KVM времен 2.6.18.

А на простоту использования ты пруфов не потребовал, почему так?

>Не понял. Ты считаешь, что я родился в KVM? Или в RedHat?
Да нет. Просто патриотизм (как и религия) традиционно ассоциируется с фанатизмом :)

>Ты норкоман штоле сцуко?
Черт, палюсь :D

>А тебе что нужно?
В целом: хочу, чтобы все было за@бись. В частностях - долго рассказывать.

>Сейчас лень искать. Погугли
Мне тоже лень искать :) Поэтому - пруфа нет - не верю.

>А на простоту использования ты пруфов не потребовал, почему так?
Потому что чихал я на простоту использования. Апчхи!

>> Сейчас лень искать. Погугли

> Мне тоже лень искать :)

Так оно тебе нужно, значит...

> В целом: хочу, чтобы все было за@бись.

Ленивые за это платят много денег.

>Так оно тебе нужно, значит...
Прежде всего это нужно тебе. Свои утверждения неплохо аргументировать фактами.
В сухом остатке имеем ничем не подтвержденное заявление, что KVM якобы быстрее. Без ссылок на результаты бенчмарков такому заявлению грош цена.

>Ленивые за это платят много денег.
И это замечательно. Иначе бы мне и моим коллегам на икру не хватало бы :)
А техническую сторону вопроса как раз мы и обеспечиваем. Поэтому нас, в отличие от наших клиентов, вопрос "как сделать за@бись", очень интересует.

> Вообще же, для производителя серверного дистра поддержка xen-сборки ядра

С появлением QEMU и KVM можно сказать "Xen ненужен". Hurd нужен, а Xen - не нужен.

> Юзер Вася ворованную винду с ворованным вордом и под vbox'ом запустит.

У VirtualBox есть одно пока что очень серезное преимущество - для него не нужен процессор с поддержкой виртуализации. И совсем не обязательно винда будет ворованная :-)

>У VirtualBox есть одно пока что очень серезное преимущество - для него не нужен процессор с поддержкой виртуализации.

Вынужден с разочарованием констатировать - мой оппонент не разбирается в вопросе.

Аппаратная поддержка виртуализации ксену нужна только для HVM domU. HVM - не Ъ, и производительность у него существенно ниже, чем у паравиртуального режима. Для паравиртуального, правда, нужно специально модифицированное гостевое ведро, но для человека с прямыми руками это опять же не проблема.

Вопросами HVM я уже давно не занимаюсь (вырос), но насколько я помню, intel VT/pacifica поддерживаются практические всеми современными процессорами, а на рухляди любую виртуалку гонять бессмысленно - там, где ресурсов еле хватает для одной машины, пихать вторую не стоит.

>И совсем не обязательно винда будет ворованная :-)

Мужики говорят, что лицензионное соглашение на винду запрещает запуск ее в любых эмуляторах. Во всяком случае во времена XP так было (до появления hyper-v).

>С появлением QEMU и KVM можно сказать "Xen ненужен". Hurd нужен, а Xen - не нужен.

Боюсь, мнение в данном вопросе человека, который не отличает паравиртуализацию от HVM, не стоит воспринимать всерьез.
Ничего личного. Нельзя жы быть профессионалом во всех областях. Но не стоит учить рыбу плавать ;)

quemu - интересный проект, но пока, не смотря на kquemu, на промышленный уровень не вышел, так и оставшись десктопной примочкой. Видимо, прирост скорости существенен только по сравнению со своей, десктопной "весовой категорией".

Что касается KVM, то на текущий момент аксакалы сошлись во мнении, что технология перспективная, но слишком молодая. Лучше выждать пару релизов RHEL, пока ее основательно перетряхнут и разок-другой перепишут с нуля - тогда, глядишь, можно и энтерпрайз-сектору на нее переползать.
Ну а частники пусть сами решают, что им важнее - стабильность или задел на будущее.