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.
Thanks -min On 8/22/14 2:25 PM, "Francois Gaudreault" <fgaudrea...@cloudops.com> wrote: >Edison, > >Isnt the templates downloaded to the Staging NFS first? > >FG >On Aug 22, 2014 5:20 PM, "Edison Su" <edison...@citrix.com> 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 >>through >> 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 >>mgt >> server. >> In order to fix it, we can add some code as: all the templates >>registered >> on Swift/S3, need to be downloaded to a NFS intermediate storage before >>it >> 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 >>etc. >> >> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] >> Sent: Friday, August 22, 2014 1:38 PM >> To: dev@cloudstack.apache.org >> 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 >>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<mailto:mike.tutkow...@solidfire.com> >> o: 303.746.7302 >> Advancing the way the world uses the cloud< >> http://solidfire.com/solution/overview/?video=play> >>
