On Tuesday 25 May 2010 16:17:17 Frank S Fejes III wrote:
> On Mon, May 24, 2010 at 1:00 PM, Bart Coninckx <bart.coninckx@xxxxxxxxxx>
wrote:
> > On Monday 24 May 2010 19:29:35 John Madden wrote:
> >> > John, I'm interested as to why you feel this is unsafe and what bad
> >> > experiences you may have had doing shared lvm in a manual (ie,
> >> > non-clvm) fashion. In clusters of up to six Xen hosts per iscsi
> >> > target I've been using a combination of scripted lvchange/lvscan
> >> > commands in lvm wrappers and have never yet run into corruption. As
> >> > far as I'm aware, there's nothing magical that clvm is doing under the
> >> > covers besides locking and if all lvm commands are run via the
> >> > "clustered" wrappers then the metadata should not be changing
> >> > unexpectedly.
> >>
> >> If you carefully coordinate changes to the metadata and, for example,
> >> reload the data on all cluster members on every change, I think you
> >> would be ok. CLVM takes care of all this for you and uses locking to
> >> ensure changes on one node can't clash with other nodes.
> >
> > Quite interesting point of view, since it is so different from the one of
> > authors commenting before ...
> > This is somewhat difficult in regards to taking decisions on setups: one
> > party says "don't", the other says "do".
>
> Well, please don't read my post as a recommendation to "do". I'm only
> writing to say that I've done it and that I do not yet have a
> technical reason for why it *shouldn't* work. As others have pointed
> out, the process to enabling clvm is long and problematic which is why
> I originally set out for a way to avoid it altogether. I think I've
> done that and I've been using it with success so far.
>
> That said, I've never been completely satisfied with this solution for
> a number of reasons. For one, it's completely undocumented and who's
> to say that a future update to lvm won't start doing things to the
> metadata that breaks my assumptions? For another, it would seem that
> very few other people are doing it which is partly why I posted in the
> first place. I'd love to see if other people such as John are doing
> this and what their experiences have been.
>
> What I'd *really* love to see is clvm decoupled from the rhel
> clustering beast and packaged as a barebones easy-to-configure and
> deploy option to the base lvm package.
>
> --frank
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
I agree cLVM adds some considerable complexity, that's why I plan to avoid it
all together. To be able to do both snapshotting and live migration (for which
I needed LVM), I decided to use iSCSI targets as vbd's in the config files and
to snaphost the iSCSI LUNs once the corresponding Dom0 is down.
Will report back on how well this works.
Rgds,
Bart
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home