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

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

Да, направление здесь немного непривычное: обычно Java запускают в Linux, а здесь я решил попробовать запустить Linux из Java.

Обычно Java и KVM находятся довольно далеко друг от друга: с одной стороны JVM и управляемая память, с другой /dev/kvm, ioctl, регистры vCPU и физическая память guest ОС. В этой статье разберём, как связать эти два мира через Foreign Function & Memory API без JNI. На примере panama-kvm пройдём путь от первого вызова KVM API до загрузки Linux, настройки памяти, обработки VM exits и интерактивной консоли внутри гостевой системы.

Привет. Я Александр Донин, я технический менеджер платформы VDI и терминального доступа Termit.  В прошлой статье мы рассказывали, почему делаем собственный протокол удаленного доступа Pulsar с нуля, а не форкаем Open Source. Это не значит, что мы вообще против Open Source — используем его, когда это экономит время и не создает проблем: например, в Termit мы используем PostgreSQL для хранения данных и NGINX как веб-сервер, да и начинал Termit с RDP и X2Go. Транспорт в Pulsar — это еще один пример, когда компонент Open Source дал нам как раз то, что требовалось, и вошел в протокол в виде модуля.

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

Хотел домашний Kubernetes, который уносится в рюкзаке. Получился кластер из четырёх RK3588 на Talos и Cozystack: control‑plane, NVMe, виртуалки и отдельный BMC на OpenWrt.

Tesco переносит с VMware около 40 тысяч серверных нагрузок, от которых зависят магазинные серверы и системы данных, включая кассы в торговых залах. По данным The Register, ритейлер начал выбирать замену после отказа Broadcom продлевать поддержку его инсталляций. Миграция идёт в предельно возможном темпе — в опубликованных материалах его описали как at exceptional pace. Уже в ходе проекта выяснилось, что Veeam и Zerto, на которых построены резервное копирование и защита данных, не работают с выбранной платформой. Часть функций пришлось дорабатывать или закупать заново. Computer Weekly

При переходе с vSphere виртуальные машины обычно переносятся средствами конвертации без серьёзных сюрпризов. Сложнее сохранить всё, что за полтора десятка лет выросло вокруг платформы: резервное копирование, микросегментацию, аварийное восстановление, интеграции и регламенты ИБ. Совместимость бэкап-системы с целевой платформой можно проверить по документации за рабочий день, но в миграционном проекте таких проверок набирается около десятка, и каждая требует примерно столько же времени. Состав этой обвязки нужно определить до переноса, иначе несовместимости обнаружатся уже во время миграции.

Обвязку можно разложить по девяти функциональным осям: часть возможностей заработает сразу после переноса, часть команде придётся собирать самостоятельно, а часть устроена иначе и потребует новых регламентов. В статье разберём эти группы, порядок проверок и различия между версиями платформ от сообщества; доработки вендоров поверх открытой базы рассмотрим отдельно. Это вторая статья цикла: в первой обсуждались класс решения, модель поддержки и совокупная стоимость владения. Материал рассчитан на инженеров эксплуатации и архитекторов виртуализации, которые выбирают целевую платформу или уже ведут миграцию; специалистам по ИБ будут полезны разделы о доступе к коду и регуляторных требованиях. Таблица девяти осей и чек-лист пригодятся также при переходе с Hyper-V и Nutanix: они относятся к слою оркестрации и не зависят от исходной платформы.

Как устроен Cozystack и managed Kubernetes на собственном железе

Во время поездки в ОАЭ я случайно попал в дубайское IT-комьюнити в Telegram. Там мы внезапно скоординировались и собрали незапланированный митап. 3 октября встретились в небольшой переговорке в Дубае — получилось душевно, и мы успели обсудить много интересных тем: от Talos и хранилища до сетей и устройства managed Kubernetes.

На митапе я рассказывал о Cozystack — открытой платформе для предоставления managed-сервисов на собственном железе. Начали с обзорной презентации, но довольно быстро перешли к вопросам: почему выбрали именно такой storage, зачем нам одновременно Kube-OVN и Cilium, как устроен Kubernetes внутри Kubernetes и где проходит граница между облачной платформой и обычной виртуализацией.

Ниже — отредактированная техническая расшифровка доклада и обсуждения. Я разберу, как связаны Talos, Flux, LINSTOR, Kube-OVN, Cilium, KubeVirt, Kamaji и Cluster API; как пользовательский ресурс превращается в работающий сервис; и почему для managed Kubernetes важно отдельно обслуживать control plane, вычислительные узлы и хранилище.

ИИ-агент работает в песочнице, но отдельным инструментам нужны разные права. Анализатору можно читать исходники, а менять их нельзя. Как проверить, что этот запрет действует?

В экспериментах с Linux и gVisor встретились три ситуации. Механизм ограничения отсутствует, для его настройки не хватает прав или настройка проходит успешно без ожидаемого эффекта. Даже загруженная и подключённая программа фильтрации не всегда что-то фильтрует. Показываю результаты, ошибки собственных проверок и подход, который помогает проверить ограничения до запуска инструмента агента.

Вроде бы довольно очевидная мысль — у ручной настройки есть предел масштабирования. Пока кластеров немного, команда может держать локальные различия под контролем. Но со временем инфраструктура растёт, команды меняются, решения накапливаются в документации, сценариях и памяти отдельных сотрудников. Площадки, одинаковые на старте, постепенно начинают жить по разным правилам, что со временем перестаёт быть особенностью эксплуатации и превращается в самостоятельный источник рисков. Хуже того, эти процессы зачастую проходят незаметно для команды, занятой рутинными делами — просто в один прекрасный день приходит осознание, что предел достигнут и надо было еще вчера что-то менять.
История, которую я хочу рассказать, началась несколько лет назад, когда перед нами была поставлена задача развернуть на наших площадках отечественную платформу виртуализации Basis Dynamix Enterprise. Закончилась же эта история внедрением качественно нового подхода к эксплуатации. Но обо всем по порядку.

Привет, Хабр! Меня зовут Никита Ивкин, я — ведущий DevOps-инженер РТЛабс, работаю с инфраструктурой Госуслуг. Сегодня я покажу один из наших реальных сценариев: как мы разворачиваем ClickHouse через Arenadata, почему выбрали именно такую топологию и какие нюансы появляются между кнопкой Install и действительно рабочим кластером. Мы разберём причины выбора такой схемы, увидим, где ADCM действительно упрощает эксплуатацию, какие мелочи всплывают вокруг SSH и Ansible и почему после успешного Install хост всё ещё может выглядеть «жёлтым». В конце — проверки со стороны самого ClickHouse и несколько вещей, которыми мы дополнили кластер уже после раскатки.

Если вы хотите запустить гипервизор или высоконагруженную СУБД, ресурсов VPS может быть недостаточно. В такой ситуации на помощь приходит выделенный физический сервер. Но сколько ядер процессора и оперативной памяти понадобится именно вашему проекту? Хватит ли канала на 1 Гбит/с или нужно больше? Можно взять конфигурацию с запасом, но переплачивать за ресурсы, которые большую часть времени будут простаивать, тоже не хочется.

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

Мы продолжаем рассказывать, как создавали AVM собственную платформу управления виртуальными машинами Aéza. В этой части разберём, как обновляем систему без остановки клиентских VM, выполняем живую миграцию, переживаем сбои и масштабируем инфраструктуру а также расскажем, с какими проблемами столкнулись по пути.

1 января 2024 года умер Никлаус Вирт, человек, который придумал Pascal, Modula-2 и Oberon, получил премию Тьюринга и всю жизнь упрямо воевал с раздутым софтом. Мало кто знает, что уже глубоко за семьдесят он сел и спроектировал собственный процессор, маленький и простой, чтобы на нём можно было показать студентам компьютер целиком, от логических вентилей до окон на экране.

В сентябре 2026 года я взял этот процессор и попробовал запустить его везде, куда смог дотянуться. Сначала прямо во вкладке браузера, причём не в эмуляторе, а в виде той самой схемы, которую нарисовал Вирт. Потом в QEMU, как обычную виртуальную машину. Потом в Kubernetes, где вообще-то живут совсем другие виртуалки, с Ubuntu и базами данных. И в конце концов в Cozystack, нашей облачной платформе, где машину Вирта теперь можно поставить кнопкой из каталога, как какой-нибудь PostgreSQL. По дороге я наконец измерил то, о чём программисты спорят десятилетиями, — сколько на самом деле стоит проверка выхода за границы массива. Ещё запустил на процессоре Вирта маленькую языковую модель. И, раз уж честно, одним неосторожным движением отправил в переезд все виртуалки рабочего кластера (никто не пострадал, но было неприятно).

Статья получилась очень длинной, потому что за девять дней случилось очень много всего, и значительная часть случившегося — это мои собственные ошибки, которые пришлось находить и исправлять. Я старался писать так, чтобы её мог читать человек, который про Оберон никогда не слышал, а всё, что интересно только специалистам, спрятал под спойлеры. Читать можно подряд, а можно прыгнуть сразу в интересную часть. Сначала будет рассказ про сам Оберон, потом про то, как разваливался мой первоначальный план, потом про процессор и проверку границ, про браузер и лабораторные, про QEMU, Kubernetes и Cozystack, а в самом конце про языковую модель и про то, как всё это поставить себе.

Все мы изучаем что‑то, чтобы применять полученные знания на практике — от школьников до студентов и далее до профильных специалистов. Передо мной однажды встала задача изучения матчасти судна. Любому понятно, что сопоставление изображений и текста в книгах — та ещё задача, а видеоматериал нагляден, но не интерактивен (нельзя изучать в собственных последовательностях, темпах и ракурсах). Год назад была моя публикация по скрипту на портале 3D печати ( скрипт автоматически открывает соответствующий текстовый блок, при выборе объекта или коллекции в аутлайнере или объекта на сцене), а недавно я показал её попутчику, с которым мы разговорились в поезде и он спросил — «Можно это использовать для изучения астрономии или биологии?», «Да» — ответил я, и вот он и предложил сделать более массовую публикацию на другом портале.

Часть 2

Примечание переводчика

В первой части статьи о протоколах удаленного доступа разобраны архитектурные особенности Citrix HDX\EDT, Omnissa BlastExtreme, Microsoft и Parallels RDP. В этой части о технических, финансовых и "пользовательских" последствиях выбора того или иного VDI, а значит и протокола, а так же итоговая таблица "чемпионата" протоколов.

7. Перспектива FinOps: экономика кодеков и плотность пользователей VDI. 

Архитектура протокола напрямую влияет на капитальные и операционные затраты. Конвейер кодеков определяет потребление ресурсов ЦП и GPU на хостах ВМ, что, в свою очередь, определяет плотность пользователей на одном физическом сервере — основной единице стоимости инфраструктуры VDI. В этом разделе анализ протокола связывается с экономикой серверов, необходимой для стратегии FinOps. 

7.1 Экономическая эффективность Thinwire для CPU по сравнению с полнокадровым H.264 

Архитектура Citrix Thinwire, использующая многокодековое кодирование в одном кадре, вычислительно сложнее на кадр, чем стандартное кодирование H.264. Классификатор содержимого экрана, детектор областей и распределение кодеков добавляют циклы ЦП, чего не делает простой полнокадровый кодировщик H.264. Вопрос архитектуры заключается в том, превышает ли эта дополнительная нагрузка экономию. Эмпирический ответ: нет. Стоимость классификатора существенно ниже, чем стоимость кодирования, сэкономленная за счет отказа от применения H.264 к статическим текстовым областям (которые Thinwire обрабатывает без потерь с минимальным битрейтом). Полнокадровое кодирование в H.264 видео качество для экрана, на 80% состоящего из статического текста и на 20% из видео — значительная трата циклов ЦП и полосы пропускания. Thinwire кодирует 20% видео-области в H.264, а 80% текстовой области без потерь, используя кодек MDRLE, с минимальными затратами ЦП. Потребление ресурсов ЦП при типичном сеансе работы «продвинутого» сотрудника (редактирование документов, браузер, электронные таблицы) в Thinwire заметно ниже, чем при полнокадровом кодировании H.264 без применения vGPU в Omnissa Blast. 

Привет, Хабр! Разбирать вопросы после эфиров — полезная практика. В чате трансляции часто поднимают темы, с которыми инженерам приходится сталкиваться на пилотах и в продакшене.

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

Под катом разбор этих тем и линк на демо.

Вообще-то, эта статья планировалась последней в цикле технических статей, в которой по шагам планировалось изложить технические заметки о внедрении нами NVMEoF через ROCEv2.

Но потом подумалось, а ведь сам процесс, как это всё организовалось, происходило, и все пережитые эмоции, интереснее, чем чисто техническое изложение.

Предисловие переводчика

По жизни и по работе (сначала в Wyse, потом в Dell, а теперь в Getmobit) я занимаюсь уже давным-давно тонкими клиентами, VDI, терминальными серверами и всем, что с этими «темами» связано. В этой ситуации свойства разных протоколов удаленного доступа откладываются в голове крепче «Устава внутренней службы». Однако, жизнь меняется и «Уставы» постоянно нужно обновлять, особенно в ситуации, когда нам всем приходится сталкивать с «заново изобретенными» ОС, приложениями, VDI, ВКС и так далее. Просматривая инет в поисках новостей по протоколам, я наткнулся на цикл статей Артура Оглоза, сравнивающих текущие версии протоколов с неожиданной (для меня во всяком случае) стороны – с архитектурной.

Думаю, многие читали «сборники» типа “VDI smack down”, где фактически сравнивались матрицы фич протоколов (типа есть\нет H.264\multimedia redirection\Zoom optimization…). Это несомненно было полезно при выборе того или иного решения, но не давало представления о реальной жизни, скажем, присутствующей в матрицах фич разных протоколов функции оптимизации одной и той же ВКС.

С другой стороны, холиварные статьи типа «Blast vs PCoIP» раскрывали внутреннюю кухню протоколов, но в основном были ориентированы на негативные стороны конкурента, что в общем-то путало и пугало всех подряд и не позволяло видеть объективную картину.

Чем меня привлекли именно эти статьи, так это ясной прослеживаемостью принятых архитектурных решений на качество user experience и потолок возможностей, обусловленный архитектурой. И для каждого, кто тесно связан с темой VDI, эти статьи прозрачно намекают на абсолютную необходимость внедрения технологий сегодняшнего дня, а не только воспроизведением идей последних 15-20 лет, ну, и раскрытием «коварных намерений гиперскейлеров» в разработке ПО😊

Недавно переносил у нас рабочую Windows-ВМ с Hyper-V на Proxmox.

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

Сам процесс я автоматизировал через AI-агента и уже на первой попытке всплыл хороший пример того, почему такие задачи нельзя сводить к последовательному выполнению команд. Агент создал ВМ на Proxmox, запустил ее, получил от qm status состояние running и посчитал перенос завершенным, хотя сама Windows в этот момент вообще не загрузилась.

Дальше таких моментов всплыло еще больше.

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

Запустить контейнер — дело нескольких секунд. Но как только их количество начинает исчисляться сотнями и тысячами, начинаются сложности — их нужно размещать по узлам, распределять ресурсы, обновлять приложения, не нарушая их доступность, обеспечивать отказоустойчивость и следить, чтобы вся система работала стабильно. И очень быстро оказывается, что основная проблема уже не в самих контейнерах, а в инфраструктуре, на которой они работают.

В ответ на эти сложности появились сервисные модели, позволяющие снять с команд часть рутинных задач и операций. Одни из них полностью скрывают от пользователя серверы и механику оркестрации, оставляя только возможность передать образ и получить работающий сервис. Другие предоставляют готовый Kubernetes-кластер,  избавляя от необходимости разворачивать и обслуживать его control plane, но сохраняя привычную модель работы через API Kubernetes.

На первый взгляд различие между ними не то чтобы огромное — и там, и там в итоге запускаются контейнеры. Но по факту это два разных подхода с разным уровнем контроля, гибкости и разделением зон ответственности. В этой статье разберем, чем Container as a Service отличается от Kubernetes as a Service и как выбрать более подходящую под ваши задачи модель.

Каждый раз управляя облаком, мы совершаем повторяющиеся действия: создаем сеть, виртуальную машину, настраиваем правила Firewall и NAT… Все это интересно и удобно первые несколько раз, а потом тебя начинает напрягать не самый отзывчивый интерфейс и кликов по UI набегают сотни, а то и тысячи в месяц. Но ведь можно же делегировать все эти рутинные приседания ИИ-агенту?

Да, именно так мы и сделали у себя в Облаке VMware, но спокойствие, в этой статье мы его вам продавать не будем. Здесь расскажем тем, кто администрирует свой дата-центр или облачный тенант на базе VMware, как прикрутить к нему Claude Code, Open Code или любого другого MCP-совместимого агента без написания собственной обертки над API. Ну и само собой, мы сделаем это так, чтобы разбушевавшийся агент не смог наворотить лишнего, даже если очень захочет.