Можно ли смонтировать устройство в уже запущенном LXC?

Могу ошибаться, но кажется доступ к устройствам управляется через cgroup, их можно конфигурять на ходу, ?????, PROFIT!

Ручки devices.{allow,deny,list} в группе контейнера (расположение зависит от, в общем покопайся в точке монтирования cgroup).

можно. я через virsh (virt-manager) делаю

Попробуй посмотреть это: https://openvz.org/Bind_mounts .

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

Спасибо, помогло разрешение всего (с конкретными номерами разбираться влом) с помощью:

echo 'b *:* rwm' > /sys/fs/cgroup/devices/lxc/<container-name>/devices.allow

Как пользоваться для монтирования virsh и при чём тут openvz — не понял :)

Ну ты суров, довать контейнеру полный доступ ко всем устройствам это сильно. Ты-же понимаешь что сейчас процесс в контейнере может, например, читать/писать файлы хостовой системы?
Конкретный номер можно не напрягаясь посмотреть в выводе ls -l /dev/devname, это пятый и шестой столбцы.

А openvz, полагаю, тут при-том что смонтировать можно внутрь контейнера из хостовой системы можно и в LXC.

Технологии схожи, в обоих случаях развитый chroot и в твоём случае надо полагать также возможно с хоста смонтировать с опцией bind каталог внутрь. И если ты сделаешь тестовый контейнер с подключением каталога при старте и каким либо образом увидишь команду подключения, то после сможешь в произвольный момент подключать такой командой каталог внутрь. По ссылке пример того, как это делается в другой технологии.

Ты-же понимаешь что сейчас процесс в контейнере может, например, читать/писать файлы хостовой системы?

Понимаю. Просто контейнер под моим в одну морду руководством :) А после рестарта всё равно устройство окажется примонтированными штатным образом (как я понимаю, мои вручную выставленные разрешения сбросятся?)

Конкретный номер можно не напрягаясь посмотреть в выводе ls -l /dev/devname, это пятый и шестой столбцы.

Хм. У нас точно один ls? :)

# ls -l /dev/balvg/lxc-airbase-caches 
lrwxrwxrwx 1 root root 8 окт  8 16:29 /dev/balvg/lxc-airbase-caches -> ../dm-29

Разве openvz тоже на cgroup работает? Я думал, он старше.

Нет, не на cgroup. Но lxc, несколько я понимаю, тоже на основе chroot. И думаю с хоста также можно подключить каталог внутрь.

lxc работает на cgroup. Более того, в моём случае в корневой системе смонтированного root lvm вообще нет и не видно, он смонтирован только внутри lvm :)

qemu hotplug вроде умеет, может и lxc каким-то боком так умеет...

Понимаю. Просто контейнер под моим в одну морду руководством :)

И софт, конечно-же, без уязвимостей…
Моё дело предупредить, «разрешить всё» в принципе плохая идея, не стоит к такому привыкать.

А после рестарта всё равно устройство окажется примонтированными штатным образом (как я понимаю, мои вручную выставленные разрешения сбросятся?)

После рестарта хоста — да, после рестарта гостя — ХЗ, зависит от. И я-бы не стал полагаться на неизменность этого поведения.
Хотя скорее «да» чем «нет».

Хм. У нас точно один ls? :)

Буква «l» перед правами на файл как-бы намекает нам что /dev/balvg/lxc-airbase-caches является символьной ссылкой на /dev/dm-29, символьная ссылка не является устройством, а следовательно не имеет атрибутов файла-устройства (старшего и младшего номера, которые идентифицируют устройство в системе и которые нужно указывать в соответствующей cgroup).
Короче ls -l /dev/dm-29

Как асе сложно... В моём понимании, если выполняются следующие условия: с хоста есть доступ к контейнеру и с хоста доступна искомая ФС, то можно с хоста смонтировать эту ФС а этот контейнер. Но техника кончено не стоит на месте и всё что было простым становится сложным...

Прежде, чем писать предыдущий ответ я, конечно, и на простых девайсах поглядел, в т.ч. на /dev/sd?:

ls -l /dev/dm-29
brw-rw---- 1 root disk 253, 29 окт  8 16:29 /dev/dm-29

Для /dev/sd? выхлоп такой же. И я такой вижу много лет. Потому и вопрос был — у нас один ls? :)

Upd: я тормоз, да :D

с хоста есть доступ к контейнеру

Нету. Монтирование происходит внутри контейнера и снаружи, с хоста, уже смонтированные каталоги недоступны.

gcroup тут не причём. Я не вполне распарсил что имели в виду по той ссылке, но насколько я понял речь о монтировании внутрь контейнера из хостовой системы. Конкретно там шла речь о «монтировании» директорий, но никто не запрещает делать то-же самое с обычным монтированием.
Девайс так не пробросишь (пробросить может и получится, только работать он в контейнере не будет), а вот смонтированную ФС полагаю можно и с OZV и в LXC

Как пользоваться для монтирования virsh

я контейнерами тоже (как и kvm виртуалки) из под virsh, а чаще просто из virt-manager управляю. В virt-manager добавил в контейнер диск, по-сути lv с фс, в контейнере появился /dev/sda с теми же major:minor как и у lv, дальше обычный mount на /dev/sda

но насколько я понял речь о монтировании внутрь контейнера из хостовой системы

В моём случае это невозможно. «Нутрь» контейнера никак не доступна с хоста. Можно только раздел с rootfs контейнера смонтировать в отдельный каталог хоста и там уже с ним изгаляться, но это не будет иметь ничего общего с тем, что «видит» контейнер.

На всякий случай и для потомков: «253, 29» это и есть старший и младший номера устройства (не помню какой из них старший, кажется второй) идентифицирующие его.
Если скормить их утилите mknod то можно создать ещё один файл ассоциированный с тем-же устройством что и файл /dev/dm-29

в контейнере mknod не работает

Контейнер лежит на отдельном LVM томе или чём-то подобном? Думаю этот том должен быть смонтирован куда-то в хостовой системе. На сколько я представляю себе работу LXC, и других контейнеров, это должно быть так.
Посмотри выхлоп mount на хосте. Хотя точки монтирования оттуда вроде можно скрыть

Разве? Может «при определённых настройках контейнера mknod в нём не работает»?
Другое дело что просто создать файл устройства недостаточно что-бы получить доступ к устройству из контейнера, ядерная часть LXC фильтрует обращения к устройствам.

ох уж эти ЛОРовскик специалисты по всему, особенно чего в реале не видели

Контейнер лежит на отдельном LVM томе или чём-то подобном?

Да, именно так.

Думаю этот том должен быть смонтирован куда-то в хостовой системе

Нет, даже хостовый mount его не показывает, только гостевой :)

Не поленился проверить. В дефолтных (для моей системы) настройках mknod не работает, говорит что прав не хватает, но при lxc.cgroup.devices.allow = a (дети, не повторяйте этого дома, так делать нехорошо) можно невозбранно создать файл для диска хостовой системы и делать с ним что угодно.
В общем как я и говорил, «при определённых настройках контейнера…»

В общем как я и говорил, «при определённых настройках контейнера…»

при определённых настройках можно и хер дверь прищемить

Не спорю, но выше ты заявил что сделать это невозможно.
«Невозможно» и «неразумно» это сильно разные вещи.