Hi Mice,
Thanks for the email - Looking at the proposal, I have the following feedback - 1. Is archival to secondary storage being considered? 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 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. 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
