Hi, Currently virt-aa-helper has no support for pools, so if you use a volume from a pool like: <disk type='volume' device='disk'> <driver name='qemu' type='raw' cache='none'/> <source pool='internal' volume='foo'/> <target dev='vdc' bus='virtio'/> </disk> Then there is no matching apparmor rule generated to allow qemu to access the related devices. That goes along a simple pool like: # create a zpool to use $ for i in $(seq 1 3); do dd if=/dev/zero of=/tmp/fdisk${i} bs=1M count=1024; done $ sudo zpool create internal /tmp/fdisk* # make pool in libvirt and guest disk foo $ virsh pool-define-as internal zfs $ virsh pool-start internal $ virsh vol-create-as internal foo 2G When libvirt actually builds up the command for qemu what to use based on the pools information it uses the function "virStorageTranslateDiskSourcePool" to learn about the actual path of the disk. Usually virt-aa-helper tries to stay close to what libvirt does to spawn the guest, because only then the generated rules match what will be used. But in this case this isn't as easy. The lookup by "virStorageTranslateDiskSourcePool" is done on a virConnectPtr via: conn->storageDriver->storagePoolLookupByName That is fine from the code that sets up the guest, but virt-aa-helper has no virConnectPtr context. Surely virt-aa-helper could connect via e.g. "virConnectOpenReadOnly" but the lifecycle of virt-aa-helper doesn't match that. It is invoked as external program by libvirtd local to the execution of the guest e.g. the qemu. So adding a connection via a socket makes not much sense. Also in this environment the connect URI is not set and also not passed to virt-aa-helper so we can't be sure we have "the same". I found that while trying to implement that, but I don't like the preliminary change [1] for the reasons I identified and outlined above. It initializes the storage drivers correctly, but then fails to look up [2] and since I doubt it is the right way for the environment and lifecycle of virt-aa-helper I don't want to go down that way before having a discussion about it. Therefore I wanted to ask for some guidance: 1. is there a reasonable way to be able to call virStorageTranslateDiskSourcePool from virt-aa-helper 2. maybe I overlook a path to get to a valid virConnectPtr from the virDomainDefPtr or any other in [3] that virt-aa-helper aready has. 3. what would be an alternative to be able to translate pool/volume info to real paths from virt-aa-helper [1]: http://paste.ubuntu.com/25570670/ [2]: http://paste.ubuntu.com/25570673/ [3]: http://paste.ubuntu.com/25570720/ -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd