cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: SolidFire Plugin - Weird Behavior
Date Fri, 22 Aug 2014 16:42:17 GMT
As an FYI, the reason this still works for "traditional" (so-called
non-managed) primary storage in CloudStack on XenServer is that those
environments put many CloudStack root and data disks on the same backend
SAN volume (or NFS share).

Even if the size of the root disk is incorrectly specified, if there is
space remaining on the storage repository where the template gets copied
to, the process will still work.

In the case of plug-ins that support managed storage (examples would be
SolidFire and CloudByte), they will dynamically create a backend volume to
support the CloudStack root disk. If the metric regarding size of the root
disk is incorrect, these plug-ins can make backend volumes that are too
small (or too large, but too large is less noticeable of an issue).


On Fri, Aug 22, 2014 at 10:27 AM, Francois Gaudreault <
fgaudreault@cloudops.com> 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 <
>> 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_
>
>


-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message