контейнер lxc что это
Контейнеризация на Linux в деталях — LXC и OpenVZ. Часть 1
В прошлой статье мы начали разговор о преимуществах контейнерной изоляции (контейнеризации), теперь мне бы хотелось углубится в технические аспекты реализации контейнеров.
Контейнеризация в Linux
Механизмы, которые обеспечивают работу контейнеров внутри ядра, называются namespaces (вот хороший обзор данной функциональности). Кроме этого, за ограничения различных ресурсов контейнера (объем занимаемой памяти, нагрузка на диск, нагрузка на центральный процессор) отвечает механизм ядра — cgroups (обзор). А в свою очередь обе эти технологии для удобства повествования я решил объединить под названием Linux upstream containers, то есть контейнеры из актуальной версии Linux ядра с kernel.org.
Если же говорить о пространстве пользователя, то такие пакеты как LXC, systemd-nspawn и даже vzctl (утилита из проекта OpenVZ) занимаются исключительно тем, что создают/удаляют namespac’ы и конфигурируют для них cgroup’ы.
Что такое OpenVZ?
Если с Linux upstream containers все более-менее понятно, так как они входят в ядро Linux, то для OpenVZ потребуются пояснения. OpenVZ — это open source проект развиваемый компанией Parallels (называвшейся ранее SwSoft) с 2005 года (уже более 8 лет) и занимающийся разработкой и поддержкой production ready решения по контейнеризации на базе ядра Linux (патчи накладываются на ядра от RHEL).
Данный проект состоит из двух частей — Linux ядра с патчами от компании Parallels (vzkernel), а также набора утилит для управления ядром (vzctl, vzlist и проч). Так как модифицированное ядро от OpenVZ строится на базе ядра Red Hat Enterprise Linux, то логично предположить, что рекомендованная ОС для OpenVZ — это RedHat либо CentOS. Также недавно была осуществлена очень большая работа по предоставлению поддержки OpenVZ в Debian 7 Wheezy, но со своей стороны я все равно рекомендуют использовать OpenVZ исключительно на CentOS 6.
На данный момент в мире насчитывается более 25 тысяч серверов (стоит отметить, что в связи с особенностями сбора статистики, данные несколько занижены) с установленным OpenVZ, подробную статистику можно увидеть тут: https://stats.openvz.org/ 
История развития OpenVZ
История развития Linux upstream containers
Две фундаментальных технологии лежат в основе Linux upstream containers — это namespaces и cgroups. Фреймворк namespaces в виде mount namespace был впервые представлен в 2000 году известным разработчиком Al Viro (Alexander Viro). В свою же очередь фреймворк cgroup был разработан в Google, с участием инженеров Paul Menage и Rohit Seth.
Также очень большой вклад в разработку новых подсистем namespaces/cgroups внесли разработчики проекта OpenVZ. В частности, namespace’ы PID и Net были разработаны в контексте проекта OpenVZ. Кроме этого, недавно был переведен в стабильную фазу фреймворк Criu для сериализации/десериализации наборов работающих Linux процессов lwn.net/Articles/572125, разрабатывался он также в контексте решения задач для OpenVZ.
Если Вы хотите оценить вклад самостоятельно, предлагаю два документа — отчет о вкладе компаний в разработку ядра в 2013 году и аналогичный отчет за 2012й год: Parallels там имеет вклад 0.7% и 0.9% соответственно. Может показаться, что 1% — это мало, то хотелось бы напомнить, что размер правок в год достигает нескольких миллионов строк.
Если Вы уже используете OpenVZ и у Вас есть что сообщить (баги) или чем поделиться (патчи), то милости прошу в баг-трекер OpenVZ Каждый Ваш бег репорт улучшает стабильность и качество проекта для всех его пользователей!
Техническая реализация подсистемы изоляции контейнеров
Тут я хотел бы пойти по пути, через который, уверен, проходил каждый системный администратор, у которого стояла задача «изолировать пользователей друг от друга» в пределах одного Linux сервера.
Итак, допустим у нас имеется два веб-приложения, которые принадлежат разным клиентам (обращаю внимание, я тут не использую термин «пользователи», чтобы не было путаницы с Linux пользователями) и не должны никак влиять друг на друга (например, при взломе, перегрузке, исчерпании ресурсов) и тем более на сам физический сервер.
Давайте последовательность предпринимаемых шагов представим в виде списка:
Что ждать в продолжении?
Отдельно хотелось бы поблагодарить Andrey Wagin avagin за помощь в редактуре особо сложных технических вопросов.
С уважением,
CTO хостинг-компании FastVPS
Павел Одинцов
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
LXC, LXD и LXCFS – в чем разница?
О LXC
Важные характеристики
Текущая версия LXC задействует ряд функций ядра, чтобы обеспечить контейнеризацию следующих процессов:
Как правило, контейнеры LXC обычно воспринимаются пользователями как нечто усредненное между Chroot и VM. Эта технология нацелена на то, чтобы создать среду, аналогичную стандартно установленной Linux, но сделать это без необходимости в дополнительном ядре.
Компоненты
Ниже в списке, несколько актуальных компонентов LXC:
LXD (Linux Container Daemon) является базирующимся на LXC гипервизором контейнеров.
Основные части LXD:
REST API предоставляется демоном в локальном или сетевом режиме. Эффективная утилита управления, клиент командной строки, отличается своей интуитивностью и простотой. Именно с помощью него реализовано управление каждым контейнером. Клиент обрабатывает подключение одновременно к разному количеству контейнеров, отображает уже созданные и создает новые. Есть возможность их перемещения в процессе функционирования.
Упомянутый плагин “превращает” все LXD-host в вычислительные узлы, которые работают для поддержки контейнеров, а не VM.
Преимущества
Основные преимущества LXD:
Связь с LXC
LXCFS: настройка контейнеризации
LXCFS включает в себя:
Так в чем же разница?
Сравнивать LXC, LXD, LXCFS не имеет смысла, так как они не представляют из себя 3 разных продукта с одинаковым функционалом. Грубо можно описать их как программу, дополнение к ней и патч, который позволяет среде пользователя адаптироваться под ее нужды.
Онлайн курс по Linux
Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps
Создание LXC-контейнеров с общей файловой базой
Применение легковесных контейнеров LXC в настоящий момент довольно ограничено главным образом по причине их «сырости». Применять их в production – удел настоящих джедаев. Под production в данном случае подразумевается непосредственное предоставление услуг клиентам.
Однако для простого разделения сервисов и контроля ресурсов такие контейнеры вполне подходят с некоторыми допущениями. Например, мы полагаем, что root в контейнере равен root в целевой системе.
В статье будет показано, как можно быстро создавать легковестные контейнеры на локальном диске с общими файлами без использования LVM-снапшотов.
Кратко о сути контейнеров LXC
LXC является средством для реализации виртуальных контейнеров в ядре Linux. По сути своей LXC – это просто набор userspace утилит, которые эксплуатируют реализованные в ядре возможности. Как таковое понятие LXC в ядре Linux отсутствует.
Двумя основные составляющими контейнера являются пространства имен (namespaces) и контрольные группы (cgroups). Первые обеспечивают изоляцию процессов контейнера друг от друга, а вторые отвечают за ограничение ресурсов, выделенных контейнеру.
К настоящему моменту, действующими пространствами имен являются:
К слову сказать, последний namespace обещают окончательно допилить к версии ядра 3.9
Этих пространств вполне достаточно, чтобы контейнеры чувствовали себя независимыми.
Изначально все процессы в системе используют общие пространства имен. Создавая новый процесс, мы можем указать ядру склонировать нужные нам пространства имен для этого процесса. Это достигается путем указания специальных флагов CLONE_NEW* вызова clone(). Указывая этот флаг для определенного пространства имен при создании процесса, мы добиваемся того, что процесс будет создан в своем собственном пространстве имен. Именно так и работают утилиты LXC, создавая новый контейнер.
Отделить пространство имен существующего процесса можно с помощью вызова unshare(). Целиком заменить одно пространство имен процесса на другое можно с помощью setns(), но для этого вызова требуется поддержка новых ядер (>3.0).
Именно setns() используется для того, чтобы «впрыгнуть» в контейнер.
Контрольные группы, как и пространтсва имен, реализованы в ядре. В пространстве пользователя их использование доступно LXC с помощью интерфейса специальной файловой системы cgroup. LXC-утилиты создают каталог в этой файловой системе с именем контейнера, а затем записывают pid процессов в файлы контрольных групп. Поэтому имя контейнера по сути есть имя контрольной группы.
Подготавливаем систему к созданию контейнеров LXC
Пропустим этот шаг, поскольку о нем много где рассказано. Например, здесь. Суть конфигурации заключается в сборке ядра с нужными опциями и установке userspace утилит.
К счастью, многие ядра современных дистрибутивов уже собраны с этими опциями, поэтому пересборка скорее всего не понадобится.
Если Вы привыкли использовать libvirt для управления виртуализацией, то есть хорошая новость – libvirt полностью поддерживает LXC. В статье о нем рассказано не будет, чтобы быть «ближе к телу».
Создаем основу файловой системы для контейнеров
Обычно делают так: создают некое базовое устройство LVM, а уже на его основе создают отдельные снапшоты для файловых систем каждого контейнера. Таким образом, это позволяет экономить дисковое пространство за счет того, что снапшот занимает место только на величину измененных блоков.
Вместо lvm, как вариант, возможно, использование файловой системы поддерживающей снапшоты, например btrfs.
Но у этого метода есть существенный недостаток: дисковые операции на запись с lvm-снапшотами крайне медленные.
Поэтому для определенных задач можно использовать следующий способ:
Приступим. В качестве базового контейнера будем использовать тот же LVM (хотя это совсем необязательно):
После окончания копирования, приступим к созданию неизменяемой части. Назовем ее common:
После этого удаляем start_udev из /etc/rc.sysinit, отключаем ненужные сервисы, и по своему усмотрению проводим дополнительные настройки. Убираем hostname из конфигурационных файлов, чтобы он не переопределялся при старте контейнера.
Смонтируем файловую систему cgroup, с помощью которой будет происходить ограничение ресурсов контейнера. Данный процесс будет происходить путем создания директории с именем контейнера внутри файловой системы. Директорию будут создавать (и удалять) утилиты LXC.
Мы явно указываем контроллеры, которые хотим монтировать, поскольку по-умолчанию в дистрибутивах Centos6/RHEL6 монтиоруется контроллер blkio, который не поддерживает вложенные иерархии, необходимые для работы LXC. В Ubuntu/Debian с этим проблем нет.
Теперь создадим сетевой мост, в который будут подключаться все контейнеры. Будьте внимательны, при выполнении операции пропадает сеть.
Все новые виртуальные интерфейсы контейнеров будут включаться в этот новый мост.
Не забудем отразить все изменения в стартовых конфигурационных файлах дистрибутива.
Создаем контейнер LXC
После подготовки базового образа системы мы можем приступить непосредственно к созданию первого контейнера в системе. Назовем его просто lxc-container.
Процедура создания контейнера включает в себя три простых этапа:
Настроим fstab для нашего контейнера:
Теперь подготовим файловую систему для нашего первого контейнера lxc-container, используя ранее созданную неизменяемую часть базового образа.
Последние две строчки не получается объединить в одну. Ну и ладно.
Как видно, здесь выявляется главный недостаток (или главное преимущество) описываемого метода. Базовая часть файловой системы внутри контейнера – read-only.
И наконец самое главное – конфигурационный файл контейнера. В указанном примере мы полагаем, что lxc-утилиты установлены в корень системы
Обратите внимание, мы запретили доступ ко всем устройствам, кроме явно указанных, а также ограничили память и своп. Несмотря на это действующее ограничение утилиты free, top внутри контейнера будут показывать полную физическую память.
Не забудем отразить все изменения в стартовых конфигурационных файлах дистрибутива, иначе они все потеряются после перезагрузки!
Запускаем контейнер LXC
Настало время запустить наш свежесозданный контейнер. Для этого воспользуемся утилитой lxc-start, передав ей в качестве аргумента имя нашего контейнера:
Подключаемся к контейнеру LXC
В LXC существует проблема с прыжком в контейнер из физического сервера.
lxc-attach, предназначенная для этого, работает только с патченным ядром. Патчи реализуют функционал для определенных пространств имен (а именно, mount-namespace и pid-namespace). Сами патчи можно скачать по ссылке.
Функционал прыжка реализуется специальным системным вызовом setns(), который привязывает сторонний процесс к существующим пространствам имен.
Заменить прыжок в контейнер может lxc-console, которая подключается к одной из виртуальных консолей контейнера
И перед нами консоль контейнера /dev/tty2
Устройство /dev/tty2 имеет major-номер 136, и не является «настоящим tty». Это устройство обслуживается драйвером псевдотерминала, мастер которого, читается на физическом сервере, а слейв – на контейнере. То есть наш /dev/tty2 является обычным устройством /dev/pts/3
И, конечно, можно подключаться по ssh:
Эксплуатация LXC
Это очень интересная, но отдельна тема обсуждения. Здесь можно отметить, что часть задач по администрированию контейнеров берут на себя утилиты LXC, но можно вполне обойтись и без них. Так, например, можно посмотреть список процессов в системе с разбиением на контейнеры:
cgroup в данном случае совпадает с именем контейнера
Linux-контейнеры: когда контейнеров становится больше
В прошлой статье я вкратце рассказал о том, что такое контейнерная виртуализация, LXC в частности, зачем это нужно и как это все по-быстрому настроить.
В процессе использования, количество контейнеров постепенно растет. При этом, одни могут быть клонами других, и плюс ко всему, построены на снапшотах. Возникает естественное желание: облегчить себе процедуру управления этим контейнерным складом.
Это только то, что живет на личном лаптопе.
Настройка командной оболочки
В первую очередь, хочется избавиться от необходимости каждый раз вводить sudo/su и получить доступ к утилитам управления LXC из-под своего пользователя.
Тут сразу возникает естественная мысль понаделать алиасов оболочки. Что и было проделано:
lxc.alias
Подойдет как для zsh, так и для bash. Для активации, потребуется прописать source /path/to/lxc.alias в
Второе — прописать выполнение всех этих команд в /etc/sudoers.d с разрешением на выполнение без ввода пароля:
/etc/sudoers.d/lxc
Здесь «user» — имя вашей учетной записи.
Настройка локального DHCP-сервера
Следующее, что хотелось бы сделать: дать возможность нашим контейнерам получать настройки сети в автоматическом режиме, без нудного редактирования персональных конфигов. Немножко погуглив, я наткнулся на вот эту статью.
Рецепт был творчески переосмыслен и взят на вооружение, но кое-что пришлось поправить. Что именно, поведаю далее.
Первое, что нужно сделать — это установить сам dhcp-server.
Если настраивали по моей прошлой статье, то трогать /etc/network/interfaces не нужно. На всякий случай, напомню, как он выглядит:
/etc/network/interfaces
Вместо того, чтобы править конфиг каждого контейнера, отредактируем глобальный:
/etc/lxc/default.conf
Прописывать здесь шлюзы, маски подсети, DNS и тем более mac-адреса не нужно. Все это выдадут dhcp-сервер и lxc.
/etc/default/isc-dhcp-server
То есть, просто укажем интерфейс, на котором dhcpd будет работать.
Открываем файл /etc/dhcp/dhcpd.conf, находим там закоментированные директивы вида subnet и дописываем туда следующее:
/etc/dhcp/dhcpd.conf
DNS я указал гугловские. Понятно, что каждый может выбрать по вкусу, например отсюда или использовать свой локальный.
Итоги
В результате вышеприведенных действий, манипуляции с контейнерами становятся гораздо приятнее: пропала нужда править конфиг каждого контейнера да и вообще вводить лишние буковки с клавиатуры.
Контейнер lxc что это
LXC (Linux Containers) — механизм виртуализации на уровне операционной системы, позволяющий исполнять множество изолированных Linux-систем (контейнеров) в одной системе.
Ядро Linux может изолировать ресурсы (процессор, память, ввод/вывод, сеть и так далее) при помощи cgroups, не прибегая для этого к использованию виртуальных машин. Посредством cgroups изолируются так же деревья процессов, сеть, пользователи и файловые системы.
LXC комбинирует cgroups и пространства имён (namespace).
На данный момент использует LXC следующие возможности ядра:
LXC используется в разнообразных проектах, в том числе в Docker.
LXC можно воспринимать как что-то среднее между chroot и полноценной виртуальной машиной, такой chroot на стероидах.
Содержание
[править] Установка
1. Инсталлируем сразу все необходимые пакеты:
2. Монтирование cgroup. Пакет lxc зависит от пакета cgroup-lite, который монтирует каждую cgroup подсистему отдельно в /sys/fs/cgroup/ (в Debian и Ubuntu cgroup вручную монтировать не нужно), но если cgroup все же не смонтирован, то:
добавляем строку в /etc/fstab:
3. Проверяем правильность установки:
В достаточно длинном выводе команды не должно присутствовать сообщений об ошибках:
[править] Команды
[править] Примеры использования
[править] Создание контейнера.
Файлы доступных шаблонов (для debian) находятся в каталоге /usr/share/lxc/templates/
Например, скачивание и установка шаблона ubuntu может быть выполнена следующим образом:
[править] Запуск контейнера
В данном случае будет запущен контейнер с ubuntu и мы сразу же попадаем в консоль этой системы. Как правило, логин root, а пароль генерируется случайный:
Читать вывод на консоль в последней строке запуска контейнера (иногда логин и пароль root:root либо ubuntu:ubuntu. ). После входа рекомендуется его сменить командой passwd.
Согласно документации, отключиться от консоли можно комбинацией клавиш ctrl-a q (в некоторых случая, например при использовании терминальных менеджеров типа tmux или screen, может не работать! в этом случае нужно проверить тип терминала и попробовать с терминалом TERM=vt100).
Если запустить контейнеры с ключом -d, контейнер будет работать в фоновом режиме без подключения к консоли:
[править] Просмотр запущенных контейнеров
[править] Просмотр состояния конкретного контейнера
[править] Подключение к консоли запущенного контейнера
Для более комфортной работы, настроим доступ по ssh. Изначально командой lxc-console заходим на консоль контейнера и устанавливаем sshd (в случае выхода во внешнюю сеть, возможно потребуется скопировать содержимое /etc/resolv.conf из хост-машины), а также создаем нового пользователя user:
Впоследствии, для доступ к запущенному контейнеру достаточно:
[править] Остановка контейнера
При этом контейнер нормально завершит свою работу (с сохранениями изменений во всех открытых файлах).
[править] Клонирование контейнера
[править] Настройка сети
Согласно документации, существует 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 правило:
Пункты 2-4 выполняем по аналогии для всех контейнеров сети.
[править] Статические ip-адреса
Этот вариант уместно использовать, когда у каждого контейнера должен быть постоянный выделенный ip (и, соответственно, возможность заходить из инета внутрь контейнера напрямую).
1. На хост-машине отредактируем файл /etc/network/interfaces, дописывая блок настроек br0:
2. Правим файл /var/lib/lxc/test_01/config, дописывая блок настроек сети:
В результате будем иметь следующую картину (на хост-машине):
Результат вывода ifconfig внутри контейнера test_01:
Пункт 2 выполняем по аналогии для всех контейнеров сети.
[править] Использование DHCP
Сеть может быть настроена как статически в контейнерах, так и динамически и помощью DHCP-сервера, запущенного на хост-машине. Такой DHCP-сервер должен быть сконфигурирован для ответа на запросы на интерфейсе br0:
1. Устанавливаем и настраиваем DHCP-сервер
2. Файл /etc/network/interfaces, примет вид:
3. В файле /var/lib/lxc/test_02/config, удаляем или комментируем все статические настройки сети:
[править] Несколько виртуальных сетевых интерфейсов с разными MAC-адресами (type = 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 контейнерами.
[править] Ограничение ресурсов
[править] Память
Чтобы ограничить выделяемую контейнеру память, необходимо в его конфигурационном файле добавить следующий параметр:
[править] CPU
Есть два параметра описывающих лимит процессора:
В конфигурационном файле контейнера (выделяем под контейнер первых два ядра процессора):
Или то же из-под консоли:
[править] Дисковые квоты: использование loopback-устройств
Если каталог контейнера будет размещён на отдельной файловой системе, её размер будет автоматически ограничен размером нижележащего блочного устройства. Файловая система может быть размещена на:
Последние два варианта, как правило, не используются из-за недостаточной их гибкости, хотя в некоторых случаях они вполне могут найти своё применение. Использование файлов считается более медленным чем непосредственное использование LVM или btrfs, посколько вводит дополнительный слой (файловую систему, на которой располагается сам файл), с другой стороны этот способ является наиболее гибким.
Использование LVM и btrfs помимо прочих преимуществ обладает ещё тем, что позволяет создавать снэпшоты устройств, а в случае с btrfs ещё и снэпшоты со снэпшотов, что облегчает задачу клонирования контейнеров.
Ниже подробно рассматривается, как можно использовать файл для хранения файловой системы LXC.
Создаем файл определенного размера (в примере ниже он называется disk и имеет размер 600Мб), форматируем его и монтируем средствами хост-машины. А далее в этот каталог (/var/fs) устанавливаем контейнер:
Естественно, команду монтирования можно прописать в /etc/fstab. Ну и следует не забывать указывать ключ lxcpath при работе с контейнером, например:
[править] Запуск контейнеров поверх LVM
Принципиально данный способ не отличается от предыдущего: изначально подготавливается логический том требуемого размера, в который далее инсталлируется контейнер LXC.
Подробнее об использовании LVM: LVM.
[править] Проверка ограничений
Данные по использованию памяти, процессора и пр., находятся в / /lxc/ / :
Что произойдёт с процессом если он превысит отведённые ему лимиты памяти? Как проверить? Проверить можно очень просто, можно просто создать процесс, который запрашивает необходимое количество памяти:
Видно, что программа занимает чуть больше запрошенных 100 мегабайтов (пятая колонка, первый ряд).
[править] Проброс устройств
[править] Конфигурация контейнера
Конфигурация контейнера находится в файле
Конфигурация контейнера описывает всевозможные аспекты его существования, начиная от доменного имени, IP-адреса и заканчивая ограничениями всех ресурсов, которые он использует.
[править] X-Server
Устанавливаем внутри контейнера графическую оболочку и софт для работы с удаленным рабочим столом по протоколу RDP:
[править] LXC без LXC
Функционал LXC фактически представлен механизмами ядра Linux и утилиты lxc, работающие в пространстве пользователя (userspace). Это означает, что контейнеры LXC в полной мере могут использоваться и без утилит lxc. Естественно, что в этом случае потребуется какая-то другая программа/система, выполняющая управление ими.
[править] libvirt
libvirt LXC-драйвер не использует никакие утилиты LXC и никак не зависит от них.
Возможности ядра, необходимые для работы LXC:
Подробнее о возможностях драйвера контейнеров LXC библиотеки libvirt:
[править] libcontainer
[править] LXC в сравнении с другими проектами
[править] LXC vs OpenVZ
Хотя и немного устаревшую, но всё же полезную информацию на эту тему можно найти здесь: