Распределение ресурсов между доменами Xen
Материал из Xgu.ru
- Коротко: xen/resources
Содержание |
[править] Процессор
Виртуальные процессоры (VCPU) виртуальных машин автоматически распределяются планировщиком между доступными физическими процессорами. Назначать соответствие виртуального процесса реальному вручную не нужно. Однако, при возникновении такой необходимости, можно указать на каком процессоре будет выполняться виртуальный процессор. Это делается с помощью команды xm vcpu-pin.
Каждый домен характеризуется двумя числами — весом (weight) и лимитом (cap).
Домен с весом 512 получает на том же хосте в два раза больше процессорного времени чем домен с весом 256. Вес может изменяться в диапазоне от 1 до 65535, и он равен по умолчанию 256.
Значение лимита (cap) может использоваться для того чтобы указать максимальную величину процессорного времени, которую может получить домен, даже в случае, если хост-система простаивает. Значение выражается в процентах: 100 это 1 физический процессор, 50 это половина процессора, 400 — 4 процессора и т.д. Однако следует учитывать, что значение cpu_cap не может быть большим чем VCPU*100, т.е. одному виртуальному процессору не может соответствовать больше чем один реальный процессор.
Значения лимита и веса можно просматривать и модифицировать с помощью команд:
- xm sched-credit -d domain — показать значение вес (weight) и лимит (cap) для домена;
- xm sched-credit -d domain -w weight — установить вес равным weight;
- xm sched-credit -d domain -c cap — установить верх равным cap.
Для того чтобы эти значения сохранялись и после перезапуска домена, их нужно указать в конфигурационном файле с помощью параметров:
- cpu_cap — лимит (по умолчанию 0);
- cpu_weight — вес (по умолчанию 256).
[править] Количество и конфигурация процессоров
cpus vcpus
Горячее подключение процессора
[править] Частота процессора
cpufreq=dom0-kernel cpufreq=xen
Утилита xenpm [1]
[править] Оперативная память
Xen позволяет гибко распределять память между доменами. Распределение осуществляется с помощью специального механизма управления памятью, реализованного в balloon-драйвере. Основное требование — суммарный объём текущей оперативной памяти всех доменов не должен превышать объём оперативной памяти физической системы, на которой домены исполняются.
По умолчанию, домен 0 сначала получает весь доступный объём оперативной памяти, а потом, по мере необходимости, при старте других доменов, его начинают снижать. Это делает специально предназначенный для такой работы balloon-драйвер.
Можно выделить домену 0 определённый объём памяти при его старте. Впоследствии он сможет снижаться, но выше этого значения домену память получить не удастся.
Объём памяти, выделяемой домену 0, задаётся как параметр dom0_mem гипервизора Xen, в килобайтах.
Пример секции конфигурационного файла menu.lst загрузчика GRUB:
title Xen 3.2-1-i386 / Debian GNU/Linux, kernel 2.6.18-4-xen root (hd0,0) kernel /boot/xen-3.2-1-i386.gz dom0_mem=1200000 module /boot/vmlinuz-2.6.18-4-xen-686 root=/dev/sda1 ro console=tty0 module /boot/initrd.img-2.6.18-4-xen-686 savedefault
В этом примере домен 0 при старте будет в объёме оперативной памяти до 1.2G.
Снижение будет производиться до величины dom0-min-mem, заданной в конфигурационном файле /etc/xen/xend-config.sxp. Здесь величина памяти указывается в мегабайтах. Если в качестве значения указан 0, уменьшение памяти домена 0 выполняться не будет.
Пример настройки:
(dom0-min-mem 0)
Объём памяти, выделяемой остальным доменам (то есть, виртуальным машинам), задаётся в их конфигурационных файлах с помощью параметра memory. Параметр может быть указан с суффиксом B, K, M или G, что означает байты, килобайты, мегабайты или гигабайты соответственно. По умолчанию подразумевается, что в конфигурационном файле домена объём памяти указан в мегабайтах.
Впоследствии этот размер можно изменить прямо для работающего домена при помощи команды:
xm mem-set <domain-id> <mem>
Подняться выше заданного в конфигурационном файле значения без дополнительных хитростей не получится. Самая простая хитрость — задавать при старте домена большое значение памяти, потом его сразу же снижать, а потом повышать по мере необходимости.
Более правильный способ — использовать параметр конфигурационного файла домена maxmem, и передавать ядру гостевой системы (при условии что это Linux) параметр mem:
$ grep mem /etc/xen/dhcp memory = 128 maxmem = 512 extra = "mem=512M"
Система при старте получает 128 MB ОЗУ, но она сможет корректно отработать увеличение памяти до 512 MB.
$ sudo xm create dhcp Using config file "/etc/xen/dhcp". Started domain dhcp $ sudo xm list Name ID Mem VCPUs State Time(s) Domain-0 0 1171 1 r----- 5274.5 dhcp 8 128 1 -b---- 2.8
Гостевая операционная система видит 128MB:
$ sudo xm console dhcp
Debian GNU/Linux lenny/sid dhcp tty1
dhcp login: root
Password:
dhcp:~# free
total used free shared buffers cached
Mem: 131220 33132 98088 0 1524 12204
-/+ buffers/cache: 19404 111816
Swap: 0 0 0
Увеличиваем объём доступной домену оперативной памяти:
%$ sudo xm mem-set dhcp 256 %$ sudo xm list Name ID Mem VCPUs State Time(s) Domain-0 0 1171 1 r----- 5329.8 dhcp 8 256 1 -b---- 2.9
Гостевая операционная система теперь видит 256MB:
$ sudo xm console dhcp
dhcp:~#
dhcp:~#
dhcp:~# free
total used free shared buffers cached
Mem: 262144 33336 228808 0 1620 12228
-/+ buffers/cache: 19488 242656
Swap: 0 0 0
|
|
В настоящий момент изменение памяти на лету НЕ поддерживает ядро Linux, работающее через pv-ops. Это означает, в частности, что паравиртуальные ядра 2.6.24 и 2.6.25 не смогут увидеть изменение памяти в домене. |
[править] Автоматизация распределения памяти, swapping и memory overcommitment
Процессор, канал доступа к дисковой подсистеме и к сети можно разделять между доменами, но с памятью так сделать намного труднее. Для динамического распределения памяти между доменами используется selfballooning.
[править] Дисковая подсистема
- Основная статья: Приоритезация ввода/вывода в Xen
Приоритезация обращений доменов Xen к дисковой подсистеме в настоящее время может выполняться двумя способами:
- средствами планировщика CFQ Linux (подробнее: Приоритезация ввода/вывода в Xen);
- средствами контроллера dm-band (подробнее: Dm-band);
Первый способ более простой, и работает в любой современной системе (CFQ появился в 2.6.13); второй — более мощный, но требует инсталляции dm-band.
[править] Сеть
Распределение сетевых ресурсов между виртуальными машинами выполняется штатными средствами управления трафиком хост-системы. В частности, с помощью механизмов QoS.
Подробнее:
[править] Прямой доступ к устройствам
[править] PCI-устройства
В режиме нормальной работы Xen-инсталляции все устройства (дисковая подсистема, сетевые адаптеры и проч.) видны напрямую только домену 0. Гостевые домены могут пользоваться этими устройствами, но не напрямую, а только опосредованно, при помощи механизмов, предоставляемых доменом 0.
В некоторых случаях, однако, бывает необходимо чтобы гостевой домен увидел устройство сам, без посредников. Такое, в частности, возможно, когда гостевая система должна использовать специфический драйвер для доступа к специальным функциям устройства, недоступным через паравиртуальный интерфейс.
Для проброса PCI-устройств необходимо чтобы:
- в ядре привилегированного домена (домена 0) присутствовала поддержка PCI backend;
- в ядрах, которые будут запускаться в пользовательских доменах и которые собираются использовать PCI-устройства, присутствовала поддержка PCI frontend.
В XenLinux PCI backend включается в конфигурационной секции Xen, а PCI frontend включается в зависимой от архитектуры секции "Bus Options". Можно вкомпилировать вместе в одно ядро поддержку backend'а и поддержку frontend'а. Они друг другу не мешают. Обычно в ядрах, которые входят в состав распространённых дистрибутивов, поддержка есть по умолчанию.
PCI-устройство, которое передаётся непривилегированному домену, должно быть скрыто от backend-домена (обычно домена 0) — не должно так получиться, что домен 0 загрузит случайно драйвер устройства, и тот начнём работать с этим устройством.
Для этого нужно указать PCI backend, какое устройство он должен скрыть. Он привязывает себя как драйвер к устройству и тем самым гарантирует, что никакие другие драйверы устройств к нему не привяжутся. То есть, в действительности, устройства не скрываются от домена 0, просто они никак им не используются.
Информация о том, какое устройство должно скрываться, передаётся как параметр ядра pciback.hide в его командной строке, задающейся через загрузчик. PCI-устройства идентифицируются шестнадцатеричными числами слот/функция (slot/function), в Linux эти номера можно определить с помощью программы lspci. Их можно указывать с информацией о номере домена или без неё:
(bus:slot.func) например (02:1d.3)
(domain:bus:slot.func) например (0000:02:1d.3)
Пример параметров ядра Linux, скрывающих два PCI-устройства:
root=/dev/sda4 ro console=tty0 pciback.hide=(02:01.f)(0000:04:1d.0)
Устройство можно отобрать у драйвера и скрыть его и без перезагрузки:
# echo -n 0000:05:02.0 > /sys/bus/pci/drivers/3c905/unbind # echo -n 0000:05:02.0 > /sys/bus/pci/drivers/pciback/new_slot # echo -n 0000:05:02.0 > /sys/bus/pci/drivers/pciback/bind
Сначала устройство отвязывается от драйвера, который его держит. Затем оно привязывается к PCI backend.
Просмотреть к какому устройству привязан какой драйвер можно командой:
%# ls -l /sys/bus/pci/devices/*/driver
После того как устройство освобождено от домена 0, его можно передавать внутрь гостевого домена. Для того чтобы передать устройство внутрь домена, в его конфигурационном файле нужно указать строку:
pci=['05:02.0']
Когда гостевой домен будет запущен, проверить видит ли он проброшенное внутрь устройство, можно командой:
%# lspci
Если PCI-устройств для проброски внутрь доменов не хватает, можно воспользоваться расширителями PCI. Подробнее об этих устройствах [2], [3], [4], [5].
[править] SCSI-устройства
Подробнее:
[править] USB-устройства
Подробнее:
 |
|
|---|
