All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Pflug <pgadmin@pse-consulting.de>
To: Jacek Konieczny <jajcus@jajcus.net>
Cc: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] resize and snapshots with clvm
Date: Wed, 20 Feb 2013 16:41:08 +0100	[thread overview]
Message-ID: <5124EE94.6070000@pse-consulting.de> (raw)
In-Reply-To: <20130220143043.3a35f495@jajo.eggsoft>

Am 20.02.13 14:30, schrieb Jacek Konieczny:
> On Wed, 20 Feb 2013 14:18:23 +0100
> Andreas Pflug <pgadmin@pse-consulting.de> wrote:
>> I would have expected lvm to take that exclusive lock implicitely
>> when necessary?
> I would not expect that. LVM provides means to activate in a shared or
> exclusive way, but it does not choose itself.

I could live with that if it would be possible to elevate a LV from 
normal active to exclusive manually, but that seems not possible ATM.
Actually I guess that lvm _does_ perform the exclusive lock implicitely, 
if it can (i.e. lv inactive on all nodes)

>
>>> When the LV is exclusively activated (lvchange -aey) snapshots
>>> should work (and they do work for me).
>> The volume is "lvchange -aly" active on one node and in use there
>> (e.g. mounted or attached to a VM). If I try to lvchange -aey on that
>> node, I get "Error locking on node xxxx: Device or resource busy".
> I do not use '-aly' (in fact I am not sure what it does), so I cannot
> relate.
It activates only on the local node; other nodes might enable as well if 
necessary.
>
>> Actually, lock exclusive will even fail if the device is not in use,
>> but only active locally.
>>
>> A workaround would probably be to activate the lv exclusively
>> _before_ using it, but then it would be impossible to migrate the vm
>> to another host later on.
> I use clustered LVM for my VMs too and always use "-aey" locking mode –
> each volume can be active on a single cluster node a time. When doing VM
> migration I first deactivate the volume on one host, then activate
> it (exclusively) on the other. I feel safer knowing none of the volumes
> will ever be active on more than one host.
>
> Is your scenario much different?

You're obviously doing offline migration. While migrating live, there's 
a period with two nodes needing the volume being active. Thus exclusive 
locking would prevent live migration.

Regards
Andreas

      reply	other threads:[~2013-02-20 15:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-19 13:37 [linux-lvm] resize and snapshots with clvm Andreas Pflug
2013-02-19 13:59 ` Jacek Konieczny
2013-02-20 13:18   ` Andreas Pflug
2013-02-20 13:30     ` Jacek Konieczny
2013-02-20 15:41       ` Andreas Pflug [this message]

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=5124EE94.6070000@pse-consulting.de \
    --to=pgadmin@pse-consulting.de \
    --cc=jajcus@jajcus.net \
    --cc=linux-lvm@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.