Привет, Хабр! Я — Саша Епихин, CTO платформы zVirt. Из-за того, что она базируется на oVirt, возникает много вопросов, чем же отличается наше решение от Open Source. Например, в oVirt есть задатки SDN, задатки интеграции с Keycloak и интеграция с Gluster. И инженеру, который не пробовал воспользоваться этой функциональностью в oVirt, может показаться, что в zVirt нет ничего нового, и это всего лишь BolgenOS с нескучными обоями. Но на практике все обстоит совершенно иначе.

Я попробую раскрыть тему и расскажу, чем же zVirt отличается от oVirt. У этой статьи будет несколько частей. Сегодня я начну, как полагается, с истории oVirt и с рассказа, почему мы выбрали разработку именно на базе этого решения.

История oVirt

Считается, что oVirt был публично анонсирован в 2011 году как Open Source проект от Red Hat. В начале была попытка привлечь к нему других участников. Был создан Open Virtualization Alliance, в который, помимо Red Hat, входили такие компании, как Cisco, Suse, IBM, Canonical, Intel, и NetApp. 

Так получилось, что все перечисленные выше вскоре вышли из oVirt, и команда Red Hat тянула проект практически в одиночку, так как вклад от сообщества был небольшим. По сути, это был upstream для Red Hat Virtualization (RHV), который раньше назывался Red Hat Enterprise Virtualization (RHEV). 

В 2019 в oVirt внесла свой первый значительный патч компания Oracle. Они приняли решение использовать oVirt в качестве основы для своего продукта виртуализации Oracle Linux Virtualization Manager (OLVM), так как посчитали, что это единственный проект корпоративного уровня с открытым исходным кодом для управления виртуализацией KVM. Также они сразу обозначили свою позицию — не делать форк, а использовать oVirt как есть, с несколькими патчами, которые всем свободно доступны. OLVM постепенно вытеснил их предыдущую платформу виртуализации и с 2021 года является решением по умолчанию для всех клиентов, которые собираются использовать СУБД Oracle в среде виртуализации.

Но на самом деле история oVirt началась еще раньше — с поглощения израильской компании Qumranet в 2008 году. Так Red Hat получили виртуализацию, основанную на KVM, с набором возможностей, похожих на VMware vSphere. Менеджер управления был написан на .NET и работал на Windows Server 2008.

Джим Уайтхёрст, CEO Red Hat, написал об этом в своей книге «Открытая организация. Страсть, приносящая плоды». Там рассказывается, как продвигали продукт, который был на тот момент очень незрелым, и как Red Hat на этом обжегся. Заказчики тогда меняли проект, не дожидаясь зрелости, а продажи переместились на OpenStack как многообещающую технологию, без понимания того, что если бы даже OpenStack когда-нибудь стал стабильным, у него бы все равно никогда не появилась функциональность виртуализации, необходимой заказчикам, такой как высокая доступность и живой ресайзинг. 

В 2022 году, когда oVirt уже достиг зрелости, Red Hat все же решил сфокусироваться на OpenShift и KubeVirt и объявил о планах прекратить развитие oVirt. Еще в 2021 году они перевели разработку на Github, а систему доставки — на Fedora COPR и CentOS CBS, и в ноябре 2022 года объявили, что теперь судьба проекта в руках сообщества. При этом подчеркнули, что перевод RHV в Maintenance Mode с End-of-life в августе 2026 не является End-of-life для oVirt.

Месяцем позже выпустили последний релиз 4.5.4, где была добавлена функциональность от Red Hat. От них шли в основном security-багфиксы и критические правки, улучшающие стабильность, а также сотрудники Red Hat продолжали ревьюить и принимать правки от сообщества. К сожалению, принимались они не быстро, так как делали это сотрудники Red Hat по зову души. Но сейчас роль лидера сообщества подхватила европейская компания Team.blue. Ревью правок стало значительно бодрее. В том числе наших правок и правок от других российских компаний, которые используют oVirt для своих платформ виртуализации.

Пик развития oVirt пришелся на 2015-2018 годы. Именно тогда была реализована вся функциональность классической серверной виртуализации в видении Red Hat. После миграции oVirt собственного хостинга Gerrit на публичный Github мы можем увидеть 85 публичных репозиториев. В сборке COPR 45 репозиториев — это большой многокомпонентный проект. Везде видно, что количество коммитов уменьшилось с конца 2022-го года. Все еще продолжают выходить новые версии, но уже не так часто (4.5.5 и 4.5.6). 

В мае 2024 года Red Hat уже официально завершили участие в проекте, end of life поддержки oVirt назначен на 2026 год. Сообщество тем временем продолжает развивать проект. Сейчас мы помогаем ему выпустить версию 4.5.7. 

Главным бенефициаром ухода Red Hat из проекта стала компания Oracle. Это видно по регулярным вебинарам, где рассказывается, как можно сократить операционные затраты и повысить гибкость, перейдя с VMware vSphere дорогого legacy-решения на решение от Oracle, т. е. на oVirt. 

Oracle до сих пор активно участвует в комьюнити oVirt, дорабатывая продукты на базе oVirt, поддерживая ключевые пакеты, участвуя в конференциях, выпуская багфиксы и в целом внося вклад в кодовую базу. На вебинарах в этом году можно было послушать про интеграции с системой резервного копирования Veeam, с SDS от Linbit и с микросегментацией от Zero Networks. 

Почему мы выбрали oVirt 

Посмотрим на решения, которые могут составить конкуренцию oVirt:

• Red Hat предлагают для виртуализации OpenShift плюс KubeVirt. Но OpenShift — это Kubernetes-платформа, и она не была спроектирована для управления серверной виртуализацией.

• OpenStack и OpenNebula — облачные платформы, которые дают инструментарий для построения облаков, но не решают весь круг вопросов классической серверной виртуализации.

• VMware остается королем виртуализации и в мире, и у нас. Но после поглощения Broadcom заказчиков начали все сильнее напрягать новая модель подписок и рост цен, который иногда сложно предсказать.

• Proxmox VE — отличное Open Source решение, и по функциональности, возможно, оно ближе всех к vSphere, но кластерный стек реализован на corosync c толстым UDP-трафиком, что требует надежной производительной сети с задержками менее 5 миллисекунд (LAN) между хостами. Поэтому на практике трудно найти инсталляции Proxmox VE больше чем на 3-5 хостов.

• Я не нашел успешных историй использования в Enterprise bhyve на FreeBSD, но было бы интересно посмотреть на путь компаний, которые выберут эти технологии.

В итоге oVirt — один из самых полнофункциональных и Enterprise-ready Open Source проектов виртуализации. Это надежное, гибкое и проверенное решение. В 2018 году, когда началась разработка zVirt, на рынке не было другого настолько же зрелого продукта, как oVirt, с поддержкой от такого крупного вендора, как Red Hat. 

Мы не сразу взяли за базу Open Source, но в других вариантах увидели минусы:

• Конечно, всегда есть опция сделать платформу с нуля. Взять KVM, qemu и поверх построить оркестрацию. Хороший путь, но долгий. Понадобится несколько лет, чтобы нарастить функциональность, и еще несколько лет эксплуатации у тысяч заказчиков, чтобы догнать oVirt по готовности к production. 

  Еще один минус собственной разработки — в ограниченности своей базой заказчиков. Собственный продукт тестируется на ней, но приходит компания не с 10, а с 50 хостами, и система падает. В итоге нужно переписывать архитектуру практически с нуля под лучшую масштабируемость, и этот процесс повторяется каждый раз, когда приходит кто-то с более объемной инфраструктурой. Open Source имеет существенно большую выборку, и ошибки в нем исправляются гораздо быстрее. Он дает возможность собрать большинство «шишек» не у конкретного заказчика, а у множества по чуть-чуть, и развивать продукт быстрее.

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

• Можно повторить путь Red Hat с OpenShift и попытаться предложить KubeVirt в качестве платформы виртуализации, но трудно сказать, сколько лет понадобится, чтобы догнать oVirt. И это все равно будет cloud-native виртуализация без всех тех возможностей, которые нужны заказчикам Enterprise-виртуализации, и требующая экспертизы в Kubernetes.

В итоге zVirt начался как форк oVirt из-за того, что Red Hat не планировал многое из того, что требовалось российским заказчикам. Например: управление локальными пользователями из UI (в oVirt было убрано), удобное простое развертывание, офлайн установка в закрытом контуре, поддержка устаревшего железа. Также многие вещи российские заказчики привыкли видеть в UI — как в VMware vSphere. Само собой, локализация на русский язык. 

Сначала процесс шел не быстро и носил скорее проектный характер. Мы перешли к полноценному продуктовому подходу с присущим ему тиражированием в 2021 году. А в 2022 году, когда VMware ушла с рынка, стало очевидно, что то решение было верным. 

После того, как появился запрос на полноценную замену продуктам VMware, мы ускорили развитие собственного продукта.

Для этого команда разработки решила уйти от модели форка и создавать новые возможности zVirt отдельными сервисами, которые живут рядом с oVirt, не вмешиваясь в его работу там, где это не требуется. Если мы правим баги или добавляем функциональность в самом oVirt, то отдаем в сообщество.

Такой подход позволяет одновременно сохранять стабильность oVirt и быстро внедрять новую функциональность в zVirt. Мы не вносим баги в базовую часть ванильного oVirt, что было бы неизбежно при модели форка. И можем быстрее адаптировать новых разработчиков в команде, потому что им не нужно глубоко погружаться в немаленькую кодовую базу oVirt с первого дня. Это позволяет быстрее включать разработчиков в развитие новой функциональности, соответствовать требованиям рынка и увеличивать команду (в 6 раз за 3 года). В 2025 году наша команда разработчиков и инженеров дошла до отметки в 100 человек.

За 3 года мы написали большое количество своего кода. Если сравнить объем с кодом oVirt, то zVirt — это код oVirt + еще 40%.

Стоит добавить, что zVirt основывается не только на oVirt, но и на других Open Source решениях, которые развиваются.

График контрибуторов keycloak

График контрибуторов cockpit

А правильной ли была ставка на oVirt?

В коде oVirt сконцентрирован многолетний опыт компании в развертывании виртуализации как на собственных стендах, так и на стендах многочисленных заказчиков. За 14 лет были собраны все «шишки» от эксплуатации платформы у тысяч организаций по всему миру, в том числе на различных форках и деривативах. Платформу виртуализации забросили совсем не вовремя, в тот момент, когда oVirt уже достиг необходимой зрелости, вобрал в себя лучшие практики эксплуатации и компетенции инженеров Red Hat.

Несвоевременность решения стала очевиднее, когда VMware поглотил Broadcom, который сменил политику компании и решил отказаться от perpetual-модели. В новом взгляде на коммерческое развитие продукта главную роль играет подписочная модель, и компания предпринимает все больше мер, чтобы перетянуть заказчиков на нее. Работа не то чтобы спорится, ведь подписка обходится в 2-3 раза дороже, чем perpetual-лицензии. В попытках создать для заказчиков дополнительную мотивацию VMware vSphere действует все более категорично, прекращая техподдержку для владельцев бессрочных лицензий и блокируя загрузку security-обновлений для них, если у них нет активного support-контракта.

Перспектива серьезного увеличения расходов заставляет заказчиков искать альтернативу VMware. Компании из Латинской Америки, Юго-Восточной Азии, Австралии, с которыми общается моя команда, уже напрямую заявляли, что их не устраивает дороговизна решения, и они собираются мигрировать с него. 

Российским компаниям в этой ситуации приходится еще сложнее, так как все контракты с ними были разорваны еще в 2022 году. Скачать обновления и security-багфиксы, купить пакеты техподдержки официальным способом больше нельзя, а на неофициальные пути компании будут надеяться все меньше из-за пресекающих мер самого вендора. Сейчас любые данные, которые скачиваются с официального сайта, VMware помечает токенами и фиксирует их путь, проводит массовые аудиты продуктов у клиентов, отслеживает подозрительный трафик, связанный с распространением лицензий в слишком большом объеме. Заметив нежелательные действия, вендор может заблокировать всех, через кого прошли лицензии, и остановить работу уже действующих лицензий. Подробнее о всех рисках мы писали в другой нашей статье, но суть одна: доминируя на рынке, VMware начала устанавливать правила, которые не нравятся заказчикам. Если бы Red Hat не ушел, возможно, его проекту достался бы тот кусок пирога, который постепенно теряет VMware.

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

Тем не менее с 2018 года бывший форк oVirt очень далеко ушел от Open Source, который сейчас обеспечивает только стабильный и проверенный фундамент. Поверх него мы постоянно дорабатываем под задачи российских заказчиков ту функциональность, которой нет в oVirt, сами и вместе с другими компаниями. Например, отказоустойчивый SDN с микросегментацией, управление репликацией на уровне СХД (YADRO TATLIN UNIFIED и Huawei Dorado), автоматизация планов восстановления (DR-планы), SDS на базе более стабильного Gluster. Кроме того, мы перешли на отечественное ядро Linux и делаем свою сборку ядра виртуализации.

Подробнее о том, как именно мы все это (и не только) реализовывали, как расставляли приоритеты при доработках и на что сделали ставку в развитии, я расскажу в следующих статьях.