Re: [RFC v3] domain snapshot documents

Re: [RFC v3] domain snapshot documents

[Jim Fehlig]

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?

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

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

>     ])
>
> 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.

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

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

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

Re: [RFC v3] domain snapshot documents

[Bamvor Jian Zhang]

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

Re: [RFC v3] domain snapshot documents

[David kiarie]

[-- Attachment #1.1: Type: text/plain, Size: 12053 bytes --]

On Mon, Jun 9, 2014 at 5:08 PM, Bamvor Jian Zhang <bjzhang@suse.com> 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
> > >
> > >
>
>

[-- Attachment #1.2: Type: text/html, Size: 15901 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: [RFC v3] domain snapshot documents

[David kiarie]

[-- Attachment #1.1: Type: text/plain, Size: 12702 bytes --]

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@gmail.com>
wrote:

>
>
>
> On Mon, Jun 9, 2014 at 5:08 PM, Bamvor Jian Zhang <bjzhang@suse.com>
> 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
>> > >
>> > >
>>
>>
>

[-- Attachment #1.2: Type: text/html, Size: 16498 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: [RFC v3] domain snapshot documents

[Bamvor Jian Zhang]

Hi, Jim
> Bamvor Jian Zhang wrote:
> > Hi, David
> >
> >> On Fri, May 16, 2014 at 6:00 PM, Bamvor Jian Zhang <bjzhang@xxxxxxxx> wrote:
> >>
> >>
> >>> Hi, david
> >>>
> >>>
> >>>> On Thu, May 15, 2014 at 4:58 PM, Bamvor Jian Zhang <bjzhang@xxxxxxxx>
> >>>>
> >>> wrote:
> >>>
> >>>>> Hi,
> >>>>>
> >>>>> here is the third version about domain snapshot documents, the second
> >>>>> version
> >>>>> and the first version is here[1][2].
> >>>>>
> >>> ...
> >>>
> >>>>> 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.
> >>>>>
> >>>>> 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);
> >>>>>
> >> Are this the only two functions you are exposing?I mean the API?or am I
> >> getting something wrong?
> >>
> >>
> > there are functions libxl_qmp_loadvm, libxl_qmp_savevm which is called by
> > domain internal snapshot create/revert. currently, they are internal
> > functions.
> > (libxl_intenal.h). but i should expose them, e.g. look like:
> > int libxl_loadvm(libxl_ctx *ctx, int domid, libxl_domain_snapshot *snapshot,
> >                  const libxl_asyncop_how *ao_how);
> > int libxl_savevm(libxl_ctx *ctx, int domid, libxl_domain_snapshot *snapshot,
> >                  const libxl_asyncop_how *ao_how);
> >
>
> IMO, would be better to have libxl_disk_snapshot_create() and
> libxl_disk_snapshot_delete() exposed, and keep these as internal.
i am not sure if i could follow you. i guess you mean we should expose unique
api for dedicate operations. this is what i want.
but the issue is there is no single revert disk snapshot qmp or hmp in qemu.
so, in libvirt qemu driver, internal or external disk snapshot call
loadvm/savevm/delvm and transaction/blockdev-snapshot-sync/
blockdev-snapshot-internal-sync respectively.
IMO, it will be better if qemu support blockdev snapshot revert qmp which expose
bdrv_snapshot_goto to qemu user(e.g. libxl).
i do not know how qemu upstream think about it.  how about discuss it later
when basic snapshot function accept in libxl?

regards

bamvor

>
> Regards,
> Jim
>

Re: [RFC v3] domain snapshot documents

[David kiarie]

On Fri, Jun 6, 2014 at 1:44 AM, Jim Fehlig <jfehlig@suse.com> wrote:
> Bamvor Jian Zhang wrote:
>> Hi, David
>>
>>> On Fri, May 16, 2014 at 6:00 PM, Bamvor Jian Zhang <bjzhang@suse.com> wrote:
>>>
>>>
>>>> Hi, david
>>>>
>>>>
>>>>> On Thu, May 15, 2014 at 4:58 PM, Bamvor Jian Zhang <bjzhang@suse.com>
>>>>>
>>>> wrote:
>>>>
>>>>>> Hi,
>>>>>>
>>>>>> here is the third version about domain snapshot documents, the second
>>>>>> version
>>>>>> and the first version is here[1][2].
>>>>>>
>>>> ...
>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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);
>>>>>>
>>> Are this the only two functions you are exposing?I mean the API?or am I
>>> getting something wrong?
>>>
>>>
>> there are functions libxl_qmp_loadvm, libxl_qmp_savevm which is called by
>> domain internal snapshot create/revert. currently, they are internal functions.
>> (libxl_intenal.h). but i should expose them, e.g. look like:
>> int libxl_loadvm(libxl_ctx *ctx, int domid, libxl_domain_snapshot *snapshot,
>>                  const libxl_asyncop_how *ao_how);
>> int libxl_savevm(libxl_ctx *ctx, int domid, libxl_domain_snapshot *snapshot,
>>                  const libxl_asyncop_how *ao_how);
>>
>
> IMO, would be better to have libxl_disk_snapshot_create() and
> libxl_disk_snapshot_delete() exposed, and keep these as internal.
>

I was stuck at how to create a system checkpoint without these?

> Regards,
> Jim
>

Trivial fix,all "int domid" should be "uint32_t domid"

>

Re: [RFC v3] domain snapshot documents

[Jim Fehlig]

Bamvor Jian Zhang wrote:
> Hi, David
>   
>> On Fri, May 16, 2014 at 6:00 PM, Bamvor Jian Zhang <bjzhang@suse.com> wrote:
>>
>>     
>>> Hi, david
>>>
>>>       
>>>> On Thu, May 15, 2014 at 4:58 PM, Bamvor Jian Zhang <bjzhang@suse.com>
>>>>         
>>> wrote:
>>>       
>>>>> Hi,
>>>>>
>>>>> here is the third version about domain snapshot documents, the second
>>>>> version
>>>>> and the first version is here[1][2].
>>>>>           
>>> ...
>>>       
>>>>> 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.
>>>>>
>>>>> 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);
>>>>>           
>> Are this the only two functions you are exposing?I mean the API?or am I
>> getting something wrong?
>>
>>     
> there are functions libxl_qmp_loadvm, libxl_qmp_savevm which is called by
> domain internal snapshot create/revert. currently, they are internal functions.
> (libxl_intenal.h). but i should expose them, e.g. look like:
> int libxl_loadvm(libxl_ctx *ctx, int domid, libxl_domain_snapshot *snapshot,
>                  const libxl_asyncop_how *ao_how);
> int libxl_savevm(libxl_ctx *ctx, int domid, libxl_domain_snapshot *snapshot,
>                  const libxl_asyncop_how *ao_how);
>   

IMO, would be better to have libxl_disk_snapshot_create() and
libxl_disk_snapshot_delete() exposed, and keep these as internal.

Regards,
Jim

Re: [RFC v3] domain snapshot documents

[David kiarie]

Looks Okay now.

On Mon, May 19, 2014 at 6:45 AM, Bamvor Jian Zhang <bjzhang@suse.com> wrote:
> Hi, David
>> On Fri, May 16, 2014 at 6:00 PM, Bamvor Jian Zhang <bjzhang@suse.com> wrote:
>>
>> > Hi, david
>> >
>> > > On Thu, May 15, 2014 at 4:58 PM, Bamvor Jian Zhang <bjzhang@suse.com>
>> > wrote:
>> > >
>> > > > Hi,
>> > > >
>> > > > here is the third version about domain snapshot documents, the second
>> > > > version
>> > > > and the first version is here[1][2].
>> > ...
>> > > > 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.
>> > > >
>> > > > 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);
>> >
>> Are this the only two functions you are exposing?I mean the API?or am I
>> getting something wrong?
>>
> there are functions libxl_qmp_loadvm, libxl_qmp_savevm which is called by
> domain internal snapshot create/revert. currently, they are internal functions.
> (libxl_intenal.h). but i should expose them, e.g. look like:
> int libxl_loadvm(libxl_ctx *ctx, int domid, libxl_domain_snapshot *snapshot,
>                  const libxl_asyncop_how *ao_how);
> int libxl_savevm(libxl_ctx *ctx, int domid, libxl_domain_snapshot *snapshot,
>                  const libxl_asyncop_how *ao_how);
>
> sorry for confuse.
>
> regards
>
> bamvor
>
>> > > >
>> > > I think we also need revert libxl_disk_snapshot_revert() here.
>> > there are two methods for revert disk snapshot state in qemu: call
>> > "loadvm" hmp
>> > and "qemu-img snapshot -a". and i will call loadvm for reverting the qemu
>> > state
>> > and disk state in libxl_snapshot_create.
>> > user could revert the dedicate disk snapshot with qemu-img when domain is
>> > not
>> > running.it seems not a good idea wrap the qemu-img command in libxl.
>> >
>> > regards
>> >
>> > bamvor
>> >
>
>
>

Re: [RFC v3] domain snapshot documents

[Bamvor Jian Zhang]

Hi, David
> On Fri, May 16, 2014 at 6:00 PM, Bamvor Jian Zhang <bjzhang@suse.com> wrote:
>
> > Hi, david
> >
> > > On Thu, May 15, 2014 at 4:58 PM, Bamvor Jian Zhang <bjzhang@suse.com>
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > here is the third version about domain snapshot documents, the second
> > > > version
> > > > and the first version is here[1][2].
> > ...
> > > > 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.
> > > >
> > > > 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);
> >
> Are this the only two functions you are exposing?I mean the API?or am I
> getting something wrong?
>
there are functions libxl_qmp_loadvm, libxl_qmp_savevm which is called by
domain internal snapshot create/revert. currently, they are internal functions.
(libxl_intenal.h). but i should expose them, e.g. look like:
int libxl_loadvm(libxl_ctx *ctx, int domid, libxl_domain_snapshot *snapshot,
                 const libxl_asyncop_how *ao_how);
int libxl_savevm(libxl_ctx *ctx, int domid, libxl_domain_snapshot *snapshot,
                 const libxl_asyncop_how *ao_how);

sorry for confuse.

regards

bamvor

> > > >
> > > I think we also need revert libxl_disk_snapshot_revert() here.
> > there are two methods for revert disk snapshot state in qemu: call
> > "loadvm" hmp
> > and "qemu-img snapshot -a". and i will call loadvm for reverting the qemu
> > state
> > and disk state in libxl_snapshot_create.
> > user could revert the dedicate disk snapshot with qemu-img when domain is
> > not
> > running.it seems not a good idea wrap the qemu-img command in libxl.
> >
> > regards
> >
> > bamvor
> >

Re: [RFC v3] domain snapshot documents

[David kiarie]

[-- Attachment #1.1: Type: text/plain, Size: 2252 bytes --]

On Fri, May 16, 2014 at 6:00 PM, Bamvor Jian Zhang <bjzhang@suse.com> wrote:

> Hi, david
>
> > On Thu, May 15, 2014 at 4:58 PM, Bamvor Jian Zhang <bjzhang@suse.com>
> wrote:
> >
> > > Hi,
> > >
> > > here is the third version about domain snapshot documents, the second
> > > version
> > > and the first version is here[1][2].
> ...
> > > 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.
> > >
> > > 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);
>
Are this the only two functions you are exposing?I mean the API?or am I
getting something wrong?

>
>
> >
> > >
> > I think we also need revert libxl_disk_snapshot_revert() here.
> there are two methods for revert disk snapshot state in qemu: call
> "loadvm" hmp
> and "qemu-img snapshot -a". and i will call loadvm for reverting the qemu
> state
> and disk state in libxl_snapshot_create.
> user could revert the dedicate disk snapshot with qemu-img when domain is
> not
> running.it seems not a good idea wrap the qemu-img command in libxl.
>
> regards
>
> bamvor
>
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 3555 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: [RFC v3] domain snapshot documents

[Bamvor Jian Zhang]

Hi, david

> On Thu, May 15, 2014 at 4:58 PM, Bamvor Jian Zhang <bjzhang@suse.com> wrote:
>
> > Hi,
> >
> > here is the third version about domain snapshot documents, the second
> > version
> > and the first version is here[1][2].
...
> > 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.
> >
> > 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);
> >
> >
> I think we also need revert libxl_disk_snapshot_revert() here.
there are two methods for revert disk snapshot state in qemu: call "loadvm" hmp
and "qemu-img snapshot -a". and i will call loadvm for reverting the qemu state
and disk state in libxl_snapshot_create.
user could revert the dedicate disk snapshot with qemu-img when domain is not
running.it seems not a good idea wrap the qemu-img command in libxl.

regards

bamvor

Re: [RFC v3] domain snapshot documents

[David kiarie]

[-- Attachment #1.1: Type: text/plain, Size: 8297 bytes --]

On Thu, May 15, 2014 at 4:58 PM, Bamvor Jian Zhang <bjzhang@suse.com> 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.
>

Yes,I can be able to get a lot of work going with some knowledge about the
API but I will still be hanging around to help on anything.

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.
>
> 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?
> 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),
>     ])
>
> 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")),
>     ])
>
> 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.
>
> 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);
>
>
I think we also need revert libxl_disk_snapshot_revert() here.

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

[-- Attachment #1.2: Type: text/html, Size: 10818 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: [RFC v3] domain snapshot documents

[Bamvor Jian Zhang]

Hi, Philipp

thanks for reviewing.
> Hello,
>
> On 15.05.2014 15:58, Bamvor Jian Zhang wrote:
> > Disk snapshot will only be crash-consistent if the domain is running.
>                                                                ^not?
what i mean is that there are three types of consistent, inconsistent,crash-cons
istent, and application-consistent(e.g. a database).
when the domain is running, we could not ensure the application-consistent,
if application do not aware of snapshot. so, we only get crash-consistent.
when the domain is not running. we could get the application-consistent.

regards

bamvor
>
> Sincerely
> Philipp

Re: [RFC v3] domain snapshot documents

[Philipp Hahn]

Hello,

On 15.05.2014 15:58, Bamvor Jian Zhang wrote:
> Disk snapshot will only be crash-consistent if the domain is running.
                                                               ^not?

Sincerely
Philipp

[RFC v3] domain snapshot documents

[Bamvor Jian Zhang]

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

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?
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),
    ])

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")),
    ])

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.

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);

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.

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