[libvirt-users] libgfapi disk locking in virtlockd not working

[Piotr Rybicki]

Hello.

I'm playing with libgfapi network disks, over IB and all is working 
fine, but not disk locking (and true rdma transport).
I use virtlockd, and with fuse mount, locking works as expected.

But when i converted disk definitions to libgfapi, locks are not created 
(but qemu starts and works fine). I used direct and indirect locking - 
same result : qemu working fine, no locks.

my revelant xml section:

     <disk type='network' device='disk'>
       <driver name='qemu' type='raw' cache='writethrough' iothread='1'/>
       <source protocol='gluster' 
name='pool_test/gentoo-virtio-lib1-sys.img'>
         <host name='X.X.X.X' port='24007' transport='rdma'/>
       </source>
       <target dev='vda' bus='virtio'/>
       <address type='pci' domain='0x0000' bus='0x00' slot='0x04' 
function='0x0'/>
     </disk>

I also tried devices <lease> but it also doesn't work:
     <lease>
       <lockspace>somearea</lockspace>
       <key>somekey</key>
       <target path='/data/nfs/lockd'/>
     </lease>

# virsh start gentoo-virtio-lib1
błąd: Uruchomienie domeny gentoo-virtio-lib1 nie powiodło się
błąd: internal error: Lockspace for path /data/nfs/lockd/somearea does 
not exist

well, lockspace exists...

# ls -al /data/nfs/lockd
razem 4K
drwxrwxrwx 3 root root   21 12-08 22:43 .
drwxrwxrwt 7 root root 4096 12-08 14:29 ..
drwxrwxrwx 2 qemu qemu    6 12-08 22:43 somearea

# ls -al /data/nfs/lockd/somearea/
razem 0K
drwxrwxrwx 2 qemu qemu  6 12-08 22:43 .
drwxrwxrwx 3 root root 21 12-08 22:43 ..

Are libgfapi based disks supported by virtlockd? Is there a bug. Am I 
missing something?

My test system:
# uname -r
3.14.24-gentoo

# libvirtd -V
libvirtd (libvirt) 1.2.10

# virtlockd -V
virtlockd (libvirt) 1.2.10

# qemu-x86_64 -version
qemu-x86_64 version 2.1.2, Copyright (c) 2003-2008 Fabrice Bellard

# glusterfs -V
glusterfs 3.5.20141204.7b160e3 built on Dec  8 2014 19:03:37
(normally 3.5.2, but was curious if 3.5 series nightly buld will enable 
true RDMA transfer, not IPOIB. - it did not).

Best regards
Piotr Rybicki