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
signature.asc
Description: PGP signature