Пермская группа пользователей Linux

Доброго времени суток. Вечер. 31 декабря 2008 года. Чем заняться человеку в такое время? Правильно! Начать писать статью на permlug, чтобы поделиться опытом. :)

Цели данной статьи - рассмотреть особенности установки, настройки и использования qemu в операционных системах windows и linux, реализовать возможность работы виртуальных машин с существующей сетью на канальном уровне и их быстрое дублирование.

Часть 1. Настройка под Windows (на примере Windows 2003 SP2).

Преамбула: на работе стоял в стойке двухюнитовый сервер HP ML380 с четырнадцатью гигабайтами памяти и восемью SCSI дисками общим объёмом чуть менее терабайта. На этом сервере были размещены расшаренные папки всей организации и внушительное количество всяческого хлама - дистрибутивы, драйвера и т.д.. В качестве операционной системы на сервере использовалась Windows 2003 SP2. После установки snmp и мониторинга на протяжении недели, были получены следующие результаты: средняя загрузка памяти - 1,6%, загрузка процессоров не поднималась выше трёх процентов, причём гигабитным портом сервер был подключен к стомегабитному порту коммутатора, так как свободных гигабитных портов больше не было, из чего следовал совершенно очевидный вывод о неэффективности использования данного сервера. В то же время, на работе постоянно не хватало машин, на которых можно было бы что-то потестировать, опробовать и проверить, поэтому мной было принято решение устроить серверу "размножение личности", благо, вычислительных ресурсов у него на это хватает с лихвой. Был проведён разговор с начальством и получено "добро" на использование сервера в своих целях при условии, что это не помешает пользователям работать с расшаренными ресурсами, так как перенести этот объём информации просто некуда. При помощи утилиты SequoiaView (аналог встроенной в Konqueror FSView), в папках пользователей среди документов было обнаружено внушительное количество музыки, фильмов, и прочей подобной информации, которая к делу не относится. Проведя разъяснительную беседу с рядом пользователей, Было освобождено определённое необходимое пространство на рейд массиве.

Итак, приступаем к боевым действиям.

Какой эмулятор выбрать? Все вокруг пользуются VmWare или же, VirtualBox'ом, но я всеми силами стараюсь поддерживать GPL и предпочитаю открытый софт, нежели просто Freeware, даже если работа с ним окажется несколько сложнее. Поэтому для меня вопрос был решён изначально. Я выбрал qemu. Но пользоваться qemu из командной строки не всегда удобно. Скажем, если на виртуальный хост поставлена w2k3, то для того, чтобы авторизоваться в системе, надо послать ей Ctrl+Alt+Del, но это сочетание клавиш перехватывает хост-система. Поэтому нам желательно использовать некую оболочку, которая будет выполнять эти и ряд других функций, например, возможность поставить систему на "паузу" или сохранить её состояние. Под windows выбор был не так велик и в конце-концов, я остановился на Qemu Manager (http://www.davereyn.co.uk/). Есть вариант для установки и есть zip архив, который можно распаковать и носить с собой на флешке, например. При установке или первом запуске лучше включить инсталляцию kqemu, это позволит несколько ускорить работу эмулятора.
На возможностях программы я особо останавливаться не буду, всё просто и очевидно. Главный вопрос, с которым мне пришлось столкнуться - как вывести машины в сеть. Дело в том, что при обилии подобной информации для *nix систем, наблюдался явный её недостаток для систем семейства windows.

Общий принцип - для того, чтобы виртуальная машина могла общаться по сети с хост машиной, нужен так называемый tap интерфейс (Traffic Accounting Protocol). Но w2k3 в своём составе не имеет средств для создания tap интерфейсов и придётся поставить эти средства отдельно. Для этого нам понадобится дистрибутив OpenVPN, который можно найти тут: http://openvpn.net/index.php/downloads.html. OpenVPN так же является свободной разработкой, о чём гласит надпись на их сайте "OpenVPN is Free Software released under the GNU/GPL License." При установке мы должны выбрать только TAP-Win32 Virtual Ethernet Adapter, убрав все остальные галочки. На вопросы о совместимости оборудования отвечаем "Всё равно продолжить". После окончания установки у нас появится новый сетевой интерфейс. Если windows руссифицирована, то интерфейс будет назван "Подключение по локальной сети" + некий порядковый номер. Заходим в Панель управления > Сеть и подключения к Интернету > Сетевые подключения. Там видим ещё одно подключение (сетевой кабель не подключен). Подводим к нему мышь и во всплывающей подсказке мы должны увидеть что-то вроде TAP-Win32 Adapter V8. Нажимаем правой кнопкой мыши и выбираем пункт "Переименовать", после чего даём нашему тап интерфейсу для определённости имя tap0. Затем в Qemu Manager нажимаем на иконку с красным плюсом, вводим имя машины, задаём количество памяти и размер жётского диска. После чего нажимаем кнопку с надписью Create, переходим на вкадку Networking в правой части окна, дважды кликаем на строку VLAN0 User Networking и в выпадающем меню Network Type выбираем пункт Tap Networking. В появившейся строке VLAN0 Tap ID вводим имя нашего tap интерфейса. В данном случае tap0. Теперь необходимо объёдинить его с физическим интерфейсом. Заходим в Сетевые подключения, одиночным щелчком выделяем наш tap интерфейс и удерживая Ctrl выделяем физический интерфейс, потом на одном из них нажимаем правой кнопкой мыши и выбираем пункт "Подключение типа мост". Всё, наша виртуальная машина будет использовать нашу реальную сетевую карту для общения с сетью. В отличие от юникса, нам понадобится две сетевых карты. Одна - для хост системы, другая для виртуальных машин. Так же, нам надо заранее создать столько tap интерфейсов, сколько виртуальных машин предполагается держать включенными одновременно. Добавить новый tap интерфейс можно запустив скрипт C:\Program Files\OpenVPN\bin\addtap.bat, после чего его нужно будет по аналогии переименовать в tap1. Привязать его к мосту можно в свойствах моста, просто отметив галочкой.

Часть 2. Настройка под linux (на примере Ubuntu 8.10).

Машина, на которой проводились эксперименты имела следующую конфигурацию: AMD Sempron(tm) Processor 3000+ 64 (1,6Mhz)/8Гб/2x640Гб. Пусть Вас не пугает конфигурация, для эмуляции должно хватить и меньших ресурсов.

Итак, что нам необходимо - возможность запускать виртуальные машины, используя те же образы жёстких дисков, что и под win, которые находились бы в той же сети, что и наша машина, другими словами, реализовать то же самое, что мы уже рассмотрели выше, только средствами linux.
Сейчас моя машина работает под 64-х битной Ubuntu 8.10.
Для начала нужно установить два пакета - quemu и qemuctl, которые есть практически в любом дистрибутиве.
Под дистрибутивами, основанными на debian это можно сделать, дав комманду sudo apt-get install qemu qemuctl.
Первый из пакетов - это собственно сам эмулятор, второй - средство для управления им, которое потребуется нам например в случае необходимости быстро послать эмулятору Ctrl+Alt+Del. Синтаксис параметров запуска qemuctl полностью совпадает с таковым для qemu.

Предположим, образ жёсткого диска для виртуальной машины называется disk.dsk и лежит в директории, из которой происходит запуск и мы хотим выделить машине 256 мегабайт оперативной памяти. Команда будет выглядеть так:

qemuctl -hda disk.dsk -m 256

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

Если же по каким-то причинам Вы не хотите использовать qemuctl, то в принципе можно обойтись и средствами самой qemu, но это будет менее удобно. Находясь в окне эмулятора, нажмите сочетание клавиш Ctrl-Alt-2. Заметьте - именно "2", а не "F2". Перед Вами появится консоль управления эмулятором.

QEMU 0.9.1 monitor - type 'help' for more information
(qemu)

Для того, чтобы послать эмулятору сочетание клавиш Ctrl-Alt-Del, нужно набрать:

sendkey ctrl-alt-delete

Более подробную справку можно получить, набрав слово help.

По нажатию Ctrl-Alt-F можно перевести qemu в полноэкранный режим.

Теперь вернёмся к вопросам работы с сетью. Сразу оговорюсь, что данный способ несколько отличается от тех, что мне довелось видеть в сети.

Нам нужно создать так называемый мост (объединение интерфейсов на канальном уровне), после чего для каждой виртуальной машины создавать виртуальный tap интерфейс и объединять его с мостом. В отличие от windows, где нам приходилось создавать для каждой виртуальной машины новый tap интерфейс от имени администратора, в linux есть возможность этот процесс автоматизировать и создавать tap интерфейсы автоматически для каждой новой виртуальной машины, а после завершения её работы удалять соответствующий интерфейс. Конечно, для этих действий так же необходимы права супер пользователя, но мы решим эту проблему при помощи sudo. Далее необходимо будет произвести ряд действий от имени суперпользователя, поэтому можно воспользоваться командами sudo -s либо su -.

Сначала установим пакет bridge-utils, который позволит нам работать с соединениями типа мост.

apt-get install bridge-utils

Ещё в нашей системе должны иметься средства для работы с tun/tap интерфейсами. Обычно это tunctl, но в моей системе (ubuntu 8.10) он почему-то назывался vde_tunctl. Вы можете это проверить следующим образом:

locate tunctl
/usr/bin/vde_tunctl
/usr/share/man/man8/vde_tunctl.8.gz

В случае, если у Вас этот исполняемый файл называется tunctl, укажите его в скриптах вместо vde_tunctl.

Далее нам необходимо создать мост. Делается это примерно следующим образом:

Сначала наш физический интерфейс должен быть поднят без адреса

ifconfig eth0 down
ifconfig eth0 0.0.0.0 up

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

brctl addbr br0
brctl addif br0 eth0

ifconfig br0 192.168.1.1 up

либо если машина получает адрес через DHCP

ifconfig br0 up
dhclient br0

В debian-based дистрибутивах настройки интерфейсов находятся в файле /etc/network/interfaces. Если мы рассчитываем работать с виртуальными машинами постоянно, то будет целесообразно внести настройки в него, чтобы они остались после перезагрузки системы.

Для определённости возьмём тот же пример, когда интерфейс сетевой карты называется eth0 и имеет адрес 192.168.1.1 или получает его посредством обращения к DHCP. Тогда содержимое файла /etc/network/interfaces будет примерно следующим:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.1.1
netmask 255.255.255.0

в случае, если ip адрес был задан статически или

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

если адрес был получен посредством DHCP.

Вот на что мы должны заменить содержимое:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 0.0.0.0

auto br0
iface br0 inet static
address 192.168.1.1
netmask 255.255.255.0
bridge_ports eth0
bridge_fd 9
bridge_hello 2
bridge_maxage 12
bridge_stp off

либо в случае с DHCP

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 0.0.0.0

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

Теперь у нас есть мост, к которому мы можем добавлять любые интерфейсы в нашей системе. Для добавления и удаления tap интерфейсов мы напишем пару скриптов, которые будут выполняться до старта виртуальной машины и после окончания её работы.

Я обычно использую в своей работе vim, Вы можете воспользоваться тем, что привычнее Вам, скажем, nano или mcedit. Следующая комманда откроет текстовый редактор и после сохранения создаст файл /usr/sbin/tapup:

vim /usr/sbin/tapup

Ниже содержимое скрипта:

#!/bin/sh

#Script for creating new tap interface and appending it to the existing bridge
#Usage: tapup [ UID_of_interface_owner ]
#(c) Evgeniy Shumilov (corpse@permlug.org)

if [ -n "$1" ]; then

if [ -n "$2" ]; then
iface=$( vde_tunctl -b -u $2 )
else
iface=$( vde_tunctl -b )
fi

chown root:qemu /dev/net/tun
/sbin/ifconfig $iface 0.0.0.0 promisc up
brctl addif $1 $iface
echo $iface
sleep 2

fi

Скрипт вызывается с двумя параметрами, первый из которых - имя интерфейса нашего моста, в нашем случае, это br0, а второй - имя пользователя, который будет владельцем созданного интерфейса и сможет впоследствии с ним работать. Например вызов /usr/sbin/tapup br0 user создаст tap интерфейс tap0, владельцем которого будет user и привяжет его к мосту br0. При повторном вызове будет создан интерфейс с именем tap1, при следующем - tap2 и т.д.. Первый параметр является обязательным, а второй можно опустить. При этом владельцем интерфейса будет root. C испоьзованием этого скрипта можно будет привязывать tap интерфейсы к различным мостам, что довольно удобно, если наша машина имеет несколько сетевых карт или несколько vlan интерфейсов, естесственно, для этой возможности каждый из них должен входить в состав какого-нибудь моста. При успешном выполнении скрипт выдаёт имя созданного интерфейса, нам это будет нужно.

Движемся далее. Создадим скрипт для удаления существующего интерфейса.

vim /usr/sbin/tapdown

Его содержимое:

#!/bin/sh

#Script to negate tap interface
#Usage: tapdown

if [ -n "$1" ]; then
vde_tunctl -d $1
fi

Здесь всё просто. tap интерфейс удаляется по имени, имя - это единственный и обязательный параметр. Не забудьте изменить vde_tunctl на tunctl, если он называется так в Вашей системе.

Теперь создадим группу, которая будет иметь право работать с qemu.

addgroup qemu

Перейдём в папку /usr/sbin и изменим владельца и права на наши скрипты:

cd /usr/sbin/
chown root:qemu tapup tapdown
chmod 750 tapup tapdown
chmod +s tapup tapdown

Проверяем, что получилось

ll tap*
-rwxr-x--- 1 root qemu 125 2009-01-01 16:00 tapdown
-rwxr-x--- 1 root qemu 403 2009-01-01 15:45 tapup

Редактируем файл /etc/sudoers и добавляем в него следующие строки:

%qemu ALL=NOPASSWD:/usr/sbin/tapup *
%qemu ALL=NOPASSWD:/usr/sbin/tapdown *

Теперь добавляем пользователя, которому нужно будет работать с виртуальными машинами в группу qemu:

adduser user qemu

Теперь, если Вы внесли изменения в /etc/network/interfaces, необходимо перезапустить службу

/etc/init.d/networking restart

Проверяем, что получилось:

ifconfig
br0 Link encap:Ethernet HWaddr 00:11:22:33:44:55
inet addr:192.168.1.8 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::21b:fcff:fe8c:a2a6/64 Диапазон:Ссылка
ВВЕРХ BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:134759 errors:0 dropped:0 overruns:0 frame:0
TX packets:72278 errors:0 dropped:0 overruns:0 carrier:0
коллизии:0 txqueuelen:0
RX bytes:174331133 (174.3 MB) TX bytes:6743605 (6.7 MB)

eth0 Link encap:Ethernet HWaddr 00:11:22:33:44:55
inet6 addr: fe80::21b:fcff:fe8c:a2a6/64 Диапазон:Ссылка
ВВЕРХ BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:134763 errors:0 dropped:0 overruns:0 frame:0
TX packets:72284 errors:0 dropped:0 overruns:0 carrier:0
коллизии:0 txqueuelen:1000
RX bytes:176221131 (176.2 MB) TX bytes:7036251 (7.0 MB)
Прервано:252 Base address:0x2000

lo Link encap:Локальная петля (Loopback)
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Диапазон:Узел
ВВЕРХ LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:37 errors:0 dropped:0 overruns:0 frame:0
TX packets:37 errors:0 dropped:0 overruns:0 carrier:0
коллизии:0 txqueuelen:0
RX bytes:2876 (2.8 KB) TX bytes:2876 (2.8 KB)

Затем входим под логином пользователя user, желательно это сделать не в иксах, а в одной из консолей, которые доступны по сочетанию клавиш Ctrl+Alt+F1 - Ctrl+Alt+F6 и проверяем, как работают наши скрипты:

sudo /usr/sbin/tapup br0 user
tap0

sudo /usr/sbin/tapdown tap0
Set 'tap0' nonpersistent

Всё замечательно. Пользователи, входящие в группу qemu ограничены в правах для работы с tunctl (vde_tunctl) и brctl напрямую, но имеют возможность работать с мостами и tap интерфейсами в той мере, в которой это необходимо для вывода в сеть виртуальных машин.

Теперь нам нужно ещё два скрипта. qemu, во всяком случае тот, что находится в репозитории ubuntu 8.10 при старте сети с поддеркой tap интерфейса выполняет скрипт /etc/qemu-ifup, без которого виртуальная машина просто не запустится. Поэтому на его место мы выложим заглушку - скрипт, который ничего не делает.

echo "#!/bin/sh" > /etc/qemu-ifup

При завершении работы тоже должен исполняться скрипт - /etc/qemu-ifdown, но при его отсутствии в поток ошибок, который при старте скрипта запуска не из консоли Вы просто не увидите, может выдаваться ошибка. Думаю, это не существенно.

Теперь всё готово. Пишем последний скрипт, который будет запускать нашу виртуальную машину.

#!/bin/bash

IFACE=$(sudo /usr/sbin/tapup br0 user )
qemuctl -m 256 -net nic -net tap,ifname=$IFACE -hda disk.dsk
sudo /usr/sbin/tapdown $IFACE

Теперь если на стороне виртуальной машины при настройке сети указать ip адрес из того же диапазона, что и на хост-машине, то они смогут друг-друга видеть.

Мои виртуальные машины получают статические ip адреса посредством DHCP, поэтому сделав необходимые записи в конфигурационных файлах DHCP сервера и запуская виртуальную машину с указанием mac адреса сетевой карты, можно управлять тем, какой ip адрес она получит. Можно выделить для виртуальных машин отдельный диапазон адресов. Например, наш DHCP сервер может выдавать машине с mac адресом 00:00:00:00:00:01 ip адрес 192.168.1.101, машине с mac адресом 00:00:00:00:00:02 ip адрес 192.168.1.102 и так далее. Строка скрипта для запуска виртуальной машины с указанием mac адреса будет выглядеть так:

qemuctl -m 256 -net nic,macaddr=00:00:00:00:00:01 -net tap,ifname=$IFACE -hda disk.dsk

Пойдя несколько дальше, можно сделать соответствующие записи в конфигурационных файлах DNS сервера. Например, в моей сети виртуальная машина с ip адресом 192.168.1.101 получает доменное имя virt1, машина с адресом 192.168.1.102 - virt2 и так далее. Таким образом можно легко избежать путаницы и на порядок облегчить себе дальнейшую работу.
После установки sshd сервера на эмулируемую linux машину, лучше работать с виртуальным хостом по ssh протоколу, отключив графический вывод qemu, по моим наблюдениям, это несколько снижает нагрузку на CPU, притом, у Вас появится возможность использовать буфер обмена для копирования/вставки информации между виртуальной и реальной машиной, что может быть крайне полезным при редактировании конфигурационных файлов. Графический вывод qemu можно отключить, добавив к строке запуска директиву "-nographic". Кстати, таким образом можно запускать виртуальные машины и при отсутствии графического окружения, скажем, на сервере так называемые "иксы" скорее всего будут отсутствовать как класс.

Часть 3. Подводные камни или трудности, с которыми придётся столкнуться.

1. Проблемы с RDP.

Если доступ к серверу, на котором запускается Qemu Вы получаете через RDP, то возможны проблемы при работе с мышью - довольно сложно добиться точного перемещения курсора в окне эмулятора, его перемещение происходит несоразмерно перемещению мыши, другими словами, работать практически невозможно, в то время как вне окна qemu проблем с позиционированием курсора нет. Проблема решается настройкой доступа через RDP на самой виртуальной машине.
При использовании для доступа к серверу VNC (TightVNC 1.3.9), проблемы не было, но VNC для меня по ряду причин не подходит.

2. Проблемы с настройкой сети под эмулируемой Windows 2003.

Так как по умолчанию qemu эмулирует хоть и довольно распространённую в своё время, но уже довольно старую сетевую карту Realtek на базе чипа rtl8029, которую Windows 2003 уже не знает и драйвера на которую для этой операционной системы я так и не смог поставить, как ни бился, то для корректной работы с сетью стоит указывать другой тип сетевого адаптера. Например, rtl8139. Тогда строка запуска будет выглядеть следующим образом:

qemuctl -m 256 -net nic,model=rtl8139 -net tap,ifname=$IFACE -hda disk.dsk

3. Проблемы с клонированием виртуальных linux машин.

Установив на одну из своих виртуальных машин Debian Etch 4.0r3, я решил сделать копию образа жёсткого диска и запустить с ней ещё одну виртуальную машину, изменив mac-адрес. Так как я запускал её с опцией "-nographic", то с удивлением обнаружил, что и через продолжительное время ip адрес, который должен был получить эмулируемый хост, не начал отвечать на ping запросы. Чтобы выяснить, в чём дело, я убил процесс qemu при помощи kill, убрал из скрипта опцию "-nographic" и снова запустил виртуальную машину. После старта я обнаружил, что интерфейс eth0 не был поднят. При попытке поднять его вручную, я получал следующее:

debian:~# ifconfig eth0 up
SIOCSIFADDR: No such device
eth0: ERROR while getting interface flags: No such device
eth0: ERROR while getting interface flags: No such device

В то же время я убедился, что он существует, причём с тем mac адресом, который был указан при старте qemu в качестве параметра:

debian:~# dmesg | grep eth
eth0: ReakTek RTL-8029 found ad 0xc100, IRQ 10, 00:00:00:00:00:02.

Проблема кроется в следующем - udev (менеджер динамического именования устройств) однажды уже нашёл сетевой интерфейс eth0 с mac адресом 00:00:00:00:00:01 и сохранил о нём запись. Теперь же он увидел ещё один такой же сетевой интерфейс, но уже с адресом 00:00:00:00:00:02 и дал ему новое имя - eth1. Это стало очевидным после попытки поднять интерфейс eth1, что удалось без проблем. Очевидно, есть несколько вариантов решения этой проблемы: запускать новую копию виртуальной машины без директивы "-nographic", после чего корректировать /etc/network/interfaces, либо перед созданием копии добавить туда следующее:

allow-hotplug eth1
iface eth1 inet dhcp

Если же для Вас это имеет какое-то значение или Вы хотите, чтобы новый интерфейс обязательно назывался eth0, то вам придётся отредактировать файл /etc/udev/rules.d/z25_persistent-net.rules (в других дистрибутивах его имя и расположение могут быть другими). Вот его содержимое (за исключением комментариев в начале файла) на момент загрузки новой копии виртуальной машины:

# PCI device 0x10ec:0x8029 (ne2k-pci)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:00:00:00:00:01", NAME="eth0"


# PCI device 0x10ec:0x8029 (ne2k-pci)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:00:00:00:00:02", NAME="eth1"

Очевидно, что нужно убрать первое описание имени сетевого интерфейса, а во втором изменить eth1 на eth0.