And when I say 'the first time the template is used, we create an SR', I mean cloudstack does it automatically.
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™
