Re: [Xen-devel] [qemu-mainline test] 59908: regressions - FAIL

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Sat, 2015-07-25 at 16:15 +0000, osstest service owner wrote:
> flight 59908 qemu-mainline real [real]
> http://secure-web.cisco.com/1u4kwl1o3Dc6FDtVhFHrYLmyppwmEL8O6TSGGkDPdNzjeTSjZl_GhmvpBKlKsBPNbIlSfLqlqdopz-VgXgkCmm0eXivzV7hDeVfWv9mkXQPnQ3spzegDYYVfh9iHBe-wMTmd3XUQxuatfoS10LGCgDxQSm8sKxRqO4rlyNLAnRT8/http%3A%2F%2Flogs.test-lab.xenproject.org%2Fosstest%2Flogs%2F59908%2F
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-freebsd10-i386 12 guest-saverestore       fail REGR. vs. 
> 59059
>  test-amd64-i386-xl-qemuu-ovmf-amd64 11 guest-saverestore  fail REGR. vs. 
> 59059
>  test-amd64-i386-xl-qemuu-debianhvm-amd64 11 guest-saverestore fail REGR. vs. 
> 59059
>  test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 11 guest-saverestore fail REGR. 
> vs. 59059
>  test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 11 guest-saverestore fail REGR. vs. 
> 59059
>  test-amd64-amd64-xl-qemuu-debianhvm-amd64 11 guest-saverestore fail REGR. 
> vs. 59059
>  test-amd64-amd64-xl-qemuu-ovmf-amd64 11 guest-saverestore fail REGR. vs. 
> 59059
>  test-amd64-amd64-xl-qemuu-winxpsp3 11 guest-saverestore   fail REGR. vs. 
> 59059
>  test-amd64-i386-freebsd10-amd64 12 guest-saverestore      fail REGR. vs. 
> 59059
>  test-amd64-i386-xl-qemuu-winxpsp3 11 guest-saverestore    fail REGR. vs. 
> 59059
>  test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 11 guest-saverestore fail 
> REGR. vs. 59059
>  test-amd64-amd64-xl-qemuu-win7-amd64 11 guest-saverestore fail REGR. vs. 
> 59059
>  test-amd64-i386-xl-qemuu-win7-amd64 11 guest-saverestore  fail REGR. vs. 
> 59059

http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-mainline/test-amd64-amd64-xl-qemuu-debianhvm-amd64.guest-saverestore.html

was almost complete before the bisector decided to go off on test-amd64
-i386-freebsd10-i386.guest-saverestore instead for some reason.

All it missed was the final confirmation of the last pass, but from the
logs it was just about to blame:

commit df4b1024526cae3479da3492d6371fd4a7324a03
Author: Juan Quintela <quintela@xxxxxxxxxx>
Date:   Wed Oct 8 10:58:10 2014 +0200

    migration: create new section to store global state
    
    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 <quintela@xxxxxxxxxx>
    Reviewed-by: Dr. David Alan Gilbert <dgilbert@xxxxxxxxxx>

Perhaps we need to prod some new thing during the migration now? (Or
fix this non-backwards compat change maybe)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel