incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tamas Monos <tam...@veber.co.uk>
Subject RE: [Discuss] VM Snapshot
Date Wed, 08 Aug 2012 10:50:23 GMT
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_xia@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.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