OK, yeah, the ACL part will be interesting. That is a bit different from
how it works with XenServer and VMware.
Just to give you an idea how it works in 4.2 with XenServer:
* The user creates a CS volume (this is just recorded in the cloud.volumes
table).
* The user attaches the volume as a disk to a VM for the first time (if the
storage allocator picks the SolidFire plug-in, the storage framework
invokes a method on the plug-in that creates a volume on the SAN...info
like the IQN of the SAN volume is recorded in the DB).
* CitrixResourceBase's execute(AttachVolumeCommand) is executed. It
determines based on a flag passed in that the storage in question is
"CloudStack-managed" storage (as opposed to "traditional" preallocated
storage). This tells it to discover the iSCSI target. Once discovered it
determines if the iSCSI target already contains a storage repository (it
would if this were a re-attach situation). If it does contain an SR
already, then there should already be one VDI, as well. If there is no SR,
an SR is created and a single VDI is created within it (that takes up about
as much space as was requested for the CloudStack volume).
* The normal attach-volume logic continues (it depends on the existence of
an SR and a VDI).
The VMware case is essentially the same (mainly just substitute datastore
for SR and VMDK for VDI).
In both cases, all hosts in the cluster have discovered the iSCSI target,
but only the host that is currently running the VM that is using the VDI
(or VMKD) is actually using the disk.
Live Migration should be OK because the hypervisors communicate with
whatever metadata they have on the SR (or datastore).
I see what you're saying with KVM, though.
In that case, the hosts are clustered only in CloudStack's eyes. CS
controls Live Migration. You don't really need a clustered filesystem on
the LUN. The LUN could be handed over raw to the VM using it.
If there is a way for me to update the ACL list on the SAN to have only a
single KVM host have access to the volume, that would be ideal.
Also, I agree I'll need to use iscsiadm to discover and log in to the iSCSI
target. I'll also need to take the resultant new device and pass it into
the VM.
Does this sound reasonable? Please call me out on anything I seem incorrect
about. :)
Thanks for all the thought on this, Marcus!
On Fri, Sep 13, 2013 at 8:25 PM, Marcus Sorensen <shadow...@gmail.com>wrote:
> Perfect. You'll have a domain def ( the VM), a disk def, and the attach
> the disk def to the vm. You may need to do your own StorageAdaptor and run
> iscsiadm commands to accomplish that, depending on how the libvirt iscsi
> works. My impression is that a 1:1:1 pool/lun/volume isn't how it works on
> xen at the momen., nor is it ideal.
>
> Your plugin will handle acls as far as which host can see which luns as
> well, I remember discussing that months ago, so that a disk won't be
> connected until the hypervisor has exclusive access, so it will be safe and
> fence the disk from rogue nodes that cloudstack loses connectivity with. It
> should revoke access to everything but the target host... Except for during
> migration but we can discuss that later, there's a migration prep process
> where the new host can be added to the acls, and the old host can be
> removed post migration.
> On Sep 13, 2013 8:16 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com>
> wrote:
>
>> 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>
>> *™*
>>
>
--
*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>
*™*
