Что такое контейнер linux

Linux-контейнеры дома: зачем и как

Рассуждения

При упоминании словосочетания «контейнерная виртуализация», многим на ум сразу же приходят Virtuozzo и OpenVZ, а также Docker. Ассоциируется же это все, в первую очередь, с хостингом, VPS и другими подобными вещами.

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

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

Во вторую — это больший расход оперативной памяти. В третью — не самые удобные инструменты взаимодействия…

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

Что такое контейнеры и чем это все отличается от виртуализации? В случае контейнеров, не создается виртуальное аппаратное окружение, а используется изолированное пространство процессов и сетевого стека. Скажем так, получается chroot с расширенными возможностями.

Зачем это нужно:

— Для сборки ПО при нежелании захламлять разномастными *-dev пакетами основную рабочую систему.
— Потребность в другом дистрибутиве для запуска каких-либо специфических программ и, опять же, сборки.
— Изоляция потенциально небезопасного софта, вроде того же скайпа совершающего разные непонятные действия в домашнем каталоге пользователя и всяких сомнительных веб-технологий: уязвимость во флеше, в java, в обработчике pdf — это только то, что плавает на поверхности.
— Анонимность. Эдак можно банально остаться залогиненым в своей любимой социалочке, забыть подчистить куки или оказаться незнакомым с очередной новой веб-технологией вроде этой webrtc. Можно, конечно, держать несколько профилей браузера, но от перечисленных выше дыр и технологий это не защитит.

Итак, рассмотрим плюсы и минусы LXC:

+ Работает на ванильном ядре
+ Простота проброса устройств и каталогов хоста, так как работает это все через cgroups
+ Очень нетребовательно к ресурсам, в отличии от виртуальных машин типа Virtualbox или qemu

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

Развертывание и настройка контейнера

В первую очередь, ставим пакет lxc и все необходимые утилиты:

Смотрим доступные группы томов LVM:

Указываем использовать LVM в качестве системы хранения, Volume Group ( в моем случае — nethack-vg) и размер 2 гигабайта, иначе по умолчанию будет создан одногиговый том. Хотя, если вдруг стало тесновато, можно будет сделать lvresize.

Видим, что у нас появился том deb_test.

Типовой конфиг, созданный скриптом:

Залогинимся с указанным паролем. Для запуска в headless-режиме используется ключ -d, а рутовую консоль можно получить с помощью команды

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

На хосте прописываем в /etc/network/interfaces

В конфиг контейнера дописываем:

Понятно, что mac-адрес произвольный, на любой вкус.
Чтобы сразу получить рабочую сеть и возможность установки пакетов apt’ом, допишем

Понятно, что 192.168.18.1 — IP моего DNS.

Установим нужные пакеты:

Дальше либо на хосте, либо на другой рабочей виртуалке можно получить список установленных пакетов и установить их все в нашем новом контейнере:

Теперь можно по-человечески настроить сетевой интерфейс в контейнере, использовав любимый текстовый редактор:

Впрочем, это можно было сделать с хост-системы, например, смонтировав логический том. Способов много.

В принципе, в качестве DNS можно указать любой публичный, если не опасаетесь за свою приватность. Например, гугловские 8.8.8.8 и 8.8.4.4.

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

Попробуем подключиться через OpenVPN. Сразу же получаем ошибку:

Система пишет, что интерфейсы TUN/TAP недоступны по причине их отсутствия. Очевидно, что нужно разрешить гостевой системе использовать устройства хоста. Открываем конфигурационный файл контейнера, /var/lib/lxc/deb_test/config и добавляем туда строчку:

В контейнере выполняем:

Обратим внимание на 10:200 — это идентификатор типа устройств. Если выполним на хосте:

То увидим идентификаторы 10, 200. По ним и будем ориентироваться, разрешая доступ к устройства, например камере — video0.

Точно также добавляем остальные нужные устройства:

Для функционирования иксов и возможности их проброса через ssh, нужно добавить точку монтирования:

По аналогии можно примонтировать и другие, нужные каталоги и файлы:

Для воспроизведения звука, можно разрешить доступ к звуковому устройству, если карта многопоточная (с однопоточной при использовании dmix возникают проблемы с блокировкой):

А можно настроить pulseaudio на воспроизведение звука по сети, как это описано здесь. Кратко:

Отредактировать на хосте /etc/pulse/default.pa, дописав туда:

В итоге у нас получается вот такой конфиг:

Контейнер готов к использованию.

Использование

Доустановим, например, i2p с Tor’ом, если не сделали этого ранее, и сходу настроим privoxy:

Запускать графические приложения вроде браузера удобнее всего через ssh:

Также, разумеется, LXC предоставляет средства для клонирования контейнеров и снятия снапшотов.

Так, например, склонировать контейнер, файловая система которого будет являться LVM-снапшотом можно командой:

Будет создан контейнер deb_test2 с файловой системой, размещенной на LVM-снапшоте размером 200MB (под хранение diff’ов). Это будет точная копия deb_test, над которой можно провести пару экспериментов и, например, безболезненно удалить.

А вот lxc-snapshot с LVM в качестве хранилища, на версии lxc-1.0.6 почему-то не работает:

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

В данном случае создали read-only снапшот с именем deb_test_before_rm_rf размером 100MB. Что с ним делать дальше? Например, его можно сдампить посредством dd, перенести на другую машину вместе с конфигами контейнера, создать там том нужного размера и пролить тем же dd (cp, cat, итд) — эдакая «живая миграция».

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

Источник

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

LXC (Linux Containers)

LXC (англ. Linux Containers ) — механизм виртуализации на уровне операционной системы, позволяющий исполнять множество изолированных Linux-систем (контейнеров) в одной системе.

Ядро Linux может изолировать ресурсы (процессор, память, ввод/вывод, сеть и так далее) при помощи CGroups, не прибегая для этого к использованию виртуальных машин. Посредством CGroups изолируются так же деревья процессов, сеть, пользователи и файловые системы.

LXC комбинирует cgroups и пространства имён (namespace).

На данный момент использует LXC следующие возможности ядра:

• Kernel namespaces (ipc, uts, mount, pid, network and user)
• AppArmor и SELinux profiles
• Seccomp policies
• Chroot (using pivot_root)
• Kernel capabilities
• CGroups (Control Groups)

LXC используется в разнообразных проектах, в том числе в Docker.

LXC можно воспринимать как что-то среднее между chroot и полноценной виртуальной машиной, такой chroot на стероидах.

Содержание

Установка

1. Инсталлируем сразу все необходимые пакеты:

2. Монтирование cgroup. Пакет lxc зависит от пакета cgroup-lite, который монтирует каждую cgroup подсистему отдельно в /sys/fs/cgroup/ (в Debian и Ubuntu cgroup вручную монтировать не нужно), но если cgroup все же не смонтирован, то:

добавляем строку в /etc/fstab:

В принципе, точка монтирования не важна — можно создать любой каталог (например, sudo mkdir /cgroup) и сохранить соответствующую запись в /etc/fstab:

3. Проверяем правильность установки:

В достаточно длинном выводе команды не должно присутствовать сообщений об ошибках:

Команды

Примеры использования

Создание контейнера.

Реализуется через выполнение шаблонов, командой: lxc-create -t -n :

Файлы доступных шаблонов (для debian) находятся в каталоге /usr/share/lxc/templates/

После загрузки и инсталляции пакетов, контейнеры будут размещаться в /var/lib/lxc/ . В данном примере — это каталог /var/lib/lxc/test_01, в котором:

Файл config — файл конфигурации контейнера, а rootfs — каталог, в котором развернута файловая система ubuntu.

В команду lxc-create можно передать параметры, в том числе желаемую версию дистрибутива. Чтобы узнать, какие параметры принимает шаблон — следует выполнить lxc-create —template —help:

Запуск контейнера

Выполняется командой lxc-start -n :

В данном случае будет запущен контейнер с ubuntu и мы сразу же попадаем в консоль этой системы (по умолчанию, логин root, пароль root — после входа рекомендуется его сменить командой passwd).

Согласно документации, отключиться от консоли можно комбинацией клавиш ctrl-a q (в некоторых случая, например при использовании терминальных менеджеров типа tmux или screen, может не работать! в этом случае нужно проверить тип терминала и попробовать с терминалом TERM=vt100).

Если запустить контейнеры с ключом -d, контейнер будет работать в фоновом режиме без подключения к консоли:

Просмотр запущенных контейнеров

Просмотр состояния конкретного контейнера

Подключение к консоли запущенного контейнера

Выполняется командой lxc-console -n :

Для более комфортной работы, настроим доступ по ssh. Изначально командой lxc-console заходим на консоль контейнера и устанавливаем sshd (в случае выхода во внешнюю сеть, возможно потребуется скопировать содержимое /etc/resolv.conf из хост-машины), а также создаем нового пользователя user:

Впоследствии, для доступ к запущенному контейнеру достаточно:

Остановка контейнера

Изнутри остановить контейнер можно обычным способом, через shutdown, poweroff или reboot, извне — командой lxc-stop -n :

При этом контейнер нормально завершит свою работу (с сохранением изменений во всех открытых файлах).

Клонирование контейнера

Рекомендуется использовать команду lxc-clone -o -n

Хотя вместо lxc-clone можно воспользоваться обычным копированием каталогов (с последующим изменением файлов конфигурации — пути, hostname, MAC- и IP-адреса. )

Настройка сети

Согласно документации, существует 5 способов виртуализации сети:

loopback interface (type = empty)

Если в конфигурационном файле контейнера укажем настройки, наподобие:

То после старта, у виртуальной машины будет настроен только loopback interface:

Использование физического интерфейса (type = phys)

Если конфигурационный файл контейнера привести к виду:

то получим, по сути, проброс физического сетевого интерфейса (после старта контейнера, интерфейс eth1 исчезнет в хост-машине, а сеть перейдет под управление eth0 в виртуальной машине).

Использование сетевого стека хост-системы (type = veth)

Данная схема используется по умолчанию. При запуске контейнера с таким типом сети, на хост-машине создается специальный виртуальный интерфейс (в примере ниже, он называется veth-*). Этот виртуальный интерфейс фактически и использует контейнер для взаимодействия с внешней средой.

Рассмотрим несколько типовых случаев.

Трансляция ip-адресов

NAT уместно использовать в случае, когда на хост-машине имеется один статический ip (например, 192.168.0.186 на интерфейсе eth0) и несколько контейнеров, которым нужен выход в сеть через данный интерфейс. Условно, это можно проиллюстрировать следующей схемой:

Создадим сеть 10.0.0.0, в которой разместим виртуальные машины. Будем использовать пакет bridge-utils.

1. На хост-машине редактируем файл /etc/network/interfaces, дописывая блок настроек br0:

Для того, чтобы изменения были приняты, выполняем:

Внимание! В случае каких-либо ошибок, может пропасть сеть.

2. Правим файл /var/lib/lxc/test_01/config, дописывая блок настроек сети:

3. Добавляем в таблицу nat правило

4. Запускаем контейнер test_01. В результате, данный хост должен получить при старте ip=10.0.0.10 и через шлюз 10.0.0.1, и далее через 192.168.0.186 — выход в сеть.

Пункты 2-4 выполняем по аналогии для всех контейнеров сети.

Статические ip-адреса

Этот вариант уместно использовать, когда у каждого контейнера должен быть постоянный выделенный ip (и, соответственно, возможность заходить из инета внутрь контейнера напрямую).

Для настройки сети нужно создать bridge br0, который будет включать с одной стороны eth0 хост-машины, а с другой — виртуальный интерфейсы контейнеров:

1. На хост-машине отредактируем файл /etc/network/interfaces, дописывая блок настроек br0:

2. Правим файл /var/lib/lxc/test_01/config, дописывая блок настроек сети:

В результате будем иметь следующую картину (на хост-машине):

Результат вывода ifconfig внутри контейнера test_01:

Пункт 2 выполняем по аналогии для всех контейнеров сети.

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

Использование DHCP

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

1. Устанавливаем и настраиваем DHCP-сервер

2. Файл /etc/network/interfaces, примет вид:

3. В файле /var/lib/lxc/test_02/config, удаляем или комментируем все статические настройки сети:

Несколько виртуальных сетевых интерфейсов с разными MAC-адресами (type = macvlan)

При использовании схемы veth, все запущенные контейнеры, принадлежащие одной сети, видны и доступны друг-другу. Например, можно из хост-системы по ssh подсоединиться к машине 10.0.0.10, а из консоли этой машины — попасть на консоль 10.0.0.20 и т.д.

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

Для демонстрации, на хост-машине редактируем файл /etc/network/interfaces, дописывая блок настроек br0:

Файлы конфигурации каждого контейнера приводим к виду:

После запуска контейнеров можно убедиться в их статусе:

При использовании macvlan следует указать один из режимов:

lxc.network.macvlan.mode = vepa В данном режиме, контейнеры ни из хост-системы ни между собой даже не пингуются lxc.network.macvlan.mode = bridge Режим bridge создает особый мост (не то же самое, что стандартный Linux-bridge), который позволяет контейнерам общаться друг с другом, но изолирует их интерфейсы от хост-системы. lxc.network.macvlan.mode = private Данный режим запрещает любую связь между LXC контейнерами.

Ограничение ресурсов

Память

Чтобы ограничить выделяемую контейнеру память, необходимо в его конфигурационном файле добавить следующий параметр:

Как вариант, можно те же действия выполнить из командной строки (перечень всех параметров — см. в man lxc-cgroup):

Более подробно, см.:

Есть два параметра описывающих лимит процессора:

• lxc.cgroup.cpuset.cpus — выделение конкретного ядра/ядер
• lxc.cgroup.cpu.shares — приоритет (по умолчанию равно 1024)

В конфигурационном файле контейнера (выделяем под контейнер первых два ядра процессора):

Или то же из-под консоли:

Более подробно, см.:

Дисковые квоты: использование loopback-устройств

Если каталог контейнера будет размещён на отдельной файловой системе, её размер будет автоматически ограничен размером нижележащего блочного устройства. Файловая система может быть размещена на:

• файле (через loopback-устройство);
• томе LVM;
• томе btrfs;
• быть дисковым разделом;
• быть полноценным диском.

Последние два варианта, как правило, не используются из-за недостаточной их гибкости, хотя в некоторых случаях они вполне могут найти своё применение. Использование файлов считается более медленным чем непосредственное использование LVM или btrfs, посколько вводит дополнительный слой (файловую систему, на которой располагается сам файл), с другой стороны этот способ является наиболее гибким.

Использование LVM и btrfs помимо прочих преимуществ обладает ещё тем, что позволяет создавать снэпшоты устройств, а в случае с btrfs ещё и снэпшоты со снэпшотов, что облегчает задачу клонирования контейнеров.

Ниже подробно рассматривается, как можно использовать файл для хранения файловой системы LXC.

Создаем файл определенного размера (в примере ниже он называется disk и имеет размер 600Мб), форматируем его и монтируем средствами хост-машины. А далее в этот каталог (/var/fs) устанавливаем контейнер:

Естественно, команду монтирования можно прописать в /etc/fstab. Ну и следует не забывать указывать ключ lxcpath при работе с контейнером, например:

Запуск контейнеров поверх LVM

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

Подробнее об использовании LVM: LVM.

Проверка ограничений

Для начала проверим, куда смонтирована cgroup (по умолчанию — в /sys/fs/cgroup):

Данные по использованию памяти, процессора и пр., находятся в / /lxc/ / :

Что произойдёт с процессом если он превысит отведённые ему лимиты памяти? Как проверить? Проверить можно очень просто, можно просто создать процесс, который запрашивает необходимое количество памяти:

(программа ждёт пока будет нажато CTRL+D, но пока не надо нажимать)

Видно, что программа занимает чуть больше запрошенных 100 мегабайтов (пятая колонка, первый ряд).

Проброс устройств

Конфигурация контейнера

Конфигурация контейнера находится в файле

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

X-Server

Устанавливаем внутри контейнера графическую оболочку и софт для работы с удаленным рабочим столом по протоколу RDP:

Если сеть настроена для работы с NAT, то на хосте приводим правила iptables к следующему виду (10.0.0.100 — ip контейнера, 192.168.0.186 — статический ip хост-машины, 3389 — порт по умолчанию для работы xrdp):

В Windows заходим в «Пуск» -> «Все программы» -> «Стандартные» -> «Подключение к удаленному рабочему столу», вводим ip хост-машины; во время подключения — выбираем модуль «sesman-Xvnc» и вводим логин/пароль пользователя контейнера.

LXC без LXC

Функционал LXC фактически представлен механизмами ядра Linux и утилиты lxc, работающие в пространстве пользователя (userspace). Это означает, что контейнеры LXC в полной мере могут использоваться и без утилит lxc. Естественно, что в этом случае потребуется какая-то другая программа/система, выполняющая управление ими.

libvirt

libvirt LXC-драйвер не использует никакие утилиты LXC и никак не зависит от них.

Возможности ядра, необходимые для работы LXC:

• control groups (требуемые контроллеры: cpuacct, memory, devices; рекомендуемые: cpu, freezer, blkio);
• namespaces (требуются mount, ipc, pid и uts; если используется собственная сеть в контейнере, то ещё требуется net).

Подробнее о возможностях драйвера контейнеров LXC библиотеки libvirt:

libcontainer

LXC в сравнении с другими проектами

LXC vs OpenVZ

OpenVZ — виртуализация уровня операционной системы. Технология базируется на ядре ОС Linux и позволяет на одном физическом сервере создавать и запускать изолированные друг от друга копии выбранной операционной системы (Debian, CentOS, Ubuntu). Установка другой ОС невозможна, так как виртуальные серверы используют общее ядро Linux. [Источник 1]

Технология отличается легкостью управления сервером: пользователь может в личном кабинете самостоятельно добавить количество ресурсов (память, процессор, жесткий диск) или перейти на другой тариф с той же виртуализацией. Изменения ресурсов применяются автоматически, без перезагрузки сервера.

На серверах с виртуализацией OpenVZ запрещается запускать: [Источник 2]

• сервисы для организации проксирования любого вида трафика
• сервисы потокового вещания
• игровые серверы
• системы или элементы систем распределённых вычислений (например, bitcoin mining)
• сервисы массовой рассылки почтовых сообщений, даже если они используются в легальных целях
• Java-приложения
• иные ресурсоёмкие приложения

Такие проекты создают неравномерную нагрузку на родительском сервере и могут мешать соседним виртуальным машинам.

Отличительные черты OpenVZ

Ввиду того, что OpenVZ использует одно ядро для всех VE, система является столь же масштабируемой, как обычное ядро Linux 2.6, то есть поддерживает максимально до 4096 процессоров и до 64 ГБ оперативной памяти для x86-версии (с использованием PAE) и 64ТБ для x86-64. Единственная виртуальная среда может быть расширена до размеров всего физического сервера, то есть, использовать все доступное процессорное время и память.

OpenVZ способна размещать сотни виртуальных сред на современном аппаратном обеспечении. Основными ограничивающими факторами являются объём ОЗУ и частота процессора.

Владелец физического сервера с OpenVZ (root) может видеть все процессы и файлы всех VE. Эта особенность делает возможным массовое управление, в отличие от других технологии виртуализации (например VMware или Xen), где виртуальные серверы являются отдельными сущностями, которыми невозможно напрямую управлять с хост-системы.

Технология	Разработчик	Лицензия	Production статус	Тип изоляции (Isolation)	Уровень интеграции в ядро Linux	Поддерживаемые клиентские ОС	Поддерживаемое оборудывание
Linux Containers, LXC	Kernel.org: Intel, IBM, Google, Parallels	GPLv2	готова, 2.0.7	os-level virtulization, containerization	полная, mainstream	Только Linux	Аналогично Linux без исключений
OpenVZ	SwSoft, Parallels	GPLv2	готова, 2.6.18 и 2.6.32	os-level virtulization, containerization	90% интеграция в mainstream и активная работа	Только Linux	Аналогично Linux без исключений

LXC vs Xen

Xen — это монитор виртуальных машин (VMM, Virtual Machine Monitor) или гипервизор (hypervisor) с поддержкой паравиртуализации (para-virtualization) для процессоров x86 архитектуры, распространяющийся с открытым исходным кодом (opensource). Xen может организовать совместное безопасное исполнение нескольких виртуальных машин на одной физической системе с производительностью близкой к непосредственной (native). [Источник 3] Впервые разработанный еще Кэмбриджскими студентами, данный проект быстро стал коммерческим благодаря своей перспективности. Кроссплатформенность и широкий функционал Xen делает его возможности достаточно обширными для применения в офисах крупных компаний и корпораций. Его ядро обладает режимом паравиртуализации, то есть его можно настроить на одновременное взаимодействие с гипервизором.

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

Технология	Разработчик	Лицензия	Production статус	Тип изоляции (Isolation)	Уровень интеграции в ядро Linux	Поддерживаемые клиентские ОС	Поддерживаемое оборудывание
Linux Containers, LXC	Kernel.org: Intel, IBM, Google, Parallels	GPLv2	готова	os-level virtulization, containerization	полная, mainstream	Только Linux	Аналогично Linux без исключений
Xen	XenSource, Citrix, XenProject	GPLv2	готова	para/full virtualization	DomU (клиент) код с 2012 года, DomO (сервер)-не планируется	Linux, Windows, FreeBSD	Согласно списку совместимости оборудывания (HCL), сильно меньше, чем у обычного Linux. Также требуется аппаратная поддержка виртуализации AMD-V, Intel-VT

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

• обязательная перезагрузка сервера после изменения конфигурации;
• сложная схема администрирования;
• необходимость использования дополнительных утилит из пакетов Xen;
• высокая стоимость серверов.

LXC vs KVM

KVM (Kernel-based Virtual Machine) — программное решение, обеспечивающее виртуализацию в среде Linux на платформе x86, которая поддерживает аппаратную виртуализацию на базе Intel VT (Virtualization Technology) либо AMD SVM (Secure Virtual Machine).

Технология	Разработчик	Лицензия	Production статус	Тип изоляции (Isolation)	Уровень интеграции в ядро Linux	Поддерживаемые клиентские ОС	Поддерживаемое оборудывание
Linux Containers, LXC	Kernel.org: Intel, IBM, Google, Parallels	GPLv2	готова	os-level virtulization, containerization	полная, mainstream	Только Linux	Аналогично Linux без исключений
KMV	RedHat (ранее Qumranet), OVA	GPLv2	готова	full virtualization	полная, mainstream (весь код поддерживается в коде ядра) с 2007 года	Linux, Windows, FreeBSD	аналогично Linux, но требуется аппаратная поддержка виртуализации AMD-V/Intel-VT

Производительность KVM при увеличении нагрузки уменьшается быстрее, чем у Xen (если верить результатам тестирования). Xen отличает масштабируемость – способность поддерживать большое число одновременно работающих ВМ. Считается, что Xen превосходит KVM по возможностям резервного копирования и управления хранением данных.

Подобная дилемма возникает и при анализе предложений по аренде виртуальных серверов (VDS/VPS). Хостеры предлагают разнообразные средства виртуализации, включая Xen, KVM, Microsoft Hyper-V, OpenVZ, Virtuozzo, VDSmanager и др. (VMware – очень редко ввиду высокой стоимости), при этом провайдер всегда готов рассказать о достоинствах используемой системы, но продукты виртуализации редко сравнивают и столь же редко упоминают об их недостатках.

Первоначально KVM поддерживал только процессоры x86, но в настоящее время к ним добавился широкий спектр процессоров и гостевых операционных систем, в том числе множество вариаций Linux, BSD, Solaris, Windows, Haiku, ReactOS и AROS Research Operating System. [Источник 5]

В числе пользователей KVM – известные Wiki-ресурсы: MediaWiki, Wikimedia Foundation, Wikipedia, Wikivoyage, Wikidata, Wikiversity. В 2015 году «Лаборатория Касперского» совместно с B2B International провела исследование, в ходе которого представителям компаний, использующих технологию виртуализации задавались вопросы про применяемые у них платформы. Выяснилось, что 15% компаний используют различные варианты коммерческих платформ на базе KVM, и еще 16% планируют их внедрять в течение ближайшей пары лет. Бесплатные версии продукта используются в 8% крупных организаций и еще в 16% опрошенных компаний будут внедрены в будущем.

Исследование «Лаборатории Касперского» показало, что если основными гипервизорами, чаще всего, являются VMware vSphere и Microsoft Hyper-V, то в качестве дополнительного предпочитают использовать решения с открытым кодом или коммерческие решения на базе Open Source. Особенно часто — KVM.

В «Лаборатории Касперского» считают, что причин популярности KVM несколько. Во-первых, в некоторых сценариях, внедрение платформы виртуализации на базе KVM (даже коммерческой ее версии) обходится значительно дешевле, чем использование Microsoft Hyper-V и VMware vSphere. Во-вторых, в мире растет количество виртуализированных Linux-серверов. Их владельцам привычнее и удобнее применять и гипервизор на базе Linux. В большинстве случаев, это именно KVM. Кроме того, Linux-сообщество вносит вклад в развитие платформы, развивается экосистема решений, которые поддерживающих KVM.

Компании, создающие собственные проекты, интегрированные решения, зачастую выбирают гипервизор Open Source, а KVM как раз предоставляет широкие возможности кастомизации. Наконец, KVM — легкий, простой в использовании, неприхотливый к ресурсам и при этом достаточно функциональный гипервизор. Он позволяет в сжатые сроки развернуть платформу виртуализации, констатируют в «Лаборатории Касперского».

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

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

Источник