Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: domain of mike.tutkowski@solidfire.com
 designates 209.85.214.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CACOnxCiYp6e-TDBTSbLuRRZMj_+JbPijLgR1__f58jtzoy2nfA@mail.gmail.com>
References: 
 <CACOnxCiYp6e-TDBTSbLuRRZMj_+JbPijLgR1__f58jtzoy2nfA@mail.gmail.com>
Date: Sat, 25 Jan 2014 00:47:03 -0700
Message-ID: 
 <CACOnxCi4dqsQA7Db1XxGcyw5PLC9CVvzK4vwj1MbdAUrZ5qKag@mail.gmail.com>
Subject: Re: Root-disk support for managed storage
From: Mike Tutkowski <mike.tutkowski@solidfire.com>
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>,
 Edison Su <edison.su@citrix.com>,
	Marcus Sorensen <shadowsor@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c30fac2c996404f0c6ae6a

--001a11c30fac2c996404f0c6ae6a
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Just wanted to throw this out there before I went to bed:

Since each root volume that belongs to managed storage will get its own
copy of some template (assuming we're dealing with templates here and not
an ISO), it is possible I may be able to circumvent a new table (or any
existing table like template_spool_ref) entirely for managed storage.

The purpose of a table like template_spool_ref appears to be mainly to make
sure we're not downloading the sample template to an SR multiple times (and
this doesn't apply in the case of managed storage since each root volume
should have at most one template downloaded to it).

Thoughts on that?

Thanks!


On Sat, Jan 25, 2014 at 12:39 AM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> Hi Edison and Marcus (and anyone else this may be of interest to),
>
> So, as of 4.3 I have added support for data disks for managed storage for
> XenServer, VMware, and KVM (a 1:1 mapping between a CloudStack volume and=
 a
> volume on a storage system). One of the most useful abilities this enable=
s
> is support for guaranteed storage quality of service in CloudStack.
>
> One of the areas I'm working on for CS 4.4 is root-disk support for
> managed storage (both with templates and ISOs).
>
> I'd like to get your opinion about something.
>
> I noticed when we download a template to a XenServer SR that we leverage =
a
> table in the DB called template_spool_ref.
>
> This table keeps track of whether or not we've downloaded the template in
> question to the SR in question already.
>
> The problem for managed storage is that the storage pool itself can be
> associated with many SRs (not all necessarily in the same cluster even):
> one SR per volume that belongs to the managed storage.
>
> What this means is every time a user wants to place a root disk (that use=
s
> a template) on managed storage, I will need to download a template to the
> applicable SR (the template will never be there in advance).
>
> That is fine. The issue is that I cannot use the template_spool_ref table
> because it is intended on mapping a template to a storage pool (1:1 mappi=
ng
> between the two) and managed storage can download the same template many
> times.
>
> It seems I will need to add a new table to the DB to support this feature=
.
>
> My table would allow a mapping between a template and a volume from
> managed storage.
>
> Do you see an easier way around this or is this how you recommend I
> proceed?
>
> 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<http://solidfire.com/solution/=
overview/?video=3Dplay>
> *=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<http://solidfire.com/solution/overview/?video=3Dplay>
*=99*

--001a11c30fac2c996404f0c6ae6a--