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] Re: 100% safe way to backup domU:

On Sun, 2007-01-14 at 19:44 +0530, Ligesh wrote:
> On Sun, Jan 14, 2007 at 02:06:38PM +0100, Goswin von Brederlow wrote:
> > Ligesh <myself@xxxxxxxxxx> writes:
> > 
> > >  Sat, Jan 13, 2007 at 07:26:58AM +0530, Ligesh wrote:
> > > On Sat, Jan 13, 2007 at 12:57:04AM +0800, Tim Post wrote:
> > >> .. and incremental thereof, on a typical (classic) linux system.
> > >> 
> > >> While I agree that lvm snapshots are the easiest way (now), if
> > >> developing something better, shouldn't a smaller option come into play?
> > 
> > I'm assuming you want to make a snapshot without shutting down the domU.
> > 
> > The problem with lvm snapshots is that xen does not pass down the
> > sync/suspend event from the dom0 to the domU. Normaly when you create
> > a snapshot from a mounted filesystem the fs gets asked to get itself
> > into a consistent state before freezing it. Not so with snapshoting in
> > dom0 and the filesystem mounted in domU. As a consequence mounting the
> > snapshot in dom0 can have filesystem errors, the mount can easily
> > fail.
> 

>  What I was proposing was a new option for xm, where it will be able to tell 
> the domU to sync 
> and suspend. We just need a domU kernel that will cooperate with this 
> request. The problem with
> daemon is that a lot of checks and measures has to be in place to make sure 
> that everything has
> happened as we thought it would, which in practice never happens anyway. If 
> we can have a specific
> domU kernel that's aware of this feature, then it would provide almost 100% 
> guaranteed consistency.
> 
>  Thanks.

Agreed. A daemon is a nice start (one that is very simple to install and
requires almost no configuration).. but a module is going to be the
goal.

Given our ability to do this at the kernel level, I think it would be
stupid NOT to. 

A good starting point is think about what modules exist that would
provide a good basic building block, to keep us from re-inventing the
whole wheel. AoE comes to mind.

Best
--Tim

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


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

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