Виртуализация и управление операционными системами
Зачем ВМ, снапшоты, Docker на старом ПК — в главе про Home Lab.
Ниже — подробная теория гипервизоров и сравнение продуктов.
Программы в двух словах
| Продукт | Тип | Power user сценарий |
|---|---|---|
| VirtualBox | Hosted | Ubuntu в ВМ на Windows |
| Hyper-V | Встроенный гипервизор Windows (Pro+) | Windows Sandbox, Linux VM |
| VMware Workstation Player | Hosted | Альтернатива VBox |
| Docker Desktop | Контейнеры | Nextcloud, Pi-hole локально |
| WSL 2 | Интеграция Linux | Dev, bash-скрипты |
| Proxmox VE | Bare metal | Несколько ВМ 24/7 |
| QEMU/KVM | Linux | Сервер без GUI |
winget install Oracle.VirtualBox, winget install Docker.DockerDesktop.
Быстрый старт WSL и Docker
wsl --install
wsl -l -v
docker run -d --name hello -p 8080:80 nginx:alpine
# http://localhost:8080
Сеть ВМ (VirtualBox): NAT — гость выходит в интернет, хост к гостю по port forwarding; Bridge — гость как отдельный IP в LAN (удобно для Home Lab); Host-only — только связь с хостом.
Снапшот: сделать → эксперимент → Restore при поломке → удалить снапшот, когда всё стабильно.
Четыре модели развёртывания
Снизу вверх приложение опирается на цепочку: сеть → физический сервер → слой управления → среда исполнения → программы. В индустрии выделяют четыре типичные схемы — от установки прямо на "железо" до контейнеров внутри облачных ВМ. Различаются уровень изоляции, накладные расходы и кто управляет жизненным циклом (ОС, гипервизор или container engine).
Traditional — bare metal
Стек: сеть → физический сервер → одна ОС → несколько приложений.
Приложения делят одну операционную систему. Изоляция — на уровне процессов и прав доступа: сбой или уязвимость в одном сервисе может затронуть соседей на том же хосте. Зато нет гипервизора и контейнерного runtime — минимальные потери на абстракцию, полный доступ к железу. Так работают многие высоконагруженные СУБД, специализированные комплексы и часть legacy на выделенных серверах. В DevOps этот вариант описан как развёртывание на физических серверах.
Virtualized — ВМ на гипервизоре
Стек: сеть → физический сервер → гипервизор (эмулирует железо для гостей) → несколько ВМ, в каждой полная гостевая ОС и свои приложения.
Это виртуализация на уровне "железа" (hardware-level) — у каждой ВМ свой набор виртуальных CPU, RAM и дисков, свои драйверы и ядро. Гипервизор (KVM, Hyper-V, VMware ESXi, Xen) планирует доступ к ресурсам хоста. Изоляция сильная — гостевые ядра разделены; цена — тяжёлые образы (полная ОС на каждую ВМ) и более долгий старт. Подробнее — ИТ-инфраструктура, хост и гости.
Containerized — виртуализация на уровне ОС
Стек: сеть → физический сервер → хостовая ОС с общим ядром → container engine (Docker, containerd, Podman) → изолированные контейнеры.
Контейнеры не поднимают вторую ОС: они используют ядро хоста, а изоляцию дают namespaces и cgroups (Linux) или аналоги в Windows. Это OS-level virtualization, изоляция процессов, а не отдельных ядер. Образ легче ВМ, старт быстрее; компромисс — общее ядро и общий драйверный стек хоста. Теория — Контейнеризация, оркестрация — раздел 8.06.
Контейнеры поверх ВМ — типичная облачная схема
Стек: сеть → физический сервер → гипервизор → ВМ с гостевой ОС → container engine внутри ВМ → контейнеры с приложениями.
Так устроены многие облачные кластеры — провайдер делит физику на ВМ (изоляция арендаторов, квоты, биллинг), а команда внутри ВМ крутит Kubernetes или Docker. Сочетаются жёсткая граница ВМ и гибкость контейнеров (например, worker-ноды EKS на EC2). Образ приложения описывают в Dockerfile; готовые шаблоны — галерея Lab.
Сводка
| Модель | Управляющий слой | Изоляция | Накладные расходы |
|---|---|---|---|
| Bare metal | ОС хоста | Процессы одной ОС | Минимальные |
| ВМ (гипервизор) | Гипервизор + гостевая ОС на каждую ВМ | Полные ядра и ОС | Высокие (RAM, диск, старт) |
| Контейнеры | Container engine + общее ядро | Процессы и namespaces | Низкие |
| Контейнеры в ВМ | Гипервизор + engine в госте | ВМ и контейнер | Сумма обоих уровней |
Ниже — гипервизоры 1-го и 2-го типа и конкретные продукты для рабочей станции. Аппаратные расширения VT-x/AMD-V — в главе про ЭВМ.
Основные понятия виртуализации
Определение виртуальной машины
Здесь — гостевая ОС на гипервизоре (VirtualBox, Hyper-V).
В разработке тот же термин означает исполнитель байт-кода (JVM, CLR) — см. Process VM, байт-код и JIT и микрокод и аппаратная виртуализация.
Виртуальная машина представляет собой программную копию физического компьютера. Каждая виртуальная машина содержит собственный набор виртуальных компонентов, которые взаимодействуют друг с другом по тем же принципам, что и компоненты реального оборудования.
Компоненты виртуальной машины включают следующие элементы:
| Компонент | Описание | Пример реализации |
|---|---|---|
| Виртуальный процессор | Набор CPU ядер, предоставляемых гипервизором | 2 vCPU, 4 vCPU, количество зависит от настроек хоста |
| Оперативная память | Выделенный объём RAM для использования гостевой системой | 4 ГБ, 8 ГБ, 16 ГБ |
| Дисковая подсистема | Виртуальные диски формата VDI, VMDK, VHDX | HDD до 100 ГБ, SSD до 500 ГБ |
| Сетевые адаптеры | Эмуляция сетевых карт разных стандартов | NAT, мостовой режим, изолированная сеть |
| Графический ускоритель | Поддержка GPU для рендеринга интерфейса | 128 МБ видеопамяти с базовыми возможностями |
| Периферийные устройства | Эмуляция USB, аудио, клавиатуры, монитора | Контроллеры USB 2.0/3.0, звуковые карты |
Каждая виртуальная машина имеет уникальный идентификатор, который используется внутренними механизмами гипервизора для различения экземпляров между собой. При запуске виртуальная машина создаёт полностью автономное окружение, где устанавливается гостевая операционная система. Гостевая система функционирует так, будто она работает на физическом оборудовании собственной конфигурации.
Роль гипервизора в архитектуре виртуализации
Гипервизор является фундаментальным компонентом любой системы виртуализации. Этот программный слой выполняет следующие функции:
Функции гипервизора:
- Распределение физических ресурсов процессора между всеми активными виртуальными машинами
- Выделение оперативной памяти каждому экземпляру согласно заявленным требованиям
- Управление доступом к дисковым накопителям и файловой системе хоста
- Обеспечение сетевой связности между виртуальными машинами и внешней средой
- Защита данных одной ВМ от доступа других ВМ через механизмы изоляции
- Реализация снапшотов — сохранение состояния системы на момент времени
- Обработка ошибок и аварийных ситуаций при работе виртуальных устройств
Архитектурная схема размещения гипервизора определяет класс системы и характер её применения. Различают два основных класса гипервизоров по принципу расположения относительно операционной системы хоста.
Классы гипервизоров и их характеристики
Тип 1 — Bare-metal гипервизоры
Bare-metal гипервизоры устанавливаются напрямую на физическое оборудование без промежуточного уровня операционной системы. Такая архитектура обеспечивает минимальные накладные расходы и максимальную производительность вычислений.
Характеристики bare-metal гипервизоров:
| Характеристика | Описание |
|---|---|
| Расположение | Непосредственно на аппаратном обеспечении |
| Потребление ресурсов | Минимальные потери на промежуточный уровень ОС |
| Масштабируемость | Возможность запуска сотен виртуальных машин на одном узле |
| Область применения | Серверные дата-центры, облачные платформы |
| Доступность для пользователей | Специализированные инструменты администрирования |
Известные представители типа 1:
- VMware ESXi — корпоративная платформа виртуализации
- Microsoft Hyper-V Server — серверная версия технологии Hyper-V
- Xen — гипервизор с открытым исходным кодом
- KVM (Kernel-based Virtual Machine) — решение для Linux
- Proxmox VE — распределённая кластерная среда на базе KVM
Тип 2 — Hosted гипервизоры
Hosted гипервизоры работают как приложения поверх установленной операционной системы пользователя. Эта архитектура подходит для локального использования на десктопах и ноутбуках разработчиков.
Характеристики hosted гипервизоров:
| Характеристика | Описание |
|---|---|
| Расположение | Внутри существующей операционной системы хоста |
| Установка | Через стандартные менеджеры пакетов или установщики .exe/.dmg |
| Производительность | Наличие двойного слоя абстракции |
| Доступность | Широкое распространение среди частных пользователей |
| Интерфейс | Графические панели управления для удобства |
Известные представители типа 2:
- Oracle VM VirtualBox — свободно распространяемое решение
- VMware Workstation Pro и Player — коммерческое профессиональное ПО
- Parallels Desktop — специализированная платформа для macOS
- QEMU — эмулятор общего назначения с открытым исходным кодом
- Docker Desktop — контейнеризованная виртуализация для разработки
Сравнение типов гипервизоров
Сравнительная таблица показывает ключевые различия между типами решений:
| Критерий сравнения | Bare-metal (Тип 1) | Hosted (Тип 2) |
|---|---|---|
| Установка на чистое железо | Да | Нет |
| Требуется ОС хоста | Нет | Да |
| Производительность | Высокая | Средняя |
| Настройка сложности | Требует квалификации | Простая установка |
| Облачное применение | Основная область | Локальная разработка |
| Лицензирование | Часто платное | Бесплатные опции |
| Интеграция с OS | Минимальная | Полная интеграция |
Выбор типа гипервизора зависит от конкретной задачи. Для развертывания лабораторных стендов на личном компьютере обычно применяют hosted решения. Для создания выделенных серверов виртуализации выбирают bare-metal платформы.
Аппаратная поддержка виртуализации
Технологии Intel VT-x и AMD-V
Современные процессоры содержат встроенные расширения для эффективной работы гипервизоров. Эти расширения реализуются на уровне архитектуры центрального процессора и позволяют передавать критические операции напрямую аппаратному обеспечению.
Intel VT-x:
- Технология виртуализации для процессоров Core i3, i5, i7, i9 и Xeon
- Включает набор инструкций для разделения контекста процессора
- Позволяет гипервизору работать поверх процессора без полной интерпретации
AMD-V:
- Аналогичная технология от компании AMD для семейств Ryzen и EPYC
- Поддерживает несколько режимов выполнения потоков параллельно
- Обеспечивает изоляцию между гостевыми системами на уровне ядра
Обе технологии имеют одинаковый функционал и применяются независимо от марки процессора. Проверка наличия поддержки осуществляется через BIOS/UEFI материнской платы.
Настройка BIOS/UEFI для включения виртуализации
Для корректной работы любого гипервизора необходимо активировать соответствующую функцию в настройках прошивки. Порядок действий следующий:
Пошаговая инструкция активации:
- Перезагрузка компьютера при включении вызывает меню загрузки
- Нажатие клавиши F2, Del, Esc или F10 для входа в BIOS/UEFI
- Поиск раздела "Advanced" или "Система Configuration" в меню
- Выбор параметра "Virtualization Technology" или аналогичного названия
- Переключение значения в положение "Enabled"
- Сохранение изменений и перезагрузка системы
Названия параметров в разных BIOS:
| Производители | Параметр в BIOS/UEFI |
|---|---|
| ASUS | SVM Mode / Virtualization Technology |
| Gigabyte | Intel Virtualization Technology |
| MSI | CPU Virtualization |
| ASRock | SVM Mode / VT-x |
| Dell | Intel VT-x / AMD-V |
| HP | Virtualization Technology |
Пропуск этого шага приводит к падению производительности виртуальных машин в десятки раз. Некоторые гипервизоры вообще не запустятся без аппаратной поддержки.
Проверка работоспособности виртуализации
Пользователи могут проверить текущий статус поддержки виртуализации изнутри операционной системы без обращения к BIOS.
Проверка в Windows PowerShell:
Get-WmiObject Win32_VirtualMachinePlatform
Проверка через командную строку:
systeminfo
В выводе команды найдите строки "Hyper-V Requirements":
- A hypervisor has been installed – наличие работающей платформы
- Hypervisor-present mode running – работа надстроенной гипервизора
Проверка в Linux терминале:
grep -E --color=auto 'vmx|svm' /proc/cpuinfo
Наличие меток vmx для процессоров Intel или svm для процессоров AMD подтверждает активацию технологий виртуализации.
Инструменты виртуализации для рабочих станций
Oracle VM VirtualBox
VirtualBox является одним из наиболее популярных инструментов типа 2. Он поддерживает все основные операционные системы в качестве хостов — Windows, Linux, macOS, Solaris.
Возможности и преимущества VirtualBox
| Функция | Описание |
|---|---|
| Кроссплатформенность | Единая база настроек между разными хостами |
| Отсутствие лицензионных ограничений | Полностью бесплатное использование |
| Широкая поддержка гостевых ОС | Совместимость со старыми и редкими дистрибутивами |
| Активное сообщество | Множество руководств и готовых образов |
| Форматы дисков | Собственный VDI и импорт VMDK, VHD, QCOW2 |
| Экспорт и импорт | Перенос машин между хостами через OVF/OVA |
Архитектурные модули VirtualBox
VirtualBox построена на модульной структуре, где каждый компонент отвечает за свою задачу:
Основные модули:
- VBoxDrv — драйвер ядра для доступа к аппаратной виртуализации
- VBoxNetAdp — виртуальные сетевые адаптеры для изоляции
- VBoxNetFlt — фильтры сетевого трафика хоста
- VBoxUSB — эмуляция USB контроллеров разного поколения
- VBoxHeadless — серверная часть без графического интерфейса
Guest Additions
Guest Additions представляют собой комплект драйверов и утилит, устанавливаемых внутри гостевой системы. После установки расширяются функциональные возможности взаимодействия с хостом.
Функции Guest Additions:
| Функция | Описание | Эффект |
|---|---|---|
| Бесшовный курсор мыши | Перемещение между окнами без захвата | Удобство работы |
| Общий буфер обмена | Копирование текста между хостом и гостем | Синхронизация данных |
| Drag-and-drop перенос файлов | Перемещение файлов мышью | Быстрая передача содержимого |
| Автомасштабирование экрана | Подгонка разрешения под окно | Оптимальное отображение |
| Ускорение дискового ввода-вывода | Специальные драйверы | Повышение скорости записи |
| Общая папка | Монтирование директории хоста | Доступ к файлам вне ВМ |
| Синхронизация времени | Автоподстройка часов | Корректные временные метки |
Процесс установки Guest Additions
- Запуск виртуальной машины с гостевой системой
- Установка базовой операционной системы
- Выбор меню "Устройства" → "Подключить образ диска Guest Additions"
- Переход в гостевую систему и открытие установщика из виртуального CD-ROM
- Следование пошаговому мастеру установки с выбором компонентов
- Перезагрузка гостевой системы для применения изменений
Важно понимать, что без Guest Additions виртуальная машина функционирует ограниченно. Производительность графики падает, сетевой трафик замедляется, а взаимодействие с хостом становится неудобным.
VMware Workstation Pro
VMware Workstation позиционируется как профессиональное решение с акцентом на высокую производительность и расширенные функции управления. Продукт включает бесплатную версию Player и платную версию Pro для продвинутых пользователей.
Отличия версий Pro и Player
| Особенность | Player | Pro |
|---|---|---|
| Создание новых машин | Только импорт | Полный редактор |
| Редактирование настроек | Ограниченные параметры | Полный контроль |
| Вложенная виртуализация | Запрещено | Поддерживается |
| Снимки состояния | Только чтение | Создание и редактирование |
| Взаимодействие с ESXi | Ограничено | Полная поддержка |
| Лицензия | Бесплатно для личного использования | Коммерческая |
Вложенная виртуализация
Вложенная виртуализация позволяет запускать гипервизор внутри виртуальной машины. Этот метод применяется для тестирования кластерных решений и симуляции дата-центра на одном рабочем месте.
Сценарии применения вложенной виртуализации:
- Тестирование Kubernetes-кластера с несколькими нодами
- Развертывание серверов ESXi для обучения виртуализации
- Исследование поведения антивирусных продуктов в изоляции
- Разработка конфигураций серверов перед продакшеном
Расширенные сетевые возможности
VMware Workstation предлагает гибкую настройку сетей с поддержкой сложных схем подключения:
| Режим сети | Описание | Применение |
|---|---|---|
| NAT | Доступ из гостя наружу, изоляция входящих | Обычный интернет |
| Bridged | Прямое подключение к физической сети | Сервера в LAN |
| Host-only | Связь только с хостом и другими ВМ | Изолированные тесты |
| Internal | Связь между ВМ без выхода наружу | Лабораторные сегменты |
| Custom | Пользовательские параметры VLAN | Продвинутые топологии |
Hyper-V в экосистеме Windows
Hyper-V представляет собой гипервизор типа 1, встроенный в корпоративные версии Windows. Несмотря на наличие внутри ОС, техническая архитектура разделяет ядро на роль хоста и роль гостя после активации.
Особенности архитектуры Hyper-V
При включении Hyper-V система меняет структуру своего функционирования:
| Показатель | До активации | После активации |
|---|---|---|
| Статус ядра | Рабочее состояние хоста | Работает как гость |
| Прямой доступ к железу | Есть у приложений | Имеет только гипервизор |
| Уровень изоляции | Стандартный | Повышенный |
| Совместимость с другими VMM | Полная | Частичная |
| Security Credential Guard | Выключено | Включено |
Применения Hyper-V
Сценарии использования:
- Разработка приложений .NET и ASP.NET Core
- Развёртывание баз данных SQL Server
- Тестирование Azure-инфраструктуры локально
- Запуск контейнеров с помощью WSL2
- Организация учебных стендов для сотрудников
Linux Integration Services (LIS)
LIS предоставляет аналогичный Guest Additions функционал для Linux-гостей. Комплект драйверов улучшает производительность дисковой подсистемы, сетевого стека и синхронизацию времени.
Windows Sandbox
Windows Sandbox представляет собой специализированную встроенную функцию операционной системы. Среда создаётся по требованию пользователя и удаляется после завершения сессии автоматически.
Характеристики Windows Sandbox
| Параметр | Значение |
|---|---|
| Время запуска | 2–5 секунд |
| Чистота системы | Полная очистка после закрытия |
| Изоляция от хоста | Полное разделение файловой системы |
| Доступ к ресурсам | Динамическое распределение CPU и памяти |
| Сетевое соединение | Активно по умолчанию |
| Постоянное хранение | Отсутствует |
| Прав доступа | Администратор по умолчанию |
Сценарии применения Sandbox
Рекомендуемые случаи использования:
- Анализ подозрительных исполняемых файлов из интернета
- Проверка установщиков потенциально опасных программ
- Тестирование драйверов оборудования
- Исследование вредоносного ПО в безопасном режиме
- Пробные запуски незнакомых приложений
- Проверка изменения системного реестра
Настройка параметров Sandbox
Конфигурация среды выполняется через XML-файлы конфигурации. Пример структуры файла:
<Configuration>
<MappedFolders>
<MappedFolder>
<HostFolder>C:\Users\Public\SandboxData</HostFolder>
<SandboxFolder>C:\SharedData</SandboxFolder>
<ReadOnly>false</ReadOnly>
</MappedFolder>
</MappedFolders>
<Networking>
<NetworkProfile>Full</NetworkProfile>
</Networking>
</Configuration>
Параметры конфигурации позволяют передавать файлы из хоста в среду, регулировать сетевой доступ и автоматизировать запуск скриптов при старте.
Запуск Windows Sandbox
Процедура запуска включает несколько простых действий:
- Открыть меню "Выполнить" комбинацией клавиш Win + R
- Ввести команду
windows-sandboxи подтвердить ввод - Система создаст новую песочницу с чистой установкой
- После завершения работы закрыть окно
- Все данные автоматически уничтожаются
Команда может быть вызвана через поиск Windows или созданный ярлык на рабочем столе.
Создание загрузочных носителей
Понятие образа ISO
Образ ISO представляет собой точную копию оптического диска. Файл содержит полную файловую систему, загрузчик, разделы и мета-данные оригинального носителя.
Характеристики формата ISO:
| Характеристика | Описание |
|---|---|
| Содержимое | Файловая система, загрузочный сектор, установщик |
| Распространение | Официальные сайты вендоров |
| Размер | От 100 МБ до 10 ГБ |
| Целостность | Хэш-сумма SHA-256 для проверки |
| Совместимость | Поддерживается большинством утилит |
Различие между образом ISO и загрузочным USB
Особое внимание следует уделять различию между простым копированием файлов и правильной записью загрузочного носителя:
| Действие | Результат | Применимость |
|---|---|---|
| Копирование файлов | Небоеспособный носитель | Не рекомендуется |
| Низкоуровневая запись | Полноценный загрузочный диск | Рекомендовано |
| Партийное копирование | Портативная система | Ограниченное применение |
Низкоуровневая запись означает посекторное копирование образа с сохранением всей структуры разделов и загрузочной информации.
Rufus
Rufus представляет собой легковесную инструментальную программу для создания загрузочных USB-накопителей на платформах Windows. Приложение работает портативно без инсталляции и поддерживает множество форматов.
Возможности Rufus
| Возможность | Описание |
|---|---|
| Схема разметки | MBR для BIOS, GPT для UEFI |
| Файловые системы | FAT32, NTFS, exFAT |
| Режим DD-образа | Прямое копирование для Live-систем |
| Обновление драйверов | Добавление USB 3.0 и NVMe |
| Проверка целостности | Верификация записи бит-в-бит |
| Форматирование | Быстрое и полное стирание данных |
Процесс создания загрузочного носителя в Rufus
- Подключение USB-накопителя к компьютеру
- Запуск приложения Rufus без необходимости установки
- Выбор устройства хранения из списка
- Нажатие кнопки выбора и указание ISO-образа
- Выбор схемы разметки: MBR или GPT
- Указание файловой системы и режима записи
- Подтверждение действия и ожидание завершения
- Проверка статуса готовности
Выбор схемы разметки:
- MBR — совместимость со старыми системами BIOS и CSM
- GPT — современный стандарт для UEFI-загрузки
- Выбор зависит от целевой платформы установки
Выбор файловой системы:
- FAT32 — максимальная совместимость, ограничение 4 ГБ на файл
- NTFS — поддержка больших файлов, требуется специальный загрузчик
- exFAT — баланс между размерами и совместимостью
Безопасность загрузочных носителей
Перед началом процесса убедитесь в следующих моментах:
| Проверяемый параметр | Требуемое значение |
|---|---|
| Наличие важных данных на USB | Отсутствие обязательных файлов |
| Целостность ISO-образа | Соответствие хэш-сумме |
| Объём свободного места | Минимум 4 ГБ свободного пространства |
| Скорость записи USB | Preferably USB 3.0 или выше |
| Стабильность питания | Отключение спящего режима |
Программа Rufus предупреждает перед форматированием и требует подтверждения от пользователя. Любые данные на устройстве будут удалены безвозвратно.
Механизмы изоляции и безопасности
Принципы изоляции виртуальных машин
Изоляция представляет собой гарантию независимости процессов и данных внутри каждого экземпляра. Реализация основана на нескольких уровнях защиты:
Уровни изоляции:
- Аппаратный уровень — отдельные виртуальные ядра процессора и блоки памяти
- Гипервизор — управление доступом к общему оборудованию
- Сетевой уровень — разделение каналов связи и маршрутизация трафика
- Файловая система — разграничение доступа к диску
- Пространство процессов — отдельная иерархия задач
Риски и ограничения изоляции
| Риск | Мера смягчения |
|---|---|
| Утечка памяти между ВМ | Статическое выделение ресурсов |
| Общие сетевые ошибки | Использование отдельных коммутаторов |
| Конфликты портов | Настройка уникальных диапазонов |
| Перекрытие адресов | Различные подсети для каждой ВМ |
| Доступ к общим данным | Отключение общих папок |
Под капотом — гипервизор, WSL и Docker
| Технология | Уровень | Суть |
|---|---|---|
| VirtualBox / VMware | Type 2 (hosted) | Гипервизор как приложение в Windows, гостевая ОС поверх |
| Hyper-V | Type 1 на Windows Pro | Роль гипервизора в ядре; ВМ ближе к "железу" |
| KVM/Proxmox | Type 1 на сервере | Домашний сервер, несколько ВМ 24/7 |
| WSL2 | Лёгкая ВМ + интеграция | Ядро Linux в Hyper-V, файлы \\wsl$\ |
| Docker | Контейнеры | Общее ядро хоста, изоляция namespaces + cgroups |
| Windows Sandbox | Одноразовая ВМ | Копия системы, выброс после закрытия |
VT-x/AMD-V в BIOS должен быть включён — иначе VirtualBox выдаст ошибку виртуализации.
Docker Desktop на Windows: WSL2 backend → Linux-ядро → containerd → ваш образ. Образ — слои файловой системы (overlayfs), не полная ОС.
Сеть ВМ: NAT (гость в частной сети), Bridge (гость как отдельный IP в LAN), Host-only (только связь с хостом).
Опыт, мнение и истории
Nested virtualization. Hyper-V включён для WSL2 — VirtualBox падал, пока не переключили backend или не развели роли (один гипервизор на машину — частое правило).
Windows Sandbox. Запуск сомнительного .exe из почты — отработал, закрыл окно — среда удалилась. Для разовой проверки удобнее, чем полная ВМ.
Docker "съел диск". Старые образы и volumes забили 50 ГБ — docker system prune стал ежемесячной привычкой.
Мнение. Домашнему энтузиасту: WSL2 + Docker закрывают 70 % экспериментов; полная ВМ — когда нужна другая ОС целиком (тест Windows 11, pfSense, Proxmox на железе).