Dom0: Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version 3.2.15-1, package blktap-dkms and all dependency packages for xen, spice and usb redirection. ------------------------- /etc/modules ------------ loop max_loop=64 xenfs xen-evtchn blktap ------------------------- hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset is 25249:a4e7fce6ee2b) vi Makefile # removed dist-kernel to not compile kernel ------------------------- Added some patches: - autoconf: add variable for pass arbitrary options to qemu upstream v3 - tools: Improve make deb ------------------------- ./configure --enable-qemuu-spice --enable-qemuu-usbredir --enable-qemuu-debug ------------------------- make deb ------------------------- Recent regression: ------------- - CRITICAL - PV domU unable to start, freeze on config parsing, with this output and nothing else: xl create /etc/xen/lucid.cfg Parsing config file /etc/xen/lucid.cfg ------------- - On hvm domU start, domU work also this output on xl create: libxl: error: libxl.c:3115:libxl_sched_credit_domain_set: Cpu weight out of range, valid values are within range from 1 to 65535 ------------------------- If you need further details tell me and I will post back -- View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5667212.html Sent from the Xen - Dev mailing list archive at Nabble.com.
On Thu, 2012-04-26 at 11:26 +0100, Fantu wrote:> Dom0: > Wheezy 64 bit with kernel from package linux-image-3.2.0-2-amd64 version > 3.2.15-1, package blktap-dkms and all dependency packages for xen, spice and > usb redirection. > ------------------------- > /etc/modules > ------------ > loop max_loop=64 > xenfs > xen-evtchn > blktap > ------------------------- > hg clone http://xenbits.xen.org/xen-unstable.hg (in this build changeset is > 25249:a4e7fce6ee2b) > vi Makefile # removed dist-kernel to not compile kernelxen-unstable.hg hasn''t (or shouldn''t have been) building a kernel for a long time -- are you really seeing it do so?> ------------------------- > Added some patches: > - autoconf: add variable for pass arbitrary options to qemu upstream v3 > - tools: Improve make deb > ------------------------- > ./configure --enable-qemuu-spice --enable-qemuu-usbredir > --enable-qemuu-debug > ------------------------- > make deb > > ------------------------- > Recent regression: > ------------- > - CRITICAL - PV domU unable to start, freeze on config parsing, with this > output and nothing else: > xl create /etc/xen/lucid.cfg > Parsing config file /etc/xen/lucid.cfgCan you run with "xl -vvv create"? What is in lucid.cfg?> ------------- > - On hvm domU start, domU work also this output on xl create: > libxl: error: libxl.c:3115:libxl_sched_credit_domain_set: Cpu weight out of > range, valid values are within range from 1 to 65535This is no doubt an issue with 25244:e428eae1838c (CCing author). I suspect the problem is that you are not setting any scheduler options but it is unconditionally setting them. I think what it really should be doing, is reading the current settings, updating those which the user has specified and writing them back. I''m not sure how best to achieve that in the libxl api though (CCing some scheduler folks)> ------------------------- > > If you need further details tell me and I will post back > > > -- > View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5667212.html > Sent from the Xen - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
Ian Campbell-10 wrote> > Can you run with "xl -vvv create"? > What is in lucid.cfg? >Ubuntu 10.04 LTS, working on previous xen-unstable test, here the xl configuration file used: ------------------------------- lucid.cfg --------- name="lucid" vcpus=2 memory=512 disk=[''/mnt/vm/disks/lucid.disk1.xm,raw,xvda1,rw'', ''/mnt/vm/disks/lucid.disk2.xm,raw,xvda2,rw''] vif=[''bridge=xenbr0''] vfb=[''vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it''] bootloader = ''/usr/bin/pygrub'' ------------------------------- xl -vvv create /etc/xen/lucid.cfg Parsing config file /etc/xen/lucid.cfg libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda1 spec.backend=unknown libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk vdev=xvda1, using backend tap libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda2 spec.backend=unknown libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk vdev=xvda2, using backend tap libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk vdev=xvda1 spec.backend=tap libxl: debug: libxl.c:1689:libxl_device_disk_local_attach: locally attaching tap disk /mnt/vm/disks/lucid.disk1.xm directly (ie without using blktap) # And after freeze -- View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5667398.html Sent from the Xen - Dev mailing list archive at Nabble.com.
On Thu, 2012-04-26 at 13:06 +0100, Fantu wrote:> Ian Campbell-10 wrote > > > > Can you run with "xl -vvv create"? > > What is in lucid.cfg? > > > > Ubuntu 10.04 LTS, working on previous xen-unstable test, here the xl > configuration file used: > ------------------------------- > lucid.cfg > --------- > name="lucid" > vcpus=2 > memory=512 > disk=[''/mnt/vm/disks/lucid.disk1.xm,raw,xvda1,rw'', > ''/mnt/vm/disks/lucid.disk2.xm,raw,xvda2,rw''] > vif=[''bridge=xenbr0''] > vfb=[''vnc=1,vncunused=1,vnclisten=0.0.0.0,keymap=it''] > bootloader = ''/usr/bin/pygrub'' > ------------------------------- > > xl -vvv create /etc/xen/lucid.cfg > Parsing config file /etc/xen/lucid.cfg > libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk > vdev=xvda1 spec.backend=unknown > libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda1, backend > phy unsuitable as phys path not a block device > libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk > vdev=xvda1, using backend tap > libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk > vdev=xvda2 spec.backend=unknown > libxl: debug: libxl_device.c:137:disk_try_backend: Disk vdev=xvda2, backend > phy unsuitable as phys path not a block device > libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk > vdev=xvda2, using backend tap > libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk > vdev=xvda1 spec.backend=tap > libxl: debug: libxl.c:1689:libxl_device_disk_local_attach: locally attaching > tap disk /mnt/vm/disks/lucid.disk1.xm directly (ie without using blktap) > # And after freezeI coincidentally just saw something like this and it turned out to be because I needed to set "PYTHON_PREFIX_ARG = --install-layout=deb" in Config.mk. What happens if you run "pygrub /mnt/vm/disks/lucid.disk1.xm"? Ian.
pygrub /mnt/vm/disks/lucid.disk1.xm
Traceback (most recent call last):
File "/usr/bin/pygrub", line 20, in <module>
import xen.lowlevel.xc
ImportError: No module named xen.lowlevel.xc
--
View this message in context:
http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5667689.html
Sent from the Xen - Dev mailing list archive at Nabble.com.
On Thu, 2012-04-26 at 14:57 +0100, Fantu wrote:> pygrub /mnt/vm/disks/lucid.disk1.xm > Traceback (most recent call last): > File "/usr/bin/pygrub", line 20, in <module> > import xen.lowlevel.xc > ImportError: No module named xen.lowlevel.xcThis is the same symptoms as the PYTHON_PREFIX_ARG issue I described. Ian.
Hi, On Thu, Apr 26, Ian Campbell wrote:> This is no doubt an issue with 25244:e428eae1838c (CCing author). I > suspect the problem is that you are not setting any scheduler options > but it is unconditionally setting them. I think what it really should be > doing, is reading the current settings, updating those which the user > has specified and writing them back. I''m not sure how best to achieve > that in the libxl api though (CCing some scheduler folks)yes, this is an issue with my patch :( All default values has to be 0, but only for the credit(2) scheduler cpu_weight must not. So I made a patch, which set a default of 256 when the cpu_weight isn''t set and credit(2) is used and let it 0 when the scheduler sedf is used. Please try the attached patch and see if it solve this issue. -- Best regards Dieter Bloms -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won''t use my address in the From field. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 27/04/12 09:21, Dieter Bloms wrote:> yes, this is an issue with my patch :( All default values has to be 0, > but only for the credit(2) scheduler cpu_weight must not. So I made a > patch, which set a default of 256 when the cpu_weight isn''t set and > credit(2) is used and let it 0 when the scheduler sedf is used. Please > try the attached patch and see if it solve this issue.Dieter, Thanks for the patch. However, I''d really rather avoid putting scheduler defaults in xl if we can at all avoid it. Defaults should be set in one place, and that should be in the scheduling code itself. I think what we really want to do is is any of the parameters are set, after the domain is first created, to read the scheduling parameters for the domain (which will be the defaults), change the ones that are set in the config file, and then write the whole structure back. That shouldn''t be too hard, as libxl__sched_set_params() is called after the domain itself is created; the main thing is how to tell libxl__sched_set_params() which parameters actually need to be set, and which should be left alone. Are you up for doing that? If not, I can put it on my to-do list. Thanks, -George
On Fri, 2012-04-27 at 09:44 +0100, George Dunlap wrote:> On 27/04/12 09:21, Dieter Bloms wrote: > > yes, this is an issue with my patch :( All default values has to be 0, > > but only for the credit(2) scheduler cpu_weight must not. So I made a > > patch, which set a default of 256 when the cpu_weight isn''t set and > > credit(2) is used and let it 0 when the scheduler sedf is used. Please > > try the attached patch and see if it solve this issue. > Dieter, > > Thanks for the patch. However, I''d really rather avoid putting > scheduler defaults in xl if we can at all avoid it. Defaults should be > set in one place, and that should be in the scheduling code itself. > > I think what we really want to do is is any of the parameters are set, > after the domain is first created, to read the scheduling parameters for > the domain (which will be the defaults), change the ones that are set in > the config file, and then write the whole structure back. That > shouldn''t be too hard, as libxl__sched_set_params() is called after the > domain itself is created;I guess the low level libxl_sched_*_params_set should take care of this?> the main thing is how to tell > libxl__sched_set_params() which parameters actually need to be set, and > which should be left alone.Do all of the fields have a spare discriminating value which could mean "the default". Ideally it would be zero but it doesn''t have to be. Otherwise we can adjust the libxl API to make one available (usually ~0 or similar), the IDL can express these sorts of concepts (see the uses of init_val). It may be appropriate to add a libxl__sched_FOO_domain__setdefaults, which params_set could call to fully initialise the struct (by calling get...)> Are you up for doing that? If not, I can put it on my to-do list. > > Thanks, > -George >
About second issue apllying patch seem solved.
About first also with this change:
vi Config.mk
PYTHON_PREFIX_ARG = --install-layout=deb
not work, show different error:
Parsing config file /etc/xen/lucid.cfg
libxl: error: libxl_create.c:603:do_domain_create: failed to run bootloader:
-3
pygrub /mnt/vm/disks/lucid.disk1.xm
Traceback (most recent call last):
File "/usr/bin/pygrub", line 822, in <module>
raise RuntimeError, "Unable to find partition containing kernel"
RuntimeError: Unable to find partition containing kernel
--
View this message in context:
http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5670111.html
Sent from the Xen - Dev mailing list archive at Nabble.com.
On Fri, 2012-04-27 at 13:15 +0100, Fantu wrote:> About second issue apllying patch seem solved. > About first also with this change: > > vi Config.mk > PYTHON_PREFIX_ARG = --install-layout=deb > > not work, show different error: > Parsing config file /etc/xen/lucid.cfg > libxl: error: libxl_create.c:603:do_domain_create: failed to run bootloader: > -3 > > pygrub /mnt/vm/disks/lucid.disk1.xm > Traceback (most recent call last): > File "/usr/bin/pygrub", line 822, in <module> > raise RuntimeError, "Unable to find partition containing kernel" > RuntimeError: Unable to find partition containing kernelHave you done a full clean rebuild since 25194:6b72eb3b40cf? IIRC that would cause these sorts of failures. There is no partition table in lucid.disk1.xm, right? I don''t use the split partition scheme myself so I don''t know what state it is in. What sort of filesystem is on lucid.disk1.xm? Looking at the history of pygrub I don''t see anything of interest which might potentially have broken it (other than the above libfsimage issue), changes have been rather few lately. Do you know when it last worked? If so then doing a bisect (just running pygrub, not booting guests) might be helpful. Ian.> > > -- > View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5670111.html > Sent from the Xen - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
Ian Campbell-10 wrote> > On Fri, 2012-04-27 at 13:15 +0100, Fantu wrote: >> About second issue apllying patch seem solved. >> About first also with this change: >> >> vi Config.mk >> PYTHON_PREFIX_ARG = --install-layout=deb >> >> not work, show different error: >> Parsing config file /etc/xen/lucid.cfg >> libxl: error: libxl_create.c:603:do_domain_create: failed to run >> bootloader: >> -3 >> >> pygrub /mnt/vm/disks/lucid.disk1.xm >> Traceback (most recent call last): >> File "/usr/bin/pygrub", line 822, in <module> >> raise RuntimeError, "Unable to find partition containing kernel" >> RuntimeError: Unable to find partition containing kernel > > Have you done a full clean rebuild since 25194:6b72eb3b40cf? IIRC that > would cause these sorts of failures. > > There is no partition table in lucid.disk1.xm, right? I don''t use the > split partition scheme myself so I don''t know what state it is in. > > What sort of filesystem is on lucid.disk1.xm? > > Looking at the history of pygrub I don''t see anything of interest which > might potentially have broken it (other than the above libfsimage > issue), changes have been rather few lately. Do you know when it last > worked? If so then doing a bisect (just running pygrub, not booting > guests) might be helpful. > > Ian. > >> >> >> -- >> View this message in context: >> http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5670111.html >> Sent from the Xen - Dev mailing list archive at Nabble.com. >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@.xen >> http://lists.xen.org/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@.xen > http://lists.xen.org/xen-devel >Lucid disk1 is ext4 partition, on old xen-unstable test build was working, also without change of python prefix, monday I retry with full clean build and also to latest changeset -- View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5670447.html Sent from the Xen - Dev mailing list archive at Nabble.com.
On Fri, 2012-04-27 at 15:27 +0100, Fantu wrote:> Lucid disk1 is ext4 partition, on old xen-unstable test build was working,Do you know what changeset that was?> also without change of python prefix, monday I retry with full clean build > and also to latest changeset
On Fri, 2012-04-27 at 16:20 +0100, Dario Faggioli wrote:> On Fri, 2012-04-27 at 10:08 +0100, Ian Campbell wrote: > > > I think what we really want to do is is any of the parameters are set, > > > after the domain is first created, to read the scheduling parameters for > > > the domain (which will be the defaults), change the ones that are set in > > > the config file, and then write the whole structure back. That > > > shouldn''t be too hard, as libxl__sched_set_params() is called after the > > > domain itself is created; > > > > I guess the low level libxl_sched_*_params_set should take care of this? > > > Possibly, but there''s more I''m not sure I understand in the patch (the > original patch, the one that has been checked-in on Wednesday): > > +int libxl__sched_set_params(libxl__gc *gc, uint32_t domid, libxl_sched_params *scparams) > +{ > + libxl_ctx *ctx = libxl__gc_owner(gc); > + libxl_scheduler sched; > + libxl_sched_sedf_domain sedf_info; > + libxl_sched_credit_domain credit_info; > + libxl_sched_credit2_domain credit2_info; > + int ret; > + > + sched = libxl_get_scheduler (ctx); > + switch (sched) { > + case LIBXL_SCHEDULER_SEDF: > + sedf_info.period = scparams->period; > + sedf_info.slice = scparams->slice; > + sedf_info.latency = scparams->latency; > + sedf_info.extratime = scparams->extratime; > + sedf_info.weight = scparams->weight; > + ret=libxl_sched_sedf_domain_set(ctx, domid, &sedf_info); > + break; > + case LIBXL_SCHEDULER_CREDIT: > + credit_info.weight = scparams->weight; > <snip> > > sched gets the return value of libxl_get_scheduler() which, if I''m not > wrong , read the "default" xen scheduler for this boot, i.e., the one > specified by the "sched=" boot command line or whatever the default for > that is (credit1). > > After that it decides what libxl_sched_*_domain_set() to call basing > right on that value. What I''m missing is what prevents the domain in > question to be part of a cpupool (e.g., by specifying "poolid=" in its > config file as well) for which the scheduler is a different one. > > It seems to me that, in such case, we will be setting the wrong set of > parameters anyway, independently on how well we manage in putting a > default in place for them... Am I missing something? If not, as I > haven''t found any way of finding out what scheduler is actually being > used for a specific domain, shouldn''t we add or mimic that (going > through cpupool, perhaps, I haven''t checked yet)?I think you are right. Should we have libxl_gfet_domain_scheduler (or some such) which implements the appropriate logic? Ian.
On Fri, 2012-04-27 at 16:35 +0100, Dario Faggioli wrote:> On Fri, 2012-04-27 at 16:28 +0100, Ian Campbell wrote: > > > It seems to me that, in such case, we will be setting the wrong set of > > > parameters anyway, independently on how well we manage in putting a > > > default in place for them... Am I missing something? If not, as I > > > haven''t found any way of finding out what scheduler is actually being > > > used for a specific domain, shouldn''t we add or mimic that (going > > > through cpupool, perhaps, I haven''t checked yet)? > > > > I think you are right. Should we have libxl_gfet_domain_scheduler (or > > some such) which implements the appropriate logic? > > > If we want to keep the patch (and I''m sure we want, as having the > possibility to set scheduling parameters in the config file kills a > regression against xm, and it''s a very nice feature after all :-D) I > think we should. > > I can look into that if you want. I''m also trying to figure out if a > default value for the various parameters of the various scheduler can be > "elected". It doesn''t look like an easy thing to do, e.g., consider sedf > wants time values for "period" and "slice", so virtually any unsigned > value is meaningful, although, yes, period=0 or slice=0 barely make > sense, and thus maybe we can use these...There''s always ~(TYPE)0 for whatever the type is... Ian.
Ian Campbell-10 wrote> > On Fri, 2012-04-27 at 15:27 +0100, Fantu wrote: >> Lucid disk1 is ext4 partition, on old xen-unstable test build was >> working, > > Do you know what changeset that was? > >> also without change of python prefix, monday I retry with full clean >> build >> and also to latest changeset > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@.xen > http://lists.xen.org/xen-devel >I retried with full clean build, changeset 25256:9dda0efd8ce1 but got same error. Last working changeset was 25070, after that I do mainly qemu upstream test. -- View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5675394.html Sent from the Xen - Dev mailing list archive at Nabble.com.
Fantu wrote> > > Ian Campbell-10 wrote >> >> On Fri, 2012-04-27 at 15:27 +0100, Fantu wrote: >>> Lucid disk1 is ext4 partition, on old xen-unstable test build was >>> working, >> >> Do you know what changeset that was? >> >>> also without change of python prefix, monday I retry with full clean >>> build >>> and also to latest changeset >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@.xen >> http://lists.xen.org/xen-devel >> > I retried with full clean build, changeset 25256:9dda0efd8ce1 but got same > error. > Last working changeset was 25070, after that I do mainly qemu upstream > test. >I tried also pv-grub but it doesn''t working. xl create /etc/xen/lucid.cfg Parsing config file /etc/xen/lucid.cfg xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel: kernel is not a bzImage: Invalid kernel Daemon running with PID 2683 -- View this message in context: http://xen.1045712.n5.nabble.com/Test-result-of-xen-unstable-changeset-25249-tp5667212p5675450.html Sent from the Xen - Dev mailing list archive at Nabble.com.