From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52733) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZCoYD-0007Li-LU for qemu-devel@nongnu.org; Wed, 08 Jul 2015 08:34:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZCoYA-0005WG-QB for qemu-devel@nongnu.org; Wed, 08 Jul 2015 08:34:09 -0400 Received: from e06smtp17.uk.ibm.com ([195.75.94.113]:58773) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZCoYA-0005Vw-Gz for qemu-devel@nongnu.org; Wed, 08 Jul 2015 08:34:06 -0400 Received: from /spool/local by e06smtp17.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 8 Jul 2015 13:34:04 +0100 Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 9DF7C17D8063 for ; Wed, 8 Jul 2015 13:35:18 +0100 (BST) Received: from d06av06.portsmouth.uk.ibm.com (d06av06.portsmouth.uk.ibm.com [9.149.37.217]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t68CY2X936831436 for ; Wed, 8 Jul 2015 12:34:02 GMT Received: from d06av06.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t687QvRl023431 for ; Wed, 8 Jul 2015 03:26:58 -0400 Message-ID: <559D18B9.4030800@de.ibm.com> Date: Wed, 08 Jul 2015 14:34:01 +0200 From: Christian Borntraeger MIME-Version: 1.0 References: <1436274549-28826-1-git-send-email-quintela@redhat.com> <1436274549-28826-16-git-send-email-quintela@redhat.com> <559CF767.3060000@de.ibm.com> <87a8v6onqi.fsf@neno.neno> <559D14BD.6000809@de.ibm.com> <87615uomyv.fsf@neno.neno> In-Reply-To: <87615uomyv.fsf@neno.neno> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PULL 15/28] migration: create new section to store global state List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: quintela@redhat.com Cc: amit.shah@redhat.com, Cornelia Huck , qemu-devel@nongnu.org, "Dr. David Alan Gilbert" Am 08.07.2015 um 14:25 schrieb Juan Quintela: > Christian Borntraeger wrote: >> Am 08.07.2015 um 14:08 schrieb Juan Quintela: >>> Christian Borntraeger wrote: >>>> Am 07.07.2015 um 15:08 schrieb Juan Quintela: >>>>> This includes a new section that for now just stores the current qemu state. >>>>> >>>>> Right now, there are only one way to control what is the state of the >>>>> target after migration. >>>>> >>>>> - If you run the target qemu with -S, it would start stopped. >>>>> - If you run the target qemu without -S, it would run just after >>>>> migration finishes. >>>>> >>>>> The problem here is what happens if we start the target without -S and >>>>> there happens one error during migration that puts current state as >>>>> -EIO. Migration would ends (notice that the error happend doing block >>>>> IO, network IO, i.e. nothing related with migration), and when >>>>> migration finish, we would just "continue" running on destination, >>>>> probably hanging the guest/corruption data, whatever. >>>>> >>>>> Signed-off-by: Juan Quintela >>>>> Reviewed-by: Dr. David Alan Gilbert >>>> >>>> This is bisected to cause a regression on s390. >>>> >>>> A guest restarts (booting) after managedsave/start instead of continuing. >>>> >>>> Do you have any idea what might be wrong? >>> >>> Can you check the new patch series that I sent. There is a fix that >>> *could* help there. *could* because I don't fully understand why it can >>> give you problems (and even only sometimes). Current guess is that some >>> of the devices are testing the guest state on LOAD, so that patch. >>> >>> Please, test. >> >> That patch does indeed fix my problem. >> I can see that virtio_init uses the runstate to set vm_running of the vdev. This >> is used in virtio-net for several aspects. >> But I really dont understand why this causes the symptoms. >> So I am tempted to add >> a >> Tested-by: Christian Borntraeger >> >> but I have a bad feeling on the "why" :-/ > > The other reason of that patch is that it removes the need that the > global_state is the last migration section. Hmm, we have some register_savevm here and there, but these seem to be called in device realize/init or machine init. > Could it be that you are > adding sections after you launch qemu? Or that virtio devices are > generated later on s390 for any reason? Not that I am aware of. There can be hotplug of course, but I dont see why libvirt should do that during migration. Still looking.....