----- "Anthony Liguori" <anth...@codemonkey.ws> wrote:
> On 10/19/2010 07:48 AM, Dor Laor wrote:
> > On 10/19/2010 04:11 AM, Chris Wright wrote:
> >> * Juan Quintela (quint...@redhat.com) wrote:
> >>>
> >>> Please send in any agenda items you are interested in covering.
> >>
> >> - 0.13.X -stable handoff
> >> - 0.14 planning
> >> - threadlet work
> >> - virtfs proposals
> >>
> >
> > - Live snapshots
> > - We were asked to add this feature for external qcow2
> > images. Will simple approach of fsync + tracking each requested
> > backing file (it can be per vDisk) and re-open the new image
> would
> > be accepted?
>
> I had assumed that this would involve:
>
> qemu -hda windows.img
>
> (qemu) snapshot ide0-disk0 snap0.img
>
> 1) create snap0.img internally by doing the equivalent of `qemu-img
> create -f qcow2 -b windows.img snap0.img'
> 2) bdrv_flush('ide0-disk0')
> 3) bdrv_open(snap0.img)
> 4) bdrv_close(windows.img)
> 5) rename('windows.img', 'windows.img.tmp')
> 6) rename('snap0.img', 'windows.img')
> 7) rename('windows.img.tmp', 'snap0.img')
All the rename logic assumes files, need to take into account devices as well
(namely LVs)
Also, just to make sure, this should support multiple images (concurrent
snapshot of all of them or a subset).
Otherwise looks good.
>
> Regards,
>
> Anthony Liguori
>
> > - Integration with FS freeze for consistent guest app snapshot
> > Many apps do not sync their ram state to disk correctly or
> frequent
> > enough. Physical world backup software calls fs freeze on xfs
> and
> > VSS for windows to make the backup consistent.
> > In order to integrated this with live snapshots we need a guest
> > agent to trigger the guest fs freeze.
> > We can either have qemu communicate with the agent directly
> through
> > virtio-serial or have a mgmt daemon use virtio-serial to
> > communicate with the guest in addition to QMP messages about
> the
> > live snapshot state.
> > Preferences? The first solution complicates qemu while the
> second
> > complicates mgmt.
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
