Well there we go. 'the more you know...'
On Fri, Dec 7, 2012 at 4:33 PM, Marcus Sorensen wrote:
> There already is backing qcow2 support. But when cloudstack moves the
> template from secondary to primary storage to use as a backing file for all
> of your VMs, it does a convert. That strips any
There already is backing qcow2 support. But when cloudstack moves the
template from secondary to primary storage to use as a backing file for all
of your VMs, it does a convert. That strips any snapshots or compression
that an uploader may have been counting on, and is overall slower than just
copy
--Original Message-
> > From: Marcus Sorensen [mailto:shadow...@gmail.com]
> > Sent: Wednesday, December 05, 2012 1:01 PM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: Re: qemu-img convert a qcow2 to a qcow2
> >
> > Eventually we'll probably w
udstack-dev@incubator.apache.org
> Subject: Re: qemu-img convert a qcow2 to a qcow2
>
> Eventually we'll probably want to support multiple versions, replacing one or
> both of the formats with variables, but even then we'll probably just want to
> copy if source format == destinat
Eventually we'll probably want to support multiple versions, replacing one
or both of the formats with variables, but even then we'll probably just
want to copy if source format == destination format.
On Wed, Dec 5, 2012 at 1:51 PM, Rohit Yadav wrote:
>
> On 05-Dec-2012, at 12:17 PM, Marcus Sor
On 05-Dec-2012, at 12:17 PM, Marcus Sorensen wrote:
> Anyone know why we do a convert from qcow2 to qcow2 when we crete a volume
> or template? It seems slower than file copy, and it strips valuable
> compression which could speed up deployments significantly. Our qcow2
> templates are compresse
Anyone know why we do a convert from qcow2 to qcow2 when we crete a volume
or template? It seems slower than file copy, and it strips valuable
compression which could speed up deployments significantly. Our qcow2
templates are compressed to about 1/3 size of uncompressed, and since the
compression
