WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] XCP - GFS - ISCSI

On Fri, Jan 15, 2010 at 02:06:30PM +0200, Pasi Kärkkäinen wrote:
> On Fri, Jan 15, 2010 at 11:56:46AM +0000, Julian Chesterfield wrote:
> > Dave Scott wrote:
> > >Hi Pasi,
> > >
> > >[cc:d Julian who is responsible for storage in XCP]
> > >
> > >  
> > >>I haven't looked at the XCP code yet, but are there some special
> > >>patches for
> > >>LVM to make it work in a shared environment on multiple hosts?
> > >>
> > >>I guess it's not CLVM, since you support snapshots.. so xapi is doing
> > >>some coordination of management commands and making sure only one LVM
> > >>command is issued at a time?
> > >>    
> > >
> > >Julian could describe the detail better than me but my high-level 
> > >understanding is:
> > >
> > >* xapi nominates one host to be the 'SR master': all LVM metadata-changing 
> > >commands are run here
> > >
> > >* all hosts are allowed to map/unmap LVs so the LVM commands were patched 
> > >to make absolutely sure they didn't attempt to change any metadata
> > >
> > >* unless you request a special "raw" LV, vhd metadata is added to the LV: 
> > >this is how we handle snapshots
> > >  
> > Yep, this is correct. We use XAPI as the "Cluster lock manager" 
> > essentially. There is a strict notion of ordering of events, and XAPI 
> > always ensures that there is a single SRMaster for any shared SR. The SR 
> > master is the only entity that modifies LVM metadata, and it 
> > strategically refreshes slaves as necessary. Typically slaves only 
> > operate in an LVM Read-only mode, so the LVM metadata is refreshed when 
> > a slave needs to access a new logical volume, and the slave is only 
> > allowed to create device-mapper nodes, never to modify the LVM metadata. 
> > There are patches to LVM to add an explicit 'master' flag, this ensures 
> > that non-masters never attempt to repair LVM metadata if ever it is read 
> > and found to be inconsistent. In practice this would never happen due to 
> > the way LVM updates its metadata and the fact that we do not allow 
> > shared Volume Groups that span more than one LUN, however it's an 
> > important safety catch.
> >
> 
> Thank you both for answers! This is good explanation of how it works.
> 
> > Snapshot and clone support is provided via the VHD layer that resides 
> > above raw Logical Volumes. i.e. we create VHD Copy-on-write instances in 
> > the same way as the file-based VHD support (e.g. NFS or local Ext3 
> > partitions).
> > 
> 
> Oh, so XenServer/XCP doesn't use LVM snapshots at all? That's good to know.
> 

So where/how does it store the deltas between the original volume and
the snapshot? 

> Is there some commandline tool to control the VHD snapshots? 
> 

Other than 'xe', of course.

-- Pasi


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

<Prev in Thread] Current Thread [Next in Thread>