¶ Лекция 2. Виртуализация: от виртуальной машины к контейнерной инфраструктуре
Дисциплина: Сетевое и системное администрирование
Курс: 3 курс СПО
Связь с курсом: после этой темы студенты начнут создавать виртуальные машины и устанавливать ALT Linux Server без GUI
Формат: теория + схемы + таблицы + визуальные материалы + короткие выводы после каждой главы
Цель лекции: понять, как один физический компьютер может одновременно выполнять несколько изолированных операционных систем; разобраться в назначении гипервизоров, vCPU, виртуальной памяти, виртуальных дисков и сетей; понять стек QEMU/KVM/Proxmox VE; отличать виртуальные машины от Linux-контейнеров и Docker; научиться рассуждать о ресурсах, отказоустойчивости и диагностике виртуальной инфраструктуры.
¶ 1. Зачем вообще нужна виртуализация
В первой лекции мы рассматривали обычный компьютер как систему, в которой операционная система управляет процессором, памятью, накопителями, сетью и устройствами. Теперь усложним задачу.
Представим, что организации одновременно нужны:
- DNS-сервер;
- DHCP-сервер;
- веб-сервер;
- сервер базы данных;
- система мониторинга;
- отдельный сервер для тестирования.
Самый прямой подход:
DNS -> отдельный физический сервер
DHCP -> отдельный физический сервер
WEB -> отдельный физический сервер
Database -> отдельный физический сервер
Monitoring -> отдельный физический сервер
Так действительно можно работать. Но очень часто каждый отдельный физический сервер использует лишь небольшую часть своих возможностей.
Например:
CPU: 7 %
RAM: 25 %
Disk: 15 %
При этом сервер всё равно требует питания, охлаждения, места, сетевого подключения, резервирования и обслуживания.
Виртуализация позволяет использовать один физический узел для запуска нескольких логически отдельных компьютеров.
` ФИЗИЧЕСКИЙ СЕРВЕР
+------------------------------------------------+
| VM1 DNS | VM2 WEB | VM3 DB | VM4 Monitoring |
+------------------------------------------------+
| гипервизор |
+------------------------------------------------+
| CPU | RAM | Storage | Network |
+------------------------------------------------+
Каждая виртуальная машина получает виртуальный CPU, память, диск, сетевой адаптер и другие устройства. Внутрь устанавливается обычная операционная система, которая запускает собственное ядро, процессы, службы и файловые системы.
¶ 1.1. Виртуальная машина, Host и Guest
Virtual Machine (VM, виртуальная машина) — программно создаваемая вычислительная среда, которая для гостевой ОС выглядит как самостоятельный компьютер.
+-----------------------------+
| Виртуальный CPU |
| Виртуальная RAM |
| Виртуальный Disk |
| Виртуальная NIC |
| Виртуальный BIOS / UEFI |
| Виртуальный Controllers |
+-----------------------------+
Host — физическая система, предоставляющая ресурсы виртуализации.
Guest — гостевая операционная система внутри VM.
Пример:
Учебный ПК
|
хост Windows
|
VMware Workstation
|
ALT Linux Guest
Важно всегда понимать, на каком уровне возникла проблема. Фраза «на виртуалке нет сети» может означать проблему физической сети host, virtual switch, vNIC, IP-адреса внутри guest, маршрута или firewall.
¶ 1.2. Что делает гипервизор
Hypervisor — механизм виртуализации, который организует выполнение виртуальных машин и распределяет между ними физические ресурсы host.
Он отвечает за:
- vCPU;
- RAM;
- виртуальные диски;
- виртуальные NIC;
- изоляцию VM;
- запуск и остановку;
- доступ к виртуальным устройствам.
Но гипервизор и платформа управления — не одно и то же. Proxmox VE, например, дополнительно предоставляет web-интерфейс, API, управление сетью, storage, backup, cluster и HA.
¶ Что важно запомнить
- Виртуализация позволяет нескольким отдельным ОС использовать один физический сервер.
- VM имеет собственную гостевую ОС и собственное ядро.
- Host предоставляет физические ресурсы, Guest использует виртуальные.
- Hypervisor распределяет CPU, RAM, storage и network между VM.
- При диагностике нужно понимать, проблема находится на уровне host, hypervisor или guest.
¶ 2. Гипервизоры Type 1 и Type 2
Для первого знакомства удобно использовать две модели: Type 1 и Type 2. Это учебная классификация, которая помогает понять расположение слоя виртуализации относительно обычной host OS.
¶ 2.1. Type 1
Type 1 часто называют bare-metal hypervisor.
+----------------------------------------+
| VM 1 | VM 2 | VM 3 |
+----------------------------------------+
| Hypervisor Type 1 |
+----------------------------------------+
| Hardware |
+----------------------------------------+
Такая модель характерна для серверной инфраструктуры. Основная задача физического узла — запускать виртуальные машины.
Примеры:
- VMware ESXi;
- Microsoft Hyper-V;
- Xen;
- серверные платформы на базе KVM;
- Proxmox VE.
¶ 2.2. Type 2
Type 2 работает поверх обычной host OS.
+----------------------------------------+
| VM 1 | VM 2 |
+----------------------------------------+
| Hypervisor Type 2 |
+----------------------------------------+
| Host Операционная система |
+----------------------------------------+
| Hardware |
+----------------------------------------+
Примеры:
- VMware Workstation;
- Oracle VirtualBox;
- Parallels Desktop.
Для учебной аудитории такой вариант очень удобен: Windows остаётся обычной рабочей ОС, а ALT Linux запускается внутри VM.
¶ 2.3. Сравнение
| Параметр | Type 1 | Type 2 |
|---|---|---|
| Основной сценарий | серверная инфраструктура | desktop / lab |
| Где работает | на серверной платформе | поверх host OS |
| Назначение host | преимущественно виртуализация | обычная работа + VM |
| Управление | часто централизованное | обычно локальное |
| Пример | ESXi, Proxmox VE | Workstation, VirtualBox |
| Наш курс | понимаем концепцию | используем на учебных ПК |
Классификация не всегда буквально описывает внутренности конкретной реализации. Например, KVM встроен в Linux kernel, поэтому реальная архитектура сложнее картинки из трёх слоёв.
На картинке главное увидеть расположение слоёв. В Type 2 между VM и физическим оборудованием есть обычная host OS. Серверная платформа Type 1 ориентирована прежде всего на виртуализацию.
¶ Что важно запомнить
- Type 1 характерен для серверной виртуализации.
- Type 2 удобен для обучения, тестирования и desktop-сценариев.
- GUI сам по себе не определяет тип гипервизора.
- KVM-based платформы сложнее простой школьной схемы.
¶ 3. Как виртуализируется процессор
Если на физическом сервере 8 ядер, а виртуальных машин десять, возникает логичный вопрос: как каждая VM может считать, что у неё есть собственный CPU?
Гостю предоставляется vCPU — virtual CPU, а hypervisor распределяет выполнение виртуальных процессоров по реальным процессорным ресурсам.
¶ 3.1. Сокет, ядро, логический процессор и vCPU
Нужно различать:
- CPU socket;
- физические ядра;
- логические ядра;
- vCPU.
Пример:
1 CPU socket
8 физические ядра
SMT = 2 аппаратных потоков на ядро
Итого:
16 логические ядра
SMT (Simultaneous Multithreading) позволяет одному физическому ядру обслуживать несколько аппаратных потоков.
Важно:
1 vCPU не обязательно равен одному навсегда выделенному физическому ядру.
Обычно выполнение vCPU планируется на доступных физических процессорах.
¶ 3.2. Аппаратная виртуализация
Современные CPU имеют специальные механизмы виртуализации.
Intel:
VT-x
AMD:
AMD-V
Они помогают безопасно выполнять guest ядро и сохранять контроль гипервизор над физическим компьютером.
Из первой лекции мы знаем упрощённую модель привилегий:
Ring 3 -> приложения
Ring 0 -> ядро ОС
Guest ядро тоже хочет выполнять привилегированные операции, поэтому CPU и гипервизор должны совместно контролировать такую работу.
¶ 3.3. VM Exit
Некоторые события требуют вмешательства гипервизор.
гостевая ОС
|
привилегированная операция
|
v
VM EXIT
|
v
Гипервизор обрабатывает событие
|
v
VM RESUME
Переход имеет стоимость. Дополнительные затраты ресурсов называют overhead.
¶ 3.4. CPU overcommit
Можно назначить суммарно больше vCPU, чем host имеет логические процессоры.
Host = 16 логические процессоры
VM1 = 4 vCPU
VM2 = 4 vCPU
VM3 = 4 vCPU
VM4 = 4 vCPU
VM5 = 4 vCPU
Assigned = 20 vCPU
Условный коэффициент:
20 / 16 = 1.25 : 1
Это не означает, что CPU уже загружен на 125 %. Если VM редко используют весь CPU одновременно, такая конфигурация может работать нормально.
Проблема возникает при одновременной нагрузке:
Требовать > Физическую емкость процессора
|
v
конкуренция за ресурсы процессора
|
v
очереди и рост задержек
¶ 3.5. Почему больше vCPU не всегда быстрее
Типичная ошибка:
«Сервис тормозит — дам VM больше vCPU».
Но приложение может:
- использовать один поток;
- ждать диск;
- ждать сеть;
- ждать базу данных;
- конкурировать с другими VM за CPU.
Правильный порядок:
Измерить
↓
Найти узкое место
↓
Проверить host
↓
Проверить guest
↓
Только потом менять vCPU
узкое место — компонент, ограничивающий производительность.
¶ Что важно запомнить
- vCPU — виртуальный процессор, а не обязательно отдельное физическое ядро.
- VT-x и AMD-V помогают эффективно выполнять guest kernel.
- CPU overcommit допустим, если гости не требуют весь CPU одновременно.
- Коэффициент overcommit описывает конфигурацию, а не текущую загрузку.
- Сначала измеряем узкое место, потом увеличиваем ресурс.
¶ 4. Как виртуализируется оперативная память
С памятью ситуация сложнее, чем с CPU. Процессор можно делить по времени: одна VM выполнялась несколько миллисекунд, затем другая. Но данные, которые приложению нужны прямо сейчас, должны физически где-то находиться.
Поэтому RAM требует более осторожного планирования.
¶ 4.1. Три уровня адресации
Внутри обычной ОС процесс использует виртуальные адреса. В VM появляется ещё один уровень:
Виртуальный адрес гостя
|
v
Физический адрес гостя
|
v
Физический адрес хоста
Гостевая ОС считает, что управляет своей физической RAM, но гипервизор дополнительно отображает её на реальную память host.
¶ 4.2. EPT и NPT
Для ускорения такой трансляции используются аппаратные механизмы:
Intel:
EPT — Extended Page Tables
AMD:
NPT — Nested Page Tables
Для администратора достаточно понимать назначение: guest управляет своей памятью, а host контролирует, где эти данные реально размещаются.
¶ 4.3. Почему нельзя отдать всю RAM виртуальным машинам
Если host имеет:
64 GB RAM
нельзя просто создать:
8 VM × 8 GB = 64 GB
и считать расчёт завершённым.
Сам host тоже использует память для:
- Linux kernel;
- management services;
- QEMU processes;
- page cache;
- storage stack;
- networking;
- backup;
- ZFS/Ceph, если они используются.
Поэтому оставляют резерв:
RAM for VM =
Физический RAM
- Host Reserve
- Storage Reserve
- Safety Reserve
¶ 4.4. RAM overcommit
RAM overcommit означает, что гостям суммарно назначено больше памяти, чем физически имеется.
Например:
Host RAM = 64 GB
VM1 = 24 GB
VM2 = 24 GB
VM3 = 24 GB
Назначенный = 72 GB
На низкой нагрузке это может работать. Но если всем VM одновременно реально понадобятся обещанные 72 GB, физического ресурса не хватит.
Поэтому RAM overcommit рискованнее CPU overcommit.
¶ 4.5. Ballooning
Один из механизмов динамического управления памятью — ballooning.
У VM могут быть:
Minimum Memory
Maximum Memory
Например:
Minimum = 2048 MB
Maximum = 8192 MB
Balloon driver позволяет гипервизор попросить guest освободить часть страниц.
Guest VM
+----------------------------+
| Приложения |
| |
| Balloon driver: XXXXXXXX |
| освобождает часть страниц |
+----------------------------+
Важно:
Ballooning не создаёт дополнительную физическую RAM.
Если сервис действительно требует 8 GB working set, сделать его полноценную работу на 2 GB одним ballooning нельзя.
¶ 4.6. Working Set и sizing
Working set — объём памяти, реально используемый нагрузкой в рассматриваемый период.
Пример:
VM настроенный RAM = 8 GB
Типичный рабочий объем = 2.5 GB
пиковый рабочий объем = 6 GB
Поэтому sizing нельзя делать только по состоянию VM в простое.
¶ 4.7. Пример расчёта
Host:
CPU: 8 ядра / 16 логические процессоры
RAM: 64 GB
SSD: 1 TB
План:
| VM | vCPU | RAM |
|---|---|---|
| ALT-RTR | 1 | 2 GB |
| ALT-DNS/DHCP | 1 | 2 GB |
| ALT-WEB | 2 | 4 GB |
| ALT-ZABBIX | 4 | 8 GB |
| 4 × ALT-CLI | 4 суммарно | 8 GB суммарно |
| Windows Lab | 4 | 8 GB |
| ALT-Docker | 4 | 8 GB |
| Итого | 20 | 40 GB |
CPU overcommit:
20 / 16 = 1.25 : 1
Если под host оставляем 10 GB:
64 - 10 = 54 GB
Для VM используем 40 GB. Остаётся 14 GB запаса.
Но этот расчёт всё ещё не учитывает место хранения и сеть.
На картинке собраны физический CPU, назначенные vCPU, резерв RAM, ballooning и идея измерения реальной нагрузки.
Смысл sizing:
Роль VM
↓
Требования ОС и приложения
↓
Стартовый vCPU/RAM
↓
Запуск
↓
Мониторинг
↓
Корректировка
Хороший администратор не угадывает ресурсы один раз навсегда.
Он:
планирует → измеряет → корректирует.
¶ Что важно запомнить
- RAM VM физически опирается на RAM host.
- Host тоже требует памяти.
- RAM overcommit опаснее CPU overcommit.
- Ballooning помогает перераспределять память, но не создаёт её.
- Рабочая и пиковая нагрузка важнее красивой цифры конфигурации.
- Sizing — это цикл измерений и корректировки.
¶ 5. Диск виртуальных машин
Виртуальный диск guest может физически быть обычным файлом, логический том, объектом ZFS/Ceph, LUN, NFS-объектом или другим ресурсом диска.
Упрощённо:
Физический NVMe
|
v
Хранилище
|
v
VM диск
|
v
Гость видит /dev/sda
Гость работает со своим диском, но администратор гипервизор должен понимать, где этот диск реально хранится.
¶ 5.1. Форматы виртуальных дисков
Распространённые форматы:
qcow2;raw;vmdk;vhdx.
Формат влияет на доступные возможности, производительность и совместимость с платформой.
¶ 5.2. Thin provisioning
При thin provisioning гостю можно объявить большой диск, но физически хранить только реально записанные данные.
Виртуальный размер = 100 GB
Фактический использованный = 12 GB
Плюсы:
- экономия места;
- быстрое создание VM;
- удобно для большого количества лёгких машин.
Риск — storage overcommit.
Физическое хранилище данных = 500 GB
VM1 = 200 GB virtual
VM2 = 200 GB virtual
VM3 = 200 GB virtual
VM4 = 200 GB virtual
Объявленный = 800 GB
Физический = 500 GB
Пока guests используют мало места, всё работает. Но если фактическое заполнение приблизится к 500 GB, место закончится.
Причём внутри VM ещё может показываться свободное виртуальное место.
¶ 5.3. Thick provisioning
При thick provisioning место резервируется заранее.
Virtual Disk = 100 GB
Reserved = 100 GB
Преимущество — предсказуемость.
Недостаток — зарезервированное место нельзя отдать другой VM, даже если guest его пока не использует.
¶ 5.4. IOPS, пропускная способность и задержка
Размер диска — не единственный параметр storage.
IOPS — количество операций ввода-вывода в секунду.
Пропускная способность — объём данных за единицу времени.
Задержка — задержка операции.
Например:
VM1 ----\
VM2 -----+---- One Physical NVMe
VM3 ----/
Все три VM могут иметь «быстрые» виртуальные диски, но конкурировать за один физический накопитель.
Если одна VM забирает почти все IOPS, остальные замедляются. Это пример noisy neighbor.
¶ 5.5. Snapshot и Copy-on-Write
Snapshot — снимок состояния VM или её диска на определённый момент.
Он полезен:
- перед обновлением;
- перед изменением конфига;
- перед экспериментом;
- перед лабораторной.
Во многих реализациях используется идея Copy-on-Write:
Base Disk
|
+--> Snapshot / Overlay
|
+--> Changed Blocks
Новые изменения сохраняются отдельно от базового состояния.
¶ 5.6. Почему Snapshot — не Backup
Если базовый диск и snapshot находятся в одном месте хранения:
Storage FAILED
|
+--> Базовый диск LOST
+--> Snapshot LOST
Snapshot удобен для быстрого отмены, но не защищает от всех сценариев потери данных.
Backup должен храниться так, чтобы пережить предусмотренный отказ.
¶ 5.7. Clone и Template
Clone — новая VM на основе существующей.
Template — подготовленный эталон.
ALT-Template
|
+--> Student-01
+--> Student-02
+--> Student-03
Для учебного класса это очень удобно.
Полный клон — независимая копия.
Связанный клон — использует общую базу и отдельно хранит изменения.
` Base Disk
/ \
/ \
Linked1 Linked2
Связанный клон экономит место, но создаёт зависимость от базового сотояния.
После клонирования нужно проверять hostname, IP, ключи и другие идентификаторы.
¶ Что важно запомнить
- Виртуальный диск guest всегда физически где-то хранится.
- Thin provisioning экономит место, но требует контроля свободного места.
- IOPS, пропускная способность и задержка так же важны, как размер диска.
- Snapshot удобен для отката, но не заменяет backup.
- Template и clone позволяют быстро создавать одинаковые учебные среды.
¶ 6. Виртуальная сеть
VM должна уметь общаться с другими VM, host, физической LAN и интернетом.
Для этого guest получает vNIC — virtual Network Interface Card.
Внутри ALT Linux она выглядит как обычный интерфейс:
enp0s3
ens18
eth0
¶ 6.1. Virtual Switch и Bridge
Несколько виртуальных NIC соединяются программным коммутатором.
VM1 ----+
|
VM2 ----+---- Virtual Switch ---- Physical NIC
|
VM3 ----+
В Linux эту роль часто выполняет bridge.
¶ 6.2. Bridge
Bridge может подключить VM к той же L2-сети, что и физический host.
Physical LAN
|
+--------+--------+
| |
Router Host NIC
|
Linux Bridge
/ \
VM1 VM2
VM становится полноценным узлом LAN.
Но для учебных экспериментов это не всегда безопасно. Например, случайно поднятый DHCP-сервер в реальной сети института может начать выдавать неправильные настройки чужим устройствам.
¶ 6.3. NAT
При NAT VM находится во внутренней сети и выходит наружу через трансляцию адресов.
VM
192.168.100.10
|
v
Virtual NAT
|
v
Host
10.10.10.50
|
v
Internet
Для входящих подключений может применяться port forwarding:
Host:2222
|
v
VM:22
¶ 6.4. Внутренняя сеть
Внутренняя сеть соединяет VM между собой без прямого участия физической LAN.
VM1 --------+
|
+---- Internal Network
|
VM2 --------+
Это отличный режим для:
- DHCP;
- DNS;
- routing;
- firewall;
- NAT;
- диагностика.
¶ 6.5. Host-only
Host-only создаёт отдельную сеть между host и guest.
Полезно, если нужно управлять VM с учебного ПК, но не включать её в общую физическую LAN.
| Режим | VM ↔ VM | VM ↔ Host | VM ↔ Physical LAN | Типичное применение |
|---|---|---|---|---|
| Bridge | Да | Да | Да | VM как узел реальной LAN |
| NAT | Да/зависит от реализации | Обычно да | Через NAT | Интернет для guest |
| Internal | Да | Обычно нет | Нет | Изолированная лаборатория |
| Host-only | Да | Да | Нет | Управление guest с host |
!
На картинке хорошо видно различие между bridge, NAT и внутренняя сеть.
Для курса особенно важны:
- NAT — для получения обновлений;
- Внутренняя сеть — для безопасных сетевых лабораторий.
¶ 6.6. Будущий стенд
` Internet
|
NAT
|
+-----------+
| ALT-RTR |
| 2 NIC |
+-----+-----+
|
Внутренняя LAN
|
+------------+-------------+
| |
+----+-----+ +---+------+
| ALT-SRV | | ALT-CLI |
| services | | client |
+----------+ +----------+
¶ Что важно запомнить
- vNIC — обычный сетевой интерфейс с точки зрения guest.
- Bridge подключает VM к L2-сети.
- NAT позволяет выходить наружу через трансляцию адресов.
- Внутренняя сеть подходит для безопасных лабораторий.
- Host-only связывает guest с host.
- При проблеме сети проверяем guest, virtual switch и host.
¶ 7. QEMU, KVM, VirtIO и Proxmox VE
В Linux-виртуализации часто встречаются сразу несколько названий:
QEMU
KVM
libvirt
VirtIO
Proxmox VE
Они связаны между собой, но выполняют разные функции.
¶ 7.1. QEMU
QEMU умеет создавать модель виртуального компьютера и эмулировать устройства.
Он может предоставлять:
- CPU;
- чипсет;
- контроллеры дисков;
- NIC;
- GPU;
- USB;
- прошивка;
- другие устройства.
QEMU способен работать и как полноценный эмулятор.
Например:
x86 Host
|
QEMU Emulation
|
ARM Guest
Но полная эмуляция другой архитектуры значительно тяжелее аппаратной виртуализации.
¶ 7.2. KVM
KVM — Kernel-based Virtual Machine — механизм Linux kernel, использующий VT-x / AMD-V.
Упрощённо:
+--------------------------------------+
| Guest VM |
+--------------------------------------+
| QEMU |
+------------------+-------------------+
|
KVM
|
+------------------+-------------------+
| Linux Kernel |
+--------------------------------------+
| Hardware + VT-x / AMD-V |
+--------------------------------------+
Для первого понимания удобно разделить роли так:
- QEMU создаёт модель виртуального компьютера и устройств;
- KVM помогает эффективно выполнять guest code на реальном CPU.
Это упрощение, но для администратора оно полезнее, чем попытка свести весь стек к одному слову «гипервизор».
¶ 7.3. libvirt
libvirt предоставляет API и инструменты управления виртуализацией.
С его помощью можно управлять:
- VM;
- виртуальные сети;
- пулы хранения;
- snapshots;
- устройства.
Известный CLI-инструмент:
virsh
Но libvirt не является обязательным слоем любой платформы на KVM.
¶ 7.4. VirtIO
При полной эмуляции гипервизор может изображать для guest настоящую модель физического устройства.
Например:
Guest
|
Intel E1000 Driver
|
Emulated E1000
|
QEMU
Это удобно для совместимости, но создаёт лишнюю работу.
Для виртуальной среды существуют специальные паравиртуальные устройства — VirtIO.
Guest VirtIO драйвер
|
v
VirtIO Интерфейс
|
v
QEMU / KVM
Примеры:
virtio-net;virtio-blk;virtio-scsi;virtio-balloon.
Guest понимает, что работает с виртуальным устройством, и использует оптимизированный интерфейс. Обычно это уменьшает overhead.
¶ 7.5. Guest Agent
Guest Agent — программа внутри гостевой ОС, которая позволяет платформе получать дополнительную информацию и выполнять предусмотренные операции.
Например:
- узнать IP guest;
- корректно инициировать shutdown;
- участвовать в некоторых операциях backup/snapshot;
- получать сведения о guest.
Важно:
Guest Agent и VirtIO драйвер — не одно и то же.
VirtIO driver обслуживает виртуальное устройство. Guest agent предоставляет дополнительный канал взаимодействия между guest и платформой.
¶ 7.6. Proxmox VE
Proxmox VE — готовая серверная платформа виртуализации.
Она объединяет:
- QEMU/KVM для VM;
- LXC для Linux контейнеры;
- web UI;
- API;
- управление хранением;
- виртуальные сети;
- кластеры;
- backup интеграции;
- HA.
Упрощённо:
+------------------------------------------------+
| Proxmox VE GUI/API |
+------------------------------------------------+
| Management / Cluster / Storage / Network |
+----------------------+-------------------------+
| QEMU/KVM | LXC |
+----------------------+-------------------------+
| Linux Kernel |
+------------------------------------------------+
| Hardware |
+------------------------------------------------+
На этой схеме особенно важно увидеть, что Proxmox VE — не «ещё один QEMU». Это полноценная управляющая платформа, внутри которой QEMU/KVM являются частью механизма запуска VM.
¶ Что важно запомнить
- QEMU создаёт модель VM и может эмулировать устройства.
- KVM использует аппаратную виртуализацию CPU внутри Linux kernel.
- libvirt предоставляет API и инструменты управления.
- VirtIO — оптимизированные виртуальные устройства.
- Guest Agent и VirtIO драйфвер решают разные задачи.
- Proxmox VE объединяет compute, network, storage и management.
¶ 8. Контейнеризация: почему Docker — не «маленькая виртуальная машина»
После VM появляется естественный вопрос:
Если нам не нужна отдельная ОС целиком, можно ли изолировать только приложение и его окружение?
Можно. Для этого используются контейнеры.
Главное различие:
VM виртуализирует компьютер. Контейнер изолирует процессы в рамках общего ядра.
¶ 8.1. Virtual Machine
+---------------------------+
| Приложение |
| Guest Библиотеки |
| Guest ОС |
| Guest Ядро |
+---------------------------+
| Виртуальное оборудование |
+---------------------------+
| Hypervisor |
+---------------------------+
| Физическое оборудование |
+---------------------------+
Каждая VM имеет собственное гостевое ядро.
Например:
VM1 -> ALT Linux
VM2 -> Windows
VM3 -> Debian
¶ 8.2. Linux Container
+-------------------------+
| Application |
| Libraries |
+-------------------------+
| Shared Host Kernel |
+-------------------------+
| Host Linux |
+-------------------------+
| Hardware |
+-------------------------+
Linux-контейнер не загружает отдельное независимое ядро, как VM.
Он использует ядро host.
Главный вопрос при сравнении:
Какое ядро выполняет системные вызовы приложения?
Для VM — ядро guest OS.
Для Linux-container — ядро host.
¶ 8.3. Пространство имён
Изоляция контейнера во многом строится на namespaces.
Пространство имён предоставляет группе процессов отдельное представление части системы.
Примеры:
- PID namespace;
- network namespace;
- mount namespace;
- UTS namespace;
- IPC namespace;
- user namespace.
¶ PID пространства имён
Один процесс может иметь разные PID с точки зрения host и контейнер.
Host sees: PID 12754
Container sees: PID 1
Это не ошибка. Просто процесс наблюдается из разных пространства имён.
¶ Сетевое пространство имён
Контейнер может иметь собственные:
- interfaces;
- IP addresses;
- routes;
- neighbor table.
Linux Bridge
/ \
veth veth
| |
C1 C2
¶ Пространство имён монтирования
Контейнер может видеть собственное дерево монтирования.
Host Filesystem
|
Mount Namespace
|
Container View
¶ 8.4. cgroups
cgroups — Control Groups используются для учёта и ограничения ресурсов.
Например:
- CPU;
- RAM;
- I/O;
- число процессов.
Для первого знакомства полезно запомнить:
Namespaces -> что процесс видит
cgroups -> сколько ресурсов он может использовать
Это упрощение, но оно хорошо передаёт роль механизмов.
¶ 8.5. Docker
Docker — экосистема для подготовки, распространения и запуска контейнерных приложений.
Он предоставляет:
- images;
- containers;
- registry;
- networks;
- volumes;
- Dockerfile;
- Compose;
- CLI/API.
Упрощённо:
docker CLI
|
v
Docker Engine
|
v
Container Runtime
|
v
Linux Kernel
Namespaces + cgroups
¶ 8.6. Образ и Контейнер
Образ — подготовленная основа.
Container — созданный экземпляр image.
образ nginx
|
+--> контейнер 1
+--> контейнер 2
+--> контейнер 3
Контейнер может быть создан, запущен, остановлен или удалён. Поэтому контейнер — не обязательно только «прямо сейчас работающий процесс».
¶ 8.7. Уровни и Реестр
Образ контейнера обычно состоит из слоёв.
+----------------------+
| Прикладной уровень |
+----------------------+
| Зависимости |
+----------------------+
| Базовый образ |
+----------------------+
Общие слои могут переиспользоваться, что экономит место.
Реестр контейнеров — хранилище образов.
Реестр
|
docker pull
|
v
Host
|
docker run
|
v
Контейнер
Не путать:
Windows реестр
и:
Docker реестр
Это совершенно разные понятия.
¶ 8.8. Volumes и постоянные данные
Контейнер часто считается заменяемым экземпляром. Поэтому важные рабочие данные выносят отдельно.
Контейнер
|
v
Volume
|
v
Постоянные данные
Volume — управляемое постоянное хранилище.
Привязка монтирования — подключение выбранного каталога host внутрь контейнер.
Но Volume тоже не является backup. Если он находится на единственном умершем диске, данные будут потеряны.
¶ 8.9. VM и контейнеры не конкуренты
Типичная современная схема:
Физический сервер
|
Гипервизор
|
Виртуальная машина
|
Linux
|
Docker
|
Контейнеры
VM даёт:
- отдельную ОС;
- инфраструктурную изоляцию;
- управление ресурсами;
- миграция;
- backup.
Контейнеризация даёт:
- упаковку приложения;
- быстрый развертывание;
- повторяемое окружение;
- удобную работу с зависимостями.
¶ 8.10. LXC
LXC — технология Linux system containers.
В Proxmox VE встречаются:
QEMU/KVM VM
и
LXC Container
Упрощённо:
KVM VM LXC
+--------------+ +--------------+
| Apps | | Apps |
| Guest OS | | Userspace |
| Guest Kernel | +--------------+
+--------------+ | Host Kernel |
| KVM/QEMU | +--------------+
+--------------+
¶ Что важно запомнить
- VM имеет собственный guest ядро.
- Linux-контейнер использует ядро host.
- Namespace изолирует представление ресурсов.
- cgroups контролируют и учитывают ресурсы.
- Docker образ — основа, контейнер — экземпляр.
- Volume хранит данные отдельно от жизненного цикла контейнер.
- VM и Docker часто работают вместе.
¶ 9. Виртуализация как инфраструктура: не только VM
Начинающий часто воспринимает виртуализацию так:
«Создал VM — виртуализация готова».
На практике полноценная инфраструктура включает минимум четыре области:
+-----------------------+
| Compute |
| CPU / RAM / VM |
+-----------------------+
| Network |
| Bridge / VLAN / SDN |
+-----------------------+
| Storage |
| Disk / Pool / Ceph |
+-----------------------+
| Management |
| GUI / API / Cluster |
+-----------------------+
Проблема в любой из них способна остановить сервис.
¶ 9.1. Live миграция
Live миграция — перенос работающей VM между физическими host с минимальным перерывом.
Host A Host B
+--------+ +--------+
| VM | ===== migration ==> | VM |
+--------+ +--------+
Используется:
- при обслуживании host;
- при перераспределении нагрузки;
- в кластере.
Но требуются подходящие CPU, network, storage и конфигурация устройств.
¶ 9.2. High Availability
HA — High Availability — высокая доступность.
Пример:
Host 1 FAILED
|
v
Cluster detects failure
|
v
VM starts on Host 2
Важно:
HA не означает «вообще никакого простоя».
После аварии нужно обнаружить отказ и запустить загруженность на другом узле.
¶ 9.3. Общее и распределённое хранилище
Кластеру часто нужно хранилище, доступное нескольким узлам.
Host1 ----\
+---- Shared Storage
Host2 ----/
Примеры:
- NFS;
- iSCSI;
- Fibre Channel;
- Ceph.
Общее хранилище означает общий доступ.
Распределенное хранилище означает распределённую организацию данных по нескольким компонентам или узлам.
¶ 9.4. Backup, RPO и RTO
Backup VM должен учитывать:
- виртуальные диски;
- конфигурацию;
- согласованность приложений;
- независимость места хранения;
- процедуру восстановления.
Главный вопрос:
Не «backup зелёный?», а «восстановление делали?»
RPO — Recovery Point Objective — допустимая потеря данных по времени.
RPO = 1 hour
RTO — Recovery Time Objective — допустимое время восстановления.
RTO = 30 minutes
Можно выполнить одно требование и провалить другое.
¶ 9.5. Scale Up и Scale Out
Scale Up:
2 vCPU -> 8 vCPU
4 GB -> 16 GB RAM
Увеличиваем один экземпляр.
Scale Out:
Web1
Web2
Web3
Добавляем экземпляры.
Виртуализация делает оба подхода удобнее, но приложение должно уметь использовать выбранную архитектуру.
¶ 9.6. Облачная инфраструктура
Виртуализация лежит в основе большого количества IaaS-платформ.
Datacenter
|
+-- Host1
| +-- VM
| +-- VM
|
+-- Host2
| +-- VM
| +-- VM
|
+-- Host3
+-- VM
+-- VM
IaaS — Infrastructure as a Service предоставляет пользователю виртуальные вычислительные ресурсы без необходимости самостоятельно обслуживать каждый физический сервер.
¶ 9.7. Безопасность панели управления
Панель управления гипервизор — критическая точка.
Если атакующий получает полный административный доступ:
Hypervisor compromised
|
+--> VM1
+--> VM2
+--> VM3
Поэтому панель управления защищают:
- отдельной сеть управления;
- firewall;
- MFA;
- минимальными правами;
- обновлениями;
- аудитом;
- ограничением внешнего доступа.
¶ Что важно запомнить
- Виртуализация — это compute + network + storage + management.
- Live миграция и HA решают разные задачи.
- HA не гарантирует нулевой downtime.
- Backup нужно проверять через restore.
- RPO отвечает за потерю данных, RTO — за время восстановления.
- Панель управления нужно защищать особенно тщательно.
¶ 10. Учебный стенд и правильная диагностика
Для нас виртуализация особенно важна потому, что каждый учебный ПК можно превратить в небольшой лабораторный дата-центр.
¶ 10.1. Первый этап
На следующем занятии будет создана первая VM:
Студенческий ПК
|
Гипервизор
|
ALT Linux Server
Стартовая конфигурация может быть примерно такой:
vCPU: 2
RAM: 2 GB
Disk: 15 GB
NIC: 1
GUI: нет
Это не универсальный официальный минимум, а удобная учебная отправная точка.
¶ 10.2. Развитие стенда
Постепенно появятся дополнительные VM:
` Internet
|
ALT-RTR
routing / NAT
|
Internal LAN
/ \
/ \
ALT-SRV ALT-CLI
services client
Дальше роли будут развиваться:
ALT-RTR
├── routing
├── firewall
└── NAT
ALT-SRV
├── DNS
├── DHCP
├── Nginx
├── Reverse Proxy
├── TLS
├── Zabbix Agent
└── Docker
ALT-CLI
└── проверка сервисов
Это не набор несвязанных лабораторных. Это одна инфраструктура, которая постепенно становится сложнее.
¶ 10.3. Virtual Console и SSH
До настройки сети основной способ доступа — virtual console.
Она полезна:
- при установке;
- при загрузке;
- если сеть guest не работает;
- при аварийном восстановлении.
После настройки сети основным способом будет SSH.
Virtual Console
|
+--> не зависит от сети guest
SSH
|
+--> требует работающую сеть
+--> требует запущенный sshd
Если SSH перестал работать, это ещё не значит, что VM выключена. Открываем console и проверяем состояние ОС.
¶ 10.4. Если виртуальная машина не запускается
Диагностика по слоям:
Работает ли физический узел?
|
Работает ли гипервизор?
|
Запущена ли виртуальная машина?
|
Достаточно ли CPU и RAM?
|
Существует ли виртуальный диск?
|
Правильно ли подключён ISO-образ
и настроен порядок загрузки?
|
Запускается ли BIOS / UEFI?
|
Запускается ли загрузчик?
|
Запускается ли ядро ОС?
|
Доступна ли файловая система?
Не нужно сразу переустанавливать операционную систему. Сначала определяем последний этап, который завершился успешно, и начинаем диагностику со следующего уровня.
Например, если на экране уже появился загрузчик, значит гипервизор, виртуальная машина, процессор, память, виртуальный диск и виртуальная прошивка уже работают как минимум на базовом уровне.
¶ 10.5. Если виртуальная машина загрузилась, но сети нет
Диагностика также выполняется последовательно:
Существует ли виртуальный
сетевой адаптер?
|
Подключён ли он
к правильной виртуальной сети?
|
Видит ли гостевая ОС
сетевой интерфейс?
|
Включён ли интерфейс?
|
Правильно ли настроен IP-адрес?
|
Правильно ли указана маска сети?
|
Есть ли необходимый маршрут?
|
Правильно ли настроен DNS?
|
Не блокирует ли соединение
межсетевой экран?
Здесь действует тот же принцип:
Не менять случайные настройки, а последовательно проверять каждый уровень от виртуального оборудования до сетевых служб.
Если интерфейс вообще отсутствует внутри гостевой ОС, искать ошибку в DNS ещё рано. Если IP-адрес и маршруты настроены правильно, но сайт не открывается по имени, тогда уже имеет смысл проверять DNS.
Позже это станет обычным алгоритмом диагностики.
¶ 10.6. Правило перед любым изменением
Перед изменением администратор должен ответить:
- Что я меняю?
- Зачем?
- Как проверю успех?
- Где посмотрю логи?
- Что может сломаться?
- Как вернуть состояние?
- Нужен ли snapshot?
- Нужен ли backup?
Это важнее, чем запомнить расположение конкретной кнопки в интерфейсе Proxmox или VMware.
¶ Что важно запомнить
- Виртуализация превращает учебный ПК в небольшой дата-центр.
- VM нужно рассматривать как часть общей инфраструктуры.
- Console и SSH — разные каналы доступа.
- Диагностика должна идти по слоям.
- Snapshot помогает учиться, но не должен заменять понимание причины ошибки.
- Перед изменением нужно знать способ проверки и возврата.
¶ 11. Что обязательно запомнить после лекции
1. VM — отдельная виртуальная вычислительная среда с собственной гостевой ОС и ядром.
2. Host предоставляет реальные CPU, RAM, место хранения и сеть, а гипервизор распределяет их между guests.
3. Type 1 ориентирован на серверную виртуализацию, Type 2 удобен для desktop и лабораторий.
4. vCPU не равен навсегда закреплённому физическому core.
5. CPU overcommit может быть нормальным, если guests не требуют весь CPU одновременно.
6. RAM overcommit требует большей осторожности; ballooning не создаёт физическую память.
7. Sizing выполняется по реальной нагрузке и уточняется по метрикам.
8. Storage нужно оценивать не только по объёму, но и по IOPS и задержка.
9. Snapshot — не backup.
10. Bridge, NAT, Внутренняя и Host-only решают разные сетевые задачи.
11. QEMU, KVM, VirtIO и Proxmox VE — разные компоненты с разными ролями.
12. VM имеет собственное ядро, Linux-контейнер использует ядро host.
13. Пространства имён изолируют представление ресурсов, cgroups контролируют их использование.
14. Docker образ и Docker контейнер — не одно и то же.
15. Виртуальная инфраструктура = compute + network + storage + management.
¶ 12. Краткий словарь терминов
| Термин | Краткое значение |
|---|---|
| VM / ВМ | Виртуальная машина |
| Host | Физический узел или система, предоставляющая ресурсы |
| Guest | Гостевая ОС внутри VM |
| Гипервизор | Механизм виртуализации |
| Type 1 | Серверная модель гипервизора |
| Type 2 | Гипервизор поверх обычной host OS |
| vCPU | Виртуальный процессор |
| SMT | Аппаратное многопоточное выполнение |
| VT-x / AMD-V | Аппаратная виртуализация CPU |
| VM Exit | Переход управления к hypervisor |
| Overcommit | Назначение виртуального ресурса сверх физического бюджета |
| EPT / NPT | Аппаратная поддержка виртуализации памяти |
| Ballooning | Динамическое управление памятью guest |
| Рабочий объем | Активно используемый объём памяти |
| Sizing | Подбор ресурсов |
| Datastore | Область размещения данных VM |
| Thin Provisioning | Выделение storage по мере записи |
| Thick Provisioning | Предварительное резервирование storage |
| IOPS | Операции ввода-вывода в секунду |
| Snapshot | Снимок состояния |
| CoW | Copy-on-Write |
| Backup | Резервная копия |
| Clone | Клон VM |
| Template | Шаблон VM |
| vNIC | Виртуальный сетевой адаптер |
| Bridge | Виртуальный L2-мост |
| NAT | Преобразование сетевых адресов |
| Внутренний Network | Изолированная сеть VM |
| Host-only | Сеть между host и guest |
| QEMU | Эмуляция и модель виртуального компьютера |
| KVM | Аппаратная виртуализация в Linux kernel |
| libvirt | API/средства управления виртуализацией |
| VirtIO | Паравиртуальные устройства |
| Guest Agent | Агент внутри guest |
| Proxmox VE | Серверная платформа виртуализации |
| Контейнер | Изолированная среда процессов |
| Пространство имён | Изолированное представление ресурсов |
| cgroups | Учёт и ограничения ресурсов |
| Docker образ | Основа для создания containers |
| Docker контейнер | Экземпляр image |
| Реестр | Хранилище образов контейнеров |
| Volume | Постоянное хранилище контейнеров |
| LXC | Linux system containers |
| Live миграция | Перенос работающей VM |
| HA | High Availability |
| RPO | Допустимая потеря данных по времени |
| RTO | Целевое время восстановления |
| Scale Up | Увеличение ресурсов одного экземпляра |
| Scale Out | Добавление экземпляров |
| IaaS | Infrastructure as a Service |
¶ 13. Контрольные вопросы
- Зачем используется виртуализация?
- Что такое VM?
- Чем Host отличается от Guest?
- Что делает hypervisor?
- Чем Type 1 отличается от Type 2?
- Почему Type 2 удобен для учебного класса?
- Что такое vCPU?
- Всегда ли один vCPU равен одному физическому core?
- Для чего нужны VT-x и AMD-V?
- Что такое VM Exit?
- Что такое CPU overcommit?
- Почему коэффициент overcommit не равен реальной загрузке CPU?
- Почему увеличение vCPU не всегда ускоряет VM?
- Как устроено отображение памяти guest на память host?
- Для чего нужны EPT/NPT?
- Что такое RAM overcommit?
- Почему RAM overcommit рискованнее CPU overcommit?
- Что такое ballooning?
- Что такое working set?
- Почему нужно оставлять RAM для host?
- Что такое sizing?
- Что такое виртуальный диск?
- Чем thin provisioning отличается от thick provisioning?
- Что такое storage overcommit?
- Что означает IOPS?
- Что такое latency?
- Что такое snapshot?
- Почему snapshot не backup?
- Что такое clone?
- Что такое template?
- Чем full clone отличается от linked clone?
- Что такое vNIC?
- Что делает bridge?
- Для чего используется NAT?
- Для чего нужна Internal Network?
- Чем Host-only отличается от Internal Network?
- Что такое QEMU?
- Что такое KVM?
- Как взаимодействуют QEMU и KVM?
- Для чего используется libvirt?
- Что такое VirtIO?
- Чем Guest Agent отличается от VirtIO driver?
- Что такое Proxmox VE?
- Чем VM отличается от Linux-container?
- Что такое namespace?
- Что такое cgroups?
- Чем Docker Image отличается от Container?
- Что такое Container Registry?
- Зачем нужны volumes?
- Почему Volume не является backup?
- Что такое LXC?
- Почему VM и containers часто используются вместе?
- Что такое Live Migration?
- Что такое HA?
- Почему HA не означает нулевого простоя?
- Чем RPO отличается от RTO?
- Почему Management Plane нужно особенно защищать?
- Для чего нужна virtual console?
- Почему работающая console и неработающий SSH не противоречат друг другу?
- Какой виртуальный стенд мы будем строить дальше?
¶ 14. Дополнительный материал
Этот раздел не обязателен для основной пары. Его можно открыть, если основную часть студенты прошли быстрее.
¶ 14.1. Passthrough и IOMMU
Иногда VM нужен почти прямой доступ к физическому устройству:
- GPU;
- NIC;
- HBA;
- NVMe;
- USB controller.
Physical Device
|
v
VM
Для PCI passthrough используется IOMMU.
Intel:
VT-d
AMD:
AMD-Vi
Не путать:
VT-x -> virtualization CPU
VT-d -> virtualization I/O
Passthrough повышает зависимость VM от конкретного host и может усложнять migration.
¶ 14.2. NUMA
На больших многосокетных серверах память может быть «ближе» к одному CPU socket и «дальше» от другого.
CPU Socket 0 ---- Local RAM 0
|
+------ interconnect ------+
|
CPU Socket 1 ---- Local RAM 1 <--+
Это называется NUMA — Non-Uniform Memory Access.
Для крупных VM неправильное размещение CPU и RAM по NUMA nodes может ухудшать производительность.
¶ 14.3. Задача на sizing
Host:
CPU: 12 cores / 24 logical processors
RAM: 128 GB
Под host оставляем:
16 GB
Планируем:
4 × Web VM = 2 vCPU / 4 GB
2 × DB VM = 6 vCPU / 16 GB
1 × Zabbix = 4 vCPU / 8 GB
6 × Lab Client = 1 vCPU / 2 GB
Вопросы:
- Сколько vCPU назначено всего?
- Какой CPU overcommit ratio?
- Сколько RAM назначено?
- Сколько RAM остаётся после host reserve?
- Есть ли RAM overcommit?
- Какие ещё ресурсы нужно проверить?
¶ 14.4. Задача на snapshot
Есть цепочка:
Base
|
Snapshot A
|
Snapshot B
|
Snapshot C
Вопросы:
- Что произойдёт, если повредится base?
- Почему цепочка snapshots не является независимым backup?
- Почему большое число snapshots может создавать проблемы?
- Что нужно проверить перед удалением snapshot?
¶ 14.5. Задача на troubleshooting
VM запускается. В console ALT Linux работает. ip addr показывает адрес. Но SSH с host не подключается.
Проверяем:
VM работает?
|
Правильный network mode?
|
Есть маршрут?
|
sshd запущен?
|
Порт слушается?
|
Firewall разрешает?
|
IP правильный?
Главное правило:
Не менять всё сразу. Проверять цепочку по слоям.
¶ 15. Домашнее задание: мини-доклады по Linux-дистрибутивам
К следующей субботе каждый студент готовит короткое выступление на 3–5 минут по одному дистрибутиву Linux.
Возможные темы:
- Debian
- Ubuntu
- Fedora
- Rocky Linux
- AlmaLinux
- Arch Linux
- Alpine Linux
- openSUSE
- Gentoo
- ALT Linux
- Astra Linux
- РЕД ОС
- Linux Mint
- Kali Linux
- Oracle Linux
¶ Что нужно рассказать
- Кто развивает дистрибутив?
- Когда он появился?
- Самостоятельный он или производный?
- К какому семейству относится?
- Какой пакетный формат используется?
- Какой пакетный менеджер используется?
- Какая модель релизов?
- Для каких задач применяется?
- Где чаще встречается: desktop, server, security, embedded?
- Какие сильные стороны?
- Какие ограничения?
- Чем отличается от ALT Linux или другого выбранного дистрибутива?
Цель:
За несколько минут объяснить группе, что это за Linux, откуда он появился и зачем существует.
¶ 16. Что будет на следующем занятии
После мини-докладов:
Linux distributions
|
+--> Debian family
+--> Red Hat family
+--> Arch family
+--> independent
+--> Russian distributions
Затем отдельно разбираем ALT Linux и сразу переходим к практике:
Создать VM
|
Настроить vCPU / RAM / Disk / NIC
|
Подключить ALT Linux ISO
|
Запустить installer
|
Установить ALT Server без GUI
|
Первая загрузка
|
Первая CLI-сессия
После этого виртуализация перестанет быть только теорией: все следующие лабораторные будут выполняться внутри собственного виртуального стенда.
ЛИТАНИЯ ЗАВЕРШЕНИЯ ПРОТОКОЛА
«Команда, исполненная без понимания, есть лишь повторение.
Команда, исполненная с пониманием, есть знание.»
|| PROTOCOL COMPLETE :: KNOWLEDGE PRESERVED :: AVE OMNISSIAH ||
¶ ◀ НАВИГАЦИЯ ▶
Архетиктура ОС
Виртуализация
Семейства и дистрибутивы Linux