о блин, такая же проблема, тоже вчера трахался 3 часа. Теперь вот курю маны на счет того, как apparmor работает.

Что самое интересное, если почитать dmesg, то можно увидеть, что там нет denied-ов никаких:

[ 1040.138579] audit: type=1400 audit(1484648012.064:20298): apparmor="AUDIT" operation="getattr" profile="/usr/sbin/libvirtd" name="/usr/bin/kvm" pid=1157 comm="libvirtd" requested_mask="r" fsuid=0 ouid=0
[ 1040.138614] audit: type=1400 audit(1484648012.064:20299): apparmor="AUDIT" operation="getattr" profile="/usr/sbin/libvirtd" name="/usr/bin/kvm" pid=1157 comm="libvirtd" requested_mask="r" fsuid=0 ouid=0
[ 1040.138639] audit: type=1400 audit(1484648012.064:20300): apparmor="AUDIT" operation="getattr" profile="/usr/sbin/libvirtd" name="/usr/bin/kvm" pid=1157 comm="libvirtd" requested_mask="r" fsuid=0 ouid=0
[ 1040.138662] audit: type=1400 audit(1484648012.064:20301): apparmor="AUDIT" operation="getattr" profile="/usr/sbin/libvirtd" name="/usr/bin/kvm" pid=1157 comm="libvirtd" requested_mask="r" fsuid=0 ouid=0
[ 1040.138686] audit: type=1400 audit(1484648012.064:20302): apparmor="AUDIT" operation="getattr" profile="/usr/sbin/libvirtd" name="/usr/bin/kvm" pid=1157 comm="libvirtd" requested_mask="r" fsuid=0 ouid=0
[ 1040.138710] audit: type=1400 audit(1484648012.064:20303): apparmor="AUDIT" operation="getattr" profile="/usr/sbin/libvirtd" name="/usr/bin/kvm" pid=1157 comm="libvirtd" requested_mask="r" fsuid=0 ouid=0
[ 1040.138734] audit: type=1400 audit(1484648012.064:20304): apparmor="AUDIT" operation="getattr" profile="/usr/sbin/libvirtd" name="/usr/bin/kvm" pid=1157 comm="libvirtd" requested_mask="r" fsuid=0 ouid=0
[ 1040.138758] audit: type=1400 audit(1484648012.064:20305): apparmor="AUDIT" operation="getattr" profile="/usr/sbin/libvirtd" name="/usr/bin/kvm" pid=1157 comm="libvirtd" requested_mask="r" fsuid=0 ouid=0
[ 1040.138781] audit: type=1400 audit(1484648012.064:20306): apparmor="AUDIT" operation="getattr" profile="/usr/sbin/libvirtd" name="/usr/bin/kvm" pid=1157 comm="libvirtd" requested_mask="r" fsuid=0 ouid=0
[ 1040.138803] audit: type=1400 audit(1484648012.064:20307): apparmor="AUDIT" operation="getattr" profile="/usr/sbin/libvirtd" name="/usr/bin/kvm" pid=1157 comm="libvirtd" requested_mask="r" fsuid=0 ouid=0

Нашел вот это - https://bugs.launchpad.net/ubuntu/ source/libvirt/ bug/1386465. Не уверен, насколько это к нам относится.

Короче я разобрался.

Эти волки позорные используют шаблоны. Шаблон для qemu лежит вот тут - /etc/apparmor.d/libvirt/TEMPLATE.qemu

В нем можно увидеть, что они инклудят /etc/apparmor.d/abstractions/libvirt-qemu

И в нем видно, что они нихрена не дают там прав на всякие левые директории, только на какие-то избранные.

У меня pool лежит в /var/lib/libvirt/pools/myapp и в нем есть volume node1, то есть полный путь к volume - /var/lib/libvirt/pools/myapp

Я добавил

/var/lib/libvirt/pools/** rw,

Блеск и нищета open source, «мы щитаем шо так правильней, поэтому мы щас всем это сломаем всем нахер».

Хорошо хоть в ядре Линус не позволяет такого говна делать.

Только вот почему это «фу»? Профиль написан через ж, в коде они ничего не добавляют, по-видимому. Единственное, что остается - править профиль. Не?

Потому что это костыли

Приходится давать гостю доступ на всё, включая системный диск, т.к. у меня используются физические диски, а они лежат в /dev. Также неясно, какие буквы будет у устройства после перезагрузки.

Хмм, если hardware не меняется, то и не меняется UUID разделов (я могу тут быть неправ), может быть имеет смысл доступаться их по UUID?

Честно говоря, не вижу почему придется давать доступ на все, а не только на те разделы, которые отдаешь в пользование kvm?

AppArmor в своей wiki сами пишут, что это верный путь:

If you want to adjust the profile for all future, newly created VM/containers, adjust /etc/apparmor.d/libvirt/TEMPLATE[.qemu|.lxc]
If you need to adjust access controls for all VM/containers, new or existing, adjust /etc/apparmor.d/abstractions/libvirt{-qemu,-lxc}
If you need to adjust access controls for a single guest, adjust /etc/apparmor.d/libvirt-<uuid>, where <uuid> is the UUID of the guest
To disable the driver, either adjust /etc/libvirt/qemu.conf to have 'security_driver = «none»' or remove the AppArmor profile for libvirtd from the kernel and restart libvirtd Of course, you can also adjust the profiles for libvirtd and virt-aa-helper if desired. All the files are simple text files.

Надо писать баг на apparmor-profiles. Вот только это совсем не очевидно. Обычно люди пишут баг на тот пакет, который сломался. А не на apparmor-profiles. Более того есть еще extra profiles, и зачастую профили идут с приложением. Но даже в данных случаях нужно писать баг на apparmor-profile. Extra не читают, а если ты пишешь на приложение, то тому кто отвечает за пакет все равно придется связываться с apparmor team, что займет время, если он/она еще конечно этим займется.
Есть еще одна особенность, которая не известна простым юзерам. Есть политика, что исправление могут включить в профиле могут сделать только в том пакете в котором эта ошибка находится. Т.е. если у тебя например сломалась программа «X», из-за того, что в профиле программы «Y» нету строчки для программы «X», например что программа «X» обновилась, и там сменился путь, то тот кто отвечает за пакет программы «X» не имеет возможности исправлять ничего в профиле своей программы «Y» или обходить в своем профиле, профиль программы «Y».
Короче если просто, то писать репорт нужно на apparmor-profiles, как я понял. И это двигает дело вперед, и действительно начинаются исправления.

О! Слона-то я и не заметил

Надо попробовать поменять /etc/apparmor.d/libvirt-<uuid>, хотя неясно, сработает ли операция разрешения по ссылке /dev/disk/by-id/..., а не /dev/sdX — но попробуем. Спасибо!