----- "Anthony Liguori" <anthony@xxxxxxxxxxxxx> wrote:
> On 10/19/2010 11:54 AM, Ayal Baron wrote:
> > ----- "Anthony Liguori"<anthony@xxxxxxxxxxxxx> wrote:
> >
> >
> >> On 10/19/2010 07:48 AM, Dor Laor wrote:
> >>
> >>> On 10/19/2010 04:11 AM, Chris Wright wrote:
> >>>
> >>>> * Juan Quintela (quintela@xxxxxxxxxx) 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)
> >
>
> Sure, just s/rename/lvrename/g.
No can do. In our setup, lvm is running in a clustered env in a single writer multiple readers configuration. Vm may be running on a reader which is not allowed to lvrename (would corrupt the entire VG).
>
> The renaming step can be optional and a management tool can take care
> of
> that. It's really just there for convenience since the user
> expectation
> is that when you give a name of a snapshot, that the snapshot is
> reflected in that name not that the new in-use image is that name.
So keeping it optional is good.
>
> > Also, just to make sure, this should support multiple images
> (concurrent snapshot of all of them or a subset).
> >
>
> Yeah, concurrent is a little trickier. Simple solution is for a
> management tool to just do a stop + multiple snapshots + cont. It's
> equivalent to what we'd do if we don't do it aio which is probably how
>
> we'd do the first implementation.
>
> But in the long term, I think the most elegant solution would be to
> expose the freeze api via QMP and let a management tool freeze
> multiple
> devices, then start taking snapshots, then unfreeze them when all
> snapshots are complete.
>
> Regards,
>
> Anthony Liguori
qemu should call the freeze as part of the process (for all of the relevant devices) then take the snapshots then thaw.
>
> > 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 majordomo@xxxxxxxxxxxxxxx
> >>> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> >>>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
