Return-Path: 
 <dev-return-63216-apmail-cloudstack-dev-archive=cloudstack.apache.org@cloudstack.apache.org>
X-Original-To: apmail-cloudstack-dev-archive@www.apache.org
Delivered-To: apmail-cloudstack-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id CD49811A5C
	for <apmail-cloudstack-dev-archive@www.apache.org>;
 Fri, 22 Aug 2014 15:44:46 +0000 (UTC)
Received: (qmail 10773 invoked by uid 500); 22 Aug 2014 15:44:46 -0000
Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org
Received: (qmail 10720 invoked by uid 500); 22 Aug 2014 15:44:46 -0000
Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@cloudstack.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@cloudstack.apache.org>
List-Post: <mailto:dev@cloudstack.apache.org>
List-Id: <dev.cloudstack.apache.org>
Reply-To: dev@cloudstack.apache.org
Delivered-To: mailing list dev@cloudstack.apache.org
Received: (qmail 10703 invoked by uid 99); 22 Aug 2014 15:44:46 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Aug 2014 15:44:46 +0000
X-ASF-Spam-Status: No, hits=-0.7 required=5.0
	tests=RCVD_IN_DNSWL_LOW
X-Spam-Check-By: apache.org
Received-SPF: unknown (athena.apache.org: error in processing during lookup of
 fgaudreault@cloudops.com)
Received: from [209.85.213.176] (HELO mail-ig0-f176.google.com)
 (209.85.213.176)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Aug 2014 15:44:41 +0000
Received: by mail-ig0-f176.google.com with SMTP id hn18so15121228igb.9
        for <dev@cloudstack.apache.org>; Fri, 22 Aug 2014 08:44:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:message-id:date:from:reply-to:user-agent
         :mime-version:to:cc:subject:references:in-reply-to:content-type
         :content-transfer-encoding;
        bh=pUlFqv75zNXRKi5y/ktBUBzsROS4laIesG/EAyTpiYc=;
        b=YDxQF8/3YBqK46s5lkwgxl+GKU5ESXTFNkVifZCFluJ4k4TcPRVP1oX+vKwHV7b+PA
         YZpy5I/rOzhqOIXYhDpN3DCUjM+sXJVnXm60m2Lz7UjN9CIuey7CXlBRoVpczlWhR+17
         6zTwZ0Rczqt5ax8fnGCt2vawVNNcxBrJp1/yTYIGl84P5fAQVMULItXVhHwYgxa0a0Qz
         sK32BOefwBuLYWYSFiLyb8zbmFQ7k4qCAyNlnGTv+ySnr7IBtJxR3nw5wtJvIqtY0eN/
         y0mWRFCY/M3U9qd4LRf+zrumX+yUoFmJHNg+84If9ySZHfEjYyptQLOcnIFbHbMzitf4
         jfIg==
X-Gm-Message-State: 
 ALoCoQmxD72rEbWuzRW3cRcgWIuFuU/zNQiKSDmPurf2lygHxmvGeVz7DvO8lIHZ+S9LnjcNW/f6
X-Received: by 10.43.140.193 with SMTP id jb1mr10332669icc.15.1408722260782;
        Fri, 22 Aug 2014 08:44:20 -0700 (PDT)
Received: from Francoiss-MacBook-Pro-3.local ([38.108.74.28])
        by mx.google.com with ESMTPSA id
 qq2sm38765540igb.19.2014.08.22.08.44.19
        for <multiple recipients>
        (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
        Fri, 22 Aug 2014 08:44:20 -0700 (PDT)
Message-ID: <53F7657A.7010903@cloudops.com>
Date: Fri, 22 Aug 2014 11:44:58 -0400
From: Francois Gaudreault <fgaudreault@cloudops.com>
Reply-To: fgaudreault@cloudops.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
CC: Mike Tutkowski <mike.tutkowski@solidfire.com>
Subject: Re: SolidFire Plugin - Weird Behavior
References: <53F76437.9000703@cloudops.com>
In-Reply-To: <53F76437.9000703@cloudops.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

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_