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

Reply via email to