Re: [RFC V8 2/3] libxl domain snapshot API design

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

On Tue, 2014-11-25 at 02:08 -0700, Chun Yan Liu wrote:
> Hi, Ian,
> 
> According to previous discussion, snapshot delete and revert are
> inclined to be done by high level application itself, won't supply a
> libxl API.

I thought you had explained a scenario where the toolstack needed to be
at least aware of delete, specifically when you are deleting a snapshot
from the middle of an active chain. 

Maybe that's not "snapshot delete API in libxl" though, but rather a
notification API which the toolstack can use to tell libxl something is
going on.

>  I'm wondering snapshot create need a new common API?
> In fact its main work is save domain and take disk snapshot, xl can
> do it too. 

I don't believe xl can take a disk snapshot of an active disk, it
doesn't have the machinery to deal with that sort of thing, nor should
it, this is exactly the sort of thing which libxl is provided to deal
with.

Also, libxl is driving the migration/memory snapshot, and I think the
disk snapshot fundamentally needs to be involved in that process, not
done separately by the toolstack.

> I just write down an overview of the snapshot work (see below).
> The problem is: do we need to export API? What kind of API?
> In updating Bamvor's code, I think xl can do all the work, libvirt can
> do the work too even without libxl's help.
> 
> Of course, there are some thing if put in libxl, it will be easier to
> use, like the domain snapshot info structure, gentype.py will
> directly generate useful init/dispose/to_json/from_json functions.
> Or the disk snapshot part can be extracted and placed in libxl or libxlu.
> 
> Any suggestions about which part is better to be extracted as libxl
> API or better not?
> 
> Thanks,
> Chunyan
> 
> ------------------------------------------------------------------------------------------------------
> libxl domain snapshot overview

Just to be 100% clear: This is an overview of a domain snapshot
architecture for a toolstack which uses libxl. A bunch of the things
described here belong to the toolstack and not to libxl itself.

I've tried to read with that in mind but a complete document should
mention this and be careful to be clear about the distinction where it
matters.

> 0. Glossary
[...]
> * not support disk-only snapshot [1].
>                                        
> [1]
>  This is different from "libvirt".
>  To xl, it only concerns active domains, and even when domain
>  is paused, there is no data flush to disk operation. So, take
>  a disk-only snapshot and then resume, it is as if the guest
>  had crashed. For this reason, disk-only snapshot is meaningless
>  to xl. Should not support.
> 
>  To libvirt, it has active domains and inactive domains, for
>  the active domains, as "xl", it's meaning less to take disk-only
>  snapshot, but for inactive domains, disk-only snapshot is valid.
>  Should support.

Do you mean to say here that disk-only snapshots are not supported in
some toolstacks, or in no toolstack? Or are you just saying that libxl
doesn't need to support them because they only apply to inactive
domains?

In either case it seems to me like your footnote is saying that you *do*
want to support disk-only snapshots, at least in some stacks and/or
configurations.

I think you probably mean to say that disk-only snapshots of *active*
domains are not supported. Whereas disk-only snapshots of inactive
domains may or may not be depending on the toolstack.

> 
> 2. Requirements
> 
> General Requirements:
> * ability to save/restore domain memory
> * ability to create/delete/apply disk snapshot [2]
> * ability to parse user config file
> * ability to save/load/update domain snapshot metadata (or called
>   domain snapshot info, the metadata at least includes:
>   snapshot name, create time, description, memory state file,
>   disk snapshot info, parent (in snapshot chain), current (is
>   currently applied))
> 
> [2] Disk snapshot requirements:
> * external tools: qemu-img, lvcreate, vhd-util, etc.
> * For a basic goal, we support 'raw' and 'qcow2' backend types only.
>   Then only requires qemu:
>     use libxl qmp command (better) or "qemu-img"

You should leave these implementation details for a later section, in
this context they just invite quibbling about whether things belong in
libxl etc and whether qmp commands are "better".

The rest looks ok, but without the remainder of the design described in
terms of the concepts given here it's hard to comment further.

I'd suggest putting this all into one coherent document (not 3 as
before) which starts by describing the terminology (section 0 in your
mail which I'm replying to now), then gives an overview of the
architecture (the rest of that mail), then describe which components
(libxl, toolstack, etc) implement each bit of the architecture, then
describe the libxl API which makes this possible (covered in previous
mails I think).

I think you have most of the words either here or from the other mails,
they just need putting together into a single thing and going through to
make sure that they use the same terminology and describe the same
things etc.

Please take a look at
http://xenbits.xen.org/people/dvrabel/event-channels-H.pdf or
http://lists.xen.org/archives/html/xen-devel/2014-10/msg03235.html for
examples of the sort of cohesive document I mean.

Ian.