Thanks for that info, Kelven!
On Wed, Mar 20, 2013 at 7:47 PM, Kelven Yang <kelven.y...@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.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> > >* * > > -- *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> *™*
