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