Re: [Xen-devel] [RFC V9 3/4] domain snapshot design: xl

["Chun Yan Liu" <cyliu@xxxxxxxx>]

>>> On 12/17/2014 at 08:28 PM, in message
<20141217122817.GG1904@xxxxxxxxxxxxxxxxxxxxx>, Wei Liu <wei.liu2@xxxxxxxxxx>
wrote: 
> On Tue, Dec 16, 2014 at 02:32:56PM +0800, Chunyan Liu wrote: 
> > Changes to V8: 
> >   * xl won't manage snapshots, that means it won't maintain json files, 
> >     won't maintain snapshot chain relationship, and then as a result 
> >     won't take care of deleting snapshot and listing snapshots. 
> >   * remove snapshot-delete and snapshot-list interface 
> >   * update snapshot-revert interface 
> >   * update snapshot-create/revert implementaion 
> >  
> > =========================================================================== 
> >  
> > XL Design 
> >  
> > 1. User Interface 
> >  
> > xl snapshot-create: 
> >   Create a snapshot (disk and RAM) of a domain. 
> >  
> >   SYNOPSIS: 
> >     snapshot-create <domain> [<cfgfile>] [--name <string>] [--live] 
> >  
> >   OPTIONS: 
> >     --name <string>  snapshot name 
> >     --live           take a live snapshot 
> >  
> >     If option includes --live, then the domain is not paused while creating 
> >     the snapshot, like live migration. This increases size of the memory 
> >     dump file, but reducess downtime of the guest. 
> >  
> >     If option doens't include --name, a default name will be generated 
> >     according to the creation time. 
> >  
> >     If specify @cfgfile, use cfgfile. (e.g. if --name specifies a name, 
> >     meanwhile there is name specified in cfgfile, name in cfgfile will 
> >     be used.) 
> >  
> >  
> > xl snapshot-revert: 
> >   Revert domain to status of a snapshot. 
> >  
> >   SYNOPSIS: 
> >       snapshot-revert <domain> <cfgfile> [--running] [--force] 
> >  
> >   OPTIONS: 
> >     --running        after reverting, change state to running 
> >     --force          try harder on risky reverts 
> >  
> >     Normally, the domain will revert to the same state the domain was in  
> while 
> >     the snapshot was taken (whether running, or paused). 
> >  
> >     If option includes --running, then overrides the snapshot state to 
> >     guarantee a running domain after the revert. 
> >  
> >  
> >  
> > 2. cfgfile syntax 
> >  
> > #snapshot name. If user doesn't provide a VM snapshot name, xl will  
> generate 
> > #a name automatically by the creation time. 
> > name="" 
> >  
> > #snapshot description. Default is NULL. 
> > description="" 
> >  
> > #memory location. This field should be filled when memory=1. Default is  
> NULL. 
> > memory_path="" 
> >  
> > #disk snapshot information 
> > #For easier parse config work, reuse disk configuration in xl.cfg, but 
> > #with different meanings. 
> > #disk syntax meaning: 'external path, external format, target device' 
> >  
> > #e.g. to specify exernal disk snapshot, like this: 
> > #disks=['/tmp/hda_snapshot.qcow2,qcow2,hda', 
> >         '/tmp/hdb_snapshot.qcow2,qcow2,hdb',] 
> >  
> > #e.g. to specify internal disk snapshot, like this: 
> > disks=[',,hda',',,hdb',] 
> >  
>  
> How is snapshot chain represented with this syntax? Does xl not need to 
> know about the chain? (Note, this is different than managing the chain) 

If only supply creating snapshot and restoring domain from a snapshot,
xl doesn't need to know the chain.

For creating snapshot, it's very easy to understand, no matter from base
or from a snapshot, saving memory and taking disk snapshot has no
difference. 

For restoring domain from snapshot, restoring memory has no difference;
applying disk snapshot, to those backend types we can expect:
qcow2 internal snapshot: no need to know chain
vhd, qcow2 external disk snapshot: both external disk snapshot, and 
both using backing file chain to implement, so apply disk snapshot
is very simple, just use the external snapshot file.
lvm: doesn't support snapshot of snapshot, so no such problem.
So, overall, it doesn't need to know the chain either.

> 
> Wei. 
>  
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel