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