Can I ask you guys a related question? When I tried to set up my iSCSI-based Primary Storage for my XenServer Cluster, I only had one XenServer in the Cluster.
What does CloudStack do from a storage repository standpoint if there are multiple XenServers in the Cluster? Do they each get a new storage repository that points to that IQN? Thanks for clarifying this for me! On Thu, Feb 7, 2013 at 7:55 PM, Mike Tutkowski <mike.tutkow...@solidfire.com > wrote: > Hey Alex, > > Thanks for your input! > > Let me make sure we're on the same page from a terminology standpoint. > > When I refer to a volume, that is equivalent to a LUN. Creating a > SolidFire volume gets you an IQN referring to LUN 0. > > It is definitely true that SolidFire would love to be able to service a > single VM Instance or Data Disk from one of its volumes (since quality of > service for SolidFire is on a volume-by-volume basis). So, saying one VDI > per volume per LUN sounds like we're talking about the same thing. > > It is my understanding that Edison's plug-in architecture that is > scheduled for 4.2 will enable this, which is great. > > In the meanwhile, I'm trying to develop a relatively simple workaround for > our customers (including those who won't upgrade to 4.2 right away). > > What I put out there in previous messages may or may not work. I'm really > new to CloudStack, so I'd certainly like to get input from those with > experience. > > I wrote it earlier, but let me re-write it here again. This is what I was > thinking: > > Most CSPs have their own GUIs that talk to CS. If I could get them to > make a little update to their code, they could invoke a program I would > (theoretically) write when a "special" Compute Offering was selected. > > The way they would recognize this special Compute Offering would be based > on its Storage Tag. Let's say its Storage Tag is "SolidFire". > > If their GUI sees that tag, it invokes my program and passes in the > necessary data. My program goes off to the SolidFire SAN and creates a > volume of the requested size and speed. The output of this operation is an > IQN. > > This program could then talk to XenServer and create a new storage > repository that's based on this IQN (or whatever the equivalent is in KVM > and VMware). > > After that has completed, this program could update the Storage Tag of a > known Primary Storage in CS with, say, the IQN of the volume. It would do > the same thing with the Compute Offering in question (so now the Compute > Offering refers to the Primary Storage due to this common Storage Tag). > > At this point, the CSP's GUI could initiate the process of creating a VM > and the VM should reside on a unique SolidFire volume that is the only > volume in that XenServer's related storage repository. > > The CSP then sets the Storage Tag of the Compute Offering and Primary > Storage back to what it was initially: "SolidFire". > > Is that reasonable or perhaps I'm missing something? It's not ideal, but > mainly I'm looking for a workable solution to provide to customers before > 4.2 is out. > > Thanks for your time! > > > On Thu, Feb 7, 2013 at 5:33 PM, Alex Huang <alex.hu...@citrix.com> wrote: > >> Mike, >> >> One thing you should be aware of is that CloudStack used lvmoiscsi SR for >> iscsi. It is not vdi per lun. From your other emails, I think solid fire >> is trying to implement vdi/volume per lun. It's very different from >> CloudStack's implementation. >> >> --Alex >> >> > -----Original Message----- >> > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] >> > Sent: Thursday, February 07, 2013 3:15 PM >> > To: Edison Su >> > Cc: cloudstack-dev@incubator.apache.org; Marcus Sorensen >> > Subject: Re: Setting up CloudStack to use XenServer with iSCSI >> > >> > OK, thanks...I can fetch the latest. >> > >> > >> > On Thu, Feb 7, 2013 at 3:57 PM, Edison Su <edison...@citrix.com> wrote: >> > >> > > It should work, maybe you can try the latest code in storage_refactor >> > > branch.**** >> > > >> > > ** ** >> > > >> > > *From:* Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] >> > > *Sent:* Thursday, February 07, 2013 2:51 PM >> > > *To:* Edison Su >> > > *Cc:* cloudstack-dev@incubator.apache.org; Marcus Sorensen >> > > *Subject:* Re: Setting up CloudStack to use XenServer with iSCSI**** >> > > >> > > ** ** >> > > >> > > Hey Edison,**** >> > > >> > > ** ** >> > > >> > > I can't get jetty to run in storage_refactor (admittedly my code is >> about >> > > a week out of date). Should jetty be working there now or is this a >> known >> > > issue?**** >> > > >> > > ** ** >> > > >> > > Thanks**** >> > > >> > > ** ** >> > > >> > > On Thu, Feb 7, 2013 at 3:48 PM, Mike Tutkowski < >> > > mike.tutkow...@solidfire.com> wrote:**** >> > > >> > > Sounds good, Edison...I was under the impression this was a known >> issue, >> > > but it sounds like maybe it's not.**** >> > > >> > > ** ** >> > > >> > > I'll try to reproduce it today.**** >> > > >> > > ** ** >> > > >> > > Thanks**** >> > > >> > > ** ** >> > > >> > > On Thu, Feb 7, 2013 at 3:41 PM, Edison Su <edison...@citrix.com> >> > wrote:*** >> > > * >> > > >> > > need error messages, otherwise, I don't know how to debug the >> > issue...**** >> > > >> > > **** >> > > >> > > *From:* Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] >> > > *Sent:* Thursday, February 07, 2013 2:11 PM >> > > *To:* cloudstack-dev@incubator.apache.org; Edison Su; Marcus Sorensen >> > > *Subject:* Setting up CloudStack to use XenServer with iSCSI**** >> > > >> > > **** >> > > >> > > Hi everyone,**** >> > > >> > > **** >> > > >> > > I noticed a while back that when I tried to create iSCSI-based Primary >> > > Storage for a XenServer Cluster that the operation failed.**** >> > > >> > > **** >> > > >> > > The way I got around this was to go into XenCenter, create a storage >> > > repository based on my iSCSI target, and then go into CloudStack and >> > create >> > > a PreSetup-based Primary Storage.**** >> > > >> > > **** >> > > >> > > Does anyone know why I had to take this PreSetup approach for >> XenServer? >> > > Is there no way for CloudStack to call into XenServer to do this >> work for >> > > me?**** >> > > >> > > **** >> > > >> > > 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> >> > > *(tm)***** >> > > >> > > >> > > >> > > **** >> > > >> > > ** ** >> > > >> > > -- >> > > *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> >> > > *(tm)***** >> > > >> > > >> > > >> > > **** >> > > >> > > ** ** >> > > >> > > -- >> > > *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> >> > > *(tm)***** >> > > >> > >> > >> > >> > -- >> > *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> >> > *(tm)* >> > > > > -- > *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> *™*
