Return-Path: X-Original-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1CF15E4AC for ; Thu, 7 Feb 2013 23:06:30 +0000 (UTC) Received: (qmail 39095 invoked by uid 500); 7 Feb 2013 23:06:29 -0000 Delivered-To: apmail-incubator-cloudstack-dev-archive@incubator.apache.org Received: (qmail 39064 invoked by uid 500); 7 Feb 2013 23:06:29 -0000 Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list cloudstack-dev@incubator.apache.org Received: (qmail 39055 invoked by uid 99); 7 Feb 2013 23:06:29 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 Feb 2013 23:06:29 +0000 X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_SOFTFAIL X-Spam-Check-By: apache.org Received-SPF: softfail (athena.apache.org: transitioning domain of mike.tutkowski@solidfire.com does not designate 209.85.219.52 as permitted sender) Received: from [209.85.219.52] (HELO mail-oa0-f52.google.com) (209.85.219.52) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 Feb 2013 23:06:25 +0000 Received: by mail-oa0-f52.google.com with SMTP id k14so3363308oag.25 for ; Thu, 07 Feb 2013 15:06:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=rfXiTLhhkhNnrlfeaxXvxP4SFTbnVAdvvt6bYKa/vCM=; b=cF1PdtyQH6pzMTrokiqfiILD6K9blz3F+EftAsSOwFtXUVHtXA8TG4cCyCfA7FQ/+D Rly+hi7EeKT4W0XJH19YB+Hc5z3ul+ycgx9lAhjLhCSNMRFsCIFFGzvEkETqUpmRe1Ut j9unh56+gM5C1a54VYcYuawOgewwfRGwuooreG9LNDqX0/xb4kQFPRqg2Cfu1AMs/QZm tjONNg4dCRe8FLPM5ugDFwI3rx43DnqCAS3rDxQEL9kiwTbCdpr0uv9Pag5TBOOlNX00 IoJkbbENpuLFTfPvqonbUN2YkU4M/gRMK9fTSY3icv7Lga4rIJqd501Gwy5+WZ95whlI HIBQ== MIME-Version: 1.0 X-Received: by 10.182.2.132 with SMTP id 4mr2625945obu.42.1360278363657; Thu, 07 Feb 2013 15:06:03 -0800 (PST) Received: by 10.182.49.202 with HTTP; Thu, 7 Feb 2013 15:06:03 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Feb 2013 16:06:03 -0700 Message-ID: Subject: Re: Supporting SolidFire QoS Before 4.2 From: Mike Tutkowski To: Edison Su Cc: "cloudstack-dev@incubator.apache.org" , Marcus Sorensen Content-Type: multipart/alternative; boundary=f46d044519d9a954fa04d52a7cb6 X-Gm-Message-State: ALoCoQkGrj2s1YvN1eIsCj6XUBHDB4ki7xVuHYaKV8mtz2H/NL7fYGfWHBbe+a+3vNANCSm+FCv6 X-Virus-Checked: Checked by ClamAV on apache.org --f46d044519d9a954fa04d52a7cb6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Edison, I'm not sure I entirely follow. Creating the volume (LUN) on our SAN is straightforward enough. We'd get back an IQN. Are you saying at this point I'd talk to, say, XenServer and have it create a storage repository that makes use of the iSCSI target (my IQN)? If so, once that is done, I was thinking I'd update a known (PreSetup-based) Primary Storage's Storage Tag. After, I'd update the single Compute Offering that references that Primary Storage by changing its Storage Tag to be equal to that of my Primary Storage. Once this is done, the VM could be spun up from the Compute Offering (and underlying Primary Storage). When the VM Instance is up and running, the Compute Offering's and Primary Storage's Storage Tag could be changed back to some expected value. I don't particularly like this solution in the sense that you can't kick off such a new Compute Offering until the one before it was done, but it would only serve as a temporary measure to help customers leverage our QoS feature. What do you think? Does this sound doable with the CS API? On Thu, Feb 7, 2013 at 3:55 PM, Edison Su wrote: > Another solution would be, totally bypass cloudstack and hypervisor, > create LUN in your storage box, then give the IQN to guest VM. Inside gue= st > VM, there may have a script, which can grab that IQN from somewhere(can b= e > in user data), then scan iSCSI, mount the device, etc. It can work with a= ll > the hypervisors.**** > > ** ** > > *From:* Mike Tutkowski [mailto:mike.tutkowski@solidfire.com] > *Sent:* Thursday, February 07, 2013 11:18 AM > *To:* cloudstack-dev@incubator.apache.org; Edison Su; Marcus Sorensen > > *Subject:* Supporting SolidFire QoS Before 4.2**** > > ** ** > > Hi everyone,**** > > ** ** > > I learned yesterday that Edison's new storage plug-in architecture will > first be released with 4.2.**** > > ** ** > > As such, I began to wonder if there was any way outside of CloudStack tha= t > I could support CloudStack users who want to make use of SolidFire's QoS > feature (controlling IOPS).**** > > ** ** > > A couple of us brainstormed for a bit and this is what we came up with. > Can anyone confirm if this could work?**** > > ** ** > > ************************ > > ** ** > > The CloudStack Admin creates a Primary Storage that is of the type > PreSetup. This is tagged with a name like "SolidFire_High" (for SolidFir= e > High IOPS).**** > > ** ** > > The CloudStack Admin creates a Compute Offering that refers to the > "SolidFire_High" Storage Tag.**** > > ** ** > > In the CSP's own GUI, a user picks the Compute Offering referred to above= . > The CSP's code sees the Storage Tag "SolidFire_High" and that cues it to > invoke a script of mine.**** > > ** ** > > My script is passed in the necessary information. It creates a SolidFire > volume with the necessary attributes and hooks it up to the hypervisor > running in the Cluster. It updates my Primary Storage's Tag with the IQN > (or some unique identifier), then it updates my Compute Offering's Storag= e > Tag with this same value.**** > > ** ** > > Once the Primary Storage and the Compute Offering have been updated, > CloudStack can begin the process of creating a VM Instance.**** > > ** ** > > Once the VM Instance is up and running, the CSP's GUI could set the > Primary Storage's and Compute Offering's Storage Tags back to the > "SolidFire_High" value.**** > > ** ** > > ************************ > > ** ** > > The one problem I see with this is that you would have to be sure not to > kick off the process of creating such a Compute Offering until your > previous such Compute Offering was finished (because there is a race > condition while the Storage Tag field points to the IQN (or some other > unique identifier)).**** > > ** ** > > Thanks! > **** > > ** ** > > -- > *Mike Tutkowski***** > > *Senior CloudStack Developer, SolidFire Inc.***** > > e: mike.tutkowski@solidfire.com**** > > o: 303.746.7302**** > > Advancing the way the world uses the cloud > *=99***** > --=20 *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkowski@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud *=99* --f46d044519d9a954fa04d52a7cb6--