RE: [Xen-users] High availability and live migration with just LVMand hardware fencing

[Jeff Sturm <jeff.sturm@xxxxxxxxxx>]

> -----Original Message-----
> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-users-
> bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Bart Coninckx
> Sent: Wednesday, May 19, 2010 9:00 AM
> To: xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-users] High availability and live migration with
just LVMand hardware
> fencing
> 
> Did some further research in the meantime and so far the best reason I
can
> find for using cLVM, is the making changes to the volume groups: with
cLVM
> they seem to be "published" to all Xen hosts at once, while with LVM
one needs
> to reconnect to the volume group (probably causing weird things to the
> guests).

We've done it with and without CLVM.  It's not a requirement, but it
works, and can compensate for storage devices that make it cumbersome to
manage the number of LUNs needed for your deployment.

Advantanges of CLVM:

- Fully clustered, uses robust fencing, no single point of failure
- Integration with device mapper allows for intuitive logical volume
names
- Works identically atop any network block storage (iSCSI etc.)
- Supports mirroring of block devices in recent releases
- Synchronizes volume group changes across cluster

Disadvantages:

- No support for volume snapshots (maybe someday--last I tried it didn't
work)
- Not available or convenient to use with all OS distributions
- Requires cluster infrastructure--difficult to use with system
partitions (e.g. /, /var)
- No thin provisioning

For my money I prefer the LUN management that ships with certain SAN
products (such as Dell's Equallogic arrays) over CLVM.  As we consider
moving away from a RHEL-supported dom0 kernel towards something like XCP
or XenServer, it'll become a necessity.

-Jeff



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users