KVM vs Xen

раньше склонялся в сторону Xen, но сейчас побольше почитал про KVM и озадачился

KVM умеет паравиртуализацию? в разных источниках - разные сведения, если умеет, зачем ему проц непременно с аппаратной поддержкой виртуализации? Xen вон, даже без этих всяких VT прекрасно работает

KVM может дать 3D-ускорение гостевому Линуксу?

На серверах однозначно XEN!

На серверах однозначно XEN! KVM использую на буке, и то, только по тому что под ядром с XEN не работают закрытые дрова ATI. Одно успокаивает, теперь они хотя бы собираются, надеюсь что в скором будущем допилят до рабочего состояния.

Сколько ни бился, но KVM в режиме паравиртуализации заюзать так и не удалось. Согласен - в XEN с этим дела обстоят куда как лучше.

Не могли бы объяснить почему

Не могли бы объяснить почему именно xen на серверах? Вроде как на xen все забили? Или я не прав. А то как раз делаю сервер, нужна будет виртуалка, там будет домен с иксами крутится для терминалов.

Никто на него не забивал, его

Никто на него не забивал, его даже в генте до ума довели, и базовую поддержку в ядро 2.6.37 включили.

Что же касается моего мнения что xen серверная виртуализация. XEN имеет отличную поддержку паравиртуальных доменов, на данный момент можно исполнять любой дистрибутив linux в этом режиме. Так же имеется возможность исполнять NetBSD и уже на подходе FreeBSD, с ветки 8.Х фрю начали активно пилить в этом направлении. Паравиртуальным доменам можно выделять монопольный доступ к устройствам ввода-вывода, гости с такими устройствами будут работать используя стандартные драйвера без эмуляции ввода/вывода и прочих паравиртуальных дров. Для выделения монопольного доступа гостям с аппаратной виртуализацией требуется аппаратная поддержка виртуализации ввода вывода, которую Intel и AMD только начали пилить. В противном случае дикие тормоза и нагрузка на CPU. Так же хен на самом деле изолирует операционные системы друг от друга, в kvm каждая гостевая система это пользовательский процесс, который крутится внутри ядра с kvm, на мой взгляд это выглядит весьма позорно. В хен хостовая ось ничего не знает о гостях, она лишь предоставляет интерфейсы ввода-вывода, которые реализованы в виде потоков ядра, а не пользовательских процессов. Другими словами выглядит это как гипервизор, а не как эмулятор машины с нашлёпкой в виде модуля ядра.

Что касается преимуществ KVM над XEN, то я их вижу немного:
1) наличие халявных паравиртуальных дров для винды
2) можно юзать на десктопах, т.к. не возникает проблем с закрытыми офицальными дровами. Собственно для тех, кого устраивают открытые дрова, примуществом это не является.

Ну и чего не умеет XEN, так это эмулировать машины, в этой ипостаси целиком и полностью царит qemu. И да, кстати qemu именно для этого и разрабатывался, это потом уже к нему пришлёпали KVM. XEN изначально разрабатывался для серверной виртуализации.

KVM умеет паравиртуализацию?

KVM умеет паравиртуализацию? 
KVM может дать 3D-ускорение гостевому Линуксу?

пока не до конца ( равно как и Хен), но гораздо сильнее, чем XEN: QXL <-> VDI дрова и в путь ( aqemu это уже умеет)

На серверах однозначно XEN!

Ты наверно ничего кроме линукса для лампа там не гонял ?

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

KVM предпочтительней. Xen это

KVM предпочтительней. Xen это имхо очень очень сильно перепиленный линь, потому на персоналке Xen вообще не вариант. Проц с аппаратной поддержкой виртуализации делает эту самую виртуализацию именно аппаратной, то бишь шустрой настолько, насколько это позволяет данная железяка. В то что ксен работает быстрее железяки -верится с трудом.

>>KVM может дать 3D-ускорение гостевому Линуксу?

Интересно, зачем гостевому линю могло бы понадобиться 3D ускорение

оне ше в игрухи играть

оне ше в игрухи играть

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

Паравиртуальные домены

Паравиртуальные домены работают не быстрее железки, но быстрее доменов использующих аппаратную виртуализацию. Для аппаратной виртуализации гостю требуется загрузить ядро, а с ним и драйвера устройств. Паравиртуальный домен грузит лишь бекэнды к интерфесам ввода-вывода, сеть, дисковая подсистема и консоль, все остальное можно просто выбросить из ядра. Такой домен на базе генты загружается за 5-6 секунд, и это без OpenRC и прочих твиков ускоряющих загрузку. В аппаратной виртуализации есть смысл, когда необходимо исполнять разные немодифицированные оси на одном и том же железе.

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

ты это не нам про

ты это не нам про консолидацию расскажи, а мужукам из РХЕЛа - они то не знают и все пилят и пилят. Причем что необычно - они обычно допиливают.

Такой домен на базе генты загружается за 5-6 секунд,

Сколько можно - скорость работы не определяется временем загрузки

Xen это не перепеленный линь, собственно это вовсе не линь.

теоретически - верно. А практически - ну ка выкинь линь из хена - что получил ? :)

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

slepnoga написал(а): ты это

slepnoga написал(а):
ты это не нам про консолидацию расскажи, а мужукам из РХЕЛа - они то не знают и все пилят и пилят. Причем что необычно - они обычно допиливают.

Citrix и Oracle тоже допиливают.

Такой домен на базе генты загружается за 5-6 секунд,

Сколько можно - скорость работы не определяется временем загрузки

Не вопрос, у меня в распоряжении HP Proliant DL160 c 2-мя Xeon Quad Core и десктоп AMD Phenom II 925 X4, устроим баттл паравиртуальный XEN vs. аппаратно виртуализированный KVM? :)

Xen это не перепеленный линь, собственно это вовсе не линь.

теоретически - верно. А практически - ну ка выкинь линь из хена - что получил ? :)

получу голый XEN, но никак не линь. По сути не станет дров для хостовой оси, эту же самую функцию выполняет и ядро NetBSD.

Ежели учесть, что линь - это

Ежели учесть, что линь - это ядро, то ксен - это именно перепиленный линь. Причем в некоторых не особо важных для ксена местах достаточно криво. По этой причине ставить хенсурс на десктоп я бы не стал.

Паравиртуальные домены ксена, насколько помню, не годятся для виртуализации винды. Для ксена под венду делаются паравиртуальные драйвера сетевух и дисковых контроллеров. Тот же подход используется в квм/qemu. Тоесть ввод-вывод приблизительно одинаков по скорости. За счет чего в этом случае можно ожидать ускорения от ксена?

PS
Поскольку я не хост провайдер, виртуализация никсов меня волнует мало. Линь программно устойчив, и проблему высокой доступности и производительности можно порешать кластером. Плюс к тому линевые сервисы достаточно хорошо разделяются меж пользователями. Скажем я бы не стал делать виртуальный линь под апач, когда очередному нашему программисту понадобится собственный вебсервер. Виртуализация серверов под винду, с моей точки зрения, более интересна, потому как имею некоторое подозрение, что 32 битные системы в эмуляторе будут работать не хуже чем на реальном железе ( за счет 64 битных операций IO хозяина), да и устойчивость при кластеризации хозяина будет несколько повыше. Кстати на моем десктопе винда в виртуалке стартует куда быстрее нежели у одинЭссника на реальном железе, при том что компы абсолютно одинаковые.

Цитата: Ежели учесть, что

Цитата:
Ежели учесть, что линь - это ядро, то ксен - это именно перепиленный линь

бредишь
xen - кроссплатформенный гипервизор

xen - кроссплатформенный

xen - кроссплатформенный гипервизор

и его теоретическая кроссплатформенность заканчивается на 2-х с половиной платформах. Его же практическая кроссплатформенность заканачивается там, где заканчивается линукс.

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

не суть важно зачем, но под Xen-ом вполне возможно..

по воспоминаниям двухгодичной давности, ещё тогда Хен позволял, исключать из виртуализации их гипервизором, отдельные pci-устройства и блоки IO адресов, поэтому жил тестовый стенд, с поддерживаемой для этого дела материнской платой, имеющей встроенные vga и lan контроллеры + доп. pci nvidia svga и lan, которые и использовала гостевая ось для запуска 3д и сетевых приложений! =)
лень гуглить, но в те времена - подобный функционал держала всего пара чипсетов и пяток мат.плат, сейчас наверное получше?)

PLUR, WBR RunAGate
---
Еще Прутков говорил: бойтесь объяснений, объясняющих объясненные вещи. ;))

> сейчас наверное

> сейчас наверное получше?

намного, даже на десктопе есть в 90% интелов

2Nu_NRG
> Паравиртуальные домены работают не быстрее железки, но быстрее доменов использующих аппаратную виртуализацию.

а вот это уже давно фантастика)) вот тут я спорил (да ответа так и не дождался) - http://www.linux.org.ru/news/opensource/5814268/page1?lastmod=1295993604795#comment-5817865 (и там по треду). и хоть разговор там совершенно о другом (хотя есть и о xen там по ссылке), но из моих тестов видно, что оверхед на проц менее 1%, на i/o тоже.. куда уж тут быстрей я честно говоря не знаю. правда с xen я работал сравнительно давно, но тогда оверхед был ну точно под 10% в паравиртуальном госте чисто на процессор особенно при многопоточности (множество тестов в интернете подтверждают)...

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

компиляция sqlite на

компиляция sqlite на паравиртуальном госте:

real 0m45.141s
user 0m43.960s
sys 0m0.620s
token sqlite-autoconf-3070500 #

real 0m45.000s
user 0m44.090s
sys 0m0.470s
token sqlite-autoconf-3070500 #

real 0m45.040s
user 0m43.960s
sys 0m0.630s
token sqlite-autoconf-3070500 #

компиляция sqlite на хостовой системе:

real 0m44.632s
user 0m42.760s
sys 0m1.000s
SouthPark-slave sqlite-autoconf-3070500 #

real 0m45.553s
user 0m43.880s
sys 0m1.190s
SouthPark-slave sqlite-autoconf-3070500 #

real 0m44.084s
user 0m42.450s
sys 0m1.120s
SouthPark-slave sqlite-autoconf-3070500 #

итого в среднем по паравиртуальному гостю 45,060 сек
по хосту 44,756 сек

44,756 / 45,060 * 100 = 99,325% - полезный выхлоп.

итого потерь по времени 0,675%

ничего точнее пока предложить не могу ну и по поводу HVM гостя тоже сказать нечего, поскольку таких не имею.

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".