![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Centos 7 в LXC-контейнере под Debian 11
А я сегодня победил запуск 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..
Хотя, конечно, еще Альт с астрой есть, для которых у меня тоже тэгов пока нет.
no subject
libvirt (с qemu/kvm) хорош тем, что берёт на себя ещё и сеть. Я пробовал работать с голым qemu, но там слишком много двигающихся деталей. libvirt всё-таки разумное api выставляет наружу для stop/start/destroy/undefine.
С файловой системой согласен, в остальном оверхед на бут всё-таки не очень большой. Особенно, если быстрая машина.
Насчёт "только изоляции сети" - есть firejail --net=none /usr/your_binary (те же неймспейсы).
no subject
Вот с сетью как раз в qemu все просто. Для многих задач там вообще -net user хватает. И тогда на хосте вообще ничего не менятся - с точки зрения хоста qemu оказывается просто еще одним userspaсе процессом, работащим с сетью.
А когда libvirt что-то берет на себя, работать с этим помимо libvirt становится просто невозможно. Например, она пытается завести свой собственный dhcp/dns сервер. Который из-ха того, что писали либвирт криворукие ламеры, укушенные поттерингом, еще и запросто может начать конфликтовать с моим, хостовым, любовно настроенным.
Если мне нужна от вируталок сеть, то мне не нужно чтобы кто-то брал ее на себя. Мне нужно чтобы они как законопослушные нетизены включились в МОЮ сеть, и их хостнеймы резолвились в ip-адреса, выданные им по dhcp, на моей рабочей машине (которая совершенно не обязательно совпадает с тем сервером, на котором они работают).
Я уж не говорю про то, что если я подключил через libvirt к виртуальной машине usb-устройство, а потом машину выключил, устройство выдернул, то оно само не отключится и при следующем запуске машина может не стартовать, потому что libvirt зачем-то помнит, что там было usb-устройство.
Собственно у меня было ровно две причины начать писать vws - это безобразно реализованная в libvirt работа с USB и проблемы с тем, чтобы что-то сделать с qemu, если оно не реализовано в libvirt.
Оверхед на виртуалку просто охрененный. Дело в том. что QEMU резервирует под себя всю память, выделенную виртуальной машине. А контейнеры между собой памятью делятся. И когда у тебя их десятки, и каждому в пике (но неодновременно) нужно гигабайт восемь...
firejail - хрень практически бессмысленная.
Если мне надо среду другого дистрибутива, она мне ничем не поможет.
Если мне надо запускать недоверенную программу типа скайпа, то тут кругом сплошные грабли, потому что мне нужно прокрутить в этом джайле столько дырок для того, чтобы оно делало то, что мне нужно - и клипборд с хостом общий, доступ к Downloads ему дай, микрофон с видеокамерой дай, и т.д. и т.п, что от безопасности ничего не остается.