Re: [Qemu-devel] QEMU Live Snapshots / Commiting

[Robert P]

On Fri, Sep 30, 2011 at 2:04 PM, Stefan Hajnoczi <address@hidden> wrote:

On Fri, Sep 30, 2011 at 11:32 AM, Robert P <address@hidden> 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 <address@hidden>
> 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