From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41923) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMELo-0006L9-RT for qemu-devel@nongnu.org; Fri, 13 Feb 2015 06:24:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YMELj-0000He-SY for qemu-devel@nongnu.org; Fri, 13 Feb 2015 06:24:00 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51005) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMELj-0000HU-LQ for qemu-devel@nongnu.org; Fri, 13 Feb 2015 06:23:55 -0500 Date: Fri, 13 Feb 2015 09:23:48 -0200 From: Lucas Meneghel Rodrigues Message-Id: <1423826628.2822.1@smtp.corp.redhat.com> In-Reply-To: <54DDDD76.6060300@suse.de> References: <54DDDD76.6060300@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Subject: Re: [Qemu-devel] HEAD is failing virt-test on migration tests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: amit.shah@redhat.com, quintela@redhat.com, "Dr. David Alan Gilbert" , Lucas Meneghel Rodrigues , Developers qemu-devel On Fri, Feb 13, 2015 at 9:18 AM, Alexander Graf wrote: > > > On 13.02.15 10:04, Dr. David Alan Gilbert wrote: >> * Alexander Graf (agraf@suse.de) wrote: >>> >>> >>> On 13.02.15 01:29, Lucas Meneghel Rodrigues wrote: >>>> Copying Alex. >>>> >>>> OK, after bisecting, this is what I've got: >>>> >>>> 8118f0950fc77cce7873002a5021172dd6e040b5 is the first bad commit >>>> commit 8118f0950fc77cce7873002a5021172dd6e040b5 >>>> Author: Alexander Graf > >>>> Date: Thu Jan 22 15:01:39 2015 +0100 >>>> >>>> migration: Append JSON description of migration stream >>>> >>>> One of the annoyances of the current migration format is the >>>> fact that >>>> it's not self-describing. In fact, it's not properly >>>> describing at all. >>>> Some code randomly scattered throughout QEMU elaborates >>>> roughly how to >>>> read and write a stream of bytes. >>>> >>>> We discussed an idea during KVM Forum 2013 to add a JSON >>>> description of >>>> the migration protocol itself to the migration stream. This >>>> patch >>>> adds a section after the VM_END migration end marker that >>>> contains >>>> description data on what the device sections of the stream are >>>> composed of. >>>> >>>> This approach is backwards compatible with any QEMU version >>>> reading the >>>> stream, because QEMU just stops reading after the VM_END >>>> marker and >>>> ignores >>>> any data following it. >>>> >>>> With an additional external program this allows us to >>>> decipher the >>>> contents of any migration stream and hopefully make migration >>>> bugs >>>> easier >>>> to track down. >>>> >>>> Signed-off-by: Alexander Graf >>> > >>>> Signed-off-by: Amit Shah >>> > >>>> Signed-off-by: Juan Quintela >>> > >>>> >>>> :040000 040000 e9a8888ac242a61fbd05bbb0daa3e8877970e738 >>>> 61df81f831bc86b29f65883523ea95abb36f1ec5 Mhw >>>> :040000 040000 fe0659bed17d86c43657c26622d64fd44a1af037 >>>> 7092a6b6515a3d0077f68ff2d80dbd74597a244f Minclude >>>> :040000 040000 d90d6f1fe839abf21a45eaba5829d5a6a22abeb1 >>>> c2b1dcda197d96657458d699c185e39ae45f3c6c Mmigration >>>> :100644 100644 98895fee81edfbc659fc42d467e930d06b1afa7d >>>> 80407662ad3ed860d33a9d35f5c44b1d19c4612b Msavevm.c >>>> :040000 040000 cf218bc2b841cd51ebe3972635be2cfbb1de9dfa >>>> 7aaf3d10ef7f73413b228e854fe6f04317151e46 Mtests >>>> >>>> So there you go. I'm going to sleep, if you need any extra help >>>> let me know. >>> >>> So the major difference with this patch applied is that the sender >>> could >>> send more data than the receive wants to read. I can't see the >>> actual >>> migrate command you used down there. >>> >>> I haven't seen this actually being a problem so far, as the >>> receiver >>> just close()s its file descriptor once it hits VM_EOF. This should >>> only >>> break senders if they expect they can send more. That said, I >>> think I >>> only tested offline migration (via exec:), so maybe QEMU is >>> behaving >>> badly and actually wants to send all data and just fails the >>> migration >>> without? >> >> Hmm, for such an odd change to the migration stream it's a surprise >> you >> didn't test it live. > > Well, let's say I don't remember explicitly testing it live - I > probably > did at one point. > > I just verified that migrating with tcp:... works fine in master. It is working fine with tcp migration in master indeed. The thing is, virt-test tests a bunch of variants, among them fd. fd is the only one failing from the list of things we do test (which also happen to be the virt-test default test set). > > Alex >