Пошаговое руководство (http://m-ivanov.livejournal.com/3384.html) по установке и запуску Windows, внутри QEMU окружения во FreeBSD.URL: http://m-ivanov.livejournal.com/3384.html
Новость: http://www.opennet.me/opennews/art.shtml?num=18194
"Например, нет внятного указания на то, что для запуска QEMU нужны либо права root'a, либо настроенный sudo." - или я неправильный какой-то, или FreeBSD у меня не такая, но обхожусь без root-a и без sudo...
Это зависит от того, как сеть настроена. Для бриджа нужен root или sudo.
>Это зависит от того, как сеть настроена. Для бриджа нужен root или
>sudo.Да неужели? А зачем в статье написано про?
"6) Разрешаем непривилегированному пользователю открывать устройство /dev/tap0
# chmod 666 /dev/tap0"Автор статьи и сам то не знает что пишет. Вначале утверждает, что нужны права рута, а потом пишет настройку, чтобы работало от простого пользователя.
>Автор статьи и сам то не знает что пишет. Вначале утверждает, что
>нужны права рута, а потом пишет настройку, чтобы работало от простого
>пользователя.Смысл статьи в том и заключается, чтобы избавиться от рута и запускать от простого пользователя.
ИМХО, достаточно правильно прописать пару строк в devfs.rules
Каких конкретно строк?
>Каких конкретно строк?[localrules=111]
add path 'tap*' mode 0666
[localrules=112]
add path 'kqemu' mode 0666
>[localrules=112]
>add path 'kqemu' mode 0666Что делает это правило?
У меня под юзером qemu не хотел использовать kqemu.
У меня работает вот так:# Network for Qemu
add path tap[0-9]* mode 0660 group wheel
add path bribge[0-9]* mode 0660 group wheelПри желании можно назначить разрешения не для какой-то группы, а для определенного пользователя.
>add path bribge[0-9]* mode 0660 group wheelЧто делает это правило?
>>add path bribge[0-9]* mode 0660 group wheel
>Что делает это правило?То-же самое, что и первое: при создании интефейса сименем таким-то делает его владельцами группу wheel и назначает права доступа к нему.
Интересно, почему по поводу первой строки у вас вопроса не возникло?
Переформулирую вопрос: зачем нужно это правило?Первое правило нужно для того, чтобы QEMU мог открыть TAP-интерфейс, через который будет работать сеть. А второе правило зачем?
Гы...
А зачем в вашей статье написано вот это?> 2) Создаем виртуальный сетевой интерфейс, который будет выполнять функции моста
> # ifconfig bridge0 createВторое правило затем, что если уж создается бридж, то пусть создается с нужными мне правами доступа.
Устройство bridge0 не создается и назначения прав не требует.
Снова посмотрел в статью, много думал... :-D>...
> # ifconfig tap0 create
>...
> bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>...В таком случае исправьте статью - в ней слово "bridge" встречается 12 раз... (-;
Для извращенцев вдвойне!
+1 ... не порно, но хардкорно.Сравнил с своим опытом установки и юзежа virtualbox на убунте, где все доходчиво и без черной магии (поставить из пакетов, никакой возни в консоли, слепить виртуалку в GUI виртуалбокса, на все про все уйдет отсилы ~5 минут, от моммента выбора пакета до начала загрузки с CD, скорее всего не потребуется никакого RTFM, особенно если вы хоть какой-то виртуализатор типа вмвари видели хоть раз).Невольно напросился вывод: "FreeBSD - очень дружетсвенная система... но только для любителей BSDM и черной магии".
Странно. Давно юзаю винду под qemu, и как-то ни разу не возникало желание настроить бридж. Всегда устраивал qemu-шный nat+dhcp. В общем как-то все сложно в статье.
> Всегда устраивал qemu-шный nat+dhcp.А если хочется, чтобы Windows была доступна из сетИ?
>> Всегда устраивал qemu-шный nat+dhcp.
>
>А если хочется, чтобы Windows была доступна из сетИ?Смотря что имеется в виду под доступностью. Когда мне требовалось прокинуть несколько портов - redir вполне хватало. Но и для бриджа рут нафиг не нужен, а ставить 666 на тап - неправильно. мы же не хотим, чтобы, например, юзер www мог слать в сеть любые (!) пакеты, правда? только 660 и создание группы для бридж юзеров.
>Но и для бриджа рут нафиг не нуженНужен. Без рута TAP не открыть. Прав 666 (или 660) на /dev/tap недостаточно.
>>Но и для бриджа рут нафиг не нужен
>
>Нужен. Без рута TAP не открыть. Прав 666 (или 660) на /dev/tap
>недостаточно.У меня есть qemu с бриджем и в рутлесс конфигурации. Вы что-то сделали не так.
Скорее, это Вы сделали что-то такое, что позволило Вам запускать бридж без прав рута.
NAT не решает нужных задач. Мне был нужен именно бридж.
Да, с маской 30 (максимум) - это работать будет
Объясню, что я подразумеваю:
К примеру, у Вас на Windows запущен ftp-сервер.
Как в этом случае user (anonymous)получит доступ к этому сервису
(только, please, без NATa и файервола)?
Как обычно, по IP и порту. В чем Вы видите сложность?
Например, имеем ADSL-соеединение. Модем связан с компом через Ethernet, и находится в
режиме bridge. Ваш IP-адрес имеет маску 32.
В этом и заключается вопрос:
В какое адресное пространство Вы включите IP-адрес виртуальной машины?
Ну дык, конечно. При такой постановке задачи у меня сразу возникает вопрос:Ты за меня или за медведя? (c) анекдот
нормальная статья. там нет ничего сложного. но qemu тормоз, поэтому мой выбор Sun xVM VirtualBox 2.0 :)
ну да.. вбокса под фрю нету ) поэтому как платформа виртуализации мой выбор все что угодно, только не бсд )
Тормоз? С модулем акселерации (и с включенной опцией полной акселерации) QEMU работает очень быстро.
Да и без модуля замечательно работает.
>Тормоз? С модулем акселерации (и с включенной опцией полной акселерации) QEMU работает
>очень быстро."Относительно меня или вас?" (c) реклама.Быстро?По сравнению С ЧЕМ?А то черепаха тоже быстрая.Если сравнивать с улиткой.Хотите сказать что qemu переплюнет виртуалбокса и тем более вмвару?Что-то сомнительно.
> Быстро?По сравнению С ЧЕМ?По субъективным ощущениям. Не ощущается никаких торможений.
>По субъективным ощущениям.А это не есть объективная оценка производительности.Сказать что решение X производительное - не катит.Вот если X в 2 раза быстрее Y и в основном встречается решение Y, тогда, решение X называется производительным.А то i80206 производительный, знаете ли.Был.По сравнению с i8086 :).Зуб даю что во времена 8086 никто не чувствовал тормозов на i286 :)
А кто говорил про объективные оценки? Я же русским по белому написал - "по субъективным ощущениям".
>- "по субъективным ощущениям".Субъективизм штука необъективная.По моим субъективным ощущением qemu заметно тормознее иных виртуализаторов типа вмвари и даже виртуалбокса.Зато у него есть симпатичный мне неоспоримый плюс: ARM поддерживает.Но вот винды на него ставить?... ИМХО нафиг-нафиг такое "счастье".
>>По субъективным ощущениям.
>
>А это не есть объективная оценка производительности.Сказать что решение X производительное -
>не катит.Вот если X в 2 раза быстрее Y и в
>основном встречается решение Y, тогда, решение X называется производительным.А то i80206
>производительный, знаете ли.Был.По сравнению с i8086 :).Зуб даю что во времена
>8086 никто не чувствовал тормозов на i286 :)Объективные оценки скорости виртуальных машин - очень непростая задача. Крайне. Потому как часть операций может быть лучше сделана в одних системах, а часть в других, и обычные тесты совершенно не катят. Я думаю что самое правильное - измерять и сравнивать производительно на реальных задачах.
Хорошая статья. Для меня лично, qemu - идеальный вариант для виртуализации, потому что полностью и очень гибко настраивается из коммандной строки, в отличие от (и поддерживает ненативные архитектуры, что тоже критично). К скорости претензий тоже нет, хотя никаких kqemu не использую. Если вам надо непременно запускать crysis, но не хочется грузить windows - виртуализация в любом случае не лучший выбор. А обычные приложения летают.
>запускать crysis, но не хочется грузить windows - виртуализация в любом
>случае не лучший выбор.Виртуализация бывает разной.Скажем какой-нить OpenVZ - очень тоненькая прослойка и потерь скорости почти не происходит.А вот если CPU и периферия изображается программно или гейтование требует множество действий - скорость сильно просядет.Ну например, скорость работы с диском у vmware и подобных обычно ниже всякой критики.QEMU тут думаю тоже нечем особо покозырять.
> QEMU тут думаю тоже нечем особо покозырять.Ты думаешь или ЗНАЕШЬ? Может хватит ля-ля?
>Ты думаешь или ЗНАЕШЬ?Виртуализаторы давным давно мой предмет интереса.Посему вы или аргументируете где именно я не прав или идете лесом.
> Может хватит ля-ля?
Такие заявы надо подкреплять бенчами, а не чрезмерно прокачаным гонором, Luke.
Виртуализаторы это _твой_ предмет интереса, а не мой. Поэтому или подкрепляй свои заявы бенчами, или не лезь в каждую новость, в которой встречаются слова *BSD. "Мне кажется у меня в убунте быстрее", классный бенч. Sky Walker.