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.
