|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC v2] vm snapshot documents
Hi,
>>>Jim Fehlig <jfehlig@xxxxxxxx> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |