Краткий обзор нововведений гипервизора Citrix XenServer 7.1

    В предыдущей статье я кратко описал основные новшества XenServer 7.1. Сегодня подробно остановимся на улучшениях седьмой версии XenServer и дополнениям в 7.1. Заинтересовавшихся прошу под кат.


    Итак, пройдемся по основным нововведениям седьмого поколения Citrix XenServer:

    I. В первую очередь, стоит отметить улучшения, сделанные для оптимизации установки специализированных инструментов виртуализации, которые раньше нужно было ставить самостоятельно. Сейчас их можно устанавливать через встроенный загрузчик обновлений Windows из репозитория данной ОС. Главная проблема с установкой XenTools возникает в ситуации, когда количество виртуальных машин исчисляется сотнями. Обычно это выглядело так: монтируем образ диска с XenTools, запускаем исполняемый файл для установки, Windows перезагружается и завершает установку инструментов виртуализации. Но в ситуации, когда на одном XenServer работает большое количество ВМ или же у нас несколько гипервизоров, установка становится большой проблемой для конечного заказчика (и особенно администратора сети). В XenServer 7 реализован другой вариант: поставленная на гипервизор ОС Windows определяет, где она установлена, скачивает необходимые утилиты для того чтобы управлять операционной системой виртуальной машины с Windows Update. В результате администратору не нужно вручную устанавливать обновления для каждой машины. Однако стоит учесть, что такой вариант справедлив только для Enterprise редакции XenServer.

    II. Теперь доступна интеграция гипервизора с Citrix Insight Services, что дает возможность получения анализа существующей инфраструктуры и ошибок, даже если у заказчика нет официального контракта на техническую поддержку Citrix. Insight Services открыт для всех пользователей, включая бесплатные редакции, и если у заказчика возникает необходимость в проверке виртуальной инфраструктуры на наличие ошибок, он может уже на начальном этапе провести диагностику самостоятельно. Используя учётную запись для сайта cis.citrix.com, администратор подключается к службе через XenServer, выбирает в соответствующем меню нужное действие и сервер отправляет журналы на анализ в Citrix. После разбора логов клиенту по электронной почте приходит ссылка на доступ к детальному отчёту – в каком состоянии находится инфраструктура, что с точки зрения Citrix рекомендуется исправить или установить дополнительно. В качестве примера – в прошлом году на тестировании у одного из заказчиков было выявлено, что на 3 серверах установлены три разных версии firmware, в одной из которых содержалась критическая ошибка, проявляющаяся как раз в работе с любой виртуальной инфраструктурой, о чём честно предупреждал сайт производителя оборудования. Также выяснилось, что на всех трех серверах XenServer были установлены разные версии сборки, набор обновлений также отличался. Фактически с помощью Citrix Insight Services удалось устранить большую часть проблем с виртуальной инфраструктурой.



    Можно настроить систему на периодический сбор журналов действий. Например, раз в две недели (причем администратор может указать, что он считает допустимым отправить на анализ, а что нет) в автоматизированном режиме эти журналы будут отправляться на анализ, после чего администратор получит рекомендации по устранению тех или иных ошибок и общей настройке системы. Если администратор не хочет все это «пускать на самотек» в автоматизированном режиме, он снимает галочку в соответствующем меню. При этом все равно есть возможность из меню XenCenter, не выгружая логи автоматически, пройдя по меню выбрать необходимые журналы действий или другую информацию, которую нужно отправить на анализ и загрузить данные на Citrix Insight Services. Если же у заказчика есть платная редакция с саппортом, то достаточно указать номер кейса и к этому кейсу будут подгружены соответствующие логи (чтобы саппорту не пришлось просить удаленного подключения к инфраструктуре, а администратору решать вопросы с предоставлением удалённого доступа).

    III. В седьмой версии XenServer был существенно изменен состав и размер разделов. В предыдущих версиях гипервизора все журналы действий лежали на dom0-разделе, что могло приводить к проблемам при большом количестве собираемой журналами информации. Сейчас для них выделен отдельный раздел, что снижает риск «фриза» системы, когда в нештатной ситуации журналы начинают забивать раздел dom0. Также был увеличен размер разделов primary и backup. Для того чтобы развернуть инфраструктуру гипервизора XenServer 7 теперь требуется, как минимум, 42 ГБ свободного места на жестком диске сервера. Но надо понимать, что это не размер дистрибутива, а размер дисковой емкости под разделы, с помощью которых система управляется. Сейчас раскладка выглядит так: 1 ГБ на swap, 4 ГБ для хранения журналов, 18 ГБ на основной и 18 ГБ на резервный разделы, 0,5 ГБ для UEFI, если загрузка осуществляется с его помощью. На тех машинах, где стоит UEFI, поддерживается загрузка через него, но эта возможность появляется только для тех установок, которые ставятся «с нуля». То есть если имеется старый сервер с установленным XenServer 6.5, а в сервере есть UEFI, то для того чтобы задействовать возможность загрузки с UEFI нужно полностью переустановить гипервизор XenServer, а не проводить процедуру обновления.

    IV. Один из основных источников затрат при виртуализации десктопов – это хранилище данных. Отсюда объясним рост популярности гиперконвергентных систем, когда снижаются требования к системе хранения данных. В седьмой версии XenServer расширился перечень поддерживаемых протоколов доступа к системам хранения. В дополнение к обычным fibre channel теперь поддерживаются сетевые карты с fibre channel over ethernet от Broadcom, Intel и HP. Также поддерживается загрузка по iSCSI на серверах Cisco UCS, что позволяет использовать бездисковые серверы и свободно подключаться к дисковой полке.



    V. Citrix была первой компанией, которая сначала реализовала проброс GPU в виртуальную машину, а после и виртуализацию графических карт NVIDIA GRID. В версии XenServer 7 поддерживается до 128 виртуальных графических карт на один сервер и реализована поддержка виртуальных графических адаптеров (vGPU) для гостевых операционных систем Linux. Также появилась возможность использовать виртуальные графические процессоры без установки графической карты. Это реализуется при использовании серверов с процессорами Intel Broadwell и Skylake с чипсетом C226. В этом случае встроенная графика Intel Iris Pro может быть «разрезана» на семь виртуальных GPU. Плюс решения в том что для многих прикладных продуктов скорость работы графической карты не очень важна, главное чтобы карта в принципе была видна системе. На текущий момент такая возможность есть только у XenServer, но работает это только для однопроцессорных серверов. Преимущества получают офисные и другие приложения Windows, приложения для просмотра CAD-моделей. Стоит отметить, что разделение на виртуальные графические карты возможно и в рамках виртуального десктопа и в терминальном режиме.

    VI. Если говорить о безопасности VDI, то на сегодняшний день возможно несколько вариантов защиты. Обычный подход – в виртуальной ОС есть полноценный агент, который работает в непривилегированном режиме и отслеживает изменения в системе. Агент что-то замечает и пытается с этим бороться. Однако если виртуальных машин на сервере несколько десятков или даже сотен, то получается ситуация когда система обслуживает исключительно саму себя. С легким агентом ситуация проще – система работает с внешней виртуальной машиной с которой агент обменивается хэшем. Хотя нагрузка существенно снижается, но не все же не до конца. В XenServer 7.1 реализован безагентский вариант защиты от уязвимостей нулевого дня. Компания Bitdefender вместе с Intel и Citrix разработала и интегрировала с гипервизором отдельную виртуальную машину, которая сканирует память гостевых виртуальных машин. Security Appliance работает на гипервизоре и занимается анализом памяти виртуальных машин самостоятельно. В рамках самой виртуальной ОС никаких агентов не работает. При появлении зловредной активности она блокируется на уровне гипервизора.


    Bitdefender Hypervisor Introspection (HVI)

    VII. В XenServer 7 реализована поддержка контейнеров не только для Linux, но и для Windows Server 2016. Для ряда разработчиков такая схема весьма востребована, потому что позволяет обеспечить гибкость разработки и модернизации приложений, а также ускорить цикл разработки. В рамках XenCenter существует единый интерфейс управления контейнерами, администратор видит все типы контейнеров и может обеспечивать их рабочие циклы. Если говорить про консоль Docker (поддерживается для Debian 8, Ubuntu 14.04, CoreOS & RHEL/CentOS/OEL 7.x), то доступ к ней также можно получить из XenCenter. То же относиться и к контейнерам Windows Server 2016.

    VIII. Были проведены изменения в работе процессов Datapath и Control-Plane в управляющем домене (dom0), поскольку ранее повышенная нагрузка при передаче данных по сети или работе с дисковыми операциями, приводила к тому, что переставали отвечать сервисы управления XenServer. С выходом XenServer 7 эти процессы выделили в отдельную группу (Cgroups), что позволяет им не зависеть от нагрузки, которая создается сетевой и дисковой подсистемой. Это позволило значительно снизить время на загрузку виртуальных машин и повысить надёжность и стабильность работы гипервизора.


    Cgroups позволяет процессам Control-Plane работать когда необходимо

    IX. В версии 7.1 применен механизм Live-patching, предлагающий пакетное применение обновлений. Раньше для того чтобы установить любой новый патч на гипервизор, требовалась перезагрузка системы. Live-pаtching, разработанный Citrix и Oracle (для Linux – Red Hat), позволяет при загрузке патча определить насколько он требует изменений, связанных с перезагрузкой и если она не требуется, обновление применяется без прерывания работы гипервизора. Сначала патч (в виде RPM) устанавливается в оперативной памяти и только в случае возможности переносится на диск. Система информирует администратора о том, что нужно перезагрузиться либо можно подождать до завершения работы или плановой перезагрузки. При этом в оперативной памяти изменения системы будут приняты. Если требуется обязательная перезагрузка, администратор получит об этом предупреждение. Пакеты исправлений для XenServer сменили формат – теперь они выпускаются в стандартном формате isо-файлов. Их не нужно отдельно загружать в dom0, просто появляется новое виртуальное дисковое подключение, монтируется iso-файл и происходит обновление соответствующего компонента.

    X. Функция кеширования трафика PVS (провижининг сервер) повышает скорость загрузки десктопов на 30% и гарантирует уменьшение сетевого трафика до 98%. Если сейчас виртуальная машина загружается с PVS, то для каждой виртуальной машины осуществляется передача данных, даже если все они загружаются с одного образа. При включении кеширования трафика PVS, после загрузки одной виртуальную машину, эти данные будут закешированы на гипервизоре и теперь при выполнении загрузки следующих виртуальных машин, они будут обращаться к dom0, не нагружая сеть и сервер PVS. В результате если мы запускаем больше одной машины из одного образа, то получаем ощутимый выигрыш за счет снижения нагрузки на сетевую подсистему. Для возможности использования этой функциональности необходимы сервер PVS версии начиная с 7.12 и Open virtual swich, а также XenServer 7.1.


    Кеш операций PVS на XenServer

    Вот наиболее масштабные и существенно влияющие на работу системы изменения, сделанные в седьмой версии Citrix XenServer. Помимо этого, есть ряд менее значительных нововведений:

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

    • Добавлен клиент PuTTY для того чтобы из консоли подключаться к виртуальным машинам. Исполняемый файл PuTTY включен в утилиту установки XenCenter. Кнопка на закладке «Console» запускает клиента PuTTY, который подключится к ВМ или dom0 автоматически.

    • Поддерживаются все новейшие CPU, гипервизор Xen обновлен до версии 4.7, dom0 построен на 64-битном CentOS 7.2.

    • Был переработан раздел, связанный с интеграцией Aсtive Directory. Если ранее гипервизор использовался в инфраструктуре с очень большими группами, которые мы хотели завязать на управление через XenCenter, то система замедлялась из за проверки большого количества токенов безопасности. Сейчас же используется другой провайдер для работы с Active Directory и в результате гарантирована масштабируемость для инфраструктур с миллионами пользователей и десятками тысяч групп, при интеграции с XenCenter.

    • Помимо Microsoft Hyper-V, VMware ESXi и Nutanix Acropolis теперь в гиперконвергентных решениях Nutanix можно использовать Citrix XenServer. На текущий момент Acropolis не имеет возможности работы с виртуальной графикой, не может работать с Bitdefender Hypervisor Introspection, нет возможности работы с кешированием трафика PVS, поэтому если требуются какие-либо из указанных выше функций то рекомендуется использовать XenServer. Однако некоторые функции XenServer не могут быть использованы при интеграции в Nutanix, так как они реализуются функционалом гиперконвергентной системы.

    С прошлого года Citrix начал выпускать LTSR-версии продуктов (Long Term Service Release). Заказчик, выбравший LTSR-версию, может быть уверен, что при необходимости эта версия будет поддерживаться в течение 10 лет. XenServer 7.1 как раз является первой LTSR-версией продукта. Ее поддержка закончится в 2022 году, а жизненный цикл завершится в 2027 (EOL).

    Задавайте ваши вопросы в комментариях, и я с радостью на них отвечу.
    Поделиться публикацией
    Похожие публикации
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 14
    • 0
      На текущий момент такая возможность есть только у XenServer, но работает это только для однопроцессорных серверов.

      У VMware давно заявлена поддержка интеловской интеграшки, только драйверов не найти.
      • +1
        Добрый день!
        Скорее всего на сайте коллег речь идёт о поддержке GVT-s, а не GVT-g
        выдержка с сайта Интел (https://software.intel.com/en-us/blogs/2014/05/02/intel-graphics-virtualization-update)

        Intel GVT-s

        Commercially available as Virtual Shared Graphics Adaptor (vDGA, VMWare) and Remote FX (Microsoft), this graphics virtualization approach requires a virtual graphics driver in a virtual machine, use an API forwarding technique to interface with the Intel’s graphics hardware (fig-2). Single GPU hardware can be shared amongst many concurrent users, while the graphics hardware remains abstracted from the applications. Specific sharing algorithms remain proprietary to the virtual graphics driver. Many commercial desktop and workstation remoting products in the market use this approach.

        Отличия разных вариантов виртуализации графики Интел рассматриваются тут — https://01.org/sites/default/files/downloads/igvt-g/gvtflyer.pdf

        На сайте, где рассматривается GVT-g упоминаются XenServer и KVM https://01.org/igvt-g
        Подробно об использовании технологии виртуализации графики Intel в XenDesktop можно прочитать тут — https://01.org/sites/default/files/documentation/intel-citrix-vdesktop-refresh_0.pdf

        Сравнение производителей графических чипов с точки зрения виртуализации хорошо рассмотрено тут — http://www.brianmadden.com/opinion/NVIDIA-AMD-and-Intel-How-they-do-their-GPU-virtualization

        • 0
          Хорошо бы ещё увидеть статью по выстраиванию различных вариантов инфраструктуры. В прочем мой вопрос может быть задан любому производителю решений виртуализации, но каждый на него ответит — вот 1 или несколько физических серверов, ставь, объединяй в пул, подключай дисковую полку, размещай там образы и вперёд…

          Но по факту тут заранее не понятно, какие скорости от дисковой подсистемы будут требоваться, какая полоса должна быть выделена в сети и т.д.

          Вот у меня например есть сервер. Допустим RAM и CPU хватает на мои потребности. В нём стоит аппаратный raid контроллер и на нём я сделал 2 массива — один под нужды XenServer, второй под размещение VM. Этот второй массив — RAID10, на не помню каких сигейтах серверной серии, 7200 об, 128.
          И есть второй, допустим точно такой же сервер. Хочу что бы VM мигрировали туда сюда, в случае необходимости — по запросу или в аварийной ситуации.
          Из того, что попадалось в качестве решения — собрать Ceph клайстер на двух хранилищах для VM. Но под это потребуется либо волокно утилизировать (они у меня на разных географических локациях), либо выделить некую полосу в магистральном канале. Здесь интересно — какую? И может есть что то ещё попроще, более штатное к самому XenServer что ли..?
          • 0
            Правильно заданный вопрос содержит в себе часть ответа :)
            Для того, чтобы сказать, какая скорость дисковой подсистемы понадобится нужно знать что за рабочую нагрузку вы «крутите» внутри виртуальных машин. В одном случае необходимые вычисления могут полагаться только на оперативную память и тактовую частоту процессора, а в другом случае активно работать с дисковой подсистемой. Естественно ответ будет в каждом случае разный. С сетью такая же ситуация + нужно понимать какой аспект интересует: сколько кбит/сек нужно для работы пользователя с той или иной виртуальной машиной (тогда это вообще вопрос не к гипервизору, а к терминальной системе или системе виртуализации десктопов) или интересует полоса пропускания, необходимая для например перемещения виртуальной машины с одного хоста на другой (XenMotion или Storage XenMotion) в случае нахождения хостов на разных площадках. Тут опять нет однозначного ответа — всё сильно зависит от размера виртуальной машины и объёма виртуальной оперативной памяти.
            У вас есть один сервер с XenServer, с работающими виртуальными машинами. Если вы хотите, чтобы в случае аварии машины автоматически перезапустились на другом хосте или при необходимости можно было бы переместить машины не прерывая предоставления сервиса, то для начала нужно добавить в пул второй сервер. HA, XenMotion, Storage XenMotion доступны даже в бесплатной редакции.
            • 0
              да, вопрос слишком широкий и (1) поэтому статья бы с какими нибудь хорошими практиками для различных задач была бы кстати… а (2) я наверное не смогу правильно задать вопрос, так как совсем не варюсь в теме. У меня есть желание и я его просто изложил)
              Вот вы что то рассказали, вроде бы очевидное, но мне есть от чего отталкиваться в дальнейшем разговоре.
              Допустим задачи такие:
              — 2 терминальных сервера для работы 1С и софта для управления оборудованием. На них нагрузка практически никакая, т.к. вся бухгалтерия редко работает одновременно, а софт никаких данных не собирает, а только отправляет команды и принимает ответы от оборудования через интерфейсы.
              — 1 Win сервер с MSSQL базой, размер 10Гб. Работает с ней одно приложение с одним пользователем — биллинг, когда считает — никто нагрузки не замечает, кроме поедания всей оперативы (12Гб).
              — почта, днс, Сотрудников меньше 20, почты не много.

              Сейчас всё это крутится на xen 4 развёрнутом моими кривыми руками и образами lvm патриций на аппаратном raid10. В общем проблем с производительностью нет. Но хотим получить инструменты XenServer… попутно купили второй сервак с целью получения (в идеале) горячего резерва, размещённого на разной географии. Возможно мы обойдёмся без горячего резерва (подразумеваю, что пользователи при таком резерве даже не заметят, если один из серверов виртуализации отвалится), но с быстрым запуском этой VM на другом сервере без потери оперативной информации (бэкапы делаем, но не каждые 5 минут конечно)
              Надеюсь я смог приблизить себя к хорошему ответу на свои вопросу ))
            • 0
              По трафику — один из наших заказчиков недавно проводил тестирование (самостоятельно, без участия вендора, с использованием автоматизированных средств тестирования) работы терминальных приложений (без мультимедийных возможностей). В результате усреднённая нагрузка на канал составила около 30 кбит/сек (это с печатью и прикреплением документов с локальной рабочей станции). На случай, если печать и прикрепление файлов будет идти с большинства рабочих станций одновременно была выдана рекомендация на предоставление 1 пользователю 64 кбит/сек.

              Теперь про XenServer 4 — давно надо обновлять. Версия XenServer 7.1 также доступна в виде бесплатной редакции. Единственное отличие от XenServer Standard Edition — на бесплатную редакцию нельзя купить техническую поддержку. Так что спокойно добавляйте в пул второй сервер и машины можно будет сразу перемещать между хостами (при условии что у вас процессоры одинаковые или могут быть маскированы гипервизором). High Availability тоже работает в бесплатной редакции и если вы его настроите, то машина в случае падения узла 1 автоматически перезапустится на узле 2, но (!) данные с которыми она работала — потеряются.
              • 0
                Нагрузка на сеть никакая, поэтому даже внимание не стал этому уделять. Про сеть я беспокоился по вопросу, если разворачивать хранилище Ceph и там будут дублироваться запись на оба сервера. И я знаю, что 1Гб/с не хватит, что бы это хорошо работало.

                А Xen 4 — это прям Xen hypervisor, не XenServer от Citrix…

                High Availability тоже работает в бесплатной редакции и если вы его настроите, то машина в случае падения узла 1 автоматически перезапустится на узле 2, но (!) данные с которыми она работала — потеряются.


                А потеряются данные, это на уровне того, что было не сохранено, или…? Данные то в принципе там будут синхронизироваться между серверами? Или будет лишь быстрый перезапуск образа VM, в котором можно будет продолжать пользовать софтом, а данные (типа 1С баз, документов) нужно будет хранить на отдельном ресурсе, вроде бы NAS и прочих шар?
              • 0
                HA = High Availability = Высокая Доступность и это подразумевает, что вы возможно потеряете то, что в данный момент находилось в оперативной памяти, https://en.wikipedia.org/wiki/High_availability
                Виртуальная машина и её данные в случае HA должны располагаться на общей для пула серверов системе хранения данных и тогда, в случае падения ВМ, которая работала на сервере 1, она перезапускается на сервере 2 с общей СХД и оттуда же берёт данные, необходимые ей для работы. Этот подход отличается от Fault Tolerance, кластеризации серверных приложений и других методов обеспечения непрерывности и отказоустойчивости. Так что это «быстрый перезапуск», а данные лучше располагать за пределами ВМ, на отдельном ресурсе. Ну и общая практика такова — чем больше «девяток» вы хотите получить для своей системы, тем более дорогой она оказывается.
                • 0
                  Ага. Но тогда это не мой вариант, потому что у меня нет общей СХД… У меня есть по одному raid10 массиву на каждом из серверов.
                  Получается тут без вариантов, надо мутить на более низком уровне систему хранения на этих серверах, и только потом использовать HA.
                • 0
                  Хмммм — мне кажется, что купить или собрать простой NAS будет проще и дешевле и надёжнее. Но это моё личное мнение.
                  • 0
                    чем _простой_ nas будет надёжнее raid10 на аппаратном контроллере Intel в шасси Intel?
                    NAS'ы как бы есть, qnap, мы с iscsi интерфейсы тянем, для бэкапов/хранения справочных баз и пр… ну шара там всякая, понятное дело…

                    В общем получается, что если реализовывать всё внутри сами серверов, то без drdb или ceph пока не обойтись… а им нужен хороший канал. Стояло бы всё в пределах одного узла — проблемы бы и не было между ними оптику кинуть, да и пусть оно там себе варится по 10Гб аплинку друг в друга. Но нам нужно выделять для этого волокно между локациями… отсюда и все поиски.

                    PS: вот и я промазал с ответом и запостил в новую ветку… =(
                    • 0
                      Не знаю, зачем я повёлся. Работал пул на два сервера(XS1 и XS2) под XenServer 6.5 с хранилищем на NAS и бэкап-скриптом от Andy Burton — и горя не знал. Дёрнул-ведь чёрт обновиться…

                      1. Выключил HA.
                      2. Вывел из пула сервер XS1(мастером работает XS2):
                      — Обновил винты, установил чистый Citrix XenServer 7.2
                      — Накатил все апдейты
                      3. ПРОБЛЕМА 1 — в пуле не живут вместе сервера 6.5 и 7.2; пул обратно не собрать.
                      — в нерабочее время обновляю на работающем сервере(XS2) 6.5 => 7.2
                      — как следствие теперь оба сервака на 7.2 и дружно сидят в пуле.
                      4. Перетащил все виртуалки на сервер XS1 и сделал его мастером пула, чтобы второй сервак так же обновить по железу и поставить с нуля Citrix XenServer 7.2
                      5. ПРОБЛЕМА 2 — вытащить из пула сервак XS2 не получается. "The SR.shared flag cannot be set to false while the SR remains connected to multiple hosts". Да и фиг-то с ним, думаю. Всё равно все виртуалки на NAS хранятся — не буду винты обновлять. Накачу-ка я апдейты…
                      6. ПРОБЛЕМА 3 — "XS2: The update precheck stage failed: RPM package validation requires a GPG key that is not present on the host". WTF, Citrix?
                      7. ОК, дружище. Кажется интуиция правильно говорит, что XenServer 7.2(updated from 6.5) не очень хорошая идея в продакшене и чистая установка необходима. Выключаю капризный сервер XS2.
                      8. Повторяю всё, что сделал ранее с XS1:
                      — Обновил винты, установил чистый Citrix XenServer 7.2
                      — Дурак, не накатив апдейты ввёл XS2 в пул и поимел опять:
                      -.- Ошибку установки апдейтов "XS2: The update precheck stage failed: RPM package validation requires a GPG key that is not present on the host"
                      -.- Невозможность вывести сервер XS2 из пула "The SR.shared flag cannot be set to false while the SR remains connected to multiple hosts"

                      Где ж я так нагрешил-то. © Быков
                      Работает — не трожь.
                      Стремясь к лучшему, мы часто портим хорошее. © Шекспир

                      Да, есть решение для "ПРОБЛЕМА 2" /opt/xensource/packages/iso SR pbd was blocking the host from being ejected. И что ведь удивительно, сервер XS2 вне пула прекрасно принял все апдейты, избавив от "ПРОБЛЕМА 3".

                      WTF, Citrix? Это Live-patching?

                      p.s. По ПРОБЛЕМА 3 можно почитать если вы пользуете pvsaccelerator или OpenManage / Zabbix agent. Оба случая не мои.
                      • 0
                        Кстати, апдейты с XS72E001 по XS72E009 до сих пор требуют перезагрузки сервера после каждого апдейта.
                        • 0

                          Алексей, а как-то странно получается — вы пытаетесь смешать 2 варианта — upgrade и установка с нуля. Кто мешал пойти описанным в руководстве путём — обновление в рамках пула одного сервера, а затем второго.
                          Функционал Live Patching требует платной Enterprise редакции.
                          Так что я бы определил самой главной ПРОБЛЕМУ 0 — не желание ознакомится с документацией по продукту, а вместо этого принятие решений по изменению конфигурации рабочей среды по принципу "на авось", этакий agile-style — ввяжемся в драку, а там посмотрим, что к чему.

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.