Виртуализация как основа облачной инфраструктуры

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

Виртуализация не является изобретением облачной эпохи. Первые практические реализации виртуальных машин появились ещё в 1960-х годах в контексте мэйнфреймов IBM, где требовалось одновременно исполнять несколько независимых операционных сред на одном дорогостоящем вычислительном узле. Однако именно в сочетании с облачной моделью виртуализация приобрела массовое промышленное значение: она стала технологической основой, на которой строятся центры обработки данных, платформы IaaS и большинство управляемых облачных сервисов.

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

Назначение виртуализации

Абстрагирование физических ресурсов и формирование управляемых вычислительных сред

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

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

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

Консолидация нагрузок и повышение коэффициента использования оборудования

Одним из наиболее осязаемых практических эффектов виртуализации является консолидация нагрузок (workload consolidation). В традиционной модели каждому приложению или сервису нередко выделяется отдельный физический сервер. Такой подход мотивирован соображениями изоляции и совместимости: различные приложения могут требовать разных версий операционной системы, конфликтующих библиотек или несовместимых настроек среды. Однако следствием этого является крайне низкий коэффициент использования оборудования. Исследования показывают, что средняя загрузка физических серверов в традиционных центрах обработки данных составляет от 5 до 15 процентов вычислительной мощности. Остальные ресурсы простаивают, но продолжают потреблять электроэнергию и занимать место.

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

Вместе с тем консолидация нагрузок не является безусловно позитивным явлением. Размещение слишком большого числа виртуальных машин на одном физическом узле приводит к конкуренции за ресурсы: процессорное время, пропускную способность памяти и дисковую подсистему. Если совокупная потребность виртуальных машин систематически превышает возможности оборудования, возникает деградация производительности, которая может затронуть все размещённые нагрузки. Поэтому планирование ёмкости (capacity planning) является обязательной дисциплиной при эксплуатации виртуализированной инфраструктуры.

Роль виртуализации в построении центров обработки данных и облачных платформ

Современный центр обработки данных (ЦОД), обслуживающий облачную платформу, представляет собой не просто совокупность серверов, а управляемую среду, в которой физические ресурсы объединены в единый пул и предоставляются потребителям через программные интерфейсы. Виртуализация является ключевым компонентом этой архитектуры. Она обеспечивает абстрагирование оборудования, изоляцию потребителей друг от друга (multi-tenancy), управление жизненным циклом виртуальных сред и динамическое перераспределение ресурсов.

На уровне облачной платформы виртуализация реализует несколько критически важных функций. Миграция виртуальных машин между физическими узлами (live migration) позволяет проводить обслуживание оборудования без остановки пользовательских нагрузок. Моментальные снимки состояния (snapshots) обеспечивают возможность отката к предыдущему состоянию в случае сбоя. Шаблонизация ускоряет массовое развертывание однотипных сред. Автоматизированное управление ресурсами позволяет платформе перераспределять нагрузки в зависимости от текущего потребления.

Следует, однако, учитывать, что виртуализация не является единственной технологией, используемой в облачных платформах. Современные платформы дополняют её программно-определяемыми сетями (Software-Defined Networking, SDN), программно-определяемым хранилищем (Software-Defined Storage, SDS) и системами оркестрации, которые координируют работу всех компонентов. Тем не менее именно виртуализация вычислительных ресурсов остаётся фундаментальным слоем, без которого остальные надстройки не имеют основания.

Гипервизоры и типы виртуализации

Понятие гипервизора

Гипервизор (hypervisor), или монитор виртуальных машин (Virtual Machine Monitor, VMM), представляет собой программный компонент, обеспечивающий создание и управление виртуальными машинами. Гипервизор располагается между физическим оборудованием и гостевыми операционными системами, выполняя функции распределения ресурсов, изоляции и трансляции обращений гостевых систем к аппаратуре. Именно гипервизор определяет, какие ресурсы доступны каждой виртуальной машине, каким образом обращения к оборудованию транслируются и как обеспечивается взаимная независимость виртуальных сред.

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

Гипервизор первого типа (type 1 hypervisor)

Гипервизор первого типа, называемый также «bare-metal hypervisor», устанавливается непосредственно на физическое оборудование, без промежуточной операционной системы общего назначения. Он берёт на себя функции управления аппаратными ресурсами и предоставляет их гостевым операционным системам. Фактически гипервизор первого типа сам является минимальной операционной средой, специализированной на задачах виртуализации.

Примерами гипервизоров первого типа являются VMware ESXi, Microsoft Hyper-V (в режиме серверной роли), Xen и KVM. Последний заслуживает отдельного пояснения. KVM (Kernel-based Virtual Machine) встроен в ядро Linux и превращает операционную систему Linux в гипервизор первого типа. Хотя Linux при этом продолжает функционировать как операционная система общего назначения, KVM обычно классифицируют как гипервизор первого типа, поскольку модуль виртуализации работает на уровне ядра и взаимодействует с аппаратными средствами виртуализации процессора напрямую ⁴. Эта классификация в литературе не единодушна: часть авторов относит KVM ко второму типу, поскольку рядом с ним работает полноценная ОС с обычными приложениями, а эмуляцию устройств выполняет пользовательский процесс QEMU — каждая виртуальная машина на хосте с KVM видна как процесс qemu-system-x86_64. Деление на два типа удобно как первое приближение, но реальные системы занимают промежуточные положения, и полезнее спрашивать, какая часть гипервизора работает в ядре, а какая — в пользовательском пространстве.

Гипервизоры первого типа применяются в центрах обработки данных и облачных платформах, где требуется высокая производительность, надёжная изоляция и возможность управления большим количеством виртуальных машин. Отсутствие промежуточной операционной системы общего назначения снижает накладные расходы и уменьшает поверхность атаки.

Гипервизор второго типа (type 2 hypervisor)

Гипервизор второго типа устанавливается как обычное приложение поверх существующей операционной системы. Хостовая операционная система управляет аппаратными ресурсами, а гипервизор работает как её приложение, создавая виртуальные машины как процессы хостовой среды. Слово «приложение» здесь не следует понимать буквально как «только пользовательское пространство»: для использования VT-x/AMD-V и управления памятью гостя гипервизору второго типа всё равно нужен собственный модуль ядра (у VirtualBox это драйвер vboxdrv, без которого машина не запустится). Отличие от первого типа в другом — аппаратурой управляет хостовая ОС общего назначения, и гипервизор получает процессорное время и память у её планировщика наравне с остальными программами. Обращения гостевых систем к аппаратуре проходят через два программных уровня: сначала через гипервизор, затем через хостовую операционную систему.

Примерами гипервизоров второго типа являются Oracle VirtualBox и VMware Workstation. Такие решения широко используются для разработки, тестирования и обучения, поскольку не требуют выделенного оборудования и позволяют запускать виртуальные машины на обычном рабочем компьютере наряду с другими приложениями.

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

Условие Попека — Голдберга и проблема архитектуры x86

Прежде чем рассматривать способы виртуализации, нужно понять, почему одни процессоры виртуализируются легко, а другие — нет. В 1974 году Дж. Попек и Р. Голдберг сформулировали формальное условие ¹. Назовём чувствительной (sensitive) инструкцию, которая читает или меняет состояние, важное для изоляции: режим процессора, таблицы страниц, флаг разрешения прерываний. Назовём привилегированной (privileged) инструкцию, которая в пользовательском режиме вызывает исключение (trap) и тем самым передаёт управление ядру. Теорема Попека — Голдберга утверждает: эффективный монитор виртуальных машин можно построить, если множество чувствительных инструкций является подмножеством множества привилегированных. Тогда гостевое ядро можно исполнять напрямую в непривилегированном режиме: обычные инструкции выполняются процессором с полной скоростью, а каждая чувствительная вызывает исключение, которое перехватывает гипервизор и эмулирует её эффект. Этот подход называют «trap-and-emulate».

Архитектура x86 до середины 2000-х годов этому условию не удовлетворяла: в ней было около семнадцати чувствительных, но непривилегированных инструкций. Классический пример — POPF: в пользовательском режиме она молча игнорирует попытку изменить флаг разрешения прерываний, вместо того чтобы вызвать исключение. Гостевое ядро, запущенное в непривилегированном режиме, думает, что запретило прерывания, гипервизор об этом не узнаёт, и поведение гостя становится неверным. Аналогично инструкция SMSW позволяет непривилегированному коду прочитать часть управляющего регистра и обнаружить, что он работает не в нулевом кольце защиты.

Обойти это ограничение можно двумя способами, которые соответствуют двум подходам, рассмотренным ниже: либо переписывать проблемные инструкции гостя на лету (бинарная трансляция), либо изменить само гостевое ядро так, чтобы оно не использовало их (паравиртуализация). Третий способ — изменить процессор — появился позже и сделал x86 виртуализируемой в смысле Попека — Голдберга.

Полная виртуализация, паравиртуализация и аппаратная поддержка

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

При полной виртуализации (full virtualization) гостевая операционная система не модифицируется. Она исполняется в неизменённом виде, а гипервизор перехватывает и эмулирует привилегированные инструкции. На x86 без аппаратной поддержки перехвата исключений недостаточно, поэтому VMware с 1999 года применяла бинарную трансляцию (binary translation): код гостевого ядра перед исполнением просматривается блоками, чувствительные инструкции заменяются вызовами гипервизора, а оттранслированные блоки кэшируются и повторно используются; пользовательский код гостя при этом исполняется напрямую ². Это обеспечивает максимальную совместимость: внутри виртуальной машины можно запустить практически любую операционную систему без её адаптации. Однако эмуляция привилегированных операций создаёт вычислительные накладные расходы, которые могут быть заметны при интенсивных операциях ввода-вывода или при работе с памятью.

Паравиртуализация (paravirtualization) предполагает модификацию гостевой операционной системы. Вместо выполнения привилегированных инструкций напрямую гостевая система использует специальные программные интерфейсы (hypercalls) для обращения к гипервизору. Это позволяет избежать затратного перехвата и эмуляции, повышая производительность. Однако паравиртуализация требует изменений в ядре гостевой операционной системы, что ограничивает набор совместимых систем и усложняет сопровождение. Наиболее известной реализацией паравиртуализации является гипервизор Xen в его раннем варианте ³. Сегодня паравиртуализацию ядра целиком применяют редко, но её идея сохранилась в паравиртуализированных драйверах устройств, которые рассматриваются в следующем разделе.

Аппаратная поддержка виртуализации (hardware-assisted virtualization) появилась в процессорах Intel (технология VT-x) и AMD (технология AMD-V) в середине 2000-х годов. Она вводит специальный режим работы процессора, в котором гостевые операционные системы могут безопасно исполнять привилегированные инструкции, а процессор аппаратно обеспечивает перехват тех операций, которые должны обрабатываться гипервизором. Аппаратная поддержка существенно сократила накладные расходы полной виртуализации, сделав её производительность сопоставимой с паравиртуализацией. Интересно, что первые реализации VT-x уступали по скорости зрелой бинарной трансляции: каждый выход из гостя в гипервизор (VM exit) стоил тысячи тактов, а таблицы страниц по-прежнему приходилось обслуживать программно ². Разрыв закрыло второе поколение аппаратной поддержки — двухуровневая трансляция адресов, о которой пойдёт речь ниже. В результате аппаратная виртуализация стала доминирующим подходом в современных системах. KVM, VMware ESXi и Microsoft Hyper-V опираются на аппаратную поддержку процессора как на обязательное условие работы.

Проверить наличие аппаратной поддержки в Linux можно без специальных средств: процессор с VT-x сообщает флаг vmx, с AMD-V — флаг svm, а утилита lscpu выводит итог в строке Virtualization. Ниже приведён вывод, полученный в среде WSL2 на процессоре AMD Ryzen:

lscpu | grep -i -E 'virtualization|hypervisor'

Virtualization:                       AMD-V
Hypervisor vendor:                    Microsoft
Virtualization type:                  full

Строка Hypervisor vendor показывает, что сама эта система Linux уже работает внутри виртуальной машины под гипервизором Hyper-V, а строка Virtualization: AMD-V — что гипервизор передал гостю возможность запускать собственные виртуальные машины. Эта ситуация называется вложенной виртуализацией и рассматривается в разделе о виртуализации памяти и ввода-вывода. Если строки Virtualization нет, а в /proc/cpuinfo отсутствуют флаги vmx и svm, то либо процессор не поддерживает аппаратную виртуализацию, либо она отключена в настройках BIOS/UEFI, либо (внутри ВМ) гипервизор её не пробрасывает.

Влияние выбранного подхода на практику

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

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

Виртуализация памяти и ввода-вывода

Аппаратная поддержка VT-x и AMD-V решила проблему чувствительных инструкций, но не две другие причины накладных расходов: трансляцию адресов памяти и эмуляцию устройств. Именно в них сегодня сосредоточена основная разница между «медленной» и «быстрой» виртуальной машиной, и именно их механизмы определяют, сколько стоит каждая операция гостя.

Двухуровневая трансляция адресов: EPT и NPT

В обычной системе процессор переводит виртуальный адрес процесса в физический по таблицам страниц, которые ведёт ядро. В виртуальной машине уровней адресов три: гостевой виртуальный адрес (guest virtual address, GVA), гостевой физический адрес (guest physical address, GPA), то есть адрес в «оперативной памяти», которую гость считает своей, и физический адрес хоста (host physical address, HPA). Гостевое ядро ведёт таблицы GVA → GPA и ничего не знает о том, где в действительности лежат его страницы.

До появления аппаратной помощи гипервизор строил для каждого гостевого процесса теневые таблицы страниц (shadow page tables), сразу отображающие GVA → HPA, и загружал в процессор их, а не гостевые. Чтобы теневые таблицы оставались верными, гипервизор защищал гостевые таблицы от записи и перехватывал каждое их изменение. Для нагрузок, которые часто создают процессы и отображают память (компиляция, веб-серверы с порождением процессов), такие перехваты становились главной статьёй накладных расходов.

Второе поколение аппаратной поддержки ввело двухуровневую трансляцию адресов (Second Level Address Translation, SLAT): у Intel она называется EPT (Extended Page Tables), у AMD — NPT (Nested Page Tables) или RVI. Процессор сам выполняет обе трансляции: по гостевым таблицам переводит GVA → GPA, а по второй таблице, которую ведёт гипервизор, — GPA → HPA, как показано на рисунке ниже. Гость свободно меняет свои таблицы без единого перехвата, а гипервизор правит только вторую таблицу, когда выделяет гостю или отбирает у него память.

Цена этого решения проявляется при промахе буфера ассоциативной трансляции (Translation Lookaside Buffer, TLB). Каждое обращение к гостевой таблице страниц само является гостевым физическим адресом, который нужно перевести через вторую таблицу. При четырёхуровневых таблицах с обеих сторон полный обход в худшем случае требует (4 + 1) \cdot (4 + 1) - 1 = 24 обращения к памяти вместо 4 без виртуализации ⁶. Поэтому для виртуальных машин особенно полезны большие страницы (2 МиБ и 1 ГиБ): они сокращают число уровней обхода и число записей в TLB. Наличие SLAT в Linux видно по флагам процессора ept (Intel) и npt (AMD) в /proc/cpuinfo; гипервизоры используют её автоматически, если процессор её поддерживает.

Паравиртуализированные устройства virtio

Эмуляция реального сетевого адаптера (например, Intel e1000) означает, что гостевой драйвер пишет в регистры несуществующего устройства, каждая такая запись вызывает выход в гипервизор, и гипервизор программно воспроизводит поведение микросхемы. На передачу одного сетевого пакета приходится несколько выходов из гостя, каждый из которых стоит микросекунды.

Паравиртуализированное устройство устроено иначе: гость знает, что работает в виртуальной машине, и обменивается с гипервизором через очереди в разделяемой памяти. Стандартом таких устройств стал virtio, предложенный Р. Расселом для Linux в 2008 году ⁵ и с тех пор стандартизованный организацией OASIS. Драйвер гостя кладёт в кольцевую очередь (virtqueue) описатели буферов — например, десятки пакетов сразу — и одним уведомлением сообщает об этом гипервизору; гипервизор обрабатывает пакеты пачкой и так же пачкой возвращает ответы. Семейство virtio включает сетевую карту (virtio-net), блочное устройство (virtio-blk), SCSI-контроллер (virtio-scsi), консоль, генератор случайных чисел и устройство «балуна» памяти (virtio-balloon), с помощью которого гипервизор просит гостя вернуть неиспользуемые страницы.

Таким образом, паравиртуализация, которая в варианте раннего Xen требовала переписать гостевое ядро, сегодня живёт на уровне драйверов: ядро гостя остаётся неизменным, а быстрыми становятся только устройства. Драйверы virtio входят в ядро Linux, а для Windows устанавливаются отдельно. В VirtualBox паравиртуализированный сетевой адаптер выбирается как тип «Paravirtualized Network (virtio-net)», а в облаках, построенных на KVM, virtio используется по умолчанию: внутри типичной облачной ВМ диск виден как /dev/vda, а не как /dev/sda.

Прямой доступ к устройствам: IOMMU и SR-IOV

Для сетей 100 Гбит/с и ускорителей вычислений даже virtio оказывается узким местом, и гостю передают физическое устройство напрямую (PCI passthrough). Препятствие здесь в прямом доступе к памяти (Direct Memory Access, DMA): устройство пишет в память по физическим адресам, и драйвер гостя указал бы ему гостевые физические адреса, которые не совпадают с адресами хоста. Хуже того, злонамеренный гость мог бы приказать устройству записать данные в чужую память. Эту задачу решает блок управления памятью для ввода-вывода (Input–Output Memory Management Unit, IOMMU; у Intel — VT-d, у AMD — AMD-Vi): он транслирует адреса DMA устройства так же, как MMU транслирует адреса процессора, и ограничивает устройство памятью своего гостя.

Отдавать каждой ВМ отдельную физическую карту дорого, поэтому применяется виртуализация ввода-вывода с единым корнем (Single Root I/O Virtualization, SR-IOV): одна физическая сетевая карта представляет себя на шине PCIe как одна физическая функция (physical function) и десятки виртуальных функций (virtual functions), каждая из которых передаётся отдельной ВМ. Гость работает с виртуальной функцией напрямую, минуя гипервизор на пути данных. Платой за скорость является потеря гибкости: такую машину сложнее перенести на другой узел без остановки (live migration), поскольку состояние находится в аппаратуре. Крупные облака идут дальше и выносят обработку сети и дисков на отдельные платы с собственным процессором (у AWS — система Nitro), оставляя основному процессору хоста только исполнение гостей.

Вложенная виртуализация

Вложенная виртуализация (nested virtualization) — запуск гипервизора внутри виртуальной машины. Она нужна, например, для тестирования самих гипервизоров, для учебных стендов и для сред вроде WSL2 и Docker Desktop, которые сами работают в виртуальной машине и при этом могут запускать свои ВМ. Аппаратура x86 поддерживает только один уровень VT-x, поэтому гипервизор нижнего уровня (L0) эмулирует для гостевого гипервизора (L1) инструкции VT-x: когда L1 пытается запустить свою машину (L2), инструкция перехватывается L0, который сам запускает L2 на реальном процессоре, сливая таблицы L1 со своими ⁷. Вывод lscpu, приведённый выше, получен именно в такой среде: Hyper-V (L0) пробросил флаг AMD-V в Linux-машину WSL2 (L1).

Каждый уровень добавляет выходы в гипервизор: одно событие в L2, которое должен обработать L1, превращается в несколько переходов через L0. Поэтому вложенная виртуализация пригодна для разработки, обучения и непрерывной интеграции, но для промышленных нагрузок её избегают. Облачные поставщики включают её только для отдельных типов машин или по запросу.

Ресурсная модель виртуальной машины

Виртуальные процессоры, оперативная память, дисковые образы и виртуальные сетевые интерфейсы

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

Виртуальные процессоры (virtual CPU, vCPU) соответствуют логическим ядрам физического процессора, выделяемым виртуальной машине. Количество виртуальных процессоров определяет, сколько потоков вычислений гостевая система может выполнять параллельно. Гипервизор планирует исполнение виртуальных процессоров на физических ядрах, обеспечивая разделение процессорного времени между виртуальными машинами. При этом суммарное количество виртуальных процессоров всех виртуальных машин на одном хосте может превышать количество физических ядер — это называется переподпиской (overcommitment) процессорных ресурсов. Умеренная переподписка допустима, если нагрузки не являются одновременно интенсивными, но при чрезмерной переподписке неизбежна деградация производительности.

Оперативная память виртуальной машины выделяется из общего объёма физической памяти хоста. Гипервизор обеспечивает изоляцию адресного пространства: каждая гостевая система видит собственный непрерывный диапазон адресов, хотя в действительности эти адреса могут быть размещены в различных физических областях. Некоторые гипервизоры поддерживают механизмы оптимизации памяти, такие как дедупликация одинаковых страниц (memory deduplication) и динамическое перераспределение памяти (memory ballooning), однако эти технологии имеют свои ограничения и не всегда применимы.

Дисковые ресурсы виртуальной машины представлены в виде образов дисков (disk images) — файлов или блочных устройств, которые гипервизор предоставляет гостевой системе как виртуальные жёсткие диски. Распространёнными форматами образов являются VMDK (VMware), VHD и VHDX (Microsoft), QCOW2 (QEMU/KVM) и RAW. Выбор формата влияет на производительность, возможность создания снимков состояния и эффективность использования дискового пространства. Формат RAW обеспечивает наименьшие накладные расходы, но занимает полный объём выделенного пространства. Формат QCOW2 поддерживает динамическое выделение (thin provisioning), при котором файл образа увеличивается по мере фактической записи данных, а также позволяет создавать снимки состояния. Основные свойства форматов сведены в таблицу.

Форматы взаимно преобразуются утилитой qemu-img из комплекта QEMU, а её подкоманда info показывает разницу между заявленным размером диска и фактически занятым местом — то есть результат динамического выделения:

qemu-img convert -p -f vdi -O qcow2 lab-vm-01.vdi lab-vm-01.qcow2
qemu-img info lab-vm-01.qcow2

image: lab-vm-01.qcow2
file format: qcow2
virtual size: 20 GiB (21474836480 bytes)
disk size: 3.92 GiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    compression type: zlib
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
    extended l2: false

Строка virtual size — объём диска, который видит гость, disk size — место, фактически занятое файлом на хосте. Приведённый вывод соответствует документации QEMU; конкретные числа зависят от установленной системы.

Виртуальные сетевые интерфейсы обеспечивают подключение виртуальной машины к сети. Гипервизор эмулирует сетевой адаптер, который гостевая система использует для передачи и приёма данных. Виртуальные интерфейсы могут быть подключены к различным типам виртуальных сетей: трансляции адресов (NAT), при которой гипервизор выступает для гостя маршрутизатором с трансляцией адресов в сеть хоста, мостовым (bridged), обеспечивающим доступ к физической сети хоста, внутренним (internal), связывающим только виртуальные машины на одном хосте, или изолированным (host-only), ограничивающим связность виртуальной машиной и хостом. Режим NAT используется по умолчанию в большинстве настольных гипервизоров: гость получает выход в интернет, но снаружи, в том числе с самого хоста, к нему нельзя обратиться без явного проброса портов. Поведение режимов на примере VirtualBox сведено в таблицу ⁹. Для повышения производительности сетевого ввода-вывода используются паравиртуализированные сетевые драйверы (например, virtio в среде KVM), которые снижают накладные расходы на эмуляцию полноценного аппаратного адаптера.

Сочетание двух адаптеров — NAT для выхода в интернет и host-only для доступа с хоста — даёт учебную ВМ, которая обновляется из интернета, доступна по SSH с хоста и при этом не видна из локальной сети. Именно такая конфигурация используется в лабораторной работе 2.

Шаблоны, снимки состояния и клонирование

Помимо основных вычислительных ресурсов, виртуализация предоставляет ряд инструментов, существенно упрощающих управление вычислительными средами.

Шаблон (template) виртуальной машины представляет собой предварительно настроенный образ, содержащий операционную систему, базовое программное обеспечение и конфигурацию. Шаблоны используются для быстрого развертывания новых виртуальных машин: вместо установки операционной системы с нуля администратор создаёт экземпляр на основе шаблона, что сокращает время подготовки среды с десятков минут, которые занимает установка, до времени копирования образа и загрузки гостевой системы — обычно меньше минуты. Связанные клоны (linked clones), у которых диск — разностный файл поверх общего образа, копируются за секунды, но загрузку ОС это не ускоряет. В контексте облачных платформ шаблоны лежат в основе каталогов готовых образов (например, Amazon Machine Images в AWS или образов в Yandex Cloud).

Снимок состояния (snapshot) фиксирует состояние виртуальной машины в определённый момент времени: содержимое дисков и конфигурацию виртуального оборудования, а если снимок делается с работающей машины и гипервизор это поддерживает, — также содержимое оперативной памяти и состояние процессора. В VirtualBox снимок работающей машины сохраняет память в отдельный файл, и после восстановления машина продолжает работу с того же места; снимок выключенной машины памяти не содержит, и после восстановления система загружается заново. Дисковая часть снимка не копирует диск: исходный образ становится доступным только для чтения, а все последующие записи попадают в новый разностный файл (в VirtualBox — разностный VDI, в QCOW2 — внутренний снимок или наложение с указанием backing file). Поэтому снимок создаётся за секунды, а его размер растёт по мере изменений после него. Снимки позволяют оперативно вернуться к зафиксированному состоянию, что особенно полезно при тестировании обновлений, экспериментах с конфигурацией и в учебных сценариях. Однако снимки не являются полноценной заменой резервного копирования. Длительное накопление снимков увеличивает объём занимаемого дискового пространства, усложняет управление и может негативно сказаться на производительности дисковой подсистемы, поскольку каждая операция записи должна учитывать цепочку зависимых снимков.

Клонирование (cloning) создаёт полную копию существующей виртуальной машины, включая её дисковые образы и конфигурацию. Клон представляет собой независимый экземпляр, который после создания существует и развивается отдельно от оригинала. Клонирование используется для масштабирования однотипных сред, создания тестовых копий и подготовки учебных лабораторий.

Ограничения виртуальной машины

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

Первое ограничение — накладные расходы на гостевую операционную систему. Каждая виртуальная машина содержит полноценный экземпляр операционной системы со всеми её компонентами: ядром, системными службами, библиотеками и конфигурационными файлами. Это означает, что значительная доля ресурсов — оперативной памяти и дискового пространства — расходуется не на прикладную задачу, а на поддержание операционной среды. Если на одном физическом сервере размещено двадцать виртуальных машин с одной и той же операционной системой, ядро этой системы загружено в память двадцать раз, и двадцать экземпляров системных служб потребляют процессорное время.

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

Третье ограничение — объём артефакта. Образ виртуальной машины, включающий операционную систему и прикладное программное обеспечение, может занимать гигабайты дискового пространства. Передача таких образов по сети, их хранение и версионирование требуют значительных ресурсов.

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

Механизмы изоляции на уровне ядра операционной системы

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

Пространства имён (namespaces)

Пространства имён (namespaces) обеспечивают логическое разделение глобальных ресурсов ядра между процессами. Каждое пространство имён создаёт для входящих в него процессов изолированное представление определённого ресурса, скрывая существование одноимённых ресурсов в других пространствах. Linux реализует несколько типов пространств имён, каждый из которых изолирует отдельную категорию ресурсов ¹⁰. Новое пространство имён создаётся системным вызовом clone() (при порождении процесса) или unshare() (для текущего процесса) с соответствующим флагом; одноимённая утилита unshare из пакета util-linux принимает эти флаги как ключи командной строки.

Принадлежность процесса пространствам имён видна в каталоге /proc/<pid>/ns: каждая запись — символическая ссылка, номер в квадратных скобках которой является номером индексного дескриптора пространства. Два процесса находятся в одном пространстве имён тогда и только тогда, когда номера совпадают.

ls -l /proc/self/ns

lrwxrwxrwx 1 noum noum 0 Oct 22 00:01 cgroup -> cgroup:[4026531835]
lrwxrwxrwx 1 noum noum 0 Oct 22 00:01 ipc -> ipc:[4026532206]
lrwxrwxrwx 1 noum noum 0 Oct 22 00:01 mnt -> mnt:[4026532217]
lrwxrwxrwx 1 noum noum 0 Oct 22 00:01 net -> net:[4026531840]
lrwxrwxrwx 1 noum noum 0 Oct 22 00:01 pid -> pid:[4026532219]
lrwxrwxrwx 1 noum noum 0 Oct 22 00:01 pid_for_children -> pid:[4026532219]
lrwxrwxrwx 1 noum noum 0 Oct 22 00:01 time -> time:[4026531834]
lrwxrwxrwx 1 noum noum 0 Oct 22 00:01 time_for_children -> time:[4026531834]
lrwxrwxrwx 1 noum noum 0 Oct 22 00:01 user -> user:[4026531837]
lrwxrwxrwx 1 noum noum 0 Oct 22 00:01 uts -> uts:[4026532218]

Пространство имён процессов (PID namespace) скрывает от группы процессов все остальные процессы системы. Внутри пространства имён нумерация процессов начинается заново с единицы. Первый процесс, запущенный в изолированной среде, получает идентификатор PID 1 в пределах своего пространства имён, хотя хостовая система видит его под иным глобальным идентификатором. Это легко наблюдать без контейнерных инструментов. Ключ --fork нужен потому, что новое пространство PID применяется к потомкам вызвавшего процесса, а --mount-proc монтирует новый экземпляр /proc, иначе ps читал бы список процессов хоста. Ключ -r (--map-root-user) дополнительно создаёт пространство имён пользователей, что позволяет выполнить пример без sudo:

unshare -r --pid --fork --mount-proc ps -o pid,user,cmd

  PID USER     CMD
    1 root     ps -o pid,user,cmd

Внутри нового пространства существует единственный процесс — сама команда ps с PID 1, — хотя на хосте в тот же момент работают сотни процессов.

Сетевое пространство имён (network namespace) предоставляет изолированный сетевой стек: собственные сетевые интерфейсы, таблицы маршрутизации, правила сетевого экрана и диапазон портов. Благодаря этому несколько групп процессов на одном хосте могут одновременно использовать одни и те же номера портов, не конфликтуя друг с другом.

Пространство имён точек монтирования (mount namespace) изолирует файловую систему: каждая группа процессов видит собственное дерево каталогов, независимое от основной файловой системы хоста и от файловых систем других изолированных сред.

Пространство имён узла (UTS namespace) позволяет группе процессов иметь собственное имя хоста (hostname) и доменное имя, независимое от хостовой системы. Это важно для приложений, которые используют имя хоста для идентификации узла в распределённой системе.

Пространство имён межпроцессного взаимодействия (IPC namespace) изолирует объекты System V IPC (сегменты разделяемой памяти, очереди сообщений и наборы семафоров System V) и очереди сообщений POSIX. Именованные семафоры и разделяемая память POSIX им не изолируются: они реализованы как файлы в /dev/shm и разделяются через mount namespace. Процессы внутри изолированной среды могут взаимодействовать через эти механизмы, не затрагивая процессы за её пределами.

Пространство имён пользователей (user namespace) позволяет отображать идентификаторы пользователей и групп внутри изолированной среды на иные идентификаторы снаружи. Практически значимым следствием этого является возможность предоставить процессу привилегии суперпользователя (UID 0) в пределах пространства имён, тогда как на уровне хостовой системы он будет работать с ограниченными правами непривилегированного пользователя. Данный механизм снижает риски эскалации привилегий при нарушении изоляции. Отображение задаётся файлом /proc/<pid>/uid_map, и его действие видно на простом опыте: файл, созданный «суперпользователем» внутри пространства имён, снаружи принадлежит обычному пользователю с UID 1000.

unshare -r sh -c 'cat /proc/self/uid_map; touch /tmp/ux_test; ls -ln /tmp/ux_test'
ls -ln /tmp/ux_test

         0       1000          1
-rw-r--r-- 1 0 0 0 Oct 22 00:02 /tmp/ux_test
-rw-r--r-- 1 1000 1000 0 Oct 22 00:02 /tmp/ux_test

Строка 0 1000 1 читается так: идентификатор 0 внутри пространства соответствует идентификатору 1000 снаружи, длина диапазона — один идентификатор. Привилегии «root» внутри распространяются только на объекты, принадлежащие этому пространству имён пользователей.

Группы управления ресурсами (control groups, cgroups)

Группы управления ресурсами (control groups, cgroups) решают задачу, принципиально отличную от пространств имён. Если пространства имён определяют, какие ресурсы видит процесс, то cgroups определяют, сколько ресурсов он может потребить. С их помощью можно задать верхние пределы потребления процессорного времени, оперативной памяти, пропускной способности дисковой подсистемы и числа процессов. Пропускную способность сети cgroups не ограничивают: в версии 2 сетевого контроллера нет, а контроллеры net_cls и net_prio версии 1 лишь помечали пакеты для подсистемы управления трафиком tc, которая и выполняла ограничение. При достижении лимита памяти, например, ядро может завершить наиболее ресурсоёмкий процесс группы или ограничить его выполнение — в зависимости от настроенной политики. Без количественных ограничений одна неконтролируемая группа процессов способна исчерпать все ресурсы хоста, нарушая работу остальных.

Механизм существует в двух версиях ¹¹. В cgroups v1 (ядро 2.6.24, 2008 год) у каждого контроллера — cpu, memory, blkio, pids и других — была своя иерархия, и один процесс мог находиться в разных местах разных деревьев, что делало согласованное управление трудным. В cgroups v2 (стабильна с ядра 4.5) иерархия единая: группа — это каталог в файловой системе cgroup2, все контроллеры действуют на одно и то же дерево, процессы находятся только в листовых группах, а включение контроллеров для дочерних групп задаётся файлом cgroup.subtree_control ¹². Ubuntu начиная с 21.10, Debian 11, Fedora 31 и RHEL 9 используют v2 по умолчанию. Определить версию можно по типу файловой системы, смонтированной в /sys/fs/cgroup:

stat -fc %T /sys/fs/cgroup
cat /sys/fs/cgroup/cgroup.controllers
ls /sys/fs/cgroup

cgroup2fs
cpuset cpu io memory hugetlb pids rdma
cgroup.controllers      cgroup.stat             cpu.stat.local          memory.numa_stat
cgroup.max.depth        cgroup.subtree_control  cpuset.cpus.effective   memory.pressure
cgroup.max.descendants  cgroup.threads          cpuset.mems.effective   memory.reclaim
cgroup.pressure         cpu.pressure            io.pressure             memory.stat
cgroup.procs            cpu.stat                io.stat

Этот вывод получен в WSL2: файловая система cgroup2fs означает v2, а в корне видны только файлы интерфейса корневой группы. На обычном хосте с systemd рядом с ними находятся ещё и каталоги дочерних групп — init.scope, system.slice (системные службы, в том числе docker.service и группы контейнеров), user.slice (сеансы пользователей). Файлы с префиксом контроллера задают лимиты (memory.max, cpu.max, pids.max, io.max) или отдают статистику (memory.stat, cpu.stat, *.pressure — время, в течение которого задачи простаивали из-за нехватки ресурса). Членство процесса в группе показывает файл /proc/<pid>/cgroup: в v2 в нём одна строка вида 0::/user.slice/user-1000.slice/session-3.scope, в v1 — по строке на каждую иерархию.

Отдельно стоит упомянуть контроллер pids, который ограничивает число процессов и потоков в группе. Он защищает от «форк-бомбы» — процесса, бесконечно порождающего свои копии: без него такой процесс исчерпывает общесистемный предел числа процессов (/proc/sys/kernel/pid_max), после чего на хосте не может запуститься даже оболочка администратора. Ограничение задаётся одной записью (команды требуют прав root и показаны для иллюстрации):

sudo mkdir /sys/fs/cgroup/demo
echo 20 | sudo tee /sys/fs/cgroup/demo/pids.max
echo $$ | sudo tee /sys/fs/cgroup/demo/cgroup.procs   # перенести текущую оболочку в группу
for i in $(seq 30); do sleep 600 & done

...
bash: fork: retry: Resource temporarily unavailable
bash: fork: Resource temporarily unavailable

После двадцатого процесса в группе системный вызов fork() возвращает ошибку EAGAIN, а счётчик max в файле pids.events группы увеличивается при каждом отказе. Именно этот механизм используют Docker (--pids-limit) и Kubernetes (podPidsLimit).

Соотношение аппаратной и программной изоляции

Механизмы изоляции ядра и гипервизорная виртуализация решают схожую задачу — разграничение вычислительных сред — но на разных уровнях абстракции и с различными гарантиями. Гипервизор создаёт аппаратную границу между гостевой и хостовой системой, опираясь на поддержку процессора. Пространства имён и cgroups — это программные средства одного и того же ядра операционной системы, а не аппаратные барьеры. Уязвимость в ядре хостовой системы потенциально затрагивает все изолированные среды, работающие на этом ядре. Поэтому изоляция средствами ядра считается менее строгой по сравнению с изоляцией, обеспечиваемой гипервизором.

В сценариях с высокими требованиями к безопасности дополнительно используются специализированные механизмы: seccomp-профили, ограничивающие набор доступных системных вызовов; политики AppArmor и SELinux, реализующие мандатный контроль доступа; а также изолирующие среды исполнения, добавляющие промежуточный уровень между процессами и ядром.

Промежуточные решения: microVM, gVisor и Kata Containers

Противопоставление «тяжёлая, но надёжно изолированная ВМ» и «лёгкий, но разделяющий ядро процесс» за последние годы размылось: появились решения, которые берут от каждого подхода его сильную сторону.

Микровиртуальная машина (microVM) — виртуальная машина с предельно урезанным набором виртуального оборудования. Монитор Firecracker, созданный AWS для сервисов Lambda и Fargate, работает поверх KVM, но вместо QEMU с его сотнями эмулируемых устройств предоставляет гостю только несколько устройств virtio (сеть, блочное устройство, сокет vsock), последовательный порт и контроллер клавиатуры для перезагрузки ⁸. Отсутствие BIOS, шины PCI и эмуляции старого оборудования позволяет запускать гостевое ядро Linux примерно за 125 мс и тратить на служебные структуры монитора около 5 МиБ памяти на машину, благодаря чему на одном сервере размещаются тысячи microVM. Каждая функция или контейнер клиента получает собственное ядро и аппаратную границу изоляции при затратах, сопоставимых с контейнером.

Kata Containers применяет ту же идею к контейнерам: среда исполнения, совместимая со спецификацией OCI (тема 3), запускает каждый контейнер или каждый под Kubernetes внутри отдельной лёгкой ВМ на базе QEMU, Cloud Hypervisor или Firecracker. Для Docker и Kubernetes такой контейнер выглядит обычным, но разделяет с хостом не ядро, а только гипервизор.

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

Типичные ошибки интерпретации

Первая ошибка — полагать, что процессы гостевой системы видны на хосте. Хост видит процесс гипервизора (VirtualBoxVM, qemu-system-x86_64) и, возможно, его потоки, по одному на виртуальный процессор, но не процессы внутри гостя: у гостя собственное ядро и собственная таблица процессов. Нагрузка гостя проявляется на хосте как загрузка процессора потоками гипервизора. С контейнером ситуация обратная: его процессы — обычные процессы ядра хоста и видны в ps на хосте под своими глобальными PID.

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

Третья ошибка — считать, что «аппаратная виртуализация делает ВМ такой же быстрой, как физический сервер». Вычисления действительно выполняются почти без потерь, но промахи TLB, выходы в гипервизор при вводе-выводе и эмулируемые устройства по-прежнему стоят дорого; именно поэтому так важны SLAT, virtio и SR-IOV.

Четвёртая ошибка — считать, что cgroups ограничивают «всё». Они не ограничивают сетевую полосу, а лимит памяти без запрета подкачки может перевести группу в swap вместо завершения процесса; эти детали рассматриваются в темах 3 и 5.

Итоги темы

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

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

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

Помимо аппаратной виртуализации, ядро операционной системы предоставляет собственные механизмы изоляции — пространства имён и группы управления ресурсами, — которые позволяют разграничивать процессы и ограничивать их потребление ресурсов на программном уровне. Эти механизмы обеспечивают менее строгую, но значительно более легковесную изоляцию по сравнению с гипервизором и составляют технологическую основу для подходов, рассматриваемых в последующих темах курса.

Между этими полюсами находятся промежуточные решения. Двухуровневая трансляция адресов, паравиртуализированные устройства virtio и прямой доступ к устройствам через IOMMU и SR-IOV сократили накладные расходы ВМ до уровня, при котором микровиртуальные машины вроде Firecracker запускаются за доли секунды и изолируют отдельные функции и контейнеры собственным ядром. Следующая тема рассматривает противоположный полюс — контейнер, — и показывает, как Docker собирает пространства имён и cgroups в единый объект.

Литература

1. Popek G. J., Goldberg R. P. Formal Requirements for Virtualizable Third Generation Architectures. — Communications of the ACM, 1974, Vol. 17, No. 7, С. 412–421, DOI: 10.1145/361011.361073.
2. Adams K., Agesen O. A Comparison of Software and Hardware Techniques for x86 Virtualization. — Proceedings of ASPLOS XII, 2006, С. 2–13, DOI: 10.1145/1168857.1168860.
3. Barham P., Dragovic B., Fraser K., Hand S., Harris T., Ho A., Neugebauer R., Pratt I., Warfield A. Xen and the Art of Virtualization. — Proceedings of the 19th ACM Symposium on Operating Systems Principles (SOSP '03), 2003, С. 164–177, DOI: 10.1145/945445.945462.
4. Kivity A., Kamay Y., Laor D., Lublin U., Liguori A. kvm: the Linux Virtual Machine Monitor. — Proceedings of the Linux Symposium, Ottawa, 2007, Vol. 1, С. 225–230.
5. Russell R. virtio: Towards a De-Facto Standard for Virtual I/O Devices. — ACM SIGOPS Operating Systems Review, 2008, Vol. 42, No. 5, С. 95–103, DOI: 10.1145/1400097.1400108.
6. Bhargava R., Serebrin B., Spadini F., Manne S. Accelerating Two-Dimensional Page Walks for Virtualized Systems. — Proceedings of ASPLOS XIII, 2008.
7. Ben-Yehuda M., Day M. D., Dubitzky Z., Factor M., Har'El N., Gordon A., Liguori A., Wasserman O., Yassour B.-A. The Turtles Project: Design and Implementation of Nested Virtualization. — Proceedings of the 9th USENIX Symposium on Operating Systems Design and Implementation (OSDI '10), 2010.
8. Agache A., Brooker M., Florescu A., Iordache A., Liguori A., Neugebauer R., Piwonka P., Popa D.-M. Firecracker: Lightweight Virtualization for Serverless Applications. — Proceedings of the 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI '20), 2020, С. 419–434.
9. Oracle VM VirtualBox User Guide. Virtual Networking. — https://www.virtualbox.org/manual/ (дата обращения: 22.10.2026).
10. Linux man-pages. namespaces(7) — overview of Linux namespaces. — https://man7.org/linux/man-pages/man7/namespaces.7.html (дата обращения: 22.10.2026).
11. Linux man-pages. cgroups(7) — Linux control groups. — https://man7.org/linux/man-pages/man7/cgroups.7.html (дата обращения: 22.10.2026).
12. The Linux Kernel Documentation. Control Group v2. — https://docs.kernel.org/admin-guide/cgroup-v2.html (дата обращения: 22.10.2026).

Дополнительные материалы

Вопросы для самопроверки

1. Какие задачи решает абстрагирование физических ресурсов и почему без программной управляемости виртуальных машин облачная модель была бы нереализуема?
2. Чем гипервизор первого типа отличается от гипервизора второго типа? Почему классификация KVM в литературе не единодушна?
3. Зачем гипервизору второго типа, например VirtualBox, нужен собственный модуль ядра?
4. Сформулируйте условие Попека — Голдберга. Почему архитектура x86 до середины 2000-х годов ему не удовлетворяла? Приведите пример инструкции.
5. Как работает бинарная трансляция и чем она отличается от паравиртуализации?
6. Почему первые реализации VT-x уступали по скорости зрелой бинарной трансляции и какое нововведение закрыло этот разрыв?
7. Какие три уровня адресов существуют в виртуальной машине и как двухуровневая трансляция (EPT/NPT) избавляет от теневых таблиц страниц? Почему промах TLB в ВМ дороже, чем без виртуализации?
8. Как устроено обращение гостя к устройству virtio и почему оно дешевле эмуляции реального сетевого адаптера?
9. Какую задачу решает IOMMU при передаче устройства в ВМ и что даёт SR-IOV? Какую гибкость при этом приходится терять?
10. Что такое вложенная виртуализация и почему её избегают для промышленных нагрузок? Как по выводу lscpu определить, что система сама работает в ВМ?
11. Что фиксирует снимок состояния работающей и выключенной виртуальной машины? Почему снимок создаётся за секунды и почему он не является резервной копией?
12. Сравните режимы сети NAT, host-only и bridged в VirtualBox: откуда и куда доступна ВМ в каждом из них?
13. Какие типы пространств имён Linux существуют и какими флагами clone/unshare они создаются? Почему при unshare --pid нужен ключ --fork?
14. Чем cgroups v2 отличается от v1? Почему cgroups не ограничивают пропускную способность сети и от чего защищает контроллер pids?
15. Как Firecracker, Kata Containers и gVisor размывают границу между виртуальной машиной и контейнером?

Глоссарий темы

Шпаргалка по инструментам

# Аппаратная поддержка виртуализации и признак работы внутри ВМ
lscpu | grep -i -E 'virtualization|hypervisor'
grep -o -w -E 'vmx|svm|ept|npt' /proc/cpuinfo | sort | uniq -c   # VT-x, AMD-V, SLAT
systemd-detect-virt                                             # none, kvm, oracle, microsoft, wsl...

# Пространства имён
ls -l /proc/self/ns                                   # номера пространств текущего процесса
unshare -r --pid --fork --mount-proc ps -o pid,user,cmd   # новый PID namespace без sudo
unshare -r --uts sh -c 'hostname demo; hostname'      # своё имя хоста
unshare -r sh -c 'cat /proc/self/uid_map'             # отображение UID в user namespace

# cgroups
stat -fc %T /sys/fs/cgroup                # cgroup2fs — версия 2
cat /sys/fs/cgroup/cgroup.controllers     # доступные контроллеры
cat /proc/self/cgroup                     # группа текущего процесса

# Образы дисков (QEMU)
qemu-img info disk.qcow2                              # виртуальный и фактический размер
qemu-img convert -p -f vdi -O qcow2 disk.vdi disk.qcow2

# VirtualBox из командной строки
VBoxManage list vms
VBoxManage startvm lab-vm-01 --type headless
VBoxManage snapshot lab-vm-01 take initial-state
VBoxManage controlvm lab-vm-01 poweroff
VBoxManage snapshot lab-vm-01 restore initial-state
VBoxManage list hostonlyifs                           # адреса host-only сетей

# Время загрузки (внутри гостя)
systemd-analyze                  # firmware/loader/kernel/userspace
systemd-analyze blame | head     # самые медленные службы

Что почитать и посмотреть

1. Popek G. J., Goldberg R. P. Formal Requirements for Virtualizable Third Generation Architectures — https://doi.org/10.1145/361011.361073. Короткая статья 1974 года, в которой сформулировано условие виртуализируемости; полезно увидеть, насколько просто оно формулируется.
2. Adams K., Agesen O. A Comparison of Software and Hardware Techniques for x86 Virtualization — https://doi.org/10.1145/1168857.1168860. Инженеры VMware сравнивают бинарную трансляцию с первым поколением VT-x и объясняют, почему аппаратное решение поначалу проигрывало.
3. Barham P. et al. Xen and the Art of Virtualization — https://doi.org/10.1145/945445.945462. Классическая статья о паравиртуализации и устройстве Xen.
4. Agache A. et al. Firecracker: Lightweight Virtualization for Serverless Applications — https://www.usenix.org/conference/nsdi20/presentation/agache. Как AWS строит microVM для Lambda и Fargate и какие компромиссы для этого приняты; на странице есть видео доклада.
5. Kerrisk M. Namespaces in operation — серия статей LWN 2013 года, начало: https://lwn.net/Articles/531114/. Подробный разбор пространств имён с примерами программ на C от автора man-страниц Linux.
6. The Linux Kernel Documentation. Control Group v2 — https://docs.kernel.org/admin-guide/cgroup-v2.html. Полное описание интерфейса cgroups v2 и всех контроллеров.
7. Oracle VM VirtualBox User Guide — https://www.virtualbox.org/manual/. Глава о виртуальных сетях подробно описывает режимы NAT, host-only, bridged и internal.
8. gVisor Documentation — https://gvisor.dev/docs/. Архитектура песочницы системных вызовов и сравнение с ВМ и обычными контейнерами.
9. Kata Containers — https://katacontainers.io/. Описание проекта контейнеров в лёгких ВМ, совместимых с OCI и Kubernetes.

Углубление (по желанию)

CP-40 и VM/370: виртуальные машины до x86

Первые виртуальные машины появились в IBM в середине 1960-х годов. Исследовательская система CP-40 (1967) на модифицированном мэйнфрейме System/360 запускала для каждого пользователя отдельную копию однопользовательской системы CMS, полностью изолированную от других. Её преемник VM/370 (1972) стал коммерческим продуктом, а архитектура System/370 изначально удовлетворяла условию, которое позже формализовали Попек и Голдберг. Идеи этой линии — гипервизор как управляющая программа, гостевые системы, не знающие о соседях, паравиртуализированные «диагностические» вызовы — почти без изменений вернулись в мир x86 спустя тридцать лет.

Spectre, L1TF и пределы аппаратной изоляции

Граница гипервизора считается более строгой, чем граница пространств имён, но и она не абсолютна. Уязвимости класса спекулятивного исполнения, опубликованные в 2018 году (Spectre, Meltdown, затем L1 Terminal Fault, известная также как Foreshadow), позволили гостю при определённых условиях читать данные из кэшей процессора, принадлежащие гипервизору или другой ВМ на соседнем логическом ядре. Исправления потребовали очистки кэша L1 при входе в гостя, а облачные поставщики стали размещать ВМ разных клиентов на разных физических ядрах или отключать одновременную многопоточность. Этот эпизод показывает, что изоляция всегда опирается на модель угроз и на исправность нижележащего уровня, включая сам процессор.

Лабораторная работа 2. Виртуализация как основа облачной инфраструктуры

• Раздел курса: тема 2 «Виртуализация как основа облачной инфраструктуры»

Введение

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

Работа предваряет лабораторную работу 3, в которой те же вопросы задаются контейнеру. Поэтому особенно важны наблюдения, которые потом можно будет сравнить: видимость процессов с хоста, время запуска среды, накладные расходы на память.

Работа состоит из семи частей. Базовая часть — части 1–5 и 7: создание ВМ, ресурсная модель, изоляция, снимки, замеры времени загрузки и сравнительный анализ. Часть 6 («сломать и починить» сетевую связность) выполняется по желанию.

Цель работы

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

После выполнения работы можно будет:

• создать ВМ с заданными vCPU, памятью, диском и двумя сетевыми адаптерами (NAT и host-only) и установить в неё Ubuntu Server;
• сопоставить ресурсы, которые видит гость (nproc, free, lsblk, lscpu), с заданной конфигурацией и объяснить расхождения;
• показать командами на хосте и в госте, что процессы гостя не видны хосту, а нагрузка гостя проявляется как нагрузка процесса гипервизора;
• определить адрес host-only интерфейса, подключиться к ВМ с хоста и объяснить, почему к ней нельзя обратиться из локальной сети;
• предсказать и проверить результат восстановления снимка работающей ВМ;
• измерить время загрузки ВМ по методике (секундомер по фазам и systemd-analyze) и сравнить его со временем запуска процесса на хосте;
• найти и устранить причину потери сетевой связности между хостом и ВМ.

Теоретический минимум

Необходимый материал изложен в теме 2: разделы «Гипервизоры и типы виртуализации», «Виртуализация памяти и ввода-вывода», «Ресурсная модель виртуальной машины» (в том числе таблица сетевых режимов VirtualBox и подраздел о снимках) и подраздел «Типичные ошибки интерпретации».

Учебный стенд:

 хост (Windows / macOS / Linux)
 ├── процесс VirtualBoxVM (или VBoxHeadless) — одна ВМ lab-vm-01
 │     ├── адаптер 1: NAT        → гость 10.0.2.15, выход в интернет через хост
 │     └── адаптер 2: host-only  → гость 192.168.56.101 (DHCP), хост 192.168.56.1
 └── интерфейс хоста vboxnet0 (на Windows — «VirtualBox Host-Only Ethernet Adapter»)

Команды, которые понадобятся в работе:

Утилита VBoxManage устанавливается вместе с VirtualBox; на Windows она находится в C:\Program Files\Oracle\VirtualBox\ и может потребовать добавления этого каталога в PATH. Любое действие работы можно выполнить и в графическом интерфейсе.

Перечень оснащения

• Хост: Ubuntu 24.04, Windows 11 или macOS 14 и новее; процессор с аппаратной виртуализацией (Intel VT-x или AMD-V), включённой в BIOS/UEFI. Проверка на Linux — lscpu | grep -i virtualization, на Windows — строка «Виртуализация» на вкладке «Производительность → ЦП» диспетчера задач.
• Oracle VirtualBox 7.1 или новее с официального сайта virtualbox.org; проверка — VBoxManage --version.
• Образ Ubuntu Server 24.04 LTS с ubuntu.com/download/server: для процессоров x86-64 — ubuntu-24.04.x-live-server-amd64.iso, для компьютеров Mac с процессором Apple — ubuntu-24.04.x-live-server-arm64.iso.
• Ресурсы: 2 свободных ядра, 3 ГБ свободной памяти, 25 ГБ на диске; секундомер (подойдёт телефон).

Особенности платформ, которые следует проверить до начала:

• Mac с процессором Apple (M1–M4). VirtualBox с версии 7.1 работает на таких компьютерах, но запускает только гостевые системы для архитектуры ARM. Образ amd64 не загрузится: процессор не умеет исполнять инструкции x86, а VirtualBox их не эмулирует. Используется образ arm64; имена сетевых интерфейсов в госте могут отличаться от enp0s3/enp0s8 — их следует брать из вывода ip -br link. Альтернатива — гипервизор UTM; тогда настройки сети выполняются по его документации, а смысл экспериментов не меняется.
• Windows с включёнными Hyper-V, WSL2, Docker Desktop или «Изоляцией ядра» (Virtualization-Based Security). В этом случае аппаратной виртуализацией владеет Hyper-V, и VirtualBox работает поверх Windows Hypervisor Platform: в строке состояния окна ВМ вместо значка «V» отображается зелёная черепаха, а загрузка и ввод-вывод заметно медленнее. Работа выполнима и в этом режиме, но замеры части 5 нужно сопроводить пометкой о нём. Отключение Hyper-V (bcdedit /set hypervisorlaunchtype off и перезагрузка) ускоряет VirtualBox, но выключает WSL2 и Docker Desktop, которые нужны в лабораторной работе 3; вернуть их можно командой bcdedit /set hypervisorlaunchtype auto.
• Linux с загруженным модулем KVM. Начиная с ядра 6.12 модуль kvm_intel или kvm_amd по умолчанию включает VT-x/AMD-V сразу при загрузке, и VirtualBox сообщает об ошибке VERR_VMX_IN_VMX_ROOT_MODE или аналогичной. Решение — выгрузить модуль (sudo modprobe -r kvm_intel kvm или kvm_amd kvm) на время работы. На штатном ядре Ubuntu 24.04 (6.8) эта проблема обычно не возникает.

Порядок выполнения работы

Части выполняются по порядку, поскольку каждая опирается на состояние ВМ, полученное в предыдущей. Команды с пометкой «гость» выполняются внутри ВМ (в её окне или по SSH), с пометкой «хост» — в терминале хоста. В начале каждой части, где это указано, до выполнения команд записывается предсказание результата.

Параметры ВМ задаются вариантом; номер выбирается произвольно. Далее в тексте используется вариант 1 (lab-vm-01); при другом варианте имена и числа подставляются из таблицы.

Удаление стенда после работы (хост) — ВМ и все её диски и снимки удаляются безвозвратно:

VBoxManage controlvm lab-vm-01 poweroff
VBoxManage unregistervm lab-vm-01 --delete

Часть 1. Создание и настройка виртуальной машины

Задание

1. Откройте VirtualBox и создайте новую виртуальную машину. Задайте следующие параметры конфигурации (для своего варианта):

   • имя: lab-vm-01;
   • тип и версия ОС: Linux, Ubuntu (64-bit), на Mac с процессором Apple — Ubuntu (ARM 64-bit);
   • количество виртуальных процессоров (vCPU): 2;
   • объём оперативной памяти: 2048 МБ;
   • дисковый образ: динамически расширяемый, размер 20 ГБ, формат VDI.

   Если мастер создания предлагает «автоматическую установку» (Unattended Installation), отключите её, чтобы пройти установку вручную.

2. В настройках созданной виртуальной машины перейдите в раздел «Сеть» и настройте два сетевых адаптера:

   • адаптер 1: режим NAT (для доступа в интернет из гостевой системы);
   • адаптер 2: режим «Виртуальный адаптер хоста» (Host-only Adapter) с сетью vboxnet0 (на Windows — «VirtualBox Host-Only Ethernet Adapter») — для связи между хостом и гостевой системой.

   Если в списке нет ни одной host-only сети, создайте её: «Файл → Инструменты → Менеджер сетей», вкладка «Сети виртуальных адаптеров хоста», кнопка «Создать», DHCP-сервер включён.

3. Подключите ISO-образ Ubuntu Server 24.04 LTS к виртуальному приводу и запустите виртуальную машину. Выполните установку операционной системы со следующими параметрами:

   • имя сервера (hostname): lab-vm-01;
   • имя пользователя: student;
   • установка OpenSSH Server: включена.

   На экране настройки сети установщика должны появиться два интерфейса, оба с адресами от DHCP; запишите эти адреса.

4. После завершения установки и перезагрузки войдите в систему и запишите в журнал полное имя хоста и версию ядра Linux (hostnamectl, uname -r).

5. Создайте снимок состояния работающей ВМ с именем initial-state — в меню «Машина → Сделать снимок» или командой на хосте:

   VBoxManage snapshot lab-vm-01 take initial-state --description "после установки"
   VBoxManage snapshot lab-vm-01 list
   

   Засеките, сколько времени заняло создание снимка, и запишите результат.

Что должно получиться

Работающая ВМ с заданными параметрами и снимок. Образец вывода в госте и на хосте:

6.8.0-85-generic
   Name: initial-state (UUID: 3c0b6a5e-...) *

Первая строка — вывод uname -r в госте, вторая — VBoxManage snapshot lab-vm-01 list на хосте; звёздочка отмечает текущий снимок.

Номер сборки ядра зависит от того, какая точечная версия образа использовалась и были ли установлены обновления. Снимок работающей машины создаётся за несколько секунд: память гостя (2 ГБ) записывается в файл состояния, а диск не копируется, а «замораживается». Если установщик не получил адрес на втором интерфейсе, вероятнее всего, у host-only сети выключен DHCP-сервер; это будет исправлено в части 6.

Часть 2. Исследование ресурсной модели

Задание

1. Запишите предсказание: сколько процессоров, сколько памяти и какой объём корневой файловой системы покажут команды ниже? Совпадёт ли объём / с размером диска?

2. Внутри ВМ (гость) выполните команды и сохраните вывод в журнал:

   # Количество доступных процессорных ядер
   nproc
   
   # Подробная информация о процессоре и признаки гипервизора
   lscpu | grep -E 'Model name|^CPU\(s\)|Thread|Socket|Hypervisor|Virtualization'
   
   # Объём оперативной памяти
   free -h
   
   # Дисковые устройства и разделы
   lsblk
   
   # Использование дискового пространства
   df -h /
   
   # Сетевые интерфейсы и адреса
   ip -br address show
   
   # Тип виртуализации, обнаруженный systemd
   systemd-detect-virt
   
   # Версия ядра и имя хоста
   uname -a
   hostname
   

3. Сопоставьте полученные данные с параметрами, заданными при создании ВМ. Объясните, почему значения отличаются от заданных: почему free показывает меньше 2 ГиБ, почему объём / меньше 20 ГБ.

4. Объясните, что означает строка Hypervisor vendor в выводе lscpu и почему в ВМ VirtualBox там может быть указан не Oracle.

Что должно получиться

Образец вывода (сокращён):

2
Model name:                           AMD Ryzen 5 2600 Six-Core Processor
CPU(s):                               2
Hypervisor vendor:                    KVM
Virtualization type:                  full
               total        used        free      shared  buff/cache   available
Mem:           1.9Gi       318Mi       1.2Gi       1.1Mi       468Mi       1.6Gi
...
NAME                      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda                         8:0    0   20G  0 disk
├─sda1                      8:1    0    1M  0 part
├─sda2                      8:2    0  1.8G  0 part /boot
└─sda3                      8:3    0 18.2G  0 part
  └─ubuntu--vg-ubuntu--lv 252:0    0   10G  0 lvm  /
Filesystem                         Size  Used Avail Use% Mounted on
/dev/mapper/ubuntu--vg-ubuntu--lv  9.8G  4.6G  4.7G  50% /
lo               UNKNOWN        127.0.0.1/8 ::1/128
enp0s3           UP             10.0.2.15/24 metric 100 fe80::a00:27ff:fe4e:66a1/64
enp0s8           UP             192.168.56.101/24 metric 100 fe80::a00:27ff:fe1d:2b4c/64
oracle

Гость видит модель физического процессора хоста, но только два логических процессора. Память меньше заданной, потому что часть зарезервирована ядром и прошивкой, а free показывает объём, доступный ядру; к тому же единицы Gi двоичные. Корневой том меньше диска по двум причинам: часть диска занимают раздел /boot и служебные структуры, а установщик Ubuntu Server по умолчанию отдаёт логическому тому LVM лишь часть группы томов (свободное место можно добавить командой lvextend). systemd-detect-virt определяет VirtualBox по данным прошивки и печатает oracle, а lscpu сообщает KVM, потому что VirtualBox по умолчанию предоставляет Linux-гостям паравиртуализированный интерфейс, совместимый с KVM (точные часы, ускорение прерываний). Это наглядный пример паравиртуализации без изменения ядра гостя. Строки Virtualization: AMD-V (или VT-x) в госте нет, если вложенная виртуализация не включена в настройках ВМ.

Часть 3. Исследование изоляции

Задание

1. Запишите предсказание: увидит ли хост процессы, запущенные внутри ВМ? Что покажет top на хосте, если в госте загрузить процессор?

2. В госте запустите процесс с узнаваемым именем: sleep 777 &. На хосте выполните поиск этого процесса и процесса гипервизора (на Windows — диспетчер задач, вкладка «Подробности»):

   # хост: Linux или macOS
   ps aux | grep -E 'sleep 777|VirtualBoxVM|VBoxHeadless' | grep -v grep
   

3. В госте запустите процесс с высокой нагрузкой на процессор (yes > /dev/null &) и посмотрите на хосте top -o %CPU (на macOS — top -o cpu). Определите, какой процесс хоста стал потреблять процессор и сколько. Завершите оба процесса в госте командой kill %1 %2.

4. Сравните объём памяти, занятый процессом ВМ на хосте (ps -o rss,comm -C VirtualBoxVM на Linux, столбец «Память» диспетчера задач на Windows), с объёмом, который видит гость (free -h).

5. Проверьте изоляцию файловой системы: создайте в госте файл ~/snapshot-test.txt командой echo "test" > ~/snapshot-test.txt и попробуйте найти его на хосте поиском по имени файла (find ~ -name snapshot-test.txt 2>/dev/null). Объясните результат, указав, где физически находятся данные файла.

6. Проверьте сетевую изоляцию:

   • из ВМ выполните ping -c 3 8.8.8.8 и убедитесь, что доступ в интернет есть (через адаптер NAT);

   • определите адрес host-only интерфейса в госте и адрес хоста в той же сети:

     # гость
     ip -4 -br address show enp0s8
     # хост
     VBoxManage list hostonlyifs | grep -E 'Name|IPAddress'
     

   • с хоста выполните ping -c 3 192.168.56.101 (адрес из предыдущего шага) и подключитесь к ВМ по SSH: ssh student@192.168.56.101;

   • предскажите и проверьте: ответит ли с хоста ping -c 3 10.0.2.15 (адрес NAT-интерфейса гостя)?

   • если есть второй компьютер в той же локальной сети, попробуйте обратиться с него к адресу host-only интерфейса ВМ. Зафиксируйте результат и объясните поведение.

Что должно получиться

Образец вывода на хосте Linux (сокращён):

noum   41213 103  14.2 4120544 2321408 ?  Sl  10:02  3:41 /usr/lib/virtualbox/VirtualBoxVM --comment lab-vm-01 --startvm 5b1e... --no-startvm-errormsgbox

Процесса sleep 777 на хосте нет: у гостя собственное ядро и собственная таблица процессов, а хост видит только процесс гипервизора. После запуска yes процесс VirtualBoxVM потребляет около 100 % одного ядра хоста — это поток, исполняющий виртуальный процессор гостя. Резидентная память процесса ВМ близка к объёму памяти гостя плюс накладные расходы гипервизора; она может быть и меньше заданной, если гость ещё не обращался ко всей своей памяти. Файл на хосте не находится: он лежит внутри файловой системы ext4 гостя, которая, в свою очередь, хранится в файле lab-vm-01.vdi (или в разностном файле снимка); хост видит только этот файл образа целиком. ping на 10.0.2.15 с хоста не отвечает: этот адрес существует только внутри NAT-сети, которую VirtualBox создаёт для данной ВМ. Обращение к host-only адресу с другого компьютера тоже не проходит: сеть 192.168.56.0/24 существует только между хостом и его ВМ и не маршрутизируется в физическую сеть.

Часть 4. Снимки состояния

Задание

1. Убедитесь, что файл ~/snapshot-test.txt из части 3 существует. Запустите в госте sleep 3000 & и запишите вывод uptime.

2. Запишите предсказание: после восстановления снимка initial-state будет ли существовать файл ~/snapshot-test.txt? Будет ли работать процесс sleep 3000? Придётся ли загружать систему заново, и что покажет uptime?

3. Выключите ВМ и восстановите её из снимка initial-state (хост):

   VBoxManage controlvm lab-vm-01 poweroff
   VBoxManage snapshot lab-vm-01 restore initial-state
   VBoxManage showvminfo lab-vm-01 --machinereadable | grep -E '^VMState='
   VBoxManage startvm lab-vm-01
   

4. В госте проверьте наличие файла, процесса sleep (pgrep -a sleep) и вывод uptime. Сравните с предсказанием.

5. Найдите на хосте каталог ВМ (по умолчанию ~/VirtualBox VMs/lab-vm-01) и посмотрите содержимое подкаталога Snapshots. Объясните, что находится в каждом файле.

Что должно получиться

После восстановления VMState="saved": снимок был сделан с работающей машины и содержит её память. При запуске ВМ не загружается заново, а продолжает работу с момента снимка: uptime показывает небольшое время работы, отсчитанное от загрузки перед снимком, процесса sleep 3000 нет (он был запущен после снимка), файла ~/snapshot-test.txt нет (он был записан в разностный диск, который удалён при восстановлении). В каталоге Snapshots находятся файл состояния памяти *.sav и разностный образ {UUID}.vdi, в который пишутся все изменения диска после снимка; его размер растёт по мере работы. Если бы снимок был сделан с выключенной ВМ, после восстановления она находилась бы в состоянии poweroff и загружалась заново.

Часть 5. Замер времени загрузки

Цель части — получить воспроизводимую оценку времени загрузки ВМ и разложить её на фазы.

Задание

1. Запишите предсказание: сколько секунд проходит от запуска ВМ до приглашения login:? Во сколько раз это больше, чем время запуска небольшой программы на хосте?

2. Методика замера секундомером. Выключите ВМ (в госте sudo poweroff). Включите секундомер одновременно с нажатием кнопки «Запустить» (или с выполнением VBoxManage startvm lab-vm-01) и фиксируйте промежуточные отметки: t_1 — появление меню или сообщений загрузчика GRUB, t_2 — появление приглашения login:. Повторите замер три раза и вычислите среднее. Учтите, что после восстановления снимка ВМ находится в состоянии saved; перед первым замером её нужно выключить «по-честному», то есть загрузить и затем выполнить sudo poweroff.

3. Методика замера изнутри. После каждой загрузки выполните в госте:

   systemd-analyze
   systemd-analyze blame | head -5
   systemd-analyze critical-chain
   

   Первая команда разделяет время на работу ядра (от передачи управления ядру до запуска systemd) и пользовательского пространства (от запуска systemd до достижения цели multi-user.target); время прошивки и загрузчика ВМ с BIOS она не показывает. Вторая выводит службы, дольше всего стартовавшие, третья — цепочку зависимостей, определившую итоговое время.

4. Для сравнения измерьте время запуска процесса на хосте. Команда time echo "hello" для этого не годится: echo — встроенная команда оболочки, и её «запуск» не создаёт процесса. Используйте внешние программы:

   # хост
   time /bin/true
   time python3 -c 'pass'
   

5. Измерьте время «пробуждения» из сохранённого состояния: на хосте выполните VBoxManage controlvm lab-vm-01 savestate, затем запустите ВМ и засеките время до появления работоспособной консоли.

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

Что должно получиться

Образец вывода systemd-analyze в госте (значения зависят от хоста):

Startup finished in 2.903s (kernel) + 13.874s (userspace) = 16.777s
multi-user.target reached after 13.842s in userspace.

6.122s systemd-networkd-wait-online.service
2.311s snapd.seeded.service
1.874s cloud-init-local.service
...

Типичный порядок величин на современном ноутбуке: t_2 — 20–40 секунд, из них несколько секунд — прошивка и GRUB (включая таймаут меню), 2–4 секунды — ядро, 10–20 секунд — службы. Заметную долю пользовательского времени часто занимает ожидание сети systemd-networkd-wait-online, которое не связано с виртуализацией. Пробуждение из сохранённого состояния занимает единицы секунд, поскольку загрузки нет: память гостя считывается из файла. Запуск python3 на хосте занимает десятки миллисекунд, /bin/true — около миллисекунды, то есть на три–четыре порядка меньше загрузки ВМ. На Windows с включённым Hyper-V все времена ВМ будут заметно больше; это ожидаемый результат, и он должен быть отмечен в журнале.

Часть 6. Потеря связности: сломать и починить

Эта часть выполняется по желанию.

Задание

1. Убедитесь, что с хоста работает ping -c 2 192.168.56.101. Затем в госте (в окне ВМ, а не по SSH — соединение пропадёт) «сломайте» host-only интерфейс:

   sudo ip link set enp0s8 down
   

2. Предскажите, какие проверки из части 3 перестанут работать, и проверьте: ping с хоста на host-only адрес, ping 8.8.8.8 из гостя, SSH.

3. Проведите диагностику так, как если бы причина была неизвестна: в госте ip -br link, ip -4 -br address show, ip route; на хосте — состояние интерфейса vboxnet0 (ip -br address show vboxnet0 на Linux) и настройки адаптера 2 ВМ (VBoxManage showvminfo lab-vm-01 | grep -i 'NIC 2'). Запишите, по какому признаку найдена причина.

4. Восстановите связность: sudo ip link set enp0s8 up. Если после этого интерфейс не получил адрес (например, установщик не настроил его), добавьте его в конфигурацию netplan и примените:

   # /etc/netplan/60-hostonly.yaml
   network:
     version: 2
     ethernets:
       enp0s8:
         dhcp4: true
   

   sudo chmod 600 /etc/netplan/60-hostonly.yaml
   sudo netplan apply
   ip -4 -br address show enp0s8
   

5. Второй вариант поломки — на стороне гипервизора: при выключенной ВМ переключите адаптер 2 в режим «Не подключён» (VBoxManage modifyvm lab-vm-01 --nic2 null), загрузите ВМ и повторите диагностику. Чем отличается картина в ip -br link от первого случая? Верните режим host-only: VBoxManage modifyvm lab-vm-01 --nic2 hostonly --hostonlyadapter2 vboxnet0 (на Windows — имя адаптера из VBoxManage list hostonlyifs).

Что должно получиться

В первом случае интерфейс enp0s8 в госте находится в состоянии DOWN, адреса на нём нет, связь с хостом по host-only пропадает, а выход в интернет через NAT продолжает работать — изоляция двух адаптеров видна прямо в результате. Во втором случае гость видит интерфейс в состоянии UP или NO-CARRIER, но без несущей: «кабель» виртуального адаптера отключён на стороне гипервизора, и никакие настройки в госте связь не вернут. Умение различать эти два случая — причина в госте или в конфигурации ВМ — и есть цель части.

Часть 7. Сравнительный анализ виртуальной машины и физического хоста

Задание

1. Заполните сравнительную таблицу на основании наблюдений частей 1–5 и материала темы 2. Оценку давайте применительно к конкретной среде, которая использовалась в работе, а не в общем виде.

2. На основании таблицы и собственных наблюдений ответьте на вопросы:

   • Какие задачи разумно решать с помощью виртуальной машины, а не на физическом хосте? Обоснуйте выбор.
   • Какие ограничения виртуализации на базе гипервизора второго типа проявились в ходе работы? Какие из них исчезли бы при использовании гипервизора первого типа, а какие (время загрузки ОС, накладные расходы на гостевое ядро) остались бы?
   • Какую роль снимки состояния играют в контексте облачных вычислений и почему они не заменяют резервное копирование?

Что должно получиться

Заполненная таблица, в которой строки «время запуска» и «видимость процессов» содержат числа и наблюдения из работы, а не общие слова, и ответы на вопросы объёмом до страницы. Эта таблица понадобится в лабораторной работе 3, где к ней добавится столбец «Контейнер».

Журнал работы

Журнал ведётся для себя: для каждого задания с предсказанием записываются предсказание, выполненная команда, фактический вывод (достаточно значимых строк) и объяснение расхождения. Для замеров части 5 записываются условия: модель процессора хоста, ОС хоста, версия VirtualBox, режим работы (значок «V» или черепаха на Windows). Эти записи понадобятся для сравнения с контейнерами в следующей работе.

Контрольные вопросы

1. В чём состоит принципиальное различие между гипервизором первого и второго типа? Почему VirtualBox, у которого есть собственный драйвер ядра, всё равно относят ко второму типу?
2. Каким образом гипервизор обеспечивает изоляцию виртуальных машин от хостовой системы и друг от друга? Что произойдёт, если гостевая ОС попытается выполнить привилегированную инструкцию?
3. Почему процессы гостевой системы не видны на хосте, а нагрузка гостя видна? Чем это отличается от контейнера?
4. Объясните, что такое переподписка (overcommitment) процессорных ресурсов. При каких условиях она допустима и когда становится проблемой?
5. Чем динамически расширяемый дисковый образ (thin provisioning) отличается от образа фиксированного размера? Почему в части 2 объём корневой файловой системы оказался меньше размера диска и связано ли это с динамическим выделением?
6. Почему после восстановления снимка работающей ВМ система не загружается заново, а после восстановления снимка выключенной — загружается? Где физически хранятся изменения диска, сделанные после снимка?
7. Почему снимки не следует считать полноценной заменой резервного копирования?
8. Почему с хоста можно обратиться к host-only адресу ВМ, но нельзя к её NAT-адресу 10.0.2.15? Какой режим сети нужен, чтобы ВМ была доступна из локальной сети?
9. Почему команда time echo "hello" не измеряет время запуска процесса? Из каких фаз складывается время загрузки ВМ и какие из них исчезают при пробуждении из сохранённого состояния?
10. Почему образ Ubuntu для архитектуры amd64 не загружается в VirtualBox на Mac с процессором Apple, хотя гипервизор установлен и работает?
11. В каких сценариях виртуальные машины предпочтительнее контейнеров? Ответ обоснуйте, опираясь на различия в механизмах изоляции двух подходов.