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
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
