On a related note, it looks like the scope of Primary Storage has changed in 4.2. What are the benefits of this scoping feature? For example, does it help mainly if you want to migrate a VM from one cluster to another?
Thanks On Tue, Mar 5, 2013 at 10:56 AM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > Thanks, Marcus > > When Edison sees this e-mail chain, he will be able to fill in extra > details. > > > On Mon, Mar 4, 2013 at 11:08 PM, Marcus Sorensen <shadow...@gmail.com>wrote: > >> Generally the targets I've worked with support different levels of >> access control, so you may have a high level block where you can't >> even see the target unless you come from the right IP (ACL/firewall), >> then you've got something like CHAP, and then maybe the target >> supports persistent reservations so that only one client can use a >> given LUN at any one time. It's a combination of the client software >> expects and what the target offers that ensures integrity. >> >> I should probably let someone else who has more insight into the >> storage 2.0 specific stuff clarify your questions, since I'm not 100% >> certain what those methods are intended for. >> >> On Mon, Mar 4, 2013 at 10:55 PM, Mike Tutkowski >> <mike.tutkow...@solidfire.com> wrote: >> > Interesting, Marcus...thanks for the comments. >> > >> > Yeah, the way it works on our SAN is a given volume is either accessible >> > via CHAP credentials or - if CHAP is not being used - a set of IQNs is >> > maintained and any initiator with a "proper" IQN can access the volume >> (we >> > depend on client-side software to be smart enough to not corrupt the >> state >> > of a volume). >> > >> > I wonder what you recommend in this situation? >> > >> > Thanks! >> > >> > >> > On Mon, Mar 4, 2013 at 10:45 PM, Marcus Sorensen <shadow...@gmail.com >> >wrote: >> > >> >> On Mon, Mar 4, 2013 at 10:41 PM, Marcus Sorensen <shadow...@gmail.com> >> >> wrote: >> >> > On revoke/grant access, If we're talking about individual volumes >> >> > being equal to a data/root disk, it's wise to adjust ACLs to only >> >> > allow access to the host that is currently wanting to run the >> VM/disk. >> >> > This way, cloudstack is authoritative in what's accessing the lun, >> and >> >> > you don't have to run a separate cluster/locking daemon. Otherwise, >> if >> >> > you launch a VM on a host, and that host goes rogue (loses some sort >> >> > of connectivity, but the vm remains running and connected to the >> >> > storage), when cloudstack tries to start that VM elsewhere then the >> >> > access to storage is cut off from the original VM. Having the same VM >> >> > running twice, connected to the same disk image, is a bad thing :-) >> >> > >> >> > In other words, before you start a VM or attach a disk, you'd revoke >> >> > access to everyone, then grant access to the host you're running the >> >> > VM/disk on. >> >> >> >> **disclaimer - I haven't done more than a cursory look at the storage >> >> 2.0 stuff, so what I'm saying might not even apply to what you're >> >> looking at now, but you probably should implement revokeAccess to >> >> remove ACLs based on the parameters passed. >> >> >> >> > >> >> > On Mon, Mar 4, 2013 at 10:21 PM, Mike Tutkowski >> >> > <mike.tutkow...@solidfire.com> wrote: >> >> >> Hi, >> >> >> >> >> >> I'm working on implementing a storage plug-in for CS 4.2. >> >> >> >> >> >> I'm looking at the following Wiki page for guidance, but have some >> >> >> questions: >> >> >> >> >> >> https://cwiki.apache.org/CLOUDSTACK/storage-subsystem-20.html >> >> >> >> >> >> One interface that needs to be implemented is >> PrimaryDataStoreDriver. >> >> I'm >> >> >> not sure what is expected for all of the following methods: >> >> >> >> >> >> * grantAccess: It looks like this is called in an attempt to >> confirm >> >> that >> >> >> the host which desires access to the volume in question is allowed >> to do >> >> >> so. I suspect this is where CHAP credentials might be provided? >> In my >> >> >> situation, there are a couple ways I'd like to restrict access: 1) >> >> CHAP or >> >> >> 2) allow a subset of IQNs to access the volume in question. Is this >> >> kind >> >> >> of information provided to me here? Do I simply return the IQN of >> the >> >> >> volume as a successful response from this method? What if the >> access >> >> sent >> >> >> is not sufficient? How do I deny access? >> >> >> >> >> >> * revokeAccess: I don't really understand when this method would be >> >> called >> >> >> or why. Perhaps I can simply implement it to return true (or >> false)? >> >> In >> >> >> my situation, when a volume is dynamically created for a hypervisor >> of a >> >> >> cluster, I'd want to allow access to it from all hosts in the app >> >> cluster >> >> >> in question. Maybe this method is called before the volume is >> deleted >> >> or >> >> >> something? >> >> >> >> >> >> * listObjects: I don't really understand when this method would be >> >> called >> >> >> or why. >> >> >> >> >> >> * createAsync: I believe this is where I place my code to create a >> >> volume >> >> >> (LUN) on our SAN. >> >> >> >> >> >> * deleteAsync: I believe this is where I place my code to delete a >> >> volume >> >> >> (LUN) on our SAN. >> >> >> >> >> >> Thanks for any guidance here! >> >> >> >> >> >> -- >> >> >> *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> *™*
