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