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.tutkow...@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.tutkow...@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.y...@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.tutkow...@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.y...@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.tutkow...@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.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> >**
