Хабр Курсы для админов
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Администрирование доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 9
теперь Omnissa под крылом Broadcom
Omnissa Horizon - ни разу не под крылом Broadcom. Broadcom продал весь EUC (включая Horizon) в KKR, и там оно называется Omnissa. https://www.omnissa.com/insights/blog/announcing-omnissa-a-new-standalone-software-company/
После приобретения Broadcom многие пересматривают контракты. Это создаёт волну миграций,
Непоятно откуда волна миграции и пересмотра контрактов. vSphere(VVF for Desktop) доступен у Omnissa в контракте на Horizon. Слухов, про массовое изменение условий контрактов (как это происходит у VMware) и цен, что-то не слышно.
Контекст рынка. VMware Horizon после Broadcom прошёл через похожую болезненную трансформацию
А о чем конкретно идет речь? Какая трансформация произошла после Broadcom? Переход на подписку? Так это ещё до Broadcom было.
Nutanix Frame
Nutanix, аналогично, продал Frame. https://www.dizzion.com/post/dizzion-acquires-frame-from-nutanix-to-accelerate-growth-in-daas-market
VMware Horizon продвинулся дальше, но до уровня Citrix — где настраивается не «печать», а конкретный тип принтера с конкретным драйвером для конкретной группы в конкретном сценарии — ещё не добрались.
Да вроде вполне себе настраивается. И давно уже. https://www.carlstalhood.com/horizon-group-policy-and-profiles/ + https://docs.omnissa.com/bundle/Horizon-Remote-Desktop-FeaturesV2309/page/ConfiguringIntegratedPrinting.html
Citrix работает поверх vSphere, Hyper-V, Nutanix AHV, Citrix Hypervisor, KVM. После того как Broadcom пересмотрела ценовую политику VMware — это стало особенно актуальным.
Так и Omnissa поддерживает по мимо vSphere ещё Nutanix AHV, MS Hyper-V. А в случае manual pool, так там вообще где угодно. https://docs.omnissa.com/bundle/Desktops-and-Applications-in-HorizonVmulti/page/CreatingandManagingManualDesktopPools.html
Спасибо, по делу.
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 как единственный контекст.
Спасибо за ссылки — комментарий полезнее некоторых рецензий.
Разрыв с Citrix сократился, но по глубине — раздельное управление каналами по типу данных, зависимость от контекста подключения, deny-by-default на уровне отдельных виртуальных каналов — Citrix пока плотнее.
"Blast uses virtual channels to multiplex multiple data streams at different priorities between server and client. Clearly, time-sensitive data, such as pixel information and audio, is prioritized higher than bulk data, such as print and USB redirection." https://blogs.vmware.com/euc/2016/09/story-of-vmware-blast.html
Transport Switching: Use the right combination of transport based on application and network feedback
Load sharing and Load balancing: Can optionally drive both transports at the same time to balance the load across transports, or pin certain classes of traffic to a particular transport (not covered in this blog).
Visibility to the underlying transport is needed to read the network-related sensors and use the feedback loop from the applications’ sensors to make an intelligent decision on the right combination of the transports to use. This decision can either be policy based or be auto-learned. И т.д. https://blogs.vmware.com/euc/2018/08/blast-extreme-network-intelligent-transport.html
Blast Extreme Adaptive Transport (BEAT) by default (in Horizon 7.1+), which attempts UDP if possible and falls back to TCP if not. Under BEAT, Blast will prefer UDP 8443 (or UDP 22443 internally) with a DTLS encrypted channel for low-latency data, while still using TCP 443/8443 for control and virtual channel traffic https://www.theitvortex.com/whitepaper-a-comparative-study-of-pcoip-and-blast-protocols-for-horizon-view/
зависимость от контекста подключения
When you define a Horizon Smart Policy or environment variable in Dynamic Environment Manager, you can add conditions that must be met for the policyor variable to take effect. For example, you can add a condition that deactivates the client drive redirection feature only if a user connects to the remote desktop from outside your corporate network. https://docs.omnissa.com/bundle/LinuxDesktops-and-Applications-in-HorizonV2303/page/AddingConditionstoHorizonSmartPolicyDefinitionsandEnvironmentVariableDefinitions.html
VMware Horizon Smart Policies with DEM and Horizon Client Properties https://afshinlak.com/vmware/vmware-horizon-smart-policies/ + https://docs.omnissa.com/bundle/DEMAdminGuideV2209/page/ConfigureHorizonSmartPoliciesforUserEnvironmentSettings.html
The location-based printing feature maps printers that are physically near client systems to remote desktops. https://docs.omnissa.com/bundle/Horizon-Remote-Desktop-FeaturesV2406/page/SettingUpLocation-BasedPrinting.html
deny-by-default на уровне отдельных виртуальных каналов
The Virtual Channel Allow List in Horizon Agent enables the use of an allow list that specifies which virtual channels are allowed to be opened in Blast session.
The AllowVirtualChannels registry is located at HKLM\SOFTWARE\Omnissa\Horizon\VirtualChannels
1 (Enable), 0 (Disable) (By default this value is set to 0 so the feature is disabled meaning all channels are allowed to open). https://kb.omnissa.com/s/article/84156
Реструктуризация VMware под Broadcom затронула прежде всего инфраструктурных клиентов (vSphere, vSAN, лицензирование), и часть из них пересматривает стек целиком, включая VDI.
Мне это не понятно. Лицензирование vSphere под VDI/Terminal всегда было отдельным - использовалась vSphere for Desktop. Она и сейчас может использоваться - покупается целиком от Omnissa и с Broadcom даже не надо общаться. https://kb.omnissa.com/s/article/6000381
Технически, инфраструктура под VDI тоже всегда (при более-менее приличном размере VDI) делалась независимой (отдельные vCenter, отдельные кластера, отдельные СХД).
Поэтому даже если у меня проблемы с Broadcom и я не согласен покупать VCF на серверную инфраструктуру и мигрирую куда-то, то как это влияет на то, что я буду мигрировать с Horizon на Citrix? Почему? Зачем?
Реструктуризация VMware под Broadcom и выделение EUC в Omnissa перетряхнули рынок
Как? Почему? Если мы говорим про EUC, а не про серверную инфраструктуру?
Спасибо за детальный разбор с документацией.
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 применяются внутри уже созданной сессии.
Переписал врезку с конкретикой и без категоричных формулировок. Спасибо за ссылки — статья стала точнее.
Хм... Смотрите, я вот про что. Вы пишите, что Horizon догоняет (но не догнал) Citrix технологически. И приводите (на мой взгляд) странные аргументы. Разная ли реализация фичей у Citrix и Horizon? Безусловно. Но
Access Policy на Delivery Controller решает до создания сессии
У Horizon ДО сессии работает Workspace One Access. https://docs.omnissa.com/bundle/workspace-one-access-deployment-with-UEM/page/CreateaConditionalAccessPolicyRule.html После сессии - DEM. А еще есть и NSX Identity Firewall сверху, как "внешний" (по сравнению с гостем) Firewall, прилепленный к ВМ, правила доступа на котором определяются на уровне того, в какой группе AD состоит пользователь, которые залогинился на нее. https://techdocs.broadcom.com/us/en/vmware-cis/nsx/vmware-nsx/4-1/administration-guide/security/identity-firewall.html
Строго ли соответствует реализация у Horizon и Citrix? Нет, конечно. Но почему это плохо и кто сказал, что надо делать именно так, а не иначе?
Smart Policies через DEM — работают, но DEM Enterprise Edition нужен для Smart Policies (Horizon Standard/Advanced получают DEM Standard, где Smart Policies нет)
Это вопрос не имеет смысла в отрыве от обсуждения стоимости лицензий, условий и т.д. А тут вроде это не обсуждается.
Ну и к тому же в неком виде Conditions в Standard есть https://docs.omnissa.com/bundle/DEMAdminGuideV2212/page/DEMStandardEditionandDEMEnterpriseEdition.html
беспокойство было реальным:
Беспокойство насчет Citrix после продаже ее Tibco и рассмотрение альтернатив ему так же ведется. Это нормальный и естественный процесс
Вааще-то первый продукт citrus systems был ещё для DOS ( и есс-но модемов).
Первый коммерческий продукт — Citrix Multiuser — действительно был расширением для OS/2, не для DOS. Но подключаться к нему можно было с DOS-машин через Multiuser Link (RS-232, модемы, ICA-эмуляция терминала). Версия 2.0 в 1992-м уже была совместима с DOS-приложениями, а WinView в 1993-м запускал и DOS, и Windows. Так что DOS в истории Citrix появился рано — но не как первый продукт, а как среда подключения и потом как платформа для приложений.
Если есть ссылка на что-то до Multiuser — интересно посмотреть, возможно я пропустил.
Семен, спасибо за статью, но полно неточностей.
На некоторые уже указали коллеги, наброшу ещё несколько:
XenApp и XenDesktop - это разные продукты :), а не переименование.
ICA --> HDX, не надстройка а функциональное развитие протокола, показывающее смену парадигмы с Independent Computer Architecture на High Definition eXperience
У RDP тоже есть подканалы https://learn.microsoft.com/en-us/windows/win32/termserv/terminal-services-virtual-channels
У BCR есть много ограничений, в том числе и с точки зрения пользовательского опыта
Citrix нельзя взять и поставить на KVM :), для поддержки AHV совместно работали команды CTX и Nutanix.
Оптимизацию для ВКС решений все кроме Microsoft делали самостоятельно и Cisco и Avaya и Vidiya.
NetScaler это не замена Access Gateway :) NetScaler это теперь бренд в котором зашита разная функциональность. И раньше был NetScaler Gateway, который по факту являлся наследником Access Gateway.
NetScaler в поставку не входил, особенно в части GSLB.
NetScaler стал отдельным бизнес юнитом, но точно также продаётся в составе МЕГА подписок. (У него кстати тоже теперь нет перманентных лицензий - всё)
А с середины апреля 2026 все кто пользуется решениями Citrix (и хочет получать обновления своих систем) вынуждены перевести лицензирование на облачный сервис LAS. Естественно это преподносится как забота о любимых заказчиках.
Тему TCO лучше вообще не трогать :), так как её мало кто может посчитать, (или готов предоставить все данные).
Создаётся стойкое ощущение что статья писалась ИИ с последующим переводом :) не везде успешным или пропущенным.
На российском рынке сейчас представлены почти 30 решений и часть из них это 100% зарубежные кальки даже с отсутствующим (или не полным) переводом на русский язык.
И функционально они очень разные, включая те элементы, которые здесь отмечены как отсутствующие в российских решениях.
Для полноты картины ещё стоит упомянуть китайские решение, некоторые из которых это "цельнотянутый" CVAD (всё, включая картинки в документации).
Ну и ключевой момент VDI это инфраструктурное решение, которое очень сильно зависит от обвязки - Службы каталогов, ОС, приложения и СУБД и часть замечаний относится к этой обвязке. В MS AD есть куча политик, которые можно использовать в CVAD а в Линукс службах каталогов с этим всё не так успешно.
Все серьёзно, спасибо. По пунктам.
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 стесняться, что гуглишь.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Citrix: как протокол из 90-х стал частью инфраструктуры, от которой не отказаться