The cpu weight of a domain gets reset to the default one after a save/restore. Step to Reproduce: 1. Create a guest whose cpu_weight is 512 # xm sched-cr -d rhel5_fv_21 {'cap': 0, 'weight': 256} # xm sched-credit -d rhel5_fv_21 -w 512 # xm sched-cr -d rhel5_fv_21 {'cap': 0, 'weight': 512} 2. Save the guest with xm save <guest's name> savefile #xm save rhel5_fv_21 51 3. Restore the guest with xm restore savefile # xm restore 51 4. Show cpu_weight of the guest with xm sched-cr -d <guest's name> # xm sched-cr -d rhel5_fv_21 {'cap': 0, 'weight': 256} Actual Results: {'cap': 0, 'weight': 256} Expected Results: {'cap': 0, 'weight': 512}
I've recreated the problem on the latest 5.4 and now I'm taking a look.
I don't have an upstream build to test on right now. I'm working on that. In the meantime though, I'll just ask. Do you know if this problem exists upstream as well?
The save/restore of weight and cap doesn't appear to be implemented either in RHEL codes or in the upstream. In both streams there is a block of code like the the following in xend/XendDomainInfo.py that gets run during the restore path. # Check for cpu_{cap|weight} validity for credit scheduler if used if xen.lowlevel.xc.xc().sched_id_get() == xen.lowlevel.xc.XEN_SCHEDULER_CREDIT: cap = self.getCap() weight = self.getWeight() assert type(weight) == int assert type(cap) == int if weight < 1 or weight > 65535: raise VmError("Cpu weight out of range, valid values are within range from 1 to 65535") if cap < 0 or cap > self.getVCpuCount() * 100: raise VmError("Cpu cap out of range, valid range is from 0 to %s for specified number of vcpus" % (self.getVCpuCount() * 100)) What's strange is we do nothing with weight and cap after we've grabbed and validated them. The fix is to send these values back down to the hypervisor with a domctl call, i.e. diff xend/XendDomainInfo.py xend/XendDomainInfo.py-bz513211 1863a1864,1865 > xc.sched_credit_domain_set(self.domid, weight, cap) > I believe the same fix will work for upstream. After some upstream testing, I'll submit a patch there first to get feedback before submitting a final patch here.
I submitted a patch upstream. In the upstream the save path also needed a small fix, but the restore path change is the same as in #c8. I'm waiting for some feedback from that post, but I think the fix for at least RHEL will remain as is.
It turns out there was an upstream changeset added 2 weeks ago that fixes the exact same issue. I missed it since I messed up and didn't do my testing on the tip. Feedback from upstream pointed me to it, which is here, http://xenbits.xensource.com/xen-unstable.hg?rev/e07726c03d31. All that said, the "port" of the upstream patch to rhel will remain the same one-liner as in #c8. I'll post the patch in a moment.
Created attachment 356327 [details] xend: save-restore resets cpu params
Created attachment 363955 [details] ver2: save-restore preserve cpu params plus remove redundant param setting In review it was found that this patch introduces a redundant param setting on the create path. The extra param setting call is removed in this version (2) of the patch.
Fix built into xen-3.0.3-97.el5
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-0294.html
This bug was closed during 5.5 development and it's being removed from the internal tracking bugs (which are now for 5.6).