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 789396 - minimal disk size is too high
minimal disk size is too high
Status: RESOLVED FIXED
Product: gnome-boxes
Classification: Applications
Component: wizard
3.26.x
Other Linux
: Normal normal
: --
Assigned To: GNOME Boxes maintainer(s)
GNOME Boxes maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2017-10-24 09:53 UTC by Kamil Páral
Modified: 2017-11-13 13:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
boxes with F27 VM (19.32 KB, image/png)
2017-10-24 13:42 UTC, Kamil Páral
  Details
libvirt-machine-props: Don't use default size as min size (2.70 KB, patch)
2017-10-24 16:19 UTC, Fabiano Fidêncio
committed Details | Review

Description Kamil Páral 2017-10-24 09:53:47 UTC
When I want to create a new VM for Fedora, the minimal disk size is 21.5 GB. While that is a reasonable *recommended* size for light usage, I believe it's a big mistake to not allow the size to be set any lower. As a SSD user, I value every GB that I save. As a QA tester, I need to have many many VMs present. With boxes, I simply can't satisfy my use cases, because the VMs occupy too much space and can't be made smaller.

gnome-boxes-3.26.1-3.fc27.x86_64
Comment 1 Felipe Borges 2017-10-24 13:00:30 UTC
This doesn't mean that GNOME Boxes will allocate 20GB of space when creating the VM. The actual disk space used by Boxes will be less than (or in worst case, equal to) the disk space used by the virtual machine itself.

Besides, Boxes gets this data from Libosinfo through the os.get_minimum_resources api. See https://lazka.github.io/pgi-docs/Libosinfo-1.0/classes/Os.html#Libosinfo.Os.get_minimum_resources

Anyway I think it is relevant to discuss the minimal storage size.

I would assume most vendors specify in their website their minimal supported resources, and libosinfo incorporates that. Is that correct?
Comment 2 Fabiano Fidêncio 2017-10-24 13:10:20 UTC
Kamil, if you click the "Customize..." button (in the "Review" page of the wizard) you'll see there a way to decrease the disk size. In case it doesn't work for you, then it's a bug in GNOME Boxes.

Can you tell me whether the "Customize..." button works for you and also which version of Fedora you tried? It may be the case that the OS is not recognized and GNOME Boxes is allocating a "safe but too big" disk space for you.
Comment 3 Fabiano Fidêncio 2017-10-24 13:13:40 UTC
Just for the record: https://fidencio.fedorapeople.org/boxes_customize.png
Comment 4 Kamil Páral 2017-10-24 13:41:48 UTC
(In reply to Felipe Borges from comment #1)
> This doesn't mean that GNOME Boxes will allocate 20GB of space when creating
> the VM. The actual disk space used by Boxes will be less than (or in worst
> case, equal to) the disk space used by the virtual machine itself.

Yes I'm aware of that. But the image grows with each filesystem change, up to 20 GB. Freeing up the space in guest does not free it up on host. So it doesn't really help me in ensuring the image occupies at most e.g. 10 GB.

(In reply to Fabiano Fidêncio from comment #3)
> Just for the record: https://fidencio.fedorapeople.org/boxes_customize.png

That's interesting. See my screenshot attached. It's this image:
https://kojipkgs.fedoraproject.org/compose/branched/Fedora-27-20171023.n.0/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-27-20171023.n.0.iso

I always work with in-development Fedora images. Maybe that explains why I never see the option to make the disk smaller.

I tested with F26 and you're right that the image can be made smaller up to 10.7 GB.
Comment 5 Kamil Páral 2017-10-24 13:42:05 UTC
Created attachment 362183 [details]
boxes with F27 VM
Comment 6 Fabiano Fidêncio 2017-10-24 14:20:47 UTC
(In reply to Kamil Páral from comment #4)
> (In reply to Felipe Borges from comment #1)
> > This doesn't mean that GNOME Boxes will allocate 20GB of space when creating
> > the VM. The actual disk space used by Boxes will be less than (or in worst
> > case, equal to) the disk space used by the virtual machine itself.
> 
> Yes I'm aware of that. But the image grows with each filesystem change, up
> to 20 GB. Freeing up the space in guest does not free it up on host. So it
> doesn't really help me in ensuring the image occupies at most e.g. 10 GB.
> 
> (In reply to Fabiano Fidêncio from comment #3)
> > Just for the record: https://fidencio.fedorapeople.org/boxes_customize.png
> 
> That's interesting. See my screenshot attached. It's this image:
> https://kojipkgs.fedoraproject.org/compose/branched/Fedora-27-20171023.n.0/
> compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-27-20171023.n.
> 0.iso
> 
> I always work with in-development Fedora images. Maybe that explains why I
> never see the option to make the disk smaller.
> 

So, I've just checked the code and came up with a (not yet) tested patch which sets the minimum disk size to 10GB in case the image is not recognized.

Just to be more than clear, the recommended size won't be changed, at all, but at least you'll have the chance to customize the disk size to something smaller that fits your needs.

Thanks for pointing us out to this issue.
Comment 7 Kamil Páral 2017-10-24 14:42:12 UTC
Thanks, that sounds reasonable.
Comment 8 Fabiano Fidêncio 2017-10-24 16:19:22 UTC
Created attachment 362201 [details] [review]
libvirt-machine-props: Don't use default size as min size

When an ISO is not part of osinfo-db GNOME Boxes previously used a default pre-defined size for storage as the minimum size for the storage, which had as a drawback that the users were not able to decrease the size of the disk when customizing the VM.

In order to avoid the issue described above a new pre-defined size for minimum storage has been added (10 GIBIBYTES) which gives the users the chance to decrease the disk size according to their needs, in case the default pre-defined size is too big for them.

Although adding a new method seems to be a too cumbersome, I do believe it's a better way to handle this (and that we can expand in the future) than having constants being used in libvirt-machine-properties as we do for the minimum RAM size.
Comment 9 Felipe Borges 2017-11-09 13:26:36 UTC
Review of attachment 362201 [details] [review]:

Sure.

As we spoke out of record, it would be interesting if Osinfo could be more accurate in this regard, providing proper minimum AND recommended resources.

Thanks for your contribution!
Comment 10 Fabiano Fidêncio 2017-11-09 13:34:26 UTC
(In reply to Felipe Borges from comment #9)
> Review of attachment 362201 [details] [review] [review]:
> 
> Sure.
> 
> As we spoke out of record, it would be interesting if Osinfo could be more
> accurate in this regard, providing proper minimum AND recommended resources.
> 
> Thanks for your contribution!

Thanks for the review, but let me just mention one thing.

Osinfo *does* provide minimum and recommended resources and it *is* used by GNOME Boxes already. The problem here affected only the case where the ISO was *not* recognized, so Osinfo does not have much to do on those cases.
Comment 11 Felipe Borges 2017-11-13 13:04:43 UTC
Attachment 362201 [details] pushed as 670d447 - libvirt-machine-props: Don't use default size as min size