I believe, though, we should look into adding calls to grantAccess and revokeAccess for 4.3.
For 4.2 I didn't worry about it because my plug-in didn't work with KVM. I set XenServer and VMware up to use shared SRs/datastores using CHAP credentials that I added to all hosts in the cluster (programmatically). VM migrations were handled natively (meaning here coordinated by the cluster), as far as I know. Since CloudStack handles live migrations for KVM, it would probably be better to have support for grantAccess and revokeAccess the way you described earlier (since there is no true KVM cluster to handle this). On Sat, Sep 21, 2013 at 11:10 PM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > Also, we can bring John Burwell into this as he had related comments > several months ago, but we did not want to have the storage plug-ins > calling into the hypervisors. The idea was to get away from having any > hypervisor dependencies in the storage plug-ins. > > The default storage plug-in does not follow this practice (it does call > into the hypervisors), but the idea is to get away from that. > > > On Sat, Sep 21, 2013 at 11:07 PM, Mike Tutkowski < > mike.tutkow...@solidfire.com> wrote: > >> Hey Marcus, >> >> As far as I remember, grantAccess and revokeAccess are not invoked at all >> in 4.2. Edison may be able to elaborate more on this, but I don't believe >> the framework ever calls them. >> >> Talk to you later >> >> >> On Sat, Sep 21, 2013 at 11:02 PM, Marcus Sorensen <shadow...@gmail.com>wrote: >> >>> Oh, one more question. Is grantAccess/revokeAccess called as I'd >>> expect for migration, e.g. when PrepareForMigrationCommand is called >>> on the target host we can grantAccess to the new host, and then when >>> MigrateCommand returns successfully from the old host we revokeAccess >>> from the old host? >>> >>> On Sat, Sep 21, 2013 at 10:57 PM, Marcus Sorensen <shadow...@gmail.com> >>> wrote: >>> > All, >>> > We've had our own storage plugins based on the 4.1 branch for >>> > awhile now. Basically everything was done in KVM on the Agent side. >>> > With the new storage framework in place for 4.2, I'm working on >>> > splitting this code between Agent-specific (attach to VM, etc) and the >>> > code that talks to the SAN apis, which should live in the new plugin. >>> > However, I seem to be missing some functionality, namely storage >>> > stats. In 4.1, GetStorageStatsCommand would be sent to the Agent, and >>> > it would call _storagePoolMgr.getStoragePool, which we'd use to update >>> > the used bytes and capacity of the storage pool. >>> > >>> > 1) with the new framework, will storage pools managed by a plugin >>> > still call GetStorageStatsCommand? This is less than ideal, but >>> > better than nothing. I'd prefer to move all code that talks to the SAN >>> > into the storage plugin and out of the KVM agent. >>> > >>> > 2) Or is there some call I can handle that I'm not noticing will >>> > already do this in the storage plugin? I can fetch the current >>> > size/used in the initialize, or even when hosts attach in the Listener >>> > (which I don't see any documentation on), but I think the plugin >>> > framework needs the equivalent of GetStorageStatsCommand if it doesn't >>> > already have it. >>> >> >> >> >> -- >> *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> *™*
