Как стать автором
Обновить

Комментарии 33

Для полноты картины еще бы Virtuozzo сюда :)
Это пока на VDS вы одни. Именно на это жалуются, подразумевая «тормоза» — что соседи тоже хотят iops, и побольше, побольше :)
Всегда, когда есть соседи, они хотят iops — при любой виртуализации;)
Это не измерение а сферический конь в вакууме. В каком виде хранятся данные DomU в Dom0 и не указали какой драйвер используется в DomU для доступа к диску, работает ли DomU в HVM или нет. Я замечал проблемы с вводом-выводом при малом выделении памяти Dom0.
> Xen PV — замер на виртуальной машине Xen в режиме паравиртуализации: 1 CPU, 256 Mb RAM. Kernel: 2.6.18-164.el5xen

Какой такой HVM?
Xen PV — замер на виртуальной машине Xen в режиме паравиртуализации

И? Какая версия ядра была использована внутри DomU? Какая версия ядра на Dom0? В каком виде предоставлялось блочное устройство DomU?

Какой такой HVM?

Аппаратная виртуализация. Была она использована или нет не указано. Не указано какая версия Xen используется. Не проведено тестирование с двумя виртуальными машинами.
Вы слово «паравиртуализация» видите? Это исключает HVM. Это не аппаратная виртуализация, это модификация ядра гостевой ОС, так, что оно работает не в ring 0, а в ring 1. (userspace не меняется — как работало в ring 3, так и работает). Этот процесс модификации — портирование в Xen; именно поэтому портированы только открытые системы (напр. Linux).

Кстати говоря, это основной режим работы Xen, который там был с самого начала, а вот HVM — это костыль.
Вы слово «паравиртуализация» видите? Это исключает HVM.

С какого перепуга? К примеру существуют паравиртуализационные драйвера для Windows и он работает именно в HVM.

Это не аппаратная виртуализация, это модификация ядра гостевой ОС, так, что оно работает не в ring 0, а в ring 1. (userspace не меняется — как работало в ring 3, так и работает). Этот процесс модификации — портирование в Xen; именно поэтому портированы только открытые системы (напр. Linux).

Извините меня, но кто вам сказал, что программная реализация будет работать быстрее и надежнее аппаратной? Термин «паравиртуализация» подразумевает знание виртуализируемой системы о том что она работает в виртуальной среде. Это может выражаться или в модификации ядра, чтобы система использовала API гипервизора или в использовании специальных драйверов ввода-вывода, так-как использование в виртуальной машине драйвера для реальных устройств добавляет «overhead».

Кстати говоря, это основной режим работы Xen, который там был с самого начала, а вот HVM — это костыль.

Кстати говоря он таким является потому что раньше поддержки виртуализации небыло. К примеру KVM работает только при наличии аппаратной виртуализации.
Вы в теме? Вы вообще понимаете, как Xen устроен и работает?

А то создаётся впечатление, что знаете только понаслышке.

> Кстати говоря он таким является потому что раньше поддержки виртуализации небыло. К примеру KVM работает только при наличии аппаратной виртуализации.

Мы про KVM говорим или про Xen? Да, KVM не умеет работать в режиме паравируализации, и ему это и не нужно — он как раз задумывался для того, чтобы использовать именно аппаратные возможности, которые к этому времени уже существовали.

Xen же задумывался как раз именно для паравиртуализации. Тогда не было никакой виртуализации, для запуска виртуальной машины нужно было имитировать CPU, что и является самой дорогостоящей операцией (представляете, весь абсолютно код сканировать и подменять некоторые инструкции?). В Xen виртуальные машины выполняются на реальных CPU, и заранее модифицированы так, чтобы вообще не было лишних инструкций, а все их функции заменены обращениями к гипервизору. Вот отсюда и его знаменитый малый overhead (по сравнению с полной виртуализацией).

> Извините меня, но кто вам сказал, что программная реализация будет работать быстрее и надежнее аппаратной? Термин «паравиртуализация» подразумевает знание виртуализируемой системы о том что она работает в виртуальной среде. Это может выражаться или в модификации ядра, чтобы система использовала API гипервизора или в использовании специальных драйверов ввода-вывода, так-как использование в виртуальной машине драйвера для реальных устройств добавляет «overhead».

Боже, как наивно. Конечно, паравиртуализация означает знание системы, что она не там есть что-то ещё. В HVM-режиме domU-система видит «как бы настоящие» CPU (именно этим занимается аппаратура), виртуальную эмулируемую шину PCI (какие бы драйверы не стояли!), и либо использует эмулируемые диски, сети и пр., либо через специальное эмулированное PCI-устройство «xenbus» (pci-id не помню наизусть) общается с гипервизором на предмет сетей, дисков и прочего. В Xen HVM гостевая система вообще всегда способна определить, что работает в Xen HVM, а не на bare metal, просто проверив наличие этого устройства.

В случае «полной паравиртуализации» с модифицированной гостевой ОС никакое специальное PCI-устройство xenbus не эмулируется. В этом режиме гостевая система видит сами настоящие CPU, вообще нет никакой шины PCI (если специально не сделать), а устройство xenbus — это прямое обращение к PV, просто вызов syscall (впрочем, как и для всех остальных устройств).

В общем, вы для начала просто сделайте и поиграйтесь с паравиртуальным линуксом, взгляните, что там, а потом и спорьте.
Кстати и с аппаратной виртуализацией почти все устройства можно паравертуализовать, у kvm уже есть диск и сеть. Но по моим субъективным тестам, xen пока рвёт kvm.
А там собственно по сути и надо только диск и сеть. Как правило, если требуется работа с особо странным оборудованием, то это мультимедиа-оборудование. (1С не в счёт: HASP USB-ключики пробрасываются в Xen, на xgu.ru писали)
НЛО прилетело и опубликовало эту надпись здесь
Он явно не в теме :)
Вы в теме? Вы вообще понимаете, как Xen устроен и работает?

Конечно. я знаю как он работает.

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

Извините меня, но overhead в KVM еще меньше так как нет переключения между гипервизором и dom0.

Боже, как наивно.

Да вы что?

Конечно, паравиртуализация означает знание системы, что она не там есть что-то ещё. В HVM-режиме domU-система видит «как бы настоящие» CPU (именно этим занимается аппаратура), виртуальную эмулируемую шину PCI (какие бы драйверы не стояли!), и либо использует эмулируемые диски, сети и пр., либо через специальное эмулированное PCI-устройство «xenbus» (pci-id не помню наизусть) общается с гипервизором на предмет сетей, дисков и прочего.

А в случае паравиртуализации у вас ВНЕЗАПНО нет CPU и устройств? Они никуда не деваются, просто путь попрямее.

В случае «полной паравиртуализации» с модифицированной гостевой ОС никакое специальное PCI-устройство xenbus не эмулируется. В этом режиме гостевая система видит сами настоящие CPU, вообще нет никакой шины PCI (если специально не сделать), а устройство xenbus — это прямое обращение к PV, просто вызов syscall (впрочем, как и для всех остальных устройств).

Вообще вызов syscall происходти следующим образом:
DomU syscall -> hypervisor -> Dom0 и только потом уже идет обращение к устройству. Причем виртуальное устройство в DomU ядре есть. В случае HVM и отсутствия паравиртуализационного драйвера путь длиннее
DomU -> hypervisor -> Dom0 (эмуляция устройства ) -> Dom0 (доступ)
В случае если у нас есть паравиртуализационный драйвер то путь выглядит так:
DomU -> hypervisor -> Dom0
т.е. приходим к тому что имеем выше.

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

Извините, но я использовал и Xen и с HVM и без HVM, и KVM, а так же OpenVZ и lxc. Так что давайте вы четко распишите что и как было сделано, а потом будете возмущаться. Опять же вы тут мифические тормоза диска в Xen не развеяли. Если вы сходите и почитаете когда они возникают, то увидите что большинство этих жалоб касаются HVM. И я считаю использование HVM и паравиртуализированных драйверов более перспективно нежели использование модифицированных ядер. Этому есть причины:
Переключение контекста происходит в любом случае.
Аппаратная виртуализированая среда обеспечивает лучшую изоляцию и быстродействие.
Не требуется модифицировать ядро, что позволяет запускать те операционные системы, что не могут быть подвергнуты модификации.
Добрый день, у меня есть вопрос к специалисту, у меня возник вопрос виртуализации серверов телефонии, телефония плого работает в виртуальном пронстранстве из за отсутствия точного источника часов «Timer source» оно служит для синхронизации голоса от разный источников, например при конференции, если таймер прохой голоса выходят из «фазы» и получается дисторсия, у меня есть такие ключики Usb которые можно воткнуть в систему дла точного тайминга, а можно ли один ключик распределить на все виртуальные машины?
Тест без графиков — негодный тест. Нужны графики замеров на ovz и xen, чтоб визуально сравнить.
Ну, поясните, какие графики — зависимость чего от чего имеется ввиду?
Например, от количества соседних виртуальных машин, постоянно выполняющих дисковые бенчмарки.
Вы же запускали тесты «в одно лицо»?
Запустите 10 гостевых систем и одновременно запустите в них тесты.
Зачем? И так понятно, что 10 гостей замедлят друг друга. Если запустить в native OS десять dd, читающих диск, или запустить в 10 гостях по одному такому dd, они будут тормозить друг друга в обоих случаях, вне зависимости от наличия Xen.

Тест проверял только то, сколько теряется именно на самом Xen, как прослойке между виртуальной машиной и физическим диском.
Часто при обсуждении различных способов виртуализации, сторонники Virtuozzo (обычно, хостеры на OpenVZ) вспоминают про услышенное когда-то и где-то утверждение типа «Xen тормозит при работе с диском»

Может быть, стоило тестировать по 10 гостей в XEN и OpenVZ?
Может быть и стоило бы. Этот тест проверяет оверхед по сравнению с нативной ОС, показывает 7% и мне этого достаточно. Не думаю, что OpenVZ покажет лучший результат, чем нативная ОС и из-за этого оторвется от 7%. Поэтому сравнение с OpenVZ мне не настолько интересно, чтобы тратить время еще и не тестирование его. Но если это сделаете вы, я с удовольствием посмотрю результаты.
Попробуйте с PV ядром гостя, производительность относительно HVM либо не изменится, либо увеличится. Разница там около пары процентов, но, думаю, поймать на кучке тестов можно.
Оу, не заметил, что было изначально PV.
Нормальный тест должен выполняться так: ставим XEN, запускаем одну машину, две машины, и 10 машин и меряем в трёх вариантах. Потом на ту же машину ставим OpenVZ, и повторяем тест. Это даст результат. А измерение в идеальных несуществующих в природе условиях даст непонятно кому полезные данные.
Для фулл- в этом случае должен быть подобран оптимальный шедулер в хосте, а для пара- просто одинаковые ведра у гостей.
А чтобы провести тест что надо сделать? Ответ прост — надо провести тест.
в Ксене видел проблемы с дисками не на линейном чтении блоками, а на конкурентности.
попробуйте читать в 5 потоков в ядре ксена и без него. в ксене iowait будет 100% и ввод/вывод и вообще система у меня тормозится. без ксена все ок
Здесь ксен и опенвз ставят на одну ступеньку, меж тем это цели у них немного различны. OpenVZ замечательно подходит для массового хостинга, не забирая лишних ресурсов, правда, там есть ограничения, упомянутые по ссылкам — нет полноценного управления машиной в смысле классического ребута или шатдауна, минимальный уровень абстракции — фс, а не голый диск, такая модель очень хороша, когда вы хотите воткнуть впс и запустить на нем кучу обычных сервисов. Xen применим в тех случаях, когда а) нужно использовать свое ядро или полную виртуализацию б) для более гибкого управления, когда всему domU выделяется один lv в виде физ. диска и он делает с ним что хочет + возможность ребутов. Ксен обеспечивает такую штуку, как живая миграция, благодаря которой его можно использовать в отказоустойчивых системах. Я применяю следующую схему: common xen pv -> common xen vg > много uniquie xen domain lv -> pv -> uniquie xen domain vg -> lv (разделы)
Не совсем понял про схему. vg и lv это про lvm-разделы и pv-в смысле домен в паравиртулизации?
Отвечу сразу по двум вопросам: lv, vg, pv в строчке выше — logical volume, volume group и physical volume группы LVM. Двухслойный пирог необходим для следующего: я подключаю iscsi диск к машине, с которой производится миграция, делаю vgextend vg второго уровня на этот диск, затем pvmove physical vol. второго уровня туда (без разницы, на какой уровень, это временное хранилище, по-хорошему, опять же на второй), переносятся все разделы в онлайне, потом vgreduce локального pv, далее на целевой машине подключаю тот же iscsi и запускаю горячую миграцию — поскольку пути к блочным устройствам не менялись, использую тот же конфиг. Далее создаю такой же уникальный lv, как был на первом, завожу в нем pv, расширяю vg на iscsi на него, делаю pvmove && vgreduce как в первой части, только уже на локальный диск. Плюс такой схемы, в отличие от валяющихся в сети, в том, что она может использовать конечной точкой не iscsi target, а физ. диск той машины, на которой будет исполняться виртуалка.

Про вланы и мосты — я после довольно большого опыта работы с ксеном считаю, что всю настройку сети, отличную от создания одиночного бриджа, следует производить в оси, а гости подключать к уже существующим бриджам, то есть, следует создать нужный набор вланов и лепить их в бриджи самописным скриптом и уже в конце цеплять к ним гостей.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий