Yeah, that would be ideal.
So, I would still need to discover the iSCSI target, log in to it, then
figure out what /dev/sdX was created as a result (and leave it as is - do
not format it with any file system...clustered or not). I would pass that
device into the VM.
Kind of accurate?
On Fri, Sep 13, 2013 at 8:07 PM, Marcus Sorensen <shadow...@gmail.com>wrote:
> Look in LibvirtVMDef.java (I think) for the disk definitions. There are
> ones that work for block devices rather than files. You can piggy back off
> of the existing disk definitions and attach it to the vm as a block device.
> The definition is an XML string per libvirt XML format. You may want to use
> an alternate path to the disk rather than just /dev/sdx like I mentioned,
> there are by-id paths to the block devices, as well as other ones that will
> be consistent and easier for management, not sure how familiar you are with
> device naming on Linux.
> On Sep 13, 2013 8:00 PM, "Marcus Sorensen" <shadow...@gmail.com> wrote:
>
>> No, as that would rely on virtualized network/iscsi initiator inside the
>> vm, which also sucks. I mean attach /dev/sdx (your lun on hypervisor) as a
>> disk to the VM, rather than attaching some image file that resides on a
>> filesystem, mounted on the host, living on a target.
>>
>> Actually, if you plan on the storage supporting live migration I think
>> this is the only way. You can't put a filesystem on it and mount it in two
>> places to facilitate migration unless its a clustered filesystem, in which
>> case you're back to shared mount point.
>>
>> As far as I'm aware, the xenserver SR style is basically LVM with a xen
>> specific cluster management, a custom CLVM. They don't use a filesystem
>> either.
>> On Sep 13, 2013 7:44 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com>
>> wrote:
>>
>>> When you say, "wire up the lun directly to the vm," do you mean
>>> circumventing the hypervisor? I didn't think we could do that in CS.
>>> OpenStack, on the other hand, always circumvents the hypervisor, as far as
>>> I know.
>>>
>>>
>>> On Fri, Sep 13, 2013 at 7:40 PM, Marcus Sorensen <shadow...@gmail.com>wrote:
>>>
>>>> Better to wire up the lun directly to the vm unless there is a good
>>>> reason not to.
>>>> On Sep 13, 2013 7:40 PM, "Marcus Sorensen" <shadow...@gmail.com>
>>>> wrote:
>>>>
>>>>> You could do that, but as mentioned I think its a mistake to go to the
>>>>> trouble of creating a 1:1 mapping of CS volumes to luns and then putting a
>>>>> filesystem on it, mounting it, and then putting a QCOW2 or even RAW disk
>>>>> image on that filesystem. You'll lose a lot of iops along the way, and
>>>>> have
>>>>> more overhead with the filesystem and its journaling, etc.
>>>>> On Sep 13, 2013 7:33 PM, "Mike Tutkowski" <
>>>>> mike.tutkow...@solidfire.com> wrote:
>>>>>
>>>>>> Ah, OK, I didn't know that was such new ground in KVM with CS.
>>>>>>
>>>>>> So, the way people use our SAN with KVM and CS today is by selecting
>>>>>> SharedMountPoint and specifying the location of the share.
>>>>>>
>>>>>> They can set up their share using Open iSCSI by discovering their
>>>>>> iSCSI target, logging in to it, then mounting it somewhere on their file
>>>>>> system.
>>>>>>
>>>>>> Would it make sense for me to just do that discovery, logging in, and
>>>>>> mounting behind the scenes for them and letting the current code manage
>>>>>> the
>>>>>> rest as it currently does?
>>>>>>
>>>>>>
>>>>>> On Fri, Sep 13, 2013 at 7:27 PM, Marcus Sorensen <shadow...@gmail.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Oh, hypervisor snapshots are a bit different. I need to catch up on
>>>>>>> the work done in KVM, but this is basically just disk snapshots + memory
>>>>>>> dump. I still think disk snapshots would preferably be handled by the
>>>>>>> SAN,
>>>>>>> and then memory dumps can go to secondary storage or something else.
>>>>>>> This
>>>>>>> is relatively new ground with CS and KVM, so we will want to see how
>>>>>>> others
>>>>>>> are planning theirs.
>>>>>>> On Sep 13, 2013 7:20 PM, "Marcus Sorensen" <shadow...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Let me back up and say I don't think you'd use a vdi style on an
>>>>>>>> iscsi lun. I think you'd want to treat it as a RAW format. Otherwise
>>>>>>>> you're
>>>>>>>> putting a filesystem on your lun, mounting it, creating a QCOW2 disk
>>>>>>>> image,
>>>>>>>> and that seems unnecessary and a performance killer.
>>>>>>>>
>>>>>>>> So probably attaching the raw iscsi lun as a disk to the VM, and
>>>>>>>> handling snapshots on the San side via the storage plugin is best. My
>>>>>>>> impression from the storage plugin refactor was that there was a
>>>>>>>> snapshot
>>>>>>>> service that would allow the San to handle snapshots.
>>>>>>>> On Sep 13, 2013 7:15 PM, "Marcus Sorensen" <shadow...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Ideally volume snapshots can be handled by the SAN back end, if
>>>>>>>>> the SAN supports it. The cloudstack mgmt server could call your
>>>>>>>>> plugin for
>>>>>>>>> volume snapshot and it would be hypervisor agnostic. As far as space,
>>>>>>>>> that
>>>>>>>>> would depend on how your SAN handles it. With ours, we carve out luns
>>>>>>>>> from
>>>>>>>>> a pool, and the snapshot spave comes from the pool and is independent
>>>>>>>>> of
>>>>>>>>> the LUN size the host sees.
>>>>>>>>> On Sep 13, 2013 7:10 PM, "Mike Tutkowski" <
>>>>>>>>> mike.tutkow...@solidfire.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hey Marcus,
>>>>>>>>>>
>>>>>>>>>> I wonder if the iSCSI storage pool type for libvirt won't work
>>>>>>>>>> when you take into consideration hypervisor snapshots?
>>>>>>>>>>
>>>>>>>>>> On XenServer, when you take a hypervisor snapshot, the VDI for
>>>>>>>>>> the snapshot is placed on the same storage repository as the volume
>>>>>>>>>> is on.
>>>>>>>>>>
>>>>>>>>>> Same idea for VMware, I believe.
>>>>>>>>>>
>>>>>>>>>> So, what would happen in my case (let's say for XenServer and
>>>>>>>>>> VMware for 4.3 because I don't support hypervisor snapshots in 4.2)
>>>>>>>>>> is I'd
>>>>>>>>>> make an iSCSI target that is larger than what the user requested for
>>>>>>>>>> the
>>>>>>>>>> CloudStack volume (which is fine because our SAN thinly provisions
>>>>>>>>>> volumes,
>>>>>>>>>> so the space is not actually used unless it needs to be). The
>>>>>>>>>> CloudStack
>>>>>>>>>> volume would be the only "object" on the SAN volume until a
>>>>>>>>>> hypervisor
>>>>>>>>>> snapshot is taken. This snapshot would also reside on the SAN volume.
>>>>>>>>>>
>>>>>>>>>> If this is also how KVM behaves and there is no creation of LUNs
>>>>>>>>>> within an iSCSI target from libvirt (which, even if there were
>>>>>>>>>> support for
>>>>>>>>>> this, our SAN currently only allows one LUN per iSCSI target), then
>>>>>>>>>> I don't
>>>>>>>>>> see how using this model will work.
>>>>>>>>>>
>>>>>>>>>> Perhaps I will have to go enhance the current way this works with
>>>>>>>>>> DIR?
>>>>>>>>>>
>>>>>>>>>> What do you think?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Sep 13, 2013 at 6:28 PM, Mike Tutkowski <
>>>>>>>>>> mike.tutkow...@solidfire.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> That appears to be the way it's used for iSCSI access today.
>>>>>>>>>>>
>>>>>>>>>>> I suppose I could go that route, too, but I might as well
>>>>>>>>>>> leverage what libvirt has for iSCSI instead.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Sep 13, 2013 at 6:26 PM, Marcus Sorensen <
>>>>>>>>>>> shadow...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> To your question about SharedMountPoint, I believe it just acts
>>>>>>>>>>>> like a
>>>>>>>>>>>> 'DIR' storage type or something similar to that. The end-user is
>>>>>>>>>>>> responsible for mounting a file system that all KVM hosts can
>>>>>>>>>>>> access,
>>>>>>>>>>>> and CloudStack is oblivious to what is providing the storage.
>>>>>>>>>>>> It could
>>>>>>>>>>>> be NFS, or OCFS2, or some other clustered filesystem,
>>>>>>>>>>>> cloudstack just
>>>>>>>>>>>> knows that the provided directory path has VM images.
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Sep 13, 2013 at 6:23 PM, Marcus Sorensen <
>>>>>>>>>>>> shadow...@gmail.com> wrote:
>>>>>>>>>>>> > Oh yes, you can use NFS, LVM, and iSCSI all at the same time.
>>>>>>>>>>>> > Multiples, in fact.
>>>>>>>>>>>> >
>>>>>>>>>>>> > On Fri, Sep 13, 2013 at 6:19 PM, Mike Tutkowski
>>>>>>>>>>>> > <mike.tutkow...@solidfire.com> wrote:
>>>>>>>>>>>> >> Looks like you can have multiple storage pools:
>>>>>>>>>>>> >>
>>>>>>>>>>>> >> mtutkowski@ubuntu:~$ virsh pool-list
>>>>>>>>>>>> >> Name State Autostart
>>>>>>>>>>>> >> -----------------------------------------
>>>>>>>>>>>> >> default active yes
>>>>>>>>>>>> >> iSCSI active no
>>>>>>>>>>>> >>
>>>>>>>>>>>> >>
>>>>>>>>>>>> >> On Fri, Sep 13, 2013 at 6:12 PM, Mike Tutkowski
>>>>>>>>>>>> >> <mike.tutkow...@solidfire.com> wrote:
>>>>>>>>>>>> >>>
>>>>>>>>>>>> >>> Reading through the docs you pointed out.
>>>>>>>>>>>> >>>
>>>>>>>>>>>> >>> I see what you're saying now.
>>>>>>>>>>>> >>>
>>>>>>>>>>>> >>> You can create an iSCSI (libvirt) storage pool based on an
>>>>>>>>>>>> iSCSI target.
>>>>>>>>>>>> >>>
>>>>>>>>>>>> >>> In my case, the iSCSI target would only have one LUN, so
>>>>>>>>>>>> there would only
>>>>>>>>>>>> >>> be one iSCSI (libvirt) storage volume in the (libvirt)
>>>>>>>>>>>> storage pool.
>>>>>>>>>>>> >>>
>>>>>>>>>>>> >>> As you say, my plug-in creates and destroys iSCSI
>>>>>>>>>>>> targets/LUNs on the
>>>>>>>>>>>> >>> SolidFire SAN, so it is not a problem that libvirt does not
>>>>>>>>>>>> support
>>>>>>>>>>>> >>> creating/deleting iSCSI targets/LUNs.
>>>>>>>>>>>> >>>
>>>>>>>>>>>> >>> It looks like I need to test this a bit to see if libvirt
>>>>>>>>>>>> supports
>>>>>>>>>>>> >>> multiple iSCSI storage pools (as you mentioned, since each
>>>>>>>>>>>> one of its
>>>>>>>>>>>> >>> storage pools would map to one of my iSCSI targets/LUNs).
>>>>>>>>>>>> >>>
>>>>>>>>>>>> >>>
>>>>>>>>>>>> >>> On Fri, Sep 13, 2013 at 5:58 PM, Mike Tutkowski
>>>>>>>>>>>> >>> <mike.tutkow...@solidfire.com> wrote:
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> LibvirtStoragePoolDef has this type:
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> public enum poolType {
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> ISCSI("iscsi"), NETFS("netfs"),
>>>>>>>>>>>> LOGICAL("logical"), DIR("dir"),
>>>>>>>>>>>> >>>> RBD("rbd");
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> String _poolType;
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> poolType(String poolType) {
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> _poolType = poolType;
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> }
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> @Override
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> public String toString() {
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> return _poolType;
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> }
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> }
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> It doesn't look like the iSCSI type is currently being
>>>>>>>>>>>> used, but I'm
>>>>>>>>>>>> >>>> understanding more what you were getting at.
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> Can you tell me for today (say, 4.2), when someone selects
>>>>>>>>>>>> the
>>>>>>>>>>>> >>>> SharedMountPoint option and uses it with iSCSI, is that
>>>>>>>>>>>> the "netfs" option
>>>>>>>>>>>> >>>> above or is that just for NFS?
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> Thanks!
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> On Fri, Sep 13, 2013 at 5:50 PM, Marcus Sorensen <
>>>>>>>>>>>> shadow...@gmail.com>
>>>>>>>>>>>> >>>> wrote:
>>>>>>>>>>>> >>>>>
>>>>>>>>>>>> >>>>> Take a look at this:
>>>>>>>>>>>> >>>>>
>>>>>>>>>>>> >>>>> http://libvirt.org/storage.html#StorageBackendISCSI
>>>>>>>>>>>> >>>>>
>>>>>>>>>>>> >>>>> "Volumes must be pre-allocated on the iSCSI server, and
>>>>>>>>>>>> cannot be
>>>>>>>>>>>> >>>>> created via the libvirt APIs.", which I believe your
>>>>>>>>>>>> plugin will take
>>>>>>>>>>>> >>>>> care of. Libvirt just does the work of logging in and
>>>>>>>>>>>> hooking it up to
>>>>>>>>>>>> >>>>> the VM (I believe the Xen api does that work in the Xen
>>>>>>>>>>>> stuff).
>>>>>>>>>>>> >>>>>
>>>>>>>>>>>> >>>>> What I'm not sure about is whether this provides a 1:1
>>>>>>>>>>>> mapping, or if
>>>>>>>>>>>> >>>>> it just allows you to register 1 iscsi device as a pool.
>>>>>>>>>>>> You may need
>>>>>>>>>>>> >>>>> to write some test code or read up a bit more about this.
>>>>>>>>>>>> Let us know.
>>>>>>>>>>>> >>>>> If it doesn't, you may just have to write your own
>>>>>>>>>>>> storage adaptor
>>>>>>>>>>>> >>>>> rather than changing LibvirtStorageAdaptor.java. We can
>>>>>>>>>>>> cross that
>>>>>>>>>>>> >>>>> bridge when we get there.
>>>>>>>>>>>> >>>>>
>>>>>>>>>>>> >>>>> As far as interfacing with libvirt, see the java bindings
>>>>>>>>>>>> doc.
>>>>>>>>>>>> >>>>> http://libvirt.org/sources/java/javadoc/ Normally,
>>>>>>>>>>>> you'll see a
>>>>>>>>>>>> >>>>> connection object be made, then calls made to that 'conn'
>>>>>>>>>>>> object. You
>>>>>>>>>>>> >>>>> can look at the LibvirtStorageAdaptor to see how that is
>>>>>>>>>>>> done for
>>>>>>>>>>>> >>>>> other pool types, and maybe write some test java code to
>>>>>>>>>>>> see if you
>>>>>>>>>>>> >>>>> can interface with libvirt and register iscsi storage
>>>>>>>>>>>> pools before you
>>>>>>>>>>>> >>>>> get started.
>>>>>>>>>>>> >>>>>
>>>>>>>>>>>> >>>>> On Fri, Sep 13, 2013 at 5:31 PM, Mike Tutkowski
>>>>>>>>>>>> >>>>> <mike.tutkow...@solidfire.com> wrote:
>>>>>>>>>>>> >>>>> > So, Marcus, I need to investigate libvirt more, but you
>>>>>>>>>>>> figure it
>>>>>>>>>>>> >>>>> > supports
>>>>>>>>>>>> >>>>> > connecting to/disconnecting from iSCSI targets, right?
>>>>>>>>>>>> >>>>> >
>>>>>>>>>>>> >>>>> >
>>>>>>>>>>>> >>>>> > On Fri, Sep 13, 2013 at 5:29 PM, Mike Tutkowski
>>>>>>>>>>>> >>>>> > <mike.tutkow...@solidfire.com> wrote:
>>>>>>>>>>>> >>>>> >>
>>>>>>>>>>>> >>>>> >> OK, thanks, Marcus
>>>>>>>>>>>> >>>>> >>
>>>>>>>>>>>> >>>>> >> I am currently looking through some of the classes you
>>>>>>>>>>>> pointed out
>>>>>>>>>>>> >>>>> >> last
>>>>>>>>>>>> >>>>> >> week or so.
>>>>>>>>>>>> >>>>> >>
>>>>>>>>>>>> >>>>> >>
>>>>>>>>>>>> >>>>> >> On Fri, Sep 13, 2013 at 5:26 PM, Marcus Sorensen
>>>>>>>>>>>> >>>>> >> <shadow...@gmail.com>
>>>>>>>>>>>> >>>>> >> wrote:
>>>>>>>>>>>> >>>>> >>>
>>>>>>>>>>>> >>>>> >>> Yes, my guess is that you will need the iscsi
>>>>>>>>>>>> initiator utilities
>>>>>>>>>>>> >>>>> >>> installed. There should be standard packages for any
>>>>>>>>>>>> distro. Then
>>>>>>>>>>>> >>>>> >>> you'd call
>>>>>>>>>>>> >>>>> >>> an agent storage adaptor to do the initiator login.
>>>>>>>>>>>> See the info I
>>>>>>>>>>>> >>>>> >>> sent
>>>>>>>>>>>> >>>>> >>> previously about LibvirtStorageAdaptor.java and
>>>>>>>>>>>> libvirt iscsi
>>>>>>>>>>>> >>>>> >>> storage type
>>>>>>>>>>>> >>>>> >>> to see if that fits your need.
>>>>>>>>>>>> >>>>> >>>
>>>>>>>>>>>> >>>>> >>> On Sep 13, 2013 4:55 PM, "Mike Tutkowski"
>>>>>>>>>>>> >>>>> >>> <mike.tutkow...@solidfire.com>
>>>>>>>>>>>> >>>>> >>> wrote:
>>>>>>>>>>>> >>>>> >>>>
>>>>>>>>>>>> >>>>> >>>> Hi,
>>>>>>>>>>>> >>>>> >>>>
>>>>>>>>>>>> >>>>> >>>> As you may remember, during the 4.2 release I
>>>>>>>>>>>> developed a SolidFire
>>>>>>>>>>>> >>>>> >>>> (storage) plug-in for CloudStack.
>>>>>>>>>>>> >>>>> >>>>
>>>>>>>>>>>> >>>>> >>>> This plug-in was invoked by the storage framework at
>>>>>>>>>>>> the necessary
>>>>>>>>>>>> >>>>> >>>> times
>>>>>>>>>>>> >>>>> >>>> so that I could dynamically create and delete
>>>>>>>>>>>> volumes on the
>>>>>>>>>>>> >>>>> >>>> SolidFire SAN
>>>>>>>>>>>> >>>>> >>>> (among other activities).
>>>>>>>>>>>> >>>>> >>>>
>>>>>>>>>>>> >>>>> >>>> This is necessary so I can establish a 1:1 mapping
>>>>>>>>>>>> between a
>>>>>>>>>>>> >>>>> >>>> CloudStack
>>>>>>>>>>>> >>>>> >>>> volume and a SolidFire volume for QoS.
>>>>>>>>>>>> >>>>> >>>>
>>>>>>>>>>>> >>>>> >>>> In the past, CloudStack always expected the admin to
>>>>>>>>>>>> create large
>>>>>>>>>>>> >>>>> >>>> volumes ahead of time and those volumes would likely
>>>>>>>>>>>> house many
>>>>>>>>>>>> >>>>> >>>> root and
>>>>>>>>>>>> >>>>> >>>> data disks (which is not QoS friendly).
>>>>>>>>>>>> >>>>> >>>>
>>>>>>>>>>>> >>>>> >>>> To make this 1:1 mapping scheme work, I needed to
>>>>>>>>>>>> modify logic in
>>>>>>>>>>>> >>>>> >>>> the
>>>>>>>>>>>> >>>>> >>>> XenServer and VMware plug-ins so they could
>>>>>>>>>>>> create/delete storage
>>>>>>>>>>>> >>>>> >>>> repositories/datastores as needed.
>>>>>>>>>>>> >>>>> >>>>
>>>>>>>>>>>> >>>>> >>>> For 4.3 I want to make this happen with KVM.
>>>>>>>>>>>> >>>>> >>>>
>>>>>>>>>>>> >>>>> >>>> I'm coming up to speed with how this might work on
>>>>>>>>>>>> KVM, but I'm
>>>>>>>>>>>> >>>>> >>>> still
>>>>>>>>>>>> >>>>> >>>> pretty new to KVM.
>>>>>>>>>>>> >>>>> >>>>
>>>>>>>>>>>> >>>>> >>>> Does anyone familiar with KVM know how I will need
>>>>>>>>>>>> to interact with
>>>>>>>>>>>> >>>>> >>>> the
>>>>>>>>>>>> >>>>> >>>> iSCSI target? For example, will I have to expect
>>>>>>>>>>>> Open iSCSI will be
>>>>>>>>>>>> >>>>> >>>> installed on the KVM host and use it for this to
>>>>>>>>>>>> work?
>>>>>>>>>>>> >>>>> >>>>
>>>>>>>>>>>> >>>>> >>>> Thanks for any suggestions,
>>>>>>>>>>>> >>>>> >>>> Mike
>>>>>>>>>>>> >>>>> >>>>
>>>>>>>>>>>> >>>>> >>>> --
>>>>>>>>>>>> >>>>> >>>> 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<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>
>>>>>>>>>> *™*
>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *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>
>>> *™*
>>>
>>
--
*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>
*™*
