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

Re: [Xen-devel] [RFC V6] Libxl Domain Snapshot API Design

On Tue, 2014-09-09 at 23:53 -0600, Chun Yan Liu wrote:
> > So I don't think there is any need (or even desire) for libxl to 
> > replicate any of that functionality. It should concern itself with 
> > taking a snapshot when asked and then forget all about it. 
> >  
> > I think things work the same with e.g. qemu and other libvirt backends. 
> > A qemu process only exists to track an actual running domain, all of the 
> > other state including the configuration when the domain is not running 
> > etc is all handled at the libvirt layer. When you take a snapshot of a 
> > qemu backed domain then after that snapshot has happened the qemu 
> > process knows no more about it. So in this way of thinking qemu and 
> > libxl are functionally equivalent bits i.e. things which are used to 
> > instantiate actual running domains and perform operations on them. 
> >  
> > Does that make sense? 
> Totally agree with you. I've mixed something in xl and libxl. It's correct
> that as libxl it should only do what application asks it to do and then
> forget everything. Maintaining state and other information is not libxl's
> work, it's the work of high level application. Libvirt does have datamodel
> to keep tracking snapshot info, it doesn't need libxl to do that. xl can
> maintain snapshot info in application level.

Great! I'm glad we are on the same page.

> The only problem is snapshot-delete:
> to delete disk snapshot, it has to call qmp command, libvirt libxl driver
> cannot do that itself (except adding qmp related helper functions, quite
> a duplicate with libxl_qmp.c I think).

What is this qmp command, what does it do and what arguments does it

Perhaps it's something like "the snapshot chain of $disk may have
changed, go and figure out what to do"? Or is it more complicated than

> If we supply libxl_domain_snapshot_delete API, to handle snapshot-chain
> (parent, children, sibling), it doesn't work without info about all snapshots.
> Or, if we supply libxl_disk_snapshot_delete API, that's also weird with this
> only-one disk snapshot API.

So, the issue here is deleting a snapshot where there is an actively
running domain using some other snapshot in the chain, is that right?

Specifically we aren't interested in deleting a snapshot which is
actually being used right now? Would that case be handled by destroying
the domain in question first?

So in the simplest case we might have:


And there may be a domain running which is using any of BASE, A or B? Do
we then need to be able to delete either of the other two snapshots?

If a domain is running using SNAPSHOT A then I presume SNAPSHOT B can be
trivially deleted without needing to communicate with that domain.

If a domain is running using SNAPSHOT B and we want to delete SNAPSHOT A
then the domain needs to know that it should rescan the chain to
discover that it is has become:

        BASE -> SNAPSHOT B

Or is the qemu associated with the domain actually responsible for
making that happen (i.e. folding the contents of SNAPSHOT A into either
BASE or SNAPSHOT B as appropriate at runtime)? Or does that happen

I think there are more complex cases with tree's of snapshots etc (e.g):
            ----- SNAPSHOT A
BASE ----x
            ----- SNAPSHOT B

But lets deal with the simple linear case first ;-)


Xen-devel mailing list



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