Re: [Xen-devel] [RFC V8 2/3] libxl domain snapshot API design

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

>>> On 11/28/2014 at 11:43 PM, in message 
>>> <1417189409.23604.62.camel@xxxxxxxxxx>,
Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote: 
> On Tue, 2014-11-25 at 02:08 -0700, Chun Yan Liu wrote: 
> > Hi, Ian, 
> >  
> > According to previous discussion, snapshot delete and revert are 
> > inclined to be done by high level application itself, won't supply a 
> > libxl API. 
>  
> I thought you had explained a scenario where the toolstack needed to be 
> at least aware of delete, specifically when you are deleting a snapshot 
> from the middle of an active chain.
  
The reason why I post such an overview here before sending next
version is: I'm puzzled about what should be in libxl and what
in toolstack after previous discussion. So posted here to seek
some ideas or agreement first. It's not a full design, not break
down to libxl and toolstack yet.

>  
> Maybe that's not "snapshot delete API in libxl" though, but rather a 
> notification API which the toolstack can use to tell libxl something is 
> going on. 

About notification API, after looking at lvm, vhd-util and qcow2, 
I don't think we need it. No extra work needs to do to handle 
disk snapshot chain. 
lvm: doesn't support snapshot of snapshot. 
vhd-util: backing file chain, external snapshot. Don't need to 
          delete the disk snapshot when deleting domain snapshot. 
qcow2: 
* internal disk snapshot: each snapshot increases the refcount 
  of data, deleting snapshot only decrease the refcount, won't 
  affect other snapshots. 
* external disk snapshot: same as vhd-util, backing file chain. 
  Don't need to delete disk snapshot when deleting domain snapshot.

>  
> >  I'm wondering snapshot create need a new common API? 
> > In fact its main work is save domain and take disk snapshot, xl can 
> > do it too.  
For saving memory, there is already API for that. The missing part is
taking disk snapshot.

>  
> I don't believe xl can take a disk snapshot of an active disk, it 
> doesn't have the machinery to deal with that sort of thing, nor should 
> it, this is exactly the sort of thing which libxl is provided to deal 
> with. 

Like delete a disk snapshot, xl can call external command to do that
(e.g. qemu-img). But it's better to call qmp to do that.
Anyway, if for domain snapshot create, we should put creating disk
snapshot process in libxl, then for domain snapshot delete, we
should put deleting disk snapshot process in libxl. That is, in libxl
there should be:
libxl_disk_snapshot_create (which handles creating disk snapshot)
libxl_disk_snapshot_delete (which handles deleting disk snapshot)

Otherwise I would think it's weird to have in libxl:
libxl_domain_snapshot_create (wrap saving memory [already has API] 
                              and creating disk snapshot)
libxl_disk_snapshot_delete (deleting disk snapshot)

>  
> Also, libxl is driving the migration/memory snapshot, and I think the 
> disk snapshot fundamentally needs to be involved in that process, not 
> done separately by the toolstack. 
>  
> > I just write down an overview of the snapshot work (see below). 
> > The problem is: do we need to export API? What kind of API? 
> > In updating Bamvor's code, I think xl can do all the work, libvirt can 
> > do the work too even without libxl's help. 
> >  
> > Of course, there are some thing if put in libxl, it will be easier to 
> > use, like the domain snapshot info structure, gentype.py will 
> > directly generate useful init/dispose/to_json/from_json functions. 
> > Or the disk snapshot part can be extracted and placed in libxl or libxlu.
 
And about the snapshot json file store and retrieve, using
gentype.py to autogenerate xx_to_json and xx_from_json functions
is very convenient, there would be a group of functions
set/get/update/delete_snapshot_metadata based on that.
But I didn't see other such usage in xl, and it's not proper to 
place in libxl. Anywhere could it be placed but used by xl? 
Wei might have some ideas about this?

-Chunyan

> >  
> > Any suggestions about which part is better to be extracted as libxl 
> > API or better not? 
> >  
> > Thanks, 
> > Chunyan 
> >  
> >  
> ----------------------------------------------------------------------------- 
> ------------------------- 
> > libxl domain snapshot overview 
>  
> Just to be 100% clear: This is an overview of a domain snapshot 
> architecture for a toolstack which uses libxl. A bunch of the things 
> described here belong to the toolstack and not to libxl itself. 
>  
> I've tried to read with that in mind but a complete document should 
> mention this and be careful to be clear about the distinction where it 
> matters. 
>  
> > 0. Glossary 
> [...] 
> > * not support disk-only snapshot [1]. 
> >                                         
> > [1] 
> >  This is different from "libvirt". 
> >  To xl, it only concerns active domains, and even when domain 
> >  is paused, there is no data flush to disk operation. So, take 
> >  a disk-only snapshot and then resume, it is as if the guest 
> >  had crashed. For this reason, disk-only snapshot is meaningless 
> >  to xl. Should not support. 
> >  
> >  To libvirt, it has active domains and inactive domains, for 
> >  the active domains, as "xl", it's meaning less to take disk-only 
> >  snapshot, but for inactive domains, disk-only snapshot is valid. 
> >  Should support. 
>  
> Do you mean to say here that disk-only snapshots are not supported in 
> some toolstacks, or in no toolstack? Or are you just saying that libxl 
> doesn't need to support them because they only apply to inactive 
> domains? 
>  
> In either case it seems to me like your footnote is saying that you *do* 
> want to support disk-only snapshots, at least in some stacks and/or 
> configurations. 
>  
> I think you probably mean to say that disk-only snapshots of *active* 
> domains are not supported. Whereas disk-only snapshots of inactive 
> domains may or may not be depending on the toolstack. 
>  
> >  
> > 2. Requirements 
> >  
> > General Requirements: 
> > * ability to save/restore domain memory 
> > * ability to create/delete/apply disk snapshot [2] 
> > * ability to parse user config file 
> > * ability to save/load/update domain snapshot metadata (or called 
> >   domain snapshot info, the metadata at least includes: 
> >   snapshot name, create time, description, memory state file, 
> >   disk snapshot info, parent (in snapshot chain), current (is 
> >   currently applied)) 
> >  
> > [2] Disk snapshot requirements: 
> > * external tools: qemu-img, lvcreate, vhd-util, etc. 
> > * For a basic goal, we support 'raw' and 'qcow2' backend types only. 
> >   Then only requires qemu: 
> >     use libxl qmp command (better) or "qemu-img" 
>  
> You should leave these implementation details for a later section, in 
> this context they just invite quibbling about whether things belong in 
> libxl etc and whether qmp commands are "better". 
>  
> The rest looks ok, but without the remainder of the design described in 
> terms of the concepts given here it's hard to comment further. 
>  
> I'd suggest putting this all into one coherent document (not 3 as 
> before) which starts by describing the terminology (section 0 in your 
> mail which I'm replying to now), then gives an overview of the 
> architecture (the rest of that mail), then describe which components 
> (libxl, toolstack, etc) implement each bit of the architecture, then 
> describe the libxl API which makes this possible (covered in previous 
> mails I think). 
>  
> I think you have most of the words either here or from the other mails, 
> they just need putting together into a single thing and going through to 
> make sure that they use the same terminology and describe the same 
> things etc. 
>  
> Please take a look at 
> http://xenbits.xen.org/people/dvrabel/event-channels-H.pdf or 
> http://lists.xen.org/archives/html/xen-devel/2014-10/msg03235.html for 
> examples of the sort of cohesive document I mean. 
>  
> Ian. 
>  
>  
>  




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