linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zkabelac@redhat.com>
To: Vladislav Bogdanov <bubble@hoster-ok.com>
Cc: Andreas Pflug <pgadmin@pse-consulting.de>,
	LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] LVM snapshot with Clustered VG [SOLVED]
Date: Fri, 15 Mar 2013 14:32:53 +0100	[thread overview]
Message-ID: <51432305.7020007@redhat.com> (raw)
In-Reply-To: <514319C7.8020601@hoster-ok.com>

Dne 15.3.2013 13:53, Vladislav Bogdanov napsal(a):
> 15.03.2013 12:37, Zdenek Kabelac wrote:
>> Dne 15.3.2013 10:29, Vladislav Bogdanov napsal(a):
>>> 15.03.2013 12:00, Zdenek Kabelac wrote:
>>>> Dne 14.3.2013 22:57, Andreas Pflug napsal(a):
>>>>> On 03/13/13 19:30, Vladislav Bogdanov wrote:
>>>>>>
>>> You could activate LVs with the above syntax [ael]
>> (there is a tag support - so you could exclusively activate LV on remote
>> node in via some configuration tags)
>
> Could you please explain this - I do not see anything relevant in man pages.

Let's say - you have 3 nodes  A, B, C - each have a TAG_A, TAG_B, TAG_C,
then on node A you may exclusively activate LV which has TAG_B - this
will try to exclusively active LV on the node which has it configured
in lvm.conf  (see the  volume_list= [])

>
>>
>> And you want to 'upgrade' remote locks to something else ?
>
> Yes, shared-to-exclusive end vice verse.

So how do you convert the lock from   shared to exclusive without unlock
(if I get it right - you keep the ConcurrentRead lock - and you want to take 
Exlusive -  to  make change state from  'active' to 'active exlusive')
https://en.wikipedia.org/wiki/Distributed_lock_manager

Clvmd 'communicates' via these locks.
So the proper algorithm needs to be there for ending with some proper state 
after locks changes (and sorry I'm not a dlm expert here)


>>
>> What would be the use-case you could not resolve with current command
>> line args?
>
> I need to convert lock on a remote node during last stage of ver3
> migration in libvirt/qemu. That is a "confirm" stage, which runs on a
> "source" node, during which "old" vm is killed and disk is released.
> So, I first ("begin" stage) convert lock from exclusive to shared on a
> source node, then obtain shared lock on a target node (during "prepare"

Which most probably works only your environment - since you do not try to
'break' the logic - but it's probably not a generic concept - i.e.
in this controlled environment you may live probably happily even with
local activation of LVs - since you always know what the tool is doing.

> There is no other events on a destination node in ver3 migration
> protocol, so I'm unable to convert lock to exclusive there after
> migration is finished. So I do that from a source node, after it
> released lock.
>
>>
>> Is that supported by dlm (since lvm locks are mapped to dlm)?
> Command just sent to a specific clvm instance and performed there.

As said - the 'lock' is the thing which controls the activation state.
So faking it on the software level may possible lead to inconsistency between 
the dlm and clvmd view of the lock state.

Zdenek

  parent reply	other threads:[~2013-03-15 13:32 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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-12  6:52                   ` Andreas Pflug
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 [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2013-03-15 16:31 David Teigland
2013-03-15 17:46 ` Vladislav Bogdanov
2013-03-15 18:38   ` David Teigland
2013-03-16 11:00     ` 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=51432305.7020007@redhat.com \
    --to=zkabelac@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).