Hi, all I've posted a draft doc on http://wiki.cloudstack.org/display/COMM/VM+Snapshots
With some limitation and simple test code, VM snapshot for Xenserver and VMware seems feasible, but for the KVM part, because I'm not familiar with KVM, I have to postpone it to the next stage or maybe someone can help with it. For testing part, my idea is providing some simple testcases for BVT, but I'm not sure if it's sufficient. Any comments are welcomed. Regards Mice -----Original Message----- From: Edison Su [mailto:edison...@citrix.com] Sent: Thursday, August 09, 2012 9:52 AM To: cloudstack-dev@incubator.apache.org Subject: RE: [Discuss] VM Snapshot > -----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 > >
