These images are huge #24
Comments
|
hi! first things first - thanks for finding my images useful :-) box size ended being 40G for historical and consistency reasons - as it's the same size in the other variants for the remaining providers. I can trivially take a lower default and update docs to point users to
I'll take a look soonish at shrinking default size while at same time trying to transparently handle on my side the fs resize part which the thanks again! |
|
Thank you! Yes very useful. I'm a big fan of the stateless design and Clear
Linux and finding little gems like your project is very exciting and gives
me great hope (and ideas) for my future plans with the OS.
…On Tue, Jun 30, 2020, 2:09 PM António Meireles ***@***.***> wrote:
@inmanturbo <https://github.com/inmanturbo>
hi! first things first - *thanks for finding my images useful* :-)
box size ended being 40G for historical and consistency reasons - as it's
the same size in the other variants for the remaining providers.
I can trivially take a lower default and update docs to point users to
vagrant-livbirt's driver machine_virtual_size option which (quoting
<https://github.com/vagrant-libvirt/vagrant-libvirt#domain-specific-options>)
...
Sets the disk size in GB for the machine overriding the default specified
in the box. Allows boxes to defined with a minimal size disk by default and
to be grown to a larger size at creation time. Will ignore sizes smaller
than the size specified by the box metadata. Note that *currently there
is no support for automatically resizing the filesystem to take advantage
of the larger disk.*
I'll take a look soonish at shrinking default size while at same time
trying to transparently handle on my side the fs resize part which the
vagrant-livbirt's driver doesn't do, so that ends being fully transparent
to the end user.
thanks again!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#24 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALHJ6SFZLYQWLULSJYZ5XMLRZIS6LANCNFSM4OMP6MPQ>
.
|
Signed-off-by: António Meireles <antonio.meireles@reformi.st>
|
Hi, (sorry the lag) just committed the needed changes. Default size will be now 5G. if no issues arise in ongoing smoke testing this week images will already consume this changes. Many thanks for your patience! |
|
Thank you very much! Less overhead makes it much easier to spin up a bunch
of these. Size can always be increased when needed.
…On Mon, Aug 17, 2020, 7:52 AM António Meireles ***@***.***> wrote:
@inmanturbo <https://github.com/inmanturbo>
Hi, (sorry the lag)
just committed the needed changes. Default size will be now 5G. if no
issues arise in ongoing smoke testing this week images will already consume
this changes.
Many thanks for your patience!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#24 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALHJ6SCS3W4P2OQ4O3TCEULSBEKYTANCNFSM4OMP6MPQ>
.
|
per AntonioMeireles/ClearLinux-packer#24 the ClearLinux libvirt boxes default size was lowered from the previous 40G to a more manageable 5G, having the user the ability to, at box instantiation, to increase that value to whatever is adequate. In order to avoid surprises in this side the Vagrantfile was modded to have hardcoded the previous default value. This change is forward and backward compatible as it will just be ignored when using older boxes ( since the 'new' root volume size just the same as original one) and will resize the box to the expected 40G in newer ones. Signed-off-by: António Meireles <antonio.meireles@reformi.st>
…way (#330) per AntonioMeireles/ClearLinux-packer#24 the ClearLinux libvirt boxes default size was lowered from the previous 40G to a more manageable 5G, having the user the ability to, at box instantiation, to increase that value to whatever is adequate. In order to avoid surprises in this side the Vagrantfile was modded to have hardcoded the previous default value. This change is forward and backward compatible as it will just be ignored when using older boxes ( since the 'new' root volume size just the same as original one) and will resize the box to the expected 40G in newer ones. Signed-off-by: António Meireles <antonio.meireles@reformi.st>
|
just pushed Feel free to reopen or fill a new bug if issues arise. Thanks, once again, for your patience! |
First I just want to say that is is great that someone is doing this. However when I pull this I end up with like a 40g volume (!).
I'm trying to set up a three node prototype for a kubernetes project on a small nested libvirt instance. I don't want to have to mount a san/nas volume with this instance as that will introduce some extras complexities regarding permissions that come along with using nfs for a libvirt pool that I don't want to bother with just for this little lab. And I don't want to put in another storage ticket. It shouldn't be necessary.
Anyway the thing crashes my vm and I had no idea why until I took a peak under the hood with virsh and saw this massive qcow2. Must the image be so large?
Thanks
The text was updated successfully, but these errors were encountered: