After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 748066 - Allow users to specify CPUs assigned to a box
Allow users to specify CPUs assigned to a box
Status: RESOLVED OBSOLETE
Product: gnome-boxes
Classification: Applications
Component: properties
3.17.x
Other Linux
: Normal enhancement
: --
Assigned To: GNOME Boxes maintainer(s)
GNOME Boxes maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2015-04-17 16:11 UTC by Stefan Lau
Modified: 2018-01-11 10:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
New slider in action (33.24 KB, image/png)
2015-04-17 16:11 UTC, Stefan Lau
  Details
i-properties-provider: Extract IntProperty from SizeProperty. (6.61 KB, patch)
2015-04-17 16:21 UTC, Stefan Lau
none Details | Review
libvirt-machine-properties: Add vCPUs configuration to virtual machine configuration. (6.39 KB, patch)
2015-04-17 16:22 UTC, Stefan Lau
none Details | Review
wizard: Shows the number of vCPUs assigned to a vm in the wizard. (1.08 KB, patch)
2015-04-17 16:22 UTC, Stefan Lau
none Details | Review
libvirt-machine-properties: Add vCPUs configuration to virtual machine configuration. (6.39 KB, patch)
2015-04-30 07:54 UTC, Stefan Lau
none Details | Review

Description Stefan Lau 2015-04-17 16:11:31 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.)
Comment 1 Stefan Lau 2015-04-17 16:21:55 UTC
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.
Comment 2 Stefan Lau 2015-04-17 16:22:00 UTC
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.
Comment 3 Stefan Lau 2015-04-17 16:22:05 UTC
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.
Comment 4 Zeeshan Ali 2015-04-17 16:46:21 UTC
Firstly, you want to say `Number of CPUs' rather. Prefix of 'v' is shorthand for 'number of' AFAIK.
Comment 5 Zeeshan Ali 2015-04-17 16:48:14 UTC
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?
Comment 6 Matthias Clasen 2015-04-17 16:50:13 UTC
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.
Comment 7 Zeeshan Ali 2015-04-17 17:00:55 UTC
(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.
Comment 8 Stefan Lau 2015-04-18 10:00:49 UTC
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.
Comment 9 Lasse Schuirmann 2015-04-18 10:23:47 UTC
Especially balancing performance between host and guest is an important usecase for VMs IMO, so my vote goes for it.
Comment 10 Zeeshan Ali 2015-04-22 13:20:47 UTC
(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.
Comment 11 Zeeshan Ali 2015-04-22 13:22:51 UTC
(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.
Comment 12 Zeeshan Ali 2015-04-24 15:04:58 UTC
(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/
Comment 13 Stefan Lau 2015-04-30 07:54:53 UTC
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.
Comment 14 Zeeshan Ali 2015-04-30 13:00:33 UTC
(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).
Comment 15 Jakub Steiner 2015-04-30 13:36:22 UTC
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.
Comment 16 Andrew Crouthamel 2017-04-12 04:31:42 UTC
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
Comment 17 Marc-Andre Lureau 2017-04-12 08:18:36 UTC
(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?
Comment 18 Andrew Crouthamel 2017-04-12 14:56:28 UTC
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.
Comment 19 GNOME Infrastructure Team 2018-01-11 10:17:09 UTC
-- 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.