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

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

>>> On 12/13/2014 at 12:22 AM, in message 
>>> <1418401323.16425.28.camel@xxxxxxxxxx>,
Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote: 
> On Tue, 2014-12-09 at 20:46 -0700, Chun Yan Liu wrote: 
> >  
> > >>> On 12/9/2014 at 07:11 PM, in message 
> > >>> <1418123518.14361.20.camel@xxxxxxxxxx>, 
> > Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:  
> > > On Mon, 2014-12-08 at 22:04 -0700, Chun Yan Liu wrote:  
> > > > Partly. At least for domain disk snapshot create/delete, I prefer using 
> > > >  
> > > > qmp commands instead of calling qemu-img one by one. Using qmp  
> > > > commands, libvirt will need libxl's help. Of course, if libxl doesn't  
> > > > supply that, libvirt can call qemu-img to each disk one by one,  
> > > > not preferred but can do.  
> > >   
> > > You can't use qmp unless the domain is active, for an inactive domain  
> > > there is no qemu to talk to, so you have to use qemu-img anyway in that  
> > > case. Does libvirt not have existing code to do all this sort of thing?  
> > > (I thought so, but it turns out I may be wrong, see below).  
> >  
> > No. Even inlibvirt/qemu_driver (for kvm), it does the work itself through 
> > qemu monitor commands. 
>  
> Is this just the code for the actual act of taking a snapshot or is it a 
> complete snapshotting infrastructure in the driver itself? 
>  
> I would hope/assume that there was a split between the common code which 
> drives everything and tracks all the state etc and the specific driver 
> backend which is used to make state changes to active domains. Is that 
> the case or is everything snapshot related in the libvirt qemu_driver? 

Everything snapshot related is done in libvirt qemu driver. But data structures
about managing domain snapshots are common, so each hypervisor driver can
share.

>  
> > > And for an active domain I expect that *must* use qmp, since it seems  
> > > unlikely that you can go around changing things under the feet of an  
> > > active process (maybe I'm wrong?). 
> >  
> > For active domain, I tried 'qemu-img snapshot' after pausing a domain, 
> > the commands succeeded. But I also think using qmp commands is better 
> > since qemu supplies transaction qmp, it avoids the trouble to roll back 
> > status when using qemu-img to do disk snapshot one by one but only part of 
> > disks succeed. 
>  
> Yes, using qmp for an active domain seems sensible. 
>  
> But you can't use qmp on an inactive domain. Does libvirt deal with this 
> in common code or does it require two code paths in the backend driver, 
> one for active and one for inactive domains? 

Taking libvirt qemu driver for example, it goes two codes paths for active
domain and inactive domain. For inactive domain, it calls qemu-img
command to do the job. For active domain, calls qmp commands through
qemu monitor.

>  
> > So, if disk snapshot functions can be provided to both libvirt and xl  
> usage, 
> > it's very helpful to libvirt side. In this way, I may prefer to put disk  
> snapshot 
> > functions to libxlu. 
>  
> The actual command to snapshot a disk of an active+paused domain is fine 
> to go into libxl. In fact due to the proposed use of qmp it would have 
> to be. 
>  
> Anything to do with the subsequent management of snapshots most likely 
> doesn't belong in libxl. Whether that stuff belongs in libxlu, xl or 
> libvirt depends on what scope there is for multiple toolstacks to use a 
> given helper function. 

OK. Thanks.

>  
> > > My understanding was that your primary aim here was to enable snapshots  
> > > via libvirt and that xl support was just a nice to have. Is that right?  
> >  
> > We hope both :-) 
>  
> OK, thanks for clarifying. 
>  
> > Libvirt side already has some codes as I know and hopes to integrate with 
> > libxl to enable snapshots. Of course the two toolstacks can have some 
> > differences in commands, that's OK. 
> >  
> > Libvirt side, to use unified virsh commands, it will supply 
> > snapshot-create/delete/revert/list. 
>  
> This is what I expected you were aiming for. 
>  
> > Xl side, if it's better to supply snapshot-create/revert, we can implement 
> > like that. Then it IS much easier since no need to manage snapshots in xl, 
> > then no save/retrieve json file things and no snapshot chain things. Do 
> > we want/decide to follow this? 
>  
> The xl snapshot functionality should be kept as simple as possible and 
> following the existing xl idioms of managing storage and saved VM images 
> via existing CLI command (qemu-img, lvcreate, ls, mv, cp etc).

Got it. Thanks. So I'll update document.

Chunyan
 
>  
> Ian. 
>  
>  
>  


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