Интересный разворот. Если вопрос не «кто заменит 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 — один из вариантов, хороший в своей нише, но не универсальный ответ на всё.
В VDI нет потоков Linux↔Windows как таковых. Всегда есть «гостевая ОС → протокол → клиент». Так что тип ОС внутри не важен: сжатие выполняется на сервере по содержимому экрана, а не по ОС. Разница появляется только на клиенте — в выборе кодеков под его производительность. Но тоже не существенная
VNC образца 2007 был значительно беднее (без аудио, USB, нормального clipboard). К слову, и сегодня open-source VNC так и не получил аудио — PR в TigerVNC висит с 2023 года, а clipboard в noVNC работает через костыли с тем же spice-vdagent.
Но вы правы насчёт framebuffer'а — разница в том, как он передаётся: SPICE использует адаптивное сжатие и эвристики для детекта видеопотоков, VNC — фиксированные encoding'и (Tight, ZRLE) на весь кадр.
В целом, вы попали в точку: именно поэтому Red Hat сегодня рекомендует VNC для серверов. Когда разница нивелирована — зачем тянуть отдельный протокол? Но это не для VDI а для админов.
Про «забросили» — скорее нет. Это не активная гонка за фичами, а режим поддержки: проект живёт, чинится, используется (тот же Proxmox), просто без резких движений.
На вкус и цвет все фломастеры разные
Спасибо
Интересный разворот. Если вопрос не «кто заменит 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 — один из вариантов, хороший в своей нише, но не универсальный ответ на всё.
В VDI нет потоков Linux↔Windows как таковых. Всегда есть «гостевая ОС → протокол → клиент». Так что тип ОС внутри не важен: сжатие выполняется на сервере по содержимому экрана, а не по ОС. Разница появляется только на клиенте — в выборе кодеков под его производительность. Но тоже не существенная
VNC образца 2007 был значительно беднее (без аудио, USB, нормального clipboard). К слову, и сегодня open-source VNC так и не получил аудио — PR в TigerVNC висит с 2023 года, а clipboard в noVNC работает через костыли с тем же spice-vdagent.
Но вы правы насчёт framebuffer'а — разница в том, как он передаётся: SPICE использует адаптивное сжатие и эвристики для детекта видеопотоков, VNC — фиксированные encoding'и (Tight, ZRLE) на весь кадр.
В целом, вы попали в точку: именно поэтому Red Hat сегодня рекомендует VNC для серверов. Когда разница нивелирована — зачем тянуть отдельный протокол? Но это не для VDI а для админов.
Ну дело в том, что VNC — это remote framebuffer из 1998 года, созданный для совсем других задач.
Про «забросили» — скорее нет. Это не активная гонка за фичами, а режим поддержки: проект живёт, чинится, используется (тот же Proxmox), просто без резких движений.