Thanks Edison, the meeting notes were helpful. I am implementing a storage plugin for CloudByte & am using *_details table for storing the plugin related info.
Can anyone explain what kind/type of plugin data is not suitable in *_details table (referring to point 5). Regards, Amit *CloudByte Inc.* <http://www.cloudbyte.com/> On Fri, Sep 20, 2013 at 5:35 AM, Edison Su <edison...@citrix.com> wrote: > Meeting notes: > > Date: Sep 17, 2013 > > Attendees: > > NetApp: Chris, David > > Citrix: Alex, Animesh, Edison, Srinivas > > > > 1. TakeSnapshot method on storage plugin. > > Chris: TakeSnapshot method is implemented, but backup snapshot is > failed on the hypervisor side, as the default backup snapshot procedure > will send a copycommand to Xenserver resource, which can't recognize the > snapshot created by NetApp storage plugin. > > Edison: take snapshot, then backup snapshot to secondary storage > immediately is the default behavior in CloudStack. There is a way to > customize it, by extends SnapshotStrategy interface. For example, we can > write a SnapshotStrategy, which doesn't back up unless anther backup > snapshot API is called. Or we can add a global configuration parameter to > disable backup. > > Chris: backup snapshot is fine, but we need a way to customize the > backup logic. Should we need to let hypervisor knows the snapshot created > by NetApp, Xenserver has an API to introduce a volume/snapshot, but VMware > seems doesn't have that kind of API. > > Edison: There is ways to customize the copy logic, by extending > copyAsync in storage plugin. Everytime, mgt server sends a copycommand, it > will go through both source storage provider and destination storage > provider, If any of them knows how to handle the copycommand, then mgt > server will handle it to storage provider, otherwise, mgt server will > handle it to DataMotionService. So there are two ways to customize > copycommand: > > a. implement copyAsync in storage plugin, > > b. add a new DataMotionService. > > Method a, is easier than method b. > > In copyAsync implementation, we can send the copyCommand to SSVM to > handle the actual snapshot copy, instead of sending to hypervisor host. > > Chris: Need the detail about how to implement copyAsync in storage > plugin: > > [Action]: Edison needs to provide detailed information on how to > implementation of copyAsync > > > > 2. RevertSnapshot > > Chris: RevertSnapshot is never been called in CloudStack. > > Edison: CloudStack always assumes the snapshot is created, then will > be backed up to image store immediately, so no need to revert snapshot. > > Chris: need to add revert snapshot functionality on the UI, and API to > implement revert Snapshot functionality, as the snapshot created on NetApp > can be reverted back. > > [Action]: Edison needs to implement RevertSnapshot, and call storage > plugin's RevertSnapshot accordingly. > > > > 3. NetApp volume snapshot. > > David: Due to the limitation of NetApp hardware(the number of snapshots > can be stored on one NetApp volume is limited, less than 255?), we need to > implement volume snapshot, instead of per VM volume snapshot. > > David: Need to change storage plugin API to take snapshots for all the > VMs created on the primary storage, instead of per one volume, such as > takeSnapshot(List<VM> vms), then NetApp can take only one snapshot on the > whole NetApp volume. > > Animesh: Does NetApp's hardware has the information for VM's each > volumes, as there is only one snapshot taking on primary storage? > > David: Yes, there is information per volume, we can store them in > snapshot's path column in CloudStack DB. > > Alex: How about queue taking snapshot methods call in storage plugin? > For example, queue the taking snapshot for several minutes, then issue only > one take-snapshot command to NetApp hardware. > > David: It's doable, but maybe it's better to be done at the CloudStack > mgt server level. > > Alex: Better to send out a proposal on the mailing list, let's see what > other storage vendor's feedback. If we agree on it's better to implement it > at mgt server level, then can definitely can implement that. > > Alex: Due to tight 4.3 schedule, maybe implement it at the storage > driver level is more practical. > > [Action] NetApp will send out a proposal to mailing list. > > > > 4. Can't add multiple image storage providers in one CloudStack setup. > > Chris: There is on way to let customer to migrate existing NFS > secondary storage to NetApp's image store, due to the above limitation. > > Edison: The reason for only one image storage provider is that: > whenever CloudStack mgt server needs to access image store, mgt server has > not hint to pick up an image store, if there are multiple image stores. As > both image stores are in the same scope. And for operations, like template > sync between image stores, template copy between zones, will be much > complicated if there are multiple image stores. > > Edison: the proposal is putting the existing image store into > maintenance mode, then migrate existing templates/snapshots stored on the > image store to new image store. > > [Action] Edison needs to implement image store maintenance mode. NetApp > may need to provide way to migrate image store. > > > > 5. How to store configuration for storage plugin: > > Animesh: Alex, is it OK to create DB table in storage plugin? > > Alex: Better to use *_details table > > Chris: For configurations like NetApp server info, or any other > configuration parameter, it's not suitable in *_details > > Alex: Then can store them in configuration table > > Chris: configuration table is global, is it OK to store this kind of > plugin specific information in global configuration? > > Alex: In 4.3, people are talking about ConfigurationDepot on the > mailing list, which is suitable for your case. > > [Action]: Chris will take a look at ConfigDepot. > > > > 6. How to quiescing VMs: > > David: What we did in other VMware products is creating a VM snapshot > first, new linked clone will be created, all the data write will go to the > new linked clone. NetApp can take snapshot on the parent linked clone, then > backup it to secondary storage, then revert the snapshot, and delete the > new linked clone. In this way, we can leverage VM snapshot to quiecse VM, > then actually backup snapshot through NetApp. > > Alex: it's great! We maybe finally have a way to backup VMware snapshot > efficiently. We need to investigate it, not only for VMware but also for > Xenserver. > > [Action] Both need to investigate the possible way to quiesce VM, then > come up with new APIs to quiesce/unquiese VM. > > > > > > > >
