Недавно сделал заметку про выделение памяти для VM, кратной 512Мб, а так же чётное количество процессоров. Оказывается этому есть вполне осмысленное обоснование и отражено оно в блоге vmware - https://blogs.vmware.com/performance/2017/03/virtual-machine-vcpu-and-vnuma-rightsizing-rules-of-thumb.html
Материал большой и насыщенный. Приведу только конечные выводы по оптимальному распределению RAM и CPU между виртуалками. Там есть нюансы, о которых лично я не знал. Рассматривается в том числе вопрос с сокетами. Части вижу вопросы на тему того, как распределить процессоры и сокеты в VM.
На основе статьи рекомендации будут следующие. Для примера взят хост:
▪ 2 сокета
▪ 10 ядер на сокет
▪ 40 логических процессоров
▪ 256 GB памяти, по 128 GB на сокет
Разбираем сначала виртуалки с количеством памяти меньше 128 GB. В
этом случае мы добавляем 1 сокет и максимум 10 vCPU. Как только процессоров нужно больше, чем есть на одном сокете, дальше мы добавляем только по чётным числам и делим на 2 сокета поровну. То есть должно быть 2 сокета, 6 vCPU на сокет, в сумме 12. Это будет оптимальная конфигурация для 12 vCPU. И так дальше до 20 ядер добавляем, деля их поровну между сокетами. Напоминаю, что это для виртуалок с памятью меньше чем 128 GB.
Если в виртуальную машину надо выделить более 128 GB памяти, арифметика будет другая. Нечётное количество ядер не используем вообще. Сокетов всегда добавляем два. То есть надо виртуалке 2 vCPU и 192 GB памяти. Делаем два сокета, в каждом по ядру и сколько надо памяти, кратно числу ядер.
Я не знаю, актуально ли это для всех систем виртуализации или только для vmware. Специально не узнавал, но подозреваю, что актуально везде, так как исходит из архитектуры самой платформы хоста.
Краткий вывод такой. Если на одну виртуальную машину условно приходится ресурсов не более, чем в рамках одного сокета (vNUMA, cpu + ram), то процессоров ставим любое число, сокет всегда один. Если на vm уходит больше ресурсов одного сокета, то надо делить процессоры равномерно по сокетам. Причем даже если процессоров всего 2, а памяти больше, чем достанется сокету, все равно vCPU разделяем на сокеты.
Такая вот арифметика. Спасибо читателю за ссылку. Сам я не знал таких подробностей и неизвестно когда узнал бы. А тут реклама заказывается, деньги платятся, посты пишутся. Никуда не деться 😁 Приходится учиться.
Заметку имеет смысл сохранить, чтобы потом не вспоминать, как оптимально выделять ресурсы большой vm.
#виртуализация
Материал большой и насыщенный. Приведу только конечные выводы по оптимальному распределению RAM и CPU между виртуалками. Там есть нюансы, о которых лично я не знал. Рассматривается в том числе вопрос с сокетами. Части вижу вопросы на тему того, как распределить процессоры и сокеты в VM.
На основе статьи рекомендации будут следующие. Для примера взят хост:
▪ 2 сокета
▪ 10 ядер на сокет
▪ 40 логических процессоров
▪ 256 GB памяти, по 128 GB на сокет
Разбираем сначала виртуалки с количеством памяти меньше 128 GB. В
этом случае мы добавляем 1 сокет и максимум 10 vCPU. Как только процессоров нужно больше, чем есть на одном сокете, дальше мы добавляем только по чётным числам и делим на 2 сокета поровну. То есть должно быть 2 сокета, 6 vCPU на сокет, в сумме 12. Это будет оптимальная конфигурация для 12 vCPU. И так дальше до 20 ядер добавляем, деля их поровну между сокетами. Напоминаю, что это для виртуалок с памятью меньше чем 128 GB.
Если в виртуальную машину надо выделить более 128 GB памяти, арифметика будет другая. Нечётное количество ядер не используем вообще. Сокетов всегда добавляем два. То есть надо виртуалке 2 vCPU и 192 GB памяти. Делаем два сокета, в каждом по ядру и сколько надо памяти, кратно числу ядер.
Я не знаю, актуально ли это для всех систем виртуализации или только для vmware. Специально не узнавал, но подозреваю, что актуально везде, так как исходит из архитектуры самой платформы хоста.
Краткий вывод такой. Если на одну виртуальную машину условно приходится ресурсов не более, чем в рамках одного сокета (vNUMA, cpu + ram), то процессоров ставим любое число, сокет всегда один. Если на vm уходит больше ресурсов одного сокета, то надо делить процессоры равномерно по сокетам. Причем даже если процессоров всего 2, а памяти больше, чем достанется сокету, все равно vCPU разделяем на сокеты.
Такая вот арифметика. Спасибо читателю за ссылку. Сам я не знал таких подробностей и неизвестно когда узнал бы. А тут реклама заказывается, деньги платятся, посты пишутся. Никуда не деться 😁 Приходится учиться.
Заметку имеет смысл сохранить, чтобы потом не вспоминать, как оптимально выделять ресурсы большой vm.
#виртуализация
Вчерашняя заметка про Proxmox вызвала бурные обсуждения в комментариях на тему использования различных гипервизоров. Звучали мнения, что Proxmox нафиг не нужен, так как есть бесплатный esxi.
Мне лично Proxmox нравится больше всего тем, что его можно установить на софтовый рейд mdadm. Это основное преимущество для меня. Кто-то любит zfs и поэтому использует Proxmox. Esxi, к примеру, вообще не поддерживает софтовые рейды, только железные и то не все. Но лично мне больше нравятся именно софтовые рейды, в частности mdadm. С ним меньше всего хлопот, у него очень предсказуемое и надежное поведение. Никогда не было с ним проблем.
Таким образом, Proxmox можно установить на любой самосбор с двумя дисками и получить вполне надежное решение, особенно если подобных самосборов будет несколько и они объединены в кластер. Удобно, когда и прод и тестовые машины одинаковые, а на тест можно что-то дешманское купить. Я активно эксплуатирую бюджетные двухдисковые сервера от Selectel и ставлю туда Proxmox на mdadm из готового шаблона. Ничего настраивать не надо. Заказал сервер и получил готовый Proxmox на софтовом RAID1.
Кстати, когда XenServer можно было тоже установить на mdadm, я использовал его. Мне очень нравился этот гипервизор за его удобное приложение под Windows для управления виртуалками. Прекратил использовать Xenserver с выходом 7-й версии, когда он перестал нормально устанавливаться и обновляться на mdadm. После этого перешёл на Proxmox. А сейчас с выходом Proxmox Backup Server у него вообще нет бесплатных альтернатив.
Иногда ставлю бесплатный Hyper-V Server, если предполагается использование виндовых серверов. У меня есть ни на чём не основанное мнение, что виндовые сервера лучше запускать на Hyper-V. Да и просто хлопот меньше с драйверами. Все сразу работает и поддерживается.
#виртуализация
Мне лично Proxmox нравится больше всего тем, что его можно установить на софтовый рейд mdadm. Это основное преимущество для меня. Кто-то любит zfs и поэтому использует Proxmox. Esxi, к примеру, вообще не поддерживает софтовые рейды, только железные и то не все. Но лично мне больше нравятся именно софтовые рейды, в частности mdadm. С ним меньше всего хлопот, у него очень предсказуемое и надежное поведение. Никогда не было с ним проблем.
Таким образом, Proxmox можно установить на любой самосбор с двумя дисками и получить вполне надежное решение, особенно если подобных самосборов будет несколько и они объединены в кластер. Удобно, когда и прод и тестовые машины одинаковые, а на тест можно что-то дешманское купить. Я активно эксплуатирую бюджетные двухдисковые сервера от Selectel и ставлю туда Proxmox на mdadm из готового шаблона. Ничего настраивать не надо. Заказал сервер и получил готовый Proxmox на софтовом RAID1.
Кстати, когда XenServer можно было тоже установить на mdadm, я использовал его. Мне очень нравился этот гипервизор за его удобное приложение под Windows для управления виртуалками. Прекратил использовать Xenserver с выходом 7-й версии, когда он перестал нормально устанавливаться и обновляться на mdadm. После этого перешёл на Proxmox. А сейчас с выходом Proxmox Backup Server у него вообще нет бесплатных альтернатив.
Иногда ставлю бесплатный Hyper-V Server, если предполагается использование виндовых серверов. У меня есть ни на чём не основанное мнение, что виндовые сервера лучше запускать на Hyper-V. Да и просто хлопот меньше с драйверами. Все сразу работает и поддерживается.
#виртуализация
У меня на днях спросили, как лучше организовать сеть на гипервизоре с одним внешним ip адресом для работы сайтов на виртуальной машине. Проблема тут очевидна, если адрес только один. Вам надо как-то управлять самим гипервизором и прочие службы сделать доступными по внешнему ip. Вариантов тут 2. Я в равной степени использую оба в зависимости от задач.
1️⃣ Более простой случай, особенно если у вас гипервизор на Linux. Сам гипервизор становится маршрутизатором для виртуальных машин. Настраиваете на нём firewall, nat и проброс нужных портов в виртуальные машины. В этом случае вообще не нужно трогать сетевые настройки на гипервизоре. Достаточно будет добавить один виртуальный интерфейс и подключать его виртуалкам. Через него они будут взаимодействовать с хостом.
Плюс тут очевиден - нет лишних сущностей, быстрая настройка. Есть значительный минус - у вас настройки хранятся на гипервизоре, что неудобно. Лучше, когда вся инфраструктура полностью в виртуалках, которые можно забэкапить и потом восстановить в том же виде на другом гипервизоре и всё сразу заработает. В этом же случае, придётся отдельно настраивать гипервизор.
2️⃣ Шлюзом для гипервизора и виртуальных машин выступает одна из виртуалок. Для подобной настройки на первое время понадобится прямой доступ через ip-kvm к консоли гипервизора, так как велика вероятность потери связи с хостом во время настройки. Когда я часто настраивал подобную схему, получалось всё провернуть быстро без потери связи, если нигде не ошибиться.
Для реализации вы делаете на хосте сетевой bridge, включая туда внешний интерфейс, на который приходит внешний ip. На самом гипервизоре настройки этого ip вообще не делаете. Также добавляете один виртуальный интерфейс.
Создаёте виртуалку, которая будет шлюзом. К ней подключаете бридж и виртуальный интерфейс. На бридже настраиваете внешний ip. На виртуалке какую-то локальную сеть для связи виртуальных машин и гипервизора. Далее настраиваете всё, что нужно обычному шлюзу - firewall, nat, проброс портов. Я обычно здесь же настраиваю vpn и proxy-nginx. По необходимости dhcp и dns.
Далее эту виртуальную машину делаете шлюзом по умолчанию для самого гипервизора и остальных виртуалок, используя адрес из локальной сети, настроенной на виртуальном интерфейсе. Важно не забыть добавить виртуалку со шлюзом в автозагрузку, чтобы после перезагрузки хоста не терять с ним связь.
В итоге у вас все важные настройки инфраструктуры окажутся на виртуальной машине и успешно забэкапятся. Потом всё разом можно настроить в любом другом месте. Достаточно будет только поменять сетевые настройки на новом гипервизоре.
3️⃣ Заказываете дополнительные адреса и не тратите время на сетевые настройки. Но если у вас инфраструктура будет состоять из нескольких гипервизоров и вам захочется их объединить по vpn, то отдельный шлюз все равно пригодится, даже если адресов в избытке.
Если реально заинтересовались второй схемой, то почитайте более подробное описание в статье. Я там прям на конкретном примере с реального гипервизора показываю, как это на практике выглядит.
#виртуализация
1️⃣ Более простой случай, особенно если у вас гипервизор на Linux. Сам гипервизор становится маршрутизатором для виртуальных машин. Настраиваете на нём firewall, nat и проброс нужных портов в виртуальные машины. В этом случае вообще не нужно трогать сетевые настройки на гипервизоре. Достаточно будет добавить один виртуальный интерфейс и подключать его виртуалкам. Через него они будут взаимодействовать с хостом.
Плюс тут очевиден - нет лишних сущностей, быстрая настройка. Есть значительный минус - у вас настройки хранятся на гипервизоре, что неудобно. Лучше, когда вся инфраструктура полностью в виртуалках, которые можно забэкапить и потом восстановить в том же виде на другом гипервизоре и всё сразу заработает. В этом же случае, придётся отдельно настраивать гипервизор.
2️⃣ Шлюзом для гипервизора и виртуальных машин выступает одна из виртуалок. Для подобной настройки на первое время понадобится прямой доступ через ip-kvm к консоли гипервизора, так как велика вероятность потери связи с хостом во время настройки. Когда я часто настраивал подобную схему, получалось всё провернуть быстро без потери связи, если нигде не ошибиться.
Для реализации вы делаете на хосте сетевой bridge, включая туда внешний интерфейс, на который приходит внешний ip. На самом гипервизоре настройки этого ip вообще не делаете. Также добавляете один виртуальный интерфейс.
Создаёте виртуалку, которая будет шлюзом. К ней подключаете бридж и виртуальный интерфейс. На бридже настраиваете внешний ip. На виртуалке какую-то локальную сеть для связи виртуальных машин и гипервизора. Далее настраиваете всё, что нужно обычному шлюзу - firewall, nat, проброс портов. Я обычно здесь же настраиваю vpn и proxy-nginx. По необходимости dhcp и dns.
Далее эту виртуальную машину делаете шлюзом по умолчанию для самого гипервизора и остальных виртуалок, используя адрес из локальной сети, настроенной на виртуальном интерфейсе. Важно не забыть добавить виртуалку со шлюзом в автозагрузку, чтобы после перезагрузки хоста не терять с ним связь.
В итоге у вас все важные настройки инфраструктуры окажутся на виртуальной машине и успешно забэкапятся. Потом всё разом можно настроить в любом другом месте. Достаточно будет только поменять сетевые настройки на новом гипервизоре.
3️⃣ Заказываете дополнительные адреса и не тратите время на сетевые настройки. Но если у вас инфраструктура будет состоять из нескольких гипервизоров и вам захочется их объединить по vpn, то отдельный шлюз все равно пригодится, даже если адресов в избытке.
Если реально заинтересовались второй схемой, то почитайте более подробное описание в статье. Я там прям на конкретном примере с реального гипервизора показываю, как это на практике выглядит.
#виртуализация
На днях в комментариях к заметке о KVM зашла речь об очень интересном продукте для виртуализации - Nutanix Community Edition. Я давно о нём знаю, ещё с 2014 года, когда впервые увидел статью на хабре про неё от одного из разработчиков. Правда в то время ещё не было бесплатной CE версии, поэтому можно было только почитать, но не попробовать. Продукт стоил немалых денег.
Я узнал, что оказывается есть бесплатная Community версия, которую можно поставить у себя и попробовать. Объясню своими словами, что такое Nutanix. Это гиперконвергентное (не понимаю значение этого слова) решение, которое объединяет в себе вычислительные мощности и общее хранилище для построения распределённой системы виртуализации.
На пальцах это выглядит так. Вы берёте 4 сервера под 4 ноды. Разворачиваете на них кластер Nutanix с выбранным фактором репликации. Он объединяет все процессоры, память и диски в единое пространство. И вы в рамках этого кластера создаёте виртуальные машины, не привязываясь к конкретной ноде. Если у вас выходит из строя один из серверов, вам достаточно будет перезапустить виртуальные машины, которые на нём жили, и они будут подняты на оставшихся нодах кластера. Всё управление происходит через единую панель.
На практике установка Nutanix выглядит следующим образом. Вам нужно зарегистрироваться у них на сайте. При этом почтовые ящики публичных сервисов не принимаются (gmail, msn и т.д.), нужно использовать корпоративный. После регистрации получаете ссылки на ISO образы. Их можно установить на железо, либо виртуальные машины других гипервизоров. Далее создаёте кластер или используете в режиме одиночной ноды. Так тоже можно.
Nutanix использует свой гипервизор AHV. Причём этот гипервиpор поддерживает Veeam. Вы можете использовать его для бэкапа кластера Nutanix. Важной особенностью бесплатной версии является то, что она должна иметь доступ через интернет к серверам разработчиков. Если она 30 дней их не видит, то доступ к панели управления блокируется. Виртуальные машины при этом остаются работать. Подобное ограничение не только в современных, но и любых условиях делает использование этой системы очень спорным.
Я как-то раз столкнулся с неприятной ситуацией с XenServer. В версии до 6-й и 7-й в бесплатной версии гипервизора нужно было раз в год продлевать лицензию запросом специального файла. Это было бесплатно. Но в определённый момент Citrix решили, что людей пора согнать со старых версий, и они просто закрыли этот сервис по продлению лицензий. Пришлось срочно мигрировать. С тех пор моё доверие к XenServer сильно упало и я постепенно отказался от него.
Я видел в комментариях отзывы тех, кто использует Nutanix CE в проде. Мне интересно, вам не стрёмно с такими условиями им пользоваться? По функционалу всё выглядит очень круто, причём не только на бумаге, но и на практике. Продукт уже известный и проверенный.
#виртуализация
Я узнал, что оказывается есть бесплатная Community версия, которую можно поставить у себя и попробовать. Объясню своими словами, что такое Nutanix. Это гиперконвергентное (не понимаю значение этого слова) решение, которое объединяет в себе вычислительные мощности и общее хранилище для построения распределённой системы виртуализации.
На пальцах это выглядит так. Вы берёте 4 сервера под 4 ноды. Разворачиваете на них кластер Nutanix с выбранным фактором репликации. Он объединяет все процессоры, память и диски в единое пространство. И вы в рамках этого кластера создаёте виртуальные машины, не привязываясь к конкретной ноде. Если у вас выходит из строя один из серверов, вам достаточно будет перезапустить виртуальные машины, которые на нём жили, и они будут подняты на оставшихся нодах кластера. Всё управление происходит через единую панель.
На практике установка Nutanix выглядит следующим образом. Вам нужно зарегистрироваться у них на сайте. При этом почтовые ящики публичных сервисов не принимаются (gmail, msn и т.д.), нужно использовать корпоративный. После регистрации получаете ссылки на ISO образы. Их можно установить на железо, либо виртуальные машины других гипервизоров. Далее создаёте кластер или используете в режиме одиночной ноды. Так тоже можно.
Nutanix использует свой гипервизор AHV. Причём этот гипервиpор поддерживает Veeam. Вы можете использовать его для бэкапа кластера Nutanix. Важной особенностью бесплатной версии является то, что она должна иметь доступ через интернет к серверам разработчиков. Если она 30 дней их не видит, то доступ к панели управления блокируется. Виртуальные машины при этом остаются работать. Подобное ограничение не только в современных, но и любых условиях делает использование этой системы очень спорным.
Я как-то раз столкнулся с неприятной ситуацией с XenServer. В версии до 6-й и 7-й в бесплатной версии гипервизора нужно было раз в год продлевать лицензию запросом специального файла. Это было бесплатно. Но в определённый момент Citrix решили, что людей пора согнать со старых версий, и они просто закрыли этот сервис по продлению лицензий. Пришлось срочно мигрировать. С тех пор моё доверие к XenServer сильно упало и я постепенно отказался от него.
Я видел в комментариях отзывы тех, кто использует Nutanix CE в проде. Мне интересно, вам не стрёмно с такими условиями им пользоваться? По функционалу всё выглядит очень круто, причём не только на бумаге, но и на практике. Продукт уже известный и проверенный.
#виртуализация
На днях упоминал про систему организации виртуальных рабочих мест Termidesk. Сегодня расскажу о ней подробнее. Это российское программное обеспечение, включённое в реестр отечественного ПО. С его помощью реализуется функционал диспетчера удалённых подключений к виртуальным машинам под управлением операционных систем Linux и Windows.
Termidesk поддерживает следующие системы виртуализации: ПК СВ «Брест», zVirt, VMware, Aerodisk vAir, oVirt, Openstack и некоторые другие. То есть это универсальный продукт под разные системы виртуализации, с которыми он работает через плагины расширения.
В качестве гостевых систем для рабочих мест могут использоваться Windows 7,8,10, Windows Server, Astra Linux, Alt Linux, Debian, Ubuntu, CentOS. Для взаимодействия с Termidesk в операционные системы устанавливается агент.
Подключение к рабочим местам может осуществляться через различные протоколы. Если в системе есть RDP, то можно через него. Также поддерживается протокол SPICE, через который можно подключаться к экрану виртуальной машины. Этот протокол взаимодействия напрямую с гипервизором. Через него в том числе работает проброс usb устройств, работа мультимедиа (usb камер и микрофонов). То есть удалённое рабочее место можно использовать для полноценного общения.
Ещё один вариант подключения - через termidesk viewer. Если я правильно понял, то он использует взаимодействие с установленным агентом. Все эти подключения можно устанавливать как через браузер, так и через клиент, который представляет из себя приложение для операционной системы.
В качестве авторизации поддерживается множество популярных механизмов: локальная БД, MS Active Directory, LDAP/OpenLDAP, FreeIPA, Astra Linux Directory, IP адреса. Устанавливается Termidesk просто. Это обычный deb пакет для бесплатной ОС Astra Linux Common Edition, либо платной Astra Linux Special Edition. После установки из пакета, управление и настройка осуществляются через браузер.
В настоящее время Termidesk предлагает бесплатно лицензию на 4 конкурентных соединения с пользовательских рабочих станций. Получить её можно только вручную, отправив запрос через специальную форму на сайте. Платная версия лицензируется либо по количеству пользователей, либо по количеству одновременных соединений. Стоит от 5000 р. за пользователя, и от 9000 р. за соединение. Это стоимость за год. Цены смотрел в softline.
Посмотреть, как Termidesk работает на практике со стороны пользователя можно с помощью demo - https://termidesk.ru/vdi-demo, учётка termidesk1 / termidesk1. Можно как через браузер заходить, так и клиент себе поствить.
❗️Обращаю внимание, что через demo доступны несколько версий полноценных операционных систем с выходом в интернет. Там есть в том числе и браузеры. Можно использовать их в различных целях. Только не надо заниматься каким-то вредительством. Наверняка все подключения логируются. Если какие-то вредители начнут гадости делать, то демо скорее всего закроют. После завершения сеанса все изменения удаляются. Заново подключается уже эталонный образ.
Сайт - https://termidesk.ru/
Реестр ПО - https://reestr.digital.gov.ru/reestr/306667/
#vdi #отечественное #виртуализация
Termidesk поддерживает следующие системы виртуализации: ПК СВ «Брест», zVirt, VMware, Aerodisk vAir, oVirt, Openstack и некоторые другие. То есть это универсальный продукт под разные системы виртуализации, с которыми он работает через плагины расширения.
В качестве гостевых систем для рабочих мест могут использоваться Windows 7,8,10, Windows Server, Astra Linux, Alt Linux, Debian, Ubuntu, CentOS. Для взаимодействия с Termidesk в операционные системы устанавливается агент.
Подключение к рабочим местам может осуществляться через различные протоколы. Если в системе есть RDP, то можно через него. Также поддерживается протокол SPICE, через который можно подключаться к экрану виртуальной машины. Этот протокол взаимодействия напрямую с гипервизором. Через него в том числе работает проброс usb устройств, работа мультимедиа (usb камер и микрофонов). То есть удалённое рабочее место можно использовать для полноценного общения.
Ещё один вариант подключения - через termidesk viewer. Если я правильно понял, то он использует взаимодействие с установленным агентом. Все эти подключения можно устанавливать как через браузер, так и через клиент, который представляет из себя приложение для операционной системы.
В качестве авторизации поддерживается множество популярных механизмов: локальная БД, MS Active Directory, LDAP/OpenLDAP, FreeIPA, Astra Linux Directory, IP адреса. Устанавливается Termidesk просто. Это обычный deb пакет для бесплатной ОС Astra Linux Common Edition, либо платной Astra Linux Special Edition. После установки из пакета, управление и настройка осуществляются через браузер.
В настоящее время Termidesk предлагает бесплатно лицензию на 4 конкурентных соединения с пользовательских рабочих станций. Получить её можно только вручную, отправив запрос через специальную форму на сайте. Платная версия лицензируется либо по количеству пользователей, либо по количеству одновременных соединений. Стоит от 5000 р. за пользователя, и от 9000 р. за соединение. Это стоимость за год. Цены смотрел в softline.
Посмотреть, как Termidesk работает на практике со стороны пользователя можно с помощью demo - https://termidesk.ru/vdi-demo, учётка termidesk1 / termidesk1. Можно как через браузер заходить, так и клиент себе поствить.
❗️Обращаю внимание, что через demo доступны несколько версий полноценных операционных систем с выходом в интернет. Там есть в том числе и браузеры. Можно использовать их в различных целях. Только не надо заниматься каким-то вредительством. Наверняка все подключения логируются. Если какие-то вредители начнут гадости делать, то демо скорее всего закроют. После завершения сеанса все изменения удаляются. Заново подключается уже эталонный образ.
Сайт - https://termidesk.ru/
Реестр ПО - https://reestr.digital.gov.ru/reestr/306667/
#vdi #отечественное #виртуализация
