cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francois Gaudreault <fgaudrea...@cloudops.com>
Subject Re: SolidFire Plugin - Weird Behavior
Date Fri, 22 Aug 2014 16:27:02 GMT
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 
> <fgaudreault@cloudops.com <mailto:fgaudreault@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.tutkowski@solidfire.com <mailto:mike.tutkowski@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_


Mime
View raw message