Re: [Xen-devel] [RFC V7 3/3] xl snapshot-xxx Design

["Chun Yan Liu" <cyliu@xxxxxxxx>]

>>> On 10/21/2014 at 12:39 AM, in message 
>>> <1413823182.29506.16.camel@xxxxxxxxxx>,
Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote: 
> On Fri, 2014-10-10 at 16:48 +0800, Chunyan Liu wrote: 
> > 1. xl commandline interface design 
> >  
> > xl snapshot-create: 
> >   Create a snapshot (disk and RAM) of a domain. 
> >  
> >   SYNOPSIS: 
> >     snapshot-create <domain> [<cfgfile>] [--disk-only] [--reuse-external] 
> >     [--live] 
> >  
> >   OPTIONS: 
> >     [--domain] <string>  domain name, id or uuid 
> >     [--cfgfile] <string>  domain snapshot configuration 
>  
> Is this separate to or the same as the <cfgfile> argument? Is this a 
> xl.cfg(5) config file or something specific to snapshot cfg? 
>  
> >     --disk-only      capture disk state but not vm state 
> >     --reuse-external  reuse any existing external files 
> >     --live           take a live snapshot 
> >  
> >     If option includes --live, then the domain is not paused while creating 
> >     the snapshot, like live migration. This increases size of the memory 
> >     dump file, but reducess downtime of the guest. Only support this flag 
> >     during external checkpoints. 
> >  
> >     If option includes --disk-only, then the snapshot will be limited to 
> >     the disks, and no VM state will be saved. For an active guest, this is 
> >     not supported. 
> >  
> >     If specify @cfgfile, cfgfile is prioritized. 
>  
> What does "prioritized" mean in this context? 
>  
> > xl snapshot-delete: 
> >   Delete a snapshot of a domain. 
>  
> So what's not clear yet (but I see it is discussed below) is the manner 
> in which xl is going to manage snapshots. 
>  
> Typically in the past users have been expected to manage disk and save 
> images with rm(1) and/or various format specific tools (qemu-img, 
> vhd-image, lvcreate etc). 
>  
> I think you are proposing that there should be some path full of 
> snapshots, is that right? That is adding a lot of complexity to xl which 
> could potentially be avoided by sticking to the "user takes care of it" 
> path. 
>  
> > 3. xl structure to maintain VM snapshot info 
>  
> These are repeating the libxl ones? The look subtly different. If they 
> are xl specific then they should be in the xl_foo namespace, and of 
> course the should incorporate public libxl API structs where necessary. 
>  
> Having the structs be named libxl_* makes it hard for me to see if you 
> have gotten the layering right in much of the below. I'll try and point 
> out the ones I think should be xl_* below, if you really meant libxl_* 
> then that probably means I disagree with the layering. 
>  
> > According to libxl_domain_snapshot_info, a json file will be saved on disk. 
>  
> You mean that libxl_domain_snapshot_info (really 
> xl_domain_snapshot_info) can be serialised to disk as json, right? 
>  
> >  
> > 4. xl snapshot-xxx implementation details 
>  
> How do these interact with xl create/destroy/shutdown/save/restore? 
>  
> e.g. does destroying a domain remove any snapshots? 
> Typically in the past users have been expected to manage disk and save 
> images with rm(1) and/or various format specific tools (qemu-img, 
> vhd-image, lvcreate etc). 
>  
> I think you are proposing that there should be some path full of 
> snapshots, is that right? That is adding a lot of complexity to xl which 
> could potentially be avoided by sticking to the "user takes care of it" 
> path. 
>  
> > 3. xl structure to maintain VM snapshot info 
>  
> These are repeating the libxl ones? The look subtly different. If they 
> are xl specific then they should be in the xl_foo namespace, and of 
> course the should incorporate public libxl API structs where necessary. 
>  
> Having the structs be named libxl_* makes it hard for me to see if you 
> have gotten the layering right in much of the below. I'll try and point 
> out the ones I think should be xl_* below, if you really meant libxl_* 
> then that probably means I disagree with the layering. 
>  
> > According to libxl_domain_snapshot_info, a json file will be saved on disk. 
>  
> You mean that libxl_domain_snapshot_info (really 
> xl_domain_snapshot_info) can be serialised to disk as json, right? 
>  
> >  
> > 4. xl snapshot-xxx implementation details 
>  
> How do these interact with xl create/destroy/shutdown/save/restore? 
>  
> e.g. does destroying a domain remove any snapshots? 

Since in xl domain is deleted when destroyed/shutdown/save, no state
like previously in xend, created but not started, deleted only when issue
'delete' command.

I don't think clearly now about:
how to handle snapshots when destroy/shutdown/save/migrate a domain.
In theory, if a domain is deleted, the snapshots should all be deleted.
But this way, I don't know how much value this operation can bring to users.
Those snapshot are still usable. One can start a new domain from a snapshot.
There is memory state (can restore memory, restore config) and disk
snapshot (can restore disk status).

Do you have any suggestions?

>  
> A bunch of these are gong to require some care wrt the possibility of 
> multiple xl invocations and the possibility of an xl crash. 
>  
>  
> A bunch of these are gong to require some care wrt the possibility of 
> multiple xl invocations and the possibility of an xl crash. 
>  
> > "xl snapshot-create" 
> >  
> >     1), parse args or domain snapshot configuration file. 
> >     2), fill info in libxl_domain_snapshot_args struct according to 
> >         options or config file. 
> >     3), call libxl_domain_snapshot_create() 
> >     4), fill info in libxl_domain_snapshot_info. 
>  
> xl_domain_snapshot_info? 
>  
> >     5), save snapshot info in json file under 
> > "/var/lib/xen/snapshots/domain_uuid" 
>  
> Do the disk images go here too? 
>  
> > "xl snapshot-list" 
> >  
> >     2), display information from those libxl_domain_snapshot_info(s) 
> >  
> > "xl snapshot-delete" 
> >  
> >     1), read snapshot json file from 
> >         "/var/lib/xen/snapshots/domain_uuid/snapshotdata-<snapshot_name>\ 
> >         .libxl-json", parse the file and fill in libxl_domain_snapshot_info 
>  
> .xl-json and xl_domain_snapshot_info, I think? 
>  
> >     2), according to parent/children info in libxl_domain_snapshot_info 
>  
> xl_domain_snapshot_info. 
>  
> >         and commandline options, decide which domain snapshot to be  
> deleted. 
> >         To delete each domain snapshot, fill in 
> >         libxl_domain_snapshot_args and call libxl_domain_snapshot_delete(). 
>  
> Depending on the state of the domain, much of this can be done with 
> unlink and/or calling out to external tools. 
>  
> >     3), refresh parent/children relationship, delete json file for those 
> >         already deleted snapshot. 
> >  
> > "xl snapshot-revert" 
> >  
> >     1), read snapshot json file from 
> >         "/var/lib/xen/snapshots/domain_uuid/snapshotdata-<snapshot_name>\ 
> >         .libxl-json", parse the file and fill in  
> libxl_domain_snapshot_info. 
>  
> .xl-json and xl_domain_snapshot_info 
>  
> >     2), fill in libxl_domain_snapshot_args 
> >     3). call libxl_domain_snapshot_revert(). 
>  
>  
>  
>  
> >     1), read all domain snapshot related json file under 
> >         "/var/lib/xen/snapshots/domain_uuid". Parse each file and fill in 
> >         libxl_domain_snapshot_info struct. 
>  
> xl_domain_snapshot_info? 
>  


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