Description of problem: The command "virsh schedinfo <domain>..." can not deal with the boundary "cap" value correctly. Version-Release number of selected component (if applicable): - libvirt: 0.6.3-6.el5 How reproducible: 100%, always. Steps to Reproduce: 1, virsh define rhel5u3.xml 2, virsh start rhel5u3 3, virsh schedinfo rhel5u3 --cap 65534 ---> succeed as below: Scheduler : credit weight : 1 cap : 65534 4, virsh schedinfo rhel5u3 --cap 65535 ---> fail as below (still 65534): Scheduler : credit weight : 1 cap : 65534 5, virsh schedinfo rhel5u3 --cap 65536 ---> succeed since reaching the boundary value error: this function is not supported by the hypervisor: unsupported in xendConfigVersion Actual results: In step 4, when setting the cap to 65535, no error information (just like step 5 above) printed out, but the value "cap" is not changed. Expected results: It seems that the boundary value is 65536 from step 5, so step 4 should change the "cap" value successfully. Additional info: No.
Seems like a bug in the Xen hypervisor or 65535 is assumed to be a no-op in the system call: when tracing in xenHypervisorSetSchedulerParameters() 1271 switch (op_sys.u.getschedulerid.sched_id){ (gdb) 1277 int weight_set = 0; (gdb) 1278 int cap_set = 0; (gdb) 1280 memset(&op_dom, 0, sizeof(op_dom)); (gdb) 1281 op_dom.cmd = XEN_V2_OP_SCHEDULER; (gdb) 1282 op_dom.domain = (domid_t) domain->id; (gdb) 1283 op_dom.u.getschedinfo.sched_id = XEN_SCHEDULER_CREDIT; (gdb) 1284 op_dom.u.getschedinfo.cmd = XEN_DOMCTL_SCHEDOP_putinfo; (gdb) 1290 op_dom.u.getschedinfo.u.credit.weight = 0; (gdb) 1291 op_dom.u.getschedinfo.u.credit.cap = (uint16_t)~0U; (gdb) 1293 for (i = 0; i < nparams; i++) { (gdb) 1294 memset(&buf, 0, sizeof(buf)); (gdb) 1295 if (STREQ (params[i].field, str_weight) && (gdb) p params[0] $4 = {field = "cap\000:\000\000\0008*un:", '\0' <repeats 66 times>, type = 2, value = {i = 65535, ui = 65535, l = 65535, ul = 65535, d = 3.2378592100206092e-319, b = -1 '�'}} (gdb) n 1305 } else if (STREQ (params[i].field, str_cap) && (gdb) 1307 val = params[i].value.ui; (gdb) p params[i].value.ui $6 = 65535 (gdb) n 1308 if (val > USHRT_MAX) { (gdb) p val $7 = 65535 Somehow the stest sounds right as /usr/include/limits.h:# define USHRT_MAX 65535 (gdb) 1293 for (i = 0; i < nparams; i++) { (gdb) 1323 ret = xenHypervisorDoV2Dom(priv->handle, &op_dom); (gdb) p op_dom.u.getschedinfo.u.credit $9 = {weight = 0, cap = 65535} (gdb) n 1324 if (ret < 0) (gdb) p ret $10 = 0 (gdb) n 1335 return 0; (gdb) 1336 } (gdb) xenUnifiedDomainSetSchedulerParameters (dom=0x122526c0, params=0x12255770, nparams=1) at xen_unified.c:1280 1280 if (ret == 0) (gdb) c Continuing. Scheduler : credit weight : 256 cap : 65533 So the hypervisor doesn't raise this as an out of bound error but the value is just ignored. I guess the best is to cope locally with that value I think by just allowing 0-65534 instead of 0-65535 IMHO this is not a big deal, the fact that the correct erro message ain't displayed for out of bound values is more annoying, it's overriden by the xend driver. The best is to reverse the order of the drivers for the scheduler setting call, as this isn't performance critical Daniel
Created attachment 369899 [details] patch for the problems
The patch was also sent upstream https://www.redhat.com/archives/libvir-list/2009-November/msg00603.html Daniel
libvirt-0.6.3-22.el5 has been built in dist-5E-qu-candidate with the fixes, Daniel
For the xen and kvm hypervisor,this operation will raise different result: 1.XEN hypervisor cap can reach boundary value 65534 on xenpv and xenfv guest,but it exists extra three problems: a). when cap is an out of bound value such as cap=65535,duplicate error will be raised,and one is from xen,another is from libvirt,I think that xen's error should be catch by libvirt.then only raise a libvirt error. b). sometimes weight can't reach boundary value 65535 this will raise a error "libvir: Xen error : failed Xen syscall ioctl 3166208" I will file a new bug. c). a annoying error message is often raised, although change cap value successfully: "libvir: Xen Daemon error : this function is not supported by the hypervisor: unsupported in xendConfigVersion < 4" 2.KVM hypervisor this function is not supported by the kvm hypervisor.this will raise a error "libvir: error : this function is not supported by the hypervisor: virDomainGetSchedulerType", I am not sure whether the error message is a correct behavior. in addition: a warning message is often raised on xen host(kvm not yet), if you import libvirt module or do some 'virsh' operation,may be I still need to file a new bug or the message is a correct behavior(my machine isn't a numa system): "libnuma: Warning: /sys not mounted or no numa system. Assuming one node: No such file or directory" Steps to Reproduce & component information: see attachment.
Created attachment 380727 [details] detail information detail information
The credit scheduler is available only ion Xen, so this is to be tested only in Xen. The addition is not related to this bug, that's a warning only, it's separate and I don't think it need "fixing" for 5.5 honnestly. for points a) and c) while not ideal, I don't think it is worth spending more time on this corner case this is specific to RHEL-5 Xen version For b) that mean the hypercall failed, that should be completely reproductible on a given machine, either the hypercall is supported or not, if it's variable on a given it's a Xen bug. Daniel
The warning is a bug in numactl: https://bugzilla.redhat.com/show_bug.cgi?id=545170 Daniel
Hi,Daniel,you are right.some problems isn't related to this bug,the bug focus on cap whether can reach boundary value correctly.I retest it with libvirt-0.6.3-28.el5 on RHEL-5.5,This bug has been fixed,set bug status to VERIFIED. Steps to Reproduce: [root@dhcp-66-70-62 ~]# virsh schedinfo rhel5u5_x86_64_xenpv --cap -1 error: invalid argument in xenHypervisorSetSchedulerParameters: Credit scheduler cap parameter (-1) is out of range (0-65534) [root@dhcp-66-70-62 ~]# virsh schedinfo rhel5u5_x86_64_xenpv --cap 65535 error: invalid argument in xenHypervisorSetSchedulerParameters: Credit scheduler cap parameter (65535) is out of range (0-65534) [root@dhcp-66-70-62 ~]# virsh schedinfo rhel5u5_x86_64_xenpv --cap 0 Scheduler : credit weight : 256 cap : 0 [root@dhcp-66-70-62 ~]# virsh schedinfo rhel5u5_x86_64_xenpv --cap 65534 Scheduler : credit weight : 256 cap : 65534 Version-Release number of selected component (if applicable): [root@dhcp-66-70-62 ~]# uname -a Linux dhcp-66-70-62.nay.redhat.com 2.6.18-183.el5xen #1 SMP Mon Dec 21 18:46:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux [root@dhcp-66-70-62 ~]# rpm -qa|grep libvirt libvirt-0.6.3-28.el5 libvirt-debuginfo-0.6.3-28.el5 libvirt-python-0.6.3-28.el5 [root@dhcp-66-70-62 ~]# rpm -qa|grep xen xen-libs-3.0.3-102.el5 xen-devel-3.0.3-102.el5 kmod-gnbd-xen-0.1.5-2.el5 kmod-gfs-xen-0.1.34-9.el5 xen-3.0.3-102.el5 xen-libs-3.0.3-102.el5 kernel-xen-2.6.18-183.el5 kmod-cmirror-xen-0.1.22-3.el5 BTW,weight boundary value seems to exist problem.I am tracing the problem.
Atsushi SAKAI <sakaia.com> told me that the bug at the xen level is: > The problematic code is follows. > > Problem code (still continues on latet upstream Xen). > http://xenbits.xen.org/xen-3.4-testing.hg?file/a7b2d4e03a1f/xen/common/sched_credit.c > 678 if ( op->u.credit.cap != (uint16_t)~0U ) > 679 sdom->cap = op->u.credit.cap; > Daniel
This bug is verified PASS with libvirt-0.6.3-31.el5 on RHEL-5.5-Server-x86_64-xen with xenpv guest
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0205.html