[linux-lvm] Shared access to LVM2 metadata

[Mark Round]

As a follow-up to my own question :

Some answers off-list seem to imply that it is not so much shared access
to the SAN-shared LVM2 volume group that is the issue, it is the worry
of two or more systems updating the LVM metadata at the same time.

I just want to clarify that assuming this can be mitigated by only ever
updating the metadata (creating,deleting,resizing volumes etc.) on one
server, is this safe ?

Thanks,

-Mark

-----Original Message-----
From: linux-lvm-bounces at redhat.com [mailto:linux-lvm-bounces at redhat.com]
On Behalf Of Mark Round
Sent: 16 September 2009 17:05
To: linux-lvm at redhat.com
Subject: [linux-lvm] Shared access to LVM2 metadata

Hi all,

Quick question - is this page :
http://tldp.org/HOWTO/LVM-HOWTO/sharinglvm1.html only applicable to
LVM1, and not LVM2 ? I suspect that it is, based on the URL and my own
experiments but would like to be certain.

The reason I ask is that I have a number of hosts on a SAN (Xen Dom0
systems), which utilise a shared block device. I want to create a volume
group on this block device, and split this up into LVMs for each virtual
machine. The Dom0 systems would then see all volumes, although each
volume would only be active and mounted on one host at a time. 

I have run my own tests, and I can see that if I create, modify or
delete logical volumes within a shared volume group on one host, the
changes are immediately reflected on another (e.g. "lvcreate" on one
host shows the volume immediately on the other host with "lvs"). 

I have tried creating, resizing, delete, and performing various
file-system related activity on this shared volume group, and I haven't
run into any kind of LVM metadata or filesystem corruption, and was
happy to put this into production. But the stark warnings in that
document made me wary - am I missing something ? Am I risking some form
of latent LVM2 metadata corruption ?

Googling around didn't produce a definitive answer, so I apologise if
this has already been asked before.

Many thanks,

-Mark