> -----Original Message----- > From: Mice Xia [mailto:mice_...@tcloudcomputing.com] > Sent: Tuesday, August 07, 2012 10:17 PM > 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.
For VM based snapshot, we should not allow user to dynamically change(attach or detach) VM's disks if there are VM-based snapshot taken on this VM. Because any change to the disk layout will break the semantics of VM-based snapshot. > > 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 > >
