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

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

>>> On 10/21/2014 at 01:37 PM, in message <5445F137.5EA : 102 : 21807>, Chun Yan
Liu wrote: 

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

And here, any suggestion?

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