Centos 7 в LXC-контейнере под Debian 11

[vitus_wagner]

А я сегодня победил запуск centos 7 в LXC на свежем Dеbian.

Собственно, уже довольно давно сталкивался с тем, что относительно старые операционки в контейнерах на новых хостах работать не хотят. Вот типа вроде начало стартовать, а потом зависло. По lxc-attach зайти можно, и там никаких процессов кроме init. Сеть, естественно, не поднимается и все такое.

Сегодня наконец собрался и запустил это дело в foreground mode.

И первое что увидель Cannot mount /sys/fs/cgroup/systemd - permission denied. Потом еще несколько ругательтсов на тему cannot create manager object и в конце systemd говорит что он freezing.

То есть в новых ядрах изменили раскладку файловой системы cgroup и старый system с этим не справляется. Надо в командную строку ядра на хосте добавить параметр

systemd.unified_cgroup_hierarchy=0

И все заработает.

В общем у меня уже кучка параметров в конфиге grub набралась, чтобы в контейнерах древние линуксы запускать

vsyscall=emulate
cgroup_enable=memory
systemd.unified_cgroup_hierarchy=0

В пору уже в дополнение к тагу Debian так redhat7 заводить. А то большая часть проблем о которых я пишу связана именно с этой системой. Ну с отказом от поддержки SLES 11..

Хотя, конечно, еще Альт с астрой есть, для которых у меня тоже тэгов пока нет.

Comments

[dennis-chikin.livejournal.com]

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

[vitus_wagner]

К сожалению, я совсем независимым не являюсь. Я все-таки работаю в компании. которая Росбиттеху бизнес-партнер.

[ramendik]

Поддержка дистрибутива в течение 10 лет - это у шапки такой key marketing point. Ну и древности начинают сталкиваться с чем-то новее, это ж понятно.

Но как-то меня начинает напрягать идея, что править для этого приходится ядро на хосте. Однако я хреново понимаю в контейнерах. А LXC не трогал вообще ни разу, потому как в шапке контейнеры - podman+kubernetes, ну иногда всё ещё docker. _Насколько я понимаю_, там эта проблема невозможна, но и use case там другой.

[vitus_wagner]

Там эта проблема еще как возможна. Очень многие люди используют докер для запуска полноценной ОС со своим init. И собственно, когда я стал гуглить эту проблему, в основном попадались вопросы пользователей докера. Но kubernetes тоже попадался.

На самом деле проблема исключительно в systemd который лезет во все дырки и не довольствуетеся тем, что дали ему как нормальному юзерспейс-процессу.

Вот с vsyscall было хуже. Там проблема была в glibc, поэтому не работали просто все программы.

[vitus_wagner]

А что править приходится ядро на хосте, так это потому что контейнеры. Это их ключевая фича - общее на всех ядро. Именно потому что они не пытаются развести собственное ядро на каждую виртуальную ОС, они такие эффективные.

[juan_gandhi]

О, это хороший пунктик насчет маунта.

[amarao]

У меня был период романса с lxc, но они сотворили фигню в subusers (поменяли формат, причём так, что не было ни формата, который бы старую/новую версию устраивал, ни версии, которая бы оба формата понимала). Ещё там были крайне странные глюки в районе ntp, вроде бы. Примерно после 5-6 специальных странных хаков (это нельзя, это не делаем) я сравнил плюсы и минусы и ушёл на libvirt.

У меня сейчас код поднятия виртуалок на моей машине выполняется за примерно 30с (вместе доп. ребутом из-за этой глупой cgroup_hierachy, которую у меня cadvisor хочет), причём golden image собирается diskimage builder'ом в /var на локальной машине. Машины инициализируются (hostname/ssh через NoCloud cloud-init, конфиг в подмонтированной iso'шке), сеть dhcp с прибитыми IP в leases.

А на работе для этого используется молекула и openstack, molecule create - создаёт ephimerial окружение, molecule destroy подтирает. Между двумя этими этапами выдают инвентори ансибла для работы с правильно прописанными IP и ключами для доступа.

[vitus_wagner]

Ну libvirt это не системв вирутализации а бесполезная надстройка над системами виртуалиации. У меня был роман с libvirt, но потом я примерно по тем же причинам плюнул и если мне нужна виртуалка, а не контейнер, использую простенькую питоновскую обертку вокруг qemu,

Проблема в том, что виртуалка - крайне тормозная и неудобная штука. В ее файловую систему не залезешь просто так с хоста, нужно какой-то qemu-nbd запускать, она тратит время на выполнение ненужного ядра. Ну и не для всех нужных мне архитектур существует qemu/kvm, а lxc работает везде, где есть ядро linux.

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

[amarao]

libvirt (с qemu/kvm) хорош тем, что берёт на себя ещё и сеть. Я пробовал работать с голым qemu, но там слишком много двигающихся деталей. libvirt всё-таки разумное api выставляет наружу для stop/start/destroy/undefine.

С файловой системой согласен, в остальном оверхед на бут всё-таки не очень большой. Особенно, если быстрая машина.

Насчёт "только изоляции сети" - есть firejail --net=none /usr/your_binary (те же неймспейсы).

[vitus_wagner]

Вот с сетью как раз в qemu все просто. Для многих задач там вообще -net user хватает. И тогда на хосте вообще ничего не менятся - с точки зрения хоста qemu оказывается просто еще одним userspaсе процессом, работащим с сетью.

А когда libvirt что-то берет на себя, работать с этим помимо libvirt становится просто невозможно. Например, она пытается завести свой собственный dhcp/dns сервер. Который из-ха того, что писали либвирт криворукие ламеры, укушенные поттерингом, еще и запросто может начать конфликтовать с моим, хостовым, любовно настроенным.

Если мне нужна от вируталок сеть, то мне не нужно чтобы кто-то брал ее на себя. Мне нужно чтобы они как законопослушные нетизены включились в МОЮ сеть, и их хостнеймы резолвились в ip-адреса, выданные им по dhcp, на моей рабочей машине (которая совершенно не обязательно совпадает с тем сервером, на котором они работают).

Я уж не говорю про то, что если я подключил через libvirt к виртуальной машине usb-устройство, а потом машину выключил, устройство выдернул, то оно само не отключится и при следующем запуске машина может не стартовать, потому что libvirt зачем-то помнит, что там было usb-устройство.

Собственно у меня было ровно две причины начать писать vws - это безобразно реализованная в libvirt работа с USB и проблемы с тем, чтобы что-то сделать с qemu, если оно не реализовано в libvirt.

Оверхед на виртуалку просто охрененный. Дело в том. что QEMU резервирует под себя всю память, выделенную виртуальной машине. А контейнеры между собой памятью делятся. И когда у тебя их десятки, и каждому в пике (но неодновременно) нужно гигабайт восемь...

firejail - хрень практически бессмысленная.

Если мне надо среду другого дистрибутива, она мне ничем не поможет.

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