From mboxrd@z Thu Jan 1 00:00:00 1970 From: David kiarie Subject: Re: [RFC v3] domain snapshot documents Date: Mon, 16 Jun 2014 09:51:18 +0300 Message-ID: References: <5375388A0200003000034775@suse.com> <5390F201.9000402@suse.com> <5396306F02000030000399D9@soto.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8022686809812590990==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Bamvor Jian Zhang Cc: Zhiqiang Zhou , Ian Campbell , Ian Jackson , Chun Yan Liu , xen-devel@lists.xen.org, Jim Fehlig , Anthony PERARD List-Id: xen-devel@lists.xenproject.org --===============8022686809812590990== Content-Type: multipart/alternative; boundary=047d7b5d27184e8b3c04fbee747b --047d7b5d27184e8b3c04fbee747b Content-Type: text/plain; charset=UTF-8 Again I was thinking about freezing all the file systems before taking a snapshot.Anyway we can add this feature after the minimal snapshot operations patch gets acked. Regards. David. On Mon, Jun 16, 2014 at 9:21 AM, David kiarie wrote: > > > > On Mon, Jun 9, 2014 at 5:08 PM, Bamvor Jian Zhang > wrote: > >> Hi, Jim >> >> > Bamvor Jian Zhang wrote: >> > > Hi, >> > > >> > > here is the third version about domain snapshot documents, the second >> version >> > > and the first version is here[1][2]. >> > > >> > > there are lots of potential feature about snapshots. for now, i focus >> on >> > > providing the api for libvirt libxl driver in order to support the >> same >> > > functionality compare with libvirt qemu driver. and you may already >> notice >> > > david is working on libvirt libxl driver. it is a GSoC project[3]. it >> is >> > > important for him to know the api in order to start coding in libvirt >> side. >> > > >> > >> > Right. We can't do much on the libvirt side without libxl APIs :-). >> > >> > > i plan to work on other "advanced feature" after my first stage patch >> ack. >> > > >> > > there are two types of snapshots supported by libxl: disk snapshot >> and domain >> > > snapshot and four types of operations: create, delete, list and >> revert. >> > > >> > >> > Should the operations also include 'info', to get name, creation time, >> > disks, etc. on a particular snapshot? >> list with --long options will do this: list details of one/all snapshot >> information. reference our discuss here[1]. >> > >> > > Disk snapshot will only be crash-consistent if the domain is running. >> Disk >> > > snapshots can also be internal (qcow2) or external (snapshot in one >> file, >> > > delta >> > > in another). >> > > >> > > Domain snapshots include disk snapshots and domain state, allowing to >> resume >> > > the domain from the same state when the snapshot was created. This >> type of >> > > snapshot is also referred to as a domain checkpoint or system >> checkpoint. >> > > >> > > In libvirt, there is a something like resource manager for domain >> snapshot >> > > managements. So, in libxl, all these information is transfered through >> > > libxl_domain_snapshot struct. xl will manage the snapshot by itself. >> > > >> > > Domain snapshot create means save domain state and do disk snapshots. >> > > At the beginning of domain snapshot create, it will check whether it >> is >> > > snapshotable. it is snapshotable if all the disk is qdisk backed. >> > > >> > > Domain snapshot revert means rollback the current snapshot state. and >> > > Because the limitation of the qemu qmp, the revert could only support >> domain >> > > snapshot with internal disk snapshot. revert the domain snapshot with >> external >> > > snapshot doest not support. >> > > >> > > there are live flag in snasphot configuration file, it will be save >> domain >> > > memory and do external disk snapshot. to make the thing simple, i do >> not want >> > > to implement in my first verion of patch. >> > > >> > > As Ian Campbell said, the support of non-qdisk snapshot is very >> useful. >> > > unfortuntely, i have no idea what it need to do. the only non-qdisk i >> know is >> > > blktap. and i do not know does how to do snapshot create, delete, >> list and >> > > revert for blktap? does it support internal or external support? >> > > >> > >> > Looking in tools/blktap2, it seems only external snapshots are supported >> > via td-util or vhd-util. I suppose lvm would also be considered an >> > external disk snapshot. >> thanks. do you mean call these utils in libxl__exec? it seems that only a >> few >> binary called by this functions: bootloader, libxl-save-helper, qemu-dm, >> qemu-system-i386. >> the core function of vhd_util snapshot is vhd_snashot which defined in >> (tools/blktap2/include/libvhd.h, /usr/lib64/libvhd.so). although it >> included in >> xen-devel package in opensuse12.3. maybe it is a better choice? >> > >> > > i treat it as an "advanced" feature, i will not cover it in my first >> version >> > > of >> > > patch. >> > > >> > > the new struct, api and command is as follows: >> > > 1, new struct >> > > 1), libxl_snapshot >> > > store a disk snapshot information, it is used by disk snapshot create >> and >> > > delete. >> > > libxl_disk_snapshot = Struct("disk_snapshot",[ >> > > ("device", string), >> > > ("name", string), >> > > ("file", string), >> > > ("format", string), >> > > >> > >> > Should format be an enum? >> yeah, it should be. i will use as libxl_disk_format. i only support qcow2 >> as >> external snapshot image. >> > >> > > ]) >> > > >> > > device: device name to snapshot. e.g. sda, hda... >> > > name: snapshot name given by user. it will the be same name as domain >> snapshot >> > > name. >> > > the following paramenter is only useful for external snapshot. >> > > file: external snapshot file. >> > > format: the format of external snapshot file >> > > >> > > 2), libxl_domain_snapshot >> > > store domain snapshot information which store in the path shown >> above. i add >> > > some api for create, delete and list these information. >> > > libxl_domain_snapshot = Struct("domain_snapshot",[ >> > > ("name", string), >> > > ("creation_time", uint64), >> > > ("save", string), >> > > ("disks", Array(libxl_disk_snapshot, "num_disks")), >> > > ]) >> > > >> > >> > I think 'description' and 'state' would be useful fields, the latter >> > being the state of the domain when the snapshot was created. >> sorry missing this. when you mention state, do you mean the following >> combination in libxl_dominfo? >> bool running; >> bool blocked; >> bool paused; >> bool shutdown; >> bool dying; >> > >> > > name: snapshot name given by user. if user do not provide the name, >> it will be >> > > the epoch seconds. >> > > creation_time: the epoch seconds. >> > > save: the memory save file for this snapshot. >> > > disks: store the disk snapshot information assoiate with this domain. >> > > >> > > 2, new functions >> > > there is no common api like libxl_snapshot_xxx. the reason is that >> different >> > > toolstack may need to different event handling machanism(synchronize >> or >> > > asynchronize). and obviously, domain snapshot create need async >> handler. so i >> > > decide to only provide the sub api for xl and other toolstack(e.g. >> libvirt). >> > > it make eailer for toolstack to handle the event by themselves. >> > > >> > >> > What is the domain_snapshot struct used for then? Seems it is unneeded >> > if not exposed in the API, something to be declared by the app. I'd >> > like to hear what the Xen tools devs think about this approach. Ian J, >> > Ian C, Anthony? >> currently, libxl_domain_snapshot is only used by xl_cmdimpl.c. >> domain load snapshot configuration may be useful when libvirt libxl driver >> want to load libxl snapshot configuration. >> there is a issue i want to discuss with you. do we need libvirt and libxl >> use the same domain snapshot configuration? when domain snapshot is >> created >> or reloading, use libxl-json format file instead of libvirt xml format. >> in this >> way, it is easy to handle the snapshot if user migrate between libxl and >> libvirt >> toolstack. >> > > In my opinion, this will require a lot of changes on the libvirt > side.Libvirt depends very heavily on the xml. > I don't know if this will look hacky but I would prefer the file > management code on libxl to be include in the API. > What I suggest is the file management code to be wrapped inside the > exposed API. > Anyway we should hear from Jim but in the meantime I continue working with > the xml. > > > >> > > 1), in libxl/libxl.h >> > > the implementation will be located in libxl_snapshot.c >> > > /* disk snapshot api >> > > * support create for external and internal disks, support delete for >> internal >> > > * snapshot of disks. >> > > */ >> > > /* create disk snapshot according to the device name in snapshot >> array. nb is >> > > * the number of snapshot array. >> > > * use the qmp transaction to ensure all snapshot of disk is >> coherence. >> > > */ >> > > int libxl_disk_snapshot_create(libxl_ctx *ctx, int domid, >> > > libxl_disk_snapshot *snapshot, int nb, >> > > const libxl_asyncop_how *ao_how); >> > > /* delete number of nb disk snapshot describe in snapshot array >> > > */ >> > > int libxl_disk_snapshot_delete(libxl_ctx *ctx, int domid, >> > > libxl_disk_snapshot *snapshot, int nb); >> > > >> > >> > As David mentioned in his reply, there should be a revert as well. Is >> > list (and info if added) handled by the app (xl, libvirt, etc)? >> for revert, reference my previous reply. >> for list, it will be handled by the app, just like libvirt qemu driver. >> >> regards >> >> bamvor >> >> [1] http://lists.xen.org/archives/html/xen-devel/2014-04/msg02904.html >> >> > >> > > 2), xl_cmdimpl.c >> > > int libxl_snapshot_create(int domid, libxl_domain_snapshot *snapshot); >> > > int libxl_snapshot_delete(int domid, libxl_domain_snapshot *snapshot); >> > > int libxl_snapshot_get(int domid, libxl_domain_snapshot *snapshot, >> int nb); >> > > int libxl_snapshot_revert(int domid, libxl_domain_snapshot *snapshot); >> > > >> > > support create, delete, list and revert for domain snasphot. >> > > >> > > libxl_snapshot_get will read the domain snapshot configuration file >> stored in >> > > disk and list snapshot information in simple or long format. >> > > >> > > 3, snapshot information file >> > > i will write manpage for this with patch. >> > > >> > > i found the Wei v5 patch about xl json format. >> > > http://lists.xen.org/archives/html/xen-devel/2014-05/msg01670.html >> > > it seems that i could use these apis for parsing and generating the >> snapshot >> > > information file. >> > > >> > >> > Yeah, with all of this work, seems json would be a better way to go. >> > >> > Regards, >> > Jim >> > >> > > the domain snapshot information will store in the follow path: >> > > /var/lib/xen/snapshots//snapshotdata-.xl >> > > >> > > here is an example for snapshot information file: >> > > description="a snapshot after installation" >> > > name="1397207577" >> > > creationtime="1397207577" >> > > save="1397207577.save" >> > > type="internal"/"external" >> > > live="no" >> > > disk_only="no" >> > > disk=[ 'hda=disk_hda.qcow2,type=qcow2', >> 'hdc=disk_hdc.qcow2,type=qcow2'] >> > > >> > > the save and disk image file base on the path of >> > > "/var/lib/xen/snapshots/" >> > > >> > > the user could give a snapshot name when vm snapshot created. if not, >> the >> > > epoch >> > > seconds will set as name as the above examples. >> > > >> > > 3, new command >> > > i will write manpage for this with patch. >> > > 1), snapshot-create >> > > Usage: xl snapshot-create [options] [Domain] >> > > >> > > Create domain snapshot with ConfigFile or options >> > > >> > > Options: >> > > -n snapshot name >> > > --live do live snapshot >> > > --disk-only only disk snapshot, do not save memory. >> > > >> > > 2), snapshot-list >> > > Usage: xl snapshot-list [options] [Domain] >> > > >> > > List domain snapshot information about all/some snapshot in one >> domain. >> > > >> > > Options: >> > > -l, --long Output all domain snapshot details >> > > -n snapshot name >> > > >> > > 3), snapshot-delete >> > > Usage: xl snapshot-delete [options] [Domain] >> > > >> > > Delete domain snapshot relative data, including domain state, disk >> snapshot >> > > and domain snapshot information file. >> > > >> > > Options: >> > > -n snapshot name >> > > >> > > 4), snapshot-revert >> > > Usage: xl snapshot-revert [options] [Domain] >> > > >> > > Rollback the domain to snapshot state. >> > > >> > > Options: >> > > -n snapshot name >> > > >> > > [1] >> http://lists.xen.org/archives/html/xen-devel/2014-04/msg00414.html >> > > >> http://lists.xen.org/archives/html/xen-devel/2014-04/msg00244.html >> > > [2] >> http://lists.xen.org/archives/html/xen-devel/2014-04/msg02549.html >> > > [3] >> > > >> http://en.opensuse.org/openSUSE:GSOC_ideas#Add_virtual_machine_snapshot_support_to_libvirt_Xen_driver >> > > >> > > changes since v2: >> > > 1), reorgnized the whole docments. >> > > 2), do not export the dedicated the disk snapshot commands. >> > > 3), others changes according to Ian and Jim's comment. >> > > >> > > regards >> > > >> > > bamvor >> > > >> > > >> >> > --047d7b5d27184e8b3c04fbee747b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Again I was thinking about freezing all the file systems b= efore taking a snapshot.Anyway we can add this feature after the minimal sn= apshot operations patch gets acked.

Regards.
David.


On Mon, Jun 16, 2014 at 9:21 AM, David kiarie <davidkiarie4@gmai= l.com> wrote:



On Mon, Jun 9= , 2014 at 5:08 PM, Bamvor Jian Zhang <bjzhang@suse.com> wrote= :
Hi, Jim

> Bamvor Jian Zhang wrote:
> > Hi,
> >
> > here is the third version about domain snapshot documents, the se= cond version
> > and the first version is here[1][2].
> >
> > there are lots of potential feature about snapshots. for now, i f= ocus on
> > providing the api for libvirt libxl driver in order to support th= e same
> > functionality compare with libvirt qemu driver. and you may alrea= dy notice
> > david is working on libvirt libxl driver. it is a GSoC project[3]= . it is
> > important for him to know the api in order to start coding in lib= virt side.
> >
>
> Right. =C2=A0We can't do much on the libvirt side without libxl AP= Is :-).
>
> > i plan to work on other "advanced feature" after my fir= st stage patch ack.
> >
> > there are two types of snapshots supported by libxl: disk snapsho= t and domain
> > snapshot and four types of operations: create, delete, list and r= evert.
> >
>
> Should the operations also include 'info', to get name, creati= on time,
> disks, etc. on a particular snapshot?
list with --long options will do this: list details of one/all snapsh= ot
information. reference our discuss here[1].
>
> > Disk snapshot will only be crash-consistent if the domain is runn= ing. Disk
> > snapshots can also be internal (qcow2) or external (snapshot in o= ne file,
> > delta
> > in another).
> >
> > Domain snapshots include disk snapshots and domain state, allowin= g to resume
> > the domain from the same state when the snapshot was created. Thi= s type of
> > snapshot is also referred to as a domain checkpoint or system che= ckpoint.
> >
> > In libvirt, there is a something like resource manager for domain= snapshot
> > managements. So, in libxl, all these information is transfered th= rough
> > libxl_domain_snapshot struct. xl will manage the snapshot by itse= lf.
> >
> > Domain snapshot create means save domain state and do disk snapsh= ots.
> > At the beginning of domain snapshot create, it will check whether= it is
> > snapshotable. it is snapshotable if all the disk is qdisk backed.=
> >
> > Domain snapshot revert means rollback the current snapshot state.= and
> > Because the limitation of the qemu qmp, the revert could only sup= port domain
> > snapshot with internal disk snapshot. revert the domain snapshot = with external
> > snapshot doest not support.
> >
> > there are live flag in snasphot configuration file, it will be sa= ve domain
> > memory and do external disk snapshot. to make the thing simple, i= do not want
> > to implement in my first verion of patch.
> >
> > As Ian Campbell said, the support of non-qdisk snapshot is very u= seful.
> > unfortuntely, i have no idea what it need to do. the only non-qdi= sk i know is
> > blktap. and i do not know does how to do snapshot create, delete,= list and
> > revert for blktap? does it support internal or external support?<= br> > >
>
> Looking in tools/blktap2, it seems only external snapshots are support= ed
> via td-util or vhd-util. =C2=A0I suppose lvm would also be considered = an
> external disk snapshot.
thanks. do you mean call these utils in libxl__exec? it seems t= hat only a few
binary called by this functions: bootloader, libxl-save-helper, qemu-dm, qemu-system-i386.
the core function of vhd_util snapshot is vhd_snashot which defined in
(tools/blktap2/include/libvhd.h, /usr/lib64/libvhd.so). although it include= d in
xen-devel package in opensuse12.3. maybe it is a better choice?
>
> > i treat it as an "advanced" feature, i will not cover i= t in my first version
> > of
> > patch.
> >
> > the new struct, api and command is as follows:
> > 1, new struct
> > 1), libxl_snapshot
> > store a disk snapshot information, it is used by disk snapshot cr= eate and
> > delete.
> > libxl_disk_snapshot =3D Struct("disk_snapshot",[
> > =C2=A0 =C2=A0 ("device", =C2=A0 =C2=A0 =C2=A0 =C2=A0str= ing),
> > =C2=A0 =C2=A0 ("name", =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0string),
> > =C2=A0 =C2=A0 ("file", =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0string),
> > =C2=A0 =C2=A0 ("format", =C2=A0 =C2=A0 =C2=A0 =C2=A0str= ing),
> >
>
> Should format be an enum?
yeah, it should be. i will use as libxl_disk_format. i only support q= cow2 as
external snapshot image.
>
> > =C2=A0 =C2=A0 ])
> >
> > device: device name to snapshot. e.g. sda, hda...
> > name: snapshot name given by user. it will the be same name as do= main snapshot
> > name.
> > the following paramenter is only useful for external snapshot. > > file: external snapshot file.
> > format: the format of external snapshot file
> >
> > 2), libxl_domain_snapshot
> > store domain snapshot information which store in the path shown a= bove. i add
> > some api for create, delete and list these information.
> > libxl_domain_snapshot =3D Struct("domain_snapshot",[ > > =C2=A0 =C2=A0 ("name", =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0string),
> > =C2=A0 =C2=A0 ("creation_time", uint64),
> > =C2=A0 =C2=A0 ("save", =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0string),
> > =C2=A0 =C2=A0 ("disks", Array(libxl_disk_snapshot, &quo= t;num_disks")),
> > =C2=A0 =C2=A0 ])
> >
>
> I think 'description' and 'state' would be useful fiel= ds, the latter
> being the state of the domain when the snapshot was created.
sorry missing this. when you mention state, do you mean the following=
combination in libxl_dominfo?
=C2=A0 =C2=A0 bool running;
=C2=A0 =C2=A0 bool blocked;
=C2=A0 =C2=A0 bool paused;
=C2=A0 =C2=A0 bool shutdown;
=C2=A0 =C2=A0 bool dying;
>
> > name: snapshot name given by user. if user do not provide the nam= e, it will be
> > the epoch seconds.
> > creation_time: the epoch seconds.
> > save: the memory save file for this snapshot.
> > disks: store the disk snapshot information assoiate with this dom= ain.
> >
> > 2, new functions
> > there is no common api like libxl_snapshot_xxx. the reason is tha= t different
> > toolstack may need to different event handling machanism(synchron= ize or
> > asynchronize). and obviously, domain snapshot create need async h= andler. so i
> > decide to only provide the sub api for xl and other toolstack(e.g= . libvirt).
> > it make eailer for toolstack to handle the event by themselves. > >
>
> What is the domain_snapshot struct used for then? =C2=A0Seems it is un= needed
> if not exposed in the API, something to be declared by the app. =C2=A0= I'd
> like to hear what the Xen tools devs think about this approach. =C2=A0= Ian J,
> Ian C, Anthony?
currently, libxl_domain_snapshot is only used by xl_cmdimpl.c.
domain load snapshot configuration may be useful when libvirt libxl driver<= br> want to load libxl snapshot configuration.
there is a issue i want to discuss with you. do we need libvirt and libxl use the same domain snapshot configuration? when domain snapshot is created=
or reloading, use libxl-json format file instead of libvirt xml format. in = this
way, it is easy to handle the snapshot if user migrate between libxl and li= bvirt
toolstack.
=C2=A0
In my opinion,= this will require a lot of changes on the libvirt side.Libvirt depends ver= y heavily on the xml.
I don't know if this will look hacky bu= t I would prefer the file management code on libxl to be include in the API= .
What I suggest is the file management code to be wrapped inside the ex= posed API.
Anyway we should hear from Jim but in the meantime I c= ontinue working with the xml.

>
> > 1), in libxl/libxl.h
> > the implementation will be located in libxl_snapshot.c
> > /* disk snapshot api
> > =C2=A0* support create for external and internal disks, support d= elete for internal
> > =C2=A0* snapshot of disks.
> > =C2=A0*/
> > /* create disk snapshot according to the device name in snapshot = array. nb is
> > =C2=A0* the number of snapshot array.
> > =C2=A0* use the qmp transaction to ensure all snapshot of disk is= coherence.
> > =C2=A0*/
> > int libxl_disk_snapshot_create(libxl_ctx *ctx, int domid,
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libxl_disk_snapshot *snapsh= ot, int nb,
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0const libxl_asyncop_how *ao= _how);
> > /* delete number of nb disk snapshot describe in snapshot array > > =C2=A0*/
> > int libxl_disk_snapshot_delete(libxl_ctx *ctx, int domid,
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libxl_disk_snapshot *snapsh= ot, int nb);
> >
>
> As David mentioned in his reply, there should be a revert as well. =C2= =A0Is
> list (and info if added) handled by the app (xl, libvirt, etc)?
for revert, reference my previous reply.
for list, it will be handled by the app, just like libvirt qemu driver.

regards

bamvor

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

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



--047d7b5d27184e8b3c04fbee747b-- --===============8022686809812590990== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8022686809812590990==--