Re: [Xen-devel] [RFC v3] domain snapshot documents

[David kiarie <davidkiarie4@xxxxxxxxx>]

Again I was thinking about freezing all the file systems before taking a snapshot.Anyway we can add this feature after the minimal snapshot operations patch gets acked.

Regards.

David.

On Mon, Jun 16, 2014 at 9:21 AM, David kiarie <davidkiarie4@xxxxxxxxx> wrote:

On Mon, Jun 9, 2014 at 5:08 PM, Bamvor Jian Zhang <bjzhang@xxxxxxxx> wrote:

Hi, Jim

> Bamvor Jian Zhang wrote:
> > Hi,
> >
> > here is the third version about domain snapshot documents, the second version
> > and the first version is here[1][2].
> >
> > there are lots of potential feature about snapshots. for now, i focus on
> > providing the api for libvirt libxl driver in order to support the same
> > functionality compare with libvirt qemu driver. and you may already notice
> > david is working on libvirt libxl driver. it is a GSoC project[3]. it is
> > important for him to know the api in order to start coding in libvirt side.
> >
>
> Right. ÂWe can't do much on the libvirt side without libxl APIs :-).
>
> > i plan to work on other "advanced feature" after my first stage patch ack.
> >
> > there are two types of snapshots supported by libxl: disk snapshot and domain
> > snapshot and four types of operations: create, delete, list and revert.
> >
>
> Should the operations also include 'info', to get name, creation time,
> disks, etc. on a particular snapshot?

list with --long options will do this: list details of one/all snapshot
information. reference our discuss here[1].

>
> > Disk snapshot will only be crash-consistent if the domain is running. Disk
> > snapshots can also be internal (qcow2) or external (snapshot in one file,
> > delta
> > in another).
> >
> > Domain snapshots include disk snapshots and domain state, allowing to resume
> > the domain from the same state when the snapshot was created. This type of
> > snapshot is also referred to as a domain checkpoint or system checkpoint.
> >
> > In libvirt, there is a something like resource manager for domain snapshot
> > managements. So, in libxl, all these information is transfered through
> > libxl_domain_snapshot struct. xl will manage the snapshot by itself.
> >
> > Domain snapshot create means save domain state and do disk snapshots.
> > At the beginning of domain snapshot create, it will check whether it is
> > snapshotable. it is snapshotable if all the disk is qdisk backed.
> >
> > Domain snapshot revert means rollback the current snapshot state. and
> > Because the limitation of the qemu qmp, the revert could only support domain
> > snapshot with internal disk snapshot. revert the domain snapshot with external
> > snapshot doest not support.
> >
> > there are live flag in snasphot configuration file, it will be save domain
> > memory and do external disk snapshot. to make the thing simple, i do not want
> > to implement in my first verion of patch.
> >
> > As Ian Campbell said, the support of non-qdisk snapshot is very useful.
> > unfortuntely, i have no idea what it need to do. the only non-qdisk i know is
> > blktap. and i do not know does how to do snapshot create, delete, list and
> > revert for blktap? does it support internal or external support?
> >
>
> Looking in tools/blktap2, it seems only external snapshots are supported
> via td-util or vhd-util. ÂI suppose lvm would also be considered an
> external disk snapshot.

thanks. do you mean call these utils in libxl__exec? it seems that only a few
binary called by this functions: bootloader, libxl-save-helper, qemu-dm,
qemu-system-i386.
the core function of vhd_util snapshot is vhd_snashot which defined in
(tools/blktap2/include/libvhd.h, /usr/lib64/libvhd.so). although it included in
xen-devel package in opensuse12.3. maybe it is a better choice?

>
> > i treat it as an "advanced" feature, i will not cover it in my first version
> > of
> > patch.
> >
> > the new struct, api and command is as follows:
> > 1, new struct
> > 1), libxl_snapshot
> > store a disk snapshot information, it is used by disk snapshot create and
> > delete.
> > libxl_disk_snapshot = Struct("disk_snapshot",[
> > Â Â ("device", Â Â Â Âstring),
> > Â Â ("name", Â Â Â Â Âstring),
> > Â Â ("file", Â Â Â Â Âstring),
> > Â Â ("format", Â Â Â Âstring),
> >
>
> Should format be an enum?

yeah, it should be. i will use as libxl_disk_format. i only support qcow2 as
external snapshot image.

>
> > Â Â ])
> >
> > device: device name to snapshot. e.g. sda, hda...
> > name: snapshot name given by user. it will the be same name as domain snapshot
> > name.
> > the following paramenter is only useful for external snapshot.
> > file: external snapshot file.
> > format: the format of external snapshot file
> >
> > 2), libxl_domain_snapshot
> > store domain snapshot information which store in the path shown above. i add
> > some api for create, delete and list these information.
> > libxl_domain_snapshot = Struct("domain_snapshot",[
> > Â Â ("name", Â Â Â Â Âstring),
> > Â Â ("creation_time", uint64),
> > Â Â ("save", Â Â Â Â Âstring),
> > Â Â ("disks", Array(libxl_disk_snapshot, "num_disks")),
> > Â Â ])
> >
>
> I think 'description' and 'state' would be useful fields, the latter
> being the state of the domain when the snapshot was created.

sorry missing this. when you mention state, do you mean the following
combination in libxl_dominfo?
  bool running;
  bool blocked;
  bool paused;
  bool shutdown;
  bool dying;

>
> > name: snapshot name given by user. if user do not provide the name, it will be
> > the epoch seconds.
> > creation_time: the epoch seconds.
> > save: the memory save file for this snapshot.
> > disks: store the disk snapshot information assoiate with this domain.
> >
> > 2, new functions
> > there is no common api like libxl_snapshot_xxx. the reason is that different
> > toolstack may need to different event handling machanism(synchronize or
> > asynchronize). and obviously, domain snapshot create need async handler. so i
> > decide to only provide the sub api for xl and other toolstack(e.g. libvirt).
> > it make eailer for toolstack to handle the event by themselves.
> >
>
> What is the domain_snapshot struct used for then? ÂSeems it is unneeded
> if not exposed in the API, something to be declared by the app. ÂI'd
> like to hear what the Xen tools devs think about this approach. ÂIan J,
> Ian C, Anthony?

currently, libxl_domain_snapshot is only used by xl_cmdimpl.c.
domain load snapshot configuration may be useful when libvirt libxl driver
want to load libxl snapshot configuration.
there is a issue i want to discuss with you. do we need libvirt and libxl
use the same domain snapshot configuration? when domain snapshot is created
or reloading, use libxl-json format file instead of libvirt xml format. in this
way, it is easy to handle the snapshot if user migrate between libxl and libvirt
toolstack.

Â

In my opinion, this will require a lot of changes on the libvirt side.Libvirt depends very heavily on the xml.

I don't know if this will look hacky but I would prefer the file management code on libxl to be include in the API.

What I suggest is the file management code to be wrapped inside the exposed API.

Anyway we should hear from Jim but in the meantime I continue working with the xml.

>
> > 1), in libxl/libxl.h
> > the implementation will be located in libxl_snapshot.c
> > /* disk snapshot api
> > Â* support create for external and internal disks, support delete for internal
> > Â* snapshot of disks.
> > Â*/
> > /* create disk snapshot according to the device name in snapshot array. nb is
> > Â* the number of snapshot array.
> > Â* use the qmp transaction to ensure all snapshot of disk is coherence.
> > Â*/
> > int libxl_disk_snapshot_create(libxl_ctx *ctx, int domid,
> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Âlibxl_disk_snapshot *snapshot, int nb,
> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Âconst libxl_asyncop_how *ao_how);
> > /* delete number of nb disk snapshot describe in snapshot array
> > Â*/
> > int libxl_disk_snapshot_delete(libxl_ctx *ctx, int domid,
> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Âlibxl_disk_snapshot *snapshot, int nb);
> >
>
> As David mentioned in his reply, there should be a revert as well. ÂIs
> list (and info if added) handled by the app (xl, libvirt, etc)?

for revert, reference my previous reply.
for list, it will be handled by the app, just like libvirt qemu driver.

regards

bamvor

[1] http://lists.xen.org/archives/html/xen-devel/2014-04/msg02904.html

>
> > 2), xl_cmdimpl.c
> > int libxl_snapshot_create(int domid, libxl_domain_snapshot *snapshot);
> > int libxl_snapshot_delete(int domid, libxl_domain_snapshot *snapshot);
> > int libxl_snapshot_get(int domid, libxl_domain_snapshot *snapshot, int nb);
> > int libxl_snapshot_revert(int domid, libxl_domain_snapshot *snapshot);
> >
> > support create, delete, list and revert for domain snasphot.
> >
> > libxl_snapshot_get will read the domain snapshot configuration file stored in
> > disk and list snapshot information in simple or long format.
> >
> > 3, snapshot information file
> > i will write manpage for this with patch.
> >
> > i found the Wei v5 patch about xl json format.
> > http://lists.xen.org/archives/html/xen-devel/2014-05/msg01670.html
> > it seems that i could use these apis for parsing and generating the snapshot
> > information file.
> >
>
> Yeah, with all of this work, seems json would be a better way to go.
>
> Regards,
> Jim
>
> > the domain 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:
> > description="a snapshot after installation"
> > name="1397207577"
> > creationtime="1397207577"
> > save="1397207577.save"
> > type="internal"/"external"
> > live="no"
> > disk_only="no"
> > disk=[ 'hda=disk_hda.qcow2,type=qcow2', 'hdc=disk_hdc.qcow2,type=qcow2']
> >
> > the save and disk image file base on the path of
> > "/var/lib/xen/snapshots/<domain_uuid>"
> >
> > the user could give a snapshot name when vm snapshot created. if not, the
> > epoch
> > seconds will set as name as the above examples.
> >
> > 3, new command
> > i will write manpage for this with patch.
> > 1), snapshot-create
> > Usage: xl snapshot-create <ConfigFile> [options] [Domain]
> >
> > Create domain snapshot with ConfigFile or options
> >
> > Options:
> > -n        Âsnapshot name
> > --live      Âdo live snapshot
> > --disk-only    only disk snapshot, do not save memory.
> >
> > 2), snapshot-list
> > Usage: xl snapshot-list [options] [Domain]
> >
> > List domain snapshot information about all/some snapshot in one domain.
> >
> > Options:
> > -l, --long    ÂOutput all domain snapshot details
> > -n        Âsnapshot name
> >
> > 3), snapshot-delete
> > Usage: xl snapshot-delete [options] [Domain]
> >
> > Delete domain snapshot relative data, including domain state, disk snapshot
> > and domain snapshot information file.
> >
> > Options:
> > -n        Âsnapshot name
> >
> > 4), snapshot-revert
> > Usage: xl snapshot-revert [options] [Domain]
> >
> > Rollback the domain to snapshot state.
> >
> > Options:
> > -n        Âsnapshot name
> >
> > [1] http://lists.xen.org/archives/html/xen-devel/2014-04/msg00414.html
> > Â Â http://lists.xen.org/archives/html/xen-devel/2014-04/msg00244.html
> > [2] http://lists.xen.org/archives/html/xen-devel/2014-04/msg02549.html
> > [3]
> > http://en.opensuse.org/openSUSE:GSOC_ideas#Add_virtual_machine_snapshot_support_to_libvirt_Xen_driver
> >
> > changes since v2:
> > 1), reorgnized the whole docments.
> > 2), do not export the dedicated the disk snapshot commands.
> > 3), others changes according to Ian and Jim's comment.
> >
> > regards
> >
> > bamvor
> >
> >

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