Месяц назад начал опыты над запуском виндовс в эмуляторе qemu.
В принципе, добился достаточно большой производительности гостевой системы, но после смены ядра и пересборки модуля kqemu, счастье кончилось.Опыты провожу на ubuntu 7.10, все приложения и ядра беру из репозитория, так как делаю не вешь в себе, а решение с возможностьбю технической поддержки.
Есть ли идеи, что сделать, что бы добиться былой стабильности и производительности?
Откатиться до былого состояния?
>Откатиться до былого состояния?Нет, не могу. Из-за необходимости держать всё обновлённым.
Но обнаружил следующую закономерность:
- если запускать виндовс и он начнет сервисы свои по одному дёргать, машина перезагрузится
- если при загрузке убрать ключ -kernel-kqemu и дать загрузиться, всё будет работать, но чуть медленнее
- если сделать в гостевой машине hibernate, включать ее можно уже и с -kernel-kqemu
- очень прикольно из хибернейта выходить с уже включенным -snapshot - гостевую машину больше никогда не придется переустанавливать для повышения производительности. :)
- с включенным -kernel-kqemu не всегда работает HASP
- иногда HASP не успевает присоединиться к гостевой машине, что не удобно и требует вмешательства
- для гарантированной передачи гостевой машине ключа HASP, делаю -usbdevice host:1234:5678 два раза. Если выскочит два аппаратных ключа, моё приложение не ругается.
- очень удобно запускать гостевую машину так:
# screen -d -m \
qemu -kernel-kqemu -snapshot \
-vnc :0 -monitor stdio \
-usb -usbdevice host:1234:5678 -usbdevice host:1234:5678 \
-parallel /dev/parport0 \
-hda hda.img -localtime \
-net nic,model=rtl8139,macaddr=00:E0:4C:57:16:05,script=/etc/qemu-ifup -net tap
$ cat /etc/qemu-ifup
#!/bin/sh
echo "Executing /etc/qemu-ifup"
echo "Bringing up $1 for bridged mode..."
sudo /sbin/ifconfig $1 0.0.0.0 promisc up
echo "Adding $1 to br0..."
sudo /usr/sbin/brctl addif br0 $1
sleep 2Для труЪ безопасности можно поиграть с правами при создании устройств /dev/kqemu, /dev/net/* и устройств usb, а так же iptables.
Если есть идеи, как это сделать получше, буду только рад прочесть и сделать так же.
Кстати, в более новой ubuntu есть более новый qemu, который дает возможность использовать не только конструкции -hda hda.img, но и более интересные: выбор типа шины, отношение тома к ключу -snapshot, возможность монтировать каталоги как диски. Это всё описано в официальной документации более подробно и с примерами.
У меня qemu с виндой работает очень стабильно. uptime по полгода (был бы больше, но я иногда просто выключаю машину, чтобы за столом пропылесосить :-)). залог этой устойчивости я вижу в том, что у меня отключена вся перефирия: usb, принтер... даже сетка сделана за натом. на локальной машне поднят ftp и обмен с машиной идёт только по этому ftp. вместо vnc я использую rdesktop; он ещё и позволяет рашаривать буфер обмена, что очень удобно. рецепты по настройке я взял вот отсюда: http://michurin.com.ru/qemu.shtml (NAT-вариант)да! и использовал -win2k-hack
кроме того, может у вас не хватает памяти? -m 512 это минимум для винды.
>кроме того, может у вас не хватает памяти? -m 512 это минимум
>для винды.Памяти я правда поставил виртуальной машине мало - 160Мб, но она наполовину свободна! Я отконфигурировал систему так, что в ней нет ни одного ненужного мне включенного сервиса.
Более того, приложения перед хибернейтом загружал, пользовал и закрывал, что дает прирост при запуске приложений снова.Но проблема была заметной невооруженным глазом - элементы интерфейса программы при перерисовывании были видны то контурами, то с заливкой, то не успевшие растянуться, а потом угадывающие как им растянуться. На живой машине такого просто не заметить. И самое зло - HASP в qemu машине с ключем -kernel-kqemu перестает работать нормально. Во всяком случае, приложению плохеет. А без -kernel-kqemu (но при загруженном модуле) всё страшно тормозит, как описано выше. Но программа работает. :(
ubuntu 7.10, qemu 0.9.0, kqemu
Пользовался qemu на slackware 11 - было достаточно стабильно.
Сейчас на Slackware 12 собирается через ж и работает с ядром поновее нестабильно.
Кстати как Вы с ядром новее 2.6.17 не из под рута поднимаете tap интерфейсы?
Мне например qemu запущенная под рутом не нужна.
>Кстати как Вы с ядром новее 2.6.17 не из под рута поднимаете
>tap интерфейсы?
>Мне например qemu запущенная под рутом не нужна.$ cat /etc/qemu-ifup
#!/bin/sh
echo "Executing /etc/qemu-ifup"
echo "Bringing up $1 for bridged mode..."
sudo /sbin/ifconfig $1 0.0.0.0 promisc up
echo "Adding $1 to br0..."
sudo /usr/sbin/brctl addif br0 $1
sleep 2Понимаю, что можно это делать несколько иначе, но не задавался идеей это переделывать.
>[оверквотинг удален]
>#!/bin/sh
>echo "Executing /etc/qemu-ifup"
>echo "Bringing up $1 for bridged mode..."
>sudo /sbin/ifconfig $1 0.0.0.0 promisc up
>echo "Adding $1 to br0..."
>sudo /usr/sbin/brctl addif br0 $1
>sleep 2
>
>Понимаю, что можно это делать несколько иначе, но не задавался идеей это
>переделывать.Это у меня аналогично. Но перед запуском приходится sudo /usr/sbin/tunctl -u user -t tapx
$ cat /etc/network/interfaces
auto lo
iface lo inet loopbackauto br0
iface br0 inet static
address 10.0.0.123
netmask 255.255.255.0
network 10.0.0.0
broadcast 10.0.0.255
gateway 10.0.0.1bridge_ports eth0
bridge_fd 1
bridge_hello 1
bridge_stp offУ меня этот бридж сам подымается. Даже если не пользуюсь qemu.
Кстати, у eth0, который в бридже, у него основной адрес иногда не 10.0.0.123 (получаю по dhcp). Работает, так что не переделываю.А еще есть совет. Если виртуальным машинам давать свои собственные MAC-адреса, их можно культурно фильтровать на соответствующем уровне сетевых протоколов утилитой ebtables. Эта утилита имеет схожий с iptables синтаксис.
Подробнее на xgu.ru