Escalated to Bugzilla from IssueTracker
I.) What is the exact nature of the problem trying to be solved with this request? Add "default-vcpus" / "max-vcpus" style options to Xen configuration file. It is currently possible to set the vcpus value in the Xen config file, however, it sets both the maximum and default number of vcpus. Once set, the vcpus options limits the number of vcpus to the given value, which means that the value can be lowered but cannot be increased beyond the value initially set in the xen config file. The RFE is about using two different options to set the values for the number of vcpus, one to set the default number of vcpus at startup, and another one to set the maximum number of vcpus available. II.) What, if any, business requirements are satisfied by this request? (What is the use case context?) Customer wants to be able to increase the number of vcpus when needed. Currently, he has to do the following: 1. set vcpus=4 in my config file. 2. xm create <my guest> 3. xm vcpu-set <my guest> 2 4. And when i need to "hot add" more vcpus: xm vcpu-set <my guest> 4 This is not convenient when dealing with a lot of virtual machines since the vcpu-set has to be changed after starting each virtual machine. III.) List the functional requirement(s) for performing the action(s) that are not presently possible. Please focus on describing the problem related requirements without projecting any specific solution. Xen should give a way to set the limit of vcpus and the default number of vcpus independently. IV.) Each functional requirement must have clear acceptance criteria so Red Hat understands what success looks like. If test cases can be provided this would be even more ideal (bonus points for RHTS test cases). V.) What is the desired release vehicle to satisfy these requirements? Major release Minor release Might be a included in a minor release since it does seems to be a minor RFE (adding a new option to xen config file) VI.) What package(s) are affected by this RFE? (List "new" if new technology is likely to be required) xen libvirt This event sent from IssueTracker by jwest [SEG - Feature Request] issue 169053
File uploaded: sosreport-xen7-1-626440-d4fd1a.tar.bz2 This event sent from IssueTracker by jwest [SEG - Feature Request] issue 169053 it_file 123779
Support for this is still not present upstream FYI.
I almost did the first version of patch to add this support to Xen. But how can I check it's working fine? I did following: 1. added 'maxvcpus = 2' to a domain config file 2. xm create {guestName} 3. xm vcpu-list {guestName} -> it returned 1 line 4. xm vcpu-set {guestName} 2 -> no error 4. xm vcpu-list {guestName} -> it returned 1 line again Where can I see there are 2 vCPUs set? Number 2 in VCPU(s) column ? Thanks, Michal
I am trying to investigate this myself and I saw following: I run domain that has 1 vcpu and 2 maxvcpus and I see following in xenstore: /vm/{uuid}/vcpu{s,_avail} set to 1 with availability of 1 vcpu when I run `xm vcpu-set {guestName} 2` I am getting vcpu_avail of 3 and vcpu returns still 1. It's the result of setVCpuCount() method call. Should I consider this function is not working at all? Any ideas about that ? I need to investigate this more but I certainly don't want to break anything that's already working with current implementation of this function. Thanks, Michal
More testing shows that I can't hot-unplug VCPU. My guest is RHEL 5.3, kernel 2.6.18-128.el5xen. Does this kernel support VCPU hot-unplug ? When I remove entries manually from xenstore console prints out XENBUS: Unable to get cpu state or something like that but `cat /proc/cpuinfo` is still showing 2 cpus in place as well as xentop/xm vcpu-list. Everything is showing the domain has 2 cpus but there should be. Is it even possible with kernel stated above? Thanks, Michal
Created attachment 361880 [details] Patch to add this feature to Xen I finally figure it out how it's working. This is the patch to add desired feature into Xen package. This patch checks for `maxvcpus` option in xen config file and if the option is not found, it's set to the default value of vcpus. When you start the domain with 1 vcpu and maxvcpus is set to 3, you can easily change the number of vcpus up to 3 and back using `xm vcpu-set {guestName} {numberOfVCPUs}` command. If the number is out of range (ie. bigger than maxvcpus option) an error message is returned ... It appears relevant changesets are already upstream at http://xenbits.xensource.com/xen-unstable.hg?rev/6ca065624051 and http://xenbits.xensource.com/xen-unstable.hg?rev/4baae9f9fdbb but I was unable to use it because of another codebase and that we're not using XendAPI. Testing has been done on x86_64 box running RHEL 5.4 dom0 (kernel 2.6.18-164.el5xen) and RHEL 5.3 guest (kernel 2.6.18-128.el5xen) using the `xm vcpu-set {guestName} {numberOfVCPUs}` command.
*** Bug 525216 has been marked as a duplicate of this bug. ***
Test RPMs are available at: http://people.redhat.com/minovotn/xen/ They are based on -94 version of Xen package.
Well, I think I should copy steps from my private comment #18 as a new comment so here are the steps to reproduce: Please download package from: http://people.redhat.com/minovotn/xen/maxvcpus/ Steps are: 1. open a PV guest config file and add eg. 'vcpus = 1' and 'maxvcpus = 2' lines 2. start the guest using `xm create guestName` 3. in the guest log-in and cat /proc/cpuinfo, you should see just one VCpu now 4. disconnect from console (Ctrl + ]) and set vcpu count of guest to 2 by `xm vcpu-set guestName 2` 5. connect to guest console again (`xm console guestName`) 6. cat /proc/cpuinfo in the guest... you should be seeing 2 cpus now 7. run `xm list` in the host machine, it should be showing that guestName is using 2 vcpus Everything works fine in my testing enviroment...
Created attachment 373733 [details] New version of this patch Well, this is new version of my patch... Steps are the same, just an existing infrastructure is used... Package could be found on the same location like in comment #23.
Created attachment 373991 [details] Third version of my patch Well, this is new version of my patch... Everything is working the same way like version 2 but just code was polished a little...
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).
After a long delay I cloned this bug over to libvirt. I'm clearing out the needinfo request now. Chris Lalancette