Виртуализация *

Продакшен, производственная среда или...

Подскажите, пожалуйста, какой термин вам понятнее:

• продакшен,

• "боевой" сервер,

• производственная среда,

• производственное окружение,

• промышленная среда,

• промышленное окружение,

• live сервер,

• prod,

• production,

• PROD.

Нужно для будущей книги. Хочу написать так, чтобы читатели потом поняли, что я имею в виду.

«Почта Банк» перевел критическую инфраструктуру на zVirt

«Почта Банк» заместил решение вендора VMware, мигрировав ИТ-инфраструктуру, в том числе критический контур, на платформу zVirt. Решение Orion soft обеспечило компании быструю миграцию более 2000 виртуальных машин.

«Почта Банк» — один из крупнейших банков России с государственным участием. Компания ответственно выполняет поручения регуляторов, связанные с импортозамещением ПО для ИТ-инфраструктуры, в том числе КИИ. Для проекта по импортозамещению виртуализации специалисты банка разработали чек-лист из более чем 20 критериев, которым должно было соответствовать российское решение.

Наиболее критичным для «Почта Банка» было наличие функциональности для гибкого управления ресурсами кластера, аварийного перезапуска виртуальных машин, кластеризации, управления доменами хранения. 

Помимо этого банку было важно наличие функциональности для резервного копирования и восстановления виртуальных машин, а также возможность интеграции механизмов бэкапа с используемой в компании СРК. Также специалисты компании оценили zVirt  с точки зрения удобства администрирования.

На сегодняшний день внедрение zVirt  в «Почта Банке» завершено. Общий объем инсталляции достигает 80 хостов, идет активное тиражирование решения. Решение от Orion soft является единственным решением по виртуализации в критическом контуре компании.

«Среди функциональности zVirt особенно актуальным для нас оказался мигратор с VMware. В нашем случае речь идет о тысячах виртуальных машин, и на механическую работу по их пересозданию мы потратили бы слишком много ресурсов. Кроме того, у нас были достаточно жесткие требования к техподдержке, к наличию SLA. Коллеги из Orion soft оправдали наши ожидания — они оперативно подключаются к задачам и помогают решать даже те вопросы, которые находятся на стыке виртуализации и других систем», — комментирует Михаил Комстачев, директор по инфраструктуре и поддержке ИТ-сервисов «Почта Банка».

«Клей» для GPIO в QEMU

В прошлой статье мы пришли к выводу, что QMP — это лучше, чем ничего. Но хочется большего — библиотеку или программу (желательно, уже готовую), которая умеет читать/писать и узнавать об изменении состояния через poll() / pselect() / select() / epoll() / read(). 

В таком случае для каждой модели GPIO нужен «клей», похожий на тот, что используется с chardev — мы включаем его прямо в модифицированный QEMU. Очевидное название такого «клея» — gpiodev. Вот его основные функции, которые сейчас почти полностью соответствуют GPIO UAPI в Linux:

• сообщать количество линий, конфигурацию, название и потребителя каждой линии,

• читать и задавать состояние линии,

• отслеживать изменения состояния и конфигурации линии (вход/выход, запрос/освобождение).

«Клей» состоит из двух групп, первая — это индивидуальные для каждого модуля GPIO функции, которые gpiodev использует, чтобы запросить специфическую информацию:

• LineInfoHandler() — информация о линии: имя, флаги и потребитель,

• LineGetValueHandler() — состояние линии: условный 0 или 1,

• LineSetValueHandler() — задать состояние линии: 0 или 1.

По аналогии с GPIO UAPI напрашиваются также функции LineGetMultiValueHandler() и LineSetMultiValueHandler() для запроса и выставления линий, но я решил ограничиться минимальным набором.

Можно ли организовать прозрачное взаимодействие с устройствами внутри QEMU — использовать те же библиотеки и инструменты, как и для реальных устройств? Читайте во второй части трилогии о долгом пути до GPIO в QEMU.

Как создать простейшую модель GPIO для QEMU

Предлагаю два варианта, которые я условно решил назвать MMIO и PCI. Последний — тоже MMIO, но в QEMU они добавляются разными путями. Начнем с сердца любой MMIO-модели — апертуры.

Апертура и адресное пространство

Как я упоминал в одной из своих статей, любое MMIO-устройство — это MemoryRegion с заданными шириной доступа и размером. Для того, чтобы он был виден CPU или другому устройству, такому как DMA, его нужно разместить в соответствующем адресном пространстве — например, пространстве, назначенном для cpu0:

      0x0                                    0xffffffffffffffff
      |------|------|------|------|------|------|------|------|
0:    [                    address-space: cpu-memory-0        ]
0:    [                    address-space: memory              ]
                    0x102000           0x1023ff
0:                  [             gpio        ]

В любое время можно посмотреть существующие адресные пространства и регионы памяти в мониторе QEMU:

(qemu) info mtree
[...]
address-space: cpu-memory-0
address-space: memory
  0000000000000000-ffffffffffffffff (prio 0, i/o): system
    0000000000102000-00000000001023ff (prio 0, i/o): gpio
[...]

Тогда в модели устройства нам нужно всего лишь создать такой регион и назначить ему соответствующие функции записи и чтения:

static const MemoryRegionOps mmio_mmio_ops = {
    .read = mmio_gpio_register_read_memory,
    .write = mmio_gpio_register_write_memory,
    .endianness = DEVICE_NATIVE_ENDIAN,
    .valid = {
        .min_access_size = 4,
        .max_access_size = 4,
    },
};
 
[...]
memory_region_init_io(iomem, obj, &mmio_mmio_ops, s,
                      "gpio", APERTURE_SIZE);
[...]

Фактически это означает, что все семейство инструкций Load/Store будет вызывать mmio_gpio_register_read_memory()/mmio_gpio_register_write_memory() при совпадении адреса чтения/записи с адресом региона в адресном пространстве.

static uint64_t mmio_gpio_register_read_memory(void *opaque, hwaddr addr, unsigned size);
static void mmio_gpio_register_write_memory(void *opaque, hwaddr addr, uint64_t value, unsigned size);

Передаваемые аргументы и возвращаемое значения интуитивно понятны. Отмечу, что hwaddr addr — это адрес относительно начала нашего региона, а не абсолютный адрес.

Нам остается лишь создать устройство и добавить его регион в файле машины:

gpio = qdev_new(TYPE_MMIO_GPIO);
sysbus_mmio_map(SYS_BUS_DEVICE(gpio), 0, ADDRESS);

Почти десять лет назад Никита Шубин, ведущий инженер по разработке СнК в YADRO, сделал возможность чтения и записи GPIO для QEMU. Читайте первую часть трилогии о долгом пути до GPIO в QEMU.

Начинаю собирать домашнюю "лабу". И моя небольшая история

Я расту, и с ростом меня растут мои аппетиты. Занимаюсь программированием я класса с.. 8? Где-то так, но у меня не было возможности устроить себе рабочее место. Моим рабочим местом долгое время был небольшой ноутбук на селероне с 4 гб оперативной памяти. На нём я и простенькие сайты умудрялся делать, и в SA:MP играл (кто-то помнит?), и делал даже сервер для CR:MP.

Появился в сознательном возрасте компьютер у меня позже, но он тоже был не мощный. Не очень новый процессор, видеокарта только встроенная в процессор, один монитор. Но я пытался выжимать максимум, на нём я начал изучать Питон, тыкал Шарпы. Сейчас я окончательно закрепил себя у себя в сознании как Python Backend Web-developer.

Дальше, уже в другой квартире даже, появилась возможность собрать компьютер получше. Ryzen 7 3700X, 32 Гб ОЗУ (которые появились даже позже, изначально сидел на 12), RTX 3060.

Когда я уже начал получать свои первые деньги, я купил себе второй монитор, потому что понял, с одним мне работать тяжело. И правда: бывает нужен и браузер, и IDE, а я скакал то одно открывал, сворачивал, другое открывал, иногда делил свой 24-дюймовый экран пополам, и это было жутко некомфортно.

Примерно в то же время, даже немного раньше, чем второй монитор, я взял себе у знакомого старый Synology NAS, за недорого относительно цен на них на новые.

Купил в него диск на 4 Тб, так чтоб надолго. Пользуюсь =)

Это только начало ведь. Я расту, аппетиты растут.

По работе набирался опыта работы с железками. Видел коммутаторы, впервые смотрел как вживую настраивается Микротик (одно дело в PNET тыкнуть на роутер и вот тебе консоль, другое - настраивать реальное устройство). Что самое интересное - я узнал про Proxmox.

Не то что бы я раньше не знал про виртуализацию. Виртуалки конечно запускал, и линукс на них, но только изнутри Винды в VirtualBox или VMWare. А тут - проксмокс!

Буквально на днях решил протестировать, что же это такое. Помните ноутбук на селероне с 4 Гб оперативки, про который шла речь выше? Так вот, я взял его, старичка, накатил проксмокс по гайду с Хабра, даже виртуалочку одну на убунту всё таки создал. Более того, даже приложение по работе, которое я разрабатываю, развернул. Правда, больше ничего я не разверну - оно уже всё вместе кушает 3.28Гб ОЗУ из 4х. Но я хочу больше...

То, что будет скоро, буквально до 30 июня максимум: мой первый МиниПК. Характеристики такие: N100, 16 Gb RAM, 1Tb SSD. Беру его как раз для виртуалок. Тестовое окружение для того, чтобы деплоить и тестировать свои приложения а-ля как будто на реальном сервере, плюс отдельные виртуалки под разные сервисы, какие - посмотрим. Возможно, первым сервисом, который я поставлю, будет Plex (или его аналог). И сразу же поставлю Gitea, которая сейчас работает с моего компьютера.

И то, что будет раньше 30 июня, совсем скоро - локальная сеть быстрее 100 мбит. Я пока что взял один коммутатор с 5 портами по 2.5 гбит, надо будет подумать, между кем делить трафик на коммутаторе. Может, буду с МиниПК как раз раздавать фильмы/сериалы, и поведу быструю локалку на телевизоры - к одному на кухне, к другому в зале. Тут есть проблема - я не знаю как это сделать красиво. Сейчас телики работают по вайфаю. Как вести провод - придумаем.

P.S. Если бы тут можно было вставить больше одной фотографии - я бы вставил, но увы.

В развитие темы Bare Metal VM, над которой я время от времени размышляю начиная аж с 2010 года, предлагаю ознакомиться с интересным и, на мой взгляд, перспективным проектом OSv.

Ещё в 10-м году я подумывал над тем, что имея сервера приложений наподобие Томката и серьёзную взрослую изоляцию на уровне загрузчика классов - можно выкинуть подлежащую ОС со всеми её ненужными сервисами из нашего стека, оставив сервер приложений на голом железе. Тогда же выяснилось, что не я один так думаю, было коммерческое предложение Oracle JRockitVE. Судя по всему, наследница вот этого приобретения Bea.

Ранее я уже писал статью об этой идее на Хабре и пытался защищать в дискуссии.

Можно попробовать снова.

Ещё можно смотреть на развитие ОС на базе грааля. Или вспомнить про JaOS.

К современным ОС типа Линукса у меня есть много претензий, и есть несколько идей, которые можно было бы реализовать для их улучшения. Некоторые из них описаны в указанном проекте. Некоторые в том или ином виде наличествуют в специализированных коммерческих предложениях (Юникс) крупных вендоров типа АйбиЭм или того же Оракла. Это касается, например,

• файлово-дискового стека,

• оптимизации сети,

• использования ГПУ в неожиданных местах,

• гибкости в использовании СУБД при разработке с контейнером.

22 мая Андрей Квапил (a.k.a. kvaps) проведет вебинар на YouTube-канале CNCF и расскажет о том, как быстро и просто деплоить виртуальные машины и Kubernetes-кластеры и пробрасывать в них GPU с помощью Open Source-платформы Cozystack.

Зарегистрироваться можно по ссылке: https://tinyurl.com/yf9jcfst. Просто кликните по кнопке «Login to RSVP», чтобы получить приглашение в календаре.

Вебинар ISPsystem: «VMmanager – мощное решение для автоматизации бизнеса»

Приглашаем вас на вебинар компании ISPsystem (входит в «Группа Астра»)!

На вебинаре вы узнаете про VMmanager – масштабируемую on-premise платформу серверной виртуализации. Продукт позволяет виртуализировать все основные составляющие современной инфраструктуры: виртуальные машины и контейнеры, виртуальные сети. При этом является коробочным решением, прост в установке и эксплуатации.

В рамках вебинара будет проведена демонстрация работы платформы. Ждем вас!

→ Дата и время: 13 мая 2025, с 10:30 (мск).

→ Спикер: Станислав Южанин, пресейл-инженер компании ISPsystem.

→ Зарегистрироваться

ISPsystem — российский разработчик платформ для комплексного управления ИТ-инфраструктурой. С 2004 года мы создаем софт для управления оборудованием, серверной виртуализацией, автоматизации учета и выдачи ресурсов.

Павел Гуральник рассказал о ситуации на рынке виртуализации в эфире AM Live

Рынок виртуализации стремительно меняется, и сегодня как никогда важно понимать, какие тренды задают тон, какие стратегии работают, а где остаются вызовы. Что на самом деле произошло в отрасли за последние годы? Какие задачи по развитию виртуальной инфраструктуры компании решают успешно, а над чем еще предстоит работать?

Павел Гуральник, генеральный директор ISPsystem, побывал в гостях у AM Live и в прямом эфире ответил на вопросы, которые сейчас актуальны для всех отраслей бизнеса. Публикуем его ответы в кратком формате.

— Какая система виртуализации используется в вашей компании и есть ли у вас спецусловия для отдельных отраслей?

— Мы используем собственное решение VMmanager. Что касается отраслей, то у всех компаний разные требования, например, к виртуализации или безопасности. Видя, что каждая отрасль требует своего подхода, мы предлагаем соответствующие редакции продуктов. ISPsystem адаптирует свои продукты под нужды каждого заказчика, включая ценообразование и лицензирование.

— Выделяете ли вы такие направления, как медицина или образование?

— Да, конечно! В «Группе Астра» образование идет отдельным треком, особенно школы: это стратегическое направление для подготовки кадров. Медицина тоже выделяется отдельно особыми условиями по продуктам.

— Чем вендорские решения лучше open source?

— Open source дает гибкость и независимость — это плюс. Можно быстро запуститься, если нет жестких требований к безопасности. Но есть и минусы. Например, нужны свои специалисты, чтобы поддерживать систему. Также проект может внезапно перестать развиваться, и тогда придется снова искать решение. Кроме того, всегда сложнее с гарантиями и долгосрочной поддержкой.

Вендорские решения — это стабильность, доработки под конкретные задачи и уверенность в том, что продукт будет развиваться.

— Что делать, если open-source-проект закроется?

— Либо вкладываться в свои компетенции и развивать его самостоятельно (что дорого и сложно), либо переходить на вендорский продукт. Мы, например, сами дорабатываем open-source-решения, чтобы они отвечали современным требованиям.

— Какие у вас есть примеры крупных внедрений?

— Один из рекордов — 700 хостов в одном кластере у заказчика. Еще есть кейс с 65 тысячами виртуальных машин, распределенных географически, но с единым управлением.

— Как выбрать подходящую систему виртуализации?

— Советуем смотреть на три вещи:

• Реальные кейсы — у вендора должны быть примеры внедрений в вашей отрасли.

• Тестирование — важно попробовать продукт в своих условиях, а не в идеальной среде.

• Экосистема — как решение работает с другим ПО, которое вы используете.

— Можно ли протестировать ваш продукт без долгих согласований?

— Да, у нас есть пробная версия, которую можно скачать и использовать месяц без регистрации. Сертифицированные редакции (например, для госсектора) требуют оформления и, соответственно, ввода хотя бы минимальных данных.

— Как устроена ваша техподдержка?

— Мы работаем и напрямую с заказчиками, и через партнеров. Поддержка — это не только «починить сломанное», но и канал для обратной связи. Если у клиента появляются новые потребности, мы дорабатываем продукт.

— Какие у вас модели лицензирования?

— У нас разные модели: подписки для облачных провайдеров и бессрочные лицензии для госсектора. Сейчас мы перешли на лицензирование по сокетам, хотя изначально работали по ядрам.

— От чего зависит стоимость?

— От редакции продукта, масштаба внедрения и дополнительных модулей. Например, решения для медицины или госсектора могут иметь особые условия.

Посмотреть видео целиком можно на Rutube.

Вебинар: как устроена совместная работа виртуальных машин и контейнеров в Deckhouse

Завтра, 23 апреля, мы проведём вебинар о виртуализации в экосистеме Deckhouse. Расскажем, почему разрабатываем своё решение, и покажем, как запускать виртуальные машины рядом с контейнерами, чтобы управлять ими в рамках одной платформы оркестрации. 

Будет полезно, если вы ищете альтернативу классической виртуализации или хотите начать использовать Kubernetes для оркестрации ВМ. Регистрируйтесь и подключайтесь с 12:00 по Москве. Ссылка для подключения придёт вам на почту. 

Вы узнаете:

• Какие возможности по управлению ВМ уже есть в Deckhouse.

• Что мы вкладываем в понятие Cloud Native-виртуализации.

• Для чего может быть нужна совместная работа ВМ и контейнеров.

На демо покажем возможности Deckhouse Kubernetes Platform по администрированию и мониторингу ВМ и контейнеров, конфигурации балансировщиков и микросегментации на основе сетевых политик.

Спикеры вебинара:

• Георгий Дауман, менеджер продукта Deckhouse Virtualization Platform

• Кирилл Салеев, архитектор инфраструктурных решений Deckhouse

На гребне технологий: первые результаты партнерского тестирования zVirt 4.3

На митапе эксперты К2Тех расскажут, как будет работать новая версия zVirt на практике, чем она будет полезна, и поделятся результатами сравнения функционала продукта с другими отечественными решениями по виртуализации.

📅 8 апреля в 16:00

💻 формат: онлайн

✅ регистрация: по ссылке

В новую версию платформы войдет более 30 улучшений, и вот некоторые из них:

— Кластер доменов хранения (балансировка нагрузки)

— Управление репликацией на уровне СХД Yadro Tatlin Unified и Huawei Dorado

— Возможность обеспечить катастрофоустойчивость с использованием механизмов репликации средствами СХД Yadro Tatlin Unified и Huawei Dorado

— Переход на отечественное ядро 6.1, поддерживаемое технологическим центром и многое другое.

📋 В программе митапа:

• Тренды российского рынка и ожидания бизнеса от решений по виртуализации

• Обзор нового функционала zVirt 4.3 и результаты тестирования

• Оценка качества обновлений продукта и их применимости в реальных бизнес-кейсах

• Рекомендации по пилотированию и внедрению новой версии zVirt

👨‍💻 Спикеры:

— Александр Еремин, руководитель практики серверной виртуализации К2Тех

— Дмитрий Ширяев, эксперт по решениям серверной виртуализации К2Тех

✅ Регистрируйтесь, чтобы узнать независимую оценку функций, впервые появившихся в решении отечественного вендора.

Внимание, админы! Broadcom опять закручивает гайки и вводит штрафы задним числом для подписчиков VMware.

Orion soft обновляет виртуализацию zVirt: Storage DRS, репликация на уровне СХД YADRO и Huawei, ядро ИСП РАН и другие новые функции

31 марта мы выпустим крупное обновление нашей защищенной платформы виртуализации zVirt.

Версия 4.3 включает инструмент для объединения нескольких доменов хранения в логический кластер (Storage DRS), управление репликацией на уровне СХД YADRO и Huawei, управление сертификатами через интерфейс, отечественное ядро ИСП РАН, Terraform-провайдер и еще 30 улучшений.

Приглашаем 1 апреля в 11:00 по Мск на вебинар о новом релизе, на котором расскажем подробнее о главных нововведениях и поделимся планами на развитие продукта.

Регистрация открыта по ссылке.

🦾Простой нам только снился!

Так звучит девиз современного бизнеса, ведь проблемы с бесперебойностью инфраструктуры чреваты потерей репутации, клиентов и прибыли.

Благодаря поддержке создания HA-кластеров платформа VMmanager позволяет построить безопасную и отказоустойчивую виртуальную среду. Даже если по какой-то причине сбой все же произошёл, ни один процесс не пострадает.

Всего несколько секунд и все данные будут мигрированы с мощностей, которые временно вышли из строя, на рабочие ресурсы без потери производительности. 😏

Рассказали подробнее, как работают HA-кластеры в VMmanager в нашем новом видео.

Обойдемся и без Terraform: внедряем GitOps-подход для виртуальных машин

Для работы с OpenStack удобно использовать Terraform. Хотя компания Hashicorp прекратила свою деятельность на территории России, нам все еще доступен open source-форк под говорящим названием OpenTofu. Он позволяет автоматизировать создание виртуальных машин на основе текстовых файлов конфигурации. Схема его работы примерно такая:

1. В GitOps-репозитории находятся terraform-файлы с описанием параметров виртуальных машин и DNS.

2. На основе этих файлов формируются конфигурации для новых ВМ.

3. Все изменения вносятся через pull request, а их корректность проверяется автоматическими запусками тестов в CI.

4. После слияния изменений CI запускает процесс приведения нового желаемого состояния репозитория к действительному.

Этот подход отлично масштабируется, позволяет быстро создавать новые кластеры. Достаточно лишь скопировать все файлы в новые директории и поменять нужные переменные. В итоге с OpenTofu вы сможете описывать инфраструктуру в декларативном формате и автоматически применять изменения.

В своей статье Кирилл Яшин рассказывает, как с нуля реализовать такой подход к виртуальным машинам, используя провайдеры для работы с OpenStack и DNS.

Как и зачем дублировать Intel NTB Gen3 в QEMU

Системным программистам в YADRO нужно было «обмануть» драйвер в Linux: он не должен «знать», что работает в эмуляции. 

Для этого ведущий инженер Никита приступил к созданию виртуального двойника Intel NTB Gen3 в QEMU, документации к которому в открытом доступе нет. Реализованная модель позволяет производить разработку и тестирование протоколов более высокого уровня, а также выполнять их качественное сравнение.

PCIe NTB не позволяет увидеть адресное пространство, которое принадлежит к подключенному по NTB соседнему устройству. Вкратце он работает так:

• перенаправляет трафик PCIe между шинами как мост,

• CPU рассматривает мост как конечное устройство,

• CPU не «видит» все устройства на «другой» стороне, как правило, другая сторона — это другой компьютер.

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

В работе с PCI BAR необходимо обеспечить прозрачное использование Linux-драйвера Intel NTB для оптимального взаимодействия с оборудованием, которое мы эмулируем. Еще одна задача — разработать новые транспорты, которые работают поверх эмуляции: RPMSG, Virtio/Vhost, NTRDMA и другие. Также одна модель помогла найти ошибки в инициализации драйвера.

Никита подробно описывает тернистый путь создания виртуального двойника Intel NTB Gen3 в статье →

https://purrli.com/ - для тех у кого нет кота 🐈 симулятор мурчания с настройками.

Linux под Hyper-V, overhead со знаком минус?

Неоднократно приходилось переходить с Linux на самой машине к той же версии и на той же машине, но развернутой в виртуалке в Windows. И часто замечал, что Linux в Hyper-V работает более “отзывчиво” по части GUI (vscode, chrome, firefox и т.п.). Но это были именно субъективные ощущения, особо не заострял на этом внимание предполагая, что улучшения происходят из-за каких-либо аппаратных интерфейсов, для которых Hyper-V предоставляет стандартные реализации. 

Недавно решил обновить рабочий компьютер, и перед тем как выбрать какая ОСь будет основной, провел небольшой тест на сколько “тормозней” Linux в Hyperv-V. 

Список оборудования и ПО:

• Ноутбук Acer Aspire 7, Intel(R) Core(TM) i5-10300H CPU @ 2.50GHz, RAM 20.0 GB

• ОС Linux Mint 21.3 Virginia 64-bit, Kernel Linux 5.15.0-130-generic x86_64

• ОС Windows 10 Enterprise LTSC 21H2 (build 19044.5247)

• В качестве теста выбрана сборка проекта OpenWrt.

Сценарий теста:

1. Linux на ноутбуке:

   1. Устанавливаем Linux на ноутбук.

   2. Клонируем OpenWrt и запускаем последовательно команды:

      1. git clone -b openwrt-23.05 https://github.com/openwrt/openwrt.git

      2. cd openwrt/

      3. ./scripts/feeds update -a

      4. ./scripts/feeds install -a

      5. make menuconfig #выбираем Target System (Qualcomm Atheros IPQ807x)

      6. make -j8 download #download отдельной командой, чтобы не зависеть от сети при тесте.

      7. time make -j8

2. Linux в Hyper-V:

   1. Устанавливаем Windows 10 LTSC на ноут. 

   2. Включаем поддержку Hyper-V.

   3. Устанавливаем Linux под Hyper-V.

   4. В настройках виртуалки, установить кол-во CPU равным 8, выделить RAM 8-18 GB.

   5. Далее выполняем те же действия, что и в пп. 1.2.

Вывод time после сборки OpenWrt:

• Linux на ноутбуке:

  • попытка №1

    • real    30m37,765s

  • попытка №2

    • real    29m18,569s

• Linux в Hyper-V:

  • попытка №1

    • real    27m12,136s

  • попытка №2

    • real    27m36,395s

Получается, что Linux в Hyper-V работает немного быстрей? Странно это, и по хорошему нужно проверять еще. Но на данном этапе меня устраивает, что могу две ОСи одновременно использовать и есть уверенность что нет дополнительных проседаний в производительности.

Так же попробовал в виртуалке установить Ubuntu 24.04 и Linux Mint 22 Cinnamon, их время было такое,real  30m59,630s и 30m37,765s соответственно.

Три проверенных метода организовать обмен прерываниями между машинами QEMU c KVM и без

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

Быстрая работа такой связки приятна при разработке/отладке и очень важна при массовом прогоне автотестов в CI. Как оптимизировать обмен прерываниями и какой подход к организации IQI вам подойдет — узнаете из статьи. А еще разберемся c:

• устройством QEMU под капотом,

• реализацией модели и драйвера,

• добавлением прерываний MSI-X,

• результатами замеров.

На бонус: десяток полезных материалов для изучения.