But you'd be registering a new SR. It doesn't matter that the original volume is read-only (in fact it should be, both in name and data), because your clones will be new SRs.
On Sun, Jan 26, 2014 at 9:17 AM, Mike Tutkowski <mike.tutkow...@solidfire.com> wrote: > Here's a pic that shows some of the properties of an SR: > > http://i.imgur.com/iq6NQ1a.png > > According to some Citrix docs I read, it appears the UUID is a read-only > field. > > Unless there is some workaround for this, I may have to resort to copying > the template to a new SR each time. > > > On Sun, Jan 26, 2014 at 9:00 AM, Mike Tutkowski > <mike.tutkow...@solidfire.com> wrote: >> >> Hey Marcus, >> >> One thing I thought of late last night was that an SR has a UUID >> associated with it. >> >> If I clone the SAN volume that houses the SR each time, I'll be giving >> XenServer SRs that have the same UUID. >> >> I guess I'll need to look into if there is some way to assign a new UUID >> to an existing SR. >> >> Perhaps you or Edison (or someone else) know about this off hand? >> >> Thanks >> >> >> On Sat, Jan 25, 2014 at 11:42 PM, Mike Tutkowski >> <mike.tutkow...@solidfire.com> wrote: >>> >>> Yeah, I see that now. I was thinking my situation here would be different >>> because in the XenServer case I was looking at, CloudStack was copying the >>> template down to an SR and that same SR was later used to also house the >>> root disk (two different SRs were not involved). >>> >>> Even though my case is different, with the approach you outlined about >>> creating a "special" SR for the template itself, it ends up amounting to a >>> similar concept. >>> >>> >>> On Sat, Jan 25, 2014 at 11:27 PM, Marcus Sorensen <shadow...@gmail.com> >>> wrote: >>>> >>>> Yes. That's what all of the storage types do, they save the name of >>>> the file, volume, etc (along with path if necessary) on primary >>>> storage where the template is copied. >>>> >>>> On Sat, Jan 25, 2014 at 11:01 PM, Mike Tutkowski >>>> <mike.tutkow...@solidfire.com> wrote: >>>> > It looks like I could use the template_spool_ref table's local path >>>> > and/or >>>> > install path to point to the name of the volume on the SAN that is to >>>> > be >>>> > cloned when we need a root volume from this template. >>>> > >>>> > Is that what you do? >>>> > >>>> > >>>> > On Sat, Jan 25, 2014 at 10:46 PM, Mike Tutkowski >>>> > <mike.tutkow...@solidfire.com> wrote: >>>> >> >>>> >> Maybe 2) can be made to work in the template_spool_ref table...I need >>>> >> to >>>> >> think about it a bit. >>>> >> >>>> >> >>>> >> On Sat, Jan 25, 2014 at 10:42 PM, Mike Tutkowski >>>> >> <mike.tutkow...@solidfire.com> wrote: >>>> >>> >>>> >>> Data disks are easier than root disks. >>>> >>> >>>> >>> To be more clear, I should say data disks are easier than root disks >>>> >>> that >>>> >>> use templates (root disks that use ISOs are about the same level of >>>> >>> difficulty as data disks). >>>> >>> >>>> >>> I could see it going either way: >>>> >>> >>>> >>> 1) Copy the template down once for each root disk >>>> >>> >>>> >>> or >>>> >>> >>>> >>> 2) Copy the template to an SR and clone the SAN volume the SR is on >>>> >>> as >>>> >>> needed >>>> >>> >>>> >>> 2) has the advantage of speed, but where do you store knowledge of >>>> >>> this >>>> >>> special SR (in the DB somewhere)? >>>> >>> >>>> >>> >>>> >>> On Sat, Jan 25, 2014 at 10:39 PM, Mike Tutkowski >>>> >>> <mike.tutkow...@solidfire.com> wrote: >>>> >>>> >>>> >>>> Do you still send your SAN commands from the KVM agent? >>>> >>>> >>>> >>>> I don't have any SolidFire-specific commands outside of the >>>> >>>> SolidFire >>>> >>>> plug-in. >>>> >>>> >>>> >>>> >>>> >>>> On Sat, Jan 25, 2014 at 10:38 PM, Marcus Sorensen >>>> >>>> <shadow...@gmail.com> >>>> >>>> wrote: >>>> >>>>> >>>> >>>>> Actually, I shouldn't take the liberty to speak as though I >>>> >>>>> understand >>>> >>>>> the details about how you use SRs and VDIs. My point though is >>>> >>>>> basically that you probably can and should treat them the same as >>>> >>>>> whatever you currently do with data disks. Either create a new one >>>> >>>>> with every root volume create and copy the template contents to it >>>> >>>>> (like CLVM does), or create one on the SAN when the template copy >>>> >>>>> is >>>> >>>>> called, prepopulate it with the template, and send a clone command >>>> >>>>> against that one to your storage to generate new root disks as >>>> >>>>> needed. >>>> >>>>> >>>> >>>>> On Sat, Jan 25, 2014 at 10:30 PM, Marcus Sorensen >>>> >>>>> <shadow...@gmail.com> >>>> >>>>> wrote: >>>> >>>>> > 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™ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> 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™ >>> >>> >>> >>> >>> -- >>> 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™
