Разработчики системы виртуализации VirtualBox сообщили (http://vbox.innotek.de/pipermail/vbox-dev/2009-April/001328....) о завершении базового портирования хост-режима платформы на FreeBSD. Компания Sun Microsystems официально не поддерживает платформу FreeBSD, разработчики провели портирование в свое свободное время. На странице со скриншотами (http://www.virtualbox.org/wiki/Screenshots) опубликованы снимки экрана с выполнением во FreeBSD гостевых окружений с Ubuntu Linux и Windows.В текущем состоянии версия для FreeBSD включает реализацию программной виртуализации, GUI интерфейс на Qt4, поддерживает проброс сети через NAT и вывод звука через API звуковой системы OSS.
В настоящий момент не реализовано:
- "Bridged" и "host only" режимы проброса сети в гостевое окружение (необходима разработка драйверов для ядра FreeBSD);
- USB;
- Программа установки;
- OpenGL;
- ACPI;
- Доступ к CD/DVD хост-системы;
- Доступ к последовательному порту хост-системы....
URL: http://vbox.innotek.de/pipermail/vbox-dev/2009-April/001328....
Новость: http://www.opennet.me/opennews/art.shtml?num=21574
У меня до сих пор нет процессора с поддержкой виртуализации. Насколько вообще её наличие сказывается на производительности гостевой ОС?
>У меня до сих пор нет процессора с поддержкой виртуализации. Насколько вообще
>её наличие сказывается на производительности гостевой ОС?Довольно сильно повышает быстродействие гостя.
> Довольно сильно повышает быстродействие гостя.It depends on...
На самом деле, аппаратная виртуализация позволяет виртуализировать 64-хбитные операционные системы (конечно же, только на 64х-битных хостах), а тако ж операционные системы, использующие некоторые "эзотерические" (tm) инструкции, типа OS/2.
А вот то, что аппаратная виртуализация быстрее, чем программная -- это очень и очень questionable. Короче, почитайте доку по VirtualBox. :)
Не читала доку по VirtualBOX от корки до корки, но, обычно, аппаратная виртуализация позволяет аппаратно защитить память (а не софтово), что резко повышает производительность.В VirtualBOX "пошли своим путем"?
Разница аппаратной vs софтовой в том (если совсем на пальцах), что софтовая обходит "неприятные" инструкции путем замены их на другой код. Такая функциональность долгое время была только у vmware, сейчас есть и у virtualbox. Нахождение таких участков кода и подмена их отнимает ресурсы, но в итоге, когда это сделано, данный код повторно выполняется быстро (похоже на jit-машину в java).При использовани аппаратной супервизор виртуальных машин тупо выполняет код, ничего не анализирует и ничего не меняет (так kvm всегда работает - это очень просто). На "неприятной" инструкции срабатывает трап, процессор аппаратно производит нужное переключение и это все красиво обрабатывается. Проблема в том, что эта операция очень дорогая по циклам.
Софтварный способ часто быстрее (на что жаловались vmware, кстати, когда вышли процы с аппаратной поддержкой), потому что результирующий подмененный код заметно быстрее второго способа. Это особенно заметно, когда один и тот же код, где требовалась подмена дергается часто. Но, конечно, подмена кода очень трудоемкая операция, поэтому в определенных ситуациях аппаратный способ оказывается быстрее (если участков для подмены не много или все время разные).
>Разница аппаратной vs софтовой в том (если совсем на пальцах), что софтовая
>обходит "неприятные" инструкции путем замены их на другой код. Такая функциональность
>долгое время была только у vmware, сейчас есть и у virtualbox.Еще у Quemu, Bochs, ...
>[оверквотинг удален]
>и ничего не меняет (так kvm всегда работает - это очень
>просто). На "неприятной" инструкции срабатывает трап, процессор аппаратно производит нужное переключение
>и это все красиво обрабатывается. Проблема в том, что эта операция
>очень дорогая по циклам.
>Софтварный способ часто быстрее (на что жаловались vmware, кстати, когда вышли процы
>с аппаратной поддержкой), потому что результирующий подмененный код заметно быстрее второго
>способа. Это особенно заметно, когда один и тот же код, где
>требовалась подмена дергается часто. Но, конечно, подмена кода очень трудоемкая операция,
>поэтому в определенных ситуациях аппаратный способ оказывается быстрее (если участков для
>подмены не много или все время разные).У Вас нет ссылок на бейнчмарки? То, что Вы написали, очень интересно, не видела никогда раньше такой точки зрения...
> А вот то, что аппаратная виртуализация быстрее, чем
>программная -- это очень и очень questionable.Что, неужели софтварные решения научились уже быть быстрее аппаратных?Как-то сомнительно это заявление звучит.В чем прикол?Насчет документации - может благородный дон уточнит на что там следует обратить внимание?
А что вас удивляет? Реализация в железе никогда не гарантировала ни скорости ни надежности ни удобства. Зависимости вообще никакой нет.Уж насчет кода по-моему и дураку должно быть понятно - один раз оттранслированный код всегда будет быстрее трапа на каждый чих.
>А что вас удивляет? Реализация в железе никогда не гарантировала ни скорости
>ни надежности ни удобства. Зависимости вообще никакой нет.Ага, вот только почему-то все чисто-софтварные эмуляторы\виртуализаторы - дикие тормоза.Особенно если еще и с виртуализацией периферии.Яркий пример - bochs.Прикольный.Т.к. честно виртуализует ВСЕ.Но мееееееееедленный что пипец.
>Уж насчет кода по-моему и дураку должно быть понятно - один раз
>оттранслированный код всегда будет быстрее трапа на каждый чих.А, простите, оттранслированный код - он что будет делать?Не то же самое что и трап?И, собственно, учтя что оно в гуесте как я понимаю без привилегий кукует (чтобы отдать все бразды правления виртуализатору) - все-рано дергать кого-то привилегированного придется для обработки запросов I\O и прочая?Куда они денутся то?И почему софтварное дергание гипервизора будет быстрее аппаратного трапа в гипервизор по ровно тому же поводу?Нельзя ли более подробно объяснить?Возможно я устал и туплю, но все-таки?Я почему-то наивно полагал что одна из целей аппаратного дергания гипервизора - ускорить как раз этот процесс, а не наоборот oO
> яркий пример - bochs.Прикольный.Т.к. честно виртуализует ВСЕ.Но мееееееееедленный что пипец.Я даже не удивлен, что вы не видите разницу между виртуализацией и полной эмуляцией.
> он что будет делать?Не то же самое что и трап
Ну как вам сказать. Как вы думаете, что лучше - на каждую страницу иметь page fault и полное копирование ее из другого места, или таки ценой неких предварительных действий получить код, который может работать без page fault'ов?
У Вас есть бенчмарки?
Я Вам низко поклонюсь и скажу спасибо, так как Вы по-настоящему откроете (мне) глаза на многое.Теоретически можно выстроить, псевдо-логично, любую цепочку, и она будет выглядеть правдоподобно, если собеседники не найдут в ней ошибку, или не заметят фактор, который в реальном мире нивелирует построения.
>У меня до сих пор нет процессора с поддержкой виртуализации. Насколько вообще
>её наличие сказывается на производительности гостевой ОС?на производительность гостевой OS - не знаю. но вот гостевая OS может тратить 0 процентов (если не выводится на экран ничего) - вот это реально. особенно впечатляет линукс в качестве гостевой OS при включении аппаратной виртуализации (в основном правда kvm используется).
YES!!!
>YES!!!Только вот "Известные проблемы" сводят все на нет.
Но начало есть, теперь чтобы в развитие пошло!
Господа, объясните нубу плиз: Что значит "поддержка хост режима" для такой-то ОС??
В моем понимании, что вмваря, что любая другая система виртуализации всегда была этаким черным ящиком, в который вставляешь СД диск (монтируешь исошник), а уже с исошника запускается загрузчик этого сд, загрузчик запускает инсталлятор оси и т.д.
Сама система виртуализации предоставляет для ОС виртуальные: сетевую карту, память, проц и прочую перефирию.
Так какая-же разница вообще, что там будет за ОС, Фрибсд или линукс или Вынь?
Принцип работы с той же сетевой(виртуальной) картой все равно будет производиться через драйвер который есть в ОС. Чего я тут недопонимаю, просветите кто не занят?
Хост режим - значит под ней работает.
То есть, новость о том, что теперь есть версия VirtualBox для FreeBSD.
А запускать там можно что угодно. Только работает не всегда стабильно. Но это уже другая история :)
>Хост режим - значит под ней работает.
>То есть, новость о том, что теперь есть версия VirtualBox для FreeBSD.
>
>А запускать там можно что угодно. Только работает не всегда стабильно. Но
>это уже другая история :)Спросил еще вот почему: в вмваре под виндой когда устанавливаешь ОС, то варя спрашивает, мол, что это будет за ОС. И список там идет - линукс, винхр, фриибсд, еще куча всего. Вот это вот зачем тогда, если вы говорите, что запускать можно что угодно?
> И список там идет - линукс, винхр, фриибсд, еще куча всего.Это называется Маркетинг...
А так, например, чтоб случайно VAX/VMS, HP-UХ или AIX не пытался запускать.
Не все же такие вумные, и заклинания CISC, PPC, PA-RISC, ACPI table, GDT/GDI, MSR, и т.д., не все знают...
Можешь смело выбирать WinXP и ставить Убунту, может даже быстрее заработает. :)
Это не маркетинг, а "поддержка". А под поддержкой понимается всего лишь тулзы, которые можно поставить в гостевую =) Например VMware ESX 3.5 не поддерживала FreeBSD в качестве гостевой, но это не значит, что её нельзя было запускать) А теперь (4.0 версия) поддерживает и теперь можно установить на FreeBSD VMtools и заработают самые вкусные фишки при использовании vMotion например. Ну и т.д. =)
> А под поддержкой понимается всего лишь тулзы, которые можно поставить в гостевую =)Их можно поставить вручную, если неправильно выбрана гостевая ОС
Объясните сирому, зачем ВБокс, когда есть куэму?Точнее есть ли у ВБокса преимущества помимо динамического размера виртуального харда?
>Объясните сирому, зачем ВБокс, когда есть куэму?
>
>Точнее есть ли у ВБокса преимущества помимо динамического размера виртуального харда?ху из куэму?
Советую тебе провести сравнение между qemu и vbox.
qemu vbox
ARM + -Выбор очевиден.
> Выбор очевиден.Да, очевиден. Выбор -- VBox. Qemu, осторожно выражаясь, не блещет производительностью. :)
>> Выбор очевиден.
>
> Да, очевиден. Выбор -- VBox.Согласен. VBox имеет готовые установочные пакеты, быстро работает и почти на любой ситеме. Виртуальную ос можно легко перекидывать. Формат претендует на стандарт. Удобный интерфейс. У меня нет причин использовать qemu. Недавно как раз отказался от установки FreeBSD из-за отсутствия VBox.
> Да, очевиден. Выбор -- VBox.Ему про ARM, а он про скорость. Весна?
Вообще, если вам нужна производительность в эмуляторе/виртуализаторе, вы что-то не так делаете.
> не блещет производительностью. :)А мне там не винду запускать, производительность не сильно важна.
> Да, очевиден. Выбор -- VBox. Qemu, осторожно выражаясь, не блещет производительностью. :)Куэму в некоторых операциях сливает, в некоторых превосходит Вбокс. ВМваре - ближайший преследователь вообще курит в стороне. К тому же на компах, на которых способна крутится виста никаких тормозов не заметно.
Ещё какие-нибудь объективные параметры есть? Фичи какие-нибудь.
>Объясните сирому, зачем ВБокс, когда есть куэму?
>
>Точнее есть ли у ВБокса преимущества помимо динамического размера виртуального харда?У QEMU тоже динамически меняется размер виртуального харда. Юзай формат qcow или qcow2 для образа, вместо RAW.
А FreeBSD под FreeBSD теперь можно будет запускать? А то раньше в боксе FreeBSD в качестве гостя не работала, в отличии от QEMU.
VBox 2.2.0, VBox 2.2.2 -- отлично работает. без каких-либо плясок.
гость FreeBSD 7-STABLE.
хост Debian/GNU Linux 5, x86-64.
> отлично работаетЭто высказывание настолько субьективно как "ох*енная баба", нужно сравнение между XEN/VBox/Qemu, более обьективное.
`Работает' - это абсолютно объективное высказывание.
> У QEMU тоже динамически меняется размер виртуального харда. Юзай формат qcow или qcow2 для образа, вместо RAW.Даже так...
>Объясните сирому, зачем ВБокс, когда есть куэму?таки +1
>
>Точнее есть ли у ВБокса преимущества помимо динамического размера виртуального харда?а чем qcow/qcow2 для qemu не угодили?!
А на первом скрине что за тема гномовская???
> а чем qcow/qcow2 для qemu не угодили?!Я тупо не знал о них.
а утилиты для гостевой фрибсд появились? раньше не было