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. -- 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