Проброс блочных устройств в VM
Это скорее надо не для внешних, а для внутренних хардов, установленных в тот же сервер.
Для начала создаём каталог, в котором будут симлинки на нужные нам блочные устройства:
# mkdir /srv/block-devices
- Теперь делаем его SR типа udev с content-type=disk:
# xe sr-create name-label="Block devices" name-description="Блочные устройства, которые хотим пробросить с гипервизора в виртуалки" type=udev content-type=disk device-config:location=/srv/block-devices - Добавляем нужное нам устройство:
# ln -s /dev/sdb /srv/block-devices/sdb (какой нужен хард)
- Затем пересканируем SR, дабы автоматически создались нужные VDI:
# xe sr-scan uuid="uuid_нашего_SR" Можно табом посмотреть, какие вообще есть. - Должен появится новый VDI с name-label "Unrecognised bus type" на нашем SR.
Убедиться в этом можно командой:
# xe vdi-list sr-uuid="uuid_нашего_SR" Помогут команды:
# xe vdi-list
# xe vdi-list sr-name-label=имя
Затем в XenCenter --> нужная нам VM --> Storage --> Attach Disk - выбираем появившийся хард, затем инициализируем его в винде в диспетчере дисков.
Только в таком случае винда скорее всего снесёт всю разметку, что на нём есть.
Также:
Подключение блочного устройства можно осуществить следующим образом:
# xm block-attach "domU" "real_dev" "virt_dev" "mode"
Где:
- "domU" - номер виртуального домена или его имя (получить можно, выполнив "xm list");
- "real_dev" - блочное устройство в хост-системе (например, первый раздел flash-drive подключился как /dev/sdc1. В этом случае "real_dev" будет выглядеть так "phy:sdc1");
- "virt_dev" - блочное устройство в гостевой системе (для рассмотренного примера будет выглядеть как "sdc1"). Нужно проследить, чтобы не было конфликтов с уже существующими в гостевой системе устройствами;
- "mode" - режим работы ("r" - только чтение, "w" - чтение и запись).
Добавить дополнительный жесткий диск в XenServer как отдельное хранилище
- Создаем на новом диске разметку под LVM (ни разделы при этом, ни таблицу разделов создавать не требуется!):
pvcreate /dev/sdb --config global{metadata_read_only=0} - Добавляем диск как отдельное хранилище:
xe sr-create content-type=user host-uuid=[жмем таб] type=lvm device-config-device=/dev/sdb name-label="SAS Local storage" - После этого запрашиваем листинг имеющихся стораджей:
xe sr-list type=lvmuuid ( RO) : c7f66fc2-369e-48d7-8550-e15674bffde3
name-label ( RW): SAS Local storage
name-description ( RW):
host ( RO): xen
type ( RO): lvm
content-type ( RO): user
uuid ( RO) : 093e7a5c-1c38-258b-fb96-fe7cbb486ec0
name-label ( RW): Local storage
name-description ( RW):
host ( RO): xen
type ( RO): lvm
content-type ( RO): user
Все, после этого диск сразу появится в разделе "Disks and Storage Repositories", "Current Storage Repositories" с именем "SAS Local storage". Обращаю внимание, что этот локал сторадж не является default.
Установка ZABBIX-AGENTD
(rpm -ihv http://centos.l-sys.ru/6/i386/l-sys-repo-1.0-2.noarch.rpm)
В виду того, что centos.l-sys.ru последний раз, когда я устанавливал агента, не откликнулся - отыскал новый репозиторий: rpm -ivh http://repo.zabbix.com/zabbix/2.0/rhel/5/i386/zabbix-release-2.0-1.el5.noarch.rpm
rpm -ivh http://repo.zabbix.com/zabbix/2.0/rhel/5/i386/zabbix-2.0.12-1.el5.i386.rpm
rpm -ivh http://repo.zabbix.com/zabbix/2.0/rhel/5/i386/zabbix-agent-2.0.12-1.el5.i386.rpm
XCP-NG 8.2: rpm -ihv http://repo.zabbix.com/zabbix/5.2/rhel/7/x86_64/zabbix-agent-5.2.4-1.el7.x86_64.rpm yum install zabbix-agent
Открываем файл настроек и вписываем туда:
#/etc/zabbix/zabbix_agentd.conf
-=Начало вставки=-
Server=192.168.0.66 # IP-адрес или DNS-имя Zabbix-сервера
Hostname=HS4 # Имя хоста, которое должно совпадать с именем в
# Configuration -> Hosts в Веб-интерфейсе Zabbix
XenServer UserParameter=xe.vmlist,/opt/xensource/bin/xe vm-list | grep name-label | cut -d: -f2
UserParameter=xe.vmcountup,/opt/xensource/bin/xe vm-list | grep running | wc -l
UserParameter=xe.vmcountdown,/opt/xensource/bin/xe vm-list | grep halted | wc -l
UserParameter=xe.memory_total_kib,/opt/xensource/bin/xe host-data-source-query data-source=memory_total_kib
UserParameter=xe.memory_free_kib,/opt/xensource/bin/xe host-data-source-query data-source=memory_free_kib
UserParameter=xe.xapi_memory_usage_kib,/opt/xensource/bin/xe host-data-source-query data-source=xapi_memory_usage_kib
UserParameter=xe.xapi_free_memory_kib,/opt/xensource/bin/xe host-data-source-query data-source=xapi_free_memory_kib
UserParameter=xe.xapi_live_memory_kib,/opt/xensource/bin/xe host-data-source-query data-source=xapi_live_memory_kib
UserParameter=xe.xapi_allocation_kib,/opt/xensource/bin/xe host-data-source-query data-source=xapi_allocation_kib
UserParameter=xe.cpu3,/opt/xensource/bin/xe host-data-source-query data-source=cpu3
UserParameter=xe.cpu2,/opt/xensource/bin/xe host-data-source-query data-source=cpu2
UserParameter=xe.cpu1,/opt/xensource/bin/xe host-data-source-query data-source=cpu1
UserParameter=xe.cpu0,/opt/xensource/bin/xe host-data-source-query data-source=cpu0
UserParameter=xe.loadavg,/opt/xensource/bin/xe host-data-source-query data-source=loadavg
UserParameter=xe.vbd_xvda_write[*],/opt/xensource/bin/xe vm-data-source-query data-source=vbd_xvda_write uuid=$1
UserParameter=xe.vmi[*],/opt/xensource/bin/xe vm-data-source-query data-source=$1 uuid=$2
-=конец вставки=-
# chkconfig zabbix-agent on
# system-config-securitylevel-tui
> Добавить "10050:tcp" в список "Other ports".
service zabbix-agent start
У меня на CitrixXENserver понадобилось вот ещё что:
В файле /etc/sudoers закомментировать
Defaults requiretty
и добавить
zabbix ALL=NOPASSWD: /opt/xensource/bin/xe
В UserParameter после первой запятой добавить sudo
Настройка SNMP на Citrix XenServer 6.x
- Редактируем /etc/sysconfig/iptables
После строки
“-A RH-Firewall-1-INPUT -p udp –dport 5353 -d 224.0.0.251 -j ACCEPT”
добавляем:
-A RH-Firewall-1-INPUT -p udp --dport 161 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 123 -j ACCEPT - Запускаем:
service iptables restart - Редактируем /etc/snmp/snmpd.conf
Заменяем community на тот, который используется у на SNMP (по умолчанию - public).
# sec.name source community
com2sec notConfigUser default public - Добавляем в автозапуск:
chkconfig snmpd on - Запускаем:
service snmpd restart - Проверяем с другого компа:
snmpwalk -v 2c -c public IP-адрес_сервера
Подключение жёстких дисков из одного Xen-сервера на другой
Вводная: Есть два однотипных сервера. На обоих установлен XenServer 6.2. Сервера не в пуле. В качестве сторейджов используется локальное хранилище (HDD установленные в сам сервер). После смерти одного из серверов, необходимо поднять работу виртуальных серверов на работающем.
Решение:
- Корректно гасим рабочий.
- Берём жёсткие диски из умершего сервера и вставляем в рабочий (в данной статье не рассматривается вопрос рейда, если он у вас есть, то обязательно проверьте, что он корректно определился). Включаем сервер.
- После загрузки системы проверяем, что диск подключился
fdisk -l - Далее вводим команду
pvdisplay - Смотрим на поле VG Name — VG_XenStorage-12660091-343d-2107-5dea-bb021055c07c
(Нам нужна подстрока после «VG_XenStorage-» у вас будет ДРУГОЙ UUID)
xe sr-introduce uuid=12660091-343d-2107-5dea-bb021055c07c type=lvm name-label="Local storage REPAIR" content-type=user
Выйдет uuid подключенного сторейджа — 12660091-343d-2107-5dea-bb021055c07c. Обычно он равен номеру VG Name, но не всегда. Лучше проверить. - ll -l /dev/disk/by-id
Выйдет список дисков. Нам нужен третий (первый сам XEN, второй его резервная копия — третий диск с нужными нам образами) - xe host-list
запоминаем UUID - xe pbd-create host-uuid=f53d07d5-335a-434b-93ff-1a66faec9c7a sr-uuid=12660091-343d-2107-5dea-bb021055c07c device-config:device=/dev/disk/by-id/scsi-360050760580b2b901ba7bdcb10981ed2-part3
Выйдет UUID - 45593530-bbae-c903-12e4-96bda77bc514 - xe pbd-plug uuid=45593530-bbae-c903-12e4-96bda77bc514
- Проверяем, что сторейдж корректно подключился и у него в списке есть диски виртуальных машин.
Можно переходить к созданию виртуальных машин и после создания сделать Attach к образам.
PS: В результате скорость восстановления работоспособности существенно возрастает. По сути теперь она равна скорости
- Выключить
- Переставить диски.
- Загрузиться.
- Прописать сторейдж и виртуалки. На тестах у нас уходило по 7-9 минут до загрузки (но надо учитывать, что это спокойная обстановка тестирования, плюс я был возле сервера).
PS2: Данная инструкция больше вредна чем полезна, так как делается всё не совсем корректно с точки зрения архитектуры. И надо точно понимать, что вы делаете. Более правильным был бы подход с установкой дисковой полки и настройки high availability-cluster. Тогда бы он делал это всё автоматически. Но пару моментов -
- а) Дисковой полки не было
- б) В случае использовании дисковой полки нужно ставить их парой в зеркале, что удорожает существенно, иначе выход из строя полки убивает нам всю работу (плюс считаем цену на нормальные FC-коммутаторы и сетевые)
- в) есть варианты с использованием DRBD, но при тестах скорость работы и дисковых операций падали ОЧЕНЬ существенно
PS3: Надо не забывать, что на обоих серверах нужно оставлять некоторое количество памяти и пространства в сторейджах для создания виртуальных машин после переноса. И если память вы сможете переопределить (при выключенных виртуалках), то с пространством на жёстких всё несколько сложнее и дольше.
PS4: Вообще (если у вас ни какой-нибудь хитрый рейд) можно подключить диски "на горячую" (к примеру через rescan-scsi-bus.sh или что-то подобное). И далее идти с первого пункта. Что сэкономит нам некоторое количество времени на выключение-включение.
PS5: Есть мнение, что если у вас есть только два сервера, то можно проделать данные операции ДО возникновения проблем на каждом сервере, и затем просто игнорировать варнинги в логе о "неподключающемся" сторейдже. И в случае проблем, надо будет просто "выключить, переставить диски, включить". Но я данный вопрос не тестировал.
XenServer: скрипт очистки диска Dom0 после установки обновлений
После установки обновлений можно очистить место на диске Dom0 XenServer.
#!/bin/sh
PATCHLIST=`xe patch-list params=uuid | awk '{print $5}'`
for UUID in $PATCHLIST
do
echo "Cleanup patch $UUID"
xe patch-pool-clean uuid=$UUID
done
Идея скрипта: http://discussions.citrix.com/topic/371712-xenserver-low-root-disk-space-cleaup-script-for-patches/
Для работы скрипта на единичном сервере без пула можно использовать команду xe patch-clean, но фактически patch-pool-clean отрабатывает корректно.
Проверяем свободное место на диске df -h и содержимое каталога /var/patch/
# ls /var/patch/
applied
Содержимое каталога /var/patch/applied не трогать и не удалять!
Также не забываем периодически удалять лог-файлы XenServer.
Xenserver Root Disk Cleanup
Заполнение корневого раздела Xenserver может вызвать множество проблем, включая зависания запущенных виртуальных машин. Необходимо периодически следить за заполнением диска и проводить следующие работы:
Контроль места на диске
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 4.0G 2.2G 1.6G 59% /
Удаление применённых пакетов обновлений и hotfix
> Для Xenserver 6.2 и выше. Это освобождает место, корректно очищая папку /var/patch/
# xe patch-list params=uuid
uuid ( RO) : d3c08fcb-daa0-4410-bdb2-c298109e88ad
...
# xe patch-clean uuid=
Удаление старых лог-файлов
# cd /var/log/
# rm -rf *.gz
Очистка каталога /tmp
# cd /tmp/
# rm -rf *.log
Если виртуальная машина "застряла" и не выключается
Определяем ID её домена:
# xl list (смотрим на столбец ID напротив имени машинки, это просто число)
или даже
# xl list | grep MyMachine
Грохаем её домен:
# xl destroy ID
Эта команда отдаст распоряжение системе принудительно выключить виртуалку.
Полезные команды
xe-toolstack-restart - перезагружает обвязку управления, не затрагивая сами виртуалки
Импорт VM из командной строки
Импорт объёмных виртуальных машин через XenCenter происходит с сильно заниженной скоростью. В ходе разбора полётов было обнаружено, что в выводе команды top на хосте мастера пула XenServer фигурировали stunnel и xapi с загрузкой CPU под 100% (по умолчанию все соединения между XenCenter и хостом с XenServer шифруются 256-bit AES SSL).
Импорт виртуальной машины из CLI с отключением шифрования передачи (--nossl) позволяет достичь существенного ускорения процесса.
xe --nossl -s xen-master -u root -pw password vm-import filename=/mnt/VM.xva sr-uuid=b3bb3595-02f6-e68f-52fb-d8fb77cb1e53 preserve=true
cc90231d-e0c6-1249-5a2a-08d877af9df4
где:
sr-uuid= UUID нужной SR для сохранения диска VM.
cc90231d-e0c6-1249-5a2a-08d877af9df4 - результат выполнения команды, UUID импортированной виртуальной машины.
Проброс контроллера PCI в виртуалку
Перво-наперво необходимо убедиться в том, что в BIOS включены IOMMU (для AMD) VT-D (для Intel) и прочие "штучки" для виртуализации. Иначе, как говорил Акопян, ничего не получится.
Дальше загружаемся в консоль и смотрим список pci-устройств:
[root@xen ~]# lspci -D
Внимательно читаем вывод, находим своё устройство и запоминаем что-то наподобие
0000:18:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller 172Xa/172Xb (rev 01)
Это мой контроллер PCI-E NVMe-диска.
Теперь нужно позаботиться о том, чтобы его не использовал сам сервер XCP-NG:
[root@xen ~]# /opt/xensource/libexec/xen-cmdline --set-dom0 "xen-pciback.hide=(0000:18:0.0)"
Перезагружаем сервер. Можно, наверное, как-то иначе применить внесённые изменения, но я не нашёл как именно.
Теперь убедимся в том, что устройство "готово для проброски":
[root@xen ~]# xl pci-assignable-list
0000:18:00.0
Теперь нужно узнать uuid виртуалки и дать команду:
[root@xen ~]# xe vm-param-set other-config:pci=0/0000:04:01.0 uuid=(vm uuid)
У меня после этого виртуальная виндовс увидела NVMe и сумела показать на нём вполне приличную "скорострельность"
ZFS на гипервизоре
XCP-NG vr. 8.2 умеет размещать виртуальные диски для виртуальных машин еа файловой системе ZFS
Это даёт админу весьма широкий спектр возможностей по управлению этими самыми дисками. К примеру - снапшоты, не требующие большого места на дисках.
Для того, чтобы установить ZFS на сервер гипервизора и создать хранилище, размещённое на отдельном жёстком диске я сделал так:
yum install zfs
modprobe -v zfs
zpool create -o ashift=12 -m /volumes/ZFSstorage ZFSstorage /dev/sdb
xe sr-create host-uuid= type=zfs content-type=user name-label=ZFSstorage device-config:location=/volumes/ZFSstorage
Здесь
- /dev/sdb - жёсткий диск, предназначенный мною для создания как раз ZFS-хранилища
- ZFSstorage - плод моей буйной фантазии для именования этого хранилища
- /volume/ZFSstorage - место в дереве для хранилища
Автозапуск VM-ок
Сначала включаем из командной строки самого хоста:
# xe pool-param-set uuid= other-config:auto_poweron=true
Потом включаем для самой виртуалки:
# xe vm-param-set uuid= other-config:auto_poweron=true
