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