I'm doing some tests with proxmox. I've created a test VM with 100GB qcow2 image stored on gluster with sharding All shards was created properly. Then, I've increased the qcow2 image size from 100GB to 150GB. Proxmox did this well, but on gluster i'm still seeing the old qcow2 image size (1600 shard, 64MB each) What happens when qemu has to write the 150GB to disk by incresing the qcow2 image (it's a COW, thus it expand only when needed) Shouldn't gluster increase the image size?
2016-09-29 0:02 GMT+02:00 Gandalf Corvotempesta <gandalf.corvotempesta at gmail.com>:> Shouldn't gluster increase the image size?This morning i've checked the image size and it was properly increased. So, gluster is able to increase (by adding shards) the VM image only when needed, right? I've started with a 100GB qcow2 image that was preallocated by gluster (1600 shards created, 64MB each) even if the qcow2 image was only a couple of GB (a debian minimal install) then I've increased the image to 150GB, nothing changed. I've created a huge file (120GB) with random content and this morning the stored file was increased up to 133GB
On Thu, Sep 29, 2016 at 12:02:39AM +0200, Gandalf Corvotempesta wrote:> I'm doing some tests with proxmox. > I've created a test VM with 100GB qcow2 image stored on gluster with sharding > All shards was created properly. > > Then, I've increased the qcow2 image size from 100GB to 150GB. > Proxmox did this well, but on gluster i'm still seeing the old qcow2 > image size (1600 shard, 64MB each)We do this sort of things a lot, with the same setup, and never had a problem I never checked the file size though, but I don't see any reason it wouldn't work with you :). We are using 3.7.12 and 3.7.15 though, didn't try 3.8 yet. -- Kevin Lemonnier PGP Fingerprint : 89A5 2283 04A0 E6E9 0111 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20160930/15469cf3/attachment.sig>