I think we are moving towards to the direction of that CloudStack to hand off some of these virtualize business(no need to re-invent every wheel) and focus more on cloud orchestration itself. By doing so, features like HA, DRS, storage live Motion, Fault Tolerance will be easier to add into CloudStack through the underlying hypervisors
Kelven On 3/20/13 7:10 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com> wrote: >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> >**
