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
