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

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

>>> On 1/30/2015 at 12:33 AM, in message <1422549191.5198.32.camel@xxxxxxxxxx>, 
>>> Ian
Campbell <Ian.Campbell@xxxxxxxxxx> wrote: 
> On Mon, 2015-01-26 at 11:25 +0800, Chunyan Liu wrote: 
>  
> This is all looking good (including the previous two patches where I 
> didn't have any substantial comments). 
>  
> >     User could specify snapshot information in details through @cfgfile,  
> see 
> >     following cfgfile syntax. If configuration in @cfgfile conflicts with 
> >     other options, @cfgfile will supercede other options. (e.g. if  
> --internal 
> >     conflicts with disk spec in cfgfile, use disk spec in @cfgfile.) 
>  
> Usually I think one would expect the command line to take precedence 
> over a config file. 

OK. That works too. Will change.

>  
> >  
> >  
> > 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 
>  
> We usually talk about paused in the xl interface, e.g. --paused with the 
> default being to run. 
>  
> >     --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). 
>  
> So you need both --paused and --unpause to override both cases? 

Oh, no, maybe the description is confusing. It should be:
if domain is paused when taking snapshot, keep paused after restoreing.
if domain is running when taking snapshot, unpause to let it be running
after restoring. Libvirt keeps domain->state when taking snapshot, so it
can do that automatically; Xl doesn't keep state, so to be simple, we could
just follow xl common behavior:
Normally, the domain will restored from snapshot to a running state.
If -p|--pause specified, do not unpause domain after restoring it.

I'll update. Thanks.

- Chunyan

>  
> >     If option includes --running, then overrides the snapshot state to 
> >     guarantee a running domain after the revert. 
> >  
> >  
> > About domain snapshot delete: 
> >     xl doesn't have snapshot chain information, so it couldn't do the full  
> work. 
> >     If supply: 
> >       xl snapshot-delete <domain> <cfgfile> 
> >     For internal disk snapshot, deleting disk snapshot doesn't need  
> snapshot chain 
> >     info, this commands can finish the work. But for external disk  
> snapshot, 
> >     deleting disk snapshot will need to merge backing file chain, then will 
> >  
> need 
> >     the backing file chain information, this xl command can not finish  
> that. 
> >  
> >     So, deleting domain snapshots will be left to user: 
> >  
> >     user could delete RAM snapshots and disk snapshots by themselves: 
> >     RAM snapshot file: user could remove it directly. 
> >     Disk snapshots: 
> >       - Internal disk snapshot, issue 'qemu-img snapshot -d' 
> >       - External disk snapshot, 
> >  
> >  
> > 2. cfgfile syntax 
> >  
> > # snapshot name. If user doesn't provide a VM snapshot name, xl will  
> generate 
> > # a name automatically by creation time or by @path basename. 
> > name="" 
> >  
> > # save memory or disk-only. 
> > # If memory is '0', doesn't save memory, take disk-only domain snapshot. 
> > # If memory is '1', domain memory is saved. 
> > # Default if 1. 
> > memory=1 
> >  
> > # memory location. This field is valid when memory=1. 
> > # If it is set to "", xl will generate a path by creation time or by @path 
> > # basename. 
> > memory_path="" 
> >  
> > # disk snapshot specification 
> > # For easier parsing config work, reuse disk configuration in xl.cfg, but 
> > # with different meanings. 
> > # disk syntax meaning: 'external path, external format, target device' 
>  
> Note that the actual xl syntax is more complex than this and what you 
> appear to be reusing is the legacy syntax. See 
> docs/misc/xl-disk-configuration.txt 
>  
>  
>  
>  


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