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 664774 - allow adjustment of vm settings
allow adjustment of vm settings
Status: RESOLVED FIXED
Product: gnome-boxes
Classification: Applications
Component: general
3.3.x (unsupported)
Other Linux
: Normal normal
: --
Assigned To: GNOME Boxes maintainer(s)
GNOME Boxes maintainer(s)
ui-design
Depends on: 670994
Blocks:
 
 
Reported: 2011-11-25 00:18 UTC by doctorkohaku
Modified: 2016-03-31 14:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
WIP: properties: Allow changing of RAM & storage size (13.75 KB, patch)
2012-02-27 16:09 UTC, Zeeshan Ali
none Details | Review
properties: Allow changing of RAM & storage size (14.19 KB, patch)
2012-03-02 00:27 UTC, Zeeshan Ali
reviewed Details | Review
properties: Allow changing of RAM & storage size (14.70 KB, patch)
2012-03-03 18:12 UTC, Zeeshan Ali
reviewed Details | Review
properties: Allow changing of RAM & storage size (15.22 KB, patch)
2012-03-03 18:26 UTC, Zeeshan Ali
accepted-commit_now Details | Review
properties: Allow changing of RAM & storage size (14.35 KB, patch)
2012-03-05 15:08 UTC, Zeeshan Ali
committed Details | Review

Description doctorkohaku 2011-11-25 00:18:54 UTC
Users should be allowed to modify the basic parameters of their virtual machines (both at creation and later on); such as number of VCPUs, RAM, attached devices, disk size etc.

Rationale:
- One size does not fit all
- People may want to decide whether they want maximum guest or host performance (adjust no. of allocated VCPUs)
- Different use cases use different amount of RAM. A lightweight Openbox desktop may use less than 100MB, a huge database can use tens of GBs.
- Windows zeroes out RAM on boot (always uses the maximum amount of RAM allocated by KVM) - see http://www.linux-kvm.org/page/FAQ#Is_dynamic_memory_management_for_guests_supported.3F
- Could support other architectures through qemu emulation, such as arm for Android
- Having huge, dynamically expanding disk images is a bad idea. Some OSs refuse to boot from a huge hard drive, even Linux must be (but mostly is) compiled with support for big disks.
- Could make existing qemu images attachable to boxes for easy migration.
- The lack of customization will probably be the first thing people will point out when comparing gnome-boxes to other virtualization software.
Requirements:
- libosinfo would probably need to provide more information, such as minimum-ram, supports-smp etc.
Comment 1 Zeeshan Ali 2011-11-25 00:35:54 UTC
I think that goes against the very idea of boxes. If this size doesn't fit someone, that person is at liberty to use some advanced UI like virt-manager. Anyway, I'll still put it forward to designers.
Comment 2 Zeeshan Ali 2011-11-25 00:37:54 UTC
The aim is to have libosinfo provide most (if not all) the information possible and there is even a guy working on it as a GCI task. Hopefully soon we'll have a LOT of data in there.
Comment 3 Marc-Andre Lureau 2011-11-25 01:07:43 UTC
I have to agree with Zeeshan. In general , by design, Boxes has the minimum adjustements/settings. Things should work without pain, and for the rest, you can always setup and tune your VM either with virt-manager or even manually!

I personnally think we should overcommit by default: declare more RAM, more disk space etc.. but we will see how it goes.

So except perhaps attached devices (ie shared directory etc), I think most of your requests won't be supported by Boxes in a near future.
Comment 4 Christophe Fergeau 2011-11-25 09:19:57 UTC
I was under the impression that unchecking "express install" on https://github.com/gnome-design-team/gnome-mockups/raw/master/boxes/boxes-install4.png would allow to tweak disk space/memory, but I totally forgot if I assumed this because of a mockup showing it, a discussion with a designer or because I made it up. So better to ask :)
Comment 5 Zeeshan Ali 2011-11-28 22:23:50 UTC
(In reply to comment #4)
> I was under the impression that unchecking "express install" on
> https://github.com/gnome-design-team/gnome-mockups/raw/master/boxes/boxes-install4.png
> would allow to tweak disk space/memory, but I totally forgot if I assumed this
> because of a mockup showing it, a discussion with a designer or because I made
> it up. So better to ask :)

Indeed, hence the 'ui-design' whiteboard. :)
Comment 6 Jonathan Blandford 2011-11-28 22:26:55 UTC
Agree with teuf.  I thought that's what happened when you unchecked "express install".  Clearly there's a difference between providing everything that libvirt provides, and some basic functionality, but available disk-space seems totally reasonable and legit, and guidance on memory makes sense as well.
Comment 7 Zeeshan Ali 2011-11-28 22:30:34 UTC
FWIW, the intended meaning of 'express install' is 'unattended/automatic install' here AFAIK. Not saying that we can't extend it to mean something more.
Comment 8 Zeeshan Ali 2011-11-28 22:58:19 UTC
My proposal would be to allow the 'Memory' and 'Disk' props modifiable at this page:

https://github.com/gnome-design-team/gnome-mockups/raw/master/boxes/boxes-install5.png

Should be pretty easy to implement.
Comment 9 Zeeshan Ali 2011-11-29 01:19:37 UTC
(In reply to comment #8)
> My proposal would be to allow the 'Memory' and 'Disk' props modifiable at this
> page:
> 
> https://github.com/gnome-design-team/gnome-mockups/raw/master/boxes/boxes-install5.png

forgot to write: when 'express install' is disabled.
Comment 10 Jakub Steiner 2011-11-29 10:18:28 UTC
I don't think turning a review page into a settings page would be a good choice. The settings part needs to happen prior to the review step. While I'm not sure Jon intended the following behavior, the express setup does hint to trusting Boxes with not only the choices to get through the install process in the guest, but also making the right choices about the virtualized hardware to be able to install it. It feels natural to me to replace the controls for setting up a user in the express install with settings of the underlying system if you choose not to go with express. 

Express install and custom memory/disk settings seem exclusive. If we know the system is installable (we have the install receiepe), we don't need to expose these settings. This can later be customized in the box properties though.

There might be systems that won't allow to do an express install because we don't know about them. In that case I would either show the express switch insensitive or be verbose about not knowing about the OS (label). In both cases the memory/disk size controls would be exposed. Obviously at this point you expect a high fidelity mockup or at least a wireframe. There are some details I'd like to discuss with Jon though, mainly about using an existing disk image being a relevant case.
Comment 11 William Jon McCann 2011-12-13 21:48:50 UTC
Of course we intend to be able to change ram and disk sizes - one can change a physical machine after all.

A couple of points, though.

 * We do not really want it to be part of the typical creation process - it is just too confusing. Even the way vmware does it is pretty confusing.
 * We probably do need to have it available somehow during the box creation and before the os install since some (hopefully rare) installs may need a special tweak.
 * We probably also need to offer the same options after the install though some things may not be available while the os is running.

I don't agree with Jakub that express install and changing advanced options are mutually exclusive. One is about hardware setup and the other is about os setup (more or less). So, they are fairly orthogonal actually.

Perhaps we can show a Customize button on the summary screen before creating the box. This could show the properties dialog where hardware attributes may be changed. When done changing the attributes we could then update the summary screen as necessary and do another sanity check on the parameters.

That check probably shouldn't be necessary since we shouldn't really allow one to change things in the properties that don't make sense or obviously break things. But it doesn't hurt.

Then when the install finishes the user is free to change the settings in the same (familiar) way they did when they set it up in the first place. Which is particularly nice if the options were only needed to get the thing installed and not needed to run.

The particulars all need to be mocked up of course.
Comment 12 Zeeshan Ali 2012-02-27 16:09:42 UTC
Created attachment 208499 [details] [review]
WIP: properties: Allow changing of RAM & storage size

This is still work in progress as changing of volume size will result in
it's corruption. Need to bind some more libvirt API before I can fix this
issue.
Comment 13 Zeeshan Ali 2012-03-02 00:27:24 UTC
Created attachment 208833 [details] [review]
properties: Allow changing of RAM & storage size

Same patch but this one actually works and is on top of attachment in bug#670994.
Comment 14 Marc-Andre Lureau 2012-03-03 17:43:15 UTC
Review of attachment 208833 [details] [review]:

patch looks ok, some small comment.

::: src/properties.vala
@@ +112,3 @@
+            var machine = app.current_item as Machine;
+            if (i == PropertiesPage.SYSTEM && !(machine is LibvirtMachine))
+                continue;

There is a method "is_empty()" used bellow, that was always false until now but should return true in this case, instead of having a special case here.
Comment 15 Zeeshan Ali 2012-03-03 18:12:34 UTC
Created attachment 208914 [details] [review]
properties: Allow changing of RAM & storage size
Comment 16 Marc-Andre Lureau 2012-03-03 18:17:01 UTC
Review of attachment 208914 [details] [review]:

::: src/properties.vala
@@ +42,3 @@
+            case PropertiesPage.SYSTEM:
+                name = _("System");
+                empty = !(machine is LibvirtMachine);

I would rather check if a property has been added, that would be more "generic".
Comment 17 Marc-Andre Lureau 2012-03-03 18:17:01 UTC
Review of attachment 208914 [details] [review]:

::: src/properties.vala
@@ +42,3 @@
+            case PropertiesPage.SYSTEM:
+                name = _("System");
+                empty = !(machine is LibvirtMachine);

I would rather check if a property has been added, that would be more "generic".
Comment 18 Zeeshan Ali 2012-03-03 18:26:18 UTC
Created attachment 208915 [details] [review]
properties: Allow changing of RAM & storage size

Better?
Comment 19 Marc-Andre Lureau 2012-03-03 18:33:18 UTC
Review of attachment 208915 [details] [review]:

ack
Comment 20 Zeeshan Ali 2012-03-05 15:08:46 UTC
Created attachment 209003 [details] [review]
properties: Allow changing of RAM & storage size

Yet another version (hopefully last one) that sets current storage capacity as the lowest value on slider rather than disallowing the user to move slider below current capacity.
Comment 21 Marc-Andre Lureau 2012-03-05 16:02:53 UTC
Review of attachment 209003 [details] [review]:

::: src/libvirt-machine.vala
@@ +399,3 @@
+            add_size_property (ref list,
+                               _("RAM"),
+                               domain_config.memory,

why can't you shrink RAM?
Comment 22 Marc-Andre Lureau 2012-03-05 16:03:24 UTC
Review of attachment 209003 [details] [review]:

::: src/libvirt-machine.vala
@@ +400,3 @@
+                               _("RAM"),
+                               domain_config.memory,
+            var max_ram = connection.get_node_info ().memory;

ok you can :)
Comment 23 Zeeshan Ali 2012-03-05 16:15:06 UTC
Attachment 209003 [details] pushed as e75c506 - properties: Allow changing of RAM & storage size