Comment 12 for bug 1677398

Initially this can be run locally just with virt-aa-helper as any virt-aa-helper dev.
This mostly is like c#3, but with a service from local build and with libvtool wrapper to gdb the virt-aa-helper.

Since even this is not the most straight forward thing if you never done it here a short log how to do so:

 $ sudo ./src/virtlockd -f /etc/libvirt/virtlockd.conf -d
 $ sudo ./src/virtlogd -f /etc/libvirt/virtlogd.conf -d
 $ sudo ./daemon/libvirtd -f /etc/libvirt/libvirtd.conf -d
 # an xml containing the snippet of c#3
    <disk type='volume' device='disk'>
      <driver name='qemu' type='raw' cache='none'/>
      <source pool='internal' volume='foo'/>
      <target dev='vdc' bus='virtio'/>
    </disk>
 $ ./tools/virsh (all you need to set up the pool as in c#3)
 # run like:
 $ ./src/virt-aa-helper --lt-debug --create --dryrun --uuid 'libvirt-e2f807e2-4ee6-496f-b3cc-926b7c7cefb3' < ../bug-1677398-zfs-pool/test1.xml
 # debug like:
 $ libtool --mode=execute gdb ./src/virt-aa-helper
 (gdb) run --create --dryrun --uuid 'libvirt-e2f807e2-4ee6-496f-b3cc-926b7c7cefb3' < ../bug-1677398-zfs-pool/test1.xml

As we knew the arg to qemu uses the link like:
  -drive file=/dev/zvol/internal/foo,format=raw
But we need the base device, so in virt-aa-helper we need to:
1. the volume is a disk entry (not an FS), so we need to get the volume entry from the guest xml
2. from pool+volume get to the real path (like the -drive arg construction would do)
3. need to readlink to the link target.