Re: [RFC PATCH 3/4] hw/acpi: add VM generation counter field to VMClock

[Babis Chalios <bchalios@amazon.es>]

On Mon, 2025-12-01 at 14:41 +0000, Daniel P. Berrangé wrote:
> On Mon, Dec 01, 2025 at 02:29:57PM +0000, David Woodhouse wrote:
> > On Mon, 2025-12-01 at 14:12 +0000, Daniel P. Berrangé wrote:
> > > From QEMU's POV, live migration and snapshots
> > > are indistiguishable operations, both using the same
> > > functionaility.
> > > 
> > > eg
> > >   $ qemu-system-x86_64 -monitor stdio -device vmclock
> > >   (qemu) migrate file:snapshot.img
> > > 
> > > and
> > > 
> > >   $ qemu-system-x86_64 -monitor stdio -device vmclock -incoming
> > > file:snapshot.img
> > > 
> > > 
> > > and we can't check the QEMU migration target being "file:" and
> > > mgmt
> > > apps can use the "fd:" protocol to pass in a pre-opened target
> > > which can
> > > be a socket or pipe or file.
> > 
> > What triggers the vmgenid to actually get updated for a snapshot?
> > That's the condition we're after, isn't it?
> 
> I don't quiet understand the sequences, but libvirt is involved in
> setting
> guid=nnnn as an arg to -device vmgenid when it spawns QEMU. This
> means
> libvirt has control over when it is changed or not.
> 

That's a shame :(

Maybe we could do the same as VMGenID then. Make vm_generation_counter
something that the user can set when creating the device (same as
VMGenID's GUID). WDYT David?

Cheers,
Babis