On Wed, Oct 25, 2023 at 04:25:23PM +0100, Daniel P. Berrangé wrote: > > Libvirt will still use fixed-ram for live snapshot purpose, especially for > > Windows? Then auto-pause may still be useful to identify that from what > > Fabiano wants to achieve here (which is in reality, non-live)? > > > > IIRC of previous discussion that was the major point that libvirt can still > > leverage fixed-ram for a live case - since Windows lacks efficient live > > snapshot (background-snapshot feature). > > Libvirt will use fixed-ram for all APIs it has that involve saving to > disk, with CPUs both running and paused.
There are still two scenarios. How should we identify them, then? For sure we can always make it live, but QEMU needs that information to make it efficient for non-live. Considering when there's no auto-pause, then Libvirt will still need to know the scenario first then to decide whether pausing VM before migration or do nothing, am I right? If so, can Libvirt replace that "pause VM" operation with setting auto-pause=on here? Again, the benefit is QEMU can benefit from it. I think when pausing Libvirt can still receive an event, then it can cooperate with state changes? Meanwhile auto-pause=on will be set by Libvirt too, so Libvirt will even have that expectation that QMP migrate later on will pause the VM. > > > From that POV it sounds like auto-pause is a good knob for that. > > From libvirt's POV auto-pause will create extra work for integration > for no gain. Yes, I agree for Libvirt there's no gain, as the gain is on QEMU's side. Could you elaborate what is the complexity for Libvirt to support it? Thanks, -- Peter Xu
