I've CCed Edison on this. I think he has a bunch of experience with S3 and Swift integration into CloudStack.
On Fri, Aug 22, 2014 at 11:46 AM, Francois Gaudreault < fgaudrea...@cloudops.com> wrote: > Ok. I digged a little more, and now I know why it fails, but don't know > how to fix this :) I opened a defect: > https://issues.apache.org/jira/browse/CLOUDSTACK-7406 > > To me this is a fairly important one since is does have impacts on other > features (e.g SF storage plugin, and maybe usage reporting). > > FG > > > On 2014-08-22, 12:27 PM, Francois Gaudreault wrote: > >> Mark and I worked on that off-list, and it looks like it's a Swift >> provider issue. See, in ACS, when you use NFS, the reported template size >> is the ROOT volume size. While using swift, it's the VHD file size, which >> is not the ROOT volume size. >> >> SolidFire will rely on this metric to create the LUN for this VM. >> >> So, any idea why the Swift provider is NOT getting us the right >> information? :) >> >> FG >> >> >> On 2014-08-22, 11:47 AM, Mike Tutkowski wrote: >> >>> Hi Francois, >>> >>> Interesting...all of my tests on XS 6.1 and 6.2 check out just fine (but >>> that is with CS 4.4). >>> >>> I'll contact you off list and we can work this out. >>> >>> Thanks, >>> Mike >>> >>> >>> On Fri, Aug 22, 2014 at 9:44 AM, Francois Gaudreault < >>> fgaudrea...@cloudops.com <mailto:fgaudrea...@cloudops.com>> wrote: >>> >>> I would also add that the ROOT volume created stayed on the SF >>> cluster, even if the VM creation failed. That's also a problem, >>> although I believe the "storage garbage collector" would delete it? >>> >>> FG >>> >>> >>> On 2014-08-22, 11:39 AM, Francois Gaudreault wrote: >>> >>> Hi Mike, >>> >>> I tryed the SolidFire plugin on 4.4.1, and I don't think the >>> behavior is right for the ROOT volume. Tried on XenServer 6.2. >>> >>> First, I am using a template with technically a 20GB space, >>> but the storage plugin will create the volume only according >>> to the size of the vhd (which is 3GB). This is wrong :) >>> >>> Second, the creation fails with a XenServer error saying there >>> is not enough space to copy the VDI: >>> >>> 2014-08-22 11:25:44,417 WARN [c.c.h.x.r.CitrixResourceBase] >>> (DirectAgent-249:ctx-81a37f3b) Task failed! Task record: >>> uuid: b7cf8b1d-d9d9-c2c0-aba0-7368c181a2cb >>> nameLabel: Async.VDI.copy >>> nameDescription: >>> allowedOperations: [] >>> currentOperations: {} >>> created: Fri Aug 22 11:25:43 EDT 2014 >>> finished: Fri Aug 22 11:25:43 EDT 2014 >>> status: failure >>> residentOn: com.xensource.xenapi.Host@a7913c69 >>> progress: 1.0 >>> type: <none/> >>> result: >>> errorInfo: [SR_BACKEND_FAILURE_44, , There is >>> insufficient space] >>> otherConfig: {} >>> subtaskOf: com.xensource.xenapi.Task@aaf13f6f >>> subtasks: [] >>> >>> Should we also have a SR to handle template copy? >>> >>> Thanks! >>> >>> >>> >>> -- Francois Gaudreault >>> Gestionnaire de Produit | Product Manager - Cloud Platform & Services >>> t:514-629-6775 <tel:514-629-6775> >>> >>> CloudOps Votre partenaire infonuagique | Cloud Solutions Experts >>> 420 rue Guy | Montreal | Quebec | H3J 1S6 >>> w: cloudops.com <http://cloudops.com> | tw: @CloudOps_ >>> >>> >>> >>> >>> -- >>> *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>/™/ >>> >> >> >> > > -- > Francois Gaudreault > Gestionnaire de Produit | Product Manager - Cloud Platform & Services > t:514-629-6775 > > CloudOps Votre partenaire infonuagique | Cloud Solutions Experts > 420 rue Guy | Montreal | Quebec | H3J 1S6 > w: cloudops.com | tw: @CloudOps_ > > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud <http://solidfire.com/solution/overview/?video=play>*™*
