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.tutkow...@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 <shadow...@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.tutkow...@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 <shadow...@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 <shadow...@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.tutkow...@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.tutkow...@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.tutkow...@solidfire.com >> >> >>> o: 303.746.7302 >> >> >>> Advancing the way the world uses the cloud™ >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Mike Tutkowski >> >> >> Senior CloudStack Developer, SolidFire Inc. >> >> >> e: mike.tutkow...@solidfire.com >> >> >> o: 303.746.7302 >> >> >> Advancing the way the world uses the cloud™ >> > >> > >> > >> > >> > -- >> > Mike Tutkowski >> > Senior CloudStack Developer, SolidFire Inc. >> > e: mike.tutkow...@solidfire.com >> > o: 303.746.7302 >> > Advancing the way the world uses the cloud™ >> > > > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkow...@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.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *™*
