Kelven, Thanks for pointing out this, and yes this is getting complicated when volume states/ownership changes, we need some feature level discussion here.
For following scenarios I need some suggestions: a) 'vm snapshot, detach volume and attach it to another VM, rollback snapshot', b) 'vm snapshot, detach and destroy volume, rollback snapshot', Three candidate solutions that I can figure out now, 1) disallow detach volumes if specified VM has VM snapshots. 2) allow to snapshot/rollback, for a), this will result in two volumes, one attached to anther VM, one attached to VM that rollback from snapshot; for b), destroyed volume is not truly expunged and capacity is not released. 3) add a global configuration and leave the choices for users. Regards Mice -----Original Message----- From: Kelven Yang [mailto:kelven.y...@citrix.com] Sent: Wednesday, August 08, 2012 8:19 AM To: cloudstack-dev@incubator.apache.org Subject: Re: [Discuss] VM Snapshot 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" <kelven.y...@citrix.com> 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" <cwe...@iswest.net> 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 [alex.hu...@citrix.com] >>Received: Monday, 06 Aug 2012, 11:17am >>To: cloudstack-dev@incubator.apache.org >>[cloudstack-dev@incubator.apache.org] >>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:mice_...@tcloudcomputing.com] >>> Sent: Sunday, August 05, 2012 7:50 PM >>> To: cloudstack-dev@incubator.apache.org >>> 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 >
