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

[Ian Campbell <Ian.Campbell@citrix.com>]

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@citrix.com>,
> Ian Campbell <Ian.Campbell@citrix.com> 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?

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

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

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

Ian.