cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: Creating a VMFS datastore backed by an iSCSI target
Date Thu, 21 Mar 2013 02:10:15 GMT
Oh, I was going to ask, though, on a related note...don't we duplicate
certain hypervisor features in CS today...like HA for some platforms?


On Wed, Mar 20, 2013 at 8:01 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> Thanks for that info, Kelven!
>
>
> On Wed, Mar 20, 2013 at 7:47 PM, Kelven Yang <kelven.yang@citrix.com>wrote:
>
>> VMware is a very different animal in CloudStack, the reason lies on the
>> integration point, in XS/KVM case, CloudStack manages hypervisor host
>> directly, while in VMware case, the integration point is at vCenter
>> instead of ESX/ESXi hosts, therefore, ESX/ESXi hosts are actually
>> indirectly managed by CloudStack through vCenter.
>>
>> Why we chose this integration architecture is that most of VMware users
>> are enterprise users, CloudStack does not want to lose the whole VMware
>> ecosystem around its technology, it does not make sense to completely
>> duplicate/replace the features that vCenter has already provided,
>> especially that enterprise IT admins are already familiar with.
>>
>> Kelven
>>
>> On 3/20/13 6:33 PM, "Mike Tutkowski" <mike.tutkowski@solidfire.com>
>> wrote:
>>
>> >Hey Kelven,
>> >
>> >Can you clarify for me something?
>> >
>> >In your view, is creating a XenServer storage repository in the way I
>> >described earlier different (easier) than creating a VMware datastore?
>> >
>> >If Edison's storage plug-in framework is not going to do this, then I'm
>> >confused what value it brings to the table.  I was under the impression
>> >the
>> >purpose of the storage plug-in framework was to remove the requirement of
>> >having to have storage set aside in large chucks ahead of time (that
>> >multiple VMs eventually share).
>> >
>> >Can't we just require that customers who want to use this feature on
>> >VMware
>> >make sure they set up an iSCSI adapter on each ESX box ahead of time?
>> >
>> >Thanks for your time on this!
>> >
>> >
>> >On Wed, Mar 20, 2013 at 7:27 PM, Mike Tutkowski <
>> >mike.tutkowski@solidfire.com> wrote:
>> >
>> >> Interesting...well, hopefully Edison can comment and clear this up.
>> >>
>> >> Thanks, Kelven!
>> >>
>> >>
>> >> On Wed, Mar 20, 2013 at 7:22 PM, Kelven Yang
>> >><kelven.yang@citrix.com>wrote:
>> >>
>> >>> If this is the case, the storage plug-in framework needs to be
>> >>>adaptive to
>> >>> that a datastore may be preset from external source. Creating VMFS
>> >>> datastore involves with complex interactive flow, for example, it
>> >>>requires
>> >>> administrator to enable iScsi adapter on every ESX host under a
>> >>>cluster.
>> >>> It does not make sense for CloudStack to get involved in vCenter's own
>> >>> business.
>> >>>
>> >>> Kelven
>> >>>
>> >>> On 3/20/13 6:06 PM, "Mike Tutkowski" <mike.tutkowski@solidfire.com>
>> >>> wrote:
>> >>>
>> >>> >Thanks, Kevlen
>> >>> >
>> >>> >That makes sense that in pre 4.2 we don't use VI SDK to create a
>> >>> datastore
>> >>> >as we require the datastore to be set up ahead of creating Primary
>> >>> >Storage.
>> >>> >
>> >>> >However, as far as I understand Edison's 4.2 storage plug-in
>> >>>framework,
>> >>> >which creates the necessary storage when a VM is spun up or a data
>> >>>disk
>> >>> is
>> >>> >created, CS will need to interact with VMware to create a datastore
>> to
>> >>> map
>> >>> >the newly created SAN volume into so that CS can make Primary Storage
>> >>>for
>> >>> >it.
>> >>> >
>> >>> >This is my understanding of the 4.2 plug-in framework:
>> >>> >
>> >>> >* You create a storage plug-in.
>> >>> >
>> >>> >* Primary Storage can be associated with this plug-in (as opposed
to
>> >>> being
>> >>> >associated with pre-existing storage).
>> >>> >
>> >>> >* When a Compute or Disk Offering is executed and it is tagged to
use
>> >>> >Primary Storage that makes use of this plug-in, the plug-in is
>> >>>invoked to
>> >>> >create the necessary storage (let's say an iSCSI volume).
>> >>> >
>> >>> >* A datastore (for VMware) or a storage repository (for XenServer)
>> >>>then
>> >>> >needs to be created for the SAN volume to be utilized from CS.
>> >>> >
>> >>> >* The VM or data disk is placed on the datastore or storage
>> repository
>> >>> and
>> >>> >it (the VM or data disk) is the only object that ever utilizes this
>> >>> >datastore or storage repository.
>> >>> >
>> >>> >
>> >>> >On Wed, Mar 20, 2013 at 5:32 PM, Kelven Yang <kelven.yang@citrix.com
>> >
>> >>> >wrote:
>> >>> >
>> >>> >> We don't use VI SDK in CloudStack for VMware integration.
>> >>> >>
>> >>> >> For VMFS datastore, CloudStack will not create it and will
rely on
>> >>> >>vCenter
>> >>> >> to do it. To enable a VMFS datastore involves a series of steps,
>> the
>> >>> >>flow
>> >>> >> is provided by vCenter.
>> >>> >>
>> >>> >> Kelven
>> >>> >>
>> >>> >> On 3/20/13 1:26 PM, "Mike Tutkowski" <mike.tutkowski@solidfire.com
>> >
>> >>> >>wrote:
>> >>> >>
>> >>> >> >Hi everyone,
>> >>> >> >
>> >>> >> >Has anyone every used the VI SDK or the VI Java API to
create a
>> >>>VMFS
>> >>> >> >datastore that makes use of an iSCSI target?
>> >>> >> >
>> >>> >> >I've been searching all over Google for some decent sample
code.
>> >>>I've
>> >>> >> >found bits and pieces (more about NFS than iSCSI), but
nothing
>> that
>> >>> >>brings
>> >>> >> >it all together.
>> >>> >> >
>> >>> >> >This was fairly easy to do with XenServer, but VMware seems
to be
>> >>> >>lacking
>> >>> >> >in the sample-code area.
>> >>> >> >
>> >>> >> >Thanks!
>> >>> >> >
>> >>> >> >--
>> >>> >> >*Mike Tutkowski*
>> >>> >> >*Senior CloudStack Developer, SolidFire Inc.*
>> >>> >> >e: mike.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message