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

[Ian Campbell <Ian.Campbell@citrix.com>]

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.

> 
> 
> 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?

>     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