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!
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home