Комментарии 33
Для полноты картины еще бы Virtuozzo сюда :)
0
Это пока на VDS вы одни. Именно на это жалуются, подразумевая «тормоза» — что соседи тоже хотят iops, и побольше, побольше :)
+4
Это не измерение а сферический конь в вакууме. В каком виде хранятся данные DomU в Dom0 и не указали какой драйвер используется в DomU для доступа к диску, работает ли DomU в HVM или нет. Я замечал проблемы с вводом-выводом при малом выделении памяти Dom0.
0
> Xen PV — замер на виртуальной машине Xen в режиме паравиртуализации: 1 CPU, 256 Mb RAM. Kernel: 2.6.18-164.el5xen
Какой такой HVM?
Какой такой HVM?
+1
Xen PV — замер на виртуальной машине Xen в режиме паравиртуализации
И? Какая версия ядра была использована внутри DomU? Какая версия ядра на Dom0? В каком виде предоставлялось блочное устройство DomU?
Какой такой HVM?
Аппаратная виртуализация. Была она использована или нет не указано. Не указано какая версия Xen используется. Не проведено тестирование с двумя виртуальными машинами.
0
Вы слово «паравиртуализация» видите? Это исключает HVM. Это не аппаратная виртуализация, это модификация ядра гостевой ОС, так, что оно работает не в ring 0, а в ring 1. (userspace не меняется — как работало в ring 3, так и работает). Этот процесс модификации — портирование в Xen; именно поэтому портированы только открытые системы (напр. Linux).
Кстати говоря, это основной режим работы Xen, который там был с самого начала, а вот HVM — это костыль.
Кстати говоря, это основной режим работы Xen, который там был с самого начала, а вот HVM — это костыль.
+1
Вы слово «паравиртуализация» видите? Это исключает HVM.
С какого перепуга? К примеру существуют паравиртуализационные драйвера для Windows и он работает именно в HVM.
Это не аппаратная виртуализация, это модификация ядра гостевой ОС, так, что оно работает не в ring 0, а в ring 1. (userspace не меняется — как работало в ring 3, так и работает). Этот процесс модификации — портирование в Xen; именно поэтому портированы только открытые системы (напр. Linux).
Извините меня, но кто вам сказал, что программная реализация будет работать быстрее и надежнее аппаратной? Термин «паравиртуализация» подразумевает знание виртуализируемой системы о том что она работает в виртуальной среде. Это может выражаться или в модификации ядра, чтобы система использовала API гипервизора или в использовании специальных драйверов ввода-вывода, так-как использование в виртуальной машине драйвера для реальных устройств добавляет «overhead».
Кстати говоря, это основной режим работы Xen, который там был с самого начала, а вот HVM — это костыль.
Кстати говоря он таким является потому что раньше поддержки виртуализации небыло. К примеру KVM работает только при наличии аппаратной виртуализации.
-2
Вы в теме? Вы вообще понимаете, как 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 работает только при наличии аппаратной виртуализации.
Мы про 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 (впрочем, как и для всех остальных устройств).
В общем, вы для начала просто сделайте и поиграйтесь с паравиртуальным линуксом, взгляните, что там, а потом и спорьте.
+1
Кстати и с аппаратной виртуализацией почти все устройства можно паравертуализовать, у kvm уже есть диск и сеть. Но по моим субъективным тестам, xen пока рвёт kvm.
+1
Он явно не в теме :)
0
Вы в теме? Вы вообще понимаете, как 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 и паравиртуализированных драйверов более перспективно нежели использование модифицированных ядер. Этому есть причины:
Переключение контекста происходит в любом случае.
Аппаратная виртуализированая среда обеспечивает лучшую изоляцию и быстродействие.
Не требуется модифицировать ядро, что позволяет запускать те операционные системы, что не могут быть подвергнуты модификации.
0
Добрый день, у меня есть вопрос к специалисту, у меня возник вопрос виртуализации серверов телефонии, телефония плого работает в виртуальном пронстранстве из за отсутствия точного источника часов «Timer source» оно служит для синхронизации голоса от разный источников, например при конференции, если таймер прохой голоса выходят из «фазы» и получается дисторсия, у меня есть такие ключики Usb которые можно воткнуть в систему дла точного тайминга, а можно ли один ключик распределить на все виртуальные машины?
0
Тест без графиков — негодный тест. Нужны графики замеров на ovz и xen, чтоб визуально сравнить.
-4
Вы же запускали тесты «в одно лицо»?
Запустите 10 гостевых систем и одновременно запустите в них тесты.
Запустите 10 гостевых систем и одновременно запустите в них тесты.
0
Зачем? И так понятно, что 10 гостей замедлят друг друга. Если запустить в native OS десять dd, читающих диск, или запустить в 10 гостях по одному такому dd, они будут тормозить друг друга в обоих случаях, вне зависимости от наличия Xen.
Тест проверял только то, сколько теряется именно на самом Xen, как прослойке между виртуальной машиной и физическим диском.
Тест проверял только то, сколько теряется именно на самом Xen, как прослойке между виртуальной машиной и физическим диском.
0
Часто при обсуждении различных способов виртуализации, сторонники Virtuozzo (обычно, хостеры на OpenVZ) вспоминают про услышенное когда-то и где-то утверждение типа «Xen тормозит при работе с диском»
Может быть, стоило тестировать по 10 гостей в XEN и OpenVZ?
0
Может быть и стоило бы. Этот тест проверяет оверхед по сравнению с нативной ОС, показывает 7% и мне этого достаточно. Не думаю, что OpenVZ покажет лучший результат, чем нативная ОС и из-за этого оторвется от 7%. Поэтому сравнение с OpenVZ мне не настолько интересно, чтобы тратить время еще и не тестирование его. Но если это сделаете вы, я с удовольствием посмотрю результаты.
0
Попробуйте с PV ядром гостя, производительность относительно HVM либо не изменится, либо увеличится. Разница там около пары процентов, но, думаю, поймать на кучке тестов можно.
0
Нормальный тест должен выполняться так: ставим XEN, запускаем одну машину, две машины, и 10 машин и меряем в трёх вариантах. Потом на ту же машину ставим OpenVZ, и повторяем тест. Это даст результат. А измерение в идеальных несуществующих в природе условиях даст непонятно кому полезные данные.
0
в Ксене видел проблемы с дисками не на линейном чтении блоками, а на конкурентности.
попробуйте читать в 5 потоков в ядре ксена и без него. в ксене iowait будет 100% и ввод/вывод и вообще система у меня тормозится. без ксена все ок
попробуйте читать в 5 потоков в ядре ксена и без него. в ксене iowait будет 100% и ввод/вывод и вообще система у меня тормозится. без ксена все ок
-1
Хабравчане юзающие xen, как может прокомментировать эти ссылки:
— www.hpl.hp.com/techreports/2007/HPL-2007-59R1.pdf
— www.fridu.org/hosting/52-openvz-virtualization
— www.hpl.hp.com/techreports/2007/HPL-2007-59R1.pdf
— www.fridu.org/hosting/52-openvz-virtualization
0
Здесь ксен и опенвз ставят на одну ступеньку, меж тем это цели у них немного различны. OpenVZ замечательно подходит для массового хостинга, не забирая лишних ресурсов, правда, там есть ограничения, упомянутые по ссылкам — нет полноценного управления машиной в смысле классического ребута или шатдауна, минимальный уровень абстракции — фс, а не голый диск, такая модель очень хороша, когда вы хотите воткнуть впс и запустить на нем кучу обычных сервисов. Xen применим в тех случаях, когда а) нужно использовать свое ядро или полную виртуализацию б) для более гибкого управления, когда всему domU выделяется один lv в виде физ. диска и он делает с ним что хочет + возможность ребутов. Ксен обеспечивает такую штуку, как живая миграция, благодаря которой его можно использовать в отказоустойчивых системах. Я применяю следующую схему: common xen pv -> common xen vg > много uniquie xen domain lv -> pv -> uniquie xen domain vg -> lv (разделы)
+1
Не совсем понял про схему. vg и lv это про lvm-разделы и pv-в смысле домен в паравиртулизации?
0
Может еще по-этому подскажите community.livejournal.com/ru_root/1924149.html не могу с vlanaми разобратся.
0
Отвечу сразу по двум вопросам: 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, а физ. диск той машины, на которой будет исполняться виртуалка.
Про вланы и мосты — я после довольно большого опыта работы с ксеном считаю, что всю настройку сети, отличную от создания одиночного бриджа, следует производить в оси, а гости подключать к уже существующим бриджам, то есть, следует создать нужный набор вланов и лепить их в бриджи самописным скриптом и уже в конце цеплять к ним гостей.
Про вланы и мосты — я после довольно большого опыта работы с ксеном считаю, что всю настройку сети, отличную от создания одиночного бриджа, следует производить в оси, а гости подключать к уже существующим бриджам, то есть, следует создать нужный набор вланов и лепить их в бриджи самописным скриптом и уже в конце цеплять к ним гостей.
+1
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Мифические тормоза диска на Xen