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.
