[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Tue, 2014-12-02 at 23:14 -0700, Chun Yan Liu wrote:
> >>> 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.

I guess I thought we had gotten closer to this than we actually have.

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

You don't need to, but might a toolstack (or user) want to consolidate
anyway, e.g. to reduce chain length? (which might otherwise be overly

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

The toolstack (xl or libvirt) doesn't have direct access to qmp, it
would have to go via a libxl API, for an Active domain at least.
qemu-img is the right answer for an Inactive domain.

Secondly, the disk snapshot has to happen while the domain is
paused/quiesced for consistency. This happens deep in the bowels of the
libxl save/restore code. So either libxl has to do the disk snapshots at
the same time or we need a callback to the toolstack in order for it to
make the snapshots.

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

The create and delete cases are subtly different, so it may be that the
API ends up asymmetric.

The create mechanism (whichever one it is) operates on a single Active
domain and is reasonably well defined.

The delete operation however can potentially operate on multiple Active
domains, e.g. 2 domains are running with a common ancestor snapshot
which is being removed.

How would the delete interface deal with this case? In particular
without libxl becoming involved in "storage management".

The reason I'm thinking of a "delete notify" style interface for Active
domains is that it then applies to a single Active domain at a time. If
multiple domains are affected by a snapshot deletion then the
notification is called multiple times.

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

xl hasn't needed to use the autogeneration infrastructure to date, but
there's no reason why it couldn't do so if there was a need. Just create
xl_types.idl and hook it into the Makeile.

It would be harder to extend this to other toolstack, but I suspect we
don't need to.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.