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

"VM = виртуальное железо (own kernel). Container = виртуальный user-space (shared kernel). microVM = VM с минимальным kernel: изоляция от VM, cold start как у container."

Зачем

Виртуализация — это слой, на котором стоит вся современная cloud-индустрия. Без неё нет EC2, нет Kubernetes, нет Lambda, нет multi-tenancy. Но "виртуализация" — это не одна технология, а целое семейство, и выбор между bare-metal, VM, container и microVM напрямую определяет три вещи в вашей системе.

Cold start. Lambda стартует за ~125 мс, EC2-инстанс — за 30-60 секунд, контейнер — за 100 мс, bare-metal сервер бутится минутами. Если вы строите serverless API с burst-нагрузкой — 60 секунд cold-start вас убьёт. Если вы крутите long-running JVM-приложение — 125 мс vs 30 секунд значения не имеет, зато имеет значение overhead памяти и CPU.

Изоляция (трастовая граница). Container escape (CVE-2019-5736 в runc, Dirty COW) пробивает shared kernel — атакующий получает root на host и доступ ко всем соседним контейнерам. VM escape требует уязвимости в гипервизоре, что на порядки реже. Если у вас выполняется untrusted user code (как Lambda) — shared kernel недопустим, нужен микро-VM.

Density и billing. Bare-metal: 1 workload на хост. VM: десятки. Container: сотни. microVM: тысячи. Это напрямую транслируется в $/час: чем выше плотность, тем дешевле каждый tenant. Именно поэтому AWS Lambda — это microVM, а не контейнер: им нужна изоляция VM при плотности и cold-start контейнера.

И ещё одно: понимание уровней абстракции защищает от паники, когда что-то ломается. "Pod не стартует" — это уровень оркестратора. "Container не стартует" — runtime. "Host не отвечает" — гипервизор. "Все VM на host тормозят" — noisy neighbor через гипервизор. Без модели слоёв вы не поймёте, на каком этаже искать проблему.

Mental model

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

Application       (ваш код)
  User-space      (libc, runtime)
  OS Kernel       (syscalls, scheduler)
  Hypervisor      (Ring -1, trap-and-emulate) <- VMware ESXi, KVM, Xen
  Hardware        (Intel VT-x, AMD-V)

Контейнер выкидывает слой "Hypervisor" и шарит "OS Kernel" между всеми контейнерами — отсюда дешёвый старт и слабая изоляция. microVM возвращает гипервизор, но делает kernel минимальным (Firecracker — 50K LOC vs миллионы у Xen), чтобы boot был быстрым.

Три ключевых правила:

1. Чем выше изоляция — тем медленнее старт и больше overhead. Бесплатной изоляции не бывает.
2. Trust boundary решает выбор, density — вторично. Сначала спросите "кому я доверяю", потом "сколько штук на хост".
3. Один шаг изоляции вверх стоит ~10x cold-start. Не платите если нет threat.

Что на диаграмме

Четыре группы side-by-side, демонстрирующие разные модели виртуализации:

• Type-1 Hypervisor (bare-metal) — ESXi, KVM, Xen, Hyper-V. Гипервизор сидит на железе напрямую (Ring -1), VM-1 и VM-2 имеют собственные kernel и делят CPU через vCPU scheduling. Это AWS EC2, Google Compute Engine, Azure VMs.
• Type-2 Hypervisor (hosted) — VirtualBox, Parallels, VMware Workstation. Гипервизор работает как user-space процесс поверх host OS. Дополнительный слой syscalls делает его медленнее, но удобнее для dev — вы запускаете VM прямо на ноутбуке.
• Containers (shared kernel) — Docker/containerd. Host kernel шарится между всеми контейнерами через namespaces и cgroups. Container Runtime спавнит контейнеры (Container A, B, C). Контейнер C помечен как untrusted — он понадобится для сценария 2.
• microVMs (Firecracker) — это AWS Lambda и Fargate. KVM как hardware-плечо, минималистичный Firecracker VMM, и три microVM с собственным минимальным kernel. Замечание: в реальности тут не три, а тысячи microVM на хост.
• Target Host (внизу) — пункт назначения для live migration из сценария 1.

Edges — это физические соединения в архитектуре (как VT-x trap, vCPU scheduling, KVM ioctl), а не направления данных. Анимация идёт по тем же edges в обоих направлениях.

Сценарии

1. VM lifecycle: create -> boot -> live migrate (~30-60s + ~100ms downtime)

Полный жизненный цикл VM на Type-1 гипервизоре: hypervisor занимает Ring -1, аллоцирует vCPU и RAM, бутит guest (BIOS -> bootloader -> kernel init), обрабатывает VMEXIT/VMRESUME для privileged operations. Затем — live migration: pre-copy RAM на target host итерациями (пока VM работает), потом короткий stop-and-copy для финальных dirty pages и регистров CPU. Downtime ~100 мс, TCP-соединения живут, клиенты ничего не замечают. Это магия VMware vMotion / KVM live migration, на которой держится maintenance больших кластеров.

2. VM vs Container — изоляция и blast radius

Сценарий показывает разницу трастовых границ. Untrusted контейнер C ловит CVE-2019-5736 (real exploit, runc 2019) — malicious binary перезаписывает /proc/self/exe, получает root на host kernel. С этого момента всё кончено: атакующий читает /proc/<pid>/environ соседних контейнеров (credentials, secrets), доступ ко всем shared resources. Тот же untrusted workload в VM: guest kernel exploit даёт root в guest — но это всё ещё guest. Соседняя VM-2 недоступна (отдельный address space, отдельный kernel), VM escape требует уязвимости в гипервизоре, что на порядки реже. Вывод: для multi-tenant с untrusted code shared kernel недопустим.

3. microVM cold start (<150ms): Firecracker / Lambda

Покадровая разбивка Lambda invocation: t=0ms Firecracker fork и читает 5MB vmlinux, t=10ms KVM_CREATE_VM ioctl и allocate 128MB guest memory, t=30ms минимальный kernel boot (no PCI, no ACPI, no USB — голый KVM), t=80ms init и runtime (Node.js/Python), t=120ms handler loaded, t=125ms READY. Параллельно поднимаются microVM #2 и #3. После выполнения AWS держит warm pool ~5-15 мин (warm starts ~1-5 мс), потом idle timeout убивает microVM. Главная мысль: microVM = strong isolation (own kernel) + container-like cold start. Multi-tenant без compromise — поэтому AWS перенесли Lambda с контейнеров на Firecracker в 2018.

Trade-offs (ADR-001)

Контекст. Команда строит multi-tenant платформу: часть workload — long-running web services (Node.js/JVM), часть — batch jobs, часть — user-supplied код (как AWS Lambda). Варианты: bare-metal, Type-1 VM, container, microVM. Цена ошибки: containers для untrusted code → container escape; VMs для микросервисов → деньги в overhead и медленный CI/CD; microVM для долгоживущего web-сервиса → лишний слой без выгоды.

Решение. Trust boundary решает всё, плотность — вторично.

Defaults: trusted → container, untrusted → microVM, regulated → VM, latency-critical → bare-metal.

Реальные системы

• AWS EC2 — исторически Xen, с 2017 — Nitro Hypervisor (KVM-based, специализированные карты для I/O/network/storage offload).
• AWS Lambda + Fargate — Firecracker microVMs с конца 2018. До этого Lambda работал на контейнерах с дополнительными ограничениями; миграция на Firecracker дала им density + изоляцию для multi-tenant.
• Google Cloud (GCE) — KVM-based hypervisor поверх собственного Linux fork.
• Azure — Hyper-V (Type-1).
• VMware vSphere/ESXi — корпоративная классика, доминирует в private cloud и enterprise data centers, поддерживает vMotion (live migration).
• DigitalOcean, Linode, Hetzner — все на KVM.
• Apple Silicon Macs — встроенный Virtualization.framework (Type-2 через Hypervisor.framework), на котором сидят Docker Desktop, OrbStack, Parallels, UTM.

Anti-patterns

• Untrusted code в Docker на shared host. Это не изоляция — это видимость изоляции. Один CVE в runc/containerd, и атакующий на host. Если у вас "user uploads Python script and we run it" — это microVM (gVisor, Firecracker), а не Docker.
• Микросервисы в полноценных VM. 30-60 секунд cold start, 10-20% overhead, dozens на host. CI/CD замедляется в разы, бюджет уходит в воздух. Если код ваш и доверяете — контейнеры.
• Серверный гипервизор для dev. VMware ESXi на ноутбуке вы не запустите — это Type-1, требует bare-metal. Для локальной разработки нужен Type-2 (VirtualBox, Parallels) или контейнерные wrapper (Docker Desktop через крошечный Linux VM).
• Игнорирование hardware-assisted virt. Без VT-x/AMD-V hypervisor вынужден делать binary translation или эмуляцию — медленно (5-10x overhead). Любая cloud VM сегодня требует VT-x; если случайно запустили виртуализацию в виртуализации без nested virt — упрётесь в это.
• "Containers быстрее, давайте всё в Docker". Контейнеры быстры для stateless workload и легко переносимы. Stateful БД в Docker на проде — отдельный квест: storage drivers, volume mounts, фантомные перформанс-просадки.
• Live migration как silver bullet. Migration работает только пока dirty rate < network bandwidth. На write-heavy workload (БД под нагрузкой) pre-copy фаза может никогда не сходиться. Тут нужен post-copy или принять короткий downtime.

Когда НЕ использовать виртуализацию

• Edge computing с жёсткими ресурсами. На IoT-устройстве с 512MB RAM любой hypervisor — это luxury. Bare-metal с unikernel или просто статическая бинарная сборка.
• Performance-critical HPC, ML training, HFT. Каждый VMEXIT — это ~1-10 микросекунд латентности, и она jitter, не deterministic. Trading-системы и low-latency real-time идут bare-metal или dedicated hosts (даже AWS даёт "bare metal" instances типа m5.metal).
• GPU workloads с full bandwidth. GPU passthrough в VM работает, но MIG (Multi-Instance GPU) и SR-IOV дают разделение лучше, чем гипервизор. Для серьёзного ML — dedicated GPU или bare-metal.
• Однотенантный single-purpose сервер. Если у вас один веб-сервис на один хост, и вы — единственный tenant — лишний слой не нужен. Bare-metal проще, дешевле и быстрее.
• Когда оверхед памяти критичен. VM грузит ~200-500MB на kernel/runtime — на маленьких инстансах это 20-50% RAM. Контейнеры экономнее.

Дальше читать

• System Design Space: Virtualization overview
• Firecracker paper (NSDI 2020): Firecracker: Lightweight Virtualization for Serverless Applications — must-read, объясняет почему AWS изобрела microVM и как это работает внутри
• Brendan Gregg: The Performance of Containers, VMs, and Bare Metal — performance-engineering perspective
• Intel VT-x spec: Intel 64 and IA-32 Architectures SDM, Volume 3C — глава 23+, как hardware-assisted virt работает в Ring -1
• AWS Nitro: AWS Nitro System deep dive — как EC2 ушёл от Xen
• Xen vs KVM: LWN: The KVM/Xen comparison
• Связанные концепты: ::concept{slug="containers"}, ::concept{slug="operating-system-basics"}, ::concept{slug="kubernetes-fundamentals"}