From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46439) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UF3ks-0003qc-Cc for qemu-devel@nongnu.org; Mon, 11 Mar 2013 10:31:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UF3kn-0008IH-Lh for qemu-devel@nongnu.org; Mon, 11 Mar 2013 10:31:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60867) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UF3kn-0008Hq-EJ for qemu-devel@nongnu.org; Mon, 11 Mar 2013 10:31:05 -0400 Date: Mon, 11 Mar 2013 15:31:03 +0100 From: Jiri Denemark Message-ID: <20130311143103.GA867904@orkuz.home> References: <1362644631-23113-1-git-send-email-jasowang@redhat.com> <1362644631-23113-2-git-send-email-jasowang@redhat.com> <5138B42D.3030800@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5138B42D.3030800@redhat.com> Subject: Re: [Qemu-devel] [PATCH V7 1/5] runstate: introduce prelaunch-migrate state List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: aliguori@us.ibm.com, mst@redhat.com, Jason Wang , qemu-devel@nongnu.org, owasserm@redhat.com, pbonzini@redhat.com On Thu, Mar 07, 2013 at 08:37:17 -0700, Eric Blake wrote: > On 03/07/2013 01:23 AM, Jason Wang wrote: > > Sometimes, we need track the state when guest is just about to start after > > migration. There's not a accurate state available which do this accurately > > (consider qemu may started with -S in destination). > > s/may/may be/ > > and yes, libvirt _always_ starts qemu with -S in the destination. > > > > > So this patch introduces a new state prelaunch-migrate which just tracks this > > state, it covers the case both w/ and w/o -S in destination. The first user of > > this is the support of doing announce by guest. > > > > Signed-off-by: Jason Wang > > --- > > migration.c | 3 +-- > > qapi-schema.json | 5 ++++- > > vl.c | 4 +++- > > 3 files changed, 8 insertions(+), 4 deletions(-) > > I'm not sure if this patch will have any negative effects on existing > libvirt migration or state reporting; adding Jirka to cc. I don't see any issues this patch could cause to libvirt. The only place where we ask qemu for its current state is when we reconnect to existing qemu processes after libvirtd restart. And the only thing we care about is whether the guest is running or not. We use our own state information to detect if we were migrating or not. Jirka