Re: [Xen-devel] [RFC V7 3/3] xl snapshot-xxx Design

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2014-10-10 at 16:48 +0800, Chunyan Liu wrote:
> 1. xl commandline interface design
> 
> xl snapshot-create:
>   Create a snapshot (disk and RAM) of a domain.
> 
>   SYNOPSIS:
>     snapshot-create <domain> [<cfgfile>] [--disk-only] [--reuse-external]
>     [--live]
> 
>   OPTIONS:
>     [--domain] <string>  domain name, id or uuid
>     [--cfgfile] <string>  domain snapshot configuration

Is this separate to or the same as the <cfgfile> argument? Is this a
xl.cfg(5) config file or something specific to snapshot cfg?

>     --disk-only      capture disk state but not vm state
>     --reuse-external  reuse any existing external files
>     --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. Only support this flag
>     during external checkpoints.
> 
>     If option includes --disk-only, then the snapshot will be limited to
>     the disks, and no VM state will be saved. For an active guest, this is
>     not supported.
> 
>     If specify @cfgfile, cfgfile is prioritized.

What does "prioritized" mean in this context?

> xl snapshot-delete:
>   Delete a snapshot of a domain.

So what's not clear yet (but I see it is discussed below) is the manner
in which xl is going to manage snapshots.

Typically in the past users have been expected to manage disk and save
images with rm(1) and/or various format specific tools (qemu-img,
vhd-image, lvcreate etc).

I think you are proposing that there should be some path full of
snapshots, is that right? That is adding a lot of complexity to xl which
could potentially be avoided by sticking to the "user takes care of it"
path.

> 3. xl structure to maintain VM snapshot info

These are repeating the libxl ones? The look subtly different. If they
are xl specific then they should be in the xl_foo namespace, and of
course the should incorporate public libxl API structs where necessary.

Having the structs be named libxl_* makes it hard for me to see if you
have gotten the layering right in much of the below. I'll try and point
out the ones I think should be xl_* below, if you really meant libxl_*
then that probably means I disagree with the layering.

> According to libxl_domain_snapshot_info, a json file will be saved on disk.

You mean that libxl_domain_snapshot_info (really
xl_domain_snapshot_info) can be serialised to disk as json, right?

> 
> 4. xl snapshot-xxx implementation details

How do these interact with xl create/destroy/shutdown/save/restore?

e.g. does destroying a domain remove any snapshots?

A bunch of these are gong to require some care wrt the possibility of
multiple xl invocations and the possibility of an xl crash.

> "xl snapshot-create"
> 
>     1), parse args or domain snapshot configuration file.
>     2), fill info in libxl_domain_snapshot_args struct according to
>         options or config file.
>     3), call libxl_domain_snapshot_create()
>     4), fill info in libxl_domain_snapshot_info.

xl_domain_snapshot_info?

>     5), save snapshot info in json file under
> "/var/lib/xen/snapshots/domain_uuid"

Do the disk images go here too?

> "xl snapshot-list"
> 
>     1), read all domain snapshot related json file under
>         "/var/lib/xen/snapshots/domain_uuid". Parse each file and fill in
>         libxl_domain_snapshot_info struct.

xl_domain_snapshot_info?

>     2), display information from those libxl_domain_snapshot_info(s)
> 
> "xl snapshot-delete"
> 
>     1), read snapshot json file from
>         "/var/lib/xen/snapshots/domain_uuid/snapshotdata-<snapshot_name>\
>         .libxl-json", parse the file and fill in libxl_domain_snapshot_info

.xl-json and xl_domain_snapshot_info, I think?

>     2), according to parent/children info in libxl_domain_snapshot_info

xl_domain_snapshot_info.

>         and commandline options, decide which domain snapshot to be deleted.
>         To delete each domain snapshot, fill in
>         libxl_domain_snapshot_args and call libxl_domain_snapshot_delete().

Depending on the state of the domain, much of this can be done with
unlink and/or calling out to external tools.

>     3), refresh parent/children relationship, delete json file for those
>         already deleted snapshot.
> 
> "xl snapshot-revert"
> 
>     1), read snapshot json file from
>         "/var/lib/xen/snapshots/domain_uuid/snapshotdata-<snapshot_name>\
>         .libxl-json", parse the file and fill in libxl_domain_snapshot_info.

.xl-json and xl_domain_snapshot_info

>     2), fill in libxl_domain_snapshot_args
>     3). call libxl_domain_snapshot_revert().



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