[xen-unstable test] 128240: regressions - FAIL

[xen-unstable test] 128240: regressions - FAIL

[osstest service owner]

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

Re: [xen-unstable test] 128240: regressions - FAIL

[Jan Beulich]

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

Re: [xen-unstable test] 128240: regressions - FAIL

[Wei Liu]

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

Re: [xen-unstable test] 128240: regressions - FAIL

[Jan Beulich]

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

Re: [xen-unstable test] 128240: regressions - FAIL

[Wei Liu]

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

Re: [xen-unstable test] 128240: regressions - FAIL

[George Dunlap]

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

Re: [xen-unstable test] 128240: regressions - FAIL

[Wei Liu]

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

Re: [xen-unstable test] 128240: regressions - FAIL

[Andrew Cooper]

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

Re: [xen-unstable test] 128240: regressions - FAIL

[George Dunlap]

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

Re: [xen-unstable test] 128240: regressions - FAIL

[Juergen Gross]

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

Re: [xen-unstable test] 128240: regressions - FAIL

[Dario Faggioli]

[-- 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

Re: [xen-unstable test] 128240: regressions - FAIL

[George Dunlap]

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

Re: [xen-unstable test] 128240: regressions - FAIL

[Dario Faggioli]

[-- 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

Re: [xen-unstable test] 128240: regressions - FAIL

[Jan Beulich]

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

Re: [xen-unstable test] 128240: regressions - FAIL

[Dario Faggioli]

[-- 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

Re: [xen-unstable test] 128240: regressions - FAIL

[Jan Beulich]

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

Re: [xen-unstable test] 128240: regressions - FAIL

[Dario Faggioli]

[-- 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

Re: [xen-unstable test] 128240: regressions - FAIL

[Dario Faggioli]

[-- 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

Re: [xen-unstable test] 128240: regressions - FAIL

[Juergen Gross]

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