GNOME Bugzilla – Bug 664774
allow adjustment of vm settings
Last modified: 2016-03-31 14:03:06 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.
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.
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.
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.
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 :)
(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. :)
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.
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.
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.
(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.
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.
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.
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.
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.
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.
Created attachment 208914 [details] [review] properties: Allow changing of RAM & storage size
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".
Created attachment 208915 [details] [review] properties: Allow changing of RAM & storage size Better?
Review of attachment 208915 [details] [review]: ack
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.
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?
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 :)
Attachment 209003 [details] pushed as e75c506 - properties: Allow changing of RAM & storage size