* [xen-unstable test] 128240: regressions - FAIL
@ 2018-09-30 21:59 osstest service owner
2018-10-01 9:04 ` Jan Beulich
0 siblings, 1 reply; 19+ messages in thread
From: osstest service owner @ 2018-09-30 21:59 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 128240 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128240/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs. 128084
test-amd64-i386-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs. 128084
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 128084
test-armhf-armhf-libvirt 14 saverestore-support-check fail like 128084
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 128084
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 128084
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 128084
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 128084
test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 128084
test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 128084
test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 128084
test-amd64-i386-xl-pvshim 12 guest-start fail never pass
test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-i386-libvirt 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass
test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-arm64-arm64-xl 13 migrate-support-check fail never pass
test-arm64-arm64-xl 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-xl 13 migrate-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt 13 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass
test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass
test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install fail never pass
test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
test-amd64-amd64-xl-qemut-win10-i386 10 windows-install fail never pass
test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
version targeted for testing:
xen edb4724e36256c495a6aa3cf1a12722efe271f9d
baseline version:
xen 940185b2f6f343251c2b83bd96e599398cea51ec
Last test of basis 128084 2018-09-26 01:51:53 Z 4 days
Failing since 128118 2018-09-27 00:37:03 Z 3 days 3 attempts
Testing same since 128240 2018-09-29 20:04:05 Z 1 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Alexandru Isaila <aisaila@bitdefender.com>
Amit Singh Tomar <amittomer25@gmail.com>
Andrew Cooper <andrew.cooper3@citrix.com>
Andrii Anisov <andrii_anisov@epam.com>
Christian Lindig <christian.lindig@citrix.com>
Christopher Clark <christopher.clark6@baesystems.com>
Daniel Kiper <daniel.kiper@oracle.com>
Dario Faggioli <dfaggioli@suse.com>
Doug Goldstein <cardoe@cardoe.com>
George Dunlap <george.dunlap@citrix.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Julien Grall <julien.grall@arm.com>
Razvan Cojocaru <rcojocaru@bitdefender.com>
Roger Pau Monné <roger.pau@citrix.com>
Samuel Thibault <samuel.thibault@ens-lyon.org>
Tamas K Lengyel <tamas@tklengyel.com>
Wei Liu <wei.liu2@citrix.com>
Yang Qian <krizex@gmail.com>
Yang Qian <yang.qian@citrix.com>
jobs:
build-amd64-xsm pass
build-arm64-xsm pass
build-i386-xsm pass
build-amd64-xtf pass
build-amd64 pass
build-arm64 pass
build-armhf pass
build-amd64-xen-freebsd pass
build-amd64-xen-xsm-freebsd pass
build-i386 pass
build-amd64-libvirt pass
build-arm64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-prev pass
build-i386-prev pass
build-amd64-pvops pass
build-arm64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
build-amd64-rumprun pass
build-i386-rumprun pass
test-xtf-amd64-amd64-1 pass
test-xtf-amd64-amd64-2 pass
test-xtf-amd64-amd64-3 pass
test-xtf-amd64-amd64-4 pass
test-xtf-amd64-amd64-5 pass
test-amd64-amd64-xl pass
test-arm64-arm64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-arm64-arm64-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-arm64-arm64-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvhv2-amd pass
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-rumprun-amd64 pass
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-qemut-ws16-amd64 fail
test-amd64-i386-xl-qemut-ws16-amd64 fail
test-amd64-amd64-xl-qemuu-ws16-amd64 fail
test-amd64-i386-xl-qemuu-ws16-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit1 pass
test-arm64-arm64-xl-credit1 pass
test-armhf-armhf-xl-credit1 pass
test-amd64-amd64-xl-credit2 pass
test-arm64-arm64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass
test-amd64-amd64-examine pass
test-arm64-arm64-examine pass
test-armhf-armhf-examine pass
test-amd64-i386-examine pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-rumprun-i386 pass
test-amd64-amd64-xl-qemut-win10-i386 fail
test-amd64-i386-xl-qemut-win10-i386 fail
test-amd64-amd64-xl-qemuu-win10-i386 fail
test-amd64-i386-xl-qemuu-win10-i386 fail
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-amd64-xl-pvhv2-intel pass
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-livepatch pass
test-amd64-i386-livepatch pass
test-amd64-amd64-migrupgrade fail
test-amd64-i386-migrupgrade fail
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-xl-pvshim pass
test-amd64-i386-xl-pvshim fail
test-amd64-amd64-pygrub pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw pass
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds pass
test-armhf-armhf-xl-rtds pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-amd64-xl-shadow pass
test-amd64-i386-xl-shadow pass
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
(No revision log; it would be 600 lines long.)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [xen-unstable test] 128240: regressions - FAIL
2018-09-30 21:59 [xen-unstable test] 128240: regressions - FAIL osstest service owner
@ 2018-10-01 9:04 ` Jan Beulich
2018-10-01 14:33 ` Wei Liu
0 siblings, 1 reply; 19+ messages in thread
From: Jan Beulich @ 2018-10-01 9:04 UTC (permalink / raw)
To: xen-devel; +Cc: George Dunlap, osstest service owner
>>> On 30.09.18 at 23:59, <osstest-admin@xenproject.org> wrote:
> flight 128240 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/128240/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs. 128084
At the first glance
libxl: error: libxl_sched.c:232:sched_credit_domain_set: Domain 1:Getting domain sched credit: Invalid argument
libxl: error: libxl_create.c:1275:domcreate_rebuild_done: Domain 1:cannot (re-)build domain: -3
might indicate a problem resulting from the switch to credit2 as the default
scheduler. But "first glance" here really means what it says - I didn't look
(yet) at what exactly libxl tries to do there, in the hope that others may
know without much digging.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [xen-unstable test] 128240: regressions - FAIL
2018-10-01 9:04 ` Jan Beulich
@ 2018-10-01 14:33 ` Wei Liu
2018-10-01 15:10 ` Jan Beulich
0 siblings, 1 reply; 19+ messages in thread
From: Wei Liu @ 2018-10-01 14:33 UTC (permalink / raw)
To: Jan Beulich
Cc: Wei Liu, George Dunlap, Dario Faggioli, Ian Jackson,
osstest service owner, xen-devel
On Mon, Oct 01, 2018 at 03:04:02AM -0600, Jan Beulich wrote:
> >>> On 30.09.18 at 23:59, <osstest-admin@xenproject.org> wrote:
> > flight 128240 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/128240/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> > test-amd64-amd64-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs. 128084
>
> At the first glance
>
> libxl: error: libxl_sched.c:232:sched_credit_domain_set: Domain 1:Getting domain sched credit: Invalid argument
> libxl: error: libxl_create.c:1275:domcreate_rebuild_done: Domain 1:cannot (re-)build domain: -3
>
> might indicate a problem resulting from the switch to credit2 as the default
> scheduler. But "first glance" here really means what it says - I didn't look
> (yet) at what exactly libxl tries to do there, in the hope that others may
> know without much digging.
I think this is due to toolstack trying to set the same scheduler
parameters for the newly created guest.
But in this test, the destination host is using a different scheduler
from the source host. Asking for credit scheduler on a credit2 host is
wrong.
The relevant snippet in guest cfg (JSON) is:
"sched_params": {
"sched": "credit",
"weight": 256,
"cap": 0
},
I can't think of a method to fix it off the top of my head though.
Wei.
>
> Jan
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [xen-unstable test] 128240: regressions - FAIL
2018-10-01 14:33 ` Wei Liu
@ 2018-10-01 15:10 ` Jan Beulich
2018-10-01 15:17 ` Wei Liu
0 siblings, 1 reply; 19+ messages in thread
From: Jan Beulich @ 2018-10-01 15:10 UTC (permalink / raw)
To: Wei Liu
Cc: George Dunlap, xen-devel, Dario Faggioli, Ian Jackson,
osstest service owner
>>> On 01.10.18 at 16:33, <wei.liu2@citrix.com> wrote:
> On Mon, Oct 01, 2018 at 03:04:02AM -0600, Jan Beulich wrote:
>> >>> On 30.09.18 at 23:59, <osstest-admin@xenproject.org> wrote:
>> > flight 128240 xen-unstable real [real]
>> > http://logs.test-lab.xenproject.org/osstest/logs/128240/
>> >
>> > Regressions :-(
>> >
>> > Tests which did not succeed and are blocking,
>> > including tests which could not be run:
>> > test-amd64-amd64-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs.
> 128084
>>
>> At the first glance
>>
>> libxl: error: libxl_sched.c:232:sched_credit_domain_set: Domain 1:Getting
> domain sched credit: Invalid argument
>> libxl: error: libxl_create.c:1275:domcreate_rebuild_done: Domain 1:cannot
> (re-)build domain: -3
>>
>> might indicate a problem resulting from the switch to credit2 as the default
>> scheduler. But "first glance" here really means what it says - I didn't look
>> (yet) at what exactly libxl tries to do there, in the hope that others may
>> know without much digging.
>
> I think this is due to toolstack trying to set the same scheduler
> parameters for the newly created guest.
>
> But in this test, the destination host is using a different scheduler
> from the source host. Asking for credit scheduler on a credit2 host is
> wrong.
>
> The relevant snippet in guest cfg (JSON) is:
>
> "sched_params": {
> "sched": "credit",
> "weight": 256,
> "cap": 0
> },
>
> I can't think of a method to fix it off the top of my head though.
So is this something that was specified in the original config? Or
is it just the current value which gets read and an attempt made
to re-install. If there was no explicit setting in the guest config,
shouldn't such a "default" setting be retained by not transferring
any scheduler specifics during migration?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [xen-unstable test] 128240: regressions - FAIL
2018-10-01 15:10 ` Jan Beulich
@ 2018-10-01 15:17 ` Wei Liu
2018-10-01 15:19 ` George Dunlap
0 siblings, 1 reply; 19+ messages in thread
From: Wei Liu @ 2018-10-01 15:17 UTC (permalink / raw)
To: Jan Beulich
Cc: Wei Liu, George Dunlap, Dario Faggioli, Ian Jackson,
osstest service owner, xen-devel
On Mon, Oct 01, 2018 at 09:10:25AM -0600, Jan Beulich wrote:
> >>> On 01.10.18 at 16:33, <wei.liu2@citrix.com> wrote:
> > On Mon, Oct 01, 2018 at 03:04:02AM -0600, Jan Beulich wrote:
> >> >>> On 30.09.18 at 23:59, <osstest-admin@xenproject.org> wrote:
> >> > flight 128240 xen-unstable real [real]
> >> > http://logs.test-lab.xenproject.org/osstest/logs/128240/
> >> >
> >> > Regressions :-(
> >> >
> >> > Tests which did not succeed and are blocking,
> >> > including tests which could not be run:
> >> > test-amd64-amd64-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs.
> > 128084
> >>
> >> At the first glance
> >>
> >> libxl: error: libxl_sched.c:232:sched_credit_domain_set: Domain 1:Getting
> > domain sched credit: Invalid argument
> >> libxl: error: libxl_create.c:1275:domcreate_rebuild_done: Domain 1:cannot
> > (re-)build domain: -3
> >>
> >> might indicate a problem resulting from the switch to credit2 as the default
> >> scheduler. But "first glance" here really means what it says - I didn't look
> >> (yet) at what exactly libxl tries to do there, in the hope that others may
> >> know without much digging.
> >
> > I think this is due to toolstack trying to set the same scheduler
> > parameters for the newly created guest.
> >
> > But in this test, the destination host is using a different scheduler
> > from the source host. Asking for credit scheduler on a credit2 host is
> > wrong.
> >
> > The relevant snippet in guest cfg (JSON) is:
> >
> > "sched_params": {
> > "sched": "credit",
> > "weight": 256,
> > "cap": 0
> > },
> >
> > I can't think of a method to fix it off the top of my head though.
>
> So is this something that was specified in the original config? Or
> is it just the current value which gets read and an attempt made
> to re-install. If there was no explicit setting in the guest config,
> shouldn't such a "default" setting be retained by not transferring
> any scheduler specifics during migration?
>
No setting in guest cfg. Those values are extracted from the hypervisor.
I think we may be able to not send default values to the remote end.
Wei.
> Jan
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [xen-unstable test] 128240: regressions - FAIL
2018-10-01 15:17 ` Wei Liu
@ 2018-10-01 15:19 ` George Dunlap
2018-10-01 15:35 ` Wei Liu
0 siblings, 1 reply; 19+ messages in thread
From: George Dunlap @ 2018-10-01 15:19 UTC (permalink / raw)
To: Wei Liu, Jan Beulich
Cc: George Dunlap, xen-devel, Dario Faggioli, Ian Jackson,
osstest service owner
On 10/01/2018 04:17 PM, Wei Liu wrote:
> On Mon, Oct 01, 2018 at 09:10:25AM -0600, Jan Beulich wrote:
>>>>> On 01.10.18 at 16:33, <wei.liu2@citrix.com> wrote:
>>> On Mon, Oct 01, 2018 at 03:04:02AM -0600, Jan Beulich wrote:
>>>>>>> On 30.09.18 at 23:59, <osstest-admin@xenproject.org> wrote:
>>>>> flight 128240 xen-unstable real [real]
>>>>> http://logs.test-lab.xenproject.org/osstest/logs/128240/
>>>>>
>>>>> Regressions :-(
>>>>>
>>>>> Tests which did not succeed and are blocking,
>>>>> including tests which could not be run:
>>>>> test-amd64-amd64-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs.
>>> 128084
>>>>
>>>> At the first glance
>>>>
>>>> libxl: error: libxl_sched.c:232:sched_credit_domain_set: Domain 1:Getting
>>> domain sched credit: Invalid argument
>>>> libxl: error: libxl_create.c:1275:domcreate_rebuild_done: Domain 1:cannot
>>> (re-)build domain: -3
>>>>
>>>> might indicate a problem resulting from the switch to credit2 as the default
>>>> scheduler. But "first glance" here really means what it says - I didn't look
>>>> (yet) at what exactly libxl tries to do there, in the hope that others may
>>>> know without much digging.
>>>
>>> I think this is due to toolstack trying to set the same scheduler
>>> parameters for the newly created guest.
>>>
>>> But in this test, the destination host is using a different scheduler
>>> from the source host. Asking for credit scheduler on a credit2 host is
>>> wrong.
>>>
>>> The relevant snippet in guest cfg (JSON) is:
>>>
>>> "sched_params": {
>>> "sched": "credit",
>>> "weight": 256,
>>> "cap": 0
>>> },
>>>
>>> I can't think of a method to fix it off the top of my head though.
>>
>> So is this something that was specified in the original config? Or
>> is it just the current value which gets read and an attempt made
>> to re-install. If there was no explicit setting in the guest config,
>> shouldn't such a "default" setting be retained by not transferring
>> any scheduler specifics during migration?
>>
>
> No setting in guest cfg. Those values are extracted from the hypervisor.
> I think we may be able to not send default values to the remote end.
Wait, the migration code reads the scheduler parameters -- even if these
have not been explicitly set by the admin -- and sends them along with
the migration stream? And if the remote scheduler is different, the
migration fails?
That's not so good. :-)
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [xen-unstable test] 128240: regressions - FAIL
2018-10-01 15:19 ` George Dunlap
@ 2018-10-01 15:35 ` Wei Liu
[not found] ` <fc2bbc89cfc7d9066fe0b1fd76ddd2ff@citrix.com>
` (3 more replies)
0 siblings, 4 replies; 19+ messages in thread
From: Wei Liu @ 2018-10-01 15:35 UTC (permalink / raw)
To: George Dunlap
Cc: Wei Liu, George Dunlap, Dario Faggioli, Ian Jackson,
osstest service owner, Jan Beulich, xen-devel
On Mon, Oct 01, 2018 at 04:19:07PM +0100, George Dunlap wrote:
> On 10/01/2018 04:17 PM, Wei Liu wrote:
> > On Mon, Oct 01, 2018 at 09:10:25AM -0600, Jan Beulich wrote:
> >>>>> On 01.10.18 at 16:33, <wei.liu2@citrix.com> wrote:
> >>> On Mon, Oct 01, 2018 at 03:04:02AM -0600, Jan Beulich wrote:
> >>>>>>> On 30.09.18 at 23:59, <osstest-admin@xenproject.org> wrote:
> >>>>> flight 128240 xen-unstable real [real]
> >>>>> http://logs.test-lab.xenproject.org/osstest/logs/128240/
> >>>>>
> >>>>> Regressions :-(
> >>>>>
> >>>>> Tests which did not succeed and are blocking,
> >>>>> including tests which could not be run:
> >>>>> test-amd64-amd64-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs.
> >>> 128084
> >>>>
> >>>> At the first glance
> >>>>
> >>>> libxl: error: libxl_sched.c:232:sched_credit_domain_set: Domain 1:Getting
> >>> domain sched credit: Invalid argument
> >>>> libxl: error: libxl_create.c:1275:domcreate_rebuild_done: Domain 1:cannot
> >>> (re-)build domain: -3
> >>>>
> >>>> might indicate a problem resulting from the switch to credit2 as the default
> >>>> scheduler. But "first glance" here really means what it says - I didn't look
> >>>> (yet) at what exactly libxl tries to do there, in the hope that others may
> >>>> know without much digging.
> >>>
> >>> I think this is due to toolstack trying to set the same scheduler
> >>> parameters for the newly created guest.
> >>>
> >>> But in this test, the destination host is using a different scheduler
> >>> from the source host. Asking for credit scheduler on a credit2 host is
> >>> wrong.
> >>>
> >>> The relevant snippet in guest cfg (JSON) is:
> >>>
> >>> "sched_params": {
> >>> "sched": "credit",
> >>> "weight": 256,
> >>> "cap": 0
> >>> },
> >>>
> >>> I can't think of a method to fix it off the top of my head though.
> >>
> >> So is this something that was specified in the original config? Or
> >> is it just the current value which gets read and an attempt made
> >> to re-install. If there was no explicit setting in the guest config,
> >> shouldn't such a "default" setting be retained by not transferring
> >> any scheduler specifics during migration?
> >>
> >
> > No setting in guest cfg. Those values are extracted from the hypervisor.
> > I think we may be able to not send default values to the remote end.
>
> Wait, the migration code reads the scheduler parameters -- even if these
> have not been explicitly set by the admin -- and sends them along with
> the migration stream? And if the remote scheduler is different, the
> migration fails?
>
> That's not so good. :-)
But one can argue that the guest is specific configured that way so it's
parameters should be preserved. We normally analyse things on a case by
case basis.
Wei.
>
> -George
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [xen-unstable test] 128240: regressions - FAIL
2018-10-01 15:35 ` Wei Liu
[not found] ` <fc2bbc89cfc7d9066fe0b1fd76ddd2ff@citrix.com>
[not found] ` <fc2bbc89cfc7d9066fe0b1fd76ddd2ff@citrix.com>
@ 2018-10-01 15:40 ` Andrew Cooper
2018-10-01 15:48 ` George Dunlap
2018-10-01 18:02 ` Dario Faggioli
3 siblings, 1 reply; 19+ messages in thread
From: Andrew Cooper @ 2018-10-01 15:40 UTC (permalink / raw)
To: Wei Liu, George Dunlap
Cc: George Dunlap, Dario Faggioli, Ian Jackson,
osstest service owner, Jan Beulich, xen-devel
On 01/10/18 16:35, Wei Liu wrote:
> On Mon, Oct 01, 2018 at 04:19:07PM +0100, George Dunlap wrote:
>> On 10/01/2018 04:17 PM, Wei Liu wrote:
>>> On Mon, Oct 01, 2018 at 09:10:25AM -0600, Jan Beulich wrote:
>>>>>>> On 01.10.18 at 16:33, <wei.liu2@citrix.com> wrote:
>>>>> On Mon, Oct 01, 2018 at 03:04:02AM -0600, Jan Beulich wrote:
>>>>>>>>> On 30.09.18 at 23:59, <osstest-admin@xenproject.org> wrote:
>>>>>>> flight 128240 xen-unstable real [real]
>>>>>>> http://logs.test-lab.xenproject.org/osstest/logs/128240/
>>>>>>>
>>>>>>> Regressions :-(
>>>>>>>
>>>>>>> Tests which did not succeed and are blocking,
>>>>>>> including tests which could not be run:
>>>>>>> test-amd64-amd64-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs.
>>>>> 128084
>>>>>> At the first glance
>>>>>>
>>>>>> libxl: error: libxl_sched.c:232:sched_credit_domain_set: Domain 1:Getting
>>>>> domain sched credit: Invalid argument
>>>>>> libxl: error: libxl_create.c:1275:domcreate_rebuild_done: Domain 1:cannot
>>>>> (re-)build domain: -3
>>>>>> might indicate a problem resulting from the switch to credit2 as the default
>>>>>> scheduler. But "first glance" here really means what it says - I didn't look
>>>>>> (yet) at what exactly libxl tries to do there, in the hope that others may
>>>>>> know without much digging.
>>>>> I think this is due to toolstack trying to set the same scheduler
>>>>> parameters for the newly created guest.
>>>>>
>>>>> But in this test, the destination host is using a different scheduler
>>>>> from the source host. Asking for credit scheduler on a credit2 host is
>>>>> wrong.
>>>>>
>>>>> The relevant snippet in guest cfg (JSON) is:
>>>>>
>>>>> "sched_params": {
>>>>> "sched": "credit",
>>>>> "weight": 256,
>>>>> "cap": 0
>>>>> },
>>>>>
>>>>> I can't think of a method to fix it off the top of my head though.
>>>> So is this something that was specified in the original config? Or
>>>> is it just the current value which gets read and an attempt made
>>>> to re-install. If there was no explicit setting in the guest config,
>>>> shouldn't such a "default" setting be retained by not transferring
>>>> any scheduler specifics during migration?
>>>>
>>> No setting in guest cfg. Those values are extracted from the hypervisor.
>>> I think we may be able to not send default values to the remote end.
>> Wait, the migration code reads the scheduler parameters -- even if these
>> have not been explicitly set by the admin -- and sends them along with
>> the migration stream? And if the remote scheduler is different, the
>> migration fails?
>>
>> That's not so good. :-)
> But one can argue that the guest is specific configured that way so it's
> parameters should be preserved. We normally analyse things on a case by
> case basis.
If there isn't an obvious fix, then the switch of default scheduler
needs reverting until there is a fix present. This is currently
blocking master.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [xen-unstable test] 128240: regressions - FAIL
2018-10-01 15:40 ` Andrew Cooper
@ 2018-10-01 15:48 ` George Dunlap
2018-10-01 16:07 ` Juergen Gross
0 siblings, 1 reply; 19+ messages in thread
From: George Dunlap @ 2018-10-01 15:48 UTC (permalink / raw)
To: Andrew Cooper, Wei Liu
Cc: George Dunlap, Dario Faggioli, Ian Jackson,
osstest service owner, Dario Faggioli, Jan Beulich, xen-devel
On 10/01/2018 04:40 PM, Andrew Cooper wrote:
> On 01/10/18 16:35, Wei Liu wrote:
>> On Mon, Oct 01, 2018 at 04:19:07PM +0100, George Dunlap wrote:
>>> On 10/01/2018 04:17 PM, Wei Liu wrote:
>>>> On Mon, Oct 01, 2018 at 09:10:25AM -0600, Jan Beulich wrote:
>>>>>>>> On 01.10.18 at 16:33, <wei.liu2@citrix.com> wrote:
>>>>>> On Mon, Oct 01, 2018 at 03:04:02AM -0600, Jan Beulich wrote:
>>>>>>>>>> On 30.09.18 at 23:59, <osstest-admin@xenproject.org> wrote:
>>>>>>>> flight 128240 xen-unstable real [real]
>>>>>>>> http://logs.test-lab.xenproject.org/osstest/logs/128240/
>>>>>>>>
>>>>>>>> Regressions :-(
>>>>>>>>
>>>>>>>> Tests which did not succeed and are blocking,
>>>>>>>> including tests which could not be run:
>>>>>>>> test-amd64-amd64-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs.
>>>>>> 128084
>>>>>>> At the first glance
>>>>>>>
>>>>>>> libxl: error: libxl_sched.c:232:sched_credit_domain_set: Domain 1:Getting
>>>>>> domain sched credit: Invalid argument
>>>>>>> libxl: error: libxl_create.c:1275:domcreate_rebuild_done: Domain 1:cannot
>>>>>> (re-)build domain: -3
>>>>>>> might indicate a problem resulting from the switch to credit2 as the default
>>>>>>> scheduler. But "first glance" here really means what it says - I didn't look
>>>>>>> (yet) at what exactly libxl tries to do there, in the hope that others may
>>>>>>> know without much digging.
>>>>>> I think this is due to toolstack trying to set the same scheduler
>>>>>> parameters for the newly created guest.
>>>>>>
>>>>>> But in this test, the destination host is using a different scheduler
>>>>>> from the source host. Asking for credit scheduler on a credit2 host is
>>>>>> wrong.
>>>>>>
>>>>>> The relevant snippet in guest cfg (JSON) is:
>>>>>>
>>>>>> "sched_params": {
>>>>>> "sched": "credit",
>>>>>> "weight": 256,
>>>>>> "cap": 0
>>>>>> },
>>>>>>
>>>>>> I can't think of a method to fix it off the top of my head though.
>>>>> So is this something that was specified in the original config? Or
>>>>> is it just the current value which gets read and an attempt made
>>>>> to re-install. If there was no explicit setting in the guest config,
>>>>> shouldn't such a "default" setting be retained by not transferring
>>>>> any scheduler specifics during migration?
>>>>>
>>>> No setting in guest cfg. Those values are extracted from the hypervisor.
>>>> I think we may be able to not send default values to the remote end.
>>> Wait, the migration code reads the scheduler parameters -- even if these
>>> have not been explicitly set by the admin -- and sends them along with
>>> the migration stream? And if the remote scheduler is different, the
>>> migration fails?
>>>
>>> That's not so good. :-)
>> But one can argue that the guest is specific configured that way so it's
>> parameters should be preserved. We normally analyse things on a case by
>> case basis.
>
> If there isn't an obvious fix, then the switch of default scheduler
> needs reverting until there is a fix present. This is currently
> blocking master.
Agreed. I'd argue for ignoring failures to set scheduler parameters on
migrate, on the grounds that this will be less risk to the project as a
whole than reverting credit2 again. But either way we should do
something quickly.
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [xen-unstable test] 128240: regressions - FAIL
2018-10-01 15:48 ` George Dunlap
@ 2018-10-01 16:07 ` Juergen Gross
2018-10-01 17:58 ` Dario Faggioli
` (2 more replies)
0 siblings, 3 replies; 19+ messages in thread
From: Juergen Gross @ 2018-10-01 16:07 UTC (permalink / raw)
To: George Dunlap, Andrew Cooper, Wei Liu
Cc: George Dunlap, Dario Faggioli, Ian Jackson,
osstest service owner, Dario Faggioli, Jan Beulich, xen-devel
On 01/10/2018 17:48, George Dunlap wrote:
> On 10/01/2018 04:40 PM, Andrew Cooper wrote:
>> On 01/10/18 16:35, Wei Liu wrote:
>>> On Mon, Oct 01, 2018 at 04:19:07PM +0100, George Dunlap wrote:
>>>> On 10/01/2018 04:17 PM, Wei Liu wrote:
>>>>> On Mon, Oct 01, 2018 at 09:10:25AM -0600, Jan Beulich wrote:
>>>>>>>>> On 01.10.18 at 16:33, <wei.liu2@citrix.com> wrote:
>>>>>>> On Mon, Oct 01, 2018 at 03:04:02AM -0600, Jan Beulich wrote:
>>>>>>>>>>> On 30.09.18 at 23:59, <osstest-admin@xenproject.org> wrote:
>>>>>>>>> flight 128240 xen-unstable real [real]
>>>>>>>>> http://logs.test-lab.xenproject.org/osstest/logs/128240/
>>>>>>>>>
>>>>>>>>> Regressions :-(
>>>>>>>>>
>>>>>>>>> Tests which did not succeed and are blocking,
>>>>>>>>> including tests which could not be run:
>>>>>>>>> test-amd64-amd64-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs.
>>>>>>> 128084
>>>>>>>> At the first glance
>>>>>>>>
>>>>>>>> libxl: error: libxl_sched.c:232:sched_credit_domain_set: Domain 1:Getting
>>>>>>> domain sched credit: Invalid argument
>>>>>>>> libxl: error: libxl_create.c:1275:domcreate_rebuild_done: Domain 1:cannot
>>>>>>> (re-)build domain: -3
>>>>>>>> might indicate a problem resulting from the switch to credit2 as the default
>>>>>>>> scheduler. But "first glance" here really means what it says - I didn't look
>>>>>>>> (yet) at what exactly libxl tries to do there, in the hope that others may
>>>>>>>> know without much digging.
>>>>>>> I think this is due to toolstack trying to set the same scheduler
>>>>>>> parameters for the newly created guest.
>>>>>>>
>>>>>>> But in this test, the destination host is using a different scheduler
>>>>>>> from the source host. Asking for credit scheduler on a credit2 host is
>>>>>>> wrong.
>>>>>>>
>>>>>>> The relevant snippet in guest cfg (JSON) is:
>>>>>>>
>>>>>>> "sched_params": {
>>>>>>> "sched": "credit",
>>>>>>> "weight": 256,
>>>>>>> "cap": 0
>>>>>>> },
>>>>>>>
>>>>>>> I can't think of a method to fix it off the top of my head though.
>>>>>> So is this something that was specified in the original config? Or
>>>>>> is it just the current value which gets read and an attempt made
>>>>>> to re-install. If there was no explicit setting in the guest config,
>>>>>> shouldn't such a "default" setting be retained by not transferring
>>>>>> any scheduler specifics during migration?
>>>>>>
>>>>> No setting in guest cfg. Those values are extracted from the hypervisor.
>>>>> I think we may be able to not send default values to the remote end.
>>>> Wait, the migration code reads the scheduler parameters -- even if these
>>>> have not been explicitly set by the admin -- and sends them along with
>>>> the migration stream? And if the remote scheduler is different, the
>>>> migration fails?
>>>>
>>>> That's not so good. :-)
>>> But one can argue that the guest is specific configured that way so it's
>>> parameters should be preserved. We normally analyse things on a case by
>>> case basis.
>>
>> If there isn't an obvious fix, then the switch of default scheduler
>> needs reverting until there is a fix present. This is currently
>> blocking master.
>
> Agreed. I'd argue for ignoring failures to set scheduler parameters on
> migrate, on the grounds that this will be less risk to the project as a
> whole than reverting credit2 again. But either way we should do
> something quickly.
We should ignore a mismatch of the scheduler. Failures when setting
parameters for a matching scheduler should not be ignored IMO.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [xen-unstable test] 128240: regressions - FAIL
2018-10-01 16:07 ` Juergen Gross
@ 2018-10-01 17:58 ` Dario Faggioli
2018-10-02 10:06 ` George Dunlap
2018-10-02 8:29 ` Jan Beulich
[not found] ` <5BB32C7802000078001ED8FA@suse.com>
2 siblings, 1 reply; 19+ messages in thread
From: Dario Faggioli @ 2018-10-01 17:58 UTC (permalink / raw)
To: Juergen Gross, George Dunlap, Andrew Cooper, Wei Liu
Cc: George Dunlap, xen-devel, Ian Jackson, osstest service owner,
Jan Beulich
[-- Attachment #1.1: Type: text/plain, Size: 2232 bytes --]
On Mon, 2018-10-01 at 18:07 +0200, Juergen Gross wrote:
> On 01/10/2018 17:48, George Dunlap wrote:
> > On 10/01/2018 04:40 PM, Andrew Cooper wrote:
> > > On 01/10/18 16:35, Wei Liu wrote:
> > > > > Wait, the migration code reads the scheduler parameters --
> > > > > even if these
> > > > > have not been explicitly set by the admin -- and sends them
> > > > > along with
> > > > > the migration stream? And if the remote scheduler is
> > > > > different, the
> > > > > migration fails?
> > > > >
> > > > > That's not so good. :-)
> > > >
> > > > But one can argue that the guest is specific configured that
> > > > way so it's
> > > > parameters should be preserved. We normally analyse things on a
> > > > case by
> > > > case basis.
> > >
> > > If there isn't an obvious fix, then the switch of default
> > > scheduler
> > > needs reverting until there is a fix present. This is currently
> > > blocking master.
> >
> > Agreed. I'd argue for ignoring failures to set scheduler
> > parameters on
> > migrate, on the grounds that this will be less risk to the project
> > as a
> > whole than reverting credit2 again. But either way we should do
> > something quickly.
>
> We should ignore a mismatch of the scheduler. Failures when setting
> parameters for a matching scheduler should not be ignored IMO.
>
Indeed! Especially considering that this isn't really related on what
the default scheduler is (despite it being making Credit2 default that
triggers the issue).
In fact, what if:
- user uses Credit1 (default and supported) on host A
- user uses Credit2 (supported) on host B
- user migrates VM
- BOOOM!
So, unless it is intended --and, I'd say, also documented somewhere--
that migrating between hosts which use different schedulers is to be
avoided, this is already a bug, whatever the default scheduler is...
George, let me know if you're working on a fix already, or if I should
do that myself.
Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [xen-unstable test] 128240: regressions - FAIL
2018-10-01 15:35 ` Wei Liu
` (2 preceding siblings ...)
2018-10-01 15:40 ` Andrew Cooper
@ 2018-10-01 18:02 ` Dario Faggioli
3 siblings, 0 replies; 19+ messages in thread
From: Dario Faggioli @ 2018-10-01 18:02 UTC (permalink / raw)
To: Wei Liu, George Dunlap
Cc: George Dunlap, xen-devel, Ian Jackson, osstest service owner,
Jan Beulich
[-- Attachment #1.1: Type: text/plain, Size: 1308 bytes --]
On Mon, 2018-10-01 at 16:35 +0100, Wei Liu wrote:
> On Mon, Oct 01, 2018 at 04:19:07PM +0100, George Dunlap wrote:
> > Wait, the migration code reads the scheduler parameters -- even if
> > these
> > have not been explicitly set by the admin -- and sends them along
> > with
> > the migration stream? And if the remote scheduler is different,
> > the
> > migration fails?
> >
> > That's not so good. :-)
>
> But one can argue that the guest is specific configured that way so
> it's
> parameters should be preserved. We normally analyse things on a case
> by
> case basis.
>
Sure, but then this means that, in the restore path, we should query
the scheduler which is in use on the host.
If it is the same one that we also see in the migration stream, we try
to set the parameters. If it is a different one, we skip the setparam
all together (which is basically what Juergen is suggesting later in
the thread, AFAICT).
I don't think I've ever worked on migration, but I can try to look into
fixing this (tomorrow).
Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [xen-unstable test] 128240: regressions - FAIL
2018-10-01 16:07 ` Juergen Gross
2018-10-01 17:58 ` Dario Faggioli
@ 2018-10-02 8:29 ` Jan Beulich
[not found] ` <5BB32C7802000078001ED8FA@suse.com>
2 siblings, 0 replies; 19+ messages in thread
From: Jan Beulich @ 2018-10-02 8:29 UTC (permalink / raw)
To: george.dunlap, Wei Liu, Juergen Gross
Cc: George Dunlap, Andrew Cooper, Dario Faggioli, Ian Jackson,
osstest service owner, Dario Faggioli, xen-devel
>>> On 01.10.18 at 18:07, <jgross@suse.com> wrote:
> On 01/10/2018 17:48, George Dunlap wrote:
>> On 10/01/2018 04:40 PM, Andrew Cooper wrote:
>>> If there isn't an obvious fix, then the switch of default scheduler
>>> needs reverting until there is a fix present. This is currently
>>> blocking master.
>>
>> Agreed. I'd argue for ignoring failures to set scheduler parameters on
>> migrate, on the grounds that this will be less risk to the project as a
>> whole than reverting credit2 again. But either way we should do
>> something quickly.
>
> We should ignore a mismatch of the scheduler. Failures when setting
> parameters for a matching scheduler should not be ignored IMO.
Well, depends on whether the scheduler was explicitly chosen.
I don't think migration should succeed when e.g. RTDS was used
and isn't available on the destination host.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [xen-unstable test] 128240: regressions - FAIL
[not found] ` <5BB32C7802000078001ED8FA@suse.com>
@ 2018-10-02 9:24 ` Dario Faggioli
2018-10-02 9:36 ` Jan Beulich
[not found] ` <5BB33C3202000078001ED99C@suse.com>
0 siblings, 2 replies; 19+ messages in thread
From: Dario Faggioli @ 2018-10-02 9:24 UTC (permalink / raw)
To: Jan Beulich, Juergen Gross, George Dunlap, Wei Liu
Cc: George Dunlap, Andrew Cooper, Ian Jackson, osstest service owner,
xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 1169 bytes --]
On Tue, 2018-10-02 at 09:29 +0100, Jan Beulich wrote:
> > > > On 01.10.18 at 18:07, <jgross@suse.com> wrote:
> >
> > We should ignore a mismatch of the scheduler. Failures when setting
> > parameters for a matching scheduler should not be ignored IMO.
>
> Well, depends on whether the scheduler was explicitly chosen.
> I don't think migration should succeed when e.g. RTDS was used
> and isn't available on the destination host.
>
I'm not sure I'm understanding.
You're saying, that, e.g., the migration of a VM between, for instance:
- a Xen 4.11 host, booted without any sched=, and hence running Credit,
and another Xen 4.11 host, booted with sched=credit2,
should fail _while_ :
- a migration between a Xen 4.11 host, booted without any sched=, and
hence using Credit, and a Xen 4.12 host, booted without any sched=,
and hence using Credit2 (if we switch),
should succeed ?
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [xen-unstable test] 128240: regressions - FAIL
2018-10-02 9:24 ` Dario Faggioli
@ 2018-10-02 9:36 ` Jan Beulich
[not found] ` <5BB33C3202000078001ED99C@suse.com>
1 sibling, 0 replies; 19+ messages in thread
From: Jan Beulich @ 2018-10-02 9:36 UTC (permalink / raw)
To: Dario Faggioli
Cc: Juergen Gross, Wei Liu, George Dunlap, Andrew Cooper,
Ian Jackson, george.dunlap, osstest service owner, xen-devel
>>> On 02.10.18 at 11:24, <dfaggioli@suse.com> wrote:
> On Tue, 2018-10-02 at 09:29 +0100, Jan Beulich wrote:
>> > > > On 01.10.18 at 18:07, <jgross@suse.com> wrote:
>> >
>> > We should ignore a mismatch of the scheduler. Failures when setting
>> > parameters for a matching scheduler should not be ignored IMO.
>>
>> Well, depends on whether the scheduler was explicitly chosen.
>> I don't think migration should succeed when e.g. RTDS was used
>> and isn't available on the destination host.
>>
> I'm not sure I'm understanding.
>
> You're saying, that, e.g., the migration of a VM between, for instance:
>
> - a Xen 4.11 host, booted without any sched=, and hence running Credit,
> and another Xen 4.11 host, booted with sched=credit2,
>
> should fail _while_ :
>
> - a migration between a Xen 4.11 host, booted without any sched=, and
> hence using Credit, and a Xen 4.12 host, booted without any sched=,
> and hence using Credit2 (if we switch),
>
> should succeed ?
No. See Jürgen's response. The default scheduler (irrespective of
whether it was chosen via command line option) should not matter.
Any means to force a non-default scheduler (and it indeed looks
like CPU pools are the only way) should imo retain that specific
scheduler. But I agree that this is not the only possible / sensible
view at things.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [xen-unstable test] 128240: regressions - FAIL
[not found] ` <5BB33C3202000078001ED99C@suse.com>
@ 2018-10-02 9:58 ` Dario Faggioli
0 siblings, 0 replies; 19+ messages in thread
From: Dario Faggioli @ 2018-10-02 9:58 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, Wei Liu, George Dunlap, Andrew Cooper,
Ian Jackson, George Dunlap, osstest service owner, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 1266 bytes --]
On Tue, 2018-10-02 at 10:36 +0100, Jan Beulich wrote:
> > > > On 02.10.18 at 11:24, <dfaggioli@suse.com> wrote:
> >
> No. See Jürgen's response. The default scheduler (irrespective of
> whether it was chosen via command line option) should not matter.
> Any means to force a non-default scheduler (and it indeed looks
> like CPU pools are the only way) should imo retain that specific
> scheduler.
>
Right, but the scheduler is a Xen/host (or cpupool) property, not a VM
one. Do we handle like that the other similar ones? Like, do we fail
migration if one host use the default setting wrt autoballooning and
the other doesn't? Or wrt XPTI and the other mitigations?
I mean, I think I see your point, and I'm still making up my mind about
this, but I'm starting to think that this is the user responsibility to
know what he's doing, and all we should do is, in this case, if we
notice the mismatch between the schedulers, to print a warning and
avoid setting the scheduler params...
Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [xen-unstable test] 128240: regressions - FAIL
2018-10-01 17:58 ` Dario Faggioli
@ 2018-10-02 10:06 ` George Dunlap
2018-10-02 10:36 ` Dario Faggioli
0 siblings, 1 reply; 19+ messages in thread
From: George Dunlap @ 2018-10-02 10:06 UTC (permalink / raw)
To: Dario Faggioli, Juergen Gross, Andrew Cooper, Wei Liu
Cc: George Dunlap, xen-devel, Ian Jackson, osstest service owner,
Jan Beulich
On 10/01/2018 06:58 PM, Dario Faggioli wrote:
> On Mon, 2018-10-01 at 18:07 +0200, Juergen Gross wrote:
>> On 01/10/2018 17:48, George Dunlap wrote:
>>> On 10/01/2018 04:40 PM, Andrew Cooper wrote:
>>>> On 01/10/18 16:35, Wei Liu wrote:
>>>>>> Wait, the migration code reads the scheduler parameters --
>>>>>> even if these
>>>>>> have not been explicitly set by the admin -- and sends them
>>>>>> along with
>>>>>> the migration stream? And if the remote scheduler is
>>>>>> different, the
>>>>>> migration fails?
>>>>>>
>>>>>> That's not so good. :-)
>>>>>
>>>>> But one can argue that the guest is specific configured that
>>>>> way so it's
>>>>> parameters should be preserved. We normally analyse things on a
>>>>> case by
>>>>> case basis.
>>>>
>>>> If there isn't an obvious fix, then the switch of default
>>>> scheduler
>>>> needs reverting until there is a fix present. This is currently
>>>> blocking master.
>>>
>>> Agreed. I'd argue for ignoring failures to set scheduler
>>> parameters on
>>> migrate, on the grounds that this will be less risk to the project
>>> as a
>>> whole than reverting credit2 again. But either way we should do
>>> something quickly.
>>
>> We should ignore a mismatch of the scheduler. Failures when setting
>> parameters for a matching scheduler should not be ignored IMO.
>>
> Indeed! Especially considering that this isn't really related on what
> the default scheduler is (despite it being making Credit2 default that
> triggers the issue).
>
> In fact, what if:
> - user uses Credit1 (default and supported) on host A
> - user uses Credit2 (supported) on host B
> - user migrates VM
> - BOOOM!
>
> So, unless it is intended --and, I'd say, also documented somewhere--
> that migrating between hosts which use different schedulers is to be
> avoided, this is already a bug, whatever the default scheduler is...
>
> George, let me know if you're working on a fix already, or if I should
> do that myself.
I reverted the credit2 default; but really we need to have a design
discussion about what we want the overall behavior to be. It's not
simple or obvious.
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [xen-unstable test] 128240: regressions - FAIL
2018-10-02 10:06 ` George Dunlap
@ 2018-10-02 10:36 ` Dario Faggioli
0 siblings, 0 replies; 19+ messages in thread
From: Dario Faggioli @ 2018-10-02 10:36 UTC (permalink / raw)
To: George Dunlap, Juergen Gross, Andrew Cooper, Wei Liu
Cc: George Dunlap, xen-devel, Ian Jackson, osstest service owner,
Jan Beulich
[-- Attachment #1.1: Type: text/plain, Size: 1760 bytes --]
On Tue, 2018-10-02 at 11:06 +0100, George Dunlap wrote:
> On 10/01/2018 06:58 PM, Dario Faggioli wrote:
> >
> > George, let me know if you're working on a fix already, or if I
> > should
> > do that myself.
>
> I reverted the credit2 default; but really we need to have a design
> discussion about what we want the overall behavior to be. It's not
> simple or obvious.
>
Ok. As saying to Jan, I'm starting to think that there is very few that
we can do, without risking of actively stomping on our own users' feet.
I mean, if someone wants to migrate a VM between a Credit and a Credit2
box, or between a Credit2 and RTDS box, who are we to forbid him/her to
do it?
So, basically, I'd make sure that the mismatch is being noticed, but
nothing more than that (i.e., I'd print a warning, and ignore the
parameters). Of course, if the two hosts do have the same scheduler, I
think it does makes sense to re-apply the parameters them VM had on
the source host (principle of least surprise, etc).
I appreciate that there is the risk that one may have chosen RTDS, then
forgot, and not set sched=rtds on destination, and get an apparently
weird result... But I'd argue that if you are changing scheduler,
you're doing it for a reason, and it's unlikely you don't pay attention
to that when playing with migration.
Anyway, I'm not working this afternoon. So ping me on IRC tomorrow, if
you want to discuss this there. Or we can just go on via email, of
course. :-)
Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [xen-unstable test] 128240: regressions - FAIL
@ 2018-10-02 8:45 Juergen Gross
0 siblings, 0 replies; 19+ messages in thread
From: Juergen Gross @ 2018-10-02 8:45 UTC (permalink / raw)
To: Jan Beulich, George Dunlap, Wei Liu
Cc: George Dunlap, Andrew Cooper, Ian Jackson, osstest service owner,
Dario Faggioli, xen-devel
On 02/10/2018 10:29, Jan Beulich wrote:
>>>> On 01.10.18 at 18:07, <jgross@suse.com> wrote:
>> On 01/10/2018 17:48, George Dunlap wrote:
>>> On 10/01/2018 04:40 PM, Andrew Cooper wrote:
>>>> If there isn't an obvious fix, then the switch of default scheduler
>>>> needs reverting until there is a fix present. This is currently
>>>> blocking master.
>>>
>>> Agreed. I'd argue for ignoring failures to set scheduler parameters on
>>> migrate, on the grounds that this will be less risk to the project as a
>>> whole than reverting credit2 again. But either way we should do
>>> something quickly.
>>
>> We should ignore a mismatch of the scheduler. Failures when setting
>> parameters for a matching scheduler should not be ignored IMO.
>
> Well, depends on whether the scheduler was explicitly chosen.
> I don't think migration should succeed when e.g. RTDS was used
> and isn't available on the destination host.
The only way I could think of to tell an explicit vs. an implicit
scheduler selection would be to specify a cpupool in the domain's
config file.
So what about the following:
A mismatch of the scheduler should be ignored on the receiving side
if no cpupool was specified explicitly for the domain.
I have checked that config.c_info.pool_name in JSON data is available
only if the cpupool is specified in the domain config.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2018-10-02 10:36 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-30 21:59 [xen-unstable test] 128240: regressions - FAIL osstest service owner
2018-10-01 9:04 ` Jan Beulich
2018-10-01 14:33 ` Wei Liu
2018-10-01 15:10 ` Jan Beulich
2018-10-01 15:17 ` Wei Liu
2018-10-01 15:19 ` George Dunlap
2018-10-01 15:35 ` Wei Liu
[not found] ` <fc2bbc89cfc7d9066fe0b1fd76ddd2ff@citrix.com>
[not found] ` <26110706a1830c111efd93ec76accd40@citrix.com>
[not found] ` <fc2bbc89cfc7d9066fe0b1fd76ddd2ff@citrix.com>
2018-10-01 15:40 ` Andrew Cooper
2018-10-01 15:48 ` George Dunlap
2018-10-01 16:07 ` Juergen Gross
2018-10-01 17:58 ` Dario Faggioli
2018-10-02 10:06 ` George Dunlap
2018-10-02 10:36 ` Dario Faggioli
2018-10-02 8:29 ` Jan Beulich
[not found] ` <5BB32C7802000078001ED8FA@suse.com>
2018-10-02 9:24 ` Dario Faggioli
2018-10-02 9:36 ` Jan Beulich
[not found] ` <5BB33C3202000078001ED99C@suse.com>
2018-10-02 9:58 ` Dario Faggioli
2018-10-01 18:02 ` Dario Faggioli
-- strict thread matches above, loose matches on Subject: below --
2018-10-02 8:45 Juergen Gross
[not found] <osstest128240mainreport@xen.org>
[not found] <osstest128240mainreport@xen.org>
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.