I forgot to say that this was noticed with 4.4 (but is probably an earlier issue).
On Fri, Aug 22, 2014 at 2:38 PM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > Hi, > > This was brought up in a different e-mail thread, but I wanted to make it > more clear that it's related to CloudStack's download code around S3/Swift, > so I'm opening up a new thread. > > Francois (from CloudOps) noticed today that when he downloaded a template > (VHD format) to Swift (but it looks like the same applies for S3) that the > physical and virtual sizes are set to be the same. > > This appears to have the following consequence: > > You can download a template with a physical size of, say, 3 GB and a root > disk that's supposed to be, say, 20 GB. Instead of the virtual size showing > as 20 GB, it shows as 3 GB. > > This is not an issue with NFS. In that situation, the two sizes are > correctly accounted for. > > What later can happen is the template is downloaded from Swift and takes > up an unexpected amount of space on the XenServer storage repository (SR). > > If there is enough space on the SR, this isn't too big of a deal. However, > for so-called managed storage plug-ins (examples are SolidFire and > CloudByte), this will lead to them dynamically creating a SAN volume of the > wrong size. > > Francois opened up the following ticket: > > https://issues.apache.org/jira/browse/CLOUDSTACK-7406 > > Thanks! > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkow...@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the cloud > <http://solidfire.com/solution/overview/?video=play>*™* > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud <http://solidfire.com/solution/overview/?video=play>*™*
