On Fri, Sep 30, 2011 at 2:46 PM, Robert P <robp...@gmail.com> wrote: > > > On Fri, Sep 30, 2011 at 2:04 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote: >> >> On Fri, Sep 30, 2011 at 11:32 AM, Robert P <robp...@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 <stefa...@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?
Absolutely. Each snapshot has a backing file linking back to the previous snapshot. You need to push the latest data all the way back to the base backing file. Stefan
