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

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

>>> On 9/10/2014 at 08:17 PM, in message
<1410351477.8217.375.camel@xxxxxxxxxxxxxxxxxxxxxx>, Ian Campbell
<Ian.Campbell@xxxxxxxxxx> wrote: 
> 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 
> require?

The qmp command is 'blockdev-snapshot-delete-internal-sync'.
Purpose of this qmp command is to delete an internal snapshot within the
disk. E.g. for qcow2 format, a internal disk snapshot will store snapshot
related info within the disk. To delete this snapshot, one has to communicate
with qemu (through qmp command), let qcow2 driver to handle that.

 { "execute": "blockdev-snapshot-delete-internal-sync",
                       "arguments": { "device": "ide-hd0",
                                                  "name": "snapshot0" }
}

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

I meant to say:
        BASE -> SNAPSHOT A -> SNAPSHOT B
When user want to delete  SNAPSHOT A, if flag indicates deleting
all children, then SNAPSHOT B should be deleted too; if without this flag,
then by default all changes to SNAPSHOT A should be merged to
SNAPSHOT B. In any case, it should know the relationship between
SNAPSHOT A and SNAPSHOT B.

Well, after thinking again, I think maybe there is no problem here:
libxl supplies libxl_domain_snapshot_delete API, that could help doing disk
snapshot-delete work. In disk level, 'all changes to SNAPSHOT A should
be merged to SNAPSHOT B' can be ensured by qemu automatically, libxl
doesn't need to take care of that.
Then xl or libvirt can do all other things, they scan the domain snapshot
information to decide which snapshot is related and should be deleted,
and refresh domain snapshot chain relationship after the work.

>  
> 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: 
>  
>         BASE -> SNAPSHOT A -> SNAPSHOT B 
>  
> 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 
> elsewhere?

If SNAPSHOT B is based on SNAPSHOT A, when A is deleted, changes made
to A will be merged to B. Qemu can ensure that, at least for a qcow2 disk,
qcow2 driver can ensure that.

But from Domain level, it is high level application to refresh the domain
snapshot chain relationship. In libvirt, it is qemu_driver to rerefresh the
chain relationship and update related qemuDomainSnapshotObj (update
information of .parent, .sibling, .children, etc.).

>  
> 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 ;-) 
>  
> Ian. 
>  
>  
>  


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