[libvirt] [PATCH 0/3 TCK] Some tests for snapshot management

[Daniel P. Berrange]

On Fri, Aug 26, 2011 at 09:15:43AM -0600, Eric Blake wrote:
> On 08/26/2011 09:03 AM, Daniel P. Berrange wrote:
> >>>IMHO, we should be allowed to call 'virDomainDestroy' on a
> >>>transient guest with snapshots, and then later 'virDomainCreateXML'
> >>>to re-create the guest and still have access to the snapshots
> >>
> >>But leaving the snapshot metadata files behind is problematic.  If
> >>you create a new domain with the same name but a different uuid,
> >>then those existing metadata files _will_ cause problems with the
> >>domain definition.
> >
> >Surely this simply means that the snapshot metadata files shold
> >be recording the orignal domain UUID,
> 
> They are.  Even before my series, the original UUID was the _only_
> thing about the domain that it was storing (my series fixes things
> to store the entire <domain> xml, which is needed for proper
> reversion to a snapshot, but at least old existing snapshots can
> already be recognized).
> 
> >so that we can safely
> >ignore/discard them if the guest is re-defined with the same
> >name but new uuid ?
> 
> We have two options for when to nuke stale metadata - at the point
> when the domain goes down, or at the point when a new domain is
> created whose name differs from what was stored in the stale
> metadata.
> 
> I guess you are leaning towards the latter - if a new domain is
> created with the right uuid, then the snapshots are already
> available; but if created with the same name but a new uuid, then we
> finally know to clean up the mess.
> 
> But I'm not convinced that it scales well - if you create lots of
> transient domains, all with snapshots, but never reuse the same
> name, then the metadata directory keeps growing without bounds even
> though you never have that many domains at any given point of time.
> Besides, since the only way to use libvirt to delete snapshot
> metadata is via a virDomainSnapshotPtr object, but the only way to
> get at a snapshot is via a virDomainPtr object, I think it is risky
> to leave stale metadata in libvirt's directory trees that _cannot_
> be removed by any existing libvirt API.
> 
> Cleaning at the time the transient domain goes away is nicer for
> scalability.  It means that nothing will be stored in
> /var/lib/libvirt/qemu/ unless it can also be accessed via a current
> virDomainPtr.  It is also nicer for migration - remember, in my RFC,
> I mentioned how snapshots and migration interact - the only sane way
> is for the destination to start from a blank state, then recreate
> the same snapshot hierarchy as was present on the source alongside
> the migration, then remove the snapshot metadata on the source.  If
> we keep snapshot metadata around even after a transient domain is no
> longer running on a host, then it becomes harder to start from a
> clean slate when migrating a new guest by that name onto the host.
> 
> >>If resurrecting previous snapshots is important, then it should be
> >>done with VIR_DOMAIN_SNAPSHOT_CREATE_REDEFINE.
> >
> >This is all workable, but is it overkill compared to just validating
> >the original VM uuid against the new UUID when loading metdata ?
> 
> I hope that we can come to agreement on whether or not making the
> management app of the transient domain have to track snapshot
> metadata counts as overkill or not.

I don't have a strong feeling on it, as long as we have a way to
get back the snapshots when recreating a transient guest. So lets
go with your suggestion.


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|