cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edison Su <Edison...@citrix.com>
Subject RE: [Discuss] VM Snapshot
Date Thu, 09 Aug 2012 01:51:50 GMT


> -----Original Message-----
> From: Mice Xia [mailto:mice_xia@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.yang@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.yang@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" <cweise@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.Huang@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_xia@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
> >

Mime
View raw message