> I need to convert lock on a remote node during last stage of ver3 > migration in libvirt/qemu Hi, I wrote and maintain the dlm and have more recently written a new disk-based lock manager called sanlock, https://fedorahosted.org/sanlock/ which operates with only shared storage among nodes (no networking or other cluster manager.) sanlock was written to allow RHEV to manage leases for vm images on shared storage, including the ability to migrate leases among hosts (which is the most complicated part, as you've mentioned above.) sanlock plugs into the libvirt locking api, which also supports file locks (usable on local or nfs file systems.) (Search for "virtlockd".) Trying to use/control vm locks via lvm commands is not a good way to solve the vm management/migration problem at the present time (but see below). Instead, I'd suggest doing the locking via the libvirt locking api which was designed for this purpose. As I mentioned, libvirt supports both sanlock and file locks, but another option is to write a new libvirt locking plug-in for dlm/corosync. This would be the best way to use dlm locks to protect vm images on shared storage; I've been hoping someone would do this for some time. Incidentally, I've recently started a new project which is to replace clvmd with a new "lvmlockd". I'm designing lvmlockd to support both dlm and sanlock on the back side (transparent to lvm itself). With sanlock, you will not need a dlm/corosync cluster to have the benefits of locking vgs and lvs on shared storage. This project is requiring a lot of preliminary work in the lvm code, because the clvmd approach reaches deeply into lvm itself. Relating back to virt environments, lvmlockd will give you direct control of the lock types, modes and objects in each command. This will hopefully make it much easier to use lvm locks in a controlled and programatic way to solve problems like vm management. So, in preparation for lvmlockd, you should not assume that lvm commands will operate in a dlm/corosync environment. Any new options or capabilities should be considered more generally. Also, the concept of lvm commands executing remote operations in a cluster was a poor design choice for clvm. lvmlockd will probably not support this notion. Executing remote commands should be done at a higher layer. Dave _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
