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: Root-disk support for managed storage
Date Sun, 26 Jan 2014 05:36:11 GMT
So, Marcus - it sounds like you already have this kind of functionality
working in KVM?

Perhaps it would be a good idea for me to look at it.

Thanks!


On Sat, Jan 25, 2014 at 10:33 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> 2) This is cloning the SAN volume that stores the SR in 1).
>
> 3) This is to use the SR on the cloned volume.
>
>
> On Sat, Jan 25, 2014 at 10:31 PM, Mike Tutkowski <
> mike.tutkowski@solidfire.com> wrote:
>
>> I see, Marcus. That is an interesting idea definitely.
>>
>> The process would be on a cluster-by-cluster basis:
>>
>> 1) Download the template to the SR.
>>
>> 2) Clone the SAN volume.
>>
>> 3) Use the new SR.
>>
>> Later for a new root disk:
>>
>> Just do 3.
>>
>>
>>  On Sat, Jan 25, 2014 at 10:29 PM, Marcus Sorensen <shadowsor@gmail.com>wrote:
>>
>>> Not's not really what I was describing, or that's not how we do it at
>>> least. The first time a template is used, we create an SR with one VDI
>>> (using your terminology as we don't do it in Xen, but it should map to
>>> essentially the same thing) and copy the template contents into it.
>>> Then we remove the SR. When a root disk is requested, we send a clone
>>> command to the SAN, and then register the new clone as a new volume,
>>> then attach that as a new SR dedicated to that root volume. Every root
>>> disk that makes use of that template is its own SR.
>>>
>>> On Sat, Jan 25, 2014 at 9:30 PM, Mike Tutkowski
>>> <mike.tutkowski@solidfire.com> wrote:
>>> > Thanks for your input, Marcus.
>>> >
>>> > Yeah, the SolidFire SAN has the ability to clone, but I can't use it
>>> in this
>>> > case.
>>> >
>>> > Little note first: I'm going to put some words below in capital
>>> letters to
>>> > stress some important details. All caps for some words can be annoying
>>> to
>>> > some, so please understand that I am only using them here to highlight
>>> > important details. :)
>>> >
>>> > For managed storage (SolidFire is an example of this), this is what
>>> happens
>>> > when a user attaches a volume to a VM for the first time (so this is
>>> for
>>> > Disk Offerings...not root disks):
>>> >
>>> > 1) A volume (LUN) is created on the SolidFire SAN that is ONLY ever
>>> used by
>>> > this ONE CloudStack volume. This volume has QoS settings like Min,
>>> Max, and
>>> > Burst IOPS.
>>> >
>>> > 2) An SR is created in the XenServer resource pool (cluster) that
>>> makes use
>>> > of the SolidFire volume that was just created.
>>> >
>>> > 3) A VDI that represents the disk is created on the SR (this VDI
>>> essentially
>>> > consumes as much of the SR as it can*).
>>> >
>>> > If the user wants to create a new CloudStack volume to attach to a VM,
>>> that
>>> > leads to a NEW SolidFire volume being created (with its own QoS), a
>>> NEW SR,
>>> > and a new VDI inside of that SR.
>>> >
>>> > The same idea will exist for root volumes. A NEW SolidFire volume will
>>> be
>>> > created for it. A NEW SR will consume the SolidFire volume, and only
>>> ONE
>>> > root disk will EVER use this SR (so there is never a need to clone the
>>> > template we download to this SR).
>>> >
>>> > The next time a root disk of this type is requested, this leads to a
>>> NEW
>>> > SolidFire volume (with its own QoS), a NEW SR, and a new VDI.
>>> >
>>> > In the situation you describe (which is called non-managed (meaning
>>> the SR
>>> > was created ahead of time outside of CloudStack)), you can have
>>> multiple
>>> > root disks that leverage the same template on the same SR. This will
>>> never
>>> > be the case for managed storage, so there will never be a need for a
>>> > downloaded template to be cloned multiple times into multiple root
>>> disks.
>>> >
>>> > By the way, I just want to clarify, as well, that although I am
>>> talking in
>>> > terms of "SolidFire this an SolidFire that" that the functionality I
>>> have
>>> > been adding to CloudStack (outside of the SolidFire plug-in) can be
>>> > leveraged by any storage vendor that wants a 1:1 mapping between a
>>> > CloudStack volume and one of their volumes. This is, in fact, how
>>> OpenStack
>>> > handles storage by default.
>>> >
>>> > Does that clarify my question?
>>> >
>>> > I was not aware of how CLVM handled templates. Perhaps I should look
>>> into
>>> > that.
>>> >
>>> > By the way, I am currently focused on XenServer, but also plan to
>>> implement
>>> > support for this on KVM and ESX (although those may be outside of the
>>> scope
>>> > of 4.4).
>>> >
>>> > Thanks!
>>> >
>>> > * It consumes as much of the SR as it can unless you you want extra
>>> space
>>> > put aside for hypervisor snapshots.
>>> >
>>> >
>>> > On Sat, Jan 25, 2014 at 3:43 AM, Marcus Sorensen <shadowsor@gmail.com>
>>> > wrote:
>>> >>
>>> >> In other words, if you can't clone, then createDiskFromTemplate should
>>> >> copy template from secondary storage directly onto root disk every
>>> >> time, and copyPhysicalDisk really does nothing. If you can clone, then
>>> >> copyPhysicalDisk should copy template to primary, and
>>> >> createDiskFromTemplate should clone. Unless there's template cloning
>>> >> in the storage driver now, and if so put the createDiskFromTemplate
>>> >> logic there, but you still probably need copyPhysicalDisk to do its
>>> >> thing on the agent.
>>> >>
>>> >> This is all from a KVM perspective, of course.
>>> >>
>>> >> On Sat, Jan 25, 2014 at 3:40 AM, Marcus Sorensen <shadowsor@gmail.com
>>> >
>>> >> wrote:
>>> >> > I'm not quite following.  With our storage, the template gets copied
>>> >> > to the storage pool upon first use, and then cloned upon subsequent
>>> >> > uses. I don't remember all of the methods immediately, but there's
>>> one
>>> >> > called to copy the template to primary storage, and once that's
done
>>> >> > as you mention it's tracked in template_spool_ref and when root
>>> disks
>>> >> > are created that's passed as the source to copy when creating root
>>> >> > disks.
>>> >> >
>>> >> > Are you saying that you don't have clone capabilities to clone
the
>>> >> > template when root disks are created? If so, you'd be more like
CLVM
>>> >> > storage, where the template copy actually does nothing, and you
>>> >> > initiate a template copy *in place* of the clone (or you do a
>>> template
>>> >> > copy to primary pool whenever the clone normally would happen).
CLVM
>>> >> > creates a fresh root disk and copies the template from secondary
>>> >> > storage directly to that whenever a root disk is deployed, bypassing
>>> >> > templates altogether. This is because it can't efficiently clone,
>>> and
>>> >> > if we let the template copy to primary, it will then do a full
copy
>>> of
>>> >> > that template from primary to primary every time, which is pretty
>>> >> > heavy since it's also not thin provisioned.
>>> >> >
>>> >> > If you *can* clone, then just copy the template to your primary
>>> >> > storage as normal in your storage adaptor (copyPhysicalDisk), it
>>> will
>>> >> > be tracked in template_spool_ref, and then when root disks are
>>> created
>>> >> > it will be passed to createDiskFromTemplate in your storage adaptor
>>> >> > (for KVM), where you can call a clone of that and return it as
the
>>> >> > root volume . There was once going to be template clone capabilities
>>> >> > in the storage driver level on the mgmt server, but I believe that
>>> was
>>> >> > work-in-progress last I checked (4 months ago or so), so we still
>>> have
>>> >> > to call clone to our storage server from the agent side as of now,
>>> but
>>> >> > that call doesn't have to do any work on the agent-side, really.
>>> >> >
>>> >> >
>>> >> > On Sat, Jan 25, 2014 at 12:47 AM, Mike Tutkowski
>>> >> > <mike.tutkowski@solidfire.com> wrote:
>>> >> >> 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
>>> >> >>> enables
>>> >> >>> 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
>>> >> >>> uses
>>> >> >>> 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
>>> >> >>> mapping
>>> >> >>> 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™
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >> Mike Tutkowski
>>> >> >> Senior CloudStack Developer, SolidFire Inc.
>>> >> >> e: mike.tutkowski@solidfire.com
>>> >> >> o: 303.746.7302
>>> >> >> Advancing the way the world uses the cloud™
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Mike Tutkowski
>>> > Senior CloudStack Developer, SolidFire Inc.
>>> > e: mike.tutkowski@solidfire.com
>>> > o: 303.746.7302
>>> > Advancing the way the world uses the cloud™
>>>
>>
>>
>>
>> --
>> *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>
>> *™*
>>
>
>
>
> --
> *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>
> *™*
>



-- 
*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