Hi, Hari Please see my comments inline.
1. Is archival to secondary storage being considered? [mice] Yes, but I haven’t figured out how to implement it. If the purpose of archiving it to secondary storage is to save space on primary storage, that means we have to remove a node from snapshot tree, I'm not sure if it's possible to insert that node back into the tree. If purpose is for backup and we don’t remove any nodes from the tree, it's almost same with volume snapshot; we need to backup the chain from one node up to the root, and coalesce them into one file and copy to SS, this process has some performance issue at this moment. I think for backup purpose volume snapshot is able to meet the requirement. 2. Currently, (with volume snapshots) we have the capability to setup recurring snapshots - so, with VM snapshot, can users set up automatic recurring snapshot policies? Snapshots can be created on an hourly, daily, weekly, or monthly interval. One snapshot policy can be set up per VM [mice] good point but I need some use cases/scenarios. In my opinion, volume snapshot could be periodical because it's mainly for backup, VM snapshot is mostly on-demanded because it may contain a transient memory snapshot, and users should be aware of which point 3. With each snapshot schedule, can users also specify the number of scheduled snapshots to be retained · Older snapshots that exceed the retention limit are automatically deleted. · This user-defined limit must be equal to or lower than the global limit set by the administrator. · The limit applies only to those snapshots that are taken as part of an automatic recurring snapshot policy. Additional manual snapshots can be created and retained 4. You also mention ASF 4.1 and Feb – I’m wondering what it would me as ASF 4.1 is targeted for Jan 31? If time is a constraint, would it be possible to prioritize dev on platform basis? Such as VMware prio 1 etc. [mice] if I remember correctly, code complete is targeted for Jan 31. And sure we can prioritize dev based on feedbacks. Hari Kannan -----Original Message----- From: Mice Xia [mailto:mice_...@tcloudcomputing.com] Sent: Friday, December 14, 2012 4:28 AM To: cloudstack-dev@incubator.apache.org Subject: [ACS41] VM Snapshot and possibility to introduce it in 4.1 Hi, folks, I’d like to discuss the possibility of introducing feature VM Snapshot in CS version 4.1 and I need some inputs/ideas for the rest of work. The background/spec/design is in https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Snapshots. The implementation is very straightforward (with KISS principle) , codes are in branch vm-snapshot, based on 4.0.0. * About the terminology: I’m not sure if the terminology will cause some confusion after this is merged into 4.1, because we already have “Volume Snapshot”. One candidate solution is to change "volume snapshot" to "volume backup", or change "VM snapshot" to "VM checkpoint". * About TODO list [Limit per account/domain] Should we take VM snapshot as first class object in CS and provide limit per account/domain like other first class objects? In my opinion, it's inside the scope of VM's lifecycle and a global limit is enough. [Usage Record] Similar to limit, every first class object's usage is recorded into usage database, if we agree to treat VM snapshot as first class object, it should also be recorded. And VM snapshot is primarily for private cloud, is there a strong need for charging it in an enterprise environment? [Storage Capacity Stat] VM snapshot consumes extra space on primary storage, including memory image and snapshot branches. It is supposed to provide some way to reflect the storage allocation. VM snapshot forms a tree structure, and I tend to add extra allocated_capacity as follow formula: ( allocate_capacity_of_all_volumes * (num_of_path_from_root_node_to_leaf - 1 ) ) + memorySize * number_of_snapshot [Unit Test] Still in progress [Functional Test Scenarios] Will be ready *Limitation Highlights: Customers should only use CS to take snapshot. CS maintains the snapshot tree in database, out-of-band snapshots will not be tracked or sync to CS. (for VMware perhaps we have a chance to sync them back) Not allowed to attach/detach volumes when there are some vm-snapshots. Because any change to the disk layout will break the semantics of VM-based snapshot. *Review (or vote?) It will be great if someone can take some time reviewing the design/code and give some feedbacks, especially the KVM part. *Dependency Edison is working on storage refactoring, not sure if there is any dependency. Rely on some changes in libvirt-java. *Schedule Code complete before Feb,2013 if no major requirement/design change. Welcome any comments, suggestions and flames. Regards Mice
