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

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

>>> On 10/29/2014 at 06:26 PM, in message <1414578409.29975.9.camel@xxxxxxxxxx>,
Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote: 
> On Tue, 2014-10-21 at 21:59 -0600, Chun Yan Liu wrote: 
> > > Is this operation any different to destroying the domain and using  
> > > libxl_domain_restore to start a new domain based on the snapshot? Is  
> > > this operation just a convenience layer over that operation?  
> >  
> > It depends on implementation. It's a simple way to destroy the domain 
> > first, then start new domain based on snapshot. But destroying the 
> > domain may be not good to user (after xl snapshot-revert, domid is 
> > changed.)  and may cause some problem in libvirt (may affect its 
> > event handling ?). 
>  
> I would hope that as part of the implementation libvirt would learn to 
> cope with this if it can't already, but it can surely already cope with 
> migration and reverting to a snapshot is not so very different. 

See. If implemented in this way (destroy domain and restore based on snapshot),
it's better not supply a libxl API. Let xl and libvirt handle that by 
themselves.
(Libxl destroys the domain and starts a new domain will cause problem in 
libvirt,
libvirt has no idea of the new domain created by libxl internally.)

Thanks Ian. I'll update the doc.

- Chunyan

>  
> > Or another way is: not destroying the domain, but through a process 
> > like pause domain, reload memory, reload disk snapshot, reload config 
> > file, resume domain. Complex but maybe better. 
>  
> I don't think the complexity of resetting an already existing domain's 
> memory and i/o state to an earlier incarnation rather than starting from 
> a clean slate should be underestimated either (TBH it never occurred to 
> me that you might try this). AFAICT you'd need to effectively tear 
> everything down to a blank slate and then do all the same things that 
> you would do in the destroy case. 
>  
> Ian. 
>  
>  
>  



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