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
