Re: [Qemu-devel] [Qemu-block] Some question about savem/qcow2 incremental snapshot

[Kevin Wolf <kwolf@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2708 bytes --]

Am 30.05.2018 um 16:44 hat Stefan Hajnoczi geschrieben:
> On Mon, May 14, 2018 at 02:48:47PM +0100, Stefan Hajnoczi wrote:
> > On Fri, May 11, 2018 at 07:25:31PM +0200, Kevin Wolf wrote:
> > > Am 10.05.2018 um 10:26 hat Stefan Hajnoczi geschrieben:
> > > > On Wed, May 09, 2018 at 07:54:31PM +0200, Max Reitz wrote:
> > > > > On 2018-05-09 12:16, Stefan Hajnoczi wrote:
> > > > > > On Tue, May 08, 2018 at 05:03:09PM +0200, Kevin Wolf wrote:
> > > > > >> Am 08.05.2018 um 16:41 hat Eric Blake geschrieben:
> > > > > >>> On 12/25/2017 01:33 AM, He Junyan wrote:
> > > > > >> I think it makes sense to invest some effort into such interfaces, but
> > > > > >> be prepared for a long journey.
> > > > > > 
> > > > > > I like the suggestion but it needs to be followed up with a concrete
> > > > > > design that is feasible and fair for Junyan and others to implement.
> > > > > > Otherwise the "long journey" is really just a way of rejecting this
> > > > > > feature.
> 
> The discussion on NVDIMM via the block layer has runs its course.  It
> would be a big project and I don't think it's fair to ask Junyan to
> implement it.
> 
> My understanding is this patch series doesn't modify the qcow2 on-disk
> file format.  Rather, it just uses existing qcow2 mechanisms and extends
> live migration to identify the NVDIMM state state region to share the
> clusters.
> 
> Since this feature does not involve qcow2 format changes and is just an
> optimization (dirty blocks still need to be allocated), it can be
> removed from QEMU in the future if a better alternative becomes
> available.
> 
> Junyan: Can you rebase the series and send a new revision?
> 
> Kevin and Max: Does this sound alright?

Do patches exist? I've never seen any, so I thought this was just the
early design stage.

I suspect that while it wouldn't change the qcow2 on-disk format in a
way that the qcow2 spec would have to be change, it does need to change
the VMState format that is stored as a blob within the qcow2 file.
At least, you need to store which other snapshot it is based upon so
that you can actually resume a VM from the incremental state.

Once you modify the VMState format/the migration stream, removing it
from QEMU again later means that you can't load your old snapshots any
more. Doing that, even with the two-release deprecation period, would be
quite nasty.

But you're right, depending on how the feature is implemented, it might
not be a thing that affects qcow2 much, but one that the migration
maintainers need to have a look at. I kind of suspect that it would
actually touch both parts to a degree that it would need approval from
both sides.

Kevin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]