Re: [Qemu-devel] HEAD is failing virt-test on migration tests

Fri, 13 Feb 2015 03:10:37 -0800 

Alex, Dave:

Virt-Test fd migration starts by sending a fd to the source vm

22:20:40 DEBUG| Send file descriptor migfd_28_1423786840 to source VM.
22:20:40 DEBUG| (monitor hmp1) Sending command 'getfd migfd_28_1423786840' 

later on...

22:20:42 INFO | Migrating to fd:migfd_28_1423786840
22:20:42 DEBUG| (monitor hmp1) Sending command 'migrate -d fd:migfd_28_1423786840' 
22:20:42 DEBUG| Send command: migrate -d fd:migfd_28_1423786840
Attached to this message you can find a .tar.bz2 file (~36Kb) with virt-test results. It contains extra information, such as a a record of vm registers taken periodically during the testing process. 

Cheers,

Lucas

On Thu, Feb 12, 2015 at 10:36 PM, Alexander Graf <ag...@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 <ag...@suse.de <mailto:ag...@suse.de>>
 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 <ag...@suse.de <mailto:ag...@suse.de>> 
     Signed-off-by: Amit Shah <amit.s...@redhat.com
 <mailto:amit.s...@redhat.com>>
     Signed-off-by: Juan Quintela <quint...@redhat.com
 <mailto:quint...@redhat.com>>

 :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?


Alex

Attachment: run-2015-02-12-22.20.21.tar.bz2
Description: application/bzip-compressed-tar

Reply via email to