All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC v2] vm snapshot documents
@ 2014-04-18 10:10 Bamvor Jian Zhang
  2014-04-23  3:31 ` Jim Fehlig
  2014-05-02 14:03 ` Ian Campbell
  0 siblings, 2 replies; 7+ messages in thread
From: Bamvor Jian Zhang @ 2014-04-18 10:10 UTC (permalink / raw)
  To: xen-devel
  Cc: Zhiqiang Zhou, Ian Campbell, Ian Jackson, Chun Yan Liu,
	Jim Fehlig, Anthony.perard

Hi,

here is the second version about vm snapshot documents, the first version is
here[1]

thanks Ian Jackson suggestion, i write this doc about vm snapshot including new
command, struct and api. currently, the disk snapshot(create, delete, list)
worked(patch is already sent[2]), and vm snapshot(create, delete, list) work.
but i have some questions about snapshot apply(see the last section).

feel free to comment it. thanks.

1, new command
=head1 SNAPSHOT

there are two types of snapshots supported by libxl: disk snapshot and vm
snapshot. The following subcommands management the snapshot of a domain,
including create, delete, list and apply.
a domain snapshot(or a vm snapshot) means save the domain config, memory and
disk snapshot. currently, only support qcow2 and internal disk snapshot.

the vm snapshot information will store in the follow path:
/var/lib/xen/snapshots/<domain_uuid>/snapshotdata-<snapshot_name>.xl

here is an example for snapshot information file:
snapshot_name="1397207577"
snapshot_creationtime="1397207577"
snapshot_save="/var/lib/xen/snapshots/5c84adcc-bd59-788a-96d2-195f9b599cfe/1397207577.save"

the user could give a snapshot name when vm snapshot created. if not, the epoch
seconds will set as name as the above examples.

=over 4

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

create vm snapshot.
it will call the qmp transaction for creating the disk snapshot in order to
ensure the disk snapshot is coherence.
vm is paused during snapshot create, and is unpause after take snapshot
finished.

B<OPTIONS>

=over 4

=item B<-n>

vm snapshot name

=back

=item B<vm-snapshot-delete> [I<OPTIONS>] I<domain-id>

delete vm snapshot.
delete the saved memory file and snapshot information file created by
vm-snapshot-create.

B<OPTIONS>

=over 4

=item B<-n>

vm snapshot name

=back

=item B<vm-snapshot-list> I<domain-id>

list vm snapshot for the dedicated domain including snapshot name and creation
time which stored in the vm snapshot information file.

=item B<vm-snapshot-apply> [I<OPTIONS>] I<domain-id>

apply vm snapshot for the dedicated domain.

B<OPTIONS>

=over 4

=item B<-n>

vm snapshot name

=back

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

create disk snapshot.

B<OPTIONS>

=over 4

=item B<-n>

disk snapshot name

=back

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

delete disk snapshot by snapshot name or snapshot id.

B<OPTIONS>

=over 4

=item B<-i>

disk snapshot id

=item B<-n>

disk snapshot name

=back

=item B<disk-snapshot-list> I<domain-id>

list disk snapshot including snapshot id, tag, vm size, date, vm clock.

=back

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

libxl_snapshot = Struct("snapshot",[
    ("device",        string),
    ("name",          string),
    ("id",            string),
    ("vm_state_size", uint64),
    ("date_sec",      uint64),
    ("date_nsec",     uint64),
    ("vm_clock_sec",  uint64),
    ("vm_clock_nsec", uint64),

(2), libxl_vm_snapshot store vm snapshot information which store in the path
shown above. i add some api for create, delete and list these information.
at first, i want to add these information to xenstore, but it will lose when
xenstore reboot or dom0 reboot.

libxl_vm_snapshot = Struct("vm_snapshot",[
    ("name",          string),
    ("creation_time", uint64),
    ("save",          string),
    ])

2), new api
(1), in libxl/libxl.h
/* disk snapshot api
 * support create, delete and list for internal snapshot of a single disk
 * only support internal snapshot rigt now.
 */
/* create disk snapshot according to the device name in snapshot array. nb is
 * the number of snapshot array.
 * use the qmp transaction to ensure all snapshot of disk is coherence.
 */
int libxl_disk_snapshot_create(libxl_ctx *ctx, int domid,
                               libxl_snapshot *snapshot, int nb);
/* delete number of nb disk snapshot describe in snapshot array
 */
int libxl_disk_snapshot_delete(libxl_ctx *ctx, int domid,
                               libxl_snapshot *snapshot, int nb);
int libxl__disk_snapshot_delete(libxl_ctx *ctx, int domid,
                                libxl_snapshot *snapshot);
/* apply the disk snapshot by qemu-img command
 */
int libxl_disk_snapshot_apply(libxl_ctx *ctx, int domid,
                              libxl_snapshot *snapshot, int nb);
/* list disk snapshot by qmp query-block command
 */
int libxl__disk_snapshot_list(libxl_ctx *ctx, int domid,
                              libxl_snapshot **snapshotp);

/* vm snapshot api
 */
/* write vm snapshot information to file
 */
int libxl_vm_snapshot_add(libxl_ctx *ctx, uint32_t domid,
                          libxl_vm_snapshot *snapshot,
                          const libxl_asyncop_how *ao_how)
                          LIBXL_EXTERNAL_CALLERS_ONLY;
/* delete vm snapshot information file
 */
int libxl_vm_snapshot_remove(libxl_ctx *ctx, uint32_t domid,
                             libxl_vm_snapshot *snapshot,
                             const libxl_asyncop_how *ao_how)
                             LIBXL_EXTERNAL_CALLERS_ONLY;
/* list vm snapshot from file
 */
libxl_vm_snapshot *libxl_vm_snapshot_list(libxl_ctx *ctx, uint32_t domid,
                                          int *num)
                                          LIBXL_EXTERNAL_CALLERS_ONLY;
/* read vm snapshot information from dedicated file
 */
int libxl_vm_snapshot_getinfo(libxl_ctx *ctx, uint32_t domid,
                              libxl_vm_snapshot *snapshot);
/* delete vm save image */
int libxl_vm_snapshot_delete_save_image(libxl_ctx *ctx,
                                        libxl_vm_snapshot *snapshot);

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

3, question
1), how to do disk snapshot apply?
when i apply the vm snapshot, i need to revert the disk snapshot. in qemu, it is
done by bdrv_snapshot_goto api. this api is only called by loadvm hmp or
qemu-img commands.
there is no hmp api in libxl. so the only choice is using qemu-img command.
i know usually i should call qmp for qemu operation. but there is not qmp at
the moment, could i call qemu-img in libxl for disk snapshot apply?

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC v2] vm snapshot documents
  2014-04-18 10:10 [RFC v2] vm snapshot documents Bamvor Jian Zhang
@ 2014-04-23  3:31 ` Jim Fehlig
  2014-04-23 10:18   ` Bamvor Jian Zhang
  2014-05-02 14:03 ` Ian Campbell
  1 sibling, 1 reply; 7+ messages in thread
From: Jim Fehlig @ 2014-04-23  3:31 UTC (permalink / raw)
  To: Bamvor Jian Zhang
  Cc: Zhiqiang Zhou, Ian Campbell, Ian Jackson, Chun Yan Liu,
	xen-devel, Anthony.perard

Bamvor Jian Zhang wrote:
> Hi,
>
> here is the second version about vm snapshot documents, the first version is
> here[1]
>   

Hi Bamvor,

Thanks for being adventurous and starting this work :-).

> thanks Ian Jackson suggestion, i write this doc about vm snapshot including new
> command, struct and api. currently, the disk snapshot(create, delete, list)
> worked(patch is already sent[2]), and vm snapshot(create, delete, list) work.
> but i have some questions about snapshot apply(see the last section).
>
> feel free to comment it. thanks.
>
> 1, new command
> =head1 SNAPSHOT
>
> there are two types of snapshots supported by libxl: disk snapshot and vm
> snapshot.

Here and throughout, you should be consistent with the use of 'vm'
verses 'domain'. For the most part, the existing docs use 'domain'.

It would be good to provide more detail about these types of snapshots
too. E.g. a 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.

>  The following subcommands management the snapshot of a domain,
> including create, delete, list and apply.
>   

I struggle over apply vs revert, but lean toward the latter.

> a domain snapshot(or a vm snapshot) means save the domain config, memory and
> disk snapshot. currently, only support qcow2 and internal disk snapshot.
>
> the vm snapshot information will store in the follow path:
> /var/lib/xen/snapshots/<domain_uuid>/snapshotdata-<snapshot_name>.xl
>
> here is an example for snapshot information file:
> snapshot_name="1397207577"
> snapshot_creationtime="1397207577"
> snapshot_save="/var/lib/xen/snapshots/5c84adcc-bd59-788a-96d2-195f9b599cfe/1397207577.save"
>   

The snapshot prefix seems redundant. A 'description' entry would be
useful too.

> the user could give a snapshot name when vm snapshot created. if not, the epoch
> seconds will set as name as the above examples.
>
> =over 4
>
> =item B<vm-snapshot-create> [I<OPTIONS>] I<domain-id>
>
> create vm snapshot.
> it will call the qmp transaction for creating the disk snapshot in order to
> ensure the disk snapshot is coherence.
> vm is paused during snapshot create, and is unpause after take snapshot
> finished.
>   

I think the user should be able to choose whether to live snapshot vs
pausing/unpausing, via an option. E.g. 'xl snapshot-create <dom> ...
--live'.

> B<OPTIONS>
>
> =over 4
>
> =item B<-n>
>
> vm snapshot name
>
> =back
>
> =item B<vm-snapshot-delete> [I<OPTIONS>] I<domain-id>
>   

This should take a snapshot name, since a domain could have several.

> delete vm snapshot.
> delete the saved memory file and snapshot information file created by
> vm-snapshot-create.
>
> B<OPTIONS>
>
> =over 4
>
> =item B<-n>
>
> vm snapshot name
>
> =back
>
> =item B<vm-snapshot-list> I<domain-id>
>
> list vm snapshot for the dedicated domain including snapshot name and creation
> time which stored in the vm snapshot information file.
>   

This could behave like domain listing in xl. E.g. 'xl snapshot-list
<dom>' will list all snapshots. 'xl snapshot-list --long <dom>' will
list detailed info about all snapshots. 'xl snapshot-list --long <dom>
<snapshot-name>' will list detailed info on the requested snapshot.

> =item B<vm-snapshot-apply> [I<OPTIONS>] I<domain-id>
>
> apply vm snapshot for the dedicated domain.
>
> B<OPTIONS>
>
> =over 4
>
> =item B<-n>
>
> vm snapshot name
>
> =back
>
> =item B<disk-snapshot-create> [I<OPTIONS>] I<domain-id>
>
> create disk snapshot.
>
> B<OPTIONS>
>
> =over 4
>
> =item B<-n>
>
> disk snapshot name
>
> =back
>
> =item B<disk-snapshot-delete> [I<OPTIONS>] I<domain-id>
>
> delete disk snapshot by snapshot name or snapshot id.
>
> B<OPTIONS>
>
> =over 4
>
> =item B<-i>
>
> disk snapshot id
>
> =item B<-n>
>
> disk snapshot name
>
> =back
>
> =item B<disk-snapshot-list> I<domain-id>
>
> list disk snapshot including snapshot id, tag, vm size, date, vm clock.
>
> =back
>   

IMO, the vm-snapshot-* and disk-snapshot-* subcommands can be combined
into one snapshot-*, and passing an option for disk only snapshots. E.g.
'xl snapshot-create <dom> ... --disk-only'.

> 2, new struct and new api
> 1), new struct
> (1), libxl_snapshot struct store a disk snapshot information, which get from
> qcow2 image through "query-block" qmp command.
>
> libxl_snapshot = Struct("snapshot",[
>     ("device",        string),
>   

Should this be libxl_device_disk instead of a string? And should
multiple be supported, allowing control over which of a domain's disks
are included in the snapshot?

>     ("name",          string),
>   

"description" would be helpful.

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

A lot of these are read-only and wouldn't be provided when calling
libxl_snapshot_create(). I think adding the domain state at time of
snapshot would be useful. There are probably other items I'm not
considering atm, which makes me nervous about future extensibility.

> (2), libxl_vm_snapshot store vm snapshot information which store in the path
> shown above. i add some api for create, delete and list these information.
> at first, i want to add these information to xenstore, but it will lose when
> xenstore reboot or dom0 reboot.
>
> libxl_vm_snapshot = Struct("vm_snapshot",[
>     ("name",          string),
>     ("creation_time", uint64),
>     ("save",          string),
>     ])
>
> 2), new api
> (1), in libxl/libxl.h
> /* disk snapshot api
>  * support create, delete and list for internal snapshot of a single disk
>  * only support internal snapshot rigt now.
>  */
> /* create disk snapshot according to the device name in snapshot array. nb is
>  * the number of snapshot array.
>  * use the qmp transaction to ensure all snapshot of disk is coherence.
>  */
> int libxl_disk_snapshot_create(libxl_ctx *ctx, int domid,
>                                libxl_snapshot *snapshot, int nb);
> /* delete number of nb disk snapshot describe in snapshot array
>  */
> int libxl_disk_snapshot_delete(libxl_ctx *ctx, int domid,
>                                libxl_snapshot *snapshot, int nb);
> int libxl__disk_snapshot_delete(libxl_ctx *ctx, int domid,
>                                 libxl_snapshot *snapshot);
> /* apply the disk snapshot by qemu-img command
>  */
> int libxl_disk_snapshot_apply(libxl_ctx *ctx, int domid,
>                               libxl_snapshot *snapshot, int nb);
> /* list disk snapshot by qmp query-block command
>  */
> int libxl__disk_snapshot_list(libxl_ctx *ctx, int domid,
>                               libxl_snapshot **snapshotp);
>
> /* vm snapshot api
>  */
> /* write vm snapshot information to file
>  */
> int libxl_vm_snapshot_add(libxl_ctx *ctx, uint32_t domid,
>                           libxl_vm_snapshot *snapshot,
>                           const libxl_asyncop_how *ao_how)
>                           LIBXL_EXTERNAL_CALLERS_ONLY;
> /* delete vm snapshot information file
>  */
> int libxl_vm_snapshot_remove(libxl_ctx *ctx, uint32_t domid,
>                              libxl_vm_snapshot *snapshot,
>                              const libxl_asyncop_how *ao_how)
>                              LIBXL_EXTERNAL_CALLERS_ONLY;
> /* list vm snapshot from file
>  */
> libxl_vm_snapshot *libxl_vm_snapshot_list(libxl_ctx *ctx, uint32_t domid,
>                                           int *num)
>                                           LIBXL_EXTERNAL_CALLERS_ONLY;
> /* read vm snapshot information from dedicated file
>  */
> int libxl_vm_snapshot_getinfo(libxl_ctx *ctx, uint32_t domid,
>                               libxl_vm_snapshot *snapshot);
> /* delete vm save image */
> int libxl_vm_snapshot_delete_save_image(libxl_ctx *ctx,
>                                         libxl_vm_snapshot *snapshot);
>   

IMO, these too should be combined into libxl_snapshot_*(), with disk vs
domain snapshot controlled via a flags argument.

> (2), libxl/xl_cmdimpl.c
> /* get disk device name (hda, hdc..) and image path through
>  * libxl_device_disk_list and libxl_device_disk_getinfo
>  */
> static int get_disk(uint32_t domid, libxl_snapshot **snapshotp, char *name);
>
> 3, question
> 1), how to do disk snapshot apply?
> when i apply the vm snapshot, i need to revert the disk snapshot. in qemu, it is
> done by bdrv_snapshot_goto api. this api is only called by loadvm hmp or
> qemu-img commands.
> there is no hmp api in libxl. so the only choice is using qemu-img command.
> i know usually i should call qmp for qemu operation. but there is not qmp at
> the moment, could i call qemu-img in libxl for disk snapshot apply?
>   

Similar to the libvirt qemu driver, is it possible to use both qmp and
hmp monitors in libxl?

Regards,
Jim

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC v2] vm snapshot documents
  2014-04-23  3:31 ` Jim Fehlig
@ 2014-04-23 10:18   ` Bamvor Jian Zhang
  2014-05-07  7:31     ` David kiarie
  0 siblings, 1 reply; 7+ messages in thread
From: Bamvor Jian Zhang @ 2014-04-23 10:18 UTC (permalink / raw)
  To: Jim Fehlig
  Cc: Zhiqiang Zhou, Ian Campbell, Ian Jackson, Chun Yan Liu,
	xen-devel, Anthony.perard

Hi,

 >>>Jim Fehlig <jfehlig@suse.com> wrote: 
> Bamvor Jian Zhang wrote:
> > Hi,
> > here is the second version about vm snapshot documents, the first version is
> > here[1]
> Hi Bamvor,
>
> Thanks for being adventurous and starting this work :-).
thanks for your reply.
>
> > thanks Ian Jackson suggestion, i write this doc about vm snapshot including
> > new
> > command, struct and api. currently, the disk snapshot(create, delete, list)
> > worked(patch is already sent[2]), and vm snapshot(create, delete, list) work.
> > but i have some questions about snapshot apply(see the last section).
> >
> > feel free to comment it. thanks.
> >
> > 1, new command
> > =head1 SNAPSHOT
> >
> > there are two types of snapshots supported by libxl: disk snapshot and vm
> > snapshot.
>
> Here and throughout, you should be consistent with the use of 'vm'
> verses 'domain'. For the most part, the existing docs use 'domain'.
>
> It would be good to provide more detail about these types of snapshots
> too. E.g. a 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.
thanks, i will add more description in next version.
>
> >  The following subcommands management the snapshot of a domain,
> > including create, delete, list and apply.
> >
>
> I struggle over apply vs revert, but lean toward the latter.
so as to me.
>
> > a domain snapshot(or a vm snapshot) means save the domain config, memory and
> > disk snapshot. currently, only support qcow2 and internal disk snapshot.
> >
> > the vm snapshot information will store in the follow path:
> > /var/lib/xen/snapshots/<domain_uuid>/snapshotdata-<snapshot_name>.xl
> >
> > here is an example for snapshot information file:
> > snapshot_name="1397207577"
> > snapshot_creationtime="1397207577"
> > snapshot_save="/var/lib/xen/snapshots/5c84adcc-bd59-788a-96d2-195f9b599cfe/1397207577.save"
> >
>
> The snapshot prefix seems redundant. A 'description' entry would be
> useful too.
ok.
>
> > the user could give a snapshot name when vm snapshot created. if not, the
> > epoch
> > seconds will set as name as the above examples.
> >
> > =over 4
> >
> > =item B<vm-snapshot-create> [I<OPTIONS>] I<domain-id>
> >
> > create vm snapshot.
> > it will call the qmp transaction for creating the disk snapshot in order to
> > ensure the disk snapshot is coherence.
> > vm is paused during snapshot create, and is unpause after take snapshot
> > finished.
> >
>
> I think the user should be able to choose whether to live snapshot vs
> pausing/unpausing, via an option. E.g. 'xl snapshot-create <dom> ...
> --live'.
i agree that live snapshot may be useful. meanwhile i am not sure how could i
implement the live snapshot. it might be hard to ensure the consistent between
memory and disk.
>
> > B<OPTIONS>
> >
> > =over 4
> >
> > =item B<-n>
> >
> > vm snapshot name
> >
> > =back
> >
> > =item B<vm-snapshot-delete> [I<OPTIONS>] I<domain-id>
> >
>
> This should take a snapshot name, since a domain could have several.
yes, see the option "-n" below.
>
> > delete vm snapshot.
> > delete the saved memory file and snapshot information file created by
> > vm-snapshot-create.
> >
> > B<OPTIONS>
> >
> > =over 4
> >
> > =item B<-n>
> >
> > vm snapshot name
> >
> > =back
> >
> > =item B<vm-snapshot-list> I<domain-id>
> >
> > list vm snapshot for the dedicated domain including snapshot name and creation
> > time which stored in the vm snapshot information file.
> >
>
> This could behave like domain listing in xl. E.g. 'xl snapshot-list
> <dom>' will list all snapshots. 'xl snapshot-list --long <dom>' will
> list detailed info about all snapshots. 'xl snapshot-list --long <dom>
> <snapshot-name>' will list detailed info on the requested snapshot.
yeah, it it usefull. i will add this feature.
>
> > =item B<vm-snapshot-apply> [I<OPTIONS>] I<domain-id>
> >
> > apply vm snapshot for the dedicated domain.
> >
> > B<OPTIONS>
> >
> > =over 4
> >
> > =item B<-n>
> >
> > vm snapshot name
> >
> > =back
> >
> > =item B<disk-snapshot-create> [I<OPTIONS>] I<domain-id>
> >
> > create disk snapshot.
> >
> > B<OPTIONS>
> >
> > =over 4
> >
> > =item B<-n>
> >
> > disk snapshot name
> >
> > =back
> >
> > =item B<disk-snapshot-delete> [I<OPTIONS>] I<domain-id>
> >
> > delete disk snapshot by snapshot name or snapshot id.
> >
> > B<OPTIONS>
> >
> > =over 4
> >
> > =item B<-i>
> >
> > disk snapshot id
> >
> > =item B<-n>
> >
> > disk snapshot name
> >
> > =back
> >
> > =item B<disk-snapshot-list> I<domain-id>
> >
> > list disk snapshot including snapshot id, tag, vm size, date, vm clock.
> >
> > =back
> >
>
> IMO, the vm-snapshot-* and disk-snapshot-* subcommands can be combined
> into one snapshot-*, and passing an option for disk only snapshots. E.g.
> 'xl snapshot-create <dom> ... --disk-only'.
sure.
>
> > 2, new struct and new api
> > 1), new struct
> > (1), libxl_snapshot struct store a disk snapshot information, which get from
> > qcow2 image through "query-block" qmp command.
> >
> > libxl_snapshot = Struct("snapshot",[
> >     ("device",        string),
> >
>
> Should this be libxl_device_disk instead of a string? And should
> multiple be supported, allowing control over which of a domain's disks
> are included in the snapshot?
one libxl_snapshot represent one disk. see my comment below.
>
> "description" would be helpful.
>
> >     ("id",            string),
> >     ("vm_state_size", uint64),
> >     ("date_sec",      uint64),
> >     ("date_nsec",     uint64),
> >     ("vm_clock_sec",  uint64),
> >     ("vm_clock_nsec", uint64),
> >
>
> A lot of these are read-only and wouldn't be provided when calling
> libxl_snapshot_create(). I think adding the domain state at time of
> snapshot would be useful.
do you mean the stopped or running state for a domain?
> There are probably other items I'm not
> considering atm, which makes me nervous about future extensibility.
so, how about this?
 libxl_vm_snapshot = Struct("vm_snapshot",[
     ("name",          string),
     ("creation_time", uint64),
     ("save",          string),
+    ("state",         string),
+    ("disks", Array(libxl_snapshot, "num_disks")),
     ])

BTW: maybe i should rename libxl_snapshot to libxl_disk_snapshot?

>
> > (2), libxl_vm_snapshot store vm snapshot information which store in the path
> > shown above. i add some api for create, delete and list these information.
> > at first, i want to add these information to xenstore, but it will lose when
> > xenstore reboot or dom0 reboot.
> >
> > libxl_vm_snapshot = Struct("vm_snapshot",[
> >     ("name",          string),
> >     ("creation_time", uint64),
> >     ("save",          string),
> >     ])
> >
> > 2), new api
> > (1), in libxl/libxl.h
> > /* disk snapshot api
> >  * support create, delete and list for internal snapshot of a single disk
> >  * only support internal snapshot rigt now.
> >  */
> > /* create disk snapshot according to the device name in snapshot array. nb is
> >  * the number of snapshot array.
> >  * use the qmp transaction to ensure all snapshot of disk is coherence.
> >  */
> > int libxl_disk_snapshot_create(libxl_ctx *ctx, int domid,
> >                                libxl_snapshot *snapshot, int nb);
> > /* delete number of nb disk snapshot describe in snapshot array
> >  */
> > int libxl_disk_snapshot_delete(libxl_ctx *ctx, int domid,
> >                                libxl_snapshot *snapshot, int nb);
> > int libxl__disk_snapshot_delete(libxl_ctx *ctx, int domid,
> >                                 libxl_snapshot *snapshot);
> > /* apply the disk snapshot by qemu-img command
> >  */
> > int libxl_disk_snapshot_apply(libxl_ctx *ctx, int domid,
> >                               libxl_snapshot *snapshot, int nb);
> > /* list disk snapshot by qmp query-block command
> >  */
> > int libxl__disk_snapshot_list(libxl_ctx *ctx, int domid,
> >                               libxl_snapshot **snapshotp);
> >
> > /* vm snapshot api
> >  */
> > /* write vm snapshot information to file
> >  */
> > int libxl_vm_snapshot_add(libxl_ctx *ctx, uint32_t domid,
> >                           libxl_vm_snapshot *snapshot,
> >                           const libxl_asyncop_how *ao_how)
> >                           LIBXL_EXTERNAL_CALLERS_ONLY;
> > /* delete vm snapshot information file
> >  */
> > int libxl_vm_snapshot_remove(libxl_ctx *ctx, uint32_t domid,
> >                              libxl_vm_snapshot *snapshot,
> >                              const libxl_asyncop_how *ao_how)
> >                              LIBXL_EXTERNAL_CALLERS_ONLY;
> > /* list vm snapshot from file
> >  */
> > libxl_vm_snapshot *libxl_vm_snapshot_list(libxl_ctx *ctx, uint32_t domid,
> >                                           int *num)
> >                                           LIBXL_EXTERNAL_CALLERS_ONLY;
> > /* read vm snapshot information from dedicated file
> >  */
> > int libxl_vm_snapshot_getinfo(libxl_ctx *ctx, uint32_t domid,
> >                               libxl_vm_snapshot *snapshot);
> > /* delete vm save image */
> > int libxl_vm_snapshot_delete_save_image(libxl_ctx *ctx,
> >                                         libxl_vm_snapshot *snapshot);
> >
>
> IMO, these too should be combined into libxl_snapshot_*(), with disk vs
> domain snapshot controlled via a flags argument.
maybe the function name is not clear. i will call the above function in the
libxl_snapshot_create(), like this:
libxl_snapshot_create()
{
    //save memory
    save_domain
    //get disk list
    get_disk
    //create disk snapshot according to disk list
    libxl__disk_snapshot_create
    //store snapshot information to file, maybe libxl_snapshot_store is more
    //clear?
    libxl_snapshot_add
    //unpause
    libxl_domain_unpause
}

but i have some problems while i write libxl_snapshot_* apis.
firstly, there are different routines about vm save/restore because in libvirt
the driver need to interact between libvirtd.
secondly, i want to reuse the save_domain, create_domain in xl_cmdimpl.c.
so, it is hard to me to provided the domain snapshot api directly. if i only
provide some sub-command for domain snapshot, it just like
libxl_domain_suspend in save_doman or libxl_domain_new in create_domain, it
might be easier for libvirt driver to implement snapshot.
is it make sense? or is there a better way to provide the domain snapshot api?

>
> > (2), libxl/xl_cmdimpl.c
> > /* get disk device name (hda, hdc..) and image path through
> >  * libxl_device_disk_list and libxl_device_disk_getinfo
> >  */
> > static int get_disk(uint32_t domid, libxl_snapshot **snapshotp, char *name);
> >
> > 3, question
> > 1), how to do disk snapshot apply?
> > when i apply the vm snapshot, i need to revert the disk snapshot. in qemu, it
> > is
> > done by bdrv_snapshot_goto api. this api is only called by loadvm hmp or
> > qemu-img commands.
> > there is no hmp api in libxl. so the only choice is using qemu-img command.
> > i know usually i should call qmp for qemu operation. but there is not qmp at
> > the moment, could i call qemu-img in libxl for disk snapshot apply?
> >
>
> Similar to the libvirt qemu driver, is it possible to use both qmp and
> hmp monitors in libxl?
after check the qemu code, i found that there is a qmp command
(human-monitor-command) could send hmp through qmp. so i could use loadvm and
savevm in xen.
loadvm will restore vm state and disk snapshot. i could call savevm for domain
snapshot in order to provide the qemu save file for loadvm.
for the snapshot with external snapshot, i will call save_domain for memory
save and qmp transaction for disk snapshot.
as a result, similar to libvirt, create support external disk snapshot. but
revert do not support.
and i will call different vm memory save function: qemu_save_device_state and
qemu_savevm_state depends on.

                                create        revert      mem save api
without external disk snasphot  savevm        loadvm      qemu_save_device_state

with external disk snasphot     save_domain   no support  qemu_savevm_state
                                +transaction

is it make sense?


regards

bamvor
>
> Regards,
> Jim

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC v2] vm snapshot documents
  2014-04-18 10:10 [RFC v2] vm snapshot documents Bamvor Jian Zhang
  2014-04-23  3:31 ` Jim Fehlig
@ 2014-05-02 14:03 ` Ian Campbell
  2014-05-09 16:25   ` Bamvor Jian Zhang
  1 sibling, 1 reply; 7+ messages in thread
From: Ian Campbell @ 2014-05-02 14:03 UTC (permalink / raw)
  To: Bamvor Jian Zhang
  Cc: Zhiqiang Zhou, Ian Jackson, Chun Yan Liu, xen-devel, Jim Fehlig,
	Anthony.perard

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 2, new struct and new api

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

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

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

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

What is this? Which device?

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

ID of what?

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

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

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

What is "save"?

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

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

Is libxl_snapshot really libxl_disk_snapshot?

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

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

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

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

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

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

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

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

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

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

What is this?

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

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

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

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

Ian.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC v2] vm snapshot documents
  2014-04-23 10:18   ` Bamvor Jian Zhang
@ 2014-05-07  7:31     ` David kiarie
  2014-05-07  9:10       ` Bamvor Jian Zhang
  0 siblings, 1 reply; 7+ messages in thread
From: David kiarie @ 2014-05-07  7:31 UTC (permalink / raw)
  To: Bamvor Jian Zhang
  Cc: Zhiqiang Zhou, Ian Campbell, Ian Jackson, Chun Yan Liu,
	xen-devel, Jim Fehlig, Anthony.perard

On Wed, Apr 23, 2014 at 1:18 PM, Bamvor Jian Zhang <bjzhang@suse.com> wrote:
> Hi,
>
>  >>>Jim Fehlig <jfehlig@suse.com> wrote:
>> Bamvor Jian Zhang wrote:
>> > Hi,
>> > here is the second version about vm snapshot documents, the first version is
>> > here[1]
>> Hi Bamvor,
>>
>> Thanks for being adventurous and starting this work :-).
> thanks for your reply.
>>
>> > thanks Ian Jackson suggestion, i write this doc about vm snapshot including
>> > new
>> > command, struct and api. currently, the disk snapshot(create, delete, list)
>> > worked(patch is already sent[2]), and vm snapshot(create, delete, list) work.
>> > but i have some questions about snapshot apply(see the last section).
>> >
>> > feel free to comment it. thanks.
>> >
>> > 1, new command
>> > =head1 SNAPSHOT
>> >
>> > there are two types of snapshots supported by libxl: disk snapshot and vm
>> > snapshot.
>>
>> Here and throughout, you should be consistent with the use of 'vm'
>> verses 'domain'. For the most part, the existing docs use 'domain'.
>>
>> It would be good to provide more detail about these types of snapshots
>> too. E.g. a 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.
> thanks, i will add more description in next version.
>>
>> >  The following subcommands management the snapshot of a domain,
>> > including create, delete, list and apply.
>> >
>>
>> I struggle over apply vs revert, but lean toward the latter.
> so as to me.
>>
>> > a domain snapshot(or a vm snapshot) means save the domain config, memory and
>> > disk snapshot. currently, only support qcow2 and internal disk snapshot.
>> >
>> > the vm snapshot information will store in the follow path:
>> > /var/lib/xen/snapshots/<domain_uuid>/snapshotdata-<snapshot_name>.xl
>> >
>> > here is an example for snapshot information file:
>> > snapshot_name="1397207577"
>> > snapshot_creationtime="1397207577"
>> > snapshot_save="/var/lib/xen/snapshots/5c84adcc-bd59-788a-96d2-195f9b599cfe/1397207577.save"
>> >
>>
>> The snapshot prefix seems redundant. A 'description' entry would be
>> useful too.
> ok.
>>
>> > the user could give a snapshot name when vm snapshot created. if not, the
>> > epoch
>> > seconds will set as name as the above examples.
>> >
>> > =over 4
>> >
>> > =item B<vm-snapshot-create> [I<OPTIONS>] I<domain-id>
>> >
>> > create vm snapshot.
>> > it will call the qmp transaction for creating the disk snapshot in order to
>> > ensure the disk snapshot is coherence.
>> > vm is paused during snapshot create, and is unpause after take snapshot
>> > finished.
>> >
>>
>> I think the user should be able to choose whether to live snapshot vs
>> pausing/unpausing, via an option. E.g. 'xl snapshot-create <dom> ...
>> --live'.
> i agree that live snapshot may be useful. meanwhile i am not sure how could i
> implement the live snapshot. it might be hard to ensure the consistent between
> memory and disk.
>>
>> > B<OPTIONS>
>> >
>> > =over 4
>> >
>> > =item B<-n>
>> >
>> > vm snapshot name
>> >
>> > =back
>> >
>> > =item B<vm-snapshot-delete> [I<OPTIONS>] I<domain-id>
>> >
>>
>> This should take a snapshot name, since a domain could have several.
> yes, see the option "-n" below.
>>
>> > delete vm snapshot.
>> > delete the saved memory file and snapshot information file created by
>> > vm-snapshot-create.
>> >
>> > B<OPTIONS>
>> >
>> > =over 4
>> >
>> > =item B<-n>
>> >
>> > vm snapshot name
>> >
>> > =back
>> >
>> > =item B<vm-snapshot-list> I<domain-id>
>> >
>> > list vm snapshot for the dedicated domain including snapshot name and creation
>> > time which stored in the vm snapshot information file.
>> >
>>
>> This could behave like domain listing in xl. E.g. 'xl snapshot-list
>> <dom>' will list all snapshots. 'xl snapshot-list --long <dom>' will
>> list detailed info about all snapshots. 'xl snapshot-list --long <dom>
>> <snapshot-name>' will list detailed info on the requested snapshot.
> yeah, it it usefull. i will add this feature.
>>
>> > =item B<vm-snapshot-apply> [I<OPTIONS>] I<domain-id>
>> >
>> > apply vm snapshot for the dedicated domain.
>> >
>> > B<OPTIONS>
>> >
>> > =over 4
>> >
>> > =item B<-n>
>> >
>> > vm snapshot name
>> >
>> > =back
>> >
>> > =item B<disk-snapshot-create> [I<OPTIONS>] I<domain-id>
>> >
>> > create disk snapshot.
>> >
>> > B<OPTIONS>
>> >
>> > =over 4
>> >
>> > =item B<-n>
>> >
>> > disk snapshot name
>> >
>> > =back
>> >
>> > =item B<disk-snapshot-delete> [I<OPTIONS>] I<domain-id>
>> >
>> > delete disk snapshot by snapshot name or snapshot id.
>> >
>> > B<OPTIONS>
>> >
>> > =over 4
>> >
>> > =item B<-i>
>> >
>> > disk snapshot id
>> >
>> > =item B<-n>
>> >
>> > disk snapshot name
>> >
>> > =back
>> >
>> > =item B<disk-snapshot-list> I<domain-id>
>> >
>> > list disk snapshot including snapshot id, tag, vm size, date, vm clock.
>> >
>> > =back
>> >
>>
>> IMO, the vm-snapshot-* and disk-snapshot-* subcommands can be combined
>> into one snapshot-*, and passing an option for disk only snapshots. E.g.
>> 'xl snapshot-create <dom> ... --disk-only'.
> sure.
>>
>> > 2, new struct and new api
>> > 1), new struct
>> > (1), libxl_snapshot struct store a disk snapshot information, which get from
>> > qcow2 image through "query-block" qmp command.
>> >
>> > libxl_snapshot = Struct("snapshot",[
>> >     ("device",        string),
>> >
>>
>> Should this be libxl_device_disk instead of a string? And should
>> multiple be supported, allowing control over which of a domain's disks
>> are included in the snapshot?
> one libxl_snapshot represent one disk. see my comment below.
>>
>> "description" would be helpful.
>>
>> >     ("id",            string),
>> >     ("vm_state_size", uint64),
>> >     ("date_sec",      uint64),
>> >     ("date_nsec",     uint64),
>> >     ("vm_clock_sec",  uint64),
>> >     ("vm_clock_nsec", uint64),
>> >
>>
>> A lot of these are read-only and wouldn't be provided when calling
>> libxl_snapshot_create(). I think adding the domain state at time of
>> snapshot would be useful.
> do you mean the stopped or running state for a domain?
>> There are probably other items I'm not
>> considering atm, which makes me nervous about future extensibility.
> so, how about this?
>  libxl_vm_snapshot = Struct("vm_snapshot",[
>      ("name",          string),
>      ("creation_time", uint64),
>      ("save",          string),
> +    ("state",         string),
> +    ("disks", Array(libxl_snapshot, "num_disks")),
>      ])
>
> BTW: maybe i should rename libxl_snapshot to libxl_disk_snapshot?
>
>>
>> > (2), libxl_vm_snapshot store vm snapshot information which store in the path
>> > shown above. i add some api for create, delete and list these information.
>> > at first, i want to add these information to xenstore, but it will lose when
>> > xenstore reboot or dom0 reboot.
>> >
>> > libxl_vm_snapshot = Struct("vm_snapshot",[
>> >     ("name",          string),
>> >     ("creation_time", uint64),
>> >     ("save",          string),
>> >     ])
>> >
>> > 2), new api
>> > (1), in libxl/libxl.h
>> > /* disk snapshot api
>> >  * support create, delete and list for internal snapshot of a single disk
>> >  * only support internal snapshot rigt now.
>> >  */
>> > /* create disk snapshot according to the device name in snapshot array. nb is
>> >  * the number of snapshot array.
>> >  * use the qmp transaction to ensure all snapshot of disk is coherence.
>> >  */
>> > int libxl_disk_snapshot_create(libxl_ctx *ctx, int domid,
>> >                                libxl_snapshot *snapshot, int nb);
>> > /* delete number of nb disk snapshot describe in snapshot array
>> >  */
>> > int libxl_disk_snapshot_delete(libxl_ctx *ctx, int domid,
>> >                                libxl_snapshot *snapshot, int nb);
>> > int libxl__disk_snapshot_delete(libxl_ctx *ctx, int domid,
>> >                                 libxl_snapshot *snapshot);
>> > /* apply the disk snapshot by qemu-img command
>> >  */
>> > int libxl_disk_snapshot_apply(libxl_ctx *ctx, int domid,
>> >                               libxl_snapshot *snapshot, int nb);
>> > /* list disk snapshot by qmp query-block command
>> >  */
>> > int libxl__disk_snapshot_list(libxl_ctx *ctx, int domid,
>> >                               libxl_snapshot **snapshotp);
>> >
>> > /* vm snapshot api
>> >  */
>> > /* write vm snapshot information to file
>> >  */
>> > int libxl_vm_snapshot_add(libxl_ctx *ctx, uint32_t domid,
>> >                           libxl_vm_snapshot *snapshot,
>> >                           const libxl_asyncop_how *ao_how)
>> >                           LIBXL_EXTERNAL_CALLERS_ONLY;
>> > /* delete vm snapshot information file
>> >  */
>> > int libxl_vm_snapshot_remove(libxl_ctx *ctx, uint32_t domid,
>> >                              libxl_vm_snapshot *snapshot,
>> >                              const libxl_asyncop_how *ao_how)
>> >                              LIBXL_EXTERNAL_CALLERS_ONLY;
>> > /* list vm snapshot from file
>> >  */
>> > libxl_vm_snapshot *libxl_vm_snapshot_list(libxl_ctx *ctx, uint32_t domid,
>> >                                           int *num)
>> >                                           LIBXL_EXTERNAL_CALLERS_ONLY;
>> > /* read vm snapshot information from dedicated file
>> >  */
>> > int libxl_vm_snapshot_getinfo(libxl_ctx *ctx, uint32_t domid,
>> >                               libxl_vm_snapshot *snapshot);
>> > /* delete vm save image */
>> > int libxl_vm_snapshot_delete_save_image(libxl_ctx *ctx,
>> >                                         libxl_vm_snapshot *snapshot);
>> >
>>
>> IMO, these too should be combined into libxl_snapshot_*(), with disk vs
>> domain snapshot controlled via a flags argument.

Yes, I also think so.
I was also thinking that one struct could be used to represent all
snapshot(vm and disk) information.
We should have some flags in the struct indicating the contents of the
structure whether disk_snapshot,vm_snapshot, or system checkpoint.This
can be implemented using enums or a bit mask.

That done,we can libxl_snapshot_*() functions controlled by a flags
argument for creation,deletion,listing,reverting and deleting

> maybe the function name is not clear. i will call the above function in the
> libxl_snapshot_create(), like this:
> libxl_snapshot_create()
> {
>     //save memory
>     save_domain
>     //get disk list
>     get_disk
>     //create disk snapshot according to disk list
>     libxl__disk_snapshot_create
>     //store snapshot information to file, maybe libxl_snapshot_store is more
>     //clear?
>     libxl_snapshot_add
>     //unpause
>     libxl_domain_unpause
> }
>
> but i have some problems while i write libxl_snapshot_* apis.
> firstly, there are different routines about vm save/restore because in libvirt
> the driver need to interact between libvirtd.
> secondly, i want to reuse the save_domain, create_domain in xl_cmdimpl.c.
> so, it is hard to me to provided the domain snapshot api directly. if i only
> provide some sub-command for domain snapshot, it just like
> libxl_domain_suspend in save_doman or libxl_domain_new in create_domain, it
> might be easier for libvirt driver to implement snapshot.
> is it make sense? or is there a better way to provide the domain snapshot api?
>
>>
>> > (2), libxl/xl_cmdimpl.c
>> > /* get disk device name (hda, hdc..) and image path through
>> >  * libxl_device_disk_list and libxl_device_disk_getinfo
>> >  */
>> > static int get_disk(uint32_t domid, libxl_snapshot **snapshotp, char *name);
>> >
>> > 3, question
>> > 1), how to do disk snapshot apply?
>> > when i apply the vm snapshot, i need to revert the disk snapshot. in qemu, it
>> > is
>> > done by bdrv_snapshot_goto api. this api is only called by loadvm hmp or
>> > qemu-img commands.
>> > there is no hmp api in libxl. so the only choice is using qemu-img command.
>> > i know usually i should call qmp for qemu operation. but there is not qmp at
>> > the moment, could i call qemu-img in libxl for disk snapshot apply?
>> >
>>
>> Similar to the libvirt qemu driver, is it possible to use both qmp and
>> hmp monitors in libxl?
> after check the qemu code, i found that there is a qmp command
> (human-monitor-command) could send hmp through qmp. so i could use loadvm and
> savevm in xen.
> loadvm will restore vm state and disk snapshot. i could call savevm for domain
> snapshot in order to provide the qemu save file for loadvm.
> for the snapshot with external snapshot, i will call save_domain for memory
> save and qmp transaction for disk snapshot.
> as a result, similar to libvirt, create support external disk snapshot. but
> revert do not support.
> and i will call different vm memory save function: qemu_save_device_state and
> qemu_savevm_state depends on.
>
>                                 create        revert      mem save api
> without external disk snasphot  savevm        loadvm      qemu_save_device_state
>
> with external disk snasphot     save_domain   no support  qemu_savevm_state
>                                 +transaction
>
> is it make sense?
>
>
> regards
>
> bamvor
>>
>> Regards,
>> Jim
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC v2] vm snapshot documents
  2014-05-07  7:31     ` David kiarie
@ 2014-05-07  9:10       ` Bamvor Jian Zhang
  0 siblings, 0 replies; 7+ messages in thread
From: Bamvor Jian Zhang @ 2014-05-07  9:10 UTC (permalink / raw)
  To: David kiarie
  Cc: Zhiqiang Zhou, Ian Campbell, Ian Jackson, Chun Yan Liu,
	xen-devel, Jim Fehlig, Anthony.perard

Hi, david

 >>>David kiarie <davidkiarie4@gmail.com> wrote: 
> On Wed, Apr 23, 2014 at 1:18 PM, Bamvor Jian Zhang <bjzhang@suse.com> wrote: 
> > Hi, 
> > 
> >  >>>Jim Fehlig <jfehlig@suse.com> wrote: 
> >> Bamvor Jian Zhang wrote: 
> >> > Hi, 
> >> > here is the second version about vm snapshot documents, the first version  
> is 
> >> > here[1] 
> >> Hi Bamvor, 
> >> 
> >> Thanks for being adventurous and starting this work :-). 
> > thanks for your reply. 
...
> >> > 2, new struct and new api 
> >> > 1), new struct 
> >> > (1), libxl_snapshot struct store a disk snapshot information, which get  
> from 
> >> > qcow2 image through "query-block" qmp command. 
> >> > 
> >> > libxl_snapshot = Struct("snapshot",[ 
> >> >     ("device",        string), 
> >> > 
> >> 
> >> Should this be libxl_device_disk instead of a string? And should 
> >> multiple be supported, allowing control over which of a domain's disks 
> >> are included in the snapshot? 
> > one libxl_snapshot represent one disk. see my comment below. 
> >> 
> >> "description" would be helpful. 
> >> 
> >> >     ("id",            string), 
> >> >     ("vm_state_size", uint64), 
> >> >     ("date_sec",      uint64), 
> >> >     ("date_nsec",     uint64), 
> >> >     ("vm_clock_sec",  uint64), 
> >> >     ("vm_clock_nsec", uint64), 
> >> > 
> >> 
> >> A lot of these are read-only and wouldn't be provided when calling 
> >> libxl_snapshot_create(). I think adding the domain state at time of 
> >> snapshot would be useful. 
> > do you mean the stopped or running state for a domain? 
> >> There are probably other items I'm not 
> >> considering atm, which makes me nervous about future extensibility. 
> > so, how about this? 
> >  libxl_vm_snapshot = Struct("vm_snapshot",[ 
> >      ("name",          string), 
> >      ("creation_time", uint64), 
> >      ("save",          string), 
> > +    ("state",         string), 
> > +    ("disks", Array(libxl_snapshot, "num_disks")), 
> >      ]) 
> > 
> > BTW: maybe i should rename libxl_snapshot to libxl_disk_snapshot? 
> > 
> >> 
> >> > (2), libxl_vm_snapshot store vm snapshot information which store in the  
> path 
> >> > shown above. i add some api for create, delete and list these information. 
> >> > at first, i want to add these information to xenstore, but it will lose  
> when 
> >> > xenstore reboot or dom0 reboot. 
> >> > 
> >> > libxl_vm_snapshot = Struct("vm_snapshot",[ 
> >> >     ("name",          string), 
> >> >     ("creation_time", uint64), 
> >> >     ("save",          string), 
> >> >     ]) 
> >> > 
> >> > 2), new api 
> >> > (1), in libxl/libxl.h 
> >> > /* disk snapshot api 
> >> >  * support create, delete and list for internal snapshot of a single disk 
> >> >  * only support internal snapshot rigt now. 
> >> >  */ 
> >> > /* create disk snapshot according to the device name in snapshot array. nb  
> is 
> >> >  * the number of snapshot array. 
> >> >  * use the qmp transaction to ensure all snapshot of disk is coherence. 
> >> >  */ 
> >> > int libxl_disk_snapshot_create(libxl_ctx *ctx, int domid, 
> >> >                                libxl_snapshot *snapshot, int nb); 
> >> > /* delete number of nb disk snapshot describe in snapshot array 
> >> >  */ 
> >> > int libxl_disk_snapshot_delete(libxl_ctx *ctx, int domid, 
> >> >                                libxl_snapshot *snapshot, int nb); 
> >> > int libxl__disk_snapshot_delete(libxl_ctx *ctx, int domid, 
> >> >                                 libxl_snapshot *snapshot); 
> >> > /* apply the disk snapshot by qemu-img command 
> >> >  */ 
> >> > int libxl_disk_snapshot_apply(libxl_ctx *ctx, int domid, 
> >> >                               libxl_snapshot *snapshot, int nb); 
> >> > /* list disk snapshot by qmp query-block command 
> >> >  */ 
> >> > int libxl__disk_snapshot_list(libxl_ctx *ctx, int domid, 
> >> >                               libxl_snapshot **snapshotp); 
> >> > 
> >> > /* vm snapshot api 
> >> >  */ 
> >> > /* write vm snapshot information to file 
> >> >  */ 
> >> > int libxl_vm_snapshot_add(libxl_ctx *ctx, uint32_t domid, 
> >> >                           libxl_vm_snapshot *snapshot, 
> >> >                           const libxl_asyncop_how *ao_how) 
> >> >                           LIBXL_EXTERNAL_CALLERS_ONLY; 
> >> > /* delete vm snapshot information file 
> >> >  */ 
> >> > int libxl_vm_snapshot_remove(libxl_ctx *ctx, uint32_t domid, 
> >> >                              libxl_vm_snapshot *snapshot, 
> >> >                              const libxl_asyncop_how *ao_how) 
> >> >                              LIBXL_EXTERNAL_CALLERS_ONLY; 
> >> > /* list vm snapshot from file 
> >> >  */ 
> >> > libxl_vm_snapshot *libxl_vm_snapshot_list(libxl_ctx *ctx, uint32_t domid, 
> >> >                                           int *num) 
> >> >                                           LIBXL_EXTERNAL_CALLERS_ONLY; 
> >> > /* read vm snapshot information from dedicated file 
> >> >  */ 
> >> > int libxl_vm_snapshot_getinfo(libxl_ctx *ctx, uint32_t domid, 
> >> >                               libxl_vm_snapshot *snapshot); 
> >> > /* delete vm save image */ 
> >> > int libxl_vm_snapshot_delete_save_image(libxl_ctx *ctx, 
> >> >                                         libxl_vm_snapshot *snapshot); 
> >> > 
> >> 
> >> IMO, these too should be combined into libxl_snapshot_*(), with disk vs 
> >> domain snapshot controlled via a flags argument. 
>  
> Yes, I also think so. 
> I was also thinking that one struct could be used to represent all 
> snapshot(vm and disk) information. 
> We should have some flags in the struct indicating the contents of the 
> structure whether disk_snapshot,vm_snapshot, or system checkpoint.This 
> can be implemented using enums or a bit mask. 
>  
> That done,we can libxl_snapshot_*() functions controlled by a flags 
> argument for creation,deletion,listing,reverting and deleting 
except the id/name in vm, disk, there is no common information for vm and disk.
i am not sure how do you want to do, maybe you could give a example?

regardsa

bamvor
 
> > maybe the function name is not clear. i will call the above function in the 
> > libxl_snapshot_create(), like this: 
> > libxl_snapshot_create() 
> > { 
> >     //save memory 
> >     save_domain 
> >     //get disk list 
> >     get_disk 
> >     //create disk snapshot according to disk list 
> >     libxl__disk_snapshot_create 
> >     //store snapshot information to file, maybe libxl_snapshot_store is  
> more 
> >     //clear? 
> >     libxl_snapshot_add 
> >     //unpause 
> >     libxl_domain_unpause 
> > } 
> > 
> > but i have some problems while i write libxl_snapshot_* apis. 
> > firstly, there are different routines about vm save/restore because in  
> libvirt 
> > the driver need to interact between libvirtd. 
> > secondly, i want to reuse the save_domain, create_domain in xl_cmdimpl.c. 
> > so, it is hard to me to provided the domain snapshot api directly. if i  
> only 
> > provide some sub-command for domain snapshot, it just like 
> > libxl_domain_suspend in save_doman or libxl_domain_new in create_domain, it 
> > might be easier for libvirt driver to implement snapshot. 
> > is it make sense? or is there a better way to provide the domain snapshot  
> api? 
> > 
> >> 

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC v2] vm snapshot documents
  2014-05-02 14:03 ` Ian Campbell
@ 2014-05-09 16:25   ` Bamvor Jian Zhang
  0 siblings, 0 replies; 7+ messages in thread
From: Bamvor Jian Zhang @ 2014-05-09 16:25 UTC (permalink / raw)
  To: Ian.Campbell
  Cc: Zhiqiang Zhou, Ian.Jackson, Chun Yan Liu, xen-devel, Jim Fehlig,
	Anthony.perard

Hi, Ian

thanks your reply. sorry reply late.
>
> On Fri, 2014-04-18 at 04:10 -0600, Bamvor Jian Zhang wrote:
> > Hi,
> >
> > here is the second version about vm snapshot documents, the first version is
> > here[1]
>
> Have you considered attending the hackathon and proposing this as a
> topic? See http://wiki.xen.org/wiki/Hackathon/May2014 for details, there
> are not a lot of places remaining...
>
> > thanks Ian Jackson suggestion, i write this doc about vm snapshot including
> > new
> > command, struct and api. currently, the disk snapshot(create, delete, list)
> > worked(patch is already sent[2]), and vm snapshot(create, delete, list) work.
> > but i have some questions about snapshot apply(see the last section).
> >
> > feel free to comment it. thanks.
> >
> > 1, new command
> > =head1 SNAPSHOT
> >
> > there are two types of snapshots supported by libxl: disk snapshot and vm
> > snapshot. The following subcommands management the snapshot of a domain,
> > including create, delete, list and apply.
> > a domain snapshot(or a vm snapshot) means save the domain config, memory and
> > disk snapshot. currently, only support qcow2 and internal disk snapshot.
> >
> > the vm snapshot information will store in the follow path:
> > /var/lib/xen/snapshots/<domain_uuid>/snapshotdata-<snapshot_name>.xl
> >
> > here is an example for snapshot information file:
> > snapshot_name="1397207577"
> > snapshot_creationtime="1397207577"
> > snapshot_save="/var/lib/xen/snapshots/5c84adcc-bd59-788a-96d2-195f9b599cfe/1397207577.save"
> >
> > the user could give a snapshot name when vm snapshot created. if not, the
> > epoch
> > seconds will set as name as the above examples.
>
> This all sounds like internal libxl implementation detail. What might be
> interesting to see would be the libxl library API for causing this stuff
> to happen.
yes, lots of function is implemented in libxl. except the top level of vm
snapshot. the latter one is implemented in the xl_cmdimpl.c. 
>
> At an implementation level I think this could profitably use the
> autogenerated json generators and parsers which the libxl IDL can
> provide (Wei is working on the parsing side now).
the struct is generated by libxl IDL. meanwhile for the snapshot information
file, i use the xlu_cfg_get_xxx for parse the file. i write the file with
my own function. is there some apis for generating xen config like file?
>
> > =over 4
> >
> > =item B<vm-snapshot-create> [I<OPTIONS>] I<domain-id>
> >
> > create vm snapshot.
>
> Which aspects of the VM are snapshotted? Disk you mention. What about
> memory?
vm snapshot include disk and memory.
>
> > it will call the qmp transaction for creating the disk snapshot in order to
> > ensure the disk snapshot is coherence.
>
> I'm not sure if you intend this document to literally become the xl
> manpage at some point or if it is an outline with implementation notes
> sprinkled around.
>
> If this is the manpage then talking about qmp (an implementation detail)
> isn't appropriate here.
sorry for confuse. i want to discuss the implementation. i will write the
dedicated man page with my code.
>
> If this is a implementation note then
yes, it is an implementation notes.
> it is worth considering non-qdisk
> backed snapshots and/or the mechanisms for configuring a domain such
> that it is "snapshotable" (which might for instance put constraints on
> which disk backend is used).
yes, it is worth, but i am not how to deal with non-qdisk backed. currently,
for the qdisk backed: if all the image in a domain support snapshot(qcow2,
qed?), the code support both internal and external snapshot. for others (e.g.
the domain includes raw image disk), only external snapshot is supported.
could i only consider qdisk right now?
>
> > vm is paused during snapshot create, and is unpause after take snapshot
> > finished.
>
> Is there any possibility of a live snapshot?
compare with libvirt qemu case, i guess the live snapshot is live memory save
and external disk snapshot.
> (Might make sense in the
> context of snapshotting memory at the same time)
do you mean do the disk snapshot with memory save at the same time?
>
> > =item B<vm-snapshot-apply> [I<OPTIONS>] I<domain-id>
> >
> > apply vm snapshot for the dedicated domain.
>
> What does "apply" mean here? DO you mean some sort of rollback for a
> running domain? Or just "start this snapshot as a fresh domain"?
it called revert in libvirt. currently, i implement the "apply" for the latter
one. which one do you prefer? in qemu, it seems a rollback. but it will lead
to do more about restore domain memory, i mean i need to write a function like
create_domain(xl_cmdimpl.c) without domain id changes.
>
> It's a bit unusual for an xl level API to provide this sort of
> management of a list of resources. Would it make more sense to structure
> this more like save/restore (where the user provides the filename)?
if i do not save the snapshot list for such domain, i could not provide the vm 
snapshot list command in xl level.
>
> That doesn't constrain other toolstack from providing higher level
> management functionality, providing you design the libxl layer
> correctly.
>
> > =item B<disk-snapshot-create> [I<OPTIONS>] I<domain-id>
> >
> > create disk snapshot.
>
> Hrm. so I got the impression that vm-snapshot was creating disk
> snapshots too. Maybe one is a subset of the other?
yes. i disk-snapshot will be the subset of vm snapshot. and i will add
the --disk-only parameter in vm snapshot command.
>
> Since this is described here in terms of xl and not libxl then how do
> you envisage this working in the absence of any kind of "storage
> manager" like functionality, e.g. describe where the snapshots disks
> should go etc.
for internal snapshot, there is no need to provide the filename.
for external snapshot, the user should provide the filename.
>
> > 2, new struct and new api
>
> It would have been less confusing for me if you would have started at
> the low level (libxl) and then done the higher level stuff (xl) rather
> than vice versa.
thanks your advice. i will rewrite the whole doc to make it more clearer.
>
> > 1), new struct
> > (1), libxl_snapshot struct store a disk snapshot information, which get from
> > qcow2 image through "query-block" qmp command.
>
> This all seems very specific to a particular backend. The API should be
> designed so that it can work with multiple backends, even if the
> implementation only supports qdisk at first.
yeah, understand. these struct are only used by disk snapshot list. it is
useless if we do not need the dedicate disk snapshot list. in fact, the user
could get it with qemu-img command for qcow2.
>
> > libxl_snapshot = Struct("snapshot",[
> >     ("device",        string),
>
> What is this? Which device?
the disk device in vm, such as sda, hda...
>
> >     ("name",          string),
> >     ("id",            string),
>
> ID of what?
the snapshot ID. it is a unique sequence number of each disk snapshot file.
it will be created by qemu when taking disk snapshot.
>
> >     ("vm_state_size", uint64),
> >     ("date_sec",      uint64),
> >     ("date_nsec",     uint64),
> >     ("vm_clock_sec",  uint64),
> >     ("vm_clock_nsec", uint64),
>
> Sounds like we need a time and/or date meta types.
>
> > (2), libxl_vm_snapshot store vm snapshot information which store in the path
> > shown above. i add some api for create, delete and list these information.
> > at first, i want to add these information to xenstore, but it will lose when
> > xenstore reboot or dom0 reboot.
> >
> > libxl_vm_snapshot = Struct("vm_snapshot",[
> >     ("name",          string),
> >     ("creation_time", uint64),
> >     ("save",          string),
>
> What is "save"?
the image path for save vm memory. it is named snapshot_save in snapshot file. 
as i wrote above, the path will be
snapshot_save="/var/lib/xen/snapshots/<uuid>/<snapshot-name>.save"
>
> >     ])
> >
> > 2), new api
> > (1), in libxl/libxl.h
> > /* disk snapshot api
> >  * support create, delete and list for internal snapshot of a single disk
> >  * only support internal snapshot rigt now.
> >  */
> > /* create disk snapshot according to the device name in snapshot array. nb is
> >  * the number of snapshot array.
>
> So the user must supply one of these per guest disk?
yes, if user want to take specific disk snapshot. meanwhile as you Ian Jackson
said, maybe we do not need export these disk snapshot operation for users.
>
> Is libxl_snapshot really libxl_disk_snapshot?
yes.
>
> Should there be some mechanisms to convert from libxl_disk_snapshot to a
> libxl_device_disk so that it can then be attached to a domain? Either a
> utility function or there should be a field in the snapshot.
yeah, i have a api for convert from libxl_device_disk to libxl_disk_snapshot.
it will be called in vm snapshot command.
>
> >  * use the qmp transaction to ensure all snapshot of disk is coherence.
> >  */
> > int libxl_disk_snapshot_create(libxl_ctx *ctx, int domid,
> >                                libxl_snapshot *snapshot, int nb);
>
> None of these seem to have support for async. What if the disk backend
> might take a few seconds to take a snapshot.
>
> (as a thought experiment you might consider taking a snapshot with "dd")
thanks, do you mean ao in create and save?
>
> > /* delete number of nb disk snapshot describe in snapshot array
> >  */
> > int libxl_disk_snapshot_delete(libxl_ctx *ctx, int domid,
> >                                libxl_snapshot *snapshot, int nb);
> > int libxl__disk_snapshot_delete(libxl_ctx *ctx, int domid,
> >                                 libxl_snapshot *snapshot);
> > /* apply the disk snapshot by qemu-img command
>
> There's that "apply" again. What does it mean?
revert. reference my comment above.
>
> >  */
> > int libxl_disk_snapshot_apply(libxl_ctx *ctx, int domid,
> >                               libxl_snapshot *snapshot, int nb);
> > /* list disk snapshot by qmp query-block command
> >  */
> > int libxl__disk_snapshot_list(libxl_ctx *ctx, int domid,
> >                               libxl_snapshot **snapshotp);
>
> I think the resource management aspect here needs careful thought. i.e.
> the management of the backing storage, should it be the responsibility
> of libxl or the toolstack (xl, libvirt) etc.
>
> I have a feeling that libxl should be providing the mechanisms but the
> actual management (i.e. lists of snapshots) will be the toolstack's
> doing -- i.e. doesn't libvirt already have a storage and snapshot
> manager?
libvirt already have such snapshot manager: user need provide filename for
external snapshot file. so as to xl.
for other resource do not provided by libvirt, libxl should manage it.
e.g. the memory file saved by xen, should managed by libxl as i mentioned in
snapshot information file.
>
> > (2), libxl/xl_cmdimpl.c
> > /* get disk device name (hda, hdc..) and image path through
> >  * libxl_device_disk_list and libxl_device_disk_getinfo
> >  */
> > static int get_disk(uint32_t domid, libxl_snapshot **snapshotp, char *name);
>
> What is this?
as we talk above, it convert libxl_device_disk to libxl_disk_snapshot for
domain.
>
> > 3, question
> > 1), how to do disk snapshot apply?
> > when i apply the vm snapshot, i need to revert the disk snapshot. in qemu, it
> > is
> > done by bdrv_snapshot_goto api. this api is only called by loadvm hmp or
> > qemu-img commands.
> > there is no hmp api in libxl. so the only choice is using qemu-img command.
>
> "hmp"? Did you mean "qmp"? I don't think so because there is definitely
> a qmp api in libxl, but I can't htink of anything else.
hmp is another channel for qemu operation. it could be called through qmp i
know this after i send this email.
there are loadvm and savevm hmp in qemu, libxl. it is useful for doing the
internal snapshot. savevm means save qemu memory and do internal disk snapshot.
and loadvm mean revert the snapshot state the one of savevm state.
but it will almost save qemu state twice if the vm snapshot create flow is as
follows:
1, save memory, the core function will be libxl_domain_suspend. it will save
domain memory and qemu state.
after memory save, the domain should remain pause for savevm.
2, call savevm hmp through qemu qmp. the save vm will save qemu memory
(including qemu state saved by step 1) and do internal disk snapshot.

the qemu state is very small, it will not waste a lot. is it ok?

>
> > i know usually i should call qmp for qemu operation. but there is not qmp at
> > the moment, could i call qemu-img in libxl for disk snapshot apply?
>
> In general I think it would be useful to go back and define what you
> actually mean by all these things at a higher semantic layer. i.e. what
> does it mean to "apply" a disk snapshot?
yes, it seems that i need write a new version of this doc for review.
i will update api, struct and implementation details for distinguish
non-live, live snapshot, internal and external snapshot.
meanwhile, IIUC, libvirt/qemu only support revert the non-live, internal
snapshot revert. could i fosus on non-live internal snapshot operations for
the first version of code in next steps?

regards

bamvor

>
> Ian.

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2014-05-09 16:25 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-18 10:10 [RFC v2] vm snapshot documents Bamvor Jian Zhang
2014-04-23  3:31 ` Jim Fehlig
2014-04-23 10:18   ` Bamvor Jian Zhang
2014-05-07  7:31     ` David kiarie
2014-05-07  9:10       ` Bamvor Jian Zhang
2014-05-02 14:03 ` Ian Campbell
2014-05-09 16:25   ` Bamvor Jian Zhang

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.