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? 

Same. Will remove this option.
Add an option --name (snapshot name).

> Is this a 
> xl.cfg(5) config file or something specific to snapshot cfg?

specific to snapshot cfg.

>  
> >     --disk-only      capture disk state but not vm state

Will remove this option.
As replied in previous patch, xl won't support disk-only snapshot.

> >     --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? 

If specify cfgfile, and at the same time has option '--name snapshotname', will
use cfgfile info (like use 'name' got  from config file).

>  
> > 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. 

You are right. It's xl specific one, not the same as libxl one. My mistake.
Will change into xl_foo namespace.
There is a path to store each snapshot_info in json file. From that file,
can get memory state file location and disk snapshot info. Libxl
can help delete memory state file and delete disk snapshot
(internal or external).

>  
> 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? 

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? 
>  
> A bunch of these are gong to require some care wrt the possibility of 
> multiple xl invocations and the possibility of an xl crash. 
> >         "/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? 
>  
> > "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? 

Right.

>  
> >     5), save snapshot info in json file under 
> > "/var/lib/xen/snapshots/domain_uuid" 
>  
> Do the disk images go here too? 
>  
> > "xl snapshot-list" 
> >  
> >     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?

Right.
 
>  
> >     2), display information from those libxl_domain_snapshot_info(s) 
> .xl-json and xl_domain_snapshot_info, I think? 

Right.

>  
> >     2), according to parent/children info in libxl_domain_snapshot_info 
>  
> xl_domain_snapshot_info.

Right.

>
> >  
> > "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 
>  
> >         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. 

Yes, xl or libvirt application can delete memory state file and delete
disk snapshot (eg. call qemu-img to delete internal disk snapshot instead
of qmp command, or delete external snapshot directly).
Just both xl and libvirt do the same work repeatly. So, I propose
libxl_domain_snapshot_delete API. Keep it or not?

>  
> >     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 

Right.

>  
> >     2), fill in libxl_domain_snapshot_args 
> >     3). call libxl_domain_snapshot_revert(). 
>  
>  
>  
>  


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