Re: [Xen-devel] [RFC v2] vm snapshot documents

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2014-04-18 at 04:10 -0600, Bamvor Jian Zhang wrote:
> Hi,
> 
> here is the second version about vm snapshot documents, the first version is
> here[1]

Have you considered attending the hackathon and proposing this as a
topic? See http://wiki.xen.org/wiki/Hackathon/May2014 for details, there
are not a lot of places remaining...

> thanks Ian Jackson suggestion, i write this doc about vm snapshot including 
> new
> command, struct and api. currently, the disk snapshot(create, delete, list)
> worked(patch is already sent[2]), and vm snapshot(create, delete, list) work.
> but i have some questions about snapshot apply(see the last section).
> 
> feel free to comment it. thanks.
> 
> 1, new command
> =head1 SNAPSHOT
> 
> there are two types of snapshots supported by libxl: disk snapshot and vm
> snapshot. The following subcommands management the snapshot of a domain,
> including create, delete, list and apply.
> a domain snapshot(or a vm snapshot) means save the domain config, memory and
> disk snapshot. currently, only support qcow2 and internal disk snapshot.
> 
> the vm snapshot information will store in the follow path:
> /var/lib/xen/snapshots/<domain_uuid>/snapshotdata-<snapshot_name>.xl
> 
> here is an example for snapshot information file:
> snapshot_name="1397207577"
> snapshot_creationtime="1397207577"
> snapshot_save="/var/lib/xen/snapshots/5c84adcc-bd59-788a-96d2-195f9b599cfe/1397207577.save"
> 
> the user could give a snapshot name when vm snapshot created. if not, the 
> epoch
> seconds will set as name as the above examples.

This all sounds like internal libxl implementation detail. What might be
interesting to see would be the libxl library API for causing this stuff
to happen.

At an implementation level I think this could profitably use the
autogenerated json generators and parsers which the libxl IDL can
provide (Wei is working on the parsing side now).

> =over 4
> 
> =item B<vm-snapshot-create> [I<OPTIONS>] I<domain-id>
> 
> create vm snapshot.

Which aspects of the VM are snapshotted? Disk you mention. What about
memory?

> it will call the qmp transaction for creating the disk snapshot in order to
> ensure the disk snapshot is coherence.

I'm not sure if you intend this document to literally become the xl
manpage at some point or if it is an outline with implementation notes
sprinkled around.

If this is the manpage then talking about qmp (an implementation detail)
isn't appropriate here.

If this is a implementation note then it is worth considering non-qdisk
backed snapshots and/or the mechanisms for configuring a domain such
that it is "snapshotable" (which might for instance put constraints on
which disk backend is used).

> vm is paused during snapshot create, and is unpause after take snapshot
> finished.

Is there any possibility of a live snapshot? (Might make sense in the
context of snapshotting memory at the same time)

> =item B<vm-snapshot-apply> [I<OPTIONS>] I<domain-id>
> 
> apply vm snapshot for the dedicated domain.

What does "apply" mean here? DO you mean some sort of rollback for a
running domain? Or just "start this snapshot as a fresh domain"?

It's a bit unusual for an xl level API to provide this sort of
management of a list of resources. Would it make more sense to structure
this more like save/restore (where the user provides the filename)?

That doesn't constrain other toolstack from providing higher level
management functionality, providing you design the libxl layer
correctly.

> =item B<disk-snapshot-create> [I<OPTIONS>] I<domain-id>
> 
> create disk snapshot.

Hrm. so I got the impression that vm-snapshot was creating disk
snapshots too. Maybe one is a subset of the other?

Since this is described here in terms of xl and not libxl then how do
you envisage this working in the absence of any kind of "storage
manager" like functionality, e.g. describe where the snapshots disks
should go etc.

> 2, new struct and new api

It would have been less confusing for me if you would have started at
the low level (libxl) and then done the higher level stuff (xl) rather
than vice versa.

> 1), new struct
> (1), libxl_snapshot struct store a disk snapshot information, which get from
> qcow2 image through "query-block" qmp command.

This all seems very specific to a particular backend. The API should be
designed so that it can work with multiple backends, even if the
implementation only supports qdisk at first.

> libxl_snapshot = Struct("snapshot",[
>     ("device",        string),

What is this? Which device?

>     ("name",          string),
>     ("id",            string),

ID of what?

>     ("vm_state_size", uint64),
>     ("date_sec",      uint64),
>     ("date_nsec",     uint64),
>     ("vm_clock_sec",  uint64),
>     ("vm_clock_nsec", uint64),

Sounds like we need a time and/or date meta types.

> (2), libxl_vm_snapshot store vm snapshot information which store in the path
> shown above. i add some api for create, delete and list these information.
> at first, i want to add these information to xenstore, but it will lose when
> xenstore reboot or dom0 reboot.
> 
> libxl_vm_snapshot = Struct("vm_snapshot",[
>     ("name",          string),
>     ("creation_time", uint64),
>     ("save",          string),

What is "save"?

>     ])
> 
> 2), new api
> (1), in libxl/libxl.h
> /* disk snapshot api
>  * support create, delete and list for internal snapshot of a single disk
>  * only support internal snapshot rigt now.
>  */
> /* create disk snapshot according to the device name in snapshot array. nb is
>  * the number of snapshot array.

So the user must supply one of these per guest disk?

Is libxl_snapshot really libxl_disk_snapshot?

Should there be some mechanisms to convert from libxl_disk_snapshot to a
libxl_device_disk so that it can then be attached to a domain? Either a
utility function or there should be a field in the snapshot.

>  * use the qmp transaction to ensure all snapshot of disk is coherence.
>  */
> int libxl_disk_snapshot_create(libxl_ctx *ctx, int domid,
>                                libxl_snapshot *snapshot, int nb);

None of these seem to have support for async. What if the disk backend
might take a few seconds to take a snapshot.

(as a thought experiment you might consider taking a snapshot with "dd")

> /* delete number of nb disk snapshot describe in snapshot array
>  */
> int libxl_disk_snapshot_delete(libxl_ctx *ctx, int domid,
>                                libxl_snapshot *snapshot, int nb);
> int libxl__disk_snapshot_delete(libxl_ctx *ctx, int domid,
>                                 libxl_snapshot *snapshot);
> /* apply the disk snapshot by qemu-img command

There's that "apply" again. What does it mean?

>  */
> int libxl_disk_snapshot_apply(libxl_ctx *ctx, int domid,
>                               libxl_snapshot *snapshot, int nb);
> /* list disk snapshot by qmp query-block command
>  */
> int libxl__disk_snapshot_list(libxl_ctx *ctx, int domid,
>                               libxl_snapshot **snapshotp);

I think the resource management aspect here needs careful thought. i.e.
the management of the backing storage, should it be the responsibility
of libxl or the toolstack (xl, libvirt) etc.

I have a feeling that libxl should be providing the mechanisms but the
actual management (i.e. lists of snapshots) will be the toolstack's
doing -- i.e. doesn't libvirt already have a storage and snapshot
manager?

> (2), libxl/xl_cmdimpl.c
> /* get disk device name (hda, hdc..) and image path through
>  * libxl_device_disk_list and libxl_device_disk_getinfo
>  */
> static int get_disk(uint32_t domid, libxl_snapshot **snapshotp, char *name);

What is this?

> 3, question
> 1), how to do disk snapshot apply?
> when i apply the vm snapshot, i need to revert the disk snapshot. in qemu, it 
> is
> done by bdrv_snapshot_goto api. this api is only called by loadvm hmp or
> qemu-img commands.
> there is no hmp api in libxl. so the only choice is using qemu-img command.

"hmp"? Did you mean "qmp"? I don't think so because there is definitely
a qmp api in libxl, but I can't htink of anything else.

> i know usually i should call qmp for qemu operation. but there is not qmp at
> the moment, could i call qemu-img in libxl for disk snapshot apply?

In general I think it would be useful to go back and define what you
actually mean by all these things at a higher semantic layer. i.e. what
does it mean to "apply" a disk snapshot?

Ian.


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