linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: David Teigland <teigland@redhat.com>
To: linux-lvm@redhat.com
Cc: Vladislav Bogdanov <bubble@hoster-ok.com>,
	Andreas Pflug <pgadmin@pse-consulting.de>
Subject: Re: [linux-lvm] LVM snapshot with Clustered VG [SOLVED]
Date: Fri, 15 Mar 2013 12:31:24 -0400	[thread overview]
Message-ID: <20130315163124.GA1061@redhat.com> (raw)

> 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

             reply	other threads:[~2013-03-15 16:31 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-15 16:31 David Teigland [this message]
2013-03-15 17:46 ` [linux-lvm] LVM snapshot with Clustered VG [SOLVED] Vladislav Bogdanov
2013-03-15 18:38   ` David Teigland
2013-03-16 11:00     ` Vladislav Bogdanov
  -- strict thread matches above, loose matches on Subject: below --
2013-03-01 11:28 [linux-lvm] LVM snapshot with Clustered VG Andreas Pflug
2013-03-01 15:41 ` Vladislav Bogdanov
2013-03-06  7:40   ` Andreas Pflug
2013-03-06  7:58     ` Vladislav Bogdanov
2013-03-06  9:15       ` Andreas Pflug
2013-03-06  9:35         ` Vladislav Bogdanov
2013-03-06  9:59           ` Andreas Pflug
2013-03-06 11:20             ` Vladislav Bogdanov
2013-03-06 12:17               ` Andreas Pflug
2013-03-06 13:28                 ` Vladislav Bogdanov
2013-03-13 15:14                   ` [linux-lvm] LVM snapshot with Clustered VG [SOLVED] Andreas Pflug
2013-03-13 16:53                     ` Vladislav Bogdanov
2013-03-13 17:37                       ` Andreas Pflug
2013-03-13 18:30                         ` Vladislav Bogdanov
2013-03-14 21:57                           ` Andreas Pflug
2013-03-15  9:00                             ` Zdenek Kabelac
2013-03-15  9:29                               ` Vladislav Bogdanov
2013-03-15  9:37                                 ` Zdenek Kabelac
2013-03-15 12:53                                   ` Vladislav Bogdanov
2013-03-15 13:11                                     ` Vladislav Bogdanov
2013-03-15 13:32                                     ` Zdenek Kabelac
2013-03-15 14:51                                       ` Vladislav Bogdanov
2013-03-15 15:02                                         ` Zdenek Kabelac
2013-03-15 15:36                                           ` Vladislav Bogdanov
2013-03-15 15:55                                             ` Zdenek Kabelac
2013-03-15 17:16                                               ` Vladislav Bogdanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130315163124.GA1061@redhat.com \
    --to=teigland@redhat.com \
    --cc=bubble@hoster-ok.com \
    --cc=linux-lvm@redhat.com \
    --cc=pgadmin@pse-consulting.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).