[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]