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> > *™*
