On Fri, Sep 30, 2011 at 2:04 PM, Stefan Hajnoczi <stefanha@gmail.com> wrote:

> On Fri, Sep 30, 2011 at 11:32 AM, Robert P <robp236@gmail.com> wrote:
>
> Please use Reply-All to keep qemu-devel CCed so that others can contribute.
>
> >
> > On Fri, Sep 30, 2011 at 10:16 AM, Stefan Hajnoczi <stefanha@gmail.com>
> > wrote:
> >>
> >> On Thu, Sep 29, 2011 at 09:07:19PM +0200, Robert P wrote:
> >> > Hello,
> >> >
> >> > I still have a problem with the "Live Snapshot" feature of QEMU ....
> and
> >> > before migrating to XEN, VMware or something similare, a quick post
> >> > here:
> >> >
> >> > OS: Ubuntu Natty 64bit
> >> >
> >> > First, i'm starting my KVM Machine with an image like this:
> >> > qemu-img create -f qcow2 -o backing_file=<NameOfBaseImage>
> >> > <Snapshotname>
> >> >
> >> > If i stop the KVM Machine later, and i commit <Snapshotname> into
> >> > <NameOfBaseImage>, all the new changes are in the <NameOfBaseImage>.
> >> > That would be ok.
> >> >
> >> > ---
> >> >
> >> > The Problem:
> >> >
> >> > Actually i'm trying to create "live snapshots" periodically  while the
> >> > machine is running, like this (host2Qemu is just a special function of
> >> > mine
> >> > (it works), to send a string to qemu-monitor).
> >> >
> >> >                 host2Qemu "cont"
> >> >                 host2Qemu "guest-agent-fsfreeze"
> >> >                 host2Qemu "stop"
> >> >
> >> >                 host2Qemu "info block"
> >> >                 host2Qemu "snapshot_blkdev ide0-hd0 <Snapshot1
> >> > (example)>
> >> > qcow2"
> >> >
> >> >                 host2Qemu "cont"
> >> >                 host2Qemu "guest-agent-fsthaw"
> >> >
> >> > My idea is, to commit them one by one afterwards, when the KVM Machine
> >> > is
> >> > down into the BaseImage.
> >> >
> >> > So, the Snapshots are beeing written, and everytime i call that
> function
> >> > new
> >> > data is beeing written to the new "alllocated" snapshot.
> >> > BUT, committing of that live-snapshots fails, and i've no idea why ?!
> >> >
> >> > I would commit it like that:
> >> >  qemu-img commit -f qcow2 <Snapshot, with KVM was started first>
> >> > qemu-img commit -f qcow2 <Snapshot1, newer>
> >> > qemu-img commit -f qcow2 <Snapshot1, more new>
> >> > ...
> >> > and so on.
>
> You should have something like this:
> <NameOfBaseImage> -> <Snapshot1> -> <Snapshot2> -> ... -> <SnapshotN>
>
> The qemu-img commit command merges down an image file into its backing
> file, so you would do:
>
> $ qemu-img commit <SnapshotN>
> ...
> $ qemu-img commit <Snapshot2>
> $ qemu-img commit <Snapshot1>
>

> Now all the <Snapshot*> files contain no actual data - the delta have
> been committed to their backing files.  You can discard them and use
> <NameOfBaseImage> directly.
>
> How does this compare to what you were trying?
>

Hm, that means you recommend to commit the snapshots from newest to oldest
into the base-Image?
I am committing them (when the KVM is off) from oldest to newest, like this:


$ qemu-img commit <Snapshot1>
$ qemu-img commit <Snapshot2>
....
$ qemu-img commit <SnapshotN>

Is that maybe causing that problem?

Thanks.
Robert


> Unfortunately this is an inefficient approach because the same data
> gets copied N times from <SnapshotN> all the way down to
> <NameOfBaseImage>.  What's really needed is live merge support with
> the ability to merge down multiple layers of the backing file (e.g. do
> it all in one command and only copy data once).
>

> Stefan
>