From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35500) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjXTj-0003p6-7i for qemu-devel@nongnu.org; Tue, 06 Oct 2015 15:01:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZjXTG-0000S6-Nc for qemu-devel@nongnu.org; Tue, 06 Oct 2015 15:00:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39593) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjXTG-0000OM-6B for qemu-devel@nongnu.org; Tue, 06 Oct 2015 15:00:18 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id EEB1A8EA2A for ; Tue, 6 Oct 2015 19:00:16 +0000 (UTC) Date: Tue, 6 Oct 2015 20:00:13 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20151006190013.GC2640@work-vm> References: <56141712.1010202@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56141712.1010202@redhat.com> Subject: Re: [Qemu-devel] Debugging Migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow Cc: qemu-devel * John Snow (jsnow@redhat.com) wrote: > Is there a convenient way of "pausing" or stalling a live migration to > allow methodical testing of race conditions? > > I'd like to instrument something along the lines of: > > (1) Live migration begins. > (2) migration is artificially halted or paused, but QEMU is allowed to run. > (3) Some additional qtest/QMP commands are received and processed. > (4) migration is allowed to resume. > > Does anyone have perhaps even test patches to instrument this sort of > thing, or is it up to detective john to add it if he wants it? If you catch it during the iterative stage you can probably just gdb or ctrl-z the destination and the migration thread should block; or alternatively migrate to a pipe and similarly ctrl-z what ever is there. Mostly I do a few things: 1) use tracing to follow it mostly just stderr tracing, but I've done systemtap scripts for some hairy stuff. 2) Set the migration speed (migrate_set_speed) very very low 3) Keep the source busy dirtying memory. Of course that does lead to the question of what fun problem are you trying to debug? Dave > --js -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK