GNOME Bugzilla – Bug 789396
minimal disk size is too high
Last modified: 2017-11-13 13:04:48 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
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?
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.
Just for the record: https://fidencio.fedorapeople.org/boxes_customize.png
(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.
Created attachment 362183 [details] boxes with F27 VM
(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.
Thanks, that sounds reasonable.
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.
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!
(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.
Attachment 362201 [details] pushed as 670d447 - libvirt-machine-props: Don't use default size as min size