Hi, a) 'vm snapshot, detach volume and attach it to another VM, rollback snapshot' 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; We should not allow this due to the fact one VM's snapshot cannot have any impact on another VM's snapshot. VM 'B' cannot have volume changes because I rolled back on VM "A".
b) 'vm snapshot, detach and destroy volume, rollback snapshot' 2) allow to snapshot/rollback, for b), destroyed volume is not truly expunged and capacity is not released This will lead to usage problems. The customer will complain he has deleted his volumes but still getting charged for it, yes because cloud-usage will still see the volume and report it in usage records. My suggestion would be 1) disallow detach volumes if specified VM has VM snapshots. The end user can always add more but cannot remove once snapshotted. The end user must remove snapshots before wants to remove volumes. Also all snapshots created after the one I reverted to should be invalidated and deleted/expunged. I know this would cripple the snapshot functionality quite a bit but for now I think would work perfectly, without making fundamental changes to CS infrastructure and would allow us to have proper snapshots and not exported templates. Regards Tamas Monos DDI +44(0)2034687012 Chief Technical Office +44(0)2034687000 Veber: The Hosting Specialists Fax +44(0)871 522 7057 http://www.veber.co.uk Follow us on Twitter: www.twitter.com/veberhost Follow us on Facebook: www.facebook.com/veberhost -----Original Message----- From: Mice Xia [mailto:mice_...@tcloudcomputing.com] Sent: 08 August 2012 06:17 To: cloudstack-dev@incubator.apache.org Subject: RE: [Discuss] VM Snapshot 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 >
