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.tutkow...@solidfire.com> wrote: > 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> > *™* > -- *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> *™*
