From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43646) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TjZ1N-0006Kd-KI for qemu-devel@nongnu.org; Fri, 14 Dec 2012 12:26:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TjZ1I-0005h5-HE for qemu-devel@nongnu.org; Fri, 14 Dec 2012 12:26:01 -0500 Received: from mx4-phx2.redhat.com ([209.132.183.25]:42301) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TjZ1I-0005gx-7y for qemu-devel@nongnu.org; Fri, 14 Dec 2012 12:25:56 -0500 Date: Fri, 14 Dec 2012 12:25:55 -0500 (EST) From: Paolo Bonzini Message-ID: <1530082961.24589944.1355505955172.JavaMail.root@redhat.com> In-Reply-To: <20121214161404.GC1776@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/3] qtest: add migrate-test List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jason Baron Cc: kwolf@redhat.com, aliguori@us.ibm.com, qemu-devel@nongnu.org, quintela@redhat.com > > Do you think this function could be turned into a libqtest call? > > Seems like a good idea. > > > It would take mach_a as an argument, add -incoming > > tcp:localhost:4444 > > to the command line of mach_a, use that to spawn mach_b, and > > why add to mach_a? I thought -incoming is just for the destination. Yep. Tack it at the end of mach_a's command line (actually at the end of the parameter of qtest_start) and use the result to start mach_b. The command-lines for the two machines must match (apart from -incoming of course), it's not necessary to pass it twice. > > return mach_b as the return value (or perhaps change mach_a to > > refer to the new machine). > > I think it makes sense for the caller to create and pass the machines > and then just call a library function to do the migrate. That way the > caller 'owns' the machines. But maybe I'm missing something. Yeah, owning the machines makes sense. In this case migration would just be a constructor for QTestState. The alternative is to kill mach_a during migration and only proceed with mach_b, since mach_a is effectively not going to be used. Paolo