cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Min Chen <>
Subject Re: S3/Swift Problem around Virtual Size
Date Fri, 22 Aug 2014 21:28:23 GMT
No. For S3/Swift, register template will directly upload templates to S3
without going through staging NFS. It will only be copied to staging NFS
when we first use that template to provision a VM.


On 8/22/14 2:25 PM, "Francois Gaudreault" <> wrote:

>Isnt the templates downloaded to the Staging NFS first?
>On Aug 22, 2014 5:20 PM, "Edison Su" <> wrote:
>> I know the reason why the size of template doesn¹t have correct virtual
>> size if it¹s registered in S3/Swift:
>> In case of s3/swift, the template is directly stored into s3/swift
>> swift/s3 api, there is no place for cloudstack to look into template, to
>> find out the virtual size during template registration.
>> While, if secondary storage is NFS, the template is first stored on
>> NFS(which has file system), cloudstack can unzip the template(if it¹s a
>> zipped file), and read virtual size from the file, then report back to
>> server.
>> In order to fix it, we can add some code as: all the templates
>> on Swift/S3, need to be downloaded to a NFS intermediate storage before
>> can be consumed by primary storage. After the download finished, then we
>> check virtual size of template, and report back to mgt server/update DB
>> From: Mike Tutkowski []
>> Sent: Friday, August 22, 2014 1:38 PM
>> To:
>> Cc: Edison Su
>> Subject: S3/Swift Problem around Virtual Size
>> Hi,
>> This was brought up in a different e-mail thread, but I wanted to make
>> more clear that it's related to CloudStack's download code around
>> so I'm opening up a new thread.
>> Francois (from CloudOps) noticed today that when he downloaded a
>> (VHD format) to Swift (but it looks like the same applies for S3) that
>> 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
>> disk that's supposed to be, say, 20 GB. Instead of the virtual size
>> 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
>> If there is enough space on the SR, this isn't too big of a deal.
>> for so-called managed storage plug-ins (examples are SolidFire and
>> CloudByte), this will lead to them dynamically creating a SAN volume of
>> wrong size.
>> Francois opened up the following ticket:
>> Thanks!
>> --
>> Mike Tutkowski
>> Senior CloudStack Developer, SolidFire Inc.
>> e:<>
>> o: 303.746.7302
>> Advancing the way the world uses the cloud<

View raw message