Хочу рассказать о том, как прижился XenServer в нашем отделе тестирования, а так же немного о другом используемом free/opensource (DRBL + Clonezilla, Tape redirector, MHVTL). Выбор остановился на этих продуктах не по идеологическим, а сугубо практическим причинам — они удобные и масштабируемые. Но есть и ряд проблем, которым я также уделю внимание в этой статье.
Под катом много текста и изображений.
Я работаю в команде тестирования Acronis в отделе поддержки пользователей, воспроизвожу пользовательские проблемы. Начиная с имитации дискового окружения и аппаратной части, заканчивая программным обеспечением и его специфическими настройками. Стояла задача — обеспечить работу тестового стенда с помощью двух рабочих станций. Были перепробованы и ESXi, Hyper-V, Proxmox и другие, но все же остановились на использовании XenServer. И вот что из этого получилось.
Изначально имелся один диск, на который и был установлен XenServer 4.2. По началу скорость устраивала. Чуть позже сервером стало пользоваться уже два человека, появилось уже тяжелое окружение (например, Exchange 2003 с базой данных в 300гб, которая постоянно работала под нагрузкой) и сразу стало понятно, что для комфортной работы текущей производительности явно недостаточно. Виртуальные машины грузились долго (а одновременно работает в среднем 20 штук на одном сервере), IO Wait часто достигал нескольких секуд. Надо было что-то делать.
Первое, что пришло в голову — RAID, но быстро это не реализовать, а решение нужно вчера. Как раз тогда в репозитории Debian добавили ZFS и было решено попробовать именно его.
Каждая из двух рабочих станций имеет материнскую плату с 4-мя SATA2 портами, 16ГБ ОЗУ и гигабитные сетевые карты.
Первая машина была выделена под гипервизор и загружается с USB флешки.
На вторую машину была установлена серверная Ubuntu 11.04, все необходимые пакеты для работы ZFS. Установлены 4ре диска по 1ТБ каждый. Был выбран RAID 10. Так как на материнской плате только 4 SATA порта, то ОС так же установлена на USB флешку.
Сам гипервизор соединен с ZFS через гигабитный свитч.
Были проведены эксперименты, прочитаны статьи, в итоге на ZFS была включена поддержка сжатия GZIP, выключена проверка контрольных сум, от дедупликации так же отказались. Это оказалось самым оптимальным решением, все 8 ядер очень редко нагружаются на 100%, и памяти вполне хватает. К сожалению, кэш на SSD протестировать не удалось :)
Сама файловая система экспортируется наружу через NFS, нативно поддерживаемый самим ZFS. А XenServer, да и ESX работают с NFS хранилищами. Это позволило использовать это же хранилище одновременно и для 2-х XenServer и для 3-х ESXi. Из этого ряда выбивается Hyper-V, который с завидным упорством и в Server 2012 отказывается работать с NFS, но это на совести MS.
Сконфигурированный ZFS выглядит так:
Скорость записи на диск примерно соответствует удвоенной скорости отдельного диска.
На данный момент до 40 виртуальных машин одновременно работают без каких либо проблем с производительностью, тогда как раньше 20 машин приводили к провисаниям IOW до 5 секунд. Сейчас, спустя полтора года с запуска ZFS решение можно признать надежным, быстрым и крайне бюджетным. Поднятые NFS и CIFS сервера на хранилище позволяют его использовать и для других целей:
XenServer позволяет создавать ISO хранилища на сетевых дисках CIFS. Продукты перед релизным тестированием собираются в ISO образ (инсталляторы для Windows и Linux разных локализаций), который, в свою очередь, загружен на сетевой диск во внутренней гигабитной сети. В результате, одним движением мышки (субьективно XenCenter гораздо удобнее и быстрее в такой работе, чем vSphere) или скрипта мы вставляем эту ISO в виртульный CDROM (можно и десяткам машин одновременно) и ставим продукт прямо «с диска», что значительно экономит время на копировании больших (2GB+) файлов. Конечно, такое линейное чтение просаживает сеть, особенно если установка идет сразу с 5+ машин, но это все равно очень удобно.
Гигабитная сеть, через которую подключено хранилище, доступна и для виртуальных машин. Таким образом, можно использовать CIFS для любых других тестов. Для удобства на ZFS машине так же был поднят DHCP сервер.
Кроме виртуальных машин, тестировать приходится и на обычных рабочих станциях. Это тестирование и с ленточными накопителями и всевозможные REV, RDX диски и т.д. Нужно постоянно и быстро разворачивать различное окружение на машины. Будь то ESX гипервизор или Windows 2008R2 с Hyper-V или SLES с поднятым iSCSI multipath. Для этой цели используется DRBL
DRBL в сочетании с Clonezilla позволяет быстро разворачивать образы чере PXE с гибкими сценариями, а так же служит NAT сервером для уже развернутых машин.
Машины во внутренней сети имеют доступ через NAT во внешнюю сеть, а к ним самим через iptables имеется доступ по RDP.
Набор различных ленточных накопителей подключен к одной машине, на которой используется бесплатный Tape Redirector, соответственно любая виртуальная машина может их использовать по iSCSI. Так же имеется отдельная виртуальная машина с поднятым MHVTL, но аппаратные накопители тоже нужны — не все проблемы проявляются на VTL.
Развертывание/клонирование делается в два клика с помощью утилиты, написанной на Perl+GTK. Работает достаточно просто — компонуется команда из блоков и выполняется через SSH. Кому интересно, репозиторий тут. Код сырой, но работает github.com/Pugnator/GTKdrbl
Субьективно удобный интерфейс представлен только Citrix — XenCenter, но он, к сожалению, только под Windows. Кроме того, по какой-то причине в интерфейс не были выведены важные и полезные возможности, например, возможность поставить виртуальную машину на паузу или, к сожалению, часто нужную опцию перезагрузки XAPI, когда какая-либо виртуальная машина повисает намертво
Есть и другие варианты, например sourceforge.net/projects/openxenmanager, но они они оказались недостаточно стабильными.
Существует VNC веб прокси www.xvpsource.org
Удобно, но требует Java, включенную в браузере (бывают проблемы), ну и в первую очередь это VNC, работать как с полноценным интерфейсом нельзя.
В результате на GTK3 был написан клиент под Linux, который так же можно использовать и в вебе. GTK Broadway позволяет через HTML5 + WebSockets в браузере получить вот такой инструмент
Данная технология не позволяет использовать его для множества пользователей одновременно, но с помощью неё можно полноценно работать как на Linux, так и через веб, лишь меняя параметры запуска (например, вынести в две иконки).
При использовании HTML5 фронтэнда накладывается множество ограничений на само приложение, и эти ограничения почему-то недокументированы. Примером ограничения является невозможность использования иконок в трее, относительного позиционирования окна и прочее. Последствия — от нестабильной работы до падений.
С документацией все плохо, на данный момент изучение broadway представляет собой чтение исходных кодов GTK3, так как кроме странички описания и новостей 3-х летней давности по broadway ничего нет.
API существует для C, C#, Java, Python и Powershell. Для С сборка только под линукс, но методом небольшой доработки исходников (на тот момент в mingw отсутствовала реализация какой-то функции) все успешно собралось и под Windows (MinGW). API работает через HTTP(S). API предоставляет и достаточно низкоуровневый доступ к виртуальным машинам.
Хотелось многого, от быстрого просмотра MBR кликнув мышкой, до извлечения файла с виртуалки или закачивания оного назад на выключенной виртуальной машине.
Такое бывает нужно, к примеру, в случае BSOD — извлечь реестр (и/или отредактировать его и залить обратно, например, выключив какой-либо драйвер), либо отредактировать опции загрузчика (включить дебаг через последовательный порт) и много всего. Для таких целей приходится прибегать к помощи загрузочного диска.
Но можно и иначе, виртуальную машину возможно экспортировать через HTTP GET в формате XVA, который представляет из себя TAR архив, внутри которого лежат блоки диска.
Если на лету читать этот архив, можно легко получить искомый MBR, и узнав смещения и типы разделов, читать файлы. Но на данный момент реализовано только извлечение MBR. Начиная с версии XenServer 6.2 есть возможность экспортировать RAW диск. В будущих версиях XenServer обещают ввести возможность экспортировать только дельту диска с произвольного смещения, что открывает новые возможности.
Контролировать работу с сетью виртуальной машины можно разными путями. Обычно это wireshark/tcpdump, установленные в виртуальную машину. Собирается нужный дамп и переносится в другое место для изучения. Но есть способ лучше — каждая запущенная виртуальная машина имеет свой dom-id, в соответствии с ним имеется и VIF устройство вида vifDOMID.0, доступное с гипервизора. Подключившись по SSH к гипервизору, можно легко получить дамп для любой произвольной включенной виртуальной машины (разумеется, имеющей добавленные сетевые карты), что делает тестирование чище и удобней (не нужно ставить PCAP драйвера). Далее, согаласно совету из Q&A программа делает пайп и запускает Wireshark. И в режиме реального времени получаем/фильтруем трафик.
API не предоставляет никаких средств, аналогичных guest operation у vix vmWare, например, копирование файлов.
И если с установкой основного софта проблема решается с использованием ISO на гигабитной сети, то с передачей команд/сборкой логов, просмотром данных все не так гладко. Приходится использовать промежуточные сетевые диски, а это не всегда возможно (условия тестирования, изолированная сеть). В любом случае это отнимает время и неудобно.
Самая первая идея, пришедшая в голову — использовать виртуальный последовательный порт. Можно активировать виртуальный com-порт, который средствами XenServer транслируется по TCP. Теперь, если по соответствующему адресу открыто соединение, мы можем отправлять/принимать сообщения на скорости 115200. На виртуальной машине же запущена фоновая программа «последовательный порт-CLI прокси», которая и выполняет транслирование команд из последовательного порта и возвращает результаты.
Тут не обошлось без подводных камней:
1)Передача обрывается при достижении 65535 переданных байт, если клиент (виртуальная машина) не передала за это время хотя бы один байт.
2) Включение порта работает только после рестарта. То есть включать необходимо либо на выключенной виртуальной машине, либо перезагружать её.
3) Если по какой-либо причине соединение оборвется, восстановить его до перезагрузки не имеется возможности.
4) Ну и самое плохое — если TCP сервер не отвечает — виртуальная машина зависнет на старте.
По этим причинам, параллельно искались другие методы, например, через xenstore. Это хранилище, доступное разным доменам. В том числе и виртуальным машинам. Там буфер порядка двух мегабайт, и достаточно быстрая запись. Но чтение медленнее чем 115200, требуются установленные xen tools (что не всегда возможно) и требуется тщательно тестировать код. Например, если записать больше, чем XENSTORE_PAYLOAD_MAX, судя по комментариям в исходниках драйверов, это грозит фатальными последствиями.
На данный момент думаю об использовании паравиртуального последовательного порта виртуальной машины через ssh тоннель на гипервизор, по аналогии с методом, указанным выше про сетевые карты. Судя по всему, это максимально безопасный и быстрый метод. На данный момент лишь проверено, что это осуществимо.
Точно таким же образом можно производить дебаг ядра Windows/Linux, пробрасывая по TCP/SSH последовательный порт, а локально через пайп уже подключается WinDbg, к примеру. Для таких целей была создана отдельная виртуальная машина с набором символов под все доступные версии Windows.
Работая с XenServer API и изучая его, на себе испытал многие плюсы и минусы opensource. Широкие возможности упираются в слабую документацию. Если VIX описан очень подробно, то с тем же xenserver api — 3 примера, 4 тестовых файла и комментарии в хэдерах исходников. Код понятный, но как связать отдельные функции — понятно либо разработчикам, либо тем, кто глубоко знает архитектуру Xen. Например, такая задача как узнать размер диска — нигде не описана. А не зная архитектуры — догадаться не слишком просто. Конечно, со временем вникая и углубляясь в строение Xen, многое стало понятней. Но на многие вопросы я так и не получил ответа, а в IRC чатах по выходным никто не отвечает — одинокие посетители пишут, что «сегодня же воскресение» :).
Но прогресс есть, за год пополнились wiki, статьи, примеры с демонстрацией новых возможностей. Очень надеюсь, что в будущем XenServer сможет стать сильным игроком на рынке с хорошим набором third party software
Под катом много текста и изображений.
Я работаю в команде тестирования Acronis в отделе поддержки пользователей, воспроизвожу пользовательские проблемы. Начиная с имитации дискового окружения и аппаратной части, заканчивая программным обеспечением и его специфическими настройками. Стояла задача — обеспечить работу тестового стенда с помощью двух рабочих станций. Были перепробованы и ESXi, Hyper-V, Proxmox и другие, но все же остановились на использовании XenServer. И вот что из этого получилось.
Аппаратное обеспечение
Изначально имелся один диск, на который и был установлен XenServer 4.2. По началу скорость устраивала. Чуть позже сервером стало пользоваться уже два человека, появилось уже тяжелое окружение (например, Exchange 2003 с базой данных в 300гб, которая постоянно работала под нагрузкой) и сразу стало понятно, что для комфортной работы текущей производительности явно недостаточно. Виртуальные машины грузились долго (а одновременно работает в среднем 20 штук на одном сервере), IO Wait часто достигал нескольких секуд. Надо было что-то делать.
Первое, что пришло в голову — RAID, но быстро это не реализовать, а решение нужно вчера. Как раз тогда в репозитории Debian добавили ZFS и было решено попробовать именно его.
Каждая из двух рабочих станций имеет материнскую плату с 4-мя SATA2 портами, 16ГБ ОЗУ и гигабитные сетевые карты.
Первая машина была выделена под гипервизор и загружается с USB флешки.
На вторую машину была установлена серверная Ubuntu 11.04, все необходимые пакеты для работы ZFS. Установлены 4ре диска по 1ТБ каждый. Был выбран RAID 10. Так как на материнской плате только 4 SATA порта, то ОС так же установлена на USB флешку.
Сам гипервизор соединен с ZFS через гигабитный свитч.
Были проведены эксперименты, прочитаны статьи, в итоге на ZFS была включена поддержка сжатия GZIP, выключена проверка контрольных сум, от дедупликации так же отказались. Это оказалось самым оптимальным решением, все 8 ядер очень редко нагружаются на 100%, и памяти вполне хватает. К сожалению, кэш на SSD протестировать не удалось :)
Сама файловая система экспортируется наружу через NFS, нативно поддерживаемый самим ZFS. А XenServer, да и ESX работают с NFS хранилищами. Это позволило использовать это же хранилище одновременно и для 2-х XenServer и для 3-х ESXi. Из этого ряда выбивается Hyper-V, который с завидным упорством и в Server 2012 отказывается работать с NFS, но это на совести MS.
Сконфигурированный ZFS выглядит так:
root@xenzfs:~# zpool status
pool: xen
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
xen ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sda ONLINE 0 0 0
sdb ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
sdc ONLINE 0 0 0
sdd ONLINE 0 0 0
errors: No known data errors
root@xenzfs:~# zpool list xen
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
xen 1.81T 1.57T 245G 86% 1.00x ONLINE -
Скорость записи на диск примерно соответствует удвоенной скорости отдельного диска.
На данный момент до 40 виртуальных машин одновременно работают без каких либо проблем с производительностью, тогда как раньше 20 машин приводили к провисаниям IOW до 5 секунд. Сейчас, спустя полтора года с запуска ZFS решение можно признать надежным, быстрым и крайне бюджетным. Поднятые NFS и CIFS сервера на хранилище позволяют его использовать и для других целей:
XenServer позволяет создавать ISO хранилища на сетевых дисках CIFS. Продукты перед релизным тестированием собираются в ISO образ (инсталляторы для Windows и Linux разных локализаций), который, в свою очередь, загружен на сетевой диск во внутренней гигабитной сети. В результате, одним движением мышки (субьективно XenCenter гораздо удобнее и быстрее в такой работе, чем vSphere) или скрипта мы вставляем эту ISO в виртульный CDROM (можно и десяткам машин одновременно) и ставим продукт прямо «с диска», что значительно экономит время на копировании больших (2GB+) файлов. Конечно, такое линейное чтение просаживает сеть, особенно если установка идет сразу с 5+ машин, но это все равно очень удобно.
Гигабитная сеть, через которую подключено хранилище, доступна и для виртуальных машин. Таким образом, можно использовать CIFS для любых других тестов. Для удобства на ZFS машине так же был поднят DHCP сервер.
Кроме виртуальных машин, тестировать приходится и на обычных рабочих станциях. Это тестирование и с ленточными накопителями и всевозможные REV, RDX диски и т.д. Нужно постоянно и быстро разворачивать различное окружение на машины. Будь то ESX гипервизор или Windows 2008R2 с Hyper-V или SLES с поднятым iSCSI multipath. Для этой цели используется DRBL
DRBL в сочетании с Clonezilla позволяет быстро разворачивать образы чере PXE с гибкими сценариями, а так же служит NAT сервером для уже развернутых машин.
Машины во внутренней сети имеют доступ через NAT во внешнюю сеть, а к ним самим через iptables имеется доступ по RDP.
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 3390 -j DNAT --to 192.168.1.50:3389
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 3391 -j DNAT --to 192.168.1.51:3389
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 3392 -j DNAT --to 192.168.1.52:3389
Набор различных ленточных накопителей подключен к одной машине, на которой используется бесплатный Tape Redirector, соответственно любая виртуальная машина может их использовать по iSCSI. Так же имеется отдельная виртуальная машина с поднятым MHVTL, но аппаратные накопители тоже нужны — не все проблемы проявляются на VTL.
Развертывание/клонирование делается в два клика с помощью утилиты, написанной на Perl+GTK. Работает достаточно просто — компонуется команда из блоков и выполняется через SSH. Кому интересно, репозиторий тут. Код сырой, но работает github.com/Pugnator/GTKdrbl
Интерфейс
Субьективно удобный интерфейс представлен только Citrix — XenCenter, но он, к сожалению, только под Windows. Кроме того, по какой-то причине в интерфейс не были выведены важные и полезные возможности, например, возможность поставить виртуальную машину на паузу или, к сожалению, часто нужную опцию перезагрузки XAPI, когда какая-либо виртуальная машина повисает намертво
Есть и другие варианты, например sourceforge.net/projects/openxenmanager, но они они оказались недостаточно стабильными.
Существует VNC веб прокси www.xvpsource.org
Удобно, но требует Java, включенную в браузере (бывают проблемы), ну и в первую очередь это VNC, работать как с полноценным интерфейсом нельзя.
В результате на GTK3 был написан клиент под Linux, который так же можно использовать и в вебе. GTK Broadway позволяет через HTML5 + WebSockets в браузере получить вот такой инструмент
Данная технология не позволяет использовать его для множества пользователей одновременно, но с помощью неё можно полноценно работать как на Linux, так и через веб, лишь меняя параметры запуска (например, вынести в две иконки).
При использовании HTML5 фронтэнда накладывается множество ограничений на само приложение, и эти ограничения почему-то недокументированы. Примером ограничения является невозможность использования иконок в трее, относительного позиционирования окна и прочее. Последствия — от нестабильной работы до падений.
С документацией все плохо, на данный момент изучение broadway представляет собой чтение исходных кодов GTK3, так как кроме странички описания и новостей 3-х летней давности по broadway ничего нет.
API
API существует для C, C#, Java, Python и Powershell. Для С сборка только под линукс, но методом небольшой доработки исходников (на тот момент в mingw отсутствовала реализация какой-то функции) все успешно собралось и под Windows (MinGW). API работает через HTTP(S). API предоставляет и достаточно низкоуровневый доступ к виртуальным машинам.
Диски
Хотелось многого, от быстрого просмотра MBR кликнув мышкой, до извлечения файла с виртуалки или закачивания оного назад на выключенной виртуальной машине.
Такое бывает нужно, к примеру, в случае BSOD — извлечь реестр (и/или отредактировать его и залить обратно, например, выключив какой-либо драйвер), либо отредактировать опции загрузчика (включить дебаг через последовательный порт) и много всего. Для таких целей приходится прибегать к помощи загрузочного диска.
Но можно и иначе, виртуальную машину возможно экспортировать через HTTP GET в формате XVA, который представляет из себя TAR архив, внутри которого лежат блоки диска.
$ tar -tvf test.xva ---------- 0/0 17391 1970-01-01 01:00 ova.xml ---------- 0/0 1048576 1970-01-01 01:00 Ref:946/00000000 ---------- 0/0 40 1970-01-01 01:00 Ref:946/00000000.checksum ---------- 0/0 1048576 1970-01-01 01:00 Ref:946/00000007 ---------- 0/0 40 1970-01-01 01:00 Ref:946/00000007.checksum ---------- 0/0 1048576 1970-01-01 01:00 Ref:949/00000000 ---------- 0/0 40 1970-01-01 01:00 Ref:949/00000000.checksum ---------- 0/0 1048576 1970-01-01 01:00 Ref:949/00000003 ---------- 0/0 40 1970-01-01 01:00 Ref:949/00000003.checksum
Если на лету читать этот архив, можно легко получить искомый MBR, и узнав смещения и типы разделов, читать файлы. Но на данный момент реализовано только извлечение MBR. Начиная с версии XenServer 6.2 есть возможность экспортировать RAW диск. В будущих версиях XenServer обещают ввести возможность экспортировать только дельту диска с произвольного смещения, что открывает новые возможности.
Сеть
Контролировать работу с сетью виртуальной машины можно разными путями. Обычно это wireshark/tcpdump, установленные в виртуальную машину. Собирается нужный дамп и переносится в другое место для изучения. Но есть способ лучше — каждая запущенная виртуальная машина имеет свой dom-id, в соответствии с ним имеется и VIF устройство вида vifDOMID.0, доступное с гипервизора. Подключившись по SSH к гипервизору, можно легко получить дамп для любой произвольной включенной виртуальной машины (разумеется, имеющей добавленные сетевые карты), что делает тестирование чище и удобней (не нужно ставить PCAP драйвера). Далее, согаласно совету из Q&A программа делает пайп и запускает Wireshark. И в режиме реального времени получаем/фильтруем трафик.
Guest tools и последовательный порт
API не предоставляет никаких средств, аналогичных guest operation у vix vmWare, например, копирование файлов.
И если с установкой основного софта проблема решается с использованием ISO на гигабитной сети, то с передачей команд/сборкой логов, просмотром данных все не так гладко. Приходится использовать промежуточные сетевые диски, а это не всегда возможно (условия тестирования, изолированная сеть). В любом случае это отнимает время и неудобно.
Самая первая идея, пришедшая в голову — использовать виртуальный последовательный порт. Можно активировать виртуальный com-порт, который средствами XenServer транслируется по TCP. Теперь, если по соответствующему адресу открыто соединение, мы можем отправлять/принимать сообщения на скорости 115200. На виртуальной машине же запущена фоновая программа «последовательный порт-CLI прокси», которая и выполняет транслирование команд из последовательного порта и возвращает результаты.
Тут не обошлось без подводных камней:
1)Передача обрывается при достижении 65535 переданных байт, если клиент (виртуальная машина) не передала за это время хотя бы один байт.
2) Включение порта работает только после рестарта. То есть включать необходимо либо на выключенной виртуальной машине, либо перезагружать её.
3) Если по какой-либо причине соединение оборвется, восстановить его до перезагрузки не имеется возможности.
4) Ну и самое плохое — если TCP сервер не отвечает — виртуальная машина зависнет на старте.
По этим причинам, параллельно искались другие методы, например, через xenstore. Это хранилище, доступное разным доменам. В том числе и виртуальным машинам. Там буфер порядка двух мегабайт, и достаточно быстрая запись. Но чтение медленнее чем 115200, требуются установленные xen tools (что не всегда возможно) и требуется тщательно тестировать код. Например, если записать больше, чем XENSTORE_PAYLOAD_MAX, судя по комментариям в исходниках драйверов, это грозит фатальными последствиями.
На данный момент думаю об использовании паравиртуального последовательного порта виртуальной машины через ssh тоннель на гипервизор, по аналогии с методом, указанным выше про сетевые карты. Судя по всему, это максимально безопасный и быстрый метод. На данный момент лишь проверено, что это осуществимо.
Точно таким же образом можно производить дебаг ядра Windows/Linux, пробрасывая по TCP/SSH последовательный порт, а локально через пайп уже подключается WinDbg, к примеру. Для таких целей была создана отдельная виртуальная машина с набором символов под все доступные версии Windows.
Заключение
Работая с XenServer API и изучая его, на себе испытал многие плюсы и минусы opensource. Широкие возможности упираются в слабую документацию. Если VIX описан очень подробно, то с тем же xenserver api — 3 примера, 4 тестовых файла и комментарии в хэдерах исходников. Код понятный, но как связать отдельные функции — понятно либо разработчикам, либо тем, кто глубоко знает архитектуру Xen. Например, такая задача как узнать размер диска — нигде не описана. А не зная архитектуры — догадаться не слишком просто. Конечно, со временем вникая и углубляясь в строение Xen, многое стало понятней. Но на многие вопросы я так и не получил ответа, а в IRC чатах по выходным никто не отвечает — одинокие посетители пишут, что «сегодня же воскресение» :).
Но прогресс есть, за год пополнились wiki, статьи, примеры с демонстрацией новых возможностей. Очень надеюсь, что в будущем XenServer сможет стать сильным игроком на рынке с хорошим набором third party software
