GNOME Bugzilla – Bug 748066
Allow users to specify CPUs assigned to a box
Last modified: 2018-01-11 10:17:09 UTC
Created attachment 301856 [details] New slider in action Since one is able to select the amount of memory and disk-space for a box, in my oppinion one should also be able to select the number of vCPUs for a box. This would be as an additional slider to the memory / disk-space slider. On my machine gnome-boxes defaults to using as many vCPUs as I have cpu-cores, so I would like to be able to reduce this. I wanted to get into developing gnome-apps, so I have a patch ready that adds this slider (I will try to attach it soon). Since it's my first time in Gnome/Vala/Boxes I might have overlooked some things, so please review (if you think this feature is good.)
Created attachment 301857 [details] [review] i-properties-provider: Extract IntProperty from SizeProperty. Extracts a IntProperty that displays a slider with int values from the SizeProperty Class that displays the same information using differently formatted labels. No outside interfaces have been changed except for add_int_property being added.
Created attachment 301858 [details] [review] libvirt-machine-properties: Add vCPUs configuration to virtual machine configuration. This gives the user the option to choose how many vcpus he wants to use for his virtual machine. It adds a IntProperty type property to the configuration dialog that updates the machine domain config "current-vcpus" property. A restart of the machine is required.
Created attachment 301859 [details] [review] wizard: Shows the number of vCPUs assigned to a vm in the wizard. As the number of vCPUs is now visible in the configuration it should be reflected in the wizard.
Firstly, you want to say `Number of CPUs' rather. Prefix of 'v' is shorthand for 'number of' AFAIK.
Secondly. What is the usecase? i-e what are the scenarios when user needs to explicitly specify number of CPUs? How common are these usecases expected to be?
I think the 'v' is a shorthand for virtual here ? to indicate that you are not reserving any physical cpus for the vm exclusively, but rather instruct qemu how many cpus to simulate in the vm.
(In reply to Matthias Clasen from comment #6) > I think the 'v' is a shorthand for virtual here ? to indicate that you are > not reserving any physical cpus for the vm exclusively, but rather instruct > qemu how many cpus to simulate in the vm. ah ok but still, i don't think that detail needs to be exposed to user at least. Everything is virtual anyway, including RAM and storage.
You're both right, vCPUs stands for virtual cpus, which is the number of cpus that are simluated, but the label of the slider should be "Number of CPUs" to be consistent with the other labels. As for the Use-Case, I think there are pretty common ones for this feature: * Simple way to tune performance for a box * Testing something in a resource constrained environment * Having multiple (e.g. build-) machines that don't influence each other as much I noticed that with the patches, the restart notification does not show. This is due to an error I introduced in my cleanup phase. In update_vcpus_property it should be (actual - pending) != 0.
Especially balancing performance between host and guest is an important usecase for VMs IMO, so my vote goes for it.
(In reply to github from comment #8) > You're both right, vCPUs stands for virtual cpus, which is the number of > cpus that are simluated, but the label of the slider should be "Number of > CPUs" to be consistent with the other labels. > > As for the Use-Case, I think there are pretty common ones for this feature: > * Simple way to tune performance for a box But why does user needs to do that, given that we give all CPU power to the VM already? > * Testing something in a resource constrained environment That could be a valid use case. Jimmac? > * Having multiple (e.g. build-) machines that don't influence each other as > much IMO this is very similar to saying that GNOME (or any OS) should provide a similar setting for apps. VMs share CPUs with each other just like apps on the host do so the question that comes to my mind is why then we want this for one and not the other case? > I noticed that with the patches, the restart notification does not show. > This is due to an error I introduced in my cleanup phase. In > update_vcpus_property it should be (actual - pending) != 0. Ah ok, please update the patch in that case once we have concluded if we want this or not.
(In reply to Lasse Schuirmann from comment #9) > Especially balancing performance between host and guest is an important > usecase for VMs IMO, so my vote goes for it. And you want this management to be thrown at user? I have not heard anyone having any issues regarding this. Not having sufficient resources to run VMs is a different issue and that is usually related to RAM and not CPU.
(In reply to Zeeshan Ali (Khattak) from comment #10) > (In reply to github from comment #8) > > * Testing something in a resource constrained environment > > That could be a valid use case. Jimmac? Hmm.. on second thought, is this a common enough use case? I feel it's not and can be handled in the guest itself using some specific tools: http://cpulimit.sourceforge.net/
Created attachment 302628 [details] [review] libvirt-machine-properties: Add vCPUs configuration to virtual machine configuration. This gives the user the option to choose how many vcpus he wants to use for his virtual machine. It adds a IntProperty type property to the configuration dialog that updates the machine domain config "current-vcpus" property. A restart of the machine is required.
(In reply to Stefan Lau from comment #13) > Created attachment 302628 [details] [review] [review] > libvirt-machine-properties: Add vCPUs configuration to virtual machine > configuration. Thanks for the patch Stefan but currently I'm looking for justification for this addition. Please reply to my questions above. I'm hoping we get a comment from a designer too. > This gives the user the option to choose how many vcpus he wants to use for > his > virtual machine. It adds a IntProperty type property to the configuration > dialog > that updates the machine domain config "current-vcpus" property. A restart > of the > machine is required. FWIW, details of commit log are more for high-level summary of changes (not the details), justification/benefits and known issues (if any).
Not knowing deep enough about the motives/specific user needs, here's my 2 cents worth. Performance tuning isn't exactly a use case for Boxes. That's something I'd look for in virt manager or inside a library/GNOME Builder integration. Very specific "engine-tuning" controls don't mix very well with what Boxes aims to be. General resource restriction for apps seems like something better handled at the system level.
I wanted to add some insight into this, as this is a request I have as well. Limiting the CPU cores of a VM is actually a good thing. Although seemingly opposite of what one would assume, the less cores a VM has, the better it performs (from as CPU scheduling perspective). For example, if a host computer has 4 cores, and a VM has 4 cores assigned, when the VM wishes to schedule something for the CPU, it has to wait until all 4 cores on the host are available at one time, in order to compute. If a VM has 1 core assigned, it only needs to wait until 1 of the 4 cores of the host are available. Being able to specify the number of cores I believe is an essential setting, especially if one is running these VMs on a typical desktop or laptop for testing. Most likely you are doing additional things on that computer while the VM runs. Here is a good explanation on VM CPU scheduling: https://itmonsterrrrrr.blogspot.com/2012/08/deep-dive-vmware-esx-cpu-scheduler.html
(In reply to Andrew Crouthamel from comment #16) > I wanted to add some insight into this, as this is a request I have as well. > Limiting the CPU cores of a VM is actually a good thing. Although seemingly > opposite of what one would assume, the less cores a VM has, the better it > performs (from as CPU scheduling perspective). > > For example, if a host computer has 4 cores, and a VM has 4 cores assigned, > when the VM wishes to schedule something for the CPU, it has to wait until > all 4 cores on the host are available at one time, in order to compute. If a > VM has 1 core assigned, it only needs to wait until 1 of the 4 cores of the > host are available. Is this true for kvm? do you have any reference other than vmware doc you linked?
I found the following, which states KVM uses the standard Linux CFS scheduler, with each vCPU as a process: http://www.madeforcloud.com/2012/04/20/KVM-vCPU-Scheduling/ Now, how CFS handles multiple processes at once for a VM with say 4 vCPUs, I don't know, and haven't found documentation on. This may end up being a question for KVM/CFS devs.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-boxes/issues/52.