[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.