Какую систему виртуализации выбрать?

Возьми lxc - под требования подходит. Кроме того, есть в апстримном ядре.

Как реализовано их управление через консоль не представляю (по аналогии с chroot — консольная сессия, или процесс в фоне, который не связан с терминалом?).

Есть оба варианта.

Нужна система виртуализации для конкретной задачи: тестовая установка ПО.

А вообще, посмотри docker.

Посоветую Proxmox: kvp+openvz, выберешь удобное сам

OpenVZ. Если использовать simfs будет возможность онлайн и офлайн доступа к дереву вм. Если использовать ploop (рекомендуется) то в случае если контейнер остановлен для доступа к его фс, необходимо ее смонтировать, делается просто одной штатной командой.

Oracle VM server

возможность оффлайн доступа к дереву ФС виртуальной среды из родительской системы

Это к контейнерам. Если в виртуалке надо гонять только линуксы и не надо шаманить с ядром то контейнеры подходят.
Есть в ванильном ведре, довольно прост в управлении. При желании можно использовать всяческие надстройки вроде докера, но зачем?

LXC, под твои задачи - самое оно.

Насколько я понял, у тебя и гость и хост - Linux. Тогда Docker - идеальный вариант, он как раз и делался для выполнения процессов в изолированной среде. Но можно пускать и сервисы, подробнее в google:docker+supervisord

Ну или lxc, openvz для тестинга нафиг не нужен

Например, он имеет репозиторий куда можно запушить образ для разработчиков

OpenVZ, но так как его нет в апстрим ядре, то LXC.

на сайте lxc сказано, что из-за ограничений в unprivileged контейнере нужна специально собранная под lxc система, т.е. обычные дистрибутивы не будут работать. в чём конкретно заключается эта специфика в сборке системы (кроме поддержки в ядре)?

lxc. Просто работает «из коробки» и не требует в нормальных дистрибутивах дополнительных телодвижений.

Заходить на виртуальную машину можно через lxc-console, lxc-attach или как на любой отдельный комп по ssh/ftp/etc. Файлы в простейшем случае могут просто лежать в файловой системе хоста, тогда к ним лазить можно с хоста как к родным, как в случае chroot.

из-за ограничений в unprivileged контейнере нужна специально собранная под lxc система, т.е. обычные дистрибутивы не будут работать

Gentoo, Ubuntu, CentOS — всё работает «из коробки», не требуя никакой специальной сборки. Разве что в CentOS надо iptables ручками настраивать, чтобы сеть наружу выходила (в Gentoo и Ubuntu оно работает сразу)

Тогда Docker - идеальный вариант

Docker требует особой идеологии в работе. Если его использовать просто как виртуальные машины, будет неэффективно и неудобно. Для этого чистый lxc лучше.

Docker хорош, когда тебе нужно много типовых контейнеров из расчёта одна задача/один сервис на контейнер.

Так чуваку нужно выполнить код и получить выхлоп, в Docker это одна команда

Так чуваку нужно выполнить код и получить выхлоп, в Docker это одна команда

Только при наличии нужного образа. Ты уверен, что в дефолтовых имиджах будет вся необходимая обвязка? А если ему состояние нужно сохранять? Скажем, БД потребуется наполненная?

А тут — более того: «возможность оффлайн доступа к дереву ФС виртуальной среды из родительской системы»

Да, в Docker можно мапить родительские каталоги на внутренние. Но это начинают уже плодиться специфичные сущности. И для разработки в таком случае именно lxc хорош. Можно просто иметь полностью настроенный виртуальный компьютер.

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

Короче, если знать, что точно нужен Docker — то он, конечно, лучше. Если не знать, что нужно, то lxc привычнее. Можно просто воспринимать его как продвинутый chroot или как отдельный физический компьютер и пользоваться как привык, не заморачиваясь вопросами идеологии.

В случаях с данными - можно юзать контейнер как сторедж, там будут только данные.

Я юзаю так, разбиваю все по контейнерам, например бд в одном, код в третьем и т.д., так можно и балансировать нагрузку (или делать нагрузочное).

Вообще, лучше взять то, что умеешь готовить

В случаях с данными - можно юзать контейнер как сторедж, там будут только данные.

Всё можно. И из буханки хлеба сделать троллейбус, и из Docker сделать LXC. Но зачем, когда есть сразу LXC? :)

Вообще, лучше взять то, что умеешь готовить

И вот lxc тут явно проще. Т.е. сделать docker run, конечно, проще. Но как только дело переходит от простейших тестов к разворачиванию архитектуры, тут сразу и вылезают особенности, из-за которых в одних случаях лучше использовать lxc, в других — docker.

Попробуй UML (User Mode Linux) если он не сдох ещё. Как раз всем требованиям удовлетворял на 100%. Причём доступаться к ФС виртуалки из родительской системы можно было и в онлайн.

Прикол в том, что там никакой виртуализации не было. Ядро гостя запускалось как обычный юзерский процесс и имело свою ФС в файле.

гуёвый виртуалбокс

есть и консоль

Ну, во первых, хорошо подумай, нужны ли тебе именно непривелигерованные контейнеры. Чтобы их приготовить нужны некоторые танцы с бубном в хостовой системе. С гостевой почти ничего делать не нужно ( грубо говоря, только chown -R). Специальный дистрибутив не нужен. У меня заработали в арче. Только ядро пришлось пересобрать.

ты, наверное, хочешь docker, но очень сильно это завуалировал? :)

docker чтоль?

Просто chroot — без lxc и тем более вирт. машин.

Конечно если надо ограничить ресурсы и чуть большую изоляцию, то lxc

Если нужно другое ядро и/или др. ОС — kvm

А чем не устраивает chroot?

для kvm нужен в гостевой системе видеодрайвер (fglrx)? или там эмулируется виртуальная видеокарта, и драйвер не нужен?

Kernel-based Virtual Machine

зависит от выбранной к эмуляции видеокарты, но драйвер нужен в любом случае. Просто эмулируется или видеокарта полностью(какой-нибудь Cirrus, для чистой консоли пойдет, с иксами тоже работать будет, но об OpenGL нормальном лучше сразу забыть) или паравиртуальное устройство(SPICE)