Виртуализация KVM vs XEN vs ?

в тему - кто подскажет хорошую ГУИшную панель управления виртуальными машинами для KVM ?

virt-viewer. Я ж написал выше. Я вот пытаюсь понять целесообразность применения приложений, основанных на Web-интерфейсе. Или лучше развиваться в сторону GUI по VNC?

А разве XEN не является модулем ядра? (не работал толком с данной технологией) Думаю, что просто найдёте проблем себе на глову. Грубо говоря, 2 виртуализации, а это убивание ресурсов ноды, а они не безлимитные. Будут, я в этом практически уверен, проблемы с сетью. Не знаю что использует KVM, но XEN использует dom0. Получается будет схема: eth0 -> ... (KVM сеть) -> dom0. А оптимально ли оно? Как по мне, лучше использовать использовать чистую виртуализацию и неизобреть колесо.

Хотя опять же, все написанное выше - моё ИМХО. Я в этом вопросе не силен.

я имею в виду панель для внешнего управления, а-ля VEPortal или VDSmanager

как я понимаю, virt-viewer дает управление машиной "изнутри" ?

.

Не понимаете технологии XEN. С сетью проблемы решимы. Сейчас опишу.

Для начала четко разделите типы виртуализации. XEN может работать как в режиме аппаратной виртуализации (используя аппаратную виртуализацию процессора) или в режиме паравиртуализации. Т.е. проще говоря, аппаратная виртуализация позволяет довольно быстро запускать немодифицированные операционные системы. Паравиртуализация - грубо коворя, модификация ядра виртуализируемой операционной системы. Т.е. XEN не совсем модуль, это модификация ядра ОС.

По поводу ресурсов ноды: они будут использоваться точно так же, как и при виртуализации одного типа. Здесь играет роль дополнительный софт (qemu, kvm), вохможно, придется иметь два гипервизора. Но ресурсы ноды, которые будут тратиться исходя из моих умозрительных заключений не превышают ресурсов одной небольшой виртуальной машины.

По поводу сети. Сеть XEN поднимается другим способом. Это не просто тупое навешивание доп. айпишек и перехват трафика в виртуальную машину. Поднимается бридж (xenbr0 по дефолту), на него навешиваются виртуальные адаптеры (vif), и через этот бридж все роутится. Т.е. у нас есть gateway (eth0), бридж (xenbr0) и привязанные к нему виртуальные сетевушки XEN-доменов.

Если XEN использует больше паравиртуализацию, то KVM на это вообще не рассчитан. KVM предназначен только для запуска немодифицированных ОС, а это значит, что у него более широкие возможности (теоретически) в виде виртуализации большего количества ОС, а так же более точная эмуляция архитектуры. Хотя это все уже теория. Так же, вроде как KVM местами показывает большую производительность в сравнении с XEN. Я знаю, что на этом форуме есть люди, которые могут подсказать разницу в производительности для Linux между машиной реальной и машиной под KVM. Для XEN эта разница составляет 7-12%.

Теперь немного поясню, что происходит во время попытки исполнения виртуализованной ОС под XEN опасной инструкции в режиме паравиртуализации: XEN перехватывает эту инструкцию, выполняет ее эмуляцию и возвращает нужные значения непосредственно машине. Остальные инструкции выполняются на реальном процессоре. В случае же с аппаратной виртуализацией перехватываются все инструкции и обрабатываются не программным эмулятором, а непосредственно микрокодом процессора. Т.е. в режиме аппаратной виртуализации такие инструкции выполняются быстрее.

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

Ошибаетесь. Эта штука - менеджер виртуальных машин, аналогично VDS-manager, только обладает GUI, а не WEB. Продуктов для WEB я не знаю, отсюда и задаюсь такими вопросами.

на данном этапе я пытаюсь рассмотреть целесообразность использования KVM и сравнить перспективы развития XEN и KVM технологий. Дело в том, что у обеих есть как плюсы, так и минусы. Сейчас мне приятнее XEN, но только по той причине, что про KVM я знаю слишком мало. На чтение документации и тестирование уходит слишком много времени, но рано или поздно я этот вопросы выясню. Хотелось бы пообщаться со специалистами, которые готовят KVM-виртуализацию и прояснить некоторые технические моменты, чтобы не убивать время. В свою очередь могу поделиться каким-то своим опытом.

Вообще же, за KVM говорит положительно то, что он включен в стандартное ядро Linux как модуль, начиная с ядра 2.6.26 (если мне не изменяет память).

P.S> просто пытаюсь использовать раздел форума по назначению.

10 раз ставил WinXP на KVM. Все зависали на разных этапах установки. Переключился на Xen и встало как по маслу. И ещё 10 раз после этого.

Не понимаю как RedHat переходит на такую сырую технологию.

Да, технология сырая. Но вот у меня наоборот ситуация приключилась. Я винду на ксене так и не смог завести... Точнее. она у меня сеть так и не нашла. А под КВМ коллега - запросто. Меня перспективы интересуют, так как продукты имеют, в принципе, немного разную специализацию.

Да вроде оба используют процессорные возможности по виртуализации. В чём их принципиальное отличие?

Принципиального - никакого. Родились по разному. И XEN в этом отношении пока круче и отработаннее.

Сомневаюсь, что kvm и xen получится запускать одновременно без багов.

Еще я слышал, что у openvz некоторые ядра умеют xen.

qemu - достаточно перспективно, но

1) ужасная работа с дисками.

2) ужасная работа с smp.

3) сырое и нестабильное.

Десктоп:

http://pastebin.com/yRaZT8FS

Виртуалка:

http://pastebin.com/6XUGFLXh

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

Если найдете какой-нибудь интересный тест - могу выложить результаты для qemu, так как самому интересно :)

С XEN практически не работал, да и не вижу смысла в паравиртуализации сейчас, когда процессоры мощны, память велика и узким местом все равно остается жесткий диск.