XenApp / XenDesktop — согласен, в статье они стояли в цепочке переименований, а это разные продукты: SBC vs VDI. С XenDesktop 7 начали сходиться на одной платформе, CVAD объединил в 2018-м. Поправил подачу.
ICA / HDX — тут вопрос ракурса. Смена парадигмы — да, фокус сместился от архитектуры вычислений к UX, не спорю. Но ICA-транспорт под капотом остался: порты 1494/2598, виртуальные каналы, ICA RTT как ключевая метрика. HDX — набор технологий, который живёт поверх ICA-сессии. «Надстройка» занижает масштаб, согласен — поменял на «эволюция поверх ICA».
Виртуальные каналы RDP — моя ошибка, до 31 статического + динамические каналы. Протокол поддерживает классы приоритетов, но административное управление ими ограничено по сравнению с ICA/HDX, где приоритизация, QoS и мультистрим настраиваются на уровне платформы.
BCR — да, ограничений хватает, в статье есть оговорка, но можно было акцентировать сильнее. Тема на отдельный разговор.
KVM — AHV и OpenShift Virtualization под капотом оба KVM, так что по семействам гипервизоров Citrix покрывает весь серверный рынок: Hyper-V, VMware, Xen, KVM. Но согласен — в статье формулировка читалась как поддержка vanilla KVM, а это не так. Спасибо за уточнение по AHV — действительно совместная работа команд.
Оптимизация ВКС — верно, в статье акцент на Teams как на самый частый enterprise-сценарий, но картина шире. Cisco, Zoom, Avaya, Vidyo — каждый писал свой VDI-плагин, используя SDK виртуальных каналов. Это работа экосистемы, не одного вендора. Упрощение.
NetScaler — согласен по всем пунктам. В статье была ложная цепочка «бывший ADC, бывший Access Gateway» — это разные истории. NetScaler — ADC-платформа, купленная в 2005. NetScaler Gateway — наследник Access Gateway, но сам NetScaler — нет. Не входил в базовую поставку, GSLB — тем более. Исправил. Про перманентные лицензии — тоже добавил: с LAS perpetual у NetScaler больше не поддерживаются.
LAS — важная деталь, которая в статье отсутствовала. Добавил: с 15 апреля 2026 файловое лицензирование прекращает работать, обязательный переход на облачную активацию через Citrix Cloud. Для air-gapped сред и организаций с требованиями к суверенитету — отдельная история.
TCO — согласен, минное поле. В статье намеренно не считали, а предупредили: кто обещает экономию — либо продаёт, либо не считал.
Тридцать решений? Серьёзно? Я насчитал чуть больше десятка, и то если считать щедро. Если их реально тридцать — был бы благодарен за список, потому что мне правда интересно, кто все эти люди. Подозреваю, что часть из тридцати — это форк форка OpenUDS с другим логотипом и лендингом, но готов удивиться. По функционалу — если кто-то из них реально закрыл то, что в статье описано как отсутствующее, — назовите, посмотрю руками, если выйдет. Ну или скоро ЦИПР, там надеюсь увижу. Но «функционально они очень разные» без конкретики — это как «у нас тоже enterprise», пока не спросишь про политику буфера обмена по типу данных.
Китай — это вообще отдельная вселенная, не стал туда уходить. Но вы правы, наверное Huawei отличился.
Зависимость от обвязки — важный момент, которого в статье не хватало. VDI не в вакууме: гранулярность политик CVAD — это ещё и MS AD с его GPO-машиной. Когда российские решения работают на Linux с FreeIPA или ALD Pro — у них физически нет той же базы для политик. Часть ограничений — не в VDI-платформе, а в инфраструктуре вокруг неё. Добавил.
По поводу ИИ — не буду лукавить, март 2026 на дворе, я без ИИ уже кажется в туалет не хожу. Использовал — когда формулировал мысли, когда выстраивал структуру, когда перепроверял факты (как видите, не всегда успешно). Кое-где он меня подвёл, кое-где я подвёл сам себя — не перепроверив то, в чём был уверен. Не представляю сегодня индустрию без этого инструмента и искренне желаю каждому его применять. Это изобретение уровня электричества и интернета, и прятать его использование — всё равно что в 2005 стесняться, что гуглишь.
Omnissa / Broadcom — вы правы, формулировка «под крылом Broadcom» была некорректной. KKR купил EUC, Omnissa — самостоятельная компания, vSphere for Desktop доступна через Omnissa. Привязка к серверным проблемам Broadcom для EUC не работает — VDI-инфраструктура всегда жила отдельно. На Gitex Africa 2025 я общался с европейскими интеграторами — беспокойство было реальным: неопределённость с партнёрской программой, вопросы к roadmap под KKR, несколько команд реально смотрели альтернативы. Но я из России, на международных мероприятиях бываю пару раз в год — картинка доходит с задержкой. Вы, судя по всему, работаете с этим стеком плотнее и видите ситуацию актуальнее. Переформулировал: не «волна миграций», а подвижность рынка на фоне неопределённости переходного периода.
По Blast и политикам — функционал есть у обоих, не спорю. Приоритизация каналов, BEAT, Smart Policies, Virtual Channel Allow List — всё документировано. Но нюансы остаются. Virtual Channel Allow List: вы сами привели KB84156 — «By default this value is set to 0 so the feature is disabled meaning all channels are allowed to open». У Citrix эта функция включена по умолчанию с CVAD 2109 (2021) — все сторонние каналы закрыты из коробки. Дефолтная позиция противоположная: у Citrix нужно открыть, у Horizon нужно закрыть. Smart Policies через DEM — работают, но DEM Enterprise Edition нужен для Smart Policies (Horizon Standard/Advanced получают DEM Standard, где Smart Policies нет). И архитектурно: у Citrix Access Policy на Delivery Controller решает до создания сессии — это фаервол на уровне подключения. DEM Smart Policies применяются внутри уже созданной сессии.
Переписал врезку с конкретикой и без категоричных формулировок. Спасибо за ссылки — статья стала точнее.
Первый коммерческий продукт — Citrix Multiuser — действительно был расширением для OS/2, не для DOS. Но подключаться к нему можно было с DOS-машин через Multiuser Link (RS-232, модемы, ICA-эмуляция терминала). Версия 2.0 в 1992-м уже была совместима с DOS-приложениями, а WinView в 1993-м запускал и DOS, и Windows. Так что DOS в истории Citrix появился рано — но не как первый продукт, а как среда подключения и потом как платформа для приложений.
Если есть ссылка на что-то до Multiuser — интересно посмотреть, возможно я пропустил.
Волна миграций — имелась в виду не Horizon конкретно, а общий эффект от реструктуризации VMware под Broadcom: пересмотр лицензий vSphere, vSAN, изменение партнёрской программы. Часть клиентов в этой ситуации пересматривает стек целиком. Но да, формулировка в статье это не уточняла и читалась как «все бегут с Horizon». Переписал точнее.
Трансформация после Broadcom — согласен, подписка была ещё до Broadcom. Реальное событие — продажа в KKR и выделение. Исправил.
Nutanix Frame — мой промах, Frame ушёл к Dizzion ещё в 2023-м. Поправил на Dizzion Frame с пометкой.
Политики печати в Horizon — принимаю. Integrated Printing, GPO-фильтрация принтеров — Horizon это умеет, и давно. Переформулировал: разрыв сократился, но по глубине управления виртуальными каналами Citrix пока плотнее. Без «ещё не добрались».
Hypervisor agnosticism — тоже верно, Omnissa поддерживает AHV, Hyper-V и manual pools. Дополнил, убрал привязку к Broadcom как единственный контекст.
Спасибо за ссылки — комментарий полезнее некоторых рецензий.
Интересный разворот. Если вопрос не «кто заменит VMware как гипервизор», а «кто определит следующую операционную модель» — Red Hat с KubeVirt выглядит сильнее. Tanzu как ответ действительно получился догоняющим.
Про oVirt уточню: популярен в России не потому что одолел VMware, а потому что бесплатен и доступен после санкций. Red Hat сама его похоронила в пользу OpenShift Virtualization.
По сути мы про одно: VM никуда не денутся на 5–7 лет, но control plane будущего — K8s. Вопрос — кто из заказчиков готов к смене парадигмы сегодня. По моему опыту — единицы. Но баланс сдвинется, и тут ваш аргумент сработает.
Список — личный опыт, не рейтинг и не претензия на полноту. В раздел попали платформы, которые показались мне интересными с архитектурной точки зрения — нестандартный подход, собственный стек, необычная стратегия. Basis и РЕД архитектурно ближе к мейнстриму KVM-платформ, поэтому отдельно не выделял. Это не оценка качества — это фокус статьи.
Про cloud-native — сознательно не включал. Статья про боль миграции с VMware, а это в 95% случаев классические VM-нагрузки. Cozystack и DVP от Флант — интересные проекты, но другая парадигма и другая аудитория. Заслуживают отдельного разбора.
Не кал, но и не замена VMware. Легче OpenStack, неплохо для провайдеров и edge. Но если мерить линейкой из статьи — нет DRS, нет аналога NSX, storage-интеграции минимальные, DR руками, enterprise backup через сторонние костыли. Для своей ниши — нормально. Как альтернатива vSphere для enterprise с тысячами VM — пока нет. Поэтому и не попал в обзор, статья и большая.
Начну с честного признания: часть фактов в статье я писал из чертогов разума, не перепроверяя. В следующий раз буду тщательнее. Ну а далее разберу по пунктам.
Guest Introspection. Принимаю. Формулировка в статье создаёт впечатление, что agentless закрывает все сценарии. На практике Guest Introspection снимает AV storm и централизует сигнатурное сканирование на уровне файловой системы. Но fileless malware, memory-resident и поведенческий анализ — только агент. В 2026-м NGAV без behavior analysis — не защита. Стоило написать точнее.
vVols. Не уследил, спасибо за ссылку. Часть экосистемы хоронит сама VMware — ирония для статьи про то, как тяжело эту экосистему заменить. VAAI остаётся.
NVIDIA vGPU на Proxmox. В моих чертогах памяти была другая картина — проверил, в матрице 19.0 Proxmox есть. Ошибка моя.
Nutanix и железо. Каюсь, формулировка устарела. Nutanix давно продаёт софт, OEM-модель с Dell/HPE/Lenovo — основной канал. Lock-in у Nutanix другого рода — привязка к AOS/Prism как платформе, но не к железу. Про внешние storage (PowerStore, Pure) — тоже принимаю, в таблице стоило отразить.
KubeVirt. Технически вы правы — OpenShift Virtualization через KubeVirt запускает полноценные VM на QEMU/KVM, K8s только как control plane. Но для заказчика, который двадцать лет работал с vSphere, «VM внутри K8s-кластера» — всё равно принципиально другая парадигма. Red Hat ушла не в контейнеры буквально, но ушла от standalone hypervisor. Формулировка в статье упрощает, согласен.
Иридиум и UI. Ребята идут своим путём. Может что-то забыли убрать, может оставили осознанно для первых версий — не мне судить их приоритеты. Скажу что знаю: те кнопки, которые я нажимал, вели куда нужно. Но моё испытание не показатель — нужны другие нагрузки, другие масштабы, другие сценарии. Понятно, что всего enterprise-функционала пока нет и они его пилят. Ваше замечание про ожидания — сильное: если люди видят интерфейс VMware, они ждут поведение VMware, и любое расхождение бьёт больнее. Думаю, ребята из Иридиума увидят этот комментарий — обратная связь ценная.
Вполне приемлемо будет работать, но не на spice. Можно Moonlight попробовать или parsec, или rdp если windows. У nvidia ресурсы честно разделяются и в каждой vGPU есть энкодеры/декодеры.
К сожалению мне не понять конфигурацию вашего кейса и технические подробности. Вы сказали приложения, spice не доставляет приложения. Нужно больше подробностей.
Я ни к чему не подталкиваю. Мои статьи — не про выбор «правильного VDI», а про границы инструментов и устройство протокола. Думаю нужно сначала понять сценарий (офис, видео, 4K, WAN), а уже потом выбирать протокол и архитектуру. SPICE — один из вариантов, хороший в своей нише, но не универсальный ответ на всё.
Все серьёзно, спасибо. По пунктам.
XenApp / XenDesktop — согласен, в статье они стояли в цепочке переименований, а это разные продукты: SBC vs VDI. С XenDesktop 7 начали сходиться на одной платформе, CVAD объединил в 2018-м. Поправил подачу.
ICA / HDX — тут вопрос ракурса. Смена парадигмы — да, фокус сместился от архитектуры вычислений к UX, не спорю. Но ICA-транспорт под капотом остался: порты 1494/2598, виртуальные каналы, ICA RTT как ключевая метрика. HDX — набор технологий, который живёт поверх ICA-сессии. «Надстройка» занижает масштаб, согласен — поменял на «эволюция поверх ICA».
Виртуальные каналы RDP — моя ошибка, до 31 статического + динамические каналы. Протокол поддерживает классы приоритетов, но административное управление ими ограничено по сравнению с ICA/HDX, где приоритизация, QoS и мультистрим настраиваются на уровне платформы.
BCR — да, ограничений хватает, в статье есть оговорка, но можно было акцентировать сильнее. Тема на отдельный разговор.
KVM — AHV и OpenShift Virtualization под капотом оба KVM, так что по семействам гипервизоров Citrix покрывает весь серверный рынок: Hyper-V, VMware, Xen, KVM. Но согласен — в статье формулировка читалась как поддержка vanilla KVM, а это не так. Спасибо за уточнение по AHV — действительно совместная работа команд.
Оптимизация ВКС — верно, в статье акцент на Teams как на самый частый enterprise-сценарий, но картина шире. Cisco, Zoom, Avaya, Vidyo — каждый писал свой VDI-плагин, используя SDK виртуальных каналов. Это работа экосистемы, не одного вендора. Упрощение.
NetScaler — согласен по всем пунктам. В статье была ложная цепочка «бывший ADC, бывший Access Gateway» — это разные истории. NetScaler — ADC-платформа, купленная в 2005. NetScaler Gateway — наследник Access Gateway, но сам NetScaler — нет. Не входил в базовую поставку, GSLB — тем более. Исправил. Про перманентные лицензии — тоже добавил: с LAS perpetual у NetScaler больше не поддерживаются.
LAS — важная деталь, которая в статье отсутствовала. Добавил: с 15 апреля 2026 файловое лицензирование прекращает работать, обязательный переход на облачную активацию через Citrix Cloud. Для air-gapped сред и организаций с требованиями к суверенитету — отдельная история.
TCO — согласен, минное поле. В статье намеренно не считали, а предупредили: кто обещает экономию — либо продаёт, либо не считал.
Тридцать решений? Серьёзно? Я насчитал чуть больше десятка, и то если считать щедро. Если их реально тридцать — был бы благодарен за список, потому что мне правда интересно, кто все эти люди. Подозреваю, что часть из тридцати — это форк форка OpenUDS с другим логотипом и лендингом, но готов удивиться. По функционалу — если кто-то из них реально закрыл то, что в статье описано как отсутствующее, — назовите, посмотрю руками, если выйдет. Ну или скоро ЦИПР, там надеюсь увижу. Но «функционально они очень разные» без конкретики — это как «у нас тоже enterprise», пока не спросишь про политику буфера обмена по типу данных.
Китай — это вообще отдельная вселенная, не стал туда уходить. Но вы правы, наверное Huawei отличился.
Зависимость от обвязки — важный момент, которого в статье не хватало. VDI не в вакууме: гранулярность политик CVAD — это ещё и MS AD с его GPO-машиной. Когда российские решения работают на Linux с FreeIPA или ALD Pro — у них физически нет той же базы для политик. Часть ограничений — не в VDI-платформе, а в инфраструктуре вокруг неё. Добавил.
По поводу ИИ — не буду лукавить, март 2026 на дворе, я без ИИ уже кажется в туалет не хожу. Использовал — когда формулировал мысли, когда выстраивал структуру, когда перепроверял факты (как видите, не всегда успешно). Кое-где он меня подвёл, кое-где я подвёл сам себя — не перепроверив то, в чём был уверен. Не представляю сегодня индустрию без этого инструмента и искренне желаю каждому его применять. Это изобретение уровня электричества и интернета, и прятать его использование — всё равно что в 2005 стесняться, что гуглишь.
Спасибо за детальный разбор с документацией.
Omnissa / Broadcom — вы правы, формулировка «под крылом Broadcom» была некорректной. KKR купил EUC, Omnissa — самостоятельная компания, vSphere for Desktop доступна через Omnissa. Привязка к серверным проблемам Broadcom для EUC не работает — VDI-инфраструктура всегда жила отдельно. На Gitex Africa 2025 я общался с европейскими интеграторами — беспокойство было реальным: неопределённость с партнёрской программой, вопросы к roadmap под KKR, несколько команд реально смотрели альтернативы. Но я из России, на международных мероприятиях бываю пару раз в год — картинка доходит с задержкой. Вы, судя по всему, работаете с этим стеком плотнее и видите ситуацию актуальнее. Переформулировал: не «волна миграций», а подвижность рынка на фоне неопределённости переходного периода.
По Blast и политикам — функционал есть у обоих, не спорю. Приоритизация каналов, BEAT, Smart Policies, Virtual Channel Allow List — всё документировано. Но нюансы остаются. Virtual Channel Allow List: вы сами привели KB84156 — «By default this value is set to 0 so the feature is disabled meaning all channels are allowed to open». У Citrix эта функция включена по умолчанию с CVAD 2109 (2021) — все сторонние каналы закрыты из коробки. Дефолтная позиция противоположная: у Citrix нужно открыть, у Horizon нужно закрыть. Smart Policies через DEM — работают, но DEM Enterprise Edition нужен для Smart Policies (Horizon Standard/Advanced получают DEM Standard, где Smart Policies нет). И архитектурно: у Citrix Access Policy на Delivery Controller решает до создания сессии — это фаервол на уровне подключения. DEM Smart Policies применяются внутри уже созданной сессии.
Переписал врезку с конкретикой и без категоричных формулировок. Спасибо за ссылки — статья стала точнее.
Спасибо, по делу.
Omnissa / KKR — вы правы, формулировка «под крылом Broadcom» некорректна. Broadcom продал EUC-подразделение в KKR, Omnissa — самостоятельная компания. Поправил.
Волна миграций — имелась в виду не Horizon конкретно, а общий эффект от реструктуризации VMware под Broadcom: пересмотр лицензий vSphere, vSAN, изменение партнёрской программы. Часть клиентов в этой ситуации пересматривает стек целиком. Но да, формулировка в статье это не уточняла и читалась как «все бегут с Horizon». Переписал точнее.
Трансформация после Broadcom — согласен, подписка была ещё до Broadcom. Реальное событие — продажа в KKR и выделение. Исправил.
Nutanix Frame — мой промах, Frame ушёл к Dizzion ещё в 2023-м. Поправил на Dizzion Frame с пометкой.
Политики печати в Horizon — принимаю. Integrated Printing, GPO-фильтрация принтеров — Horizon это умеет, и давно. Переформулировал: разрыв сократился, но по глубине управления виртуальными каналами Citrix пока плотнее. Без «ещё не добрались».
Hypervisor agnosticism — тоже верно, Omnissa поддерживает AHV, Hyper-V и manual pools. Дополнил, убрал привязку к Broadcom как единственный контекст.
Спасибо за ссылки — комментарий полезнее некоторых рецензий.
На вкус и цвет все фломастеры разные
Спасибо
Интересный разворот. Если вопрос не «кто заменит VMware как гипервизор», а «кто определит следующую операционную модель» — Red Hat с KubeVirt выглядит сильнее. Tanzu как ответ действительно получился догоняющим.
Про oVirt уточню: популярен в России не потому что одолел VMware, а потому что бесплатен и доступен после санкций. Red Hat сама его похоронила в пользу OpenShift Virtualization.
По сути мы про одно: VM никуда не денутся на 5–7 лет, но control plane будущего — K8s. Вопрос — кто из заказчиков готов к смене парадигмы сегодня. По моему опыту — единицы. Но баланс сдвинется, и тут ваш аргумент сработает.
Список — личный опыт, не рейтинг и не претензия на полноту. В раздел попали платформы, которые показались мне интересными с архитектурной точки зрения — нестандартный подход, собственный стек, необычная стратегия. Basis и РЕД архитектурно ближе к мейнстриму KVM-платформ, поэтому отдельно не выделял. Это не оценка качества — это фокус статьи.
Про cloud-native — сознательно не включал. Статья про боль миграции с VMware, а это в 95% случаев классические VM-нагрузки. Cozystack и DVP от Флант — интересные проекты, но другая парадигма и другая аудитория. Заслуживают отдельного разбора.
не работал с ним лично и экспертизы не имею
Не кал, но и не замена VMware. Легче OpenStack, неплохо для провайдеров и edge. Но если мерить линейкой из статьи — нет DRS, нет аналога NSX, storage-интеграции минимальные, DR руками, enterprise backup через сторонние костыли. Для своей ниши — нормально. Как альтернатива vSphere для enterprise с тысячами VM — пока нет. Поэтому и не попал в обзор, статья и большая.
В долгосрочной перспективе K8s съест значительную часть, это правда. Но это не два года и не пять. Улыбнуло, спасибо за экспертное мнение.
Спасибо. Внес изменения
Начну с честного признания: часть фактов в статье я писал из чертогов разума, не перепроверяя. В следующий раз буду тщательнее. Ну а далее разберу по пунктам.
Guest Introspection. Принимаю. Формулировка в статье создаёт впечатление, что agentless закрывает все сценарии. На практике Guest Introspection снимает AV storm и централизует сигнатурное сканирование на уровне файловой системы. Но fileless malware, memory-resident и поведенческий анализ — только агент. В 2026-м NGAV без behavior analysis — не защита. Стоило написать точнее.
vVols. Не уследил, спасибо за ссылку. Часть экосистемы хоронит сама VMware — ирония для статьи про то, как тяжело эту экосистему заменить. VAAI остаётся.
NVIDIA vGPU на Proxmox. В моих чертогах памяти была другая картина — проверил, в матрице 19.0 Proxmox есть. Ошибка моя.
Nutanix и железо. Каюсь, формулировка устарела. Nutanix давно продаёт софт, OEM-модель с Dell/HPE/Lenovo — основной канал. Lock-in у Nutanix другого рода — привязка к AOS/Prism как платформе, но не к железу. Про внешние storage (PowerStore, Pure) — тоже принимаю, в таблице стоило отразить.
KubeVirt. Технически вы правы — OpenShift Virtualization через KubeVirt запускает полноценные VM на QEMU/KVM, K8s только как control plane. Но для заказчика, который двадцать лет работал с vSphere, «VM внутри K8s-кластера» — всё равно принципиально другая парадигма. Red Hat ушла не в контейнеры буквально, но ушла от standalone hypervisor. Формулировка в статье упрощает, согласен.
Иридиум и UI. Ребята идут своим путём. Может что-то забыли убрать, может оставили осознанно для первых версий — не мне судить их приоритеты. Скажу что знаю: те кнопки, которые я нажимал, вели куда нужно. Но моё испытание не показатель — нужны другие нагрузки, другие масштабы, другие сценарии. Понятно, что всего enterprise-функционала пока нет и они его пилят. Ваше замечание про ожидания — сильное: если люди видят интерфейс VMware, они ждут поведение VMware, и любое расхождение бьёт больнее. Думаю, ребята из Иридиума увидят этот комментарий — обратная связь ценная.
Спасибо за качественный разбор!
HPE VME вышел в GA только в начале 2025-го, продукт молодой.
такой рынок)
Spice может использовать ресурсы vGPU не сможет.
Вполне приемлемо будет работать, но не на spice. Можно Moonlight попробовать или parsec, или rdp если windows. У nvidia ресурсы честно разделяются и в каждой vGPU есть энкодеры/декодеры.
К сожалению мне не понять конфигурацию вашего кейса и технические подробности. Вы сказали приложения, spice не доставляет приложения. Нужно больше подробностей.
Тогда изложите подробности. Не совсем понимаю, что вы имеете ввиду.
Я ни к чему не подталкиваю. Мои статьи — не про выбор «правильного VDI», а про границы инструментов и устройство протокола.
Думаю нужно сначала понять сценарий (офис, видео, 4K, WAN), а уже потом выбирать протокол и архитектуру. SPICE — один из вариантов, хороший в своей нише, но не универсальный ответ на всё.