As of the requirement of VM Snapshot feature. Following feature may also be needed
- Export a VM snapshot into OVA - Import OVA into CloudStack (this feature is not truly related with snapshot but make backup and restore at VM basis useful) > > - Does not conflict with volume snapshot > For this requirement, we need more discussions When people navigate to a previous VM snapshot and branch off from there, it will eventually form a snapshot tree where all chained disks will be stored on the primary storage. VM's current disk is always a branch of the tree, this information is now stored in primary storage, CloudStack currently orchestrates VM formation always on the fly, except for VM state info, most of VM level properties are transient, so we will need to adjust CloudStack underlying model to address this. Secondly, attaching and detaching volume is a very common operation in current CloudStack model, and volume is truly first-class object in CloudStack that it has its own life cycle. By including volume state in different historically associated VM snapshots (because of attaching and detaching) will have impact to how we manage the snapshot tree and its associated volume disk chain. Just a side note, if you try to navigate along with a snapshot tree with volume membership changes, it will probably fail in Vmware vCenter itself) These reality details have to be studied carefully and a detail functional spec needs to be in place before implementation. Kelven On 8/6/12 5:19 PM, "Kelven Yang" <[email protected]> wrote: >When VM is running, snapshot operations have to be co-ordinated, once you >have the snapshots in storage, it is possible to branch off other branches >forking a VM and taking other snapshots on top of it. However, you can not >have more than one parent. > >The eventual big picture of it is a tree instead of a graph (introduced by >multiple parents) > >Kelven > >On 8/6/12 5:13 PM, "Clayton Weise" <[email protected]> wrote: > >>Is it possible to have multiple parent snapshots for a VM/Volume? That >>would be a way to get around the issue of bumping heads with other >>snapshot processes. >> >>Sent from my mobile phone, please forgive any minor spelling or grammar >>mistakes. >> >>-----Original Message----- >>From: Alex Huang [[email protected]] >>Received: Monday, 06 Aug 2012, 11:17am >>To: [email protected] >>[[email protected]] >>Subject: RE: [Discuss] VM Snapshot >> >>+1. >> >>Some of the concepts in CloudStack follows too closely to what Amazon EC2 >>APIs do. Snapshots (really backup as you pointed out) is one such >>problem. >> >>In CloudStack storage, we should clearly distinguish between >> >>-Primary Storage Volume Access >>-Snapshots (VM based) >>-Backup (Moving snapshots off of primary storage and into a backing >>store) >> >>I caution that because CloudStack backup process does not account for >>extra snapshots in the XenServer VHD chain, the changes this introduces >>will be substantial. >> >>Edison is also planning to work in this area. Edison, can you discuss >>what you have so far? >> >>--Alex >> >>> -----Original Message----- >>> From: Mice Xia [mailto:[email protected]] >>> Sent: Sunday, August 05, 2012 7:50 PM >>> To: [email protected] >>> Subject: [Discuss] VM Snapshot >>> >>> Hi, All, >>> >>> I¹d like to propose a new feature ŒVM snapshot¹. >>> >>> Currently CS support volume snapshot, which is an EC-2 like public >>>cloud >>> solution. >>> IMO, it addresses problems like Œwhat if my volume lost or broke down, >>>or >>> what if my primary storage got an unrecoverable disruption¹, in other >>>words, >>> it¹s more like a backup solution, and it does take considerable long >>>time to >>> backup and restore, especially for large volumes which are >>>unfortunately >>> favored by customers. >>> >>> What I want to propose is snapshots on VM, just like what Xenserver and >>> VMware ESXi do. >>> It addresses requirement such as 'I want to save everything right now >>>so that >>> I can roll back in the future, and both operations can be done within >>>seconds¹, >>> mainly used for private cloud. >>> >>> Plan for the first stage consists of support in Xenserver and ESXi, and >>>draft >>> requirements are as followings: >>> - Create VM snapshot. VM snapshot consists of: its CPU/memory status >>>(for >>> Xenserver it needs enterprise version), and volumes; service offerings. >>> stored in PS, snapshots are removed when VM is expunged. >>> - List snapshots for a specified VM >>> - Rollback VM to a specified VM >>> - Delete a specified snapshot >>> - Does not conflict with volume snapshot >>> - Create and restore should be done within seconds. >>> >>> Before I started off writing some documents on wiki and merge code, I'd >>>like >>> to welcome any comments and flames. >>> >>> Regards >>> Mice >
