QEmu и настройка сети

Наконец-то мне удалось настроить сеть. Сейчас я расскажу, каким образом это у меня получилось.

Во-первых, я решил включить виртуальную машину в реальную локальную Ethernet-сеть, объединив мостом tap-интерфейс и eth-интерфейс. Для настройки сетевого интерфейса и мостового объединения интерфейсов нам понадобятся два пакета - соответственно uml-utilities и bridge-utils. Установим их с помощью команды:

# aptitude install uml-utilities bridge-utils

Загрузим в ядро модули bridge и tun:

# modprobe bridge
# modprobe tun

В принципе подгружать эти модули совсем не обязательно, т.к. они автоматически будут загружены командами brctl и tunctl при необходимости. Тем не менее, я таким образом просто решил заранее удостовериться, что возможные дальнейшие ошибки не связаны с отсутствием модулей или невозможностью загрузить их в ядро.

Теперь отредактируем правила демона udev. При настройке эмулятора qemu я добавил в систему группу kqemu и дал ей права на доступ к устройству /dev/kqemu, создаваемому модулем ядра kqemu для более быстрой эмуляции виртуальной машины. Теперь нужно дать права на запись в устройство /dev/net/tun группе kqemu. Нужное нам правило находится в файле /etc/udev/rules.d/91-permissions.rules, в нём необходимо заменить строчку

KERNEL=="tun",                  MODE="0666"

на строчку

KERNEL=="tun",                  MODE="0660",    GROUP="kqemu"

Затем нужно перезапустить udev, чтобы внесённые изменения вступили в силу:

# /etc/init.d/udev restart

По непонятным причинам это не оказало действия на устройство и я остановил и запустил udev снова, на сей раз отдельными командами:

# /etc/init.d/udev stop
# /etc/init.d/udev start

Теперь займёмся настройкой моста и сетевого интерфейса, в файле /etc/network/interfaces пропишем настройку моста br0 и виртуального интерфейса tap0:

auto tap0
iface tap0 inet static
  up ifconfig tap0 up
  down ifconfig tap0 down
  tunctl_user stupin

auto br0
iface br0 inet dhcp
  bridge_ports eth1 tap0
  bridge_fd 9
  bridge_hello 2
  bridge_maxage 12
  bridge_stp off

Строчка tunctl_user указывает имя пользователя, которому будет принадлежать этот интерфейс.

Теперь перезапустим настройку сети:

# /etc/init.d/networking restart

Если посмотреть список активных интерфейсов с помощью команды ifconfig, то можно увидеть 4 интерфейса: локальный петлевой интерфейс lo, интерфейс моста br0, получивший сетевые настройки по DHCP и два ненастроенных интерфейса: eth1 и tap0. eth1 соответствует реальной сетевой карте, а tap0 - виртуальному Ethernet-интерфейсу.

Теперь можно запустить виртуальную машину и настроить в ней сеть. К сожалению с помощью QEmulator'а нужные настройки через меню задать не получается, но зато можно воспользоваться, например, такой командой:

$ qemu -M pc -m 128 -no-kqemu -no-acpi -hda /home/stupin/netbsd-disk.bin -net nic,vlan=0 -net tap,vlan=0,ifname=tap0 -boot c

Фактически я скопировал её из QEmulator'а и подправил опции для второго сетевого интерфейса, указав имя интерфейса, с которым должна быть связана виртуальная машина.

В виртуальной машине указываем получение настроек сетевого интерфейса по DHCP. Поскольку у меня в локальной сети настроен DHCP-сервер, я сразу же смог выйти в виртуальной машине в сеть.

При перезагрузке всплыли кое-какие проблемы. Система запускает с помощью сценария /etc/init.d/uml-utilities некий uml-switch. Сначала я подумал, что именно этот uml-switch заменяет группу-владельца устройства /dev/net/tun на группу uml-net, в результате чего запущенная виртуальная машина не может получить доступ к устройству и сеть не работает.

Тут можно было поступить несколькими способами. Во-первых, можно включить себя в группу uml-net, тогда проблема будет обойдена. Во-вторых, можно поменять группу-владельца в файле /etc/default/uml-utilities, указав нужную в переменной UML_SWITCH_USER. И наконец, можно просто отключить uml-switch, указав в переменной UML_SWITCH_START значение false. Я выбрал именно последний способ, поскольку я даже не знаю что такое uml-switch, то он мне вряд-ли нужен. Однако и это не повлияло на групповую принадлежность устройства /dev/net/tun!

Я был озадачен и лучшая мысль, которая пришла мне в голову - это прогрепать каталог /etc/ на упоминание слова tun. И поиск дал результат. В файле /etc/network/if-pre-up.d/uml-utilities обнаруились такие строчки:

#
# why the hell does this need to be done?
#
chown root:uml-net /dev/net/tun
chmod 660 /dev/net/tun

Действительно, какого чёрта это необходимо делать? Я потратил уйму времени на правильную настройку, а тут какой-то умник соорудил костыль, из-за которого у меня ничего не работает! Сносим эти строчки и пробуем перезагрузить машину снова. На этот раз после перезагрузки всё окончательно наладилось.

Обновлено 23 апреля 2009 года.

Эмуляторы VirtualBox и QEmu в Debian

Решил посмотреть на DragonFly BSD 2.2 и файловую систему Hammer. А для этого соответственно нужен компьютер. Запускать на настольном компе не хотелось, т.к. для этого пришлось бы отказаться от привычной "рабочей" среды. Поэтому я решил запустить DragonFly в эмуляторе - так и привычная среда останется на месте и смотреть на систему можно будет долго и внимательно :)

Решил попробовать два эмулятора - VirtualBox и QEmu.

Для начала решил поставить VirtualBox. Среда нормально запускалась, но эмулировать отказывалась наотрез - не признавала версию своего модуля ядра vboxdrv. Пробовал устанавливать пакет с модулем, собранным специально для моего ядра, но VirtualBox не хотел признавать и его.

Затем решил поставить QEmu. QEmu нормально запустился, всё-таки сообщив о том, что он не может получить доступ к устройству /dev/kqemu. Это устройство создаётся модулем ядра и позволяет существенно ускорить скорость эмуляции: этот модуль позволяет выполнять инструкции эмулируемого процессора непосредственно на реальном процессоре.

Собрать модуль kqemu мне тоже не удалось, компилятор ругался на отсутствие регистров rax и т.п. Это регистры 64-битного процессора. Не смотря на то, что я пользуюсь 32-битной системой, у меня установлено ядро linux-image-2.26-1-amd64, заточенное на 64-битный процессор. Соответственно для 64-битного ядра нужно собирать 64-битный модуль, а компилятор наотрез отказывался признавать существование 64-битных процессоров, поскольку сам был заточен на 32-битную среду.

Ну что ж, подумал я, копаться с компиляцией я не стану - это непроизводительная трата времени. И решил поставить ядро linux-image-2.26-1-686. После перезагрузки в новое ядро, как и ожидалось, у меня отвалился модуль nvidia. Я соответственно залогинился в консоли под root'ом и решил его восстановить, заодно установив и модуль kqemu:

# aptitude install module-assistant
# m-a a-i nvidia
# m-a a-i kqemu

Дальше я перезапустил kdm:

# /etc/init.d/kdm restart

И вошёл в KDE.

Теперь я решил вновь установить VirtualBox с модулями для нового ядра:

# aptitude install virtualbox-ose-modules-2.6.26-1-686 virtualbox-ose

Дальше нужно загрузить модуль ядра vboxdrv. Чтобы он сразу создал устройство /dev/vboxdrv с нужными правами доступа, перезапустим udev. Пакет добавил к udev новые правила и нужно, чтобы они вступили в силу:

# /etc/init.d/udev restart

Теперь подгрузим ядро и посмотрим права доступа к устройству /dev/vboxdrv:

# modprobe vboxdrv
# ls -la /dev/vboxdrv

Видим, что право доступа имеют пользователь root и группа vboxusers. Добавим себя в группу vboxusers (с сделал это с помощью vi):

# vi /etc/group

Теперь, чтобы получить права группы, в которую мы себя добавили, нужно перелогиниться. Я вышел и вошёл в KDE.
Запускаем VirtualBox OSE - графический интерфейс программы показался мне сильно похожим на Virtual PC, в котором я года два назад по необходимости запускал Windows 98.
Ниже - скриншот основного экрана программы с созданной виртуальной машиной DragonFly BSD.

К сожалению, практически сразу после загрузки с образа диска, система зависала и продолжала отъедать 70-99% процессорного времени компьютера, не подавая никаких признаков жизни:

Окно с изображением экрана эмулируемой системы захватывает клавиатуру. Чтобы эмулируемая система "отпустила" клавиатуру, нужно нажать комбинацию клавиш, указанную в строке статуса окна в правом нижнем углу, у меня это была правая клавиша Ctrl.

Никакие попытки поменять настройки эмулируемой машины не дали результата и загрузка системы неизбежно застывала на одном и том же месте. Попытки загрузить DragonFly BSD в безопасном режиме или режиме без поддержки ACPI результатов тоже не принесли.

Далее я решил попробовать QEmu. Система уже до этого зарекомендовала себя положительным образом, правда без поддержки эмуляции на уровне ядра системы. Именно поэтому я и решил попробовать VirtualBox, но он меня разочаровал, о чём и написано выше.

Итак, приведём в чувство установленный только что модуль kqemu. Во-первых, пакет с модулем kqemu тоже добавляет правило к udev, поэтому если вы не перезапустили udev при установке VirtualBox, сделайте это сейчас:

# /etc/init.d/udev restart

Подгрузим новый модуль ядра и посмотрим на права доступа к устройству:

# modprobe kqemu
# ls -la /dev/kqemu

Правила udev предписывают давать доступ на чтение и запись в это устройство любым пользователям системы. Если вы не хотите, чтобы это было так, можете создать группу для пользователей qemu и дать права доступа к устройству только им. Эти правила находятся в файле /etc/udev/rules.d/91-permissions.rules. Строчку:

KERNEL=="kqemu",                MODE="0666"

Можно заменить на такую:

KERNEL=="kqemu",                MODE="0660",                GROUP="kqemu"

Затем добавить в систему группу kqemu, перезапустить udev и перезагрузить модуль kqemu:

# groupadd kqemu
# /etc/init.d/udev restart
# rmmod kqemu
# modprobe kqemu

Теперь можете добавить себя в только что созданную группу и перелогиниться.

Чтобы модуль kqemu загружался вместе с системой автоматически, его загрузку можно прописать в файле /etc/modules.

Продолжим установку qemu:

# aptitude install qemu

Теперь создадим файл размером 1 гигабайт, который будет использоваться в качестве образа диска эмулируемой системы. Для этого я воспользовался командой dd (официальная документация qemu рекомендует создавать образ дисков с помощью утилиты qemu-img):

# dd if=/dev/zero /home/stupin/dfbsd-disk.bin bs=1M count=1024

Запустить новую виртуальную машину можно таким образом:

$ qemu -cdrom /home/stupin/dfbsd-2.2.0_REL.iso -hda /home/stupin/dfbsd-disk.bin -boot d

Последняя опция указывает произвести загрузку с образа компакт-диска. Окно эмулируемой системы захватывает клавиатуру, отключить захват можно с помощью одновременного нажатия клавиш Ctrl и Alt (когда клавиатура захвачена, эта комбинация клавиш высвечивается в заголовке окна).

QEmu на удивление легко преодолел рубеж загрузки, на котором останавливался VirtualBox и я установил систему на виртуальный диск. С настройкой сети я пока не заморачивался, хотя без неё как без воздуха, разобраться с настройкой и настроить всё равно придётся. Кроме всего прочего, QEmu производит впечатление количеством эмулируемых архитектур (x86, x86_64, Sparc32, Sparc64, PowerPC, ARM, MIPS - в том числе поддерживается эмуляция одного процессора на другом) и возможностями проброса вовнутрь эмулируемой системы USB-устройств реального компьютера, возможностью создания снимков системы (все изменения, которые система будет производить с диском будут записываться в отдельный файл снимка, так что систему легко можно откатить до прежнего состояния), эмуляцией последовательный устройств ввода/вывода, эмуляции графических и сетевых адаптеров разных моделей.

Также в репозитории Debian я нашёл два графических интерфейса для запуска QEmu: qemu-launcher и qemulator.

Первый запускался и показывал окно с настройками, но образы виртуальных машин запускать отказывался:

Второй же оказался довольно приятным и вполне рабочим:

С помощью него я легко запустил ранее созданную с помощью консольной версии эмулятора виртуальную машину:

Дело осталось за немногим - разобраться с настройкой сети и можно будет пощупать Hammer.

Ссылки:

1. Документация пользователя эмулятора процессора QEMU - перевод документации на русский язык, датированный 2006 годом. Описанного там вполне достаточно, чтобы понять что из себя представляет qemu и начать им пользоваться.
2. QEMU - Debian - Linux - TUN/TAP - network bridge - документация по настройке сети. Её я изучу попозже и поподробнее.