как показала практика — порой быстрый отклик браузера с открытыми в нем однокакашнегами намного важнее работающего в фоне на другом сервере задания по переброске данных из одной базы в другую. Под катом расово правильный скрипт назначения приоритета виртуалкам.

Итак, выставление веса домена (приоритета использования процессорного времени) обычно помогает не особо, т.к. помимо этого нам также нужен приоритет записи на диск, учитывая, что обычно дисковая подсистема является самым слабым звеном в системе. Благодаря планировщику ввода/вывода CFQ3 мы можем указать, какой процесс быстрее получит доступ к диску. Общий принцип, в реалиях Xen описан здесь и здесь. Но как всегда есть нюансы. Во-первых: как и приоритет использования процессорного времени, ionice нам придется запускать вручную, что не очень хорошо, если у нас машина часто перезагружается. Во-вторых: выставление приоритета ввода/вывода в realtime приведет к тому, что сошедшая с ума виртуалка попросту может подвесить сам гипервизор. Пример описан здесь. В-третьих: мы можем однозначно определить принадлежность процесса драйвера блочного устройства blkback к конкретной виртуальной машине лишь в том случае, когда определим номер домена, указанный в параметрах запуска процесса qemu-dm.

Приступим. После запуска домена

xm create serverNNN

нам необходимо назначить ему вес, например:

xm sched-credit -d serverNNN -w 1024

теперь, если мы не указывали ранее вес для других доменов — процессорное время будет предоставляться в первую очередь домену serverNNN.

Далее назначим нужной виртуалке serverNNN приоритет ввода/вывода best-effort (2). Под виртуальной машиной имеются в виду процесс qemu-dm и драйвера блочных устройств blkback, т.к. запущенная виртуалка в процессах выглядит примерно так:

  835 ?        SLl   13:59 /usr/lib/xen-4.0/bin/qemu-dm -d 1259 -domain-name serverNNN .........
 6322 ?        S      0:06 [blkback.1259.hda]
 6323 ?        S      0:01 [blkback.1259.hdb]

исходя из этого рассмотрим скрипт назначения приоритета драйверам блочных устройств для нашей виртуалки:

DomainNumber=($(ps aux | grep qemu-dm | grep -v grep | grep serverNNN | awk '{print $13}'))
blkbacks=($(ps aux | grep blkback.${DomainNumber} | grep -v grep | awk '{print $2}'))
for blkback in $(seq 0 $((${#blkbacks[@]} - 1)))
do
  ionice -p ${blkbacks[$blkback]} -c 2
done

здесь мы сначала узнаем номер виртуальной машины (параметр -d запуска qemu-dm), чтобы в дальнейшем искать номера процессов blkback.[номер виртуальной машины], и уже заполучив pid драйвера — скармливаем этот pid планировщику

после этого нужно не забыть назначить приоритет собственно процессу qemu-dm нашей виртуальной машины:

DomainPid=($(ps aux | grep qemu-dm | grep -v grep | grep serverNNN | awk '{print $2}'))
ionice -p ${DomainPid} -c 2

Есть также второй вариант: назначить всем остальным доменам, кроме нужного, приоритет idle (3). Но учтите, это чревато вылетом их в синий экран в случае запуска на гипервизоре чего-то, что будет интенсивно использовать жесткий диск, например, dd. Но работает такая схема немного лучше предыдущей. Тут скрипт изменяется таким образом, что мы сначала в цикле строим массив всех номеров виртуальных машин кроме приоритетной, а затем так же в цикле ищем pid драйверов блочных устройств для каждой виртуалки:

DomainNumbers=($(ps aux | grep qemu-dm | grep -v grep | grep -v serverNNN | awk '{print $13}'))
for DomainNumber in $(seq 0 $((${#DomainNumbers[@]} - 1)))
do
  blkbacks=($(ps aux | grep blkback.${DomainNumbers[$DomainNumber]} | grep -v grep | awk '{print $2}'))
  for blkback in $(seq 0 $((${#blkbacks[@]} - 1)))
  do
    ionice -p ${blkbacks[$blkback]} -c 3
  done
done

после этого в цикле назначаем приоритет собственно процессам qemu-dm:

DomainPids=($(ps aux | grep qemu-dm | grep -v grep | grep -v serverNNN | awk '{print $2}'))
for DomainPid in $(seq 0 $((${#DomainPids[@]} - 1)))
do
  ionice -p ${DomainPids[$DomainPid]} -c 3
done