> Ok... I see where you're coming from Nikola... you're only concerned
> with safe, consistent snapshots of the filesystem state without
> checkpointing the running vm state. Yes, implementing a special xm
> fssnapshot command would be the way to go. I was just curious if
> there were any other pitfalls given my approach of checkpointing the
> entire VM with a suspend followed by an lvm snapshot. Thanks for the
> clarifications. I'm actually considering an attempt to implement the
> COW memory functionality that's been discussed on this list in the
> past.
In an earlier e-mail you also said:
>
> In looking at how xm suspend works, it seems that only memory state is
> saved and nothing is done to ensure the guest domain puts its
> filesystem into a consistent state, though I'm not completely certain
> about that.
>
xm suspend doesn't put the filesystem into a consistent state, so the
filesystem will not be clean and may be inconsistent at the time. This is
just because the guest may still be caching information that it hasn't yet
written back to disk. One *could* get it to make the filesystem consistent,
but that would slow down the suspend so I think it's really an orthogonal
problem.
As long as you have the contents of the block device *and* the suspend image,
you can resume the domain and it'll still be able to access the FS because it
has all the cached data needed to make sense of the image.
If you don't keep the suspend image with your backup then you won't
necessarily be able to mount the filesystem properly (although you can
probably repair it with fsck - but that isn't really ideal for a backup
though!).
The ability to freeze the filesystem into a consistent state, create an LVM or
qcow snapshot and then unfreeze (potentially all without pausing the domain!)
would be handy for a zero downtime backup operation.
Cheers,
Mark
>
> Mike
>
> On Dec 8, 2007 5:17 PM, Nikola Ciprich <extmaillist@xxxxxxxxxxx> wrote:
> > Hi Mike, well, I maybe don't understand where the question is ;) but I
> > guess that Your procedure is perfectly correct (for creation of a
> > checkpoint of running system), if You want to restore the backup later,
> > You restore system into running state, so a filesystem is in state
> > consistent with running system....
> > n.
> >
> > On Sat, 8 Dec 2007, Stefan de Konink wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA512
> > >
> > > Nikola Ciprich schreef:
> > >> Hi Mike,
> > >> I think that this problem can be solved using procedure Mark proposed
> > >> - freeze filesystems of all running domUs using some xm command, then
> > >> create snapshot and unfreeze them all again. I think that You won't
> > >> need suspend at all.
> > >> We just now need to implement it :)
> > >
> > > Just a question about unsafely. I have implemented iscsi and zfs as
> > > combination with Xen on Linux. Is the only safe procedure:
> > >
> > > pause
> >
> > memory snapsnot
> >
> > > [send out disk snapshot]
> > > resume
> > >
> > >
> > > Stefan
> > >
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v2.0.7 (GNU/Linux)
> > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> > >
> > > iD8DBQFHWxFIYH1+F2Rqwn0RCiT7AKCBAnfW4E0M8pLjHKZUHOOX0mwoZwCfcfY3
> > > Rns2S2AETOMypqLDmRnljx4=
> > > =ADlt
> > > -----END PGP SIGNATURE-----
> >
> > --
--
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