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