You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Francois Gaudreault <fg...@cloudops.com> on 2014/08/22 17:39:35 UTC
SolidFire Plugin - Weird Behavior
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
CloudOps Votre partenaire infonuagique | Cloud Solutions Experts
420 rue Guy | Montreal | Quebec | H3J 1S6
w: cloudops.com | tw: @CloudOps_
Re: SolidFire Plugin - Weird Behavior
Posted by Mike Tutkowski <mi...@solidfire.com>.
Just to clarify: "Mark" is really me: "Mike" :)
I give Daan a hard time about this. :) He called me Mark at CCCEU in Denver
a few times during a presentation and it seems like that's been like a
second name for me.
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 <ma...@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 <ma...@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>*™*
Re: SolidFire Plugin - Weird Behavior
Posted by Mike Tutkowski <mi...@solidfire.com>.
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 <
fgaudreault@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 <
>>> fgaudreault@cloudops.com <ma...@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 <ma...@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>*™*
Re: SolidFire Plugin - Weird Behavior
Posted by Francois Gaudreault <fg...@cloudops.com>.
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
>> <fgaudreault@cloudops.com <ma...@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 <ma...@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_
Re: SolidFire Plugin - Weird Behavior
Posted by Mike Tutkowski <mi...@solidfire.com>.
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 <ma...@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 <ma...@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>*™*
Re: SolidFire Plugin - Weird Behavior
Posted by Francois Gaudreault <fg...@cloudops.com>.
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 <ma...@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 <ma...@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_
Re: SolidFire Plugin - Weird Behavior
Posted by Mike Tutkowski <mi...@solidfire.com>.
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> 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
>
> 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>*™*
Re: SolidFire Plugin - Weird Behavior
Posted by Francois Gaudreault <fg...@cloudops.com>.
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
CloudOps Votre partenaire infonuagique | Cloud Solutions Experts
420 rue Guy | Montreal | Quebec | H3J 1S6
w: cloudops.com | tw: @CloudOps_