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? 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 >
