|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC v2] vm snapshot documents
On Wed, Apr 23, 2014 at 1:18 PM, Bamvor Jian Zhang <bjzhang@xxxxxxxx> wrote:
> 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.
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@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |