Словарик:
оверселлинг - когда продаётся больше ресурсов, нежели реально возможно предоставить, по очень грубым подсчетам, в настоящее время хостерами продано в 10 раз больше ресурсов нежели имеется аппаратной мощности
домен - читай операционная система
гипервизор - система запуска всех доменов
dom0 - основной домен
domU - гостевые домены


Привет. В этой статье я бы хотел сделать небольшое how-to если Вы хотите сделать профессиональную систему виртуализации. Хотелось бы поделиться опытом, так как русской документации(АКТУАЛЬНОЙ!) на эту тему очень и очень немного и приходилось по крупицам собирать с рассылки xen-users@lists.xensource.com. Если Вы планируете профессионально этим заниматься, обязательно подпишитесь.
Xen -- это монитор виртуальных машин (VMM, Virtual Machine Monitor) или гипервизор (hypervisor) с поддержкой паравиртуализации (para-virtualization) для процессоров x86 архитектуры, распространяющийся с открытым исходным кодом (opensource). Xen может организовать совместное безопасное исполнение нескольких виртуальных машин на одной физической системе с производительностью близкой к непосредственной (native).

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

Плюсы:
Минусы:
В первую очередь важно знать, что работа может производиться в HVM режиме и в режиме паравиртуализации. HVM режим должен поддерживаться процессором, запуск некоторых систем(Windows, FreeBSD) возможен только в HVM режиме. Паравиртуализация - это запуск системы с измененным ядром. Загрузка системы xen отличается от обычной: запускается XEN - гипервизор, который стартует основную систему (сравните, обычно система загружается сама первой а затем только стартуются прикладные программы). Далее после старта основной системы можно запускать гостевые домены. Я испробовал Suse, CentOS, Debian и отдал предпочтение Debian Lenny в качестве хост системы.
Самый простой вариант - запуск в режиме паравиртуализации:
Устанавливаем необходимые пакеты:

# aptitude install xen-tools libc6-xen

Все остальное подтянется автоматически по зависимостям.

Ставим XEN ядро:

# aptitude install xen-linux-system-2.6.26-1-xen-686

Все нормально установилось из репозитариев, перезагружаемся с новым ядром.

Далее в файле /etc/xen/xend-config.sxp нужно раскомментировать строку network-script network-bridge, чтобы мы могли гостевым системам выдавать ip адреса из нашей локальной сети.

Создавать образы гостевой системы мы будем с помощью утилиты xen-tools. Сначала настроим ее. Для этого нужно поправить /etc/xen-tools/xen-tools.conf примерно так:

dir = /home/xen # Каталог, куда будут помещены созданные образы
install-method = debootstrap # построить систему, с помощью утилиты debootstrap
size = 8Gb # Размер образа
memory = 512Mb # Сколько оперативной памяти выделяем
swap = 512Mb # Размер swap файла
fs = ext3 # Какую файловую систему создавать
dist = lenny # Какой дистрибутив устанавливать
image = sparse # Делает размер образа таким, сколько места реально занято
kernel = /boot/vmlinuz-`uname -r` # Использовать ядро основной системы
initrd = /boot/initrd.img-`uname -r` # Использовать initrd основной системы
mirror = http://mirror.yandex.ru/debian/ # С какого зеркала debootstrap будет брать пакеты
ext3_options = noatime,nodiratime,errors=remount-ro # Опции монтирования файловой системы
serial_device = hvc0 # Чтобы можно было попасть в консоль гостевой системы с основной

Создаем каталоги, куда будут помещаться созданные образы:

# mkdir /home/xen
# mkdir /home/xen/domains

Создаем образ виртуальной машины:

# xen-create-image --hostname=guest1 --ip=10.32.0.136 --netmask=255.255.252.0 --gateway=10.32.0.1 --passwd --role udev

Утилита xen-tools создаст нам образ гостевой системы на базе Debian lenny с указанными в командной строке сетевыми настройками, спросит пароль для root и создаст конфигурационный файл виртуальной машины. Нам его нужно подправить, так как по крайней мере в XEN версии 3.2 существует ошибка синхронизации времени гостевой системы с основной. Из-за этого в определенных случаях виртуальная машина прекращает работать, выдавая на консоль что-то вроде такого:

[134923.954606] clocksource/0: Time went backwards: delta=-6917269595673126078 shadow=134923109294656 offset=845310074
[134928.952308] printk: 1154382 messages suppressed.
[134928.952323] clocksource/0: Time went backwards: delta=-6917269590675409336 shadow=134928109321066 offset=842999953

Наш конфиг /etc/xen/guest1.cfg должен выглядеть примерно так:

kernel = '/boot/vmlinuz-2.6.26-1-xen-686'
ramdisk = '/boot/initrd.img-2.6.26-1-xen-686'
memory = '512'
vcpus = 2
extra = 'clocksource=jiffies' #Именно это передаем ядру, во избежание проблемы с clocksource
root = '/dev/sda1 ro'
disk = [
'file:/home/xen/domains/guest1/disk.img,sda1,w',
'file:/home/xen/domains/guest1/swap.img,sda2,w',
]
name = 'guest1'
vif = [ 'ip=10.32.0.136,mac=00:16:3E:A3:69:9C' ]
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

В документации по XEN сказано, что для увеличения производительности дисковой подсистемы виртуальных машин, использующих не физические разделы, а образы – вместо «file:/» использовать «tap:aio:/», но у меня это так и не заработало, даже после плясок с бубном. tap:aio использует драйвер blktap вместо loop, что снимает ограничение на количество одновременно смонтированных устройств, работающих через loopback. Но можно увеличить установленное по умолчанию значение, добавив в в /etc/modules: loop max_loop=255

Теперь настала пора запустить нашу виртуальную машину:

# xm create -c /etc/xen/guest1.cfg

Опция -c означает, что после запуска виртуальной машины произойдет переключение на ее консоль. Если загрузка прошла успешно, логинимся, и добавляем в конфигурационный файл опций ядра параметр xen.independent_wallclock=1, который обозначает, что не нужно брать системное время от основной системы. После этого, вышеуказанная ошибка синхронизации времени нас беспокоить не будет. Правда придется синхронизировать время например через ntp, но я думаю что это не проблема.

# echo "xen.independent_wallclock=1" >> /etc/sysctl.conf

Чтобы выйти снова в основную систему, нажимаем CTRL+]

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

xm list - посмотреть список запущенных виртуальных машин
xm console guest1 - подключиться к консоли гостевой системы
CTRL+] - отключиться от консоли
xm create /etc/xen/guest1.cfg - запустить вирт. машину (xm cr /etc/xen/guest1.cfg также возможно использовать)
xm shutdown -H guest1 - остановить вирт. машину
xm destroy guest1 - принудительно "вырубить" вирт. машину
xm top - системный монитор, покажет нагрузку всех вирт. машин
xm help - посмотреть список остальных команд

Чтобы виртуальная машина стартовала автоматически, нужно добавить симлинк на нее в /etc/xen/auto/:

# ln -s /etc/xen/guest1.cfg /etc/xen/auto/guest1.cfg

На этом базовая настройка завершена – можно пользоваться.



Для увеличения производительности виртуальных машин, лучше всего использовать не файлы с образами систем, а отдавать системам разделы жесткого диска, либо отдельные физические диски. Удобнее всего для этих целей подойдет LVM (Logical Volume Manager):
Перед использованием диска или раздела в качестве физического тома необходимо его инициализировать:
Для целого диска:
%# pvcreate /dev/hdb

Для создания группы томов используется команда 'vgcreate'
%# vgcreate vg01 /dev/hda1 /dev/hdb1

Для того, чтобы создать логический том "guest1-root ", размером 20000Мб, выполните команду:
%# lvcreate -L20000 -nguest1-root vg01
Для свапа:
%# lvcreate -L1024 -nguest1-swap vg01
Партиции можно менять, делать что угодно - подробнее http://xgu.ru/wiki/LVM

Предположим, что мы выделили для виртуальной машины два логических тома, /dev/vg01/guest1-root для корня и /dev/vg01/guest1-swap для свопа. Перенести виртуальную машину из образа на физический раздел можно так:

# dd if=/home/xen/domains/guest1/disk.img of=/dev/vg01/guest1-root bs=64k

Если размер тома больше, чем размер образа, то делаем ресайз файловой системы:

# e2fsck -f /dev/vg01/guest1-root
# resize2fs /dev/vg01/guest1-root

Создаем свап:

# mkswap /dev/vg01/guest1-swap

И исправляем конфигурацию дисков в /etc/xen/guest1.cfg

disk = [
'phy:/dev/vg01/guest1-root,sda1,w',
'phy:/dev/vg01/guest1-swap,sda2,w',
]

Запускаем вирт. машину. Теперь она расположена на физических разделах. С использованием LVM, мы можем удобно изменять размер дисков вирт. машин, делать снапшоты для бекапа и многое другое.

И в заключении рассмотрим как бекапить все это хозяйство.

Если все виртуальные машины у нас находятся в файлах, то можно просто копировать их в надежное место. Но более гибко можно выполнять бекап, если у нас используется LVM. Чтобы выполнять бекап систем без остановки вирт. машин, воспользуемся снапшотами LVM.

На жестком диске в Volume group должно быть достаточно свободного места для выполнения снапшота. Создаем снапшот:

# lvcreate -L1GB -s -n guest1backup /dev/vg01/guest1-root

Можно выполнить бекап всего раздела с помощью dd:

# dd if=/dev/vg01/guest1backup bs=64k | gzip -c > /root/guest1_backup.img.gz

Но в этом случае будет скопирован весь раздел, включая свободное место, и размер бекапа получится очень большой, поэтому лучше всего использовать утилиту dump:

# dump -0af- /dev/vg01/guest1backup | gzip -c > /root/guest1_backup.dump.gz

Удаляем снапшот:

# lvremove -f /dev/vg01/guest1backup

Мы получили полный бекап системы, восстановить который мы сможем куда угодно с помощью утилиты restore.

Очень удобно делать подобные бекапы с удаленной машины по ssh периодически, через cron. Для этого на основной XEN машине в /etc/sudoerc добавим возможность группе root выполнять команду dump через sudo без пароля:

%root ALL = NOPASSWD: /sbin/dump

Нужно добавить пользователя, под которым мы будем ходить по ssh для бекапа в группу root:

# gpasswd -a alex root

Теперь мы с удаленной машины можем делать бекап командой:

# ssh alex@xen0.domain.com 'sudo dump -0af- /dev/vg01/guest1backup | gzip -c' | dd of=./2009-03-05.dump.gz

В итоге бекап вирт. машины окажется у нас в текущем каталоге под именем 2009-03-05.dump.gz
----------------------------------------------------------------------------------------------------
Запуск в HVM
Описанное выше не подходит для FreeBSD и Windows. Если заинтересуется кто, напишу. FreeBSD поддерживается xen 3.3.1, который требуется установить из исходных кодов.


Источники:
XEN MANUAL
LVM MANUAL
Хорошая статья (копипаст с дополнениями)