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-devel

Re: [Xen-devel] consistent LVM snapshot of domUs from dom0

> thanks! I'm already looking at the changes - although the second address
> is linux-xen-fssnapshot.hg, not xen-linux-fssnapshot.hg :)

Doh!  I'm a muppet, sorry.  Well done for figuring it out.

> I'll try to add the code for (un)freeze_bdev and send You the patch..

Awesome!

> For the future, do You think we could have it that You can specify which
> device You want to freeze? It could reduce time needed for backup of domUs
> with many (and/or quickly changing) devs, if You want to make snapshot
> only of one of them...

I think it'd be nice eventually to be able to freeze individual partitions 
(should be doable, since this is the normal scope of a filesystem).

I think that might be good for several reasons, including:
1) if you only want to back up certain filesystems (e.g. ones containing user 
data)
2) if you only want to freeze one FS at a time to minimise disruption to guest 
IO

For a proof-of-concept, I think it'd be fine to freeze all 
filesystems /disks - or even just to freeze one particular filesystem / disk 
by default.

Cheers,
Mark

> Cheers!
> nik
>
>   On Sat, 5 Jan 2008, Mark Williamson wrote:
> > Oh I am a silly sausage!  I wrote the whole e-mail and forgot to mention
> > where the code actually was :-)
> >
> > See:
> > http://xenbits.xensource.com/maw/xen-fssnapshot.hg
> > and
> > http://xenbits.xensource.com/maw/xen-linux-fssnapshot.hg
> >
> > The code is just a template of what's needed to plumb commands from xm,
> > through Xend and to the guest domain.  It's probably a bit buggy and
> > ugly, but it shows basically what files you need to touch and it might
> > provide a base to work from.  With a few tweaks you should be able to get
> > some calls to filesystem freezing going, and then add more controls to
> > make it more useful to administrators.
> >
> > I've added the command to the legacy protocol for now because I don't
> > understand the XenAPI stuff.  But it ought to be added there too at some
> > point...
> >
> > Cheers,
> > Mark
> >
> > On Friday 04 January 2008, Nikola Ciprich wrote:
> >> Hi Mark,
> >> that's a good news! Where can I get the code? I don't see it in
> >> xen-unstable yet, is it available in some other repo?
> >> When it comes to dividing the work, I could try to finish the kernel
> >> part and try to glue it all together.. as soon as I can get my hands on
> >> the code :)
> >> so please let me know where I can get it and I'll have a look at it ASAP
> >> cheers and thanks!
> >> nik
> >>
> >>   On Fri, 4 Jan 2008, Mark Williamson wrote:
> >>> Hi there,
> >>>
> >>> I've started checking code into Xenbits.  Right now all that's there is
> >>> the proof-of-concept control tools work and a stub driver in the guest
> >>> kernel which is able to listen for commands.
> >>>
> >>> The actual mechanics of FS snapshotting need to be implemented, plus UI
> >>> features (such as actually taking arguments - and more importantly only
> >>> returning from xm fsfreeze when guest says the freeze is actually
> >>> complete)...
> >>>
> >>> If you want to have a crack at plumbing this together you'd be more
> >>> than welcome, or I can have a go at it, or we can split it.  Any
> >>> preference? I'll get paid for any work I do, so I'm happy to do any
> >>> amount ;-)
> >>>
> >>> Cheers,
> >>> Mark
> >>>
> >>> On Friday 04 January 2008, Nikola Ciprich wrote:
> >>>> On Mon, 24 Dec 2007, Mark Williamson wrote:
> >>>> Hi Mark,
> >>>> is there some progress regarding this subject? Still, if there is
> >>>> something I could help with, please do not hesitate to tell me what
> >>>> could I do...
> >>>> Cheers
> >>>> Nik
> >>>>
> >>>>> Yes, I think that's a sensible first step to take.  Later on, we
> >>>>> could perhaps look into putting some more smarts in, e.g. doing the
> >>>>> snapshot creation automatically in the case that an LVM volume or
> >>>>> QCow virtual disk is already being used.
> >>>>>
> >>>>> I hadn't come across freeze/thaw_bdev before - I'd found a lock /
> >>>>> unlock call for filesystem locking somewhere that looked promising
> >>>>> but not implemented it yet.  I imagine it might boil down to a
> >>>>> similar thing in the end.
> >>>>>
> >>>>> Either way, being able to freeze specific block devices could be
> >>>>> useful for backup purposes.  There's no point freezing filesystems
> >>>>> that are not used to store backed-up data, for instance!
> >>>>>
> >>>>>> Yup, agree :)
> >>>>>> Cheers!
> >>>>>
> >>>>> OK, I'll try and get some code online at some point and let you know
> >>>>> when it's available.
> >>>
> >>> --
> >>> Dave: Just a question. What use is a unicyle with no seat?  And no
> >>> pedals! Mark: To answer a question with a question: What use is a
> >>> skateboard? Dave: Skateboards have wheels.
> >>> Mark: My wheel has a wheel!
> >
> > --
> > Dave: Just a question. What use is a unicyle with no seat?  And no
> > pedals! Mark: To answer a question with a question: What use is a
> > skateboard? Dave: Skateboards have wheels.
> > Mark: My wheel has a wheel!



-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

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