From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50443) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJIeS-00060q-Af for qemu-devel@nongnu.org; Wed, 13 Jan 2016 05:27:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aJIeO-0007pc-8y for qemu-devel@nongnu.org; Wed, 13 Jan 2016 05:27:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60447) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJIeO-0007pY-3C for qemu-devel@nongnu.org; Wed, 13 Jan 2016 05:27:36 -0500 Date: Wed, 13 Jan 2016 15:57:22 +0530 From: Amit Shah Message-ID: <20160113102632.GD17885@grmbl.mre> References: <1450266458-3178-1-git-send-email-dgilbert@redhat.com> <1450266458-3178-5-git-send-email-dgilbert@redhat.com> <5671959B.60509@redhat.com> <20151216165214.GB2604@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151216165214.GB2604@work-vm> Subject: Re: [Qemu-devel] [PATCH v2 4/6] Migration: Emit event at start of pass List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: zhang.zhanghailiang@huawei.com, quintela@redhat.com, liang.z.li@intel.com, qemu-devel@nongnu.org, jdenemar@redhat.com On (Wed) 16 Dec 2015 [16:52:14], Dr. David Alan Gilbert wrote: > * Eric Blake (eblake@redhat.com) wrote: > > On 12/16/2015 04:47 AM, Dr. David Alan Gilbert (git) wrote: > > > From: "Dr. David Alan Gilbert" > > > > > > 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 > > > --- > > > 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