Re: [atomic-devel] Proposal for default qcow2 image virtual size 10G instead of 6G

[Vivek Goyal <vgoyal redhat com>]

On Fri, Sep 04, 2015 at 12:58:58PM -0400, Colin Walters wrote:
> On Fri, Sep 4, 2015, at 12:50 PM, Vivek Goyal wrote:
> 
> > Virtual size of qcow2 f22 atomic size is 6G. 
> 
> This comes from https://pagure.io/releng/blob/master/f/scripts/build-cloud-images#_93
> 
> Now, one important thing about the cloud image is that via cloud-init it supports dynamic extension of the drive.  The primary use case is in IaaS - OpenStack, AWS etc.  These systems will typically let you choose at boot time to use 10G, 20G, 160G or whatever you want, and growpart/cloud-init will extend the drive.  docker-storage-setup then kicks in and balances things between the host and Docker.
> 
> If you're booting the cloud image in bare libvirt...welll, this type of thing
> is better covered by Vagrant.  (And the Vagrant box is 40G, for this reason):
> https://pagure.io/releng/blob/master/f/scripts/build-cloud-images#_114
> 
> If you still want to use raw libvirt, I have a really stupid script here:
> 
> https://github.com/cgwalters/homegit/blob/master/bin/walters-create-cloud-vm

Colin,

I don't use vagrant and I just take qcow image and import it using
virt-manager. Following instructions here.

http://www.projectatomic.io/docs/quickstart/

So for this use case giving a better default size image might not be a
bad idea. In fact even 20G default virtual size might be better if 
one wants to do something meaningful.

Thanks
Vivek

> 
> which shows how to create a CoW image with any size you choose.
> 
> > Is it a good idea to bump up default virtual size to 10G?
> 
> So per above, I'd say Vagrant is going to be more ergonomic for users
> who hit this problem. That said I'm not opposed to increasing to 10G,
> in the end it's all thinly provisioned.