Comment 13 for bug 1677398

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.