cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edison Su <>
Subject RE: S3/Swift Problem around Virtual Size
Date Fri, 22 Aug 2014 21:19:59 GMT
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
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 []
Sent: Friday, August 22, 2014 1:38 PM
Cc: Edison Su
Subject: S3/Swift Problem around Virtual Size


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:


Mike Tutkowski
Senior CloudStack Developer, SolidFire Inc.
o: 303.746.7302
Advancing the way the world uses the cloud<>™
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message