Hi Edison, Yeah, I don't really care what those two methods are called (grant and revoke work for me). :)
The Hypervisor SS one is for any kind of managed storage. Right now it is true it is only used for SolidFire, but it does not have to be in theory. This is the idea: Storage that dynamically creates volumes (like the SolidFire plug-in does) needs to account for extra space that could be used by hypervisor snapshots. For example, if you say you want to 20 GB CloudStack volume and it is backed by my plug-in, I should create a volume on the SAN that is potentially larger than 20 GB to account for hypervisor snapshots (for Xen and VMware). This field allows you to specify how much, if any, additional space you want put aside for the hypervisor snapshots. If you say you want a 20 GB CloudStack volume with 100% reserve, you get a 40 GB volume on the storage system, 20 GB for your CloudStack volume and 20 GB for hypervisor snapshots. Any vendor that wants to implement the kind of dynamic volume creation that I do will need this ability. Accounting for space used on the storage system in this situation is more difficult, as well. If you say you want a 20 GB CloudStack volume with 100% reserve, I need to make sure I create a 40 GB volume on the SAN and account for 40 GB used on the storage system from CloudStack's point of view (because CloudStack has only been given permission to use a certain amount of space on the SAN and if I only subtract 20 GB from this number (the size of the CloudStack volume), then I'll be off). Does that make sense? This will get a bit more complex in 4.4 when I start supporting root disks. In that case, I will needs space for the template, the "real" volume, and hypervisor snapshots. Talk to you later, Mike On Wed, Jan 15, 2014 at 4:10 PM, Edison Su <edison...@citrix.com> wrote: > Hi Mike, > > Just found there are few new methods are added on > PrimaryDataStoreDriver: > > > > public boolean connectVolumeToHost(VolumeInfo volumeInfo, Host host, > DataStore dataStore); > > > > public void disconnectVolumeFromHost(VolumeInfo volumeInfo, Host host, > DataStore dataStore); > > > > public long getVolumeSizeIncludingHypervisorSnapshotReserve(Volume > volume, StoragePool pool); > > > > Could we rename the first two to something like(access/revokeAccess)? I > have this two methods long time ago, then I removed them during the merging > into 4.2, as nobody use them. > > getVolumeSizeIncludingHypervisorSnapshotReserve methods seems too specific > to your storage, better to not add it on the driver. What’s this method > used for? If you want change the usage size of volume, then why not return > a proper volume size in createAsync? Or we can add a new method called > getCapacities on the driver, if the default capacities is not enough for > storage provider. > -- *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> *™*
