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>™ >
