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