Показаны сообщения с ярлыком xen. Показать все сообщения
Показаны сообщения с ярлыком xen. Показать все сообщения

воскресенье, 1 сентября 2019 г.

Virt-manager для управления виртуальными машинами под управлением KVM и Xen

Для управления виртуальными машинам, работающими под управлением систем виртуализации KVM и Xen можно использовать программу с графическим интерфейсом, которая называется Virt-manager. Программа использует демон libvirt, установленный на компьютере с системой виртуализации. Для подключения Virt-manager к демону libvirt можно использовать SSH, что довольно удобно и безопасно. Как правило, демон SSH бывает уже установлен на компьютерах, доступных по сети, поэтому не нужно заботиться о настройке отдельного сетевого демона. Плюс к тому, SSH поддерживает аутентификацию пользователей и надёжное шифрование передаваемых данных.

Настройка демона libvirt для управления виртуальными машинами под управлением KVM (на примере Debian Stretch)

Проверим наличие аппаратной поддержки виртуализации:
$ egrep -c '(vmx|svm)' /proc/cpuinfo
Устанавливаем систему виртуализации qemu с поддержкой KVM и демон libvirt для управления виртуальными машинами, работающими под управлением KVM:
# apt-get install qemu-kvm libvirt-daemon-system
Добавляем пользователя, от имени которого будем заходить на сервер по SSH, в группу libvirt, чтобы он имел доступ к управлению виртуальными машинами:
# usermod -aG libvirt stupin
Пользователь получит доступ к Unix-сокету /var/run/libvirt/libvirt-sock

Установим netcat из OpenBSD, поддерживающий опцию -U для подключения к Unix-сокету. Это нужно для перенаправления подключения от SSH-клиента в Unix-сокет libvirt:
# apt-get install netcat-openbsd
Осталось включить и запустить демона:
# systemctl enable libvirtd
# systemctl start libvirtd

Настройка демона libvirt для управления виртуальными машинами под управлением Xen (на примере Debian Wheezy)

В моём случае Xen был развёрнут в операционной системе Debian Wheezy, где пакет с демоном libvirt называется libvirt-bin. Установим его:
# apt-get install libvirt-bin
Теперь, чтобы пользователь, от имени которого мы будем подключаться по SSH к серверу виртуализации, смог подключиться к демону libvirtd, нужно добавить его в группу libvirt:
# usermod -aG libvirt stupin
Пользователь получит доступ к Unix-сокету /var/run/libvirt/libvirt-sock

Для того, чтобы демон libvirt смог работать с системой виртуализации Xen, нужно включить HTTP-сервер, встроенный в xend. Демон libvirt будет выполнять роль посредника, транслируя входящие запросы в запросы к xend.

Настроим HTTP-сервер, ожидающий подключений на порту 8000 и адресе 127.0.0.1. Для этого нужно прописать в файл /etc/xen/xend-config.sxp следующие опции:
(xend-http-server yes)
(xend-address localhost)
(xend-port 8000)
Чтобы настройки xend вступили в силу, нужно перезапустить его (пример для Debian Wheezy):
# /etc/init.d/xen restart
Будьте осторожны - в конфигурации по умолчанию при перезапуске демона xend перезапускаются также и все виртуальные машины. Чтобы избежать этого, нужно при создании виртуальной машины прописать в её конфигурацию такие настройки:
on_xend_start = 'ignore'
on_xend_stop = 'ignore'
У меня эти настройки были прописаны в каждой виртуальной машине, поэтому я перезапускал xend без опасений.

Установка и использование Virt-manager

Устанавливаем на компьютере администратора пакет с GUI-интерфейсом для управления виртуальными машинами:
# apt-get install virt-manager
Теперь можно попробовать сделать то, ради чего всё и затевалось: подключиться к системе виртуализации из программы virt-manager. Ниже приведены снимки экрана, иллюстрирующие этот процесс.

Запуск virt-manager:

Добавление нового подключения:

Новое подключение к системе виртуализации Xen:

Настройки удалённого подключения к системе виртуализации Xen через SSH:

Подключение к системе виртуализации установлено, виден список виртуальных машин:

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

Типичные проблемы

Не установлен пакет netcat-openbsd

Не удалось подключиться к libvirt.

Для взаимодействия с удалённым узлом необходимо, чтобы версия netcat/nc поддерживала параметр -U.

Не установлен пакет libvirt-bin или libvirt-daemon-system

Не удалось подключиться к libvirt.

End of file while reading data: nc: unix connect failed: No such file or directory: Ошибка ввода/вывода

Убедитесь, что на удалённом узле запущен libvirtd.

Не настроен HTTP-сервер xend

Не удалось подключиться к libvirt.

unable to connect to 'localhost:8000': В соединении отказано

Убедитесь, что на удалённом узле запущен libvirtd.

Не установлен пакет gir1.2-spice-client-gtk-3.0

Ошибка подключения к графической консоли:
Error opening Spice console, SpiceClientGtk missing

воскресенье, 19 июня 2016 г.

Установка и настройка Open vSwitch в Debian

В прошлой заметке я создал виртуальную машину с AltLinux, которая работает под управлением Xen. Там сетевой интерфейс виртуальной машины соединяется мостом с интерфейсом хост-машины (или вернее - домена-0).

Такой способ настройки может оказаться не безопасным, если на интерфейсе имеется несколько VLAN, часть которых не должны быть доступны внутри виртуальной машины. В качестве примеров можно привести случай предоставления Xen-хостинга или попытку отделить друг от друга виртуальные машины, работающие в локальной сети и в интернете. Например, через VLAN 2 может быть доступна локальная сеть, а через VLAN 3 - сеть интернет. При том способе настройки, который был описан в прошлой статье, хозяин виртуальной машины, которая должна работать только в локальной сети, может настроить внутри виртуалки VLAN-интерфейс для доступа в интернет, прослушать трафик, попытаться подобрать свободный IP-адрес и получить таким образом доступ в интернет. Или другой пример - злоумышленник может получить доступ к виртуальной машине, доступной из сети интернет, настроить VLAN-интерфейс и продолжить взлом уже внутри локальной сети.

Чтобы ограничить передаваемые в виртуальную машину VLAN, рассмотрим использование виртуального коммутатора Open vSwitch.

1. Установка Open vSwitch

Для установки виртуального коммутатора, нужно установить в систему всего-лишь один пакет:
# apt-get install openvswitch-switch
2. Настройка виртуального коммутатора средствами Debian

В составе пакета имеются скрипты для настройки коммутатора привычными для Debian средствами, через файл /etc/network/interfaces. Почитать о настройке можно в файле /usr/share/doc/openvswitch-switch/README.Debian.gz, открыв его, например, при помощи zless, или в статье Boot integration of the Openvswitch in Ubuntu. Благодаря Open vSwitch, я смог избавиться от интерфейсов vlan и br, настроенных стандартными средствами Linux, и заменил их на функционально эквивалентные им интерфейсы Open vSwitch:
auto ovs0
allow-ovs ovs0
iface ovs0 inet manual
  ovs_type OVSBridge
  ovs_ports eth0 ovs0-vlan2 ovs0-vlan3 ovs0-vlan4

allow-ovs0 eth0
iface eth0 inet manual
  ovs_type OVSPort
  ovs_bridge ovs0
  ovs_options vlan_mode=native-untagged tag=2 trunks=2,3,4

allow-ovs0 ovs0-vlan2
iface ovs0-vlan2 inet static
  ovs_bridge ovs0
  ovs_type OVSIntPort
  ovs_options tag=2
  address 169.254.254.1
  netmask 255.255.255.0
  
allow-ovs0 ovs0-vlan3
iface ovs0-vlan3 inet dhcp
  ovs_bridge ovs0
  ovs_type OVSIntPort
  ovs_options tag=3

allow-ovs0 ovs0-vlan4
iface ovs0-vlan4 inet static
  ovs_bridge ovs0
  ovs_type OVSIntPort
  ovs_options tag=4
  address 0.0.0.0
  netmask 255.255.255.0
Интерфейс ovs0 соответствует созданию одного виртуального коммутатора. При необходимости их можно создать несколько. В этот коммутатор подключается порт eth0, по которому могут передаваться тегированные пакеты для VLAN 3 и 4, а не тегированный трафик помечается как принадлежащий VLAN 2. Следующие три интерфейса соответствуют этим трём VLAN'ам.

Если через интерфейсы, принадлежащие Open vSwitch, устанавливаются другие подключения, вроде pppoe или pptp, то эти интерфейсы можно упомянуть в опции ovs_ports после используемого им интерфейса. Далее останется только удалить опцию auto и добавить вместо неё опцию allow-ovs0 для того, чтобы поднятие этого интерфейса происходило уже по команде от демона Open vSwitch. Интерфейсы поднимаются демоном в том порядке, в котором они указаны в опции ovs_ports.

3. Ручная настройка виртуального коммутатора

Для ручной настройки всего этого хозяйства сгодились бы следующие команды:
# ovs-vsctl add-br ovs0
# ovs-vsctl add-port ovs0 eth0
# ovs-vsctl set port eth0 vlan_mode=native-untagged tag=2 trunks=2,3,4
# ovs-vsctl add-port ovs0 ovs0-vlan2 tag=2 -- set Interface ovs0-vlan2 type=internal
# ifconfig ovs0-vlan2 inet 169.254.254.1/24 up
# ovs-vsctl add-port ovs0 ovs0-vlan3 tag=3 -- set Interface ovs0-vlan3 type=internal
# dhclient ovs0-vlan3
# ovs-vsctl add-port ovs0 ovs0-vlan4 tag=4 -- set Interface ovs0-vlan4 type=internal
# ifconfig ovs0-vlan4 up
Чтобы удалить порт из коммутатора, можно воспользоваться такой командой:
# ovs-vsctl del-port ovs0-vlan2
Чтобы удалить сам коммутатор, можно воспользоваться такой командой:
# ovs-vsctl del-br ovs0
Посмотреть на текущие настройки виртуального коммутатора можно командой, которая уже была продемонстрирована выше:
# ova-vsctl show
Стоит также отметить, что имена коммутаторов и портов могут быть совершенно произвольными. Названия ovs0 и ovs0-vlan2 и т.п. были даны лишь для наглядности. При этом, название интерфейса eth0 соответствует реальному интерфейсу, который нужно подключить к порту виртуального коммутатора, поэтому он фигурирует под своим настоящим именем.

Описанное выше - лишь очень малая часть того, что умеет этот виртуальный коммутатор. Он поддерживает агрегацию портов, обнаружение петель, зеркалирование портов, сбор статистики о трафике на NetFlow-коллектор и многие другие вещи. Поддерживается даже специальный протокол OpenFlow, предназначенный для централизованного управления такими коммутаторами. Я же тут ограничился самыми простыми вещами, которые мне понадобились лишь для того, чтобы передать вовнутрь виртуальной машины под управлением Xen строго определённые VLAN.

Сама коммутация пакетов происходит на уровне ядра, что обеспечивает максимальную производительность, но поддерживается и коммутация в пользовательском пространстве. В таком случае из-за частых переключений между режимами ядра и пользователя производительность должна оказаться уже не столь высокой.

Вот так, например, можно убедиться в том, что по крайней мере некоторая часть openvswitch работает в пространстве ядра:
# lsmod | grep vs
openvswitch            63932  0 
gre                    12777  1 openvswitch
vxlan                  35053  1 openvswitch
libcrc32c              12426  1 openvswitch
5. Виртуальный коммутатор и Xen

Для того, чтобы включить в виртуальный коммутатор интерфейс виртуальной машины, работающей под управлением Xen, можно воспользоваться соответствующими настройками в файле конфигурации виртуальной машины. Например, вот фрагмент файла конфигурации /etc/xen/inet.cfg виртуальной машины inet:
vif = ['script=vif-openvswitch,bridge=ovs0.2']
Таким образом виртуальная машина будет включена в нетегированный порт коммутатора в VLAN 2.

Чтобы передать в виртуальную машину VLAN'ы 3 и 4 в тегированном режиме, можно воспользоваться следующим способом настройки:
vif = ['script=vif-openvswitch,bridge=ovs0:3:4']
О других возможностях настройки сети в виртуальных машинах Xen можно почитать здесь: Xen Networking

P.S. 25 июня 2016. Внесён ряд правок, связанных с автоматическим восстановлением настроек при перезагрузке.

воскресенье, 12 июня 2016 г.

Запуск AltLinux как domU в Xen

При помощи утилиты xen-create-image можно легко создавать виртуальные машины с любой операционной системой, поддержка которой присутствует в каталоге /usr/share/xen-tools/. Заинтересовал вопрос, как же можно создать виртуальную машину не из списка поддерживаемых? В качестве предмета для экспериментов я выбрал AltLinux. Статья делится на две части: подготовка образа для многократного дальнейшего использования и создание из этого образа одной виртуальной машины.

Сразу предупреждаю, что тут я в хвост и в гриву пользуюсь LVM. Во-первых, это удобно. Во-вторых, ну не зря же я мучился? У кого нет LVM, выпутывайтесь сами ;-P

1. Подготовка образа для последующего использования

Скачиваем один из образов из каталога http://ftp.altlinux.org/pub/distributions/ALTLinux/p7/images/starterkits/

Например, я взял altlinux-p7-vm-net-20160312-x86_64.img.xz:
$ cd /home/stupin
$ wget http://ftp.altlinux.org/pub/distributions/ALTLinux/p7/images/starterkits/altlinux-p7-vm-net-20160312-x86_64.img.xz
Распакуем его:
$ cd /home/stupin
$ 7z x altlinux-p7-vm-net-20160312-x86_64.img.xz
Получится файл с именем altlinux-p7-vm-net-20160312-x86_64.img размером 504 мегабайт.

Посмотрим при помощи утилиты file, что представляет собой этот файл:
# file /home/stupin/altlinux-p7-vm-net-20160312-x86_64.img
/home/stupin/altlinux-p7-vm-net-20160312-x86_64.img: DOS/MBR boot sector, LInux i386 boot LOader; partition 1 : ID=0x83, start-CHS (0x0,32,33), end-CHS (0x40,63,63), startsector 2048, 1030144 sectors

Это образ диска с таблицей разделов в стиле DOS.

Создадим логический том такого же размера, что и образ и скопируем в него этот файл посекторно:
# lvcreate -n image -L 528482304b stupin
# cd /home/stupin
# dd if=altlinux-p7-vm-net-20160312-x86_64.img of=/dev/mapper/stupin-image
Если при помощи fdisk посмотреть таблицу разделов в образе, то можно ещё раз убедиться в том, что в образе имеется таблица разделов DOS:
# fdisk -l /dev/mapper/stupin-image

Disk /dev/mapper/stupin-image: 504 MiB, 528482304 bytes, 1032192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xd6c97625

Device                    Boot Start     End Sectors  Size Id Type
/dev/mapper/stupin-image1       2048 1032191 1030144  503M 83 Linux
Смонтируем файловую систему из первого раздела в каталог /mnt/root:
# partprobe
# mount /dev/mapper/stupin-image1 /mnt/root
Исправим файл etc/inittab, убрав оттуда две консоли и создав вместо них консоль, которая будет доступна из dom0:
1:2345:respawn:/sbin/mingetty hvc0
#1:2345:respawn:/sbin/mingetty --noclear tty1
#2:2345:respawn:/sbin/mingetty tty2
Также я отредактировал файл etc/fstab, прописав монтирование корневой файловой системы по имени устройства вместо монтирования по идентификатору:
/dev/xvda     /                       ext4    relatime                        1 1
#UUID=5b7c2d58-0afa-4bf4-9a42-542935636a05 / ext4 relatime 1 1
Чтобы в дальнейшем меньше пришлось вписывать в файл конфигурации виртуальной машины, создадим файл конфигурации для загрузчика pygrub. Для этого создадим каталог boot/grub:
# cd /mnt/root/boot
# mkdir grub
Внутри каталога создадим файл menu.lst со следующим содержимым:
default         0
timeout         2

title           AltLinux p7 x86_64
root            (hd0,0)
kernel          /boot/vmlinuz root=/dev/xvda ipv6.disable=1 ro
initrd          /boot/initrd.img

title           AltLinux p7 x86_64 (Single-User)
root            (hd0,0)
kernel          /boot/vmlinuz root=/dev/xvda ipv6.disable=1 ro single
initrd          /boot/initrd.img
Поменяем пароль по умолчанию у пользователя root:
# chroot /mnt/root
# passwd
# exit
Теперь создадим архив для последующего разворачивания новых виртуальных машин:
# cd /mnt/root
# tar cjvf /home/stupin/altlinux-p7-vm-net-20160312-x86_64.tbz *
Наконец, раздел можно отмонтировать и уничтожить:
# umount /mnt/root
# dd if=/dev/zero of=/dev/mapper/stupin-image
# partprobe
# lvremove /dev/mapper/stupin-image
2. Создание виртуальной машины

Создадим LVM-раздел для размещения корневого раздела будущей виртуальной машины:
# lvcreate -n inet-root -L 20G stupin
Создадим файловую систему:
# mkfs.ext4 /dev/stupin/inet-root
Смонтируем файловую систему:
# mount /dev/stupin/inet-root /mnt/inet/
И распакуем в неё подготовленный архив с системой:
# cd /mnt/inet/
# tar xjvf /home/stupin/altlinux-p7-vm-net-20160312-x86_64.tbz
Размонтируем корневую файловую систему будущей виртуальной машины:
# cd /
# umount /mnt/inet
Теперь создадим файл конфигурации виртуальной машины /etc/xen/inet.cfg:
bootloader = '/usr/lib/xen-4.4/bin/pygrub'
#kernel = '/boot/vmlinuz'
#ramdisk = '/boot/initrd.img'

name = 'inet'

vcpus = 1
memory = 1024

#root = '/dev/xvda ro'
disk = ['phy:/dev/stupin/inet-root,ioemu:xvda,w']
vif = ['script=vif-bridge,bridge=xenbr0']

on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
on_xend_start = 'ignore'
on_xend_stop = 'ignore'
Параметры kernel, ramdisk и root закомментированы, потому что внутри образа имеется файл /boot/grub/menu.lst, в котором прописано, в каком файле лежит образ ядра и образ минимального корневого диска, а также прописаны все параметры, передаваемые загрузчиком ядру. В том числе прописан параметр, настраивающий имя устройства, содержащей корневую файловую систему.

воскресенье, 29 мая 2016 г.

Установка Windows XP в Xen

Возникла задача поставить Windows для запуска программы, которая не работает в Wine. Решил попробовать установить Windows под управлением Xen. Ранее я уже писал небольшую заметку о настройке Xen: Памятка по настройке Xen. В той статье для управления Xen использовалась утилита xm, поскольку писалась она применительно к Debian Wheezy. В этот раз будет использоваться утилита xl, поскольку дело происходит в Debian Jessie. Однако, несмотря на это различие, всё написанное в прошлой статье будет работать и сейчас. Надо всего лишь вместо xm использовать xl.

1. Установка операционной системы на виртуальную машину

Создадим LVM-раздел, куда будем устанавливать Windows:
# lvcreate -L10G -n winxp-disk
Создадим файл конфигурации /etc/xen/winxp.cfg, который первоначально будет использоваться для установки системы:
builder = 'hvm'
device_model_version = 'qemu-xen'
memory = 1024
vcpus = 1
pae = 0
acpi = 0
apic = 0
name = 'winxp'
disk = ['phy:/dev/vg0/winxp-disk,ioemu:hda,w',
        'phy:/home/stupin/WindowsXP_SP2.iso,ioemu:hdb:cdrom,r']
boot = 'd'

on_poweroff = 'destroy'
on_reboot = 'destroy'
on_crash = 'destroy'
on_xend_start = 'ignore'
on_xend_stop = 'ignore'

fullscreen = 1
sdl = 0
vnc = 1
vncconsole = 1
vncpasswd = ''
keymap = 'ru'
stdvga = 0
serial = 'pty'

usb = 1
usbdevice = 'tablet'
Особо стоит отметить следующие моменты в этом файле:
  • Опции acpi (интерфейс управления электропитанием) и apic (улучшенный контроллер прерываний) на время установки отключены,
  • В опции disk первым прописан LVM-раздел, в который будем устанавливать систему, а вторым прописан ISO-образ установочного диска с Windows,
  • Опция boot выставлена в значение d - загрузка "с диска D:", то есть - с компакт-диска, в роли которого выступает ISO-образ установочного диска,
  • Опция keymap позволяет в дальнейшем не следить за раскладкой на системе, где запущен VNC-клиент. Без этой опции в сеансе VNC русские буквы удастся ввести только в случае, если на системе с VNC-клиентом включена английская раскладка,
  • Включена поддержка usb, а в списке USB-устройств в опции usbdevice настроен "планшет". Эта настройка позволяет в дальнейшем без проблем манипулировать курсором мыши. Без неё при подключении через VNC будет два курсора мыши, слабо связанных между собой, так что управляться ими будет непросто.
Теперь запустим виртуальную машину:
# xl create /etc/xen/winxp.cfg
На всякий случай, если вдруг виртуальная машина зависнет, приведу команду для её принудительного выключения:
# xl destroy winxp
Напоминаю, что список запущенных виртуальных машин можно посмотреть такой командой:
# xl list
После запуска можно подключиться к виртуальной машине при помощи VNC-клиента на TCP-порт 5900 по IP-адресу 5900. Я воспользовался Remmina, о которой писал в одноимённой заметке - Remmina:

Если Вы хотите подключиться по сети не из домена dom0 или у Вас имеется несколько подобных доменов domU, к которым Вы хотите подключаться по протоколу VNC, можно настроить прослушиваемый адрес и порт при помощи опции vnclisten. Например, значение 192.168.0.1:2 будет соответствовать ожиданию подключений на TCP-порт 5902 и адрес 192.168.0.1.

Настроить переключение раскладки по нажатию Alt+Shift мне не удалось - это сочетание в сеанс VNC не попадало, поэтому пришлось настроить непривычное для меня сочетание Ctrl+Shift.

2. Изменение настроек после установки

После установки Windows нужно выключить виртуальную машину, воспользовавшись пунктом меню "Выключить компьютер", доступным по нажатию кнопки "Пуск":

Теперь нужно немного изменить конфигурацию в файле /etc/xen/winxp.cfg. Включим опции acpi и apic, уберём из списка дисков ISO-образ установочного компакт-диска и поменяем значение опции boot на c - загрузка "с диска C:":
acpi = 1
apic = 1
disk = ['phy:/dev/vg0/winxp-disk,ioemu:hda,w']
boot = 'c'
3. Проброс USB-устройств вовнутрь виртуальной машины

Ещё одна вещь, которая мне понадобилась - это пробросить флешку вовнутрь виртуальной машины. Для начала я вставил её в компьютер и нашёл её в списке имеющихся в системе USB-устройств при помощи команды:
$ lsusb -v | less
В несколько сокращённом виде, нужная мне флешка выглядела следующим образом:
Bus 001 Device 005: ID 0930:6534 Toshiba Corp. TravelDrive
Device Descriptor:
  ...
  idVendor           0x0930 Toshiba Corp.
  idProduct          0x6534 TravelDrive
  bcdDevice            1.00
  iManufacturer           1 Kingston
  iProduct                2 DataTraveler 2.0
  iSerial                 3 0201101728450
  bNumConfigurations      1
  Configuration Descriptor:
    ...
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass         8 Mass Storage
Чтобы флешка автоматически пробрасывалась в виртуальную машину, нужно отредактировать список USB-устройств в файле конфигурации /etc/xen/winxp.cfg:
usbdevice = ['tablet', 'host:0930:6534']
Если в системе имеется несколько устройств с одинаковыми идентификаторами производителя и модели, то можно указать номер шины и устройства. В нашем случае это будет выглядеть вот так:
usbdevice = ['tablet', 'host:1.5']
Однако стоит учесть, что при отключении и повторном включении устройство может получить другой номер. Использовать идентификаторы производителя и модели.

В случае с утилитой xm можно было бы вставлять и удалять устройства налету, вот так:
# xm usb-add winxp host:0930:6534
# xm usb-del winxp host:0930:6534
Однако, в утилите xl подобная функциональность пока не реализована и для введения настроек в силу понадобится завершить работу виртуальной машины и запустить её снова, с использованием исправленной конфигурации.

4. Использованные материалы

воскресенье, 1 июня 2014 г.

Памятка по настройке Xen

Xen - довольно распространённая и хорошо зарекомендовавшая себя система виртуализации. В ней можно выделить три главных компонента:
  • Гипервизор - небольшое ядро, осуществляющее управление памятью и процессором,
  • dom0 - система, находящаяся под управлением гипервизора, но определяющая политику распределения памяти и процессоров, которую и реализует гипервизор,
  • domU - система, находящаяся под управлением гипервизора.
dom0, как и гипервизор, в системе может быть только один. domU может быть несколько. Для простоты в статье будем называть dom0 хост-системой, а domU - гостевыми системами, хотя строго говоря - они оба скорее гости, просто один из них имеет право управлять гипервизором.

Сервисы Xen, работающие в dom0 и осуществляющие управление гипервизором, написаны на Python. Соответственно, файлы конфигурации являются фактически исходными текстами на языке Python.

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

1. Настройка гипервизора

Устанавливаем пакет xen-linux-system:
# apt-get install xen-linux-system
Выставляем приоритет загрузки гипервизора Xen из GRUB:
# dpkg-divert --divert /etc/grub.d/08_linux_xen --rename /etc/grub.d/20_linux_xen
Для отмены приоритета загрузки Xen из GRUB можно выполнить следующую команду:
# dpkg-divert --rename --remove /etc/grub.d/20_linux_xen
Чтобы настройки GRUB вступили в силу, запустим обновление конфигурации GRUB:
# update-grub
2. Настройка хост-системы

Образы гостевых систем будем размещать на логических томах LVM2, поэтому сначала установим утилиты для управления логическими томами:
# apt-get install lvm2
Создадим новый физический том на специально выделенном для этого разделе:
# vgcreate vg0 /dev/sda3
Установим инструменты для создания образов и управления гостевыми системами:
# apt-get install xen-tools
Пропишем в файле /etc/xen-tools/xen-tools.cfg опции, задающие настройки создаваемой по умолчанию виртуальной машины:
# Использовать для образов гостевых систем физический том VG0
lvm = vg0

# Использовать debootstrap для установки системы на гостевой том
install-method = debootstrap

# Выделить для вновь создаваемой гостевой системы 10 гигабайт на логическом томе
size = 10Gb

# По умолчанию создавать гостевую систему, которой выделено 2 гигибайта оперативной памяти
memory = 2Gb

# По умолчанию создавать гостевую систему, которой выделен 1 гигабайт раздела подкачки
#noswap = 0
swap = 1Gb

# По умолчанию использовать файловую систему ext4
fs = ext4

# Настройки монтирования раздела ext4
ext4_options = noatime,nodiratime,errors=remount-ro

# Настройки задают ветку дистрибутива, версию ядра и загрузочного образа
dist = `xt-guess-suite-and-mirror --suite`
image = sparse
kernel = /boot/vmlinuz-`uname -r`
initrd = /boot/initrd.img-`uname -r`
pygrub = 1
mirror = `xt-guess-suite-and-mirror --mirror`
Все гостевые системы будут подключаться к виртуальному сетевому мосту, соединённому с физической сетевой картой. На самом деле сетевой мост является по сути виртуальным коммутатором, поддерживающим протокол STP, но по сложившейся традиции называется сетевым мостом. Установим утилиты для управления сетевым мостом:
# apt-get install bridge-utils
Настроим интерфейс xenbr0, подсоединив его к физическому сетевому интерфейсу eth0. Для этого впишем в файл /etc/network/interfaces следующие настройки:
auto xenbr0
iface xenbr0 inet static
  address 10.0.0.1
  netmask 255.255.255.0
  bridge_ports eth0
  bridge_maxwait 0
3. Создание образа гостевой системы

Для создания образа новой гостевой системы с именем ns, настройками по умолчанию, но с двумя выделенными системе ядрами процессора, введём на хост-системе следующую команду:
# xen-create-image --hostname ns --ip 10.0.0.2 --netmask 255.255.255.0 --gateway 10.0.0.1 --vcpus 2 --dist wheezy
После создания образа будет выведен пароль пользователя root в только что созданной системе. Его необходимо запомнить или записать и поменять при первом запуске созданного образа.

Теперь можно отредактировать конфигурацию только что созданной гостевой машины /etc/xen/ns.cfg:
vif = [ 'script=vif-bridge, bridge=xenbr0' ]
При запуске гостевой машины её первый интерфейс будет подключен к мосту хост-машины xenbr0. Если необходимо создать несколько сетевых интерфейсов, можно перечислить их внутри квадратных скобок через запятую.

4. Управление гостевыми системами

Запуск гостевой машины:
# xm create /etc/xen/ns.cfg
Просмотр списка активных гостевых машин:
# xm list
Просмотра потребления ресурсов внутри каждой гостевой машины:
# xm top
Остановка гостевой машины:
# xm shutdown ns
Вход на консоль гостевой машины:
# xm console ns
Для отключения от консоли можно нажать Ctrl и ] К сожалению, эта же комбинация клавиш используется в telnet, поэтому я предпочитаю сразу настроить сеть и SSH, а дальнейшую настройку гостевой системы осуществлять уже через SSH.

5. Донастройка гостевых систем

Файл конфигурации гостевой системы может выглядеть примерно следующим образом:
# Загрузчик pygrub позволяет передавать в ядро настройки,
# подобно тому как это делается при использовании GRUB
bootloader = '/usr/lib/xen-4.1/bin/pygrub'

# Количество процессорных ядер и объём памяти, выделяемый гостевой системе
vcpus       = '2'
memory      = '2048'

root        = '/dev/xvda2 ro'
disk        = [ 'phy:/dev/vg0/ns-disk,xvda2,w', # Образ диска находится на томе LVM2
                'phy:/dev/sda3,xvda3,w' ]       # Том хост-системы монтируется внутри гостевой системы

# Имя гостевой системы
name        = 'ns'

# На гостевой системе будут созданы интерфейсы eth0 и eth1, подключенные
# соответственно к сетевым мостам хост-системы xenbr0 и xenbr1
vif         = [ 'script=vif-bridge, bridge=xenbr0',
                'script=vif-bridge, bridge=xenbr1' ]

# Что делать с гостевой системой, если она решила выключиться или перезагрузиться
on_poweroff = 'destroy'
on_reboot   = 'restart'

# Что делать с гостевой системой, если произошла ошибка на хост-системе
on_crash    = 'restart'

# Отдельно задаём поведение гостевых систем при перезапуске сервиса управления
on_xend_start = 'ignore'
on_xend_stop = 'ignore'
6. Что следует установить в гостевую систему?

Я для себя сформировал следующий контрольный список:
# apt-get install vim less apt-file resolvconf binutils screen rsync
# apt-get install sysstat tcpdump file dnsutils telnet psmisc 
# apt-get install openntpd sudo postfix bsd-mailx logwatch
Не всё из этого необходимо, поэтому вы можете оставить из этого списка то, что вам нужно и дополнить его пакетами по своему вкусу. При установке openntpd и postfix стоит подумать об их настройке.

Если вам когда-нибудь понадобится воспользоваться консолью гостевой системы, стоит установить пакеты, ответственные за консоль, клавиатуру и локаль:
# apt-get install console-setup keyboard-configuration
Соответственно, можно задать их настройки при помощи следующих команд:
# dpkg-reconfigure console-setup
# dpkg-reconfigure keyboard-configuration
# dpkg-reconfigure locales
Ниже приведены пункты конфигурирования, отличающиеся от значений по умолчанию, которые я обычно выбираю для настройки этих пакетов:
Keyboard layout: Other
Country of origin for the keyboard: Russian
Keyboard layout: Russian

Encoding to use on the console: UTF-8
Character set to support: Cyrillic - KOI8-R and KOI8-U

Default locale for the systemm environment: ru_RU.UTF-8
7. Отключение сохранения-восстановления гостевых систем

При остановке демона xen, а также при выключении и перезагрузке системы, демон по умолчанию пытается сохранить состояние всех гостевых систем в каталог /var/lib/xend/storage, из-за чего может закончиться всё место на диске.

Изменить это поведение можно в файле /etc/default/xendomains настройкой значения XENDOMAINS_SAVE. Можно указать другой каталог, в котором есть достаточно места для сохранения образов оперативной памяти гостевых систем, а можно полностью отключить сохранение, указав пустое значение:
XENDOMAINS_SAVE=
Чтобы удалить сохранённые образы памяти гостевых систем, можно воспользоваться следующими командами:
# cd /var/lib/xen
# find . -type f -delete
8. Автозапуск виртуальных машин

По умолчанию при перезагрузке хост-системы восстанавливается сохранённое состояние гостевых систем. Если мы отключили сохранение и восстановление гостевых систем, то гостевые системы запущены не будут. Чтобы гостевые системы автоматически загружались при загрузке хост-системы, нужно создать каталог автозапуска и поместить внутрь него символические ссылки на конфигурации необходимых гостевых систем:
# mkdir /etc/xen/auto
# cd /etc/xen/auto
# ln -s /etc/xen/ns.cfg .
9. Решение проблем

9.1. Ошибка настройки сети

Гостевая система долго запускается, а затем выдаёт ошибку настройки сети:
"Error: Device 0 (vif) could not be connected. Could not find bridge, and none was specified".
В этом случае нужно просто отключить скрипт настройки сети, который запускается для всех гостевых систем. Для этого нужно закомментировать строку в файле /etc/xen/xend-config.sxp на хост-системе:
#(vif-script vif-bridge)
9.2. Ошибка запуска xen

Если команда xm list выдаёт ошибку:
Error: Unable to connect to xend: No such file or directory. Is xend running?
При запуске демонов xen при помощи команды /etc/init.d/xen start выводится ошибка:
[FAIL] Starting Xen daemons: xenstored xenconsoled xend failed!
И в журнале /var/log/xen/xend.log имеется запись вида:
[2013-12-06 09:21:27 4789] ERROR (SrvDaemon:349) Exception starting xend (unclosed token: line 1282, column 32)
Значит повреждено содержимое хранилища xen в каталоге /var/lib/xend и для запуска демонов xen его необходимо очистить при помощи команд:
# cd /var/lib/xend
# find . -type f -delete