OpenNET: статья - FreeBSD QEMU + Windows 2000: новые подробности. (qemu freebsd emulator windows)

Ключевые слова: qemu, freebsd, emulator, windows, (найти похожие документы)
From: Bachilo Dmitry <root@solink.ru.> Newsgroups: email Date: Mon, 23 Jun 2006 14:31:37 +0000 (UTC) Subject: FreeBSD QEMU + Windows 2000: новые подробности. В статье http://community.livejournal.com/ru_root/710103.html описывался процесс установки Windows 2000. Сатья просто замечательная, но в ней есть упущения, делающие прямой подход к QEMU по статье невозможным. Во-первых в командах запуска QEMU не указана раскладка клавиатуры, что в результате сдвигает всю клавиатуру на 1 клавишу вправо и делает её практически неюзабельной, особенно функциональные клавиши. Во-вторых не указаны некоторые особенности модуля ускорения kqemu и особенности установки Windows 2000. В-третьих, указан стомегабитный сетевой адаптер, не определяющийся в Windows 2000, а следовательно такой винде никак не попасть в сеть, адаптер надо эмулировать другой. Не знаю как у других, а у меня Windows 2003 не увидела вообще ни одного из эмулируемых адаптеров и её попытка её установки таким образом вообще бессмысленна. Ну и главная ошибка автора этой статьи в том, что он предложил использовать какой-то древний бриджинг, совершенно нефункциональный и неудобный (ну это субъективно). Кроме того не рассказано, как быть, если установка идет с Windows-машины с иксами, ведь если виртуальная винда для входа попросит нажать Ctrl+Alt+Del под Windows это невозможно будет сделать. Выход предоставляет сам QEMU. И так, что же собственно предлагается? Лично я бы написал эту статью так: +++ Задача Поставить Windows 2000 Server на qemu под FreeBSD и удаленно ей управлять. +++ Сборка и установка # cd /usr/ports/emulator/qemu # make -DWITH_KQEMU -DWITH_HACKS && make install clean +++ Установка Windows Создаем образ жесткого диска для Windows размером 4Гб: # mkdir /usr/local/win # qemu-img create /usr/local/win/win.img 4096M Лично я ставил это всё на сервер в стойке и потому не имея монитора экспортировал окно QEMU на Windows. Для этого поднял простой X-Server X-Deep и всё, куда проще, чем поднимать Cygwin. И так, во фре, даем команду export DISPLAY=xxx.xxx.xxx.xxx:0 где ххх - это адрес виндоуз машины. Если процесс идет с этой же машины через путти - всё равно. Никаких манипуляций с путти не требуется. Ставим Windows с образа компакт-диска или прямо с диска (тогда -cdrom /dev/acd0): # qemu -k ru -win2k-hack -full-screen -localtime -m 512 \ -cdrom /tmp/win.iso -boot d /usr/local/win/win.img -m 512 ___ количество памяти, которое QEMU отожрет от физической машины. ВНИМАНИЕ! Не давайте отожрать лишнего. Если QEMU съест всю память и весь SWAP, он будет убит. -win2k-hack - чтобы винда не начала жаловаться на отсутствие места на диске. Нужно только при установке. Потом эта опция будет только замедлять работу с диском. -k - чтобы не сдвигать клавиатуру, -full-screen, чтобы работала мышь. Таковы уж виндовые иксы. Когда Windows попросит для входа нажать Ctrl+Alt+Delete, нажмите Ctrl+Alt+3 и попадете в консоль QEMU. Наберите там sendkey ctrl-alt-delete нажмите энтер и затем нажмите Ctrl+Alt+2 чтобы вернуться в виртуальную машину. +++ KQemu KQemu - модуль ядра, обеспечивающий акселерацию qemu, без него вся затея имхо теряет смысл. Подгружаем его: # kldload kqemu Чтобы подгружался автоматически при старте системы, пишем в /boot/loader.conf: kqemu_load="YES" ВНИМАНИЕ! Когда этот модуль включен, в лог и нулевую консоль сыпется мусор типа __kernel: npxdna: fpcurthread == curthread 33966 times__ где-то одна строчка в секунду в течение всего времени, пока запущен QEMU с этим кернел-модулем. Но без него действительное медленнее. ОДНАКО! Если памяти у вас совсем мало, например 256 мегабайт, использование модуля имеет строго обратный эффект. Будьте внимательны. +++ Сеть Как только Windows установлена, сразу хочется увидеть ее работоспособность в сети, для этого: Создаем /etc/qemu-ifup (там по умолчанию qemu ищет скрипт для "-net tap"), туда пишем: kldload bridge sysctl net.link.ether.bridge.enable=1 sysctl net.link.ether.bridge.ipfw=1 # эту строчку пишем, если хотим использовать ipfw для фильтрования # пакетов внутри моста через ipfw. По умолчанию не нужна. sysctl net.link.ether.bridge.ipf=1 # эту строчку пишем, если хотим фильтровать пакеты внутри моста # через ipfilter. По умолчанию не нужна. sysctl net.link.ether.bridge.config=rl0,tap0 # где rl0 - физический сетевой интерфейс, через который виртуальная винда # должна будет видеть вашу сеть. Крайне желательно, чтобы у вас в сети был DHCP-сервер. Windows как-то странно ведет себя со статическим адресом, но может быть, это только у меня... Потом, конечно: # chmod +x /etc/qemu-ifup +++ Использование Запускаем qemu: # qemu -k ru -kernel-kqemu -full-screen -localtime -boot c \ /usr/local/win/win.img -net nic -net tap -m 512 В Windows я поотключал всякие ненужные сервисы и прочее, дал доступ к Terminal Service и залогинился со своей машины. На FreeBSD затем я зафаерволил все нежелательные порты Windows. +++ Уводим в бэкграунд У меня qemu с Windows запускается при загрузке из rc.local следующей строкой: /usr/local/bin/screen -dmS qemu /usr/local/bin/qemu -nographic -parallel null \ -serial null -monitor null -k ru -kernel-kqemu -localtime -net nic -net tap \ -m 512 -boot c /usr/local/win/win.img & Вот и всё.

2.7, Bocha (??), 08:33, 26/06/2006 [^] [^^] [^^^] [ответить]	+/–
:-)))) Если я всё правильно понял, это было сделано еще в 5.3 и стех пор bridge=if_bridge. Но если я и ошибаюсь, то это не меняет главного - автор оригинала предлодил использовать бриджинг, который нельзя фаерволить. Или как я сказал "совершенно нефункциональный и неудобный", я не говорю "старый" и не говорю что мой сверхсовременный и лучший. Просто в bridge есть поддержка ipfw. Всё.

3.8, chip (??), 10:43, 26/06/2006 [^] [^^] [^^^] [ответить]

+/–

>:-)))) Если я всё правильно понял, это было сделано еще в 5.3
>и стех пор bridge=if_bridge.

bridge!=if_bridge и по сей день. Обе технологии сосуществуют параллельно.

>Но если я и ошибаюсь, то это не меняет главного - автор
>оригинала предлодил использовать бриджинг, который нельзя фаерволить.

Это так критично для виртуальной машины? Что мешает firewall'ить выходной интерфейс? Учитывая то, что адрес виртуальной машины известен.

> Или как я сказал
>"совершенно нефункциональный и неудобный", я не говорю "старый" и не говорю
>что мой сверхсовременный и лучший. Просто в bridge есть поддержка ipfw.

А разве ipfw привязан к конкретной реализации моста?! ipfw заслуживает отдельного писания о костылестроении.

4.10, Bocha (ok), 07:08, 27/06/2006 [^] [^^] [^^^] [ответить]	+/–
Вы не читали саму статью чтоли? Я же сказал, на сервере уже стоит самба и винс-сервер, если поднять винду и не зафаерволить её 135-139 порты, она перекроет самбу на физическом сервере и сеть пойдет к чертям, проверено. Фаерволить физический сервер никакого смысла не имеет, мне ведь не надо фаерволить самбу, только винду. На bridge этот фаерволинг раздельно возможен, на ng_bridge - нет.

5.13, chip (ok), 11:02, 27/06/2006 [^] [^^] [^^^] [ответить]	+/–
Вы то упоминаете if_bridge, то ng_bridge Остановитесь таки на чем-нибудь А вы ... большой текст свёрнут, показать

6.14, Bocha (ok), 12:01, 27/06/2006 [^] [^^] [^^^] [ответить]

+/–

>>На bridge этот фаерволинг раздельно возможен, на ng_bridge - нет.
>
>Вы то упоминаете if_bridge, то ng_bridge. Остановитесь таки на чем-нибудь!

Вы в самом деле не понимаете что я пишу, или просто упрямитесь? Еще раз. В оригинале была статья на ng_bridge. Он не умеет фаерволить. Я предложил другой мост, который фаерволить может. Им оказался bridge. if_bridge я не использовал, потому что man if_bridge не существуется, я воспользовался тем, что нашел.

>
>А вы читали ман к if_bridge?

Соответственно нет, искал но не нашел и потому if_bridge не юзал, об этом написано.

>
>Вы действительно считаете, что если собираются убирать поддержку bridge(4) в пользу if_bridge(4) не предусмотрели аналогичного функционала?

Это вы сами только что придумали, я вообще не спорю о бриджах.

>Как я и утверждал ранее Ваш вариант относится к "древний бриджинг, совершенно
>нефункциональный и неудобный"

На здоровье, мне нужен был только ipfw, потому я отказался от ng_bridge в пользу bridge
Никакой другой функционал ведь не нужен был, статья-то - не ман, а опыт конкретного эксперемента, удачно, между прочим, завершившегося, о чем и статья.

7.18, chip (??), 23:56, 27/06/2006 [^] [^^] [^^^] [ответить]

+/–

>if_bridge я не использовал, потому что man if_bridge не существуется, я
>воспользовался тем, что нашел.

"man if_bridge не существуется"

Подразумевалось не существует? http://www.freebsd.org/cgi/man.cgi?query=if_bridge&apropos=0&sektion=0&manpat

ps: я не упрямлюсь, а лишь говорю о том что описанный _ВАМИ_ подход является как раз устаревшим. Неоправданно хаять чужой подход...

8.19, Bocha (ok), 11:49, 28/06/2006 [^] [^^] [^^^] [ответить]	+/–
Да, подразумевалось не существует конечно же Спасибо за ссылку Хорошо, bridg... текст свёрнут, показать