When the guest gets parsed all that virt-aa-helper initially has is the disk element. This has in our case only: p *(disk->src->srcpool) $10 = {pool = 0x100236b90 "internal", volume = 0x100236440 "foo", voltype = 0, pooltype = 0, actualtype = 0, mode = 0}
Nothing in virt-aa-helper yet cares about that - it does not deliver a "virDomainDiskGetSource" and thereby gets skipped. But with that we would know pool and volume (step #1 above). Next is getting the pool details from that, to do so we align to what the actual usage of the attribute does. In virStorageTranslateDiskSourcePool is that flow which mostly is - virStoragePoolLookupByName -> virStoragePoolIsActive (check if active) -> virStorageVolLookupByName (now one has the volume) -> virStorageVolGetPath It seems designed to be safe to use virStorageTranslateDiskSourcePool, the overall pattern is to call it before handling the other attributes. It's return value is 0 if it was no srcpool disk anyway. If it is a sourcepool but it failed for any reason then it is -1. That makes it a safe pre-call before running on the disk elements data like def->src->path whicih it sets. That structurally seems to be what all other code does, so it might be wise to follow that. The problem is that this was meant to be called with an active connection (first argument). This can not be avoided by calling the sub-functions directly as this is needed in virStoragePoolLookupByName as the storage drivers it calls are in that struct. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1677398 Title: Apparmor prevents using ZFS storage pools To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1677398/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs