On (Wed) 16 Dec 2015 [16:52:14], Dr. David Alan Gilbert wrote:
> * Eric Blake (ebl...@redhat.com) wrote:
> > On 12/16/2015 04:47 AM, Dr. David Alan Gilbert (git) wrote:
> > > From: "Dr. David Alan Gilbert" <dgilb...@redhat.com>
> > >
> > > Emit an event each time we sync the dirty bitmap on the source;
> > > this helps libvirt use postcopy by giving it a kick when it
> > > might be a good idea to start the postcopy.
> > >
> > > Signed-off-by: Dr. David Alan Gilbert <dgilb...@redhat.com>
> > > ---
> > > docs/qmp-events.txt | 14 ++++++++++++++
> > > migration/ram.c | 4 ++++
> > > qapi/event.json | 13 +++++++++++++
> > > 3 files changed, 31 insertions(+)
> > >
> >
> > >
> > > +MIGRATION_PASS
> > > +--------------
> > > +
> > > +Emitted from the source side of a migration at the start of each pass
> > > +(when it syncs the dirty bitmap)
> > > +
> > > +Data: None.
> > > +
> > > + - "pass": An incrementing count (starting at 1 on the first pass)
> > > +
> > > +Example:
> > > +{"timestamp": {"seconds": 1449669631, "microseconds": 239225},
> > > + "event": "MIGRATION_PASS", "data": {"pass": 2}}
> >
> > How frequently can this event be emitted? It is not under guest
> > control, so it's harder to argue that it could be abused as a way for
> > the guest to DoS the host. And hopefully it is slow enough (considering
> > that each pass also requires lots more effort for actually transmitting
> > state from source to dest), so I don't think we have to worry about
> > adding rate-limiting to avoid overwhelming the monitor client.
>
> The only way that you'd get a rapid repetition of the events
> is if the pass was very short. However a very short pass is normally
> the signal to exit the iterative loop of migration and send the
> last blob at the end of migration. And that definition of 'short' is
> determined by the downtime set by the management layer anyway.
Yes, and this can also give us stats on how quickly migration is
progressing.
Amit
