The naming of the "exclusive-lock" feature probably implies too much compared to what it actually does. In reality, when you enable the "exclusive-lock" feature, only one RBD client is able to modify the image while the lock is held. However, that won't stop other RBD clients from *requesting* that maintenance operations be performed on the image (e.g. snapshot, resize). Behind the scenes, librbd will detect that another client currently owns the lock and will proxy its request over to the current watch owner. This ensures that we only have one client modifying the image while at the same time not crippling other use cases. librbd also supports cooperative exclusive lock transfer, which is used in the case of qemu VM migrations where the image needs to be opened R/W by two clients at the same time. -- Jason Dillaman ----- Original Message ----- > From: "Corin Langosch" <corin.langosch@xxxxxxxxxxx> > To: ceph-users@xxxxxxxxxxxxxx > Sent: Tuesday, September 22, 2015 8:11:38 AM > Subject: rbd and exclusive lock feature > > Hi guys, > > when creating an rbd with feature "exclusive-lock" (and object-map, > fast-diff, ..), do I have to pass any special > arguments to qemu to activate it? > > How does this feature work with resize, snapshot creation, etc.? Form my work > on ceph-ruby I know you have to call > "rbd_open" and then pass the returned handle to "rbd_resize", > "rbd_snap_create" etc. However with "exclusive-lock" I > assume rbd_open will fail (does it?) if it's currently used by for example a > qemu client. So there's no way to create > snapshots while the image is in use? Or do I miss anything here? > > Cheers > Corin > _______________________________________________ > ceph-users mailing list > ceph-users@xxxxxxxxxxxxxx > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |