Re: [Xen-devel] [xen-unstable test] 123379: regressions - FAIL

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 31.05.18 at 11:14, <jgross@xxxxxxxx> wrote:
> On 31/05/18 10:32, Juergen Gross wrote:
>> On 31/05/18 08:00, osstest service owner wrote:
>>> flight 123379 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/123379/ 
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed and are blocking,
>>> including tests which could not be run:
>>>  test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 14 guest-saverestore.2 
> fail REGR. vs. 123323
>> 
>> AFAICS this seems to be the suspected Windows reboot again?
> 
> Hmm, thinking more about it: xl save is done with the domU paused,
> so the guest rebooting concurrently is rather improbable.

Not sure, considering e.g.

libxl: libxl_stream_write.c:350:libxl__xc_domain_save_done: Domain 3:saving 
domain: domain responded to suspend request: Bad address

When looking into the Windows reboot issue (note this we're not dealing
with Windows here), I had noticed that there was a problem with trying
to save the guest at the "wrong" time. Generally, as explained back then,
I think the tool stack should honor the guest trying to reboot when it is
already in the process of being migrated/saved, and migration/save
should not even be attempted when the guest has already signaled
reboot (iirc it's only the former that is an actual issue). Otherwise the
tool stack will internally try to drive the same guest into two distinct new
states at the same time. Giving reboot (or shutdown) higher priority than
migration/save seems natural to me: A rebooting guest can be moved to
the new host with no migration cost at all, and a shut down guest doesn't
need (live) moving in the first place.

> As this is an issue occurring sporadically not only during 4.11
> development phase I don't think this should be a blocker.

Yes and no: Yes, it's not a regression. But as long as we don't make this
a blocker, I don't think the issue will be addressed, considering for how
long it has been there already.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel