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

Reply via email to