http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/installation.html#boot_from_san
Загрузка с SAN предоставляет ряд преимуществ - высокую производительность, избыточность и консолидацию ресурсов. В такой конфигурации загрузочный том находится в SAN, а не на локальном диске хоста. Бездисковый хост взаимодействует с SAN через соответствующий адаптер шины - host bus adapter (HBA). BIOS адаптера HBA содержит параметры, необходимые для того чтобы хост обнаружил загрузочный том.
Для загрузки с SAN требуется дисковый массив с интерфейсом Fibre Channel или iSCSI и соответствующий адаптер. Для создания полностью избыточной конфигурации нужно обеспечить несколько путей для доступа к массиву. Для этого на массиве нужно сконфигурировать поддержку multipath и включить multipathing на хосте XenServer после установки.

Для того чтобы установить XenServer на удаленный том SAN c multipathing:
- На экране приветствия (Welcome to XenServer) нажмите F2.
- At the boot prompt, enter multipath

Для того чтобы включить filesystem multipathing при установке PXE необходимо добавить device_mapper_multipath=yes в файл конфигурации PXE Linux. Пример файла:

default xenserver
label xenserver
  kernel mboot.c32
  append /tftpboot/xenserver/xen.gz dom0_mem=752M com1=115200,8n1 \
  console=com1,vga --- /tftpboot/xenserver/vmlinuz \
  xencons=hvc console=hvc0 console=tty0 \ 
  device_mapper_multipath=yes \
  --- /tftpboot/xenserver/install.img

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#networking-standalone_host_changing_network_config
Для того, чтобы изменить адаптер, используемый для управления хостом XenServer.
1. С помощью команды pif-list определите физический интерфейс (PIF) соответствующий сетевому адаптеру, который будет использоваться для управления. Команда вернет идентификаторы UUID всех PIF.

xe pif-list

2. С помощью команды pif-param-list проверьте конфигурацию адресов IP. Если необходимо - с помощью команды pif-reconfigure-ip сконфигурируйте IP.

xe pif-param-list uuid=<pif_uuid>

3. С помощью команды host-management-reconfigure задайте PIF, который должен использоваться для управления. Если хост входит в состав пула, то эту команду нужно выполнять из консоли хоста входящего в пул.

xe host-management-reconfigure pif-uuid=<pif_uuid>

Для отключения интерфейса удаленного управления используйте команду host-management-disable.

http://support.citrix.com/article/CTX121235
Настройка в XenCenter
1. В XenCenter, кликните правой кнопкой на хосте и выберите Management Interfaces.
2. Из списка Network выберите сетевой адаптер, который должен быть назначен интерфейсом управления. Сконфигурируйте его параметры.

Настройка в xsconsole
1. В консоли сервера введите xsconsole. Запустится консоль управления хостом.
2. Выберите Network and Management Interfaces. Отобразится теуущий интерфейс управления - Network 0 или eth0. Нажмите Enter.
3. Выберите Configure Management Interface и нажмите Enter.
4. Введите учетные данные пользователя, имеющего права для настройки интерфейсов XenServer.
5. Выберите физический интерфейс, который должен стать интерфейсом управления (например eth1) и нажмите Enter.
6. Выберите способ конфигурирования - DHCP, DHCP with Manually Assigned Hostname, или Static IP address.
7. Если выбран Static - укажите IP address, Netmask, Gateway, и Hostname, и нажмите Enter.

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#networking-standalone_host_changing_network_config

xe host-set-hostname-live host-uuid=<host_uuid> host-name=<host-name>

Доменное имя изменится автоматически.

Конфигурация сетевого интерфейса может быть изменена из командной строки с помощью команды pif-reconfigure-ip.

pif-reconfigure-ip uuid=<uuid_of_pif> [ mode=<dhcp> | mode=<static> ] \
gateway=<network_gateway_address> IP=<static_ip_for_this_pif> \
netmask=<netmask_for_this_pif> [DNS=<dns_address>]

Если указан режим

mode=<dhcp>

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

mode=<static>

, то нужно указать и все остальные параметры -

gateway=<network_gateway_address> IP=<static_ip_for_this_pif> netmask=<netmask_for_this_pif> [DNS=<dns_address>]

.

Для изменения IP-адреса используется команда pif-reconfigure-ip.
Например:

xe pif-reconfigure-ip uuid=<pif_uuid> mode=DHCP

Затем с помощью команды host-list следует убедиться, что хост успешно переподключился к мастер-хосту пула и видны все хосты пула.

xe host-list

Изменение IP-адреса мастер-хоста пула требует дополнительных действий для того, чтобы каждый хост пула смог использовать измененный адрес.

xe pif-reconfigure-ip uuid=<pif_uuid> mode=DHCP

После изменения IP-адреса мастер-хоста все члены пула перейдут в сосотояние emergency mode, т.к. не смогут соединиться с мастер-хостом.
Для того чтобы мастер-хост смог уведомить членов пула об изменении своего IP-адреса используется команда pool-recover-slaves

xe pool-recover-slaves

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#ad_int_configuring
XenServer поддерживает аутентификацию пользователей в домене Windows 2003 или более новой.

Для аутентификации в Active Directory на хосте XenServer должны быть прописаны серверы DNS, используемые в домене. В некоторых случаях, необходимые параметры DNS могут раздаваться централизовано, с помощью DHCP. Citrix рекомендует использовать DHCP для правильного конфигурирования хостов XenServer (например не следует использовать имена хостов типа localhost или linux).

Учитывайте следующее:
- Хосты XenServer прописываются в базу данных AD с помощью имен хостов (hostname). Следовательно, если два хоста XenServer присоединятся к домену с одинаковыми именами, то второй присоединившийся сервер перезапишет запись в AD первого сервера, независимо от того, входят сервера в один пул или нет. В результате - у первого сервера аутентификация AD работать не будет.
- Использовать одинаковые hostname у двух хостов XenServer можно, если они входят в разные домены.
- Хосты XenServer могут быть в разных временных зонах (time-zones), т.к. время на хостах сравнивается в формате UTC. Для того чтобы гарантировать синхронизацию времени в пределах домена следует использовать один и тот же сервер времени NTP на хостах XenServer и сервере AD.
- В пределах пула не поддерживается смешанная аутентификация. Это означает, что невозможно создать пул, в котором часть серверов входят в домен, а часть нет.
- Для взаимодействия с сервером домена AD хосты XenServer используют протокол Kerberos. Таким образом, хосты XenServer не смогут работать с серверами Active Directory, на которых отключен протокол Kerberos.
- Для корректной работы аутентификации XenServer в Active Directory важно, чтобы часы хостов XenServer были сонхронизированы с часами сервера AD. При присоединении хоста XenServer к домену синхронизация часов проверяется и если часы идут неверно, то присоединение не удастся.

Если вы включили для пула аутентификацию AD и затем присоединяете к пулу хост XenServer, то потребуется присоединить новый хост XenServer к домену. Для присоединения понядобится ввести учетные данные пользователя, обладающего привилегиями, достаточными для присоединения хоста к домену.

Если между сервером AD и хостами XenServer есть межсетевой экран (firewall), то для корректной работы нужно открыть порты для исходящего трафика от хостов к серверу AD:

Port Protocol Use
53 UDP/TCP DNS
88 UDP/TCP Kerberos 5
123 UDP NTP
137 UDP NetBIOS Name Service
139 TCP NetBIOS Session (SMB)
389 UDP/TCP LDAP
445 TCP SMB over TCP
464 UDP/TCP Machine password changes
3268 TCP Global Catalog Search

Также как и машины Windows, Likewise автоматически обновляет пароль учетной записи хоста XnServer каждые 30 дней (или в соответствии с заданной политикой). Дополнительная информация - http://support.microsoft.com/kb/154501.

Аутентификация в AD может быть включена как с помощью XenCenter, так и в CLI:

    xe pool-enable-external-auth auth-type=AD \
      service-name=<full-qualified-domain> \
      config:user=<username> \
      config:pass=<password>

Пользователь должен обладать правами добавления/удаления учетных записей компьютеров в домене (Add/remove computer objects or workstations privileges).

Испоьзуйте XenCenter для отключения аутентификации Active Directory или такую команду CLI:

    xe pool-disable-external-auth

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/installation.html#installing_xs_host
Задать временную зону и сервер с которым XenServer будет синхронизировать часы можно при установке XenServer. Кроме того, текущее время можно установить и вручную.
Задать сервер NTP можно как вручную, так и использовать заданный в конфигурации DHCP.

http://support.citrix.com/article/CTX116307
Если при работе XenServer с удаленной административной консолью возникают ошибки SSL, возможно, часы хоста XenServer несихронизированы с часами хоста на котром исполняется удаленная консоль.
Решить эту проблему можно установив локальный NTP сервер, с которым будут синхронизированы хосты XenServer и хост с управляющей консолью.
- Установите пакет сервера NTP. Он может называться примерно так: ntp- и номер версии. Например - ntp-4.2.0.xxxxx.
- После установки отредактируйте файл /etc/ntp.conf и укажите в нем серверы stratum1 и stratum2, с которыми будет синхронизирован локальный сервер NTP:

server yourntp.server.org # stratum1
    server secondntp.some.org # stratum2

- Укажите параметры доступа, для того чтобы разрешить использование этих серверов на вашем сервере. Приведенные строки запрещают изменять информацию во время исполнения или делать запросы к вашему серверу NTP:

    restrict yourntp.server.org mask 255.255.255.255 nomodify notrap noquery
    restrict secondntp.server.org mask 255.255.255.255 nomodify notrap noquery

- Если вы планируете использовать этот сервер для синхронизации времени в вашей локальной сети - следует разрешить запросы синхронизации из этой сети. Добавьте:

restrict 192.168.0.1 mask 255.255.255.0 nomodify notrap

^Примечание: тут отсутствует параметр noquery^
- Запустите сервис с помощью команды:

service ntp start

- С помощью следующей команды включите автозагрузку сервиса:

chkconfig ntpd on

- Укажите имя этого сервера при установке XenServer на хост. На уже установелнном хосте XenServer отредактируйте файл /etc/ntp.conf и добавьте в него строку:

server ntp-server_ip

- С помощью следующей команды синхронизируйте хост XenServer с заданным сервером NTP:

ntpdate -u NTP_server_ip

- С помощью следующей команды убедитесь, что хост XenServer использует правильный сервер NTP:

ntpq -p

Есть возможность сменить таймзону на рвботающем хосте XenServer.
Информация о текущей таймзоне задается в файле /etc/localtime. Этот файл является симлинком (symlink) на конкретный файл таймзоны, хранящийся в папке /usr/share/zoneinfo. В этой папке хрянятся файлы соответствующие разным таймзонам. Например, если при установке выбрана зона America и location New York, то в /etc/localtime будет ссылаться на /usr/share/zoneinfo/America/New_York.
Если нужно сменить таймзону, то нужно просто перезаписать симлинк /etc/localtime.

В нижеприведенном примере изменяется таймзона с America/New York на Pacific/Auckland:

1. Войдите на хост XenServer с учеткой root.
2. Проверьте текущую таймзону:

# date
Wed Dec 6 15:54:01 EST 2006

# ls -l /etc/localtime
lrwxrwxrwx 1 root root 36 Dec 6 15:55 /etc/localtime --> /usr/share/zoneinfo/America/New_York

3. Переименуйте текущий симлинк на всякий случай:

# mv /etc/localtime /etc/localtime.bak

4. Создайте новый симлинк на нужный файл таймзоны:

# ln -s /usr/share/zoneinfo/Pacific/Auckland /etc/localtime

5. Убедитесь, что новый симлинк создался:

# ls -l /etc/localtime
lrwxrwxrwx 1 root root 36 Dec 6 10:04 /etc/localtime --> /usr/share/zoneinfo/Pacific/Auckland

6. Убедитесь, что таймзона сменилась:

# date
Wed Dec 7 10:05:41 NZDT 2006 

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#cli-xe-commands_hostselectors
Многие команды команды конфигурирующие хосты XenServer требуют явного указания хоста, к которому происходит обращение. Самый простой способ указать имя хоста с помощью аргумента host=uuid_or_name_label. Кроме того, хосты могут быть указаны с помощью фильтрации полного списка хостов по значениям заданных полей. Например - указав enabled=true можно выбрать только те хосты, у которых включено заданное свойство. Если фильтру соответствуют несколько хостов и операция должна быть выполнена над всеми ними, то следует указывать опцию

--multiple

. Полный список параметров хостов может быть получен командой xe host-list params=all. Если в команде явно не указан никакой хост, то команда будет выполнена на всех хостах пула.

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/installation.html#applying_hotfixes
Между релизами XenServer, Citrix выпускает апдейты и хотфиксы (updates and hotfixes). Хотфиксы исправляют отдельные ошибки, а апдейты содерждат в себе множественные кумулятивные исправления и обновления функционала.
Публичные хотфиксы и апдейты бывают доступны для скачивания из Citrix Knowledge Center. Конкретная информация и инструкции, касающиеся каждого пакета также публикуются.
Хотфиксы и апдейты как правило устанавливаются с минимальным воздействием на инфраструктуру XenServer. При использовании пула серверов XenServer можно сократить время простоя обновляя сервера по одному, перемещая работающие на них виртуальные машины на другие сервера. XenCenter позволяет осуществить эти действия в правильной последовательности автоматически. При использовании интерфейса командной строки xe, эти действия нужно делать вручную.

Перед применением обновлений важно знать:
- Лучше всего применять обновления в течение короткого промежутка времени, т.к. работа пулов в смешанном режиме (когда одни сервера уже имеют обновления, а другие нет) не поддерживается.
- Citrix рекомендует, перед применением обновлений перезагрузить каждый хост XenServer, что позволит убедиться в его работоспособности и корректности конфигурации.

- Citrix также рекомендует сделать резервную копию состояния обновляемого пула (или индивидуальных хостов).

Перед обновлением:
- Войдите на сервер с учетной записью, имеющей полные права (Pool Administrator или локальный root).
- У всех останавливаемых виртуальных машин нужно извлечь CD/DVD (сделать empty).
- Если включена высокая доступность (HA) - отключите ее.

Если планируется применить обновление с помощью XenCenter, то XenCenter запустит ряд проверок, которые позволят убедиться, что хост готов к обновлению и совместим с данным обновлением. Эти проверки являются частью работы мастера обновлений и в случае неудачной проверки будет выведено соответствующее сообщение.

Для обноления хоста с помощью XenCenter:

1. Скачайте обновление (файл с расширением .xsupdate) на компьютер, на котором работает XenCenter.
2. Остановите (Shut down или suspend) все виртуальные машины на обновляемом хосте.
3. В меню Tools выберите Install New Update. Откроется мастер обновления.
4. Прочитайте информацию и кликните Next для продолжения.
5. Выберите Add, и затем укажите скачанный файл обновления. Кликните Open. После того как файл добавится кликните Next для продолжения.
6. Выберите один или более хостов для применения обновления.
7. Следуйте рекомендациям для разрешения проблем, выявленных при проверках. Если вы хотите, чтобы XenCenter автоматически решил все обнаруженные проблемы - кликните Resolve All. После успешного прохождения всех проверок кликните Next для продолжения.
8. Выберите режим обновления - автоматический (automatic) или вручную (manual).
Если выбран автоматический режим, то XenCenter выполнит все необходимые действия после обновления (например перезагрузку хоста). Если выбран ручной, то требуемые дейтсвия надо выполнить вручную. Необходимые действия, выполняемые после обновления перечислены в списке ниже. Если вы хотите сохранить список в текстовый файл - кликните Save to File.
Кликните Install update для продолжения обновления.
Мастер обновления отобразит прогресс обновления, сообщая об основных произведенных операциях.

9. По окончании обновления кликните Finish для того чтобы закрыть мастер обновления.
10. Если был выбран способ обновления вручную, то сейчас следует выполнить предписанные действия.

Обновление отдельного хоста с помощью интерфейса xe CLI:

1. Скачайте обновление (файл с расширением .xsupdate) на компьютер, на котором выполняются команды xe CLI. Запомните путь к файлу.
2. Остановите (Shut down или suspend) все виртуальные машины на обновляемом хосте с помощью команд vm-shutdown или vm-suspend.
3. Загрузите файл обновления на обновляемый хост командой:

xe -s <server> -u <username> -pw <password> patch-upload file-name=<filename>

Тут ключ -s указывает имя хоста (то есть имя FQDN или просто IP-адрес). XenServer присвоит файлу обновления UUID, который будет отображен. Запомните UUID.

4. Если XenServer обнаружит ошибки или то, что не были выполнены подготовительные действия - (например на хоте остались запущенные виртуальные машины) он предупредит. Перед тем как продолжить обновление убедитесь, что все нужные шаги выполнены.
5. Обновите хост, указав UUID хоста и файла обновлений:

xe patch-apply host-uuid=<UUID_of_host> uuid=<UUID_of_file>

6. Убедитесь, что обновление прошло правильно с помощью команды patch-list. Если обновление прошло успешно, то поле hosts содержит UUID хоста.
7. Выполните необходимые после обновления операции (перезагрузка и др.).

При обновлении пула с помощью XenCenter, мастер обновления Install Update автоматически определяет этапы обновления и выполняет миграцию виртуальных машин. Если требуется управлять процессом обновления и миграцией виртуальных машин вручную, то можно обновлять каждый хост отдельно, при этом основхой хост пула (pool master) следует обновлять в первую очередь.

Обновление пула с помощью XenCenter:
1. Скачайте обновление (файл с расширением .xsupdate) на компьютер, на котором работает XenCenter.
2. Если в пуле есть виртуальные машины, которые надо остановить вручную (а не автоматически) - сделайте это.
3. В меню Tools выберите Install New Update. Откроется мастер обновления.
4. Прочитайте информацию и кликните Next для продолжения.
5. Выберите Add, и затем укажите скачанный файл обновления. Кликните Open. После того как файл добавится кликните Next для продолжения.
6. Выберите пул для применения обновления. Кликните Next.
7. Следуйте рекомендациям для разрешения проблем, выявленных при проверках. Если вы хотите, чтобы XenCenter автоматически решил все обнаруженные проблемы - кликните Resolve All. После успешного прохождения всех проверок кликните Next для продолжения.
8. Выберите режим обновления - автоматический (automatic) или вручную (manual).
Если выбран автоматический режим, то XenCenter выполнит все необходимые действия после обновления (например перезагрузку хостов). Если выбран ручной, то требуемые действия надо выполнить вручную. Необходимые действия, выполняемые после обновления перечислены в списке ниже. Если вы хотите сохранить список в текстовый файл - кликните Save to File.
Кликните Install update для продолжения обновления.
Мастер обновления отобразит прогресс обновления, сообщая об основных произведенных операциях на каждом хосте пула.
Во время обновления основного хоста пула (pool master) XenCenter временно отсоединится от пула.

9. По окончании обновления кликните Finish для того чтобы закрыть мастер обновления.
10. Если был выбран способ обновления вручную, то сейчас следует выполнить предписанные действия.

1. Скачайте обновление (файл с расширением .xsupdate) на компьютер, на котором выполняются команды xe CLI. Запомните путь к файлу.
2. Загрузите файл обновления на основной хост пула (pool master) командой:

xe -s <server> -u <username> -pw <password> patch-upload file-name=<filename>

Тут ключ -s указывает имя хоста pool master. XenServer присвоит файлу обновления UUID, который будет отображен. Запомните UUID.

4. Если XenServer обнаружит ошибки или то, что не были выполнены подготовительные действия - (например в пуле остались запущенные виртуальные машины) он предупредит. Перед тем как продолжить обновление убедитесь, что все нужные шаги выполнены.

5. Обновите хост, указав UUID хоста и файла обновлений:

xe patch-apply host-uuid=<UUID_of_host> uuid=<UUID_of_file>

6. Убедитесь, что обновление прошло правильно с помощью команды patch-list. Если обновление прошло успешно, то поле hosts содержит UUID хоста.
7. Выполните необходимые после обновления операции (перезагрузка и др.).
Если нужно - остановите (Shut down или suspend) виртуальные машины в обновляемом пуле с помощью команд vm-shutdown или vm-suspend.
Для того чтобы конкретные виртуальные машины мигрировали на конкретный хост можно использовать команду vm-migrate. С помощью команды vm-migrate можно осуществлять полный контроль над распределением виртуальных машин по хостам пула.
Для автоматической “живой” миграции всех виртуальных машин внутри пула используйте команду host-evacuate.

5. Обновите пул, указав UUID файла обновлений:

xe patch-pool-apply uuid=<UUID_of_file>

Эта команда применит обновление ко всем хостам пула.
Кроме того. можно применять обновления и к конкретным хостам командой. содержащей UUID конкретного хоста:

xe patch-apply host-uuid=<UUID_of_host> uuid=<UUID_of_file>

6. Убедитесь, что обновление прошло правильно с помощью команды patch-list. Если обновление прошло успешно, то поле hosts содержит UUID хоста.
7. Выполните необходимые после обновления операции (перезагрузка и др.).

http://support.citrix.com/article/CTX121325
Симптомы:
На хост уже установлены пакеты обновлений 1 и 2. При применении пакета обновления 3 появляется сообщение:
“Update Uploaded to Server <your server>
The upload update already exists
Check your settings and try again.”

Для выключения или перезагрузки хоста XenServer, входящего в состав пула следует выполнить несколько предварительных шагов, которые подготовят хост к выключению.

Для того чтобы запретить запуск на хосте виртуальных машин предусмотрена команда host-disable:

host-disable [<host-selector>=<host_selector_value>...]

Хосты на которых следует выполнить эту операцию выбираются с помощью стандартных селекотров. Дополнительными аргументами могут быть любое число параметров хоста, описанных тут: http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#cli-xe-commands_hostparameters .

host-evacuate ''<host-selector>=<host_selector_value>''...

Эта команда осуществляет “живую” миграцию виртеальных машин на другие хосты пула. Перед использованием этой команды хот должен быть отключен с комопщью команды host-disable.
Если эвакуируемый хост является мастер-хостом пула, то должен быть выбран другой мастерхост. Для переназначения мастер-хоста при отключенной высокой доступности (HA) необходимо выполнить команду pool-designate-new-master (см. http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#cli-xe-commands_pool-designate-new-master). При включенной высокой доступности (HA) можно просто выключить хост. Выборы нового мастер-хоста произойдут автоматически путем случайного выбора из имеющихся хостов.
Хосты на которых должна быть выполнена эта команда задаются с помощью стандартных селекторов.

host-reboot [<host-selector>=<host_selector_value>...]

Эта команда перезагружает указанный хост(ы). Перед перезагрузкой на хостах нужно запретить запуск новых виртуальных машин командой xe host-disable , в противном случае будет выведено сообщение об ошибке - HOST_IN_USE.
Хосты на которых должна быть выполнена эта команда задаются с помощью стандартных селекторов.

Если указанный хост является членом пула, то после перезагрузки он восстановится в пуле. Если перезагружается мастер-хост пула, то пул не будет работать до тех пор, пока мастер-хост пула не будет доступен снова. При включенной высокой доступности (HA) выборы нового мастер-хоста пройдут автоматически.

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#pool_failures

При отсутствии высокой доступности (HA) мастер-хост следит за регулярными хертбитами (heartbeat messages). Если от хоста не приходит хертбит в течение 600 секунд - хост считается не работающим. Решить эту проблему можно двумя путями:
Первый - восстановить работоспособность хоста (т.е. просто физически перезагрузить). После перезагрузки хост снова начнет слать хертбиты и восстановится в пуле.
Второй - Полностью выключить отказавший хост и указать мастер-хосту чтобы он “забыл” отказавший хост с помощью команды xe host-forget. После того как отказавший хост “забыт” все виртуальные машины на нем работавшие помечаются как выключенные и могут быть повторно запущены на других хостах пула. Учтите, что крайне важно, чтобы отказавший хост XenServer был действительно выключен. В противном случае - возможно, что оставшиеся на нем работать экземпляры виртуальных машин будут конфликтовать с вновь запущенными в пуле, что может привести к повреждению данных виртуальных машин. Также возможно, что в результате выполнения команды xe host-forget единый пул будет разделен на множество пулов, состоящих из одного хоста. Это приведет к тому, что все эти пулы будут обращаться к одному общему хранилищу (shared storage), что также может привести к повреждению данных виртуальных машин.

Не используйте команду xe host-forget при включенной высокой доступности (HA). Перед применением xe host-forget следует выключить (HA), а после применения включить снова.^
Может так случиться, что хост вышел из строя, но виртуальные машины по прежнему имеют статус работающих (running state). Если вы уверены в том, что хост действительно выключен, выполните команду xe vm-reset-powerstate для того чтобы изменить состояние виртуальных машин на halted (см. http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#cli-xe-commands_vm-reset-powerstate).

Перед тем как запустить виртуальные машины на другом хосте понадобится снять блокировки на хранилище виртуальных машин. Каждый диск виртуальной машины, хранящийся в хранилище в каждый момент времени может использоваться только одним хостом XenServer. Таким образом, для того чтобы другой хост вместо отказавшего мог использовать диски виртуальных машин следует запустить скрипт на мастер-хосте пула для каждого хранилища (SR), хранящего диски пострадавших виртуальных машин:

/opt/xensource/sm/resetvdis.py <host_UUID> <SR_UUID> [master]

Третий аргумент master следует использовать только если хост был мастером хранилища (SR) - то есть мастер-хостом пула или если хост XenServer использовал локальное хранилище в момент отказа.

Если вы попытаетесь запустить виртуальную машин на другом хосте, перед тем как выполнили этот скрипт (если на хранилище остались блокировки), то будет выведено сообщение об ошибке - VDI <UUID> already attached RW.

Каждый член пула имеею всю необходимую информацию, чтобы стать мастер-хостом в случае необходимости. При отказе мастер хоста происходит следующее:
1. Если высокая доступность (HA) включена - новый мастер-хост выбирается автоматически.
2. Если высокая доступность (HA) отключена, то члены пула будут ждать появления нового мастер-хоста.
Если мастер-хост вернется к работе в этот момент, то соединения в пуле будут восстановлены и пул продолжит нормальную работу.
Если мастер-хост действительно сдох, то нужно выбрать новый мастер-хост и запустить а нем команду xe pool-emergency-transition-to-master и он станет мастер-хостом. Затем для восстановления подключений членов пула к новому мастер-хосту следует выполнить команду xe pool-recover-slaves.
Если старый мастер-хост буде впоследствии восстановлен, то на нем следует просто переустановить XenServer и просто добавить его в пул.
После того, как был назначен новый мастер-хост следует проверить, что используется правильное хранилище пула по-умолчанию (default pool storage repository). Это можно сделать командой xe pool-param-list, в выводе которой есть параметр default-SR.

Иногда бывает так, что пул разваливается совсем и нужно восстановить базу данных пула. Убедитесь, что вы регулярно делаете резервные копии базы данных пула с помощью команды xe pool-dump-database (см. http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#cli-xe-commands_pool-dump-database).
Для восстановления разваленного пула:
1. Установите на новые хосты XenServer. Не создавайте пул.
2. На хосте которы должен стать мастер-хостом восстановите базу данных пула из резервной копии командой xe pool-restore-database (см. http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#cli-xe-commands_pool-restore-database).
3. Подключитесь к мастер-хосту консолью XenCenter и убедитесь, что общее хранилище и виртуальные машины на месте.
4. Выполните присоединение членов пула к пулу и запустите виртуальные машины.

Если новый мастер-хост не видит хранилище, то следует восстнаовить физичесоке подключение к хранилищу, а затем изменить конфигурацию хоста с помощью команд pbd-destroy (уничтожение неработающего хранилища) и pbd-create (создание нового) (см.http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#cli-xe-commands_pbd).
Если вы создали новое хранилище, то затем присоедините физическое устройство к нему командой pbd-plug или с помощью XenCenter - Storage > Repair Storage Repository.

host-reboot [<host-selector>=<host_selector_value>...]

Эта команда перезагружает указанный хост(ы). Перед перезагрузкой на хостах нужно запретить запуск новых виртуальных машин командой xe host-disable , в противном случае будет выведено сообщение об ошибке - HOST_IN_USE.
Хосты на которых должна быть выполнена эта команда задаются с помощью стандартных селекторов.

Если указанный хост является членом пула, то после перезагрузки он восстановится в пуле. Если перезагружается мастер-хост пула, то пул не будет работать до тех пор, пока мастер-хост пула не будет доступен снова. При включенной высокой доступности (HA) выборы нового мастер-хоста пройдут автоматически.

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#pool_failures

При отсутствии высокой доступности (HA) мастер-хост следит за регулярными хертбитами (heartbeat messages). Если от хоста не приходит хертбит в течение 600 секунд - хост считается не работающим. Решить эту проблему можно двумя путями:

Первый - восстановить работоспособность хоста (т.е. просто физически перезагрузить). После перезагрузки хост снова начнет слать хертбиты и восстановится в пуле.
Второй - Полностью выключить отказавший хост и указать мастер-хосту чтобы он “забыл” отказавший хост с помощью команды xe host-forget. После того как отказавший хост “забыт” все виртуальные машины на нем работавшие помечаются как выключенные и могут быть повторно запущены на других хостах пула. Учтите, что крайне важно, чтобы отказавший хост XenServer был действительно выключен. В противном случае - возможно, что оставшиеся на нем работать экземпляры виртуальных машин будут конфликтовать с вновь запущенными в пуле, что может привести к повреждению данных виртуальных машин. Также возможно, что в результате выполнения команды xe host-forget единый пул будет разделен на множество пулов, состоящих из одного хоста. Это приведет к тому, что все эти пулы будут обращаться к одному общему хранилищу (shared storage), что также может привести к повреждению данных виртуальных машин.

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#id873168
Если на хосте включена HA, но по какой-то причине хосту не доступен файл состояния HA (HA statefile), то хост может стать недоступным (unreachable). Для восстановления нормальной работы может понадобиться отключить HA с помощью команды host-emergency-ha-disable:

xe host-emergency-ha-disable --force

Если хост был мастером пула (pool master), то он должен запуститься нормально с отключенной HA. Подчиненные хосты должны переподключиться и также автоматически отключить HA. Если хост был подчиненным (Pool slave) и не может подключиться к мастерхосту, то может понадобиться принудительная перезагрузка хоста в режиме мастерхоста (xe pool-emergency-transition-to-master) или сообщить хосту где теперь новый мастерхост (xe pool-emergency-reset-master):

xe pool-emergency-transition-to-master uuid=<host_uuid>		
xe pool-emergency-reset-master master-address=<new_master_hostname>

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

xe pool-ha-enable heartbeat-sr-uuid=<sr_uuid>

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#monitoring_xenserver
http://support.citrix.com/article/CTX136679
Можно настроить XenServer так, чтобы он оповещал администратора о различных системных событиях. Настройки можно произвести либо с помощью XenCenter, либо с помощью консоли командной строки.
По-умолчанию для отправки уведомлений используется SMTP сервер, не требующий аутентификации.
Для отправки оповещений через SMTP сервер, требующий аутентификации нужно указать соответствующие данные в конфигурационном файле /etc/mail-alarm.conf.

Включение уведомлений в XenCenter:
- Кликните правой кнопкой по хосту или пулу и выберите Properties.
- В окне Properties выберите Email Options.
- Поставьте флажок Send email alert notifications и введите адрес e-mail и SMTP сервер (не требующий аутентификации).

Включение уведомлений с помощью командной строки:
- Зайдите на сервер по учетной записью root (неважно, в консоли XenCenter или по SSH).
- Выполните следующие команды:

 xe pool-param-set uuid=<uuid> other-config:mail-destination=<joe.bloggs@domain.tld>
        xe pool-param-set uuid=<uuid> other-config:ssmtp-mailhub=<smtp.domain.tld[:port]> 

Утилита mail-alarm перед отправкой уведомления проверяет конфигурационный файл /etc/mail-alarm.conf. Если файл существует - его содержимое используется для отправки. Если его не существует - используются данные из базы XAPI (сконфигурированные в XenCenter или xe CLI).
Содержимое файла /etc/mail-alarm.conf должно быть таким:

    root=postmaster
    authUser=<username>
    authPass=<password>
    mailhub=<server address>:<port>

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#ad_int
Если вы хотите аутентифицировать много пользователей для работы с XenServer, то нужно использовать учетные записи Active Directory. Это даст возможность подключаться к XenServer с учетными данными домена Windows.
Единственный способ управлять уровнем доступа к XenServer - это включить аутентификацию Active Directory, добавить учетные записи пользователей и назначить им роли.
Пользователи Active Directory могут использовать и интерфейс командной строки (указывая свои учетные данные в аргументах -u и -pw), а также подключаться к хостам XenServer c помощью XenCenter.
Контроль доступа осуществляется на уровне субъектов (subjects). Субъект в XenServer соответствует учетной записи в AD (пользовательской или групповой). При включенной внешней аутентификации введенные учетные данные сначала сравниваются с данными локального пользователя root, а затем со списком субъектов. Для предоставления прав доступа необходимо создать запись субъекта для пользователя или группы AD. Это может быть сделано из командной строки или XenCenter.

Порядок аутентификации обычно такой:
- Учетные данные передаются контроллеру домена Active Directory.
- Контроллер домена проверяет учетные данные и если они не верны, то аутентификация немедленно прерывается.
- Если учетные данные верны, то у контроллера домена запрашивается идентификатор субъекта и групповая принадлежность.
- Если идентификатор субъекта соответствует тому, который хранится в XenServer, аутентификация завершается успешно.

Присоединение пула XenServer к домену уже описано тут: http://wiki.autosys.tk/XenApp.%d0%9f%d0%be%d0%b4%d0%b3%d0%be%d1%82%d0%be%d0%b2%d0%ba%d0%b0-%d0%ba-%d1%8d%d0%ba%d0%b7%d0%b0%d0%bc%d0%b5%d0%bd%d1%83-1Y0-A26-Citrix-XenServer-6-Administration.ashx#%D0%90%D1%83%D1%82%D0%B5%D0%BD%D1%82%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F_%D1%81_%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%D1%8C%D1%8E_AD_11

Добавляем в XenServer субъекта:

xe subject-add subject-name=<entity name>

В данном случае entity name - это имя пользователя или группы. Дополнительно можно указать домен - '<xendt\user1>'. Хотя это и не обязательно - можно просто'<user1>'.

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

xe subject-list

К списку пользователей можно применить фильтр (например - получить идентифиатор субъекта для пользователя с именем user1):

xe subject-list other-config:subject-name='<domain\user>'

Удаляем пользователя с помощью команды subject-remove, передавая в качестве аргумента идентификатор:

xe subject-remove subject-uuid=<subject-uuid>

Также может понадобиться завершить все открытые сессии указанного пользователя. Как это сделать написано тут: http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#terminating_all_authenticated_sessions. Если этого не сделать, то удаленный пользователь будет иметь возможность работать с XenServer, пока не выйдет .

Для получения списка пользователей и групп и их прав используется следующая команда:

xe subject-list

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#rbac

Делегирование прав в Citrix XenServer использует механизм ролей. Каждому пользователю назначается роль, которая определяет список доступных прав. Этот механизм называется Role Based Access Control (RBAC).
Для аутентификации пользователей RBAC использует инфораструктуру Active Ditrectory. Таким образом, для назначения пользователям ролей необходимо присоединить пул XenServer к домену.
Локальный суперпользователь (local super user - LSU), или root, это специальная учетная запись, создаваемая при установке XenServer и используемая в административных целях, имеющая полные права в системе. Аутентификация root'а происходит локально и в случае отказа внешних механизмов аутентификации root может подключиться к системе с помощью XenCenter или SSH.

Для использования RBAC надо:
1. Присоединить пул к домену.
2. Добавить пользователя (или группу) Active Directory в пул и он станет субъектом (subject).
3. Назначить субъекту роли.

В XenServer преднастроены следующие шесть ролей:

Pool Administrator (Pool Admin) – полные права, аналогичные root.

Pool Operator (Pool Operator) – имеет права на все операции, кроме добавления/удаления пользователей и изменения их ролей. Пользователи с этой ролью обслуживают хосты пула и пул вцелом.
Virtual Machine Power Administrator (VM Power Admin) – права на создание и управление виртуальными машинами. Пользователи этой роли готовят виртуальные машины к работе с ними пользователей с ролью VM operator.
Virtual Machine Administrator (VM Admin) – тем же права, что и у VM Power Admin, за исключением прав на миграцию виртуальных машин и создание снимков (snapshots).
Virtual Machine Operator (VM Operator) – те же права, что и у VM Admin, в том числе и включение/выключение виртуальных машин, кроме прав на создание/удаление виртуальных машин.
Read-only (Read Only) – права только на просмотр состояния пула и данных о производительности.

Получение списка пользователей: xe role-list. Эта команда возвращает список ролей.

uuid( RO): 0165f154-ba3e-034e-6b27-5d271af109ba
name ( RO): pool-admin
description ( RO): The Pool Administrator role can do anything
               
uuid ( RO): b9ce9791-0604-50cd-0649-09b3284c7dfd
name ( RO): pool-operator
description ( RO): The Pool Operator can do anything but access Dom0 \
and manage subjects and roles

uuid( RO): 7955168d-7bec-10ed-105f-c6a7e6e63249
name ( RO): vm-power-admin
description ( RO): The VM Power Administrator role can do anything \
affecting VM properties across the pool

uuid ( RO): aaa00ab5-7340-bfbc-0d1b-7cf342639a6e
name ( RO): vm-admin
description ( RO): The VM Administrator role can do anything to a VM
                
uuid ( RO): fb8d4ff9-310c-a959-0613-54101535d3d5
name ( RO): vm-operator
description ( RO): The VM Operator role can do anything to an already 
                
uuid ( RO): 7233b8e3-eacb-d7da-2c95-f2e581cdbf4e
name ( RO): read-only
description ( RO): The Read-Only role can only read values

Для получения списка субъектов используется команда xe subject-list.

uuid ( RO): bb6dd239-1fa9-a06b-a497-3be28b8dca44
subject-identifier ( RO): S-1-5-21-1539997073-1618981536-2562117463-2244
other-config (MRO): subject-name: example01\user_vm_admin; subject-upn: \
  user_vm_admin@XENDT.NET; subject-uid: 1823475908; subject-gid: 1823474177; \
  subject-sid: S-1-5-21-1539997073-1618981536-2562117463-2244; subject-gecos: \
  user_vm_admin; subject-displayname: user_vm_admin; subject-is-group: false; \
  subject-account-disabled: false; subject-account-expired: false; \
  subject-account-locked: false;subject-password-expired: false
roles (SRO): vm-admin
                
uuid ( RO): 4fe89a50-6a1a-d9dd-afb9-b554cd00c01a
subject-identifier ( RO): S-1-5-21-1539997073-1618981536-2562117463-2245
other-config (MRO): subject-name: example02\user_vm_op; subject-upn: \
  user_vm_op@XENDT.NET; subject-uid: 1823475909; subject-gid: 1823474177; \
  subject-sid: S-1-5-21-1539997073-1618981536-2562117463-2245; \
  subject-gecos: user_vm_op; subject-displayname: user_vm_op; \
  subject-is-group: false; subject-account-disabled: false; \
  subject-account-expired: false; subject-account-locked: \
  false; subject-password-expired: false
roles (SRO): vm-operator
                
uuid ( RO): 8a63fbf0-9ef4-4fef-b4a5-b42984c27267
subject-identifier ( RO): S-1-5-21-1539997073-1618981536-2562117463-2242
other-config (MRO): subject-name: example03\user_pool_op; \
  subject-upn: user_pool_op@XENDT.NET; subject-uid: 1823475906; \
  subject-gid: 1823474177; subject-s id:
  S-1-5-21-1539997073-1618981536-2562117463-2242; \
  subject-gecos: user_pool_op; subject-displayname: user_pool_op; \
  subject-is-group: false; subject-account-disabled: false; \ 
  subject-account-expired: false; subject-account-locked: \
  false; subject-password-expired: false
  roles (SRO): pool-operator

Добавление субъекта:

xe subject-add subject-name=<AD user/group>

После создания субъекта ему можно назначить роль. На роль можно сослаться по uuid или по имени роли:

xe subject-role-add uuid=<subject uuid> role-uuid=<role_uuid>

или

xe subject-role-add uuid=<subject uuid> role-name=<role_name>

Например следующая команда назначает роль Pool Administrator субъекту с uuid=b9b3d03b-3d10-79d3-8ed7-a782c5ea13b4:

xe subject-role-add uuid=b9b3d03b-3d10-79d3-8ed7-a782c5ea13b4 role-name=pool-admin

Для изменения роли нужно удалить текущую роль и добавить новую:
Выполните команды:

xe subject-role-remove uuid=<subject uuid> role-name= \ 
      <role_name_to_remove>
    xe subject-role-add uuid=<subject uuid > role-name= \    
      <role_name_to_add>

Для того чтобы гарантировать, что новая роль применена нужно чтобы пользователь вышел изи системы и вошел снова (logged out and logged back in again).

http://docs.vmd.citrix.com/XenServer/5.6.0fp1/1.0/en_gb/reference.html#pool_removal
http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/guest.html#creatingVMs-clone

Сделать копию существующей виртуальной машины можно путем клонирования шаблона. Шаблон представляет собой обычную виртуальную машину, используемую как мастер-копия для создания новых машин. Виртуальную машину можно сконвертировать в шаблон, выполнив перед этим подготовительные шаги описнные тут: http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/guest.html#clone_considerations_Windows, http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/guest.html#clone_considerations_Linux.

Виртуальные машины могут быть скопированы XenServer двумя способами:
1. Полное копирование.
2. Копирование при записи (Copy-on-Write - CoW).

Быстрый режим копирования при записи записывает только измененные с момента копирования блоки. Механизм CoW спроектирован так, чтобы сохранять место на дисках и обеспечивать возможность быстрого клонирования, однако он немного снижает быстродействие дисковой подсистемы. Шаблон может быть быстро склонирован много раз без замедления.

Копирование виртуальной машины на другой сервер:

xe vm-list (note the name of the VM you wish to copy)
xe sr-list (note the name of the storage you will to copy the VM to)
xe vm-copy (needs the following parameters to complete)
xe vm-copy vm=<name of VM to copy> sr-uuid=<UUID of SR to copy VM to> new-name-label=<NewNameofVM> new-name-description=”Description of VM”

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/guest.html#exporting_vms
Экспортировать виртуальные машины в форматах OVF/OVA и XVA можно как с помощью XenCenter Export wizard, так и в формате XVA с помощью командной строки.

С помощью XenCenter Export wizard, можно экспортировать одну или несколько виртуальных машин в пакет OVF/OVA. При экспорте в этом формате в пакет инкапсулируются конфигурационные данные и виртуальные диски.

Экспорт в формате OVF/OVA с помощью XenCenter:
1. Выключите (Shut down) или приостановите (suspend) виртуальную машину, которая будет экспортирована.
2. Откройте мастер экспорта: В панели ресурсов (справа) кликните правой кнопкой по пулу или хосту, на котором находится экспортируемая виртуальная машина, а затем кликните Export.
3. На первой странице мастера введите имя экспортируемого файла, укажите папку, куда будет экспортирован файл. Затем из выпадающего списка выберите формат OVF/OVA Package (*.ovf, *.ova) и нажмите Next.
4. Из списка доступных виртуальных машин выберите одну или несколько, которые будут включены в в пакет OVF/OVA и нажмите Next.
5. Можно добавить предварительно подготовленный текст лицензионного соглашения в виде файла в формате .rtf или .txt. Другие форматы файлов (XML or binary) не поддерживаются. Нажмите Next для продолжения.
6. На странице Advanced options укажите манифест, цифровую подпись и параметры выходного файла или просто нажмите Next для продолжения.
7. Сконфигурируйте сетевые свойства виртуальной машины: Выберите сеть из списка и укажите способ конфигурирования (вручную или автоматически) и нажмите Next.
8. Проверьте параметры экспорта и при необходимости поставьте флажок Verify export on completion для проверки экспортированного файла. Нажмите Finish для начала процесса экспорта.

Экспорт в формате XVA выполянется аналогично, только на этапе 3 надо выбрать формат XVA File.

1. Выключите (Shut down), виртуальную машину, которая будет экспортирована.
2. Экспортируйте виртуальную машину командой:

    xe vm-export -h <hostname> -u <root> -pw <password> vm=<vm_name> \
    filename=<pathname_of_file>

Описание процесса конвертирования приведено в документации по XenConvert. Она короткая.
http://support.citrix.com/article/CTX125530
http://support.citrix.com/servlet/KbServlet/download/28774-102-666402/XenConvertGuide.pdf

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#cli-xe-commands_vm

Некоторые из описываемых команд позволяют использовать стандартный механизм селекторов для выбора одной или нескольких виртуальных машин по определенному признаку (параметру). Простейший способ выбора виртуальной машины - это указание ее идентификатора: vm=<name_or_uuid>.
Получить значения идентификаторов можно с помощью команды, которая также поддерживает селекторы: xe vm-list power-state=running.
Полный список параметров, свойственных виртуальным машинам можно получить с помощью команды: xe vm-list params-all.
Например применение аргумента power-state=halted приведет к тому, что команда будет выполнена только для машин находящихся в состоянии halted. При этом, если под фильтр попадают много машин - нужно добавлять дополнительный параметр:

--multiple

, указывающий что действие нужно выполнить над всем списком.

Описание команд:

vm-assert-can-be-recovered <uuid> [<database>] <vdi-uuid>

Проверяет доступно ли хранилище для восстановления VM

vm-cd-add cd-name=<name_of_new_cd> device=<integer_value_of_an_available_vbd>
[<vm-selector>=<vm_selector_value>...]

Добавляет новый виртуальный привод CD. Параметры устройства должны быть выбраны из списка доступных устройств VBD.

vm-cd-eject [<vm-selector>=<vm_selector_value>...]

Извлекает CD из виртуального привода. Если приводов больше, чем один, то следует использовать команду xe vbd-eject и указать UUID устройства VBD.

vm-cd-insert cd-name=<name_of_cd> [<vm-selector>=<vm_selector_value>...]

Вставлет CD в виртуальный привод. Если приводов больше, чем один, то следует использовать команду xe vbd-insert и указать UUID устройства VBD.

vm-cd-list [vbd-params] [vdi-params] [<vm-selector>=<vm_selector_value>...]

Выводит список CD, присоединенных к указанной машине.

vm-cd-remove cd-name=<name_of_cd> [<vm-selector>=<vm_selector_value>...]

Удаляет CD из указанных VMs.

vm-clone new-name-label=<name_for_clone>
[new-name-description=<description_for_clone>] [<vm-selector>=<vm_selector_value>...]

Клонирует указанную VM, с помощью быстрого механизма хранилища(storage-level fast disk clone). Нужно указать имя и описание результирующей машины в параметрах new-name-label и new-name-description.

vm-compute-maximum-memory total=<amount_of_available_physical_ram_in_bytes>
[approximate=<add overhead memory for additional vCPUS? true | false>]
[<vm_selector>=<vm_selector_value>...]

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

Пример:

xe vm-compute-maximum-memory vm=testvm total=`xe host-list params=memory-free --minimal`

Эта команда использует значение параметра memory-free, возвращаемое командой xe host-list, для того, чтобы выделить виртуальной машине максимальное количество свободной памяти виртуальной машине testvm.

vm-copy new-name-label=<name_for_copy> [new-name-description=<description_for_copy>]
[sr-uuid=<uuid_of_sr>] [<vm-selector>=<vm_selector_value>...]

Команда копирует существующую виртульную машину без использования механизмов быстрого копирования. Получаемая копия - это полная копия, не являющаяся частью цепочки copy-on-write (CoW).
Нужно указать имя и описание результирующей машины в параметрах new-name-label и new-name-description, а также идентификатор системы хранения, куда будет скопирована VM с помощью аргумента sr-uuid. Если sr-uuid не указан - копирование будет произведено на то же хранилище, где находится оригинальная VM.

vm-crashdump-list [<vm-selector>=<vm selector value>...]

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

vm-data-source-list [<vm-selector>=<vm selector value>...]

Выводит список источников данных о производительности виртуальной машины.
Источники данных имеют два параметра: standard и enabled. Если источник данных имеет параметр enabled со значением true, то данные записываются в базу данных производительности.
Если источник данных имеет параметр standard со значением true то данные записываются в базу данных производительности по-умолчанию.
Если параметры источника данных имеют значение false, то запись значений в базу данных не ведется.
Для начала записи значений в базу данных нужно выполнить команду vm-data-source-record. Эта команда установит параметру enabled значение true. Для остановки записи нужно выполнить команду vm-data-source-forget.

vm-data-source-record data-source=<name_description_of_data-source> [<vm-selector>=<vm selector value>...]

Начинает запись значений указанного источника данных в базу данных о производительности.

vm-data-source-forget data-source=<name_description_of_data-source> [<vm-selector>=<vm selector value>...]

Останавливает запись значений указанного источника данных в базу данных о производительности.

vm-data-source-query data-source=<name_description_of_data-source> [<vm-selector>=<vm selector value>...]

Отображает значение указанного источника данных.

vm-destroy uuid=<uuid_of_vm>

Уничтожает указанную виртуальную машину. При этом, виртуальные диски этой машины остаются в хранилище. Для уничтожения машины и удаления дисков используется команда xe vm-uninstall.

vm-disk-add disk-size=<size_of_disk_to_add> device=<uuid_of_device>
[<vm-selector>=<vm_selector_value>...]

Добавляет новый виртуальный диск указанной VM. Параметр device выбирается из значений allowed-VBD-devices данной VM.
Параметр disk-size может быть указан в байтах или с помощью суффиксов KiB (2^10 bytes), MiB (2^20 bytes), GiB (2^30 bytes), и TiB (2^40).

vm-disk-list [vbd-params] [vdi-params] [<vm-selector>=<vm_selector_value>...]

Выводит список дисков, присоединенных к данной VM. Аргументы vbd-params и vdi-params задают поля соответсвующих объектов, указанные через запятую или всемто них можно использовать ключевое слово all, для полного списка.

vm-disk-remove device=<integer_label_of_disk> [<vm-selector>=<vm_selector_value>...]

Удаляет диск из указанной виртуальной машины и уничтожает его.

vm-export filename=<export_filename>
[metadata=<true | false>]
[<vm-selector>=<vm_selector_value>...]

Экспортирует указанную VM (включая и диски) в файл на локальной машине. В параметре filename нужно указать имя файла, куда будет экспортирована VM. Имя файла должно содержать расширение .xva.
Если параметр metadata имеет значение true, то экспортируются только метаданные, а диски экспортированы не будут. Этот режим используется в случаях, когда в качестве виртуальных дисков подключены физические носители и требуется только экспорт информации о них.

vm-import filename=<export_filename>
[metadata=<true | false>]
[preserve=<true | false>]
[sr-uuid=<destination_sr_uuid>]

Выполняет импорт предварительно экспортированной машины. Если параметр preserve имеет значение true, то будет сохранен MAC-адрес оригинальной машины. Параметр sr-uuid задает на каком хранилище будут размещены виртуальные диски, а если он не указан, то будет использовано хранилище по-умолчанию.
Старые версии XenServer (начиная с версии 3.2)экспортировали машины в папку, а не в файл, поэтому параметр filename также может указывать на на корневую директорию экспорта XVA, а не на конкретный файл. Последующий экспорт импортированной машины будет производиться уже в новом формате. ^Примечание: Старый формат экспорта в папку не полностью сохранял аттрибуты виртуальной машины. В частности, не сохранялась информация о сетевых интерфейсах, которые придется создать заново с помощью команд vif-create и vif-plug.^
Если параметр metadata имеет значение true, то экспортированные метаданные могут быть импортированы без дисков. Импорт только метаданных завершится неудачно, если какие-либо VDI не будут обнаружены. Использование опции

--force

позволит импортировать машину в отсутствие ее VDI. Импорт-экспорт метаданных может быть полезен в случаях, когда нужно перенести машины между пулами, имеющими доступ к одной системе хранения.

vm-install new-name-label=<name>
[ template-uuid=<uuid_of_desired_template> | [template=<uuid_or_name_of_desired_template>]]
[ sr-uuid=<sr_uuid> | sr-name-label=<name_of_sr> ]
[ copy-bios-strings-from=<uuid of host> ]

Устанавливает или клонирует виртуальную машину из шаблона. Нужно указывать либо название шаблона в параметром template, либо его идентификатор uuid в параметре template-uuid. Укажите хранилище параметром sr-uuid или sr-name-label. Укажите uuid хоста, с которого будут скопированы данные BIOS.

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

Если происходит установка из шаблона, в котором нет дисков, то новые диски будут создаваться на указанном хранилище, или на хранилище по-умолчанию.

vm-memory-shadow-multiplier-set [<vm-selector>=<vm_selector_value>...]
[multiplier=<float_memory_multiplier>]

Задает коэффициент “теневой” памяти для VM.
Этот параметр задает количество shadow memory, выделенной аппаратно-поддержаной (hardware-assisted) VM. В некоторых случаях специализированных нагрузок, например - Citrix XenApp, дополнительная “теневая память” необходима для достижения максимального быстродействия.
Эта память будет избыточной. Она отделена от объема памяти, используемого VM. При выполнении этой команды количество свободной памяти XenServer будет уменьшено соответственно множителю. В случае нехватки физической памяти будет зафиксирована ошибка.

vm-migrate [[host-uuid=<destination XenServer host UUID> ] | [host=<name or UUID of destination XenServer host> ]] [<vm-selector>=<vm_selector_value>...] [live=<true | false>]

Команда запускает миграцию виртуальной машины между физическими хостами. Параметр host может быть либо именем, либо идентификатором UUID хоста XenServer.
По-умолчанию, виртуальная машина будет остановлена (suspended), перемещена и затем оживлена на другом хосте. Параметр live активирует механизм XenMotion и позволяет машине работать во время перемещения, минимизируя время простоя до секунды. В некоторых случаях (например высокая нагрузка на память), XenMotion автоматически откатится к режиму миграции по-умолчанию и остановит VM на короткой промежуток времени, перед переносом состояния памяти.

vm-reboot [<vm-selector>=<vm_selector_value>...] [force=<true>]

Перезагружает указанную машину.
Принудительную перезагрузку можно произвести с помощью аргумента force.

vm-recover <vm-uuid> [<database>] [<vdi-uuid>] [<force>]

Восстанвливает виртуальную машину из указанной базы.

vm-reset-powerstate [<vm-selector>=<vm_selector_value>...] {force=true}

Эта команда используется в случаях, когда хост пула выходит из строя и работавшие на нем машины не возможно выключить. Эта команда принудительно переводит машины в состояние halted. На самом деле, эта команда разблокирует диски виртуальной машины и после этого ее можно запустить на другом хосте пула. Эта команда требует обязательного указания аргумента force.

vm-resume [<vm-selector>=<vm_selector_value>...] [force=<true | false>] [on=<XenServer host UUID>]

Возвращает к работе машину, находящуюся в приостановленном состоянии.
Если машина находится на общем (shared) хранилище пула, то следует использовать аргумент on, который указывает на каком хосте следует запустить машину. По-умолчанию, система сама определяет подходящий хост.

vm-shutdown [<vm-selector>=<vm_selector_value>...] [force=<true | false>]

Выключает указанную виртуальную машину.
Аргумент force позволяет принудительно выключить VM.

vm-start [<vm-selector>=<vm_selector_value>...] [force=<true | false>] [on=<XenServer host UUID>] [--multiple]

Запускает указанную машину.
Если машина находится на общем (shared) хранилище пула, то следует использовать аргумент on, который указывает на каком хосте следует запустить машину. По-умолчанию, система сама определяет подходящий хост.

vm-suspend [<vm-selector>=<vm_selector_value>...]

Приостанавливает работу указанной машины.

vm-uninstall [<vm-selector>=<vm_selector_value>...] [force=<true | false>]

Полностью удаляет виртуальную машину, включая метаданные и подключенные диски (только те VDI, которые имеют режим RW и присоединены только к этой машине).
Для удаления только метаданных используется команда xe vm-destroy.

vm-vcpu-hotplug new-vcpus=<new_vcpu_count> [<vm-selector>=<vm_selector_value>...]

Динамически изменяет количество VCPU, доступных виртуальной машине Linux, в пределах, ограниченных параметром VCPUs-max. Виртуальные машины Windows всегда используют число VCPU, заданное параметром VCPUs-max и для его изменения должны быть перезагружены.

vm-vif-list [<vm-selector>=<vm_selector_value>...]

Выводит список виртуальных сетевых адаптеров данной VM.

host-backup file-name=<backup_filename> host=<host_name>

Сохраняет резервную копию управляющего домена (control domain) указанного хоста XenServer на машину, с коротой запущена команда. ^Внимание! Несмотря на то, что команду можно запустить на локальном хосте (не указывая параметр host), в таком образом её использовать не следует, потому что раздел управляющего домена (control domain) будет полностью заполнен файлом бекапа. Эту команду следует выполнять с другого хоста, на котором есть место для сохранения бекапа. ^

host-bugreport-upload [<host-selector>=<host_selector_value>...] [url=<destination_url>]
[http-proxy=<http_proxy_name>]

Создает свежий отчет о багах (утилитой xen-bugtool со всеми включенными опциями) и загружает его на сервер службы поддержки Citrix Support или указанный сервер ftp.
Дополнительные параметры - http-proxy и url предписывает использовать указанный proxy и удаленый сервер. По-умолчанию отчет выгружается на серер Citrix Support.

host-crashdump-destroy uuid=<crashdump_uuid>

Удаляет дамп, с заданным UUID.

host-crashdump-upload uuid=<crashdump_uuid>
[url=<destination_url>]
[http-proxy=<http_proxy_name>]

Выгружает аварийный дамп на сервер Citrix Support или указанный сервер.
Дополнительные параметры - http-proxy и url предписывает использовать указанный proxy и удаленый сервер. По-умолчанию дамп выгружается на серер Citrix Support.

host-disable [<host-selector>=<host_selector_value>...]

Отключает указанный хост XenServer. После выполнения этой команды на хосте запрещен запуск виртуальных машин. Это действие подготавливает хост к выключению или перезагрузке.

host-dmesg [<host-selector>=<host_selector_value>...]

Выводит журнал ядра указанного хоста (dmesg).

host-emergency-management-reconfigure interface=<uuid_of_management_interface_pif>

Переконфигурирует основной интерфейс управления данного хоста XenServer. Эту команду следует использовать только если хост находится в аварийном режиме (emergency mode), то есть является членом пула, мастер-хост которого пропал из сети и не доступен после нескольких попыток связаться с ним.

host-enable [<host-selector>=<host_selector_value>...]

Включает указанный хост, разрешая запуск на нем виртуальных машин.

host-evacuate [<host-selector>=<host_selector_value>...]

Запускает миграцию виртуальных машин на другие подходящие хосты пула. Перед запуском этой команды хост должен быть отключен командой host-disable.
Если эвакуируемый хост - это мастер-хост пула, то нужно назначить другой мастер-хост. Для назначения нового мастер-хоста при выключенной высокой доступности (HA) нужно выполнить команду pool-designate-new-master.
При включенной HA - выборы мастер-хоста произойдут автоматически.

host-forget uuid=<XenServer_host_UUID>

Агент xapi “забудет” об указанном хосте XenServer, не связываясь с ним.
Аргумент

--force

следует использовать для того чтобы запретить запрос подтверждения этой операции.

host-get-system-status filename=<name_for_status_file>
[entries=<comma_separated_list>] [output=<tar.bz2 | zip>] [<host-selector>=<host_selector_value>...]

Выгружает информацию о состоянии системы в указанный файл. Дополнительные параметры вводятся через запятую.

host-get-system-status-capabilities [<host-selector>=<host_selector_value>...]

Получает характеристики состояния системы указанного хоста в виде файла XML, который выглядит примерно так:

<?xml version="1.0" ?>	<system-status-capabilities>
 		<capability content-type="text/plain" default-checked="yes" key="xenserver-logs"  \
           max-size="150425200" max-time="-1" min-size="150425200" min-time="-1" \
		   pii="maybe"/>
 		<capability content-type="text/plain" default-checked="yes" \
		   key="xenserver-install" max-size="51200" max-time="-1" min-size="10240" \
		   min-time="-1" pii="maybe"/>
 		...
	</system-status-capabilities>

Каждя запись имеет ряд аттрибутов:
key Уникальный идентификатор характеристики
content-type Имеет значение либо text/plain либо application/data. Показывает, может ли интерфейс отобразить запись в читаемом виде.
default-checked Имеет значение либо yes либо no. Показывает, будет ли запись отображена по-умолчанию.
min-size, max-size Показвает примерный диапазон размера записи в байтах. Значение -1 говорит, что размер не важен.
min-time, max-time Показывает примерную продолжительность сбора данных записи. Значение -1 говорит, что продолжительность не важна.
pii Персонально идентифицируемая информация. Показывает, будет ли в записи информация, идентифицирующая владельца системы или подробности сетевой топологии. Принимает значения: no, yes, maybe, if_customized

Пароли никогда не указываются ни в каких отчетах. Они могут быть указаны только в самим администратором в PII.

host-is-in-emergency-mode

Возвращает true, если хост находится в аварийном режиме. Эта команда работает на подчиненных хостах (slave hosts), даже если мастер-хост недоступен.

host-apply-edition [host-uuid=<XenServer_host_UUID>] [edition=xenserver_edition=<"free"><"advanced"><"enterprise"><"platinum"><"enterprise-xd">]

Назначает лицензию хосту XenServer. При назначении лицензии XenServer соединяется с сервером лицензий Citrix License Server и запрашивает нужный тип лицензии. Если лицензия доступна - он получает ее от сервера лицензий.

Для Citrix XenServer for XenDesktop используется <“enterprise-xd”>.
Для начальной конфигурации - нужно сконфигурировать параметры license-server-address и license-server-port.

host-license-add [license-file=<path/license_filename>] [host-uuid=<XenServer_host_UUID>]

For XenServer (free edition), use to parses a local license file and adds it to the specified XenServer host.

host-license-view [host-uuid=<XenServer_host_UUID>]

Отображает содержимое лицензии хоста XenServer.

host-logs-download [file-name=<logfile_name>] [<host-selector>=<host_selector_value>...]

Выгружает копию логов указанного хоста XenServer. Копия сохраняется по-умолчанию в файле с именем соотвествующим дате в формате hostname-yyyy-mm-dd T hh:mm:ssZ.tar.gz. Также можно указать и другое имя с помощью соответствующего аргумента.

host-management-disable

Отключает интерфейс управления хостом и отключает всех подключенных клиентов.

host-management-reconfigure [interface=<device> ] | [pif-uuid=<uuid> ]

Конфигурирует хост Xenserver для использования указанного интерфейса в качестве основного интерфейса управления (для подключения XenCenter).
Эта команда изменяет параметр MANAGEMENT_INTERFACE в файле /etc/xensource-inventory.
Если интерфейсу присовен IP-адрес в команде указано имя устройства интерфейса (device name), то конфигурирование произойдет сразу. Команда работает как в номальном, так и в аварийном (emergency) режиме.
Если указн идентификатор UUID объекта PIF, то XenServer определяет IP адрес. В таком варианте команда работает только в нормальном режиме хоста (не аварийном).
Внимание! Используйте эту команду осторожно, т.к. возможна потеря связи с хостом. Предварительно надо настроить интерфейс командой pif-reconfigure.

host-power-on [host=<host_uuid> ]

Включает хост, на котором включена соответствующая функциональность (Host Power On functionality). Перед использованием этой команды, на хосте следует выполнить команду host-set-power-on.

host-get-cpu-features {features=<pool_master_cpu_features>} [uuid=<host_uuid>]

Выводит в шестнадцатеричном виде список возможностей физического процессора.

host-set-cpu-features {features=<pool_master_cpu_features>} [uuid=<host_uuid>]

Эта команда пытается привести список возможностей физического процессора к заданному. СТрока-аргумент представляет собой 32-х символьную шестнадцатеричную строку (возможно содержащую пробелы), аналогичную выводу команды host-get-cpu-features.

host-set-power-on {host=<host uuid> {power-on-mode=<""> <"wake-on-lan"> <"iLO"> <"DRAC"> <"custom"> } | [power-on-config=<"power_on_ip"><"power_on_user"><"power_on_password_secret">] }

Включает возможность удаленного включения питания хоста. При балансировке нагрузке в режиме максимальной плотности (Maximum Density mode) может понадобиться включать и выключать неиспользуемые хосты. При выполнении этой команды нужно указать тип используемого решения управления питанием (аргумент <power-on-mode>). Затем, указать опции конфигурации с помощью аргумента <power-on-config> и пар параметр-значение.

host-reboot [<host-selector>=<host_selector_value>...]

Перезагружает указанный хост XenServer. Перед перезагрузкой хост должен быть отключен командой xe host-disable. В противном случает будет зафиксирована ошибка HOST_IN_USE.
Если указанный хост член пула, то после перезагрузки его возвращение в пул будет обработано правильно, а во время перезагрузки мастер-хост и другие члены пула будут нормально работать. Если перезагружается мастер-хост, то пул не будет доступен пока мастер-хост не вернется в строй или до тех пор, пока не будет назначен новый мастер-хост.

host-restore [file-name=<backup_filename>] [<host-selector>=<host_selector_value>...]

Восстанавливает из указанной резервной копии состояние хоста XenServer. В данном случае под восстановлением понимается не полное восстановление, а просто распаковка конфигурационных файлов на строй раздел диска. После выполнения xe host-restore нужно загрузиться с установочного диска и выбрать опцию Restore from Backup.

host-set-hostname host-uuid=<uuid_of_host> hostname=<new_hostname>

Меняет имя хоста XenServer с указанным UUID. Эта команда изменяет имя хоста как на самом хосте, так и в базе данных домена.

host-shutdown [<host-selector>=<host_selector_value>...]

КОманда выключает указанный хост XenServer. Перед выключением следует отключить (запретить запуск новых виртуальных машин на нем) хост командой xe host-disable. В противном случае - будет выведено сообщение об ошибке: HOST_IN_USE.
Если указанный хост является членом пула, то его выключение (и последующее возвращение в работу) будет правильно обработано без прерывания работы пула. Если выключается мастер-хост, то пул не будет доступен пока мастер-хост не вернется в строй или до тех пор, пока не будет назначен новый мастер-хост. Если включена высокая доступность (HA), то новый мастер-хост назначается автоматически. Если HA отключена, то нужно вручную назначить мастерхост командой pool-designate-new-master.

host-syslog-reconfigure [<host-selector>=<host_selector_value>...]

Переконфигурирует демон syslog на указанном хосте.

host-data-source-list [<host-selectors>=<host selector value>...]

Выводит список источников данных о производительности хоста.
При запуске команды без уточнения хоста - команда будет выполнена для всех хостов.
Источники данных о производительности хоста имеют два параметра - standard и enabled. Если параметр enabled имеет значение true - это значит, что данные из этого источника фиксируются в базе данных производительности хоста.
Если параметр standard имеет значение true - это значит, что данные фиксируются в базе по-умолчанию (то есть параметр enabled также имеет значение true).
Если параметр standard имеет значение false - это значит, что данные не фиксируются в базе по-умолчанию (то есть параметр enabled также имеет значение false).
Для того чтобы начать фиксировать данные о производительности в базе предназначена команда host-data-source-record (параметр enabled будет установлен в значение true).
Для того чтобы прекратить фиксировать данные о производительности в базе предназначена команда host-data-source-forget (параметр enabled будет установлен в значение false).

host-data-source-record data-source=<name_description_of_data-source> [<host-selectors>=<host selector value>...]

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

host-data-source-forget data-source=<name_description_of_data-source> [<host-selectors>=<host selector value>...]

Команда останавливает запись данных о производительности с указанного источника для указанного хоста.
При запуске команды без уточнения хоста - команда будет выполнена для всех хостов.

host-data-source-query data-source=<name_description_of_data-source> [<host-selectors>=<host selector value>...]

Отображает данные о производительности с указанного источника.
При запуске команды без уточнения хоста - команда будет выполнена для всех хостов.

Серверы XenServer могут быть объединены в пул. Такое объединение дает возможность управлять множеством хостов XenServer как единым ресурсом, внутри которого исполняются виртуальные машины. Пул предствляет собой множество (два и более) хостов XenServer, использующих общее (shared) хранилище, на котором хранятся данные виртуальных машин. Таким образом виртуальная машина может быть запущена на любом хосте пула, а также может динамически мигрировать с одного хоста на другой, обеспечивая минимальное время простоя (технология XenMotion).
При выходе из строя отдельных хостов пула, администратор может перезапустить остановленные виртуальные машины на рабочих хостах пула, а при включенной функции высокой готовности (high availability - HA), виртуальные маишны будут перезапущены автоматически. В пул могут входить до 16 серверов, хотя это ограничение не является строгим.
В состав пула всегда входит хотя бы один хост, который является мастер-хостом. Только мастер-хост предоставляет административный интерфейс для работы с пулом, перенаправляя команды XenCenter и XenServer Command Line Interface (xe CLI) отдельным хостам.

Пулы бывают гомогенные (то есть состоящие из хостов с одинаковыми CPU) либо гетерогенные (состоящие из хостов с разными CPU).

Условия, которые должны быть соблюдены для создания пула:
- в хостах XenServer установлены одинаковые процессоры (производитель, модель и функции)
- хосты работают под управлением одной версии XenServer

Также должны быть соблюдены некоторые условия конфигурации:
- Хост присоединяемый к пулу не должен входить в состав других пулов.
- На нем не должно быть сконфигурировано общего (shared) хранилища
- на присоединяемом хосте не должно быть запущенных или приостановленных (suspended) виртуальных машин
- на присоединяемом хосте не должно выполняться никаких текущих процедур с виртуальными машинами (например выключение ВМ)

Также следует проверить, что часы присоединяемого хоста и мастер-хоста пула синхронизированы с одним сервером NTP. Также интерфейс управления хостом должен иметь статический IP (сконфигурированный на хосте или через DHCP) и не должен быть объединен с другим интерфейсов в группу (bonded) - объединение можно сконфигурировать после присоединения к пулу.
Хосты могут иметь разное количество сетевых интерфейсов и локальные хранилища разного размера. Кроме того допускаются незначительные отличия в используемых CPU. Если вы уверены, что отличия в CPU хостов незначительны, то для присоединеня к пулу может понадобиться использовать параметр

--force

Хотя наличие общего (shared) хранилища не является обязательным условием работы пула, однако использование общего хранилища позволяет указывать на каком конкретно хосте должна исполняться виртуальная машина, а также динамически перемещать ВМ между хостами XenServer.
По возможности не следует создавать пул без общего хранилища, а после того как в пуле появляется общее хранилище следует переместить ВМ на общее хранилище с помощью команды xe vm-copy или XenCenter.

Пул XenServer можно создать либо из XenCenter, либо с помощью консоли и CLI. При присоединении хоста к пулу, хост синхронизирует свою локальную базу данных с базой данных пула и наследует некоторые настройки:
- Информация о виртуальных машинах, а также локальных и удаленных хранилищах попадает в базу данных пула, но локальные ресурсы все еще будут привязаны к хосту, до тех пор, пока они не будут объявлены общими.
- Присоединяемый к пулу хост наследует настройки общего хранилища пула и соответствующее PBD (физическое блочное устройство) будет создано автоматически.

- Информация о сетевых настройках наследуется частично. Наследуются структурные детали сетевых адаптеров, VLANов и объединенных интерфейсов, но не наследуются политики, в частности НЕ наследуются:
- не наследуются настройки IP-адреса интерфейса управления.
- не наследуются параметры основного интерфейса управления хоста.
- не наследуются параметры адаптеров, выделенных для работы с общим хранилищем. Адаптеры выделенные для присоединения хранилищ должны быть перенастроены, а PBD переподключены. Это происходит потому что в процессе присоединения не присваиваются IP-адреса адаптерам хоста. Подробнее конфигурирование выделенного адаптера для взаимодействия с хранилищем описано тут: http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#networking-standalone_host_config-config_dedicated_storage_nic

Для объединения хостов XenServer host1 и host2 в один пул XenServer с помощью интерфейса командной строки:
- откройте консоль host1 и host2
- В консоли host2 выполните команду присоединения к host1:

xe pool-join master-address=<host1> master-username=<administrators_username> master-password=<password>

Параметр master-address - это полное FQDN имя хоста host1, а password - это пароль администратора, задаваемый при установке XenServer.

По-умолчанию хосты принадлежат к пулу без имени. Переименовать пул можно командой (для завершения строки и заполнения uuid можно использовать tab):

xe pool-param-set name-label=<"New Pool"> uuid=<pool_uuid>

XenServer 6.0 упрощает расширение ферм, позволяя объединять в пулы хосты с разным аппаратным обеспечением - так называемые гетерогенные пулы. Создание гетерогенных пулов стало возможным благодаря использованию таких технологий как Intel (FlexMigration) и AMD (Extended Migration), которые позволяют конфигурировать CPU так, чтобы он представлял нужный набор функций. Таким образом, можно создавать пулы на базе хостов с разными процессорами, и поддерживающими “живую миграцию”.
“Маскирование” CPU новых серверов для того, чтобы они соответствовали старым CPU требует соблюдения следующих условий:
- CPU существующих и добавляемых серверов должны быть одного производителя (AMD или Intel)
- CPU добавляемых серверов должны поддерживать либо технологию Intel FlexMigration либо AMD Enhanced Migration.
- Набор функций CPU существующих серверов должен поддерживаться CPU устанавливаемых серверов
- На устанавливаемых серверах должна быть та же версия XenServer (включая хотфиксы), что и на существующих
- XenServer Advanced edition или выше

Наиболее просто создавать гетерогенные пулы с помощью XenCenter, который автоматически применяет “маскирование” CPU.
Для добавления хоста в гетерогенный пул с помощью командной строки:
- Определите набор функций процессоров существующих серверов пула с помощью команды: xe host-get-cpu-features
- На добавляемом хосте с помощью команды xe host-set-cpu-features надо установить нужный набор функций CPU:

xe host-set-cpu-features features=<pool_master's_cpu_ features>

- Перезагрузите добавляемый сервер
- Выполните команду xe pool-join для присоединения у пулу

Для возвращения “замаскированного” CPU к нормальному состоянию нужно выполнить команду xe host-reset-cpu-features

В данном разделе описано добавление общего хранилища NFS.
Добавление общего хранилища NFS с помощью командной строки:
- Подготовьте разделяемый ресурс NFS по адресу <server:/path>
- Откройте консоль
- Создайте хранилище (storage repository) по адресу <server:/path> командой:

xe sr-create content-type=user type=nfs name-label=<"Example SR"> shared=true \
      device-config:server=<server> \
      device-config:serverpath=<path>

Параметр device-config:server указывает на имя хоста (hostname) на котором размещен ресурс NFS. Параметр device-config:serverpath указывает путь на сервере NFS. Так как shared имеет значение true, общее хранилище будет автоматичсеки подключено ко всем хостам пула и ко всем хостам, которые будут впоследствии подключены к пулу. Универсальный идентификатор (UUID) созданного хранилища будет выведен на экран.

- Определите UUID пула командой

xe pool-list

- Установите созданное общее хранилище как хранилище для пула по-умолчанию:

Так как было задано общее хранилище для пула по-умолчанию, все виртуальные машины, создаваемые в будущем будут размещены на этом хранилище.

После удаления хоста из пула, система перезагружается, инициализируется и остается в том состоянии как после чистой установки XenServer.
Таким образом важно не извлекать (eject) хост из пула, если на нем есть важные данные на локальных дисках.

Для удаления хоста из пула с помощью командой но строки:
- Откройте консоль хоста
- Определите UUID хоста командой:

xe host-list

- Извлеките хост из пула командой:

xe pool-eject host-uuid=<host_uuid>

Хост будет извлечен и приведен в состояние как после чистой установки XenServer.

Не извлекайте хост из пула, если на нем есть важные данные на локальных дисках. При извлечении из пула все данные будут уничтожены.
Если нужно сохранить эти данные - скопируйте виртуальные машины на общее хранилище (shared storage) пула с помощью XenCenter или команды xe vm-copy.^

При извлечении из пула хоста XenServer, содержащего на своем локальном хранилище виртуальные машины, эти ВМ будут представлены в базе данных пула и доступны остальным хостам пула, однако не смогут быть запущены до тех пор, пока их виртуальные диски не будут перемещены на хранилище, доступное хостам пула. Именно по этой причине при присоединении к пулу настойчиво рекомендуется перемещать данные с локальных хранилищ на общее, для того чтобы отдельные хосты XenServer можно было извлечь быстро и безопасно без потерь данных.

Перед проведением обслуживания хоста XenServer, входящего в пул, следует отключить (disable) его (то есть запретить запуск виртуальных машин на хосте), затем мигрировать виртуальные машины на другие хосты пула. Это проще всего осуществить установив для хоста режим обслуживания (Maintenance mode) с помощью XenCenter.

Citrix настойчиво рекомендует перезагружать все хосты XenServer ПЕРЕД установкой обновлений и затем проверять их конфигурацию. Некоторые изменения в конфигурации вступают в силу только после перезагрузки и таким образом перезагрузка может помочь выявить проблемы в конфигурации, которые могут сделать невозможным обновление.

Для подготовки хоста XenServer к обслуживанию (maintenance):
- Выполните команды:

xe host-disable uuid=<xenserver_host_uuid>
    xe host-evacuate uuid=<xenserver_host_uuid>

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

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

xe host-enable

- Запустите выключенные и приостановленные виртуальные машины.

Также перевести хост в режим обслуживания можно с помощью XenCenter.
Нужно кликнуть правой кнопкой по хосту и в меню кликнуть пункт Enter Maintenance Mode, или выделить хост, а затем в меню Server кликнуть пункт Enter Maintenance Mode.

http://citrixxperience.com/2012/06/06/ha-best-practices-xenserver-host-maintenance/
http://citrixxperience.com/2012/06/05/xenserver-maintenance-mode-and-workload-balancing/

При работе с включенной высокой доступностью (HA) не следует вносить изменения в конфигурацию пула. Если необходимо внести существенные изменения в конфигурацию (например - установить обновления) следует сначала отключить HA, внести изменения, а затем включить HA снова.

Отключение HA:
1. В XenCenter в панели ресурсов выбрать пул.
2. Перейти на вкладку HA.
3. Кликнуть Disable HA и затем подтвердить - OK.

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#cli-xe-commands_ref_host-evacuate
Для переназначения мастер-хоста при отключенной высокой доступности (HA) необходимо выполнить команду pool-designate-new-master (см. http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#cli-xe-commands_pool-designate-new-master).

pool-designate-new-master host-uuid=<UUID of member XenServer host to become new master>

Данная команда назначает указанный хост мастер-хостом пула. В результате - роль мастер-хоста передается указанному хосту. Эту команду можно выполнить только если текущий мастер-хост присутствует в пуле. Если текущий мастер-хост вышел из строя, то нужно выполнить команду pool-emergency-transition-to-master

pool-emergency-transition-to-master

Команда предписывает хосту стать мастер-хостом. Команда будет выполнена только хостом, находящимся в режиме emergency mode. Подразумевается, что мастер-хост пропал из сети и остается недоступен после нескольких попыток связаться с ним.

При включенной высокой доступности (HA) можно просто выключить хост. Выборы нового мастер-хоста произойдут автоматически путем случайного выбора из имеющихся хостов.

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#ck_reference_storage_repository_types
Различные типы хранилищ поддерживаются XenServer с помощью подключения плагинов. Новые плагины могут быть добавлены в дирректорию /opt/xensource/sm. Изменение этих файлов не поддерживается, однако они доступны для просмотра и могут быть полезны разработчикам и продвинутым пользователям. Новые плагины, размещенные в этой директории автоматически распознаются XenServer. Для просмотра списка поддерживаемых типов хранилищ (SR types) используется команда sm-list.
Новые хранилища создаются в XenCenter с помощью мастера New Storage. Также для создания хранилища можно использовать команду sr-create, которая создаст хранилище на указанном устройстве, уничтожив там все данные. Также автоматически будут созданы объекты SR API и записи о физическом блочном устройстве (PBD). При успешном создании хранилища PBD подключается автоматически. Если указан флаг shared=true, то запись о физическом блочном устройстве (PBD) появится на всех хостах пула.
Все типы хранилищ XenServer поддерживают изменение размера VDI (VDI resize), быстрое клонирование (fast cloning) и создание мгновенных снимков (snapshot).
Хранилища на базе LVM (local, iSCSI или HBA) поддерживают «thin provisioning» (методика выделения пространства хранения приложениям не сразу при создании диска, а по мере возникновения в нем потребности у данных приложения, «on demand») для снэпшотов и скрытых родительских нод. Другие типы хранилищ поддерживают полных механизм thin provisioning (full thin provisioning), в том числе для активных виртуальных дисков.

По-умолчанию неприсоединенные к виртуальной машине (например снэпшот) VHD VDI (логический том lvm с образом диска виртуальной машины) хранится в режиме «thin provisioning». Следовательно, перед присоединением к виртуальной машине и запуском следует убедиться, что на хранилище достаточно места для того, чтобы образ диска развернулся полностью (стал thickly provisioned).^

\\

Максимальные поддерживаемые размеры VDI:

Тип хранилища - - Максимальный размер VDI
EXT3 - - - - - - - - 2TB
LVM - - - - - - - - 2TB
NetApp - - - - - - - 2TB
EqualLogic - - - - 15TB
ONTAP(NetApp) - - - 12TB

Тип хранилища Local LVM - это локальный диск хоста, на котором размещена группа томов LVM (Volume Group).
По-умолчанию XenServer использует локальный диск хоста, на который он установлен. Для управления хранилищем используется Linux Logical Volume Manager (LVM). VDI (образы дисков виртуальных машин) хранятся в формате VHD в виде томов LVM нужного размера.
Версии XenServer до 6.0 не исползовали формат VHD. Дополнительную информацию о переводе хранилищ в новый формат можно найти тут: http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#upgrading_to_lvhd

Для создания local lvm SR на устройстве /dev/sdb используется следующая команда:

xe sr-create host-uuid=<valid_uuid> content-type=user \
name-label=<"Example Local LVM SR"> shared=false \
device-config:device=/dev/sdb type=lvm

Хранилище типа Local EXT3 VHD - это набор файлов в формате VHD, хранящихся в каталоге, доступном локально.
Локальные диски хоста могут быть хранилищем типа EXT3 VHD.
Локальные хранилища типа EXT3 VHD не могут быть общими в пуле (shared) и, следовательно, хранящиеся на них образы виртуальных машин не могут мигрировать в пуле.

Для создания local ext3 SR на устройстве /dev/sdb используется следующая команда:

xe sr-create host-uuid=<valid_uuid> content-type=user \
   name-label=<"Example Local EXT3 SR"> shared=false \
   device-config:device=/dev/sdb type=ext

В хранилище типа ISO хранятся образы дисков CD в формате ISO. Этот тип предназначен для создания библиотек образов дисков в формате ISO. Для таких хранилищ параметр content-type должен иметь значение iso.
Например:

xe sr-create host-uuid=<valid_uuid> content-type=iso \
  type=iso name-label=<"Example ISO SR"> \
  device_config:location=<nfs server:path>>

XenServer поддерживает хранилища на базе iSCSI LUNs. iSCSI поддерживается с помощью программного open-iSCSI инициатора, либо с помощью аппаратного адаптера iSCSI Host Bus Adapter (HBA).
Программный инициатор iSCSI позволяет работать с общим (shared) хранилищем на базе Linux Volume Manager (LVM) и предоставляет такую же производительность и функционал как и хранилище типа Local LVM, в том числе и “живую” миграцию XenMotion.
Хранилища iSCSI используют целый LUN, указываемый при создании хранилища и не могут включать в себя больше одного LUN. Для аутентификации поддерживается CHAP (как на этапе data path initialization, так и LUN discovery).

Все инициаторы и таргеты iSCSI должны иметь уникальные имена. Инициатор и таргет имеют адреса iSCSI - iSCSI Qualified Names или коротко - - IQN.
Хост XenServer поддерживает один инициатор iSCSI, автоматически создаваемый при установке хоста, которому дается случайное имя IQN. Этот инициатор может подключаться к нескольким таргетам одновременно.
Таргеты iSCSI обычно предоставляют доступ данным в соответствии с заданным списком разрешенных инициаторов iSCSI. Таким образом, для того чтобы хост XenServer могу получить доступ к таргету может понадобиться внести имя его инициатора в список доступа. Аналогично, для того чтобы выступать в роли общего хранилища пула, таргет и LUN должны быть настроены соответсвующим образом, предоставляя доступ к LUN для всех iSCSI инициаторов хостов пула.

Как правило, если iSCSI таргет не поддерживает списков доступа, то он обеспечивает целостность данных путем предоставления доступа к одному LUN только одного инициатора. Для того чтобы таргет мог использоваться как общее хранилище для хостов пула, он должен поддерживать подключение нескольких инициаторов к одному LUN.^
Значение IQN хоста XenServer может быть переопределено либо с помощью XenCenter, либо командой:

xe host-param-set uuid=<valid_host_id> other-config:iscsi_iqn=<new_initiator_iqn>

Имена таргетов и инициаторов iSCSI обязательно должны иметь уникальные IQN. В противном случае LUN может стать недоступен, или возможны повреждения данных.^

Нельзя изменять IQN хоста XenServer при подключенных хранилищах iSCSI. Если изменить имя, не отключив хранилище, то могут возникнуть проблемы при доступе к новым, либо уже подключенным хранилищам.^

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/installation.html#id885653
Для создания общего хранилища iSCSI в пуле нужно в консоли любого хоста пула выполнить команду:

xe sr-create name-label=<name_for_sr> \
    content-type=user device-config-target=<iscsi_server_ip_address> \ 
    device-config-targetIQN=<iscsi_target_iqn> \
    device-config-localIQN=<iscsi_local_iqn> \
    type=lvmoiscsi shared=true device-config-LUNid=<lun_id>

Аргумент device-config-target - это FQDN имя или IP адрес сервера iSCSI.
Аргумент device-config-LUNid - это список LUN ID (разделенных запятыми).
Так как аргумент shared имеет значение true, общее хранилище будет добавлено на всех хостах пула и хосты подключатся к хранилищу.
Команда возвращает UUID созданного хранилища.
Можно установить это хранилище используемым по-умолчанию в пуле:
Нужно выяснить UUID пула, с помощью команды pool-list.
Установить хранилище используемым по-умолчанию в пуле:

xe pool-param-set uuid=<pool_uuid> default-SR=<iscsi_shared_sr_uuid>

Теперь все создаваемые виртуальные машины будут размещены на этом хранилище.

Хранилища Citrix StorageLink (CSL) используют прямой доступ к программным интерфейсам (API) аппаратных систем хранения, для разгрузки хостов от типичных “тяжелых” задач, таких как создание снэпшотов, клонирование и других.

CSL поддерживают несколько типов адаптеров, соответствующих API систем хранения. Сконфигурированный адаптер берет на себя задачи предоставления ресурсов СХД хостам XenServer по их требованию.

Так как хранилища CSL могут работать на базе разных СХД, точный набор поддерживаемых функций зависит от конкретной СХД. Все хранилища CSL используют модель LUN-per-VDI, то есть каждому виртуальному диску соответствует (VDI) отдельный LUN.

Хранилища CSL могут сосуществовать на одной СХД с хранилищами других типов. В пуле может быть создано несколько хранилищ Citrix StorageLink.

Хранилища CSL поддерживают СХД следующих типов:

При использовании СХД NetApp в качестве хранилища StorageLink, на СХД для хоста XenServer автоматически создаются Initiator Groups. Для этих Initiator Groups в качестве Operating System (OS) указан Linux.
Добавление Initiator Groups вручную с другими типами OS не рекомендуется. ^

Dell EqualLogic API использует SNMP для взаимодействия. Требуется поддержка SNMP v3 и следовательно версия firmware v5.0.0 или более новая. Если ваша СХД EqualLogic работает под более старой firmware, то следует обновить firmware до версии v5.0.0.
После обновления нужно явно сбросить пароль администратора (grpadmin). Это нужно для того, чтобы пароль сконвертировался в ключи ауетнтификации и шифрования SNMPv3. Сбросить пароль можно подключившись к СХД с помощью telnet или ssh и выполнив команду:

account select grpadmin passwd

Пароль может быть таким же как и был до этого.^

http://support.citrix.com/article/CTX131761
По-умолчанию, при установке программному инициатору iSCSI назначается случайный IQN.
Если значение IQN по-умолчанию не устраивает, то следует изменить его.

Необходимо создать файл /etc/iscsi/initiatorname.iscsi, если его не существует.^
Текущее значение IQN инициатора хоста можно найти в XenCenter на вкладке General данного хоста.
Для определения uuid хоста на до в консоли выполнить команду

xe host-list

Затем для изменения IQN выполнить команду:

xe host-param-set uuid=<host UUD> other-config:iscsi_iqn=<New IQN>

Дальше следует убедиться, что в файле /etc/iscsi/initiatorname.iscsi указано новое имя IQN.
Если это не так, то нужно открыть файл в редакторе (например nano) и изменить указанный там IQN вручную. Содержимое файла должно соотвествовать фомату:

InitiatorName=iqn.yyyy-mm.<reversed domain name>[:identifier]

То есть быть примерно таким:

 InitiatorName=iqn.2001-04.com.redhat:fc6

После этого надо перезапустить службу iSCSI:

service open-iscsi restart

Удостовериться, что сервис iSCSI запускается автоматически при старте системы:

chkconfig open-iscsi on
chkconfig --list

http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/installation.html#intellicache
Применение IntelliCache позволяет более эффективно использовать ресурсы инфраструктуры, благодаря комбинации общего и локального хранилищ. В частности - в случаях когда есть много виртуальных машин, использующих один образ операционной системы, применение IntelliCache позволяет снизить нагрузку на СХД и повысить производительность. Благодаря тому что образ ОС кешируется на локальном хранилище, также снижается и сетевой трафик от СХД.
IntelliCache кеширует данные из основного VDI виртуальной машины на локальном хранилище хоста, на котором работает виртуальная машина.
Для работы IntelliCache требуется чтобы локальное хранилище поддерживало Thin Provisioning, то есть выделение требуемого места по требованию.

Включение Thin Provisioning изменяет тип локального хранилища с LVM на EXT3.^
Thin Provisioning позволяет использовать отображать больше места, чем есть на хранилище. Фактическое выделение пространства на хранилище происходит только когда виртуальная машина записывает данные.

Хранилища использующие Thin Provisioning могут быть переполнены, в результате активной записи данных виртуальными машинами. IntelliCache обрабатывает эту ситуацию автоматически, перенося образы дисков виртуальных машин обратно на общее хранилище. Не рекомендуется на одном хранилище смешивать обычные виртуальные машины и виртуальные машины поддержкой IntelliCache, так как образы дисков машин IntelliCache могут быстро расти.^

IntelliCache можно включить как при установке хоста XenServer, так и вручную с помощью командной строки.
Citrix рекомендует использовать максимально быстрые устройства в качестве локального хранилища (SSD или RAID). Общее хранилище может быть либо NFS, либо EXT.

Для включения IntelliCache при установке, на стадии Virtual Machine Storage следует выбрать Enable thin provisioning (Optimized storage for XenDesktop).

Для того чтобы заменить текущее локальное хранилище LVM на хранилище типа EXT3 с поддержкой Thin Provisioning выполните следующие команды:

Выполнение этих команд уничтожит все данные на локальном хранилище.^

localsr=`xe sr-list type=lvm host=<hostname> params=uuid --minimal`
    echo localsr=$localsr
    pbd=`xe pbd-list sr-uuid=$localsr params=uuid --minimal`
    echo pbd=$pbd

    xe pbd-unplug uuid=$pbd
    xe pbd-destroy uuid=$pbd
    xe sr-forget uuid=$localsr
    sed -i "s/'lvm'/'ext'/" /etc/firstboot.d/data/default-storage.conf
    rm -f /etc/firstboot.d/state/10-prepare-storage
    rm -f /etc/firstboot.d/state/15-set-default-storage
    service firstboot start
    xe sr-list type=ext

Для того чтобы включить кеширование на локальном хранилище:

xe host-disable host=<hostname>
    localsr=`xe sr-list type=ext host=<hostname> params=uuid --minimal`
    xe host-enable-local-storage-caching host=<hostname> sr-uuid=$localsr
    xe host-enable host=<hostname>

Виртуальная машина может быть загружена в двух вариантах:
Shared Desktop Mode - В этом режиме виртуальная машина НЕ сохраняет сделанные пользователем изменения и всегда загружается в одном и том же состоянии.

Private Desktop Mode - В этом режиме виртуальная машина сохраняет сделанные пользователем изменения и загружается в том же состоянии, в котором была выключена.

Параметр VDI allow-caching задает режим кеширования:

Shared Desktop Mode - параметр on-boot имеет значение reset, а флаг allow-caching установлен в значение true. Новые данные, генерируемые во время работы, будут записываться только на локальном хранилище. Таким образом, нагрузка на общее хранилище будет существенно снижена. В этом режиме машина НЕ сможет мигрировать между хостами.

Private Desktop Mode - параметр on-boot имеет значение persist, а флаг allow-caching установлен в значение true. Новые данные, генерируемые во время работы, будут записываться и на локальное и на общее хранилище. Таким образом, нагрузка на общее хранилище снижается только при чтении данных. В этом режиме машина сможет мигрировать между хостами.

http://support.citrix.com/article/CTX129309
Протокол iSCSI не приспособлен к обработке отказов оборудования и не поддерживает обработку отключения соединения или повторную отправку пакетов. Таким образом, крайне важно обеспечить максимальную надежность подключения хостов XenServer к СХД.
Multipathing - это механизм, позволяющий подключить СХД к хосту или пулу XenServer с помощью двух адаптеров одновременно. Таким образом обеспечивается повышение отказоустойсивости подключения (защита от выхода из строя аппаратных компонент), а также увеличение производительности.
В отличие от механизма объединения адаптеров (NIC bonding), который обеспечивает только избыточность, multipathing работает в режиме active-active, что позволяет не только повысить надежность, но и увеличить производительность.
Citrix рекомендует всегда вместо объединения адаптеров (NIC bonding) использовать multipathing и никогда не смешивать их в одной конфигурации.

Multipathing поддерживается при работе с хранилищами NFS и iSCSI.

При конфигурировании Multipathing следует учитывать следующее:
- Тип Multipathing, поддерживаемый СХД
- Количество IQN, предоставляемых СХД - один или много.
При включении Multipathing в пуле следует его сконфигурировать на всех хостах.

Multipathing создает несколько подключений между хостом и хранилищем. Эти подключения называются пути (paths).
XenServer поддерживает обработчик DM-MP multipath handler. Основная задача DM-MP handler - представление в системе одного устройства хранения для каждого LUN ( которому установлено несколько подключений), а не множества устройств на каждое подключение (path). То есть DM-MP объединяет множество подключений к одному LUN в единое устройство хранения в системе. Без DM-MP Linux создает по одному устройству на каждый path.

Для подключения хоста XenServer к СХД должо быть установлено соединение между инициатором (клиентом) iSCSI и таргетом (сервером). Инициатор XenServer делает запрос к таргету СХД и ждет ответа о готовности со списком доступных IQN. Затем XenServer подключается к нужному IQN.
Установленное соединение между хостом XenServer и таргетом остается активным и должно быть установлено повтороно только в случае перезагрузки хоста. После конфигурирования multipath XenServer может создавать два (и более) подключения к СХД - по одному на каждое физичекое подключение (link).
Получив список IQN, который включает в себя серийные номера LUN, обработчик Multipath сравнивает серийные номера LUN на разных подключениях и определяет, являются ли обнаруженные LUN несколькими разными LUN, либо это один LUN и к нему установлено несколько подключений, а также определяет количество подключений установленных к одному LUN.
При создании хранилища (storage repository) с влюченным multipath, а именно - при создании Physical Block Device (PBD), XenServer добавляет параметр multihome, который указывает на то что логическое устройство связано с СХД несколькими подключениями.
Если в конфигурации XenServer не указано, что устройство хранения multihomed (например - multipath не был включен в момент создания PBD или хранилища (storage repository)), то XenServer сможет устанавливать к этому LUN только одно подключение.

При подключении к СХД с интерфейсом iSCSI лучше всего создавать конфигурацию multipath сразу. Хотя, если хранилище было создано при отключенном multipath, то можно перевести хост в режим обслуживания (maintenance mode) и сконфигурировать multipathing.

Для СХД с интерфейсом Fibre Channel, Citrix настойчиво рекомендует конфигурировать multipath и ставить флажок multipathing в XenCenter перед созданием хранилища (storage repository).
Для всех типов СХД рекомендуется планировать и конфигурировать подключения к массивам дисков заранее, до запуска пула в работу. Настройка multipathing после запуска пула в работу приведет к остановкам - настройка multipath повлияет на все виртуальные машины, размещенные на хранилище.

XenServer поддерживает два обработчика multipath - Device Mapper Multipathing (DM-MP) и Multipathing Proxy Redundant Disk Array Controller (MPP RDAC). Кроме того, поддерживается и сочетание DMP RDAC.
По-умолчанию XenServer использует встроенный в Linux multipath - DM-MP. При этом, XenServer поддерживает различные расширения этого обработчика и может использовать различные функции, сецифичные для СХД разных производителей (vendor-specific features). Типичные примеры СХД с поддержкой режима портала (portal mode) - это многие СХД NetApp, HP Storage Works Modular Smart Array (MSA) и HP Storage Works Enterprise Virtual Array (EVA).
Для работы с СХД производства LSI XenServer поддерживает LSI Multi-Path Proxy Driver (MPP) для Redundant Disk Array Controller (RDAC). MPP RDAC работает иначе, чем DMP и требует некоторых подготовительных действий, выполненных в правильной последовательности. Начиная с XenServer 5.6 Feature Pack 1, XenServer имеет специальную команду интерфейса CLI, которая включает поддержку MPP RDAC и выполняет нужную последовательность действий в правильном порядке. Типичным примером СХД MPP RDAC является серии СХД Dell MD3000-series, IBM DS4000 и другие, указанные в статье CTX122824.
За дополнительными сведениями о поддерживаемых алгоритмах multipath Citrix рекомендует обращаться к документации, поставляемой с СХД. При возникновении разногласий следует учесть, что СХД на базе LSI как правило лучше всего работают с MPP RDAC.

Самым правильным решением, для обеспечения отказоустойчивости, является использование двух коммутаторов. Однако, в случае если два коммутатора не используются, то следует логически разделить пути (paths), то есть назначить каждому сетевому адаптеру СХД (NIC) свою подсеть и соотвествующим образом настроить адаптеры хостов XenServer. И, разумеется, правильно настроить параметры TCP/IP.

После правильного физического подключения можно включить или выключить поддержку multipathing в XenCenter на вкладке хоста Multipathing. Это проще сделать, когда хранилище (storage repository) еще не создано. Вцелом процесс включения multipathing требует выполнения ряда задач, приведенных далее.

Если multipathing включен когда хост подключен к хранилищу (storage repository), то XenServer может не суметь правильно сконфигурировать multipathing. Если хранилище (storage repository) уже создано и нужно сконфигурировать multipathing, то сначала следует перевести все хосты пула в режим Maintenance Mode, а затем сконфигурировать multipathing на всех хостах пула. Это гарантирует, что данные всех работающих виртуальных машин мигрируют, перед применением изменений.

Приведенная ниже инструкция предполагает использование XenCenter.
Настройка программного инициатора iSCSI с использованием multipathing:
1. Создайте избыточные (резервные) физические подключения и настройте параметры подсетей TCP/IP. Убедитесь, что созданы подсети как для адаптеров хостов XenServer, так и для адаптеров СХД и адаптеры подключены правильно.
2. В соотвествии с рекомендациями производителя СХД сконфигурируйте СХД и создайте LUN с поддержкой multipathing.

3. Убедитесь, что порты таргета iSCSI работают в режиме портала (portal mode):
В XenCenter, запустите мастер New Storage Repository (Storage menu > New Storage Repository).
i. На странице мастера Enter a name and path for the new iSCSI storage кликните Discover IQNs. XenServer запросит у таргета список IQN.
ii. Проверьте, что список Target IQN на странице Location. Если порты таргета iSCSI работают в режиме портала (portal mode), то все IP таргета должны показаться на странице Location.

4. Включите обработчик multipath одним из способов:
• В случае MPP RDAC, включите multipathing в XenCenter (то есть выберите Enable multipathing на сервере на вкладке Multipathing), дополнительную информацию о работе СХД LSI смотрите раздел “Enabling MPP RDAC Handler Support for LSI Arrays”.

• При использовании DMP, то есть выберите Enable multipathing на сервере на вкладке Multipathing в свойствах хоста.

Для включения поддержки MPP RDAC нужно выполнить приведенную ниже процедуру на всех хостах пула:
1. В консоли хоста выполните следующую команду:

# /opt/xensource/libexec/mpp-rdac --enable

2. Перезагрузите хост.

Лучше всего создавать хранилище (storage repository) после конфигурирования multipathing на всех хостах пула. При создании хранилища на хостах с включенным multipathing нужно указать правильное количество IQN таргета, возвращаемое СХД.
При создании хранилища нужно указать IQN таргета, то есть адреса, указывающего на нужное устройство iSCSI, однако в ответ на запрос СХД может возвращать несколько IQN, в зависимости от конфигурации СХД.
После включения multipathing оба пути (paths) должны указывать на один и тот же LUN, а таргет должен возвращать единственный IQN. Однако, некоторые СХД даже после включения multipath возвращают разные IQN (одного и того же LUN) на разных подключениях.
Вид IQN-ов в мастере Storage Repository может несколько удивить, так как там отображаются некоторые дополнительные сведения. В отличие от вывода консольной команды xe sr-probe, в XenCenter отображаются IP-адреса сетевых адаптеров контролера СХД, а такде номер порта, хост и имя СХД.
Если СХД возвращает один или несколько IQN, то в XenCenter будет отображаться примерно следующее:

Первая часть IQN - указывает на тип, дату создания и имя. ВТорая часть - задается производителем СХД. Третья - IP адрес контроллера СХД и порт.

Некоторые СХД, например DataCore и StarWind имеют возмжность возвращать несколько IQN (multi-IQN feature). Для работы с данным типом СХД следует указывать IP-адреса всех таргетов в поле Target Host на странице мастера Location. и разделять IP-адреса запятыми. После ввода адресов и нажатия на кнопку Discover IQNs, XenCenter покажет несколько IQN-ов с разными именами.
Для СХД, возвращающих несколько IQN, при создании хранилища следует выбирать опцию Wildcard Masking (*) в XenCenter, которая обозначается звездочкой (*) в начале поля Target IQN как показано ниже:

Для создания хранилища после включения multipathing:
1. В XenCenter создайте новое хранилище (storage repository) с помощью мастера New Storage Repository.
2. На этапе ввода параметров iSCSI (Enter a name and path for the new iSCSI storage) заполните поля до этапа Discover IQNs.
3. Кликните Discover IQNs. XenServer получит от СХД список IQN-ов. Затем:
• Если возвращается только одно (одинаковое) значение IQN, то выберите нужный LUN и сконфигурируйте его.
• Если возвращается много IQN-ов, то выберите опцию (*) из списка Target IQN.
4. Finish creating the storage repository and exit the wizard.

Source: Citrix XenServer Design: Designing XenServer Network Configurations,
Pages 30 - 32
http://support.citrix.com/article/CTX129320
Source: Citrix XenServer 6.0 Administrator’s Guide
http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/reference.html#network
ing-standalone_host_config-vlans